製品セキュリティの最前線【第4回】

暗号は変わる ― 法規要件を守り続けるための
「クリプトインベントリ」と「クリプトアジリティ」

※こちらのページに記載されている内容は、2026年5月時点の情報です。

例えば、欧州連合(EU)のCRA(サイバーレジリエンス法)の必須要件(Annex I)では、

といった項目が示されています。
これらの要件は、各機能があることではなく、製品ライフサイクル全体を通じてその状態が維持されていることを求めている点が重要です。

例えば「保存時・通信時のデータ暗号化」という要件に関しては、一度暗号化してしまえば要件を満たせるということではありません。暗号鍵や証明書が信頼できる状態で管理され、もし問題があった場合に新しいものに切り替えるなどの対応を行えることを含めて、初めて「データが守られている状態」と言えます。

同様に、認証やアクセス制御についても、単に認証の機能が実装されているかどうかではなく、その認証を行うために必要な暗号鍵や証明書が都度有効であるか、失効が必要な場合は失効できるかなどが前提になります。
脆弱性対応の要件も、更新プログラムが正当なものであると検証でき、その検証に用いる暗号や署名が問題なく使えることが必要なのです。

このように見ると、前記の各要件は一見バラバラに見えながら、軸となる暗号が実装されるだけでなく、常に機能し続けられることが必要であり、これが「信頼」を技術的に支えているということがわかります。

では「機能し続けられる」とはいったいどういうことでしょうか。これが今回のテーマである「暗号は変わる」につながります。最初に暗号が実装されたときに使えるのは当然の話。ただし、製品が使われ、時間が経過するうちに、さまざまな事象が発生することが考えられます。

暗号鍵や証明書に問題が生じた、あるいはその疑いが生じた場合、もう使えなくなってしまってよいのでしょうか？
証明書を新しいものに更新することや、漏洩してしまった暗号鍵をもう二度と使えないようにする必要はないでしょうか？
遵守しなければならない法規や、それを実現するために参照している規格が変更されてしまったら？
攻撃手法の進歩により、今使っている暗号アルゴリズムに想定外の脆弱性が発見されたとき、どうしますか？

これらの問いに答えるためには、暗号を「変えられる」ようにしておく必要があります。言い換えると、使用する暗号鍵や証明書、さらには暗号アルゴリズムや鍵長は、変更できるようにしておく必要があります。そのためには製品全体として対応可能な設計が求められます。ここまでできて初めて、これまで述べてきたさまざまな要件がようやく満たされる、ということになるのです。

さて、どのようなときに「暗号は変わる」のでしょうか。
ここで大事なのは、現在使っている暗号技術が間違っているから変わるのではない、という点です。
暗号が変わる理由には、次のようなものがあります。

近年話題になっているPQC(耐量子計算機暗号)は、こうした流れの中で注目を集めている代表例に過ぎません。
本質的な問題は、「いつPQCになるか」ではなく「暗号は製品の寿命よりも短いサイクルで変わり得る」というところにあります。製品が長いものでは10年、15年と使われる中で、暗号アルゴリズムや鍵長が一度も変わらないと想定すること自体が、すでに現実的ではなくなっているのです。

暗号を「変えられる」状態にしておくには、まず前提として、いまなにがどこで使われているかを把握できている必要があります。この「把握」を正しく行うために使えるのが「クリプトインベントリ」です。

クリプトインベントリとは、暗号アルゴリズムや暗号鍵、証明書の使われ方や関係性などを把握するための「暗号に関する台帳」です。ここで誤解されがちなのは、クリプトインベントリは「使用中の暗号アルゴリズムを一覧化する」という目的のみで使用されると思ってしまうことです。もちろんアルゴリズムの一覧も一部ではありますが、それだけでは「暗号を変えられる」状態には到達しません。

実際には、次のような情報が整理されている必要があります。

これらの情報が揃うことで「暗号がどこで、どのように使われているか」が適切に把握できる状態になります。
一覧化されていることで、暗号鍵や証明書の具体的な所在を明確にするだけでなく、依存関係を説明することや、運用において証明書の有効期限などを管理することが可能です。

重要なのは、クリプトインベントリが開発メンバーの棚卸し目的のみの利用で終わらないことです。
法規対応を進める中で、認証や監査などを受けた際、暗号の利用状況を適切に把握できていることを説明するためのエビデンスとして使えるような内容であることが求められます。

クリプトインベントリは、まず情報を集めるということから手動作成するケースが多いかと思いますが、今後複雑化する暗号の利用状況を考慮すると、より効率的に暗号に関する情報を収集・管理できることが求められるようになるとみられます。そこで近年注目されているのが「CBOM（Cryptography Bill of Materials）」です。

OWASP※¹のCycloneDX※²プロジェクトでは、暗号資産（アルゴリズム、証明書、鍵など）を標準的な形で記述する枠組みが不足しているという問題意識から、SBOMの枠組みを拡張してCBOMを整備する動きが進められています。
SBOM管理をツールに任せることで、組織における暗号利用状況の把握も自動化され、より鮮度の高い形で可視化できるようになることが期待されます。

クリプトインベントリを用いて「現状把握」ができるようになることと並んで必要なのが、今度はそれを将来の変化に対応できるように備えることです。暗号方式を、既存のシステムやプロセスに大きい影響を与えず、運用を止めることなく、迅速かつ柔軟に変更できる能力。これが「クリプトアジリティ」です。

ここで注意したいのは、クリプトアジリティが単に暗号ライブラリの差し替えが容易であることを指す言葉ではない、という点です。実際の製品では、暗号の切り替えを行う場合、暗号鍵の変更、証明書の再発行・配布、不要な暗号鍵・証明書の失効措置などを行うことになります。これに伴う、製品や製造インフラのソフトウエアやハードウエアの変更も発生します。それも1回きりの変更でなく、継続的な変更が行えるようにする必要があるのです。

単に暗号だけを変えられても「機能し続ける状態」は維持できないというのは、紛れもない事実なのです。
量子コンピューターの普及によりPQCへの切り替えが現実味を帯びている今、クリプトアジリティの必要性は一段と増してきています。PQC移行においては、PQCと古典暗号を組み合わせたハイブリッド暗号方式の採用、実装における暗号機能の疎結合化などが具体的な手法として挙げられており、将来的な脅威への対応が進みつつあります。
また、暗号を新しいものに移行した場合、後方互換性や相互運用性などについて問題がないか検証を行っておかなければなりません。さらに、これらの対応を行うにあたっては、それぞれの過程で相応のリードタイムを必要とします。

クリプトアジリティを実現するにあたっては、単にひとつのプロジェクトや製品で対応するのではなく、企業の組織や製品の製造プロセスの高度化を含め、全体的なITアーキテクチャの観点で最適な設計を行っていくことが有用です。

ここまでお読みいただくと、クリプトインベントリやクリプトアジリティの導入は、とても壮大な取組みに見えるかもしれません。しかし、導入の勘所は、実は意外とシンプルです。

そうはいっても、実際のところまだ何もできていないという方もいらっしゃるかもしれません。
その場合、まずは「信頼の基点」の要素のひとつである、暗号鍵の管理について考えるところから始めてみてはいかがでしょうか。

次回は、ここまで述べてきた内容を受け、「暗号鍵管理」とはどのようなものか、どういった対応が必要となるのかを、設計・運用・説明責任の観点から整理します。