安全なプロトコル設計の原則

セキュアプロトコルの設計では、ネットワークを完全に制御する攻撃者を想定します。Dolev-Yaoモデル（1983年）では、攻撃者に次の能力があると定めます。通信中の任意のメッセージを傍受、読み取り、遅延、リプレイ、削除、変更できる。正当な参加者が生成したものと区別できないメッセージを生成できる。既知のメッセージ構成要素から新しいメッセージを組み立てられる。一方で、暗号プリミティブを破ること（鍵なしで復号することや署名を偽造すること）はできません。重要なのは、攻撃者は計算量的に制限され、多項式時間で動作する一方、すべての通信チャネルを制御するという点です。プロトコルの安全性とは、基盤となるプリミティブの計算量的困難性だけを根拠として、この強力な攻撃者に対しても認証と秘匿性の目標を達成することです。

AbadiとNeedham（1994年）は、実践的なプロトコル設計の教訓を一連の原則にまとめました。(1) すべてのメッセージは、その意味を示す必要があります。メッセージの解釈はコンテキストに依存せず、自己完結していなければなりません。(2) プリンシパルがアクションを実行するための条件は、プロトコル内で明示する必要があります。(3) プリンシパルの身元が重要である場合は、メッセージ内に明示する必要があります。(4) 暗号化を使う理由を明確にします。暗号化は機密性を、署名は認証を提供するため、署名の代わりに暗号化を使ってはいけません。(5) メッセージは、その秘匿性が必要となるプロトコル層で暗号化する必要があります。これらの原則により、NS型の欠陥の多くが防止されました。

リプレイ攻撃は、プロトコルで最も一般的な脆弱性の一つです。新鮮性の仕組みにより、受信したメッセージが古いセッションからリプレイされたものではなく、最近生成されたものだと保証します。アプローチは2つあります。(1) ノンス（Number used ONCE：一度だけ使う値）—受信者がランダムな値を送信し、応答にその値が返されることを期待するチャレンジレスポンスです。応答にはノンスを暗号化または署名したものを含める必要があり、古い記録だけではチャレンジを満たせないようにします。(2) タイムスタンプ—両者が現在時刻を含め、古いタイムスタンプを持つメッセージを拒否します。タイムスタンプには時刻の同期が必要です（Kerberosでは5分のずれが許容されます）。時刻の同期が利用できない場合はノンスが好まれ、タイムスタンプはステートレスな検証を簡略化します。

同じ暗号鍵を複数の目的に使うと、危険な相互作用が生じます。鍵Kを暗号化と認証の両方に使うと、攻撃者が細工した暗号文を認証機構に入力し、情報を引き出せる可能性があります。TLS 1.3は、派生する鍵ごとに異なるラベルを使うHKDF-Expand-Labelによって、この問題を厳密に回避します。「c hs traffic」（クライアントハンドシェイク）、「s hs traffic」（サーバーハンドシェイク）、「c ap traffic」（クライアントアプリケーション）などです。ハンドシェイク鍵が漏えいしても、別のHKDF分岐から派生したアプリケーション鍵は安全なままです。プロトコル設計では、すべての鍵について多目的利用のリスクを監査し、目的ごとに別の鍵を導出する必要があります。

認証資格情報は、それが使用される特定のセッションにバインドする必要があります。バインドしない場合、あるセッションで取得された資格情報を別のセッションにリプレイできます。手法：(1) セッション識別子を署名またはMACで保護したデータに含めます。(2) 署名にDHトランスクリプトを含めます（STSアプローチ）。(3) HKDFから導出したセッション鍵を使用して、アイデンティティに対するMACを生成します（SIGMAアプローチ）。TLS 1.3のFinishedメッセージ：MAC(server_finished_key, transcript_hash) — このMACは完全なトランスクリプトを対象とするため、別のセッションのFinishedをリプレイすると失敗します。このバインディングによって、初期のKerberosやNS系プロトコルで見られたセッション間攻撃を防止できます。

プロトコルは、その機能に必要な最小限の情報だけを開示すべきです。アイデンティティは、それを必要とする相手にだけ明らかにします。必要でない限り、証明書のシリアル番号や、セッションとアイデンティティの関連付けを可能にする識別子を含めてはいけません。TLS 1.3ではサーバー証明書を暗号化します（証明書が平文だったTLS 1.2とは異なります）。これにより、受動的な盗聴者が得られる情報を減らせます。ESNI（Encrypted SNI、現在はECH — Encrypted Client Hello）はサーバー名指示を暗号化し、クライアントがどのサーバーに接続しているかを隠します。最小限の情報開示はトークン設計の原則でもあります。JWT claimsには認可に必要な情報だけを含め、完全なアイデンティティレコードを含めるべきではありません。

