要約

  • RFC 5349 は、KDC が受理できない ECDH パラメータに対し、KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED と優先順の TD-DH-PARAMETERS を返す方式を定める。ただし、その Kerberos エラーには完全性保護がないため、一覧は候補情報であって権限ではない。
  • 証明書パス、CMS 署名、アルゴリズム制約、正しい曲線上の公開点は別々に検証する必要がある。構文的に読めることや証明書が有効なことから、点の数学的な有効性は導けない。
  • clientDHNonce と serverDHNonce による鍵再利用の許可、共有秘密の導出、チケット発行、アプリケーション権限も独立した境界である。長期鍵ほど、各入力に対する点検証の証拠が重要になる。

危険を決めるのは失敗一回ではなく反復可能性

無効な公開点を一度受け取ったという事実だけでは、被害の規模は決まらない。秘密鍵が同じまま何回使われるか、攻撃者が何回入力を送れるか、応答の差をどこまで観測できるかが組み合わさって危険を作る。

RFC 5349 は、長期 ECDH 秘密鍵を使う受信側が正しい曲線上の有効点を確認しなければ、鍵に関する情報を漏らし、反復によって全体を露出し得ると明示する。

したがって、単一セッションの成功記録では安全性を説明できない。過去の不正点が計算前に拒否されたか、同じ秘密値が何件の入力に触れたか、鍵の存続期間がどれほどだったかを結び付ける必要がある。

レート制限は試行を遅らせても、点を有効にはしない。短い鍵寿命は累積を減らしても、検証を不要にはしない。一次防御は秘密鍵演算の前にある。

証明書検証の緑色は数学検証の緑色ではない

ECC 証明書は PKINIT と CMS の既存構造に収まる。X.509 パス検証は発行者、信頼アンカー、名前、用途、制約、有効期間、署名などを扱う。

一方、ECDH が消費する公開点には別の問いがある。その点は期待した曲線に属するか。必要な条件を満たすか。秘密鍵との計算に渡してよいか。

署名済みコンテナ内のビット列だからといって、すべての数学的入力が安全になるわけではない。「証明書有効」という一つのフラグに統合すれば、点検証が実行されたのかを後から確認できない。

監査記録では、エンコード解析、証明書パス、署名、アルゴリズム方針、点検証を分離すべきである。失敗理由も、秘密鍵演算に到達したかどうかも残す。

KDC の一覧はローカル方針に入る入力である

クライアントが提示した ECDH パラメータを KDC が拒否すると、KDC は代替候補を自身の優先順で返せる。クライアントはそこから選び、再送できる。

しかし、このエラーは完全性で保護されない。攻撃者は候補の削除、追加、並べ替えを試みられる。受信した先頭項目をそのまま採用すれば、未認証メッセージに暗号方針の更新権を与えることになる。

正しい境界は積集合である。ローカル方針が先に許容集合を定め、受信一覧はその集合を狭める材料にしかならない。積集合が空なら、失敗が方針の実行結果である。

KDC 側も、ライブラリが実装する曲線と運用上許可する曲線を分ける必要がある。能力は権限の証明ではない。

再試行成功は一覧の出所を証明しない

攻撃者が最も優先された共通曲線だけを消し、クライアントの方針内にある次点を残したとする。クライアントは再試行し、PKINIT は成功できる。

最終交換が正しくても、最初の一覧が KDC の原文だったとは言えない。ローカル方針は危険な値を防いだかもしれないが、優先順位の真正性までは回復しない。

監査には二つの判定が要る。最終値は許可され、正しく実行されたか。交渉経路は KDC の実際の選好を表していたか。前者が合格でも後者は不明であり得る。

保存すべきなのは最終曲線だけではない。初期提案、拒否コード、受信順序、当時の方針、積集合、選択結果、再試行結果を一連の証拠として残す。

並び順を集合に潰してはいけない

TD-DH-PARAMETERS の順序には意味がある。同じ曲線を含む二つの一覧でも、順序が違えば選択が変わる。

生の受信一覧と方針で絞った一覧は別々に保存する。後者で前者を上書きすると、何が制御面に影響を与えようとしたかを失う。

方針は後から改定されるため、現在の設定だけで過去の判断を再現できない。当時の版または内容ハッシュを選択記録に結び付ける。

この設計により、「安全な積集合には残ったが選好が変えられた」事象と、「許容範囲外の値が実行された」事象を区別できる。

