8. Security Considerations (セキュリティ考慮)

SIP でシグナリングされる DTLS/TLS メディアでは, 通信ピアの証明書が正しいことを保証する必要がある.

標準的な TLS/DTLS 認証はサーバ (と任意でクライアント) に PKIX [RFC5280] 証明書を与え, クライアントが検証し名前がドメインと一致するか確認する. VoIP ではサーバ名が明確で少数という前提が通常成り立たない.

本設計はシグナリングチャネルの真正性を利用し (機密性は必須としない). 双方が相手から受け取った SDP の整合性を検証できれば DTLS ハンドシェイクは MITM で乗っ取られない. 発信者から着信者へ (第 7 節の Alice から Bob) は SIP Identity [RFC4474] で容易に提供できる. RFC 3261 の S/MIME や将来の仕組みも同目的に使える.

そのような整合性機構なしでも使えるが, 中間者の受動攻撃への防御に限られる. シグナリングへの能動攻撃とメディア面への能動攻撃の組合せで接続を攻撃し得る ([RFC5479] の R-SIG-MEDIA).

8.1. Responder Identity

SIP Identity は応答への署名をサポートしない. 理想的には Alice は Bob の SDP が改ざんされていないことと送信者を知りたい. [RFC4916] はピア UA に身元を提示し認証サービスが署名する方法を定義する. 例: Bob は answer の直後に fingerprint を含む UPDATE を送り SIP Identity で [email protected] からであると主張する. 欠点は UPDATE の往復が増えること. すべてのプロキシが信頼できなくても単純で安全. offerer は SHOULD でこれを支持し, answerer は SHOULD で使う.

answerer が UPDATE を送らない場合や UPDATE 前にメディアが流れる場合, Bob から Alice への fingerprint に整合性がない. シグナリング上の攻撃者が fingerprint を改ざんしメディアで MITM になり得る. Alice は誰かと安全な通話をしているが Bob か MITM か分からない. Bob は攻撃を検知し得る. 一方が検知できるなら双方が暗号化を望む多くの場合は問題にならない. Bob は受信メディアを誰にでも漏らし得るという点に留意する. Bob も安全を望むと仮定する. 何もしない場合, Bob は第三者による改ざん・傍受がなく [email protected] からであることを知る. Alice は誰かと話しており相手がおそらく傍受・改ざんを検査したと知る. 理想的ではないが多くの状況で実用的.

8.2. SIPS

SIP Identity なしでシグナリングが SIPS なら保証は弱い. すべてのプロキシが信頼できる限り一部の安全は得られる. fingerprint の整合性は信頼の連鎖モデルで与えられる. プロキシが信頼できないなら限定的.

8.3. S/MIME

RFC 3261 [RFC3261] の S/MIME で fingerprint の出自 (Bob) に署名でき, それは安全である.

8.4. Continuity of Authentication

安全なメディアでは認証の連続性が望ましい: 以前と同じ相手と話していることを暗号的に保証する. DTLS では (少なくとも同一ピアに対し) 同一公開鍵/自己署名証明書を使うことで達成する. 資格 (またはハッシュ) をキャッシュし不変を検証できる. 一度安全接続が張れば将来シグナリングが不安全でも将来の安全チャネルを確立し得る.

連続性のため実装は長期鍵を可能な限り一定に SHOULD. 検証側はピア身元ごとに鍵をキャッシュし変化でユーザに警告 SHOULD.

8.5. Short Authentication String

Alice と Bob は音声で身元を確認し続けて fingerprint を音声で確認する代替がある. 声のなりすましと音声の無痕改変が難しいなら比較的安全. ビデオや IM には不向き. DTLS はこの運用を支持する. 安全な fingerprint の最小長は約 64 ビット.

ZRTP [AVT-ZRTP] は SAS モードを持ち接続毎のビット列を生成する. SAS は 25 ビットまで短く読みやすい. DTLS はネイティブに未対応. TLS 拡張 [RFC5246] で対応し得る. SAS は相互の声を識別できる場合に限り有効 (コールセンター等では不適).

8.6. Limits of Identity Assertions

RFC 4474 でメディア鍵を SIP に束縛する場合, メディアの出所と安全についての保証はシグナリングの保証を超えない. 重要な二点:

• RFC 4474 は証明書 "example.com" のプロキシが名前空間 example.com を支配すると仮定する. よって権威ある認証サービスは名前の割当を制御でき, かつて Alice のアドレスを Bob に移し得る. これは意図された設計である.

• 電話番号 URI 使用時, ドメインが番号に権威があるという構造的理由はない (個別の信頼関係はあり得る). PSTN 要素が番号を正しく主張すると信頼されるが番号空間の権威という概念は弱い.

いずれにせよ DTLS-SRTP のデータ起源整合性・機密性の保証は RFC 4474 使用時の SIP シグナリング整合性を超えない. 実装者は UI で誤解を招くピア身元表示を避ける. ピアが sip:[email protected] なら +17005551008 だけ表示するのは, chicago.example.com が E.164 を主張するのを信頼する方針がない限り不十分. E.164 と明らかなら「暗号化されているが相手不明」とする方が混乱が少ない.

さらに B2BUA や SBC が RFC 4474 署名計算に入る SIP 部分を改変し署名を壊すことが知られる. 中間者の改変は RFC 4474 が検出しようとするものである. 中間盒が同一管理域の認証サービスとして有効な署名を生成できるなら再署名し得る. そうでなければ受信者は Identity 断言を頼れず UA は主張された身元への安全呼をユーザに MUST NOT 示す. 安全呼のみに設定した実装は SHOULD で切断する.

SIP Identity または同等がなければシグナリングを能動的に変えられない攻撃者への防御に留まる. 以前の仕組みより良いがシグナリング整合性がある場合より劣る.

8.7. Third-Party Certificates

端点証明書が第三者検証可能であることに本仕様は依存しない. そのような証明書の使用は妨げられない. 取得の難しさに加え証明書に何の身元を入れるか不明確: RFC 3261 の S/MIME 慣例が流用し得るが展開は少ない. 閉じた文脈で慣例を定めれば第三者証明書はドメイン内プロキシへの依存を減らし得る.

8.8. Perfect Forward Secrecy

長期鍵の侵害が過去通信を侵害し得る懸念に対し, DTLS は DH/ECDHE スイートで完全前方秘匿 (PFS) を支持する. 使用時はその攻撃に耐える. 長期鍵侵害は将来の能動攻撃に繋がり得る. 懸念があれば手動 fingerprint 合意や SAS 等の予備認証チャネルを使う.