プロンプトとコンテキスト
ある企業には、依然として RSA や楕円曲線暗号を使用しているモバイル、Web、デバイス、およびサードパーティ API のクライアントが存在します。ポスト量子暗号への移行計画を設計し、互換性、パフォーマンス、鍵のローテーション、およびロールバックについて説明してください。
NIST は ML-KEM、ML-DSA、および SLH-DSA に関する FIPS 203、204、205 を公開しました。この面接は単なる名称当ての演習ではありません。長期的な機密性、クライアントのライフサイクル、および運用リスクを段階的な意思決定に落とし込めるかどうかを試しています。IETF のハイブリッド TLS ドラフトはまだドラフト段階であり、普遍的な互換性を保証するものではありません。
面接官が見ているポイント
面接官は、実際の暗号資産の棚卸し、鍵確立と署名の区別、「今収集し、後で解読する（harvest-now-decrypt-later）」リスクの説明、暗号アジリティ（crypto agility）の設計、そして互換性、失敗率、パフォーマンスに関する測定可能なゲート（判断基準）を提示できるかを見ています。また、セキュリティ、コンプライアンス、ベンダー、およびプロダクトのレビューが必要な決定事項を特定することも求められます。
最初に明確にすべき質問
- どのデータを10年以上機密として保持する必要があり、どの署名に長期的な検証が必要か？
- クライアントのバージョン、ファームウェアのアップグレードパス、オフライン期間、およびサードパーティへの依存関係はどのように分布しているか？
- RSA、ECDH、ECDSA の呼び出し箇所、証明書チェーン、HSM、およびバックアップはどこにあるか？
- トランスポート、保存データ（data-at-rest）、コード署名、およびトークン署名の鍵は別々のライフサイクルを持っているか？
- ハンドシェイクのレイテンシ、メッセージサイズ、CPU、メモリ、および失敗率の許容バジェットはどれくらいか？
- 古いアルゴリズムは限定された期間内であれば維持できるか、またダウングレードや緊急ロールバックは誰が承認するのか？
30秒での回答
「まず暗号資産と機密保持期間を棚卸しし、露出度、置き換えの難易度、クライアントの更新可能性に基づいて優先順位を付けます。鍵確立と署名を分離し、古典暗号、ポスト量子暗号、またはハイブリッドモードに対応する機能検出（capability detection）を備えたバージョン管理されたアルゴリズムスイートを使用します。サイレントなダウングレードは許可しません。制御可能なサービスや新しいクライアントに対してカナリアリリースを実施しながら、ハンドシェイクの成功率、レスポンスサイズ、CPU、フォールバック、および鍵ローテーションのメトリクスを測定します。互換性、パフォーマンス、監査、ロールバックの各ゲートを通過した後にのみ対象を拡大し、古い形式の新しい認証情報は発行せずに、古い検証用鍵を保持します。」
ステップバイステップの詳細な回答
ステップ 1：アルゴリズムとデータのライフタイムの棚卸し
TLS、VPN、サービス間 RPC、データベース暗号化、バックアップ、署名、証明書、ファームウェア、およびベンダー SDK の呼び出し箇所をスキャンします。各資産について、アルゴリズム、鍵長、用途、オーナー、ローテーション方法、クライアントのバージョン、および機密保持期間を記録します。現在収集される可能性があり長期的な機密性が必要なトラフィックを優先し、次に長年にわたり検証が必要な署名を優先します。
ステップ 2：リスク階層とターゲットベースラインの策定
資産の重要度、攻撃の実現可能性、移行期間、更新不可能なクライアントの割合、および置き換えコストをスコアリングします。ベースラインには、どの新しい接続にポスト量子またはハイブリッドの保護が必要か、どの古い接続が承認された短期間の監視付き互換性ウィンドウでのみ継続できるかを明記する必要があります。実用的な量子コンピュータの登場時期だけを唯一の決定変数にしてはなりません。
ステップ 3：暗号を交換可能な機能にする
バージョン管理されたアルゴリズムスイート、鍵タイプ、および証明書ポリシーを通じて、ビジネスロジックを暗号ライブラリから独立させます。サーバーは機能宣言を評価できますが、クライアントが脆弱なアルゴリズムを選択してはなりません。ポリシーサービスは、スイートの一時停止、プロバイダーの切り替え、およびスコープの記録を行える必要があります。暗号文と署名のメタデータにはバージョンを含め、過去のフォーマットを識別できるようにします。
ステップ 4：鍵確立と署名のパスの選択
ML-KEM は鍵カプセル化用であり、ML-DSA と SLH-DSA は署名標準です。これらは鍵、証明書、パフォーマンスが異なります。TLS については、実装状況、ドラフトのステータス、ゲートウェイおよびエンドポイントのサポートを確認した上で、古典暗号と ML-KEM のハイブリッドハンドシェイクを評価します。署名については、証明書チェーンのサイズ、検証コスト、およびアーカイブ要件を個別に検証します。
ステップ 5：互換性とロールバックの境界の定義
新しいクライアントには機能検出を通じてスイートを選択させ、古いクライアントは明示的な互換性プールに配置します。ダウングレードは観測可能で、時間制限があり、テナントまたはデバイスごとに承認される必要があります。ハンドシェイクの失敗が無制限のフォールバックを引き起こしてはなりません。ロールバックは、検証にまだ必要な古い公開鍵を削除することなく、新しいトラフィックのエントリポイントを取り下げるようにします。理由、スコープ、および再有効化の基準を記録します。
ステップ 6：カナリア実験によるコストの測定
内部サービス、更新可能なモバイルクライアント、およびリスクの低いテナントで、接続成功率、ハンドシェイクのレイテンシ、メッセージサイズ、CPU、メモリ、帯域幅、証明書のキャッシング、および HSM のスループットをテストします。トラフィックのピーク、脆弱なネットワーク、オフラインからの復帰、複数リージョンでの負荷テストを実施します。ポスト量子のオーバーヘッドをビジネスの SLO と比較し、セキュリティポリシーをグローバルに無効化するのではなく、バージョンやクライアントタイプごとに対応します。
ステップ 7：鍵、ベンダー、監査の調整
新しい鍵と古い鍵について、生成、保管、ローテーション、失効、バックアップ、破棄の各期間を定義します。HSM、クラウド KMS、認証局（CA）、プロキシ、およびサードパーティ SDK におけるターゲットフォーマットのサポートを確認し、スイートの変更を監査イベントとして記録します。セキュリティがポリシーを所有し、プラットフォームが実装を担当し、法務またはコンプライアンスが適用される保持要件と証拠要件を確認します。
ステップ 8：リリースのゲートと長期的な終了戦略の設定
リリースゲートには、互換性の成功、パフォーマンスバジェット、古いアルゴリズムのトラフィック割合、異常なフォールバック、ローテーションの成功、および監査の完全性を含める必要があります。すべてのステージに停止基準（ストップライン）とオーナーを設けます。古いフォーマットのトラフィックが閾値を下回ったら、古い認証情報の新規発行を停止し、一定の検証期間の後に受け入れを失効させます。次のアルゴリズム置き換えを根拠を持って開始できるよう、移行記録を保持します。
トレードオフと境界
ハイブリッドモード対純粋なポスト量子モード
ハイブリッドモードは1つの新しいアルゴリズムへの依存を減らしますが、ハンドシェイクサイズ、実装の複雑さ、およびネゴシエーションテストを増加させます。純粋なポスト量子モードはターゲットをより直接的に表現しますが、アップグレードできないクライアントを排除する可能性があります。互換性マトリックスとリスクゲートに基づいて決定します。
セキュリティ強度対パフォーマンスバジェット
鍵、暗号文、または署名が大きくなると、MTU、ハンドシェイク、キャッシュ、および HSM のスループットに影響します。実際のトラフィックを測定し、モバイルネットワーク、デバイスの CPU、およびピーク時の同時実行性のためのマージンを確保します。サイレントなダウングレードによってパフォーマンスのチューニングを達成してはなりません。
ロールバック対古い鍵の保持
ロールバックのエントリポイントの切り替えと鍵の破棄は別個の決定です。過去の署名のために古い公開鍵がまだ必要な場合があるため、ロールバックによって即座にそれらを削除してはなりません。新規発行を停止し、新しい接続を制限し、読み取り専用の検証を維持し、十分な証拠が揃った場合にのみ破棄します。
障害訓練と進化計画
古いデバイスがアップグレードできない場合
デバイスバージョンのインベントリ、隔離されたゲートウェイ、および明示的な有効期限を設定します。隔離によって脆弱なスイートが新しいクライアントに波及しないことを検証し、所有者にアップグレードまたは交換のパスを提供します。
大きくなったハンドシェイクにより接続が切断される場合
実際のプロキシ、ロードバランサー、およびモバイルネットワークを通じて、フラグメンテーション、MTU、タイムアウト、およびリトライをテストします。新しいスイートが失敗した場合は、承認された互換性プールに戻してアラートを発報します。クライアントが独自に他の脆弱なスイートを試行してはなりません。
ベンダーが古い署名のみをサポートしている場合
ベンダーに対して、バージョン管理されたインターフェースと移行用証明書を提供し、古い署名に対する有効期間と権限を制限します。「今後の課題」として制御不能な依存関係を隠すのではなく、アップグレードのコミットメントを契約および受け入れ基準に盛り込みます。
よくある間違いとフォローアップ
間違い 1：アルゴリズムの置き換えを単一の設定リリースとして扱うこと
フォローアップ：すべての暗号呼び出し箇所、バックアップ、オフラインデバイスをどのように特定しますか？優れた回答では、資産インベントリ、依存関係グラフ、およびオーナーを挙げます。
間違い 2：FIPS の公開をクライアントの普遍的なサポートと同一視すること
フォローアップ：ターゲットライブラリ、認証局、HSM、ゲートウェイ、ブラウザにおけるサポートはどこで証明されていますか？完成した標準と、利用可能なプロダクト実装を区別してください。
間違い 3：RSA へのサイレントなフォールバック
フォローアップ：ダウングレードは誰が承認し、どのくらい持続し、どのようにアラートが出され、何をもって終了しますか？監査可能な互換性ウィンドウを提示してください。
間違い 4：平均レイテンシのみを測定すること
フォローアップ：ピーク時の同時実行性、脆弱なネットワーク、パケットサイズ、CPU、メモリ、証明書キャッシングをどのようにテストしますか？階層化された負荷テストと停止基準を説明してください。
フォローアップの質問と回答
なぜ鍵確立と署名を個別に移行するのですか？
鍵確立はセッションの機密性を保護し、署名はアイデンティティと完全性を保護します。それらのアルゴリズム、証明書チェーン、鍵サイズ、および検証ライフタイムは異なるため、個別にカナリアリリースを行うことで、1つの置き換えによってすべてのワークロードがブロックされるのを防ぎます。
暗号アジリティをどのように証明しますか？
バージョン管理されたスイート、ポリシー切り替え、鍵のメタデータ、プロバイダーの置き換え、互換性マトリックス、監査イベント、およびロールバック訓練を示します。単一の設定ファイルを編集するだけでは、ビジネスコード、証明書、およびデバイスパスが置き換え可能であることの証明にはなりません。
古いアルゴリズムの受け入れはいつ停止できますか？
新しいクライアントのカバレッジ、接続の成功、パフォーマンス、および監査の各ゲートを通過し、古いトラフィックの帰属が特定され、オーナーがアップグレードを完了した後に、まず新規発行を停止します。読み取り専用の検証期間の後、受け入れを失効させます。各ステップにはロールバック条件とオーナーが必要です。