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

「暗号技術」を使うのに、なぜ「鍵管理」はいつも後回しにされるのか ― 暗号をただ使うだけでは足りない、見落としがちなポイント

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

製品セキュリティを実現する上で暗号を使うことは必須ではありますが、実際のところ、

ということを考慮しなければなりません。

暗号そのものの強度は当然重要であり、現在さまざまなシステムの調達や利用において推奨される暗号は、例えば、「CRYPTREC暗号リスト※」などを参照しながら実装することになります。

しかし、近年の法規や認証制度においては、ただ推奨される暗号を使用していればよい、ということではありません。暗号鍵や証明書が適切に管理され、問題が起きた際に対応・更新できる状態にあるかどうかということが、製品の「信頼」を判断する基準になりつつあるのです。言い換えれば、暗号の「使い方」を、具体的に製品の設計と運用で明確にしておかなければならない、ということです。

製品セキュリティ対応を進める中で、「暗号化が必要」「鍵管理が重要」こうした言葉を聞いたことがない、という読者の方はほとんどいないと思います。「信頼」を支えるために暗号鍵や証明書が重要であることは、専門家でなくとも感覚的にわかっていることでしょう。
それでも現実には、暗号鍵や証明書の管理が仕様として明確に定義されないまま、製品が設計・出荷されるというケースが少なくありません。なぜでしょうか。鍵管理が明示的な設計テーマとして扱われることがほとんどない理由は、軽視されてきたからというよりも、長い間「暗黙の前提」として扱われてきた面があるからではないでしょうか。

暗号の処理は正しく動いていて、認証も問題なく行えており、製品として問題なく使えている。
製品の開発を進めていくうちに、まずは正しく動くことをおのずと優先してしまった結果、暗号鍵や証明書は「どこかで誰かが適切に扱っているはず」という前提になってしまっているのではないでしょうか。
こうなってしまうと、もう製品ができてしまったのだから、それに付随する暗号鍵管理という行為をわざわざ切り出して検討し、運用をしていこうという動機が生まれにくいのです。

でも、本当にそれでよいのでしょうか。
家の鍵を「家族がわかりやすい場所だから」といって玄関の植木鉢の下に入れて出かけてしまい、それを泥棒に見られていたとしたらどうでしょう。鍵を取られ、堂々と玄関から入ってお金や大事なものを盗まれてしまいます。鍵の管理が適切に行われていないと、そういった事態を招いてしまうのです。自己責任の世界ですね。

これと同じことです。
デジタルなので目には見えないが、製品の「信頼」を支えるために重要なデータである暗号鍵は、

といったことを正しく把握した上で、管理され続けなければなりません。
これを行えることが「適切」であると言えるのではないでしょうか。

法規や規格への対応を行う中で、審査や認証試験を受けたり、顧客から説明を求められたりする際に問われるのは、自分たちが使っている暗号を、把握し、説明できているかです。

暗号鍵が漏洩したらどうするのか？
証明書に問題が見つかったらどう対応するのか？
将来、暗号方式を変更する必要が出たらどうするのか？
これらの問いに答えられない場合、暗号は「使われている」だけで、「管理されている」とは見なされません。

「そういうことはめったに起きない前提だから大丈夫」「もしそうなったら、そのとき対応を考えればいいや」という姿勢は、もはや通用しなくなっています。
これから製品メーカーが対応しなければならないセキュリティ法規や認証制度は、「事故が起きないこと」ではなく、「起きたときに対処できる設計になっているか」を見ています。
その前提から見ても、暗号鍵や証明書は「存在している」だけでは不十分で、管理され、把握され、制御できる対象でなければならないのです。
ここで問題になるのが、暗号鍵や証明書の管理をどの段階で考えるか、という点です。

多くの設計では、暗号方式や認証ロジックは仕様書に書かれているが、暗号鍵や証明書を誰が管理するのか、どこまでを製品の責任範囲とするのかが整理されていないという状態が多く見受けられます。
これは「設計漏れ」というよりも、暗号鍵や証明書の管理を「後工程の運用課題」として扱ってきた結果ではないでしょうか。

しかし、出荷後もセキュリティ要求が継続する現在の前提では、鍵管理は後付けできる要素ではありません。
製造時から埋め込んだままで更新できない暗号鍵、やたら有効期限の長い証明書、全体像を説明できない暗号構成。心当たりはないでしょうか。これらは、設計段階での甘い判断がそのまま表面化した結果なのです。そして、これからの法規や規格は、それを許してくれません。

それを防ぐ手段として有効なのは、暗号鍵や証明書の管理を、最初から「設計要件」とすることです。
暗号鍵や証明書といった大事な情報を安全に取り扱うために、責任の所在や前提条件、運用の仕方などを前もって設計すること。そして、その設計に沿って正しく運用すること。
これらをあらかじめ設計段階で決めておくことが、これからの製品セキュリティに求められるのです。

ここまで見てきた通り、製品セキュリティにおける暗号は、強度に加え、設計や運用まで含めて考えることが重要になっています。その出発点になるのが、以下の2つです。

次回は、暗号の状態を「把握できる」ようにし、必要が生じたときに「変えられる」ようにするための考え方を整理します（クリプトインベントリ／クリプトアジリティ）。
暗号を「選ぶ」時代から、暗号を「管理し、変え続ける」時代へ。その具体的な対応方法につき掘り下げていきます。