®PKI・HSMのPQC対応
長期間有効な証明書や署名鍵には、特に綿密に調整された移行が必要です。貴社の証明書階層とHSM接続を確認し、適切な目標アーキテクチャを策定したうえで、実際に検証を行うアプリケーションを用いて新しいアルゴリズムをテストします。
OTOKO®へのご依頼内容
HSMがあるアルゴリズムに対応していても、認証局（CA）やプロバイダー、あるいは後段の検証者がまだ対応していない場合があります。証明書プロファイル、トラストストア、ステータスサービス、署名形式を含むチェーン全体を把握します。機器や文書の長いライフサイクルは、移行に影響を与えます。並行階層は有効な選択肢になり得ますが、明確な対応関係が求められます。すなわち、どのアプリケーションがどのチェーンを信頼し、新旧の成果物をどのように区別するかです。
具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。
技術を分かりやすく解説
ハードウェア、ファームウェア、ライセンス、運用モードに関するメーカーのドキュメントを確認します。あるアルゴリズムが利用可能であるからといって、必要な認証や認可の範囲内で使用してよいとは限りません。バックアップ、レプリケーション、鍵移行についても、新しい方式に対応している必要があります。新しいトラストアンカーについては、役割、アクセス手段、セレモニーを計画します。状態を保持する署名方式には、加えて特に慎重な状態管理が必要です。製品のオプションにあるというだけで、検証せずに導入することはありません。
検収には、代表的な証明書の発行と検証に加え、エラーケース、失効情報、旧クライアントの挙動が含まれます。トラスト配布の順序は、切り替えの前に定めます。長期署名検証とアーカイブ要件については、関係部署と調整します。成果は、制約事項を明記した、文書化済みかつテスト済みの構成です。
検証可能な成果
引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。
貴社の取り組みの詳細
実際の製品やアプリケーションの対応状況に沿ってPQCの取り組みを計画します。HSMに新しいアルゴリズムを導入するだけでは、CA、証明書形式、ライブラリ、あるいは検証を行うアプリケーションがそれに対応できなければ十分ではありません。
HSM、ファームウェア、クライアント、PKI、そして利用側システムについての互換性マトリクスを作成します。鍵生成に対応していることは、必要となるすべての署名、インポート、バックアップ処理に対応していることを意味するわけではありません。そのため、対応状況は具体的なバージョンと操作ごとに評価されます。
認可と認証は別個に検討します。技術的なPQC機能が備わっているからといって、特定の規制対象用途での承認が自動的に得られるわけではありません。必要となる証跡やメーカーからの確約は、プロジェクト計画上の前提条件として管理されます。
切り替えの前に、証明書プロファイル、サイズ、転送方法、保存方法、そしてトラストアンカーの配布状況を確認します。制限のあるライブラリを使用しているアプリケーションや、証明書について固定的な前提を持つアプリケーションには、追加の対応が必要になる場合があります。そのためパイロットには、少なくとも一件の完全な発行処理と、実際の利用側システムによる検証の成功が含まれます。
移行にあたっては、既存証明書の残存期間、失効処理、そして起こり得る併存状態を計画します。鍵材料を一律に新しいアルゴリズムへ変換できるわけではなく、多くの場合、新しい鍵と証明書が必要になります。切り戻し経路においても、既に発行済みのオブジェクトとその依存関係を考慮しなければなりません。
プロジェクトシナリオの例
例：社内のPKIを、将来の切り替えに備えて準備するとします。範囲を限定したテストサービスを選定し、想定されるバージョンでCAとHSMを検証したうえで、クライアント側での証明書検証をテストします。対応していないシステムは、具体的な移行上の依存関係として明示されたままになります。
この例は想定される進め方を説明するものであり、顧客事例ではありません。
最初の一歩の前に
これは、モデル、ファームウェア、運用モード、必要なアルゴリズムをもとにしてはじめて判断できます。拡張、並行運用、交換のそれぞれを比較検討します。
いいえ。並行チェーンと暗号的に組み合わせた方式は、異なる移行モデルです。どちらが機能するかは、関係する製品と検証者によって異なります。