nonce は再利用の許可条件を保存する

RFC 4556 の clientDHNonce と serverDHNonce は、クライアントと KDC が鍵再利用を認めるための文脈を担い、RFC 5349 もその枠組みを ECDH に適用する。

これは実装が都合よく長期再利用してよいという包括許可ではない。どちらが何を提示し、どの鍵対をどれだけ再利用したかが重要である。

再利用は計算量や待ち時間を減らせる。同時に、一つの秘密値へ届く外部入力を増やす。点検証の欠落が一回限りの不具合ではなく、反復可能な面になる。

台帳には nonce、方針決定、鍵識別子、生成時刻、曲線、利用回数、点検証結果、拒否、破棄を結び付ける。「ECDH 完了」という結果だけでは許可経路を示せない。

小さい鍵から運用コストは読めない

RFC 5349 は、当時一般的だった RSA や DSA に比べ、小さい鍵で同程度の安全強度を得られることを ECC の利点として説明する。引用された歴史的指針に基づく近似表も含む。

その表は設計時の判断材料であり、現在の総所有コスト表ではない。証明書運用、ハードウェア対応、サイドチャネル、実装品質、方針追加、交渉試験、移行時間は鍵長だけでは測れない。

短いエンコードが帯域や保存量を減らす一方、新しいパーサー、アルゴリズム識別子、曲線設定、障害経路を追加する場合がある。実環境の測定が必要である。

現在の採用判断には現在の標準と脅威評価を使うべきで、2008 年の強度対応だけを購買根拠にしてはならない。

必須実装は実行証拠ではない

RFC 5349 は適合実装に P-256 と P-384 のサポートを求める。これは相互運用性の最低線を作る。

特定環境で有効化されていること、クライアントが提案したこと、方針が許可したこと、KDC が返したこと、再試行で選ばれたこと、点検証を通ったこと、実際に計算されたことは別である。

歴史的文書における ecdsa-with-Sha256 の必須サポートも同じで、個別証明書や署名の利用実績にはならない。

資産表は、実装済み、設定済み、提示、受信、許可、選択、検証、実行の状態を分離する。仕様のチェック欄だけでは運用面は見えない。

標準曲線は摩擦と集中を同時に生む

名前付き曲線はオブジェクト識別子でパラメータを共有し、エンコードと相互理解を簡潔にする。RFC 4556 の構造は明示パラメータも扱える。

一つの曲線が広く使われれば、テスト、証明書、ハードウェアは揃いやすい。同時に、将来の曲線上の攻撃や共通実装の欠陥が多数の鍵へ波及しやすい。

曲線を増やせば自動的に安全になるわけでもない。コード経路、設定、交渉、ダウングレード面が増える。集中リスクと複雑性リスクを実測で比較する必要がある。

鍵数、実装の多様性、検証カバレッジ、ハードウェア依存、置換所要時間、実際の選択頻度が判断材料になる。

証明書パラメータは管理場所を変える

ECC 証明書のドメインパラメータを ECDH に使えば、別途の事前設定を減らせる。設定ファイルが一つ減ることは運用上の利点である。

ただし権限は消えず、証明書発行、パス検証、アルゴリズム制約、鍵解析、ローカル受理方針へ移る。証明書内にあるだけで、あらゆる用途に自動許可されるわけではない。

パラメータの出所を、明示的なローカル設定、現在の証明書、KDC エラー一覧、その他の仕組みに分けて記録する。出所を失えば、管理場所の移動を統制の削減と誤認する。

重要なのは「設定が減ったか」ではなく、「誰が値を変えられ、その変更はどの証拠を残すか」である。

共有秘密から業務実行までには段差がある

受理済みの ECDH 交換では、双方が楕円曲線点を計算し、その x 座標をオクテット列にして RFC 4556 の DHSharedSecret とする。これは次段階の入力を生成した証拠である。

組織的な相手同定、Kerberos チケット発行、サービスチケット取得、アプリケーション認可、業務動作完了は証明しない。各段階は前段が成功しても拒否できる。

RFC 5349 は 2008 年 9 月公開の Informational 文書であり、RFC 4556 メッセージの構文や意味を変えない。取得時の RFC Editor errata 検索には対象記録が表示されなかったが、実装の無欠陥を意味しない。

暗号合意を業務権限へ昇格させず、証明書、公開点、方針積集合、共有秘密、チケット、業務結果を別々の受領証として扱うべきである。