SIP (RFC 3261) におけるセキュリティ課題とその対策

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

SIP (RFC 3261) におけるセキュリティ課題とその対策

背景

Session Initiation Protocol (SIP) は、IPネットワーク上でマルチメディアセッション（音声通話、ビデオ会議、インスタントメッセージなど）を確立、変更、終了するためのシグナリングプロトコルです。その定義は主にRFC 3261「SIP: Session Initiation Protocol」で標準化されており、VoIP (Voice over IP) システムの基盤技術として広く利用されています。SIPはHTTPに似たテキストベースのプロトコルであり、その柔軟性と拡張性から多様な通信サービスに適用されてきましたが、同時にその性質に起因するセキュリティ課題も存在します。これらの課題は、ユーザーのプライバシー、システムの可用性、課金の正確性などに直接影響を与えるため、プロトコル実装において適切な対策を講じることが不可欠です。

設計目標

RFC 3261自体は、セッションの確立と管理に主眼を置いて設計されており、そのセキュリティモデルは後の拡張RFCによって補完されることを前提としていました。初期のSIPのセキュリティに関する設計目標は以下の通りです。

  1. 基本的な認証: HTTP Digest認証メカニズムを援用し、ユーザーの識別を可能にする。

  2. メッセージの完全性: メッセージの改ざんを検知する手段を提供（ただし、暗号化はスコープ外）。

  3. プライバシー: メディア自体ではなく、シグナリング情報のプライバシー保護の必要性を示唆。

  4. サービス可用性: DoS攻撃に対する耐性。

しかし、これらの目標は、今日の脅威環境においては不十分であり、より堅牢なセキュリティを実現するために、RFC 3329「Security Mechanisms for the Session Initiation Protocol (SIP)」やRFC 5630「Protecting the Session Initiation Protocol (SIP) via TLS over TCP and SCTP」などの拡張RFCが策定されてきました。

詳細

SIPメッセージ構造と脆弱性

SIPはテキストベースのプロトコルであり、URI、ヘッダー、メッセージボディで構成されます。以下に、SIP INVITEメソッドの主要なヘッダーの一部を例として示します。

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.org>;tag=1928301774
To: Bob <sip:bob@example.com>
Call-ID: a84b4c76e66710@pc33.example.org
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.org>
Content-Type: application/sdp
Content-Length: 142

(SDP body here)

この構造は、以下の基本的なセキュリティ課題を内在しています。

  • なりすまし（Spoofing）: FromヘッダーやContactヘッダーは容易に偽装できるため、未認証の状態では発信元の正当性を検証できません。

  • 盗聴（Eavesdropping）: UDPや非暗号化TCP上でSIPメッセージが平文で送られる場合、中間者によってシグナリング情報が容易に盗聴されます。メディア（RTP）も同様に保護されません。

  • メッセージ改ざん（Tampering）: ヘッダーやSDPボディの内容が通信経路上で改ざんされる可能性があります。これにより、セッションパラメータの変更、ルーティングの不正操作などが引き起こされかねません。

  • サービス妨害（DoS）: 大量のINVITEやREGISTERメッセージを送信することで、SIPサーバーのリソースを枯渇させ、サービスを停止させることが可能です。特に認証なしで実行可能な場合、このリスクは高まります。

SIPメッセージフローにおける潜在的な攻撃点

Mermaidのフローチャートを用いて、SIPの基本的なメッセージフローと潜在的な攻撃点を視覚化します。

flowchart TD
    A["ユーザーエージェント (UA-A)"] -->|1. INVITE("非暗号化")| B("プロキシサーバー/レジストラ")
    B -->|2. INVITE("非暗号化")| C["ユーザーエージェント (UA-B)"]
    C -->|3. 180 Ringing| B
    B -->|4. 180 Ringing| A
    C -->|5. 200 OK| B
    B -->|6. 200 OK| A
    A -->|7. ACK| B
    B -->|8. ACK| C
     subgraph 攻撃者による盗聴・改ざん
        subgraph 非保護経路
            1 --> M1("中間者攻撃")
            2 --> M2("中間者攻撃")
            3 --> M3("中間者攻撃")
            4 --> M4("中間者攻撃")
            5 --> M5("中間者攻撃")
            6 --> M6("中間者攻撃")
            7 --> M7("中間者攻撃")
            8 --> M8("中間者攻撃")
        end
        M1 --a-->|ヘッダー偽装/盗聴| B
        M2 --b-->|SDP改ざん/盗聴| C
        M3 --c-->|ルーティング変更| B
    end
    style M1 fill:#f9f,stroke:#333,stroke-width:2px
    style M2 fill:#f9f,stroke:#333,stroke-width:2px
    style M3 fill:#f9f,stroke:#333,stroke-width:2px
    style M4 fill:#f9f,stroke:#333,stroke-width:2px
    style M5 fill:#f9f,stroke:#333,stroke-width:2px
    style M6 fill:#f9f,stroke:#333,stroke-width:2px
    style M7 fill:#f9f,stroke:#333,stroke-width:2px
    style M8 fill:#f9f,stroke:#333,stroke-width:2px

このフローでは、SIPメッセージが平文で交換されるため、各ステップで中間者攻撃による盗聴や改ざんのリスクが存在します。

相互運用性

SIPのセキュリティ強化は、既存のセキュリティプロトコルとの連携によって実現されます。

  • TLS (Transport Layer Security): SIPシグナリングの暗号化と認証には、トランスポート層でTLS (RFC 5630で推奨) が利用されます。これにより、メッセージの盗聴と改ざんが防止され、サーバー証明書によって通信相手の認証も行われます。クライアント証明書を組み合わせることで、双方向認証も可能です。

  • SIPS URIスキーム: SIP over TLSを示す sips: URIスキームが定義されており、SIPメッセージが安全なトランスポートチャネルを介して送信されることを保証します。

  • SRTP (Secure Real-time Transport Protocol): SIPで確立されたメディアセッション（RTP）の暗号化と認証にはSRTP (RFC 3711) が用いられます。SIP/SDPで鍵交換情報が安全に伝達されることで、メディアストリームが保護されます。

  • S/MIME: SIPメッセージの特定のヘッダーやボディを暗号化・署名するためにS/MIME (RFC 3329) が利用されることもあります。これはメッセージ単位の保護を提供します。

既存プロトコルとの比較 (HTTP/S)

SIPとHTTPはテキストベースである点で共通しますが、セキュリティモデルには重要な違いがあります。

  • HTTP/S:

    • トランスポート層セキュリティ: ほとんどの場合、基盤となるTCP上でTLSを使用することで、通信全体を保護します (HTTPS)。

    • 認証: Basic認証、Digest認証、クライアント証明書、OAuthなど多様な認証メカニズムをサポートします。

    • セッション管理: Cookieやトークンを用いたステートフルなセッション管理が一般的です。

    • メディア: HTTP自体はリアルタイムメディア転送には不向きで、メディアは別のプロトコル（例: WebRTC）や専用のストリーミングプロトコルで扱われます。

  • SIP (RFC 3261):

    • トランスポート層セキュリティ: RFC 3261自体はTLSを必須とせず、UDPもサポートします。セキュリティは主に拡張機能（TLS、SIPS）に依存します。

    • 認証: RFC 3261ではHTTP Digest認証が基本です。より堅牢な認証は、S/MIME (RFC 3329) やTLSクライアント証明書に依存します。

    • セッション管理: Dialogという概念に基づき、複数のSIPメッセージで構成される対話の状態を管理します。

    • メディア: シグナリングとメディア転送が分離されており、メディア自体はRTPなどの別のプロトコルで処理されます。SIPのセキュリティ対策とRTPのセキュリティ対策（SRTP）は個別に講じる必要があります。

SIPはリアルタイム通信の特性上、シグナリングとメディアの両方でセキュリティを考慮する必要がある点が、一般的なHTTPベースのアプリケーションよりも複雑になります。

セキュリティ

SIP (RFC 3261) およびその拡張における主要なセキュリティ課題と対策を詳述します。

1. なりすましとメッセージの完全性

  • 課題: From、To、Call-IDなどのヘッダーは容易に偽装可能であり、メッセージが中間で改ざんされるリスクがあります。

  • 対策:

    • TLS (Transport Layer Security): SIPサーバーとクライアント間の通信をTLSで保護することで、発信元の認証（サーバー証明書）とメッセージの完全性を確保します (RFC 5630)。クライアント証明書による双方向認証は、より強力な相互認証を提供します。

    • HTTP Digest認証: RFC 3261で定義されている標準的な認証メカニズムですが、ユーザー名とパスワードのハッシュ値のみを交換するため、辞書攻撃やリプレイ攻撃に脆弱な場合があります。

    • S/MIME (Secure/Multipurpose Internet Mail Extensions): メッセージの特定の部分にデジタル署名を付与し、完全性と非否認性を提供します。また、メッセージの暗号化も可能です (RFC 3329)。

2. 盗聴（Eavesdropping）

  • 課題: UDPや非暗号化TCP上でSIPメッセージが平文で流れる場合、シグナリング情報（発着信者情報、IPアドレス、SDPメディア記述など）が盗聴されるリスクがあります。

  • 対策:

    • TLS: シグナリングチャネル全体を暗号化し、盗聴から保護します (RFC 5630)。

    • SRTP (Secure Real-time Transport Protocol): SIPで確立されたメディア（RTP）ストリームを暗号化および認証し、メディアの盗聴や改ざんを防ぎます (RFC 3711, RFC 4568)。

3. リプレイ攻撃（Replay Attacks）

  • 課題: 過去に傍受した有効なSIPメッセージ（例: REGISTER要求、INVITE要求）を再送信することで、不正な登録やセッション確立を試みる攻撃です。Digest認証はnonceを使用しますが、再利用されると脆弱になります。

  • 対策:

    • 強力なnonceの利用: Digest認証のnonceは予測不能で、一度しか使用できないものであるべきです。

    • TLS: TLS自身がリプレイ保護機構を持つため、TLSを使用することでトランスポート層でのリプレイ攻撃を防ぎます。

    • CSeqヘッダー: SIPのCSeqヘッダーはメッセージシーケンス番号を含みますが、これ単体ではリプレイ攻撃に対する十分な保護にはなりません。TLSなどのより強力なメカニズムと組み合わせる必要があります。

4. ダウングレード攻撃（Downgrade Attacks）

  • 課題: 攻撃者がクライアントとサーバー間の通信を傍受し、より弱いセキュリティプロトコルや暗号スイートへの切り替えを強制する攻撃です。例えば、TLSを無効化して平文通信を強制したり、弱い暗号スイートの使用を強制したりします。

  • 対策:

    • プロトコルと暗号スイートの強制: クライアントとサーバーは、セキュアなプロトコル（TLS 1.2以上）と強力な暗号スイートのみを受け入れるように設定されるべきです。古い、脆弱なオプションは無効化します。

    • HSTS for SIP (HSS): HTTP Strict Transport Security (HSTS) のようなメカニズムをSIP環境にも適用し、クライアントが常にSIPS（SIP over TLS）で接続することを強制する仕組みが有効です。

5. キー更新（Key Update）

  • 課題: 長期間同じ暗号鍵を使用し続けると、鍵が漏洩した場合のリスクが高まります。SIPにおけるSRTPの鍵交換は通常セッション確立時に行われますが、その後の定期的な鍵更新は必須ではありません。

  • 対策:

    • SRTPの鍵再生成: SRTPはRFC 3711で鍵再生成メカニズムをサポートしています。セッション中に定期的に新しい鍵に更新することで、耐タンパー性を向上させます。

    • TLSセッションの再ネゴシエーション: 基盤となるTLSセッション自体も、定期的に再ネゴシエーションを行い、セッション鍵を更新すべきです。

6. 0-RTTの再送リスク (TLS 1.3 利用時)

  • 課題: SIPは直接0-RTT (Zero Round Trip Time) をサポートするわけではありませんが、もしSIPがTLS 1.3を基盤として利用する場合、TLS 1.3の0-RTT機能はリプレイ攻撃のリスクを伴います。0-RTTは過去のセッション鍵を用いてアプリケーションデータを初回ハンドシェイクと同時に送信するため、そのデータがリプレイされる可能性があります。

  • 対策:

    • 冪等性の確保: 0-RTTで送信されるSIPメッセージは、プロキシサーバーや終端UAにおいて冪等性を持つべきです。つまり、複数回受信しても副作用がない操作（例: INFOメッセージ）に限定するか、リプレイ保護メカニズムをアプリケーション層で実装します。

    • 0-RTTデータの制限: SIP REGISTERやINVITEのような状態を変更する可能性のあるメッセージは、0-RTTデータとして送信しないことを強く推奨します。

セキュアなSIPハンドシェイク (TLS利用)

Mermaidのシーケンス図で、TLSを用いたSIPセッション確立の概略を示します。

sequenceDiagram
    participant UA_A as ユーザーエージェントA
    participant TLS as TLS層
    participant PS as プロキシサーバー
    participant UA_B as ユーザーエージェントB

    UA_A ->> TLS: SIP INVITE (sips:...)
    TLS ->> PS: TLSハンドシェイク (ClientHello)
    PS ->> TLS: TLSハンドシェイク (ServerHello, Certificate, ServerKeyExchange, ServerHelloDone)
    TLS ->> PS: TLSハンドシェイク (ClientKeyExchange, ChangeCipherSpec, Encrypted Handshake Message)
    PS ->> TLS: TLSハンドシェイク (ChangeCipherSpec, Encrypted Handshake Message)
    TLS -->> UA_A: TLS接続確立 (鍵交換完了)

    UA_A ->> PS: SIP INVITE (暗号化済み)
    PS ->> PS: ルーティング処理
    PS ->> UA_B: SIP INVITE (必要に応じてTLS再確立)
    UA_B ->> PS: 180 Ringing (暗号化済み)
    PS ->> UA_A: 180 Ringing (暗号化済み)
    UA_B ->> PS: 200 OK (暗号化済み)
    PS ->> UA_A: 200 OK (暗号化済み)
    UA_A ->> PS: ACK (暗号化済み)
    PS ->> UA_B: ACK (暗号化済み)
    UA_A UA_B: SRTPメディアセッション (暗号化済み)

この図では、SIPメッセージの交換前にTLSハンドシェイクが完了し、以降のSIPシグナリングが暗号化される様子を示しています。メディアストリームは別途SRTPで保護されます。

実装メモ

セキュアなSIPプロトコルを実装する際の注意点です。

  • MTU / Path MTU: TLSレコードサイズが大きすぎると、IP層でのフラグメンテーションが発生し、性能低下やパケットロスにつながることがあります。特にUDP上でDTLS (Datagram TLS) を利用する場合、Path MTU Discovery (PMTUD) を適切に行い、フラグメンテーションを避けるためのレコードサイズ調整が重要です。通常、1200バイトや1400バイト程度のレコードサイズを推奨します。

  • HOL blocking回避 (Head-of-Line blocking): TCP上でSIPを利用する場合、TLS層でのTLSレコードの処理遅延や、SIPメッセージのパース遅延が、TCPのパイプライン処理においてHOL blockingを引き起こす可能性があります。SCTP (Stream Control Transmission Protocol) や、メッセージングを考慮したアプリケーション層プロトコル設計が有効です。

  • キュー制御と優先度: SIPサーバーは大量の同時リクエストを処理するため、各リクエストキューを適切に管理し、優先度の高い（例: 応答時間が重要な）メッセージを優先的に処理するメカニズムが必要です。特に、DoS攻撃に対する耐性を高めるために、不正なトラフィックを早期に識別し、キューイングやレート制限を適用することが重要です。

  • 鍵管理と証明書検証: TLSを利用する上で、信頼できるCA (Certificate Authority) から発行された証明書の使用、証明書の有効期限チェック、OCSP (Online Certificate Status Protocol) や CRL (Certificate Revocation List) による失効状態の確認が必須です。内部的には、鍵ペアの安全な生成、保管、更新ポリシーを確立する必要があります。

  • セキュリティヘッダーの利用: P-Asserted-Identity (RFC 3325) や Privacy ヘッダー (RFC 3323) など、セキュリティやプライバシーに関連するSIPヘッダーを適切に利用することで、より詳細な制御と情報提供が可能になります。

まとめ

SIP (RFC 3261) はVoIPサービスの基盤となる重要なプロトコルですが、その基本設計は今日のセキュリティ脅威に対応するために不十分な点があります。なりすまし、盗聴、改ざん、リプレイ攻撃、DoS攻撃といった様々な課題に対し、TLSによるシグナリングチャネルの暗号化と認証 (RFC 5630)、SRTPによるメディアストリームの保護 (RFC 4568)、およびS/MIMEによるメッセージレベルの保護 (RFC 3329) といった拡張プロトコルを組み合わせることで、堅牢なセキュリティを確立できます。実装においては、MTUやHOL blockingへの配慮、適切なキュー制御、そして厳格な鍵管理と証明書検証が不可欠です。これらの対策を講じることで、SIPベースの通信システムの信頼性と安全性を高めることができます。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました