メインコンテンツまでスキップ

付録F. セキュリティ分析 (Security Analysis)

本付録では、TLS 1.2プロトコルのセキュリティ分析を提供します。

F.1. ハンドシェイクプロトコル (Handshake Protocol)​

F.1.1. 認証と鍵交換 (Authentication and Key Exchange)​

TLSハンドシェイクプロトコルの核心的なセキュリティ目標は:

  1. 認証: 通信ピアの身元を確認する
  2. 鍵協定: 安全に共有秘密を確立する
  3. 完全性: ハンドシェイクメッセージが改ざんされていないことを確認する

F.1.1.1. 匿名鍵交換 (Anonymous Key Exchange)​

匿名鍵交換は推奨されません!

匿名Diffie-Hellman (DH_anon) 暗号スイートは認証を提供しません:

  • 中間者攻撃に対して脆弱
  • 特定の管理された環境でのみ使用
  • 本番環境では使用を避けるべき

セキュリティリスク:

クライアント <---> 攻撃者 <---> サーバー
         |         |
         2つの独立したDH交換
         クライアントはサーバーと通信していると思っている
         サーバーはクライアントと通信していると思っている
         実際には両方とも攻撃者と通信している

F.1.1.2. RSA鍵交換と認証 (RSA Key Exchange and Authentication)​

RSA鍵交換は以下を提供します:

  • サーバー認証 (証明書経由)
  • オプションのクライアント認証
  • プレマスターシークレットの機密送信

セキュリティ特性:

  • 信頼されたCAによって署名されたサーバー証明書
  • クライアントが証明書チェーンを検証
  • プレマスターシークレットはサーバー公開鍵で暗号化
  • サーバー秘密鍵の保持者のみが復号可能

制限事項:

  • 前方秘匿性を提供しない
  • サーバー秘密鍵が漏洩した場合、過去のセッションが復号される可能性がある

F.1.1.3. 認証付きDiffie-Hellman鍵交換 (Diffie-Hellman Key Exchange with Authentication)​

DHE (一時的Diffie-Hellman) は以下を提供します:

  • サーバー認証
  • 前方秘匿性
  • より強力なセキュリティ保証

セキュリティ上の利点:

  1. 前方秘匿性:

    • 各セッションで新しい一時鍵ペアを使用
    • 長期鍵が漏洩しても、過去のセッションは安全なまま

  2. 認証:

    • DHパラメータはサーバー秘密鍵で署名
    • クライアントが署名を検証

推奨: DHEおよびECDHE (楕円曲線DHE) 暗号スイートは、現代のTLS展開における推奨選択です。

F.1.2. バージョンロールバック攻撃 (Version Rollback Attacks)​

TLSは、バージョンロールバックを防ぐために複数の防御層を使用します:

  1. ClientHelloとServerHelloのバージョン:

    • 交渉されたバージョンを明示的に示す
    • Finishedメッセージにこれらの値のハッシュを含む

  2. Finishedメッセージ:

    • すべてのハンドシェイクメッセージのMACを含む
    • 変更があると検証が失敗する

  3. TLS_FALLBACK_SCSV (RFC 7507):

    • 追加のシグナリングメカニズム
    • ダウングレード攻撃を防ぐ

F.1.3. ハンドシェイクプロトコルに対する攻撃の検出 (Detecting Attacks Against the Handshake Protocol)​

TLSは攻撃を検出するために以下のメカニズムを提供します:

  1. メッセージ完全性:

    • Finishedメッセージがハンドシェイク全体を検証
    • PRFが暗号学的強度を保証

  2. 証明書検証:

    • 完全な証明書チェーン検証
    • ホスト名チェック
    • 失効チェック

  3. タイミング攻撃保護:

    • 定数時間操作
    • 統一されたエラー処理

F.1.4. セッション再開 (Resuming Sessions)​

セッション再開のセキュリティ考慮事項:

セキュリティ特性:

  • マスターシークレットを再利用
  • 計算オーバーヘッドを削減
  • 新しい乱数が鍵の一意性を保証

潜在的リスク:

  • セッションチケットの安全な保管
  • チケット暗号化鍵の保護
  • 適切なタイムアウト設定

推奨事項:

  • セッション有効期間を制限
  • チケット暗号化鍵を定期的にローテーション
  • セッション失効メカニズムを実装

F.2. アプリケーションデータの保護 (Protecting Application Data)​

F.2.1. データ機密性​

TLSは以下を提供します:

  • 強力な暗号化アルゴリズム (AESなど)
  • レコードごとの一意の鍵マテリアル
  • 完全性保護 (MACまたはAEAD)

F.2.2. データ完全性​

各TLSレコードは以下を含みます:

  • MAC (従来の暗号スイート用)
  • 認証タグ (AEAD暗号スイート用)
  • シーケンス番号 (リプレイ防止)

F.3. 明示的IV (Explicit IVs)​

TLS 1.2は、TLS 1.0のBEAST攻撃に対処するために明示的IVを使用します:

TLS 1.0の問題:

  • 前の暗号文ブロックを次のレコードのIVとして使用
  • 予測可能なIVが選択平文攻撃を許す

TLS 1.2の解決策:

  • 各レコードにランダム生成された明示的IVを含む
  • IVは予測不可能
  • BEAST攻撃を緩和

F.4. 複合暗号モードのセキュリティ (Security of Composite Cipher Modes)​

F.4.1. CBCモード​

既知の問題:

  • パディングオラクル攻撃
  • Lucky 13タイミング攻撃
  • BEAST攻撃 (TLS 1.0)

緩和策:

  • TLS 1.2は明示的IVを使用
  • 定数時間パディング検証
  • 統一されたエラーメッセージ

F.4.2. AEADモード​

利点:

  • 機密性と認証を同時に提供
  • パディングオラクル攻撃の影響を受けない
  • より単純な実装
  • より良いパフォーマンス

推奨: 現代の展開では、AEAD暗号スイート (GCM、CCM、ChaCha20-Poly1305) を優先すべきです。

F.5. サービス拒否 (Denial of Service)​

TLSハンドシェイクは比較的高価であり、DoS攻撃に使用される可能性があります。

F.5.1. 攻撃ベクトル​

  • 大量のハンドシェイクリクエスト
  • リソース枯渇 (CPU、メモリ)
  • 証明書検証オーバーヘッド

F.5.2. 緩和戦略​

サーバー側:

  • レート制限
  • クライアントパズル
  • セッション再開優先
  • リソース制限

ネットワーク層:

  • SYN cookies
  • 接続制限
  • ファイアウォールルール

F.6. 最終注記 (Final Notes)​

F.6.1. 既知の制限​

TLS 1.2は以下を防ぐことができません:

  • エンドポイントの侵害
  • 証明機関の侵害
  • 弱いパスワード選択
  • ソーシャルエンジニアリング攻撃

F.6.2. ベストプラクティス​

  1. 最新状態を維持:

    • セキュリティアナウンスを監視
    • 実装を速やかに更新
    • 弱いアルゴリズムを無効化

  2. 設定管理:

    • 強力な暗号スイートを使用
    • すべてのセキュリティ機能を有効化
    • 定期的に設定を監査

  3. 監視と対応:

    • セキュリティイベントを記録
    • 異常なパターンを監視
    • インシデント対応計画を準備

F.6.3. TLS 1.3への移行​

TLS 1.3 (RFC 8446) は以下を提供します:

  • より合理化されたハンドシェイク
  • より強力なセキュリティ保証
  • 弱いアルゴリズムの削除
  • 改善されたパフォーマンス

推奨: 新しい展開では、TLS 1.2との後方互換性を維持しながら、TLS 1.3の使用を検討すべきです。

注記: 完全なセキュリティ分析と詳細な議論については、RFC 5246付録Fの完全なテキストを参照してください。また、最新のセキュリティ考慮事項については、RFC 7457 (TLSおよびDTLSに対する既知の攻撃を要約) も参照してください。

に最終更新