バージョンネゴシエーションは、一般的な攻撃対象領域です。攻撃者はClientHelloを削除または変更して、双方に古くて弱いプロトコルバージョンを使用させます。防御策：(1) 認証済みバージョンネゴシエーション — ネゴシエーションされたバージョンを署名対象のトランスクリプトに含めます（TLS Finishedはバージョンを含むClientHelloを対象とします）。(2) ダウングレードセンチネル — TLS 1.3では、TLS 1.2へダウングレードするときにServerHello.Randomへマジックバイトを設定し、クライアントがダウングレードを検出できるようにします。(3) バージョン非互換の防止 — サーバーは形式が不正なClientHelloを、何も通知せずにフォールバックするのではなく、拒否する必要があります。(4) SCSV — TLS_FALLBACK_SCSVは、クライアントが低いバージョンで再試行していることをサーバーに通知し、サーバーが不正なフォールバックを拒否できるようにします。

プロトコルメッセージには、最初の交換時点からコミットする必要があります。非可鍛性とは、攻撃者が暗号文や署名を変更し、それを別のコンテキストで検証に成功させることができない性質です。AEADは暗号文の非可鍛性を提供します。どのような変更でも認証タグが無効になります。プロトコルレベルの非可鍛性については、トランスクリプトのハッシュ化により、ハンドシェイクの最後に行われるFinishedの交換が、送信されたすべてのメッセージにコミットすることを保証します。これにより、カットアンドペースト攻撃を防止できます。異なる2つのセッションからメッセージをつなぎ合わせても、どちらのセッションに対しても有効なFinished値を生成することはできません。コミットメントスキーム（ハッシュコミットメント）を使うと、明らかにする前に事前コミットメントが必要なプロトコルフローにもこの考え方を拡張できます。

複雑なプロトコルでは、ステートマシンの境界で問題が起こることがよくあります。状態遷移が曖昧だと、たとえばメッセージ2より先にメッセージ3が届いた場合や、予期しないメッセージタイプが届いた場合にどう処理するかが実装ごとに異なり、攻撃者に悪用される不整合が生じる可能性があります。プロトコル仕様では、完全なステートマシン（すべての状態と有効な遷移）、予期しない入力への動作（特定のエラーで拒否するか、何もせず無視するか）、タイムアウトと再送回数の上限、セッションのクリーンアップを定義する必要があります。SSL/TLSでは、歴史的にステートマシンの実装が分岐していました。CVE-2014-0160（Heartbleed）は本質的にステートマシンの障害であり、メモリの境界が適切に制限されていない状態でheartbeatリクエストが処理されました。

暗号プロトコルが単独で使われることはほとんどありません。AKEプロトコルがセッション鍵を確立し、その鍵がアプリケーション層プロトコルで使用されます。AKEとアプリケーションプロトコルを合成可能性を考慮せずに独立して設計すると、相互作用によってセキュリティが損なわれる可能性があります。Universal Composability（UC）フレームワーク（Canetti、2001）は、プロトコルの合成に関する厳密なモデルを提供します。プロトコルがUC-secureであるとは、他のUC-secureなプロトコルと任意に合成しても安全性を維持できることを意味します。TLS 1.3、Signal、Noiseは、合成可能なセキュリティを目指しています。実際には、チャネルバインディング（トランスクリプトハッシュをエクスポートする）を使用して、AKEセッションを後続のアプリケーション認証に結び付けます。これにより、同じAKEプロトコルで確立されたセッション間で認証情報が転送されるのを防止できます。

プロトコル設計者は、同じ種類の間違いを繰り返し犯します。(1) 独自暗号の自作：十分なレビューを受けずに、独自のブロック暗号、MAC、鍵導出を実装すること。(2) 暗黙の信頼：暗号学的な証明ではなく、ネットワークコンテキストに基づいてメッセージの送信元を信頼すること。(3) セキュリティのオプション化：暗号化や認証を設定可能にし、必然的にダウングレードを招くこと。(4) 失効機能のない長期間有効なトークン：有効期間が長く、失効メカニズムのないJWTやセッション鍵を発行すること。(5) エラーチャネルの無視：エラーメッセージを認証しないことで、攻撃者がエラーを注入してプロトコルの動作に影響を与えられること。(6) 認証に暗号化を使用すること：MACや署名がなければ、データを暗号化しても送信元は認証されないこと。

セキュアなプロトコル設計では、確立された原則を適用します。Dolev-Yao攻撃者モデル（ネットワークを制御する攻撃者）、Abadi-Needham原則（明示的なアイデンティティ、自己完結型メッセージ）、nonceまたはタイムスタンプによる鮮度、異なるラベルを使用するHKDFによる鍵分離、認証資格情報のセッションへのバインディング、最小限の情報開示、トランスクリプト認証によるダウングレード防止、AEADとトランスクリプトのハッシュ化による非可鍛性、エラー処理を定義した明確なステートマシン、UCモデルのセキュリティ証明による合成可能性です。これらの原則に違反することが、既知のプロトコルレベルの暗号脆弱性のほぼすべての原因となっています。