Loading article…
メディアストリーム用のSDES（Session Description Protocol Security Descriptions ）は、セキュアリアルタイムトランスポートプロトコルの鍵をネゴシエートする方法です。[ 1 ] 2006年7月にIETFに標準化が提案されました（RFC 4568を参照）。
鍵はSIPメッセージのSDP添付ファイルとして転送されます。つまり、SIPトランスポート層は、他の誰も添付ファイルを見ることができないようにする必要があります。これは、TLSトランスポート層を使用するか、S/MIMEなどの他の方法を使用することで実現できます。TLSを使用する場合、SIPプロキシチェーンの次のホップは信頼できると想定され、リクエストのセキュリティ要件はプロキシ側で処理されます。
この方法の最大の利点は、非常にシンプルであることです。鍵交換方式は既に複数のベンダーに採用されていますが、中には鍵の転送に安全なメカニズムを使用していないベンダーもあります。これにより、この方式を事実上の標準とするために必要な実装規模が確保されつつあります。
この原理を例で説明すると、電話機はプロキシに発信します。sipsスキームを使用することで、通話を安全に行う必要があることを示します。鍵はSDP添付ファイルにBase64エンコードされています。
INVITE sips:*97@ietf.org;user=phone SIP/2.0 経由: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport 送信元: "123" < sips:123@ietf.org >;タグ=mogkxsrhm4 宛先: < sips:*97@ietf.org;user=phone > 通話ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07 CSeq: 1 INVITE 最大フォワード数：70 連絡先: < sip:123@172.20.25.100:2049;transport=tls;line=gyhiepdm >;reg-id=1 ユーザーエージェント: snom360/6.2.2 承認: application/sdp 許可: INVITE、ACK、CANCEL、BYE、REFER、OPTIONS、NOTIFY、SUBSCRIBE、PRACK、MESSAGE、INFO Allow-Events: talk、hold、refer サポートされている機能: タイマー、100rel、置換、発信者ID セッション有効期限: 3600;リフレッシャー=uas 最小SE: 90 コンテンツタイプ: application/sdp コンテンツの長さ: 477 v=0 o=root 2071608643 2071608643 IN IP4 172.20.25.100 s=呼び出し c=IN IP4 172.20.25.100 t=0 0 m=オーディオ 57676 RTP/SAVP 0 8 9 2 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=暗号化:オプション a=sendrecv
電話機はプロキシから応答を受信し、これで双方向の安全な通話が可能になります。
SIP/2.0 200 OK 経由: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96 送信元: "123" < sips:123@ietf.org >;タグ=mogkxsrhm4 宛先: < sips:*97@ietf.org;user=phone >;tag=237592673 通話ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07 CSeq: 1 INVITE 連絡先: < sip:*97@203.43.12.32:5061;transport=tls > サポート対象: 100rel、置き換え対象 Allow-Events: 参照 許可: INVITE、ACK、CANCEL、BYE、REFER、OPTIONS、PRACK、INFO 承認: application/sdp ユーザーエージェント: pbxnsip-PBX/1.5.1 コンテンツタイプ: application/sdp コンテンツの長さ: 298 v=0 o=- 1996782469 1996782469 IP4 203.43.12.32 s=- c=IN IP4 203.43.12.32 t=0 0 m=オーディオ 57076 RTP/SAVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx a=ptime:20 a=sendrecv
セキュアメディアでよくある問題は、最初のメディアパケットが到着した時点で鍵交換が完了していない可能性があることです。最初のクリックノイズを回避するために、これらのパケットは破棄する必要があります。通常、これはごく短時間（100ミリ秒未満）なので、大きな問題にはなりません。
SDES方式は「エンドツーエンド」のメディア暗号化には対応していません。例えば、ユーザーAがプロキシPを介してユーザーBと通信する場合、SDESではAとP間、またはBとP間での鍵のネゴシエーションは可能ですが、AとB間では不可能です。エンドツーエンドのメディアセキュリティを実現するには、まず相手側との信頼関係を確立する必要があります。このために信頼できる中間者を使用すると、通話設定の遅延が大幅に増加し、プッシュトゥトークなどのアプリケーションが困難になります。ピアツーピアでこれを行う場合、相手側を特定するのが難しい場合があります。例えば、オペレーターがB2BUAアーキテクチャを実装して相手側の役割を担う場合、エンドツーエンドのセキュリティは確保されません。ZRTPなどの最新のプロトコルは、SIP/RTP通話のエンドツーエンド暗号化を提供します。