鍵を失ったあと、暗号は何を守れるのか

架空事例：青葉機材が取引先の契約書と本人確認情報を保存する。鍵や暗号方式の運用例は概念の説明であり、特定製品への導入手順や保証値ではない。

暗号化されたファイルが、読めてしまった

契約書の保存先を調べると、すべてのファイルは暗号化されていた。担当者は安心した。ところが、復号鍵がアプリケーションの設定ファイルに記載され、その設定ファイルも暗号文と同じ場所へバックアップされていた。

鍵を持つ者には、暗号文は読める。暗号方式が正しくても、その鍵が攻撃者へ渡れば、守りたい秘密は守れない。

暗号のアルゴリズムを選ぶだけでは設計は終わらない。誰が鍵を生成し、どこへ置き、いつ使い、どの時点で失効させ、復元に必要な鍵をどう保持するか。暗号化の中心には、鍵という別の秘密の管理がある。NIST SP 800-57 Part 1は、暗号技術が提供するサービスと鍵素材の保護、鍵管理の機能を整理している。2

ここで「AES-256を採用したから安全」と説明しても、復号鍵を誰でも取得できる環境では意味が薄い。鍵長は一つの性質であり、運用全体の評価ではない。

四つの目的を、一つの「暗号」に入れない

外部の契約書を第三者に読ませないなら機密性が必要だ。改ざんされていないと確認したいなら完全性が必要である。相手が本当に取引先のサーバなのかを確認したいなら、その主体との結び付きが問題になる。

共通鍵暗号AESはデータ暗号化に利用できるが、AESという名前だけで「誰が送ったか」が確定するわけではない。署名方式は、対応する秘密鍵による署名と公開鍵での検証を用いて、署名対象の完全性と鍵の帰属に関する根拠を与える。ただし、署名鍵を操作した本人が人間として誰だったか、署名に法的な意思表示があったかは、鍵の管理・認証・業務手続の条件も必要になる。

HMACなどのメッセージ認証コードは共有秘密鍵を知る者が生成できる。検証者も同じ鍵を持っていれば、第三者に「相手だけが作成した」と示す用途では、公開鍵署名と同じ性質にならない。

ハッシュ関数は一方向性や衝突耐性を重視する要約であり、元の値を秘密にする暗号化とは違う。攻撃者が任意のデータとハッシュ値を置き換えられるなら、単なるハッシュ値の併置だけで真正性を証明できない。要約を鍵や署名と結び付ける理由がそこにある。1

保存時と通信時では、鍵の置き方が違う

サーバ間の通信で暗号化を使うとき、相手の認証とセッション鍵の確立が必要になる。TLS 1.3のRFC 8446は、ハンドシェイクによる鍵確立・認証と、その結果を利用して通信を守るレコード層を分けて規定する。3

青葉機材がHTTPSを採用しても、ブラウザへ正しい証明書が届き、ホスト名や信頼チェーンが検証されることが重要になる。暗号化された回線であっても、誤った相手へ秘密を送るなら、通信路を読まれなかったことは救いにならない。

保存時の暗号化は、接続先を認証して一時的なセッション鍵を使う場面とは違う。数年後に契約書を読めるようにするには、保存データと対応する鍵の保持期間を考えなければならない。最新鍵へ変更しただけで、過去に暗号化したすべてのデータが自動的に読み替えられるわけではない。

鍵を失うと、暗号文は正しく保護されたまま業務上は読めなくなる。機密性と可用性が、ここで衝突する。

鍵の更新は、名前の差替えではない

運用者は「今月から新しい鍵を使う」と決めた。新規の契約書は新鍵で暗号化できる。では旧鍵で保存した契約書はどうなるか。

旧鍵をすぐ削除すると読めなくなる可能性がある。逆に旧鍵を無期限に利用可能な状態へ置けば、漏えいした場合の影響期間が広くなる。どこまでを再暗号化するか、古い鍵を参照専用で残すか、契約書の保存期間と削除手続を合わせて判断する必要がある。

データ暗号鍵と、その鍵を保護する鍵を分離する設計もある。暗号データを再暗号化せず鍵の包み方だけ変更できる場合があるが、何が守られるかは鍵階層と漏えい範囲次第である。鍵ラッピングや鍵管理サービスの採用だけで業務上の権限が自動的に細分化されるわけではない。

OWASPの暗号化保存ガイドも、鍵の生成、配布、保存、更新、廃棄を一連の管理対象として扱う。4 方式選定時には機能の名前よりも、鍵を利用できる主体の数と保管条件を先に確かめたい。

認証された暗号化は、どこまで同時に守るか

機密性だけを想定して暗号文を置いた場合、暗号化方式や運用方法によっては改ざんへの検出が十分でない。認証付き暗号（AEAD）は、暗号化とともに改ざん検出の仕組みを持ち、関連データを認証対象へ含めることもできる。

ただし「認証付き」は、それを使った人間の身元を確認するという意味ではない。AEADの認証は、鍵を知る主体との暗号学的な関係に基づいてデータの完全性を扱う。鍵の保持者を組織の従業員に結び付けるには別の管理が必要になる。

暗号化された予約番号と顧客IDの組合せを、別の予約へ付け替えられると困るなら、関連する文脈を何と結び付けて認証するかが重要になる。データだけを秘匿しても、別件の正しい暗号文を差し込まれる問題は別に考えなければならない。

暗号モードにはそれぞれnonceやIVの使用規則がある。新しい暗号化ごとに必要な一意性や予測困難性を守らなければ、同じアルゴリズム名でも安全性の前提が崩れ得る。ここでは個別モードを自作するのでなく、検証済みの実装と方式に従うことを設計条件とする。4

証明書が有効でも、業務の相手かは別の問い

証明書には有効期限がある。失効情報や利用目的を確認する必要もある。ただし、公開鍵証明書の検証は、業務で許可された担当者かどうかの判断の全部ではない。

たとえば配送会社のAPIが、技術的には正しいTLS証明書を提示したとしても、青葉機材のどの取引を更新してよいかをそこから決められるわけではない。通信の相手の識別と、伝えられた処理を受け入れる権限を分ける。

コード署名も同じだ。発行元や改ざんの有無を確認する助けになるが、署名付きのソフトウェアに欠陥がないことまで保証しない。鍵が不正利用された場合には、正しく検証される不正な配布物が生じる危険もある。

青葉機材のシステムアーキテクトは、証明書チェーンと業務の認可判断を別の設計項目として残す。「電子署名」「デジタル証明書」「コード署名」「eシール」が、何の主体と何の事実を対応付けるかを整理する。原教材第20章で区別した意味が、実際の境界設計へ戻ってくる。1

復旧手順で、暗号の設計が露呈する

障害で保存サーバが失われた。バックアップは別拠点にあり、データは復元できた。しかし、復号に必要な鍵が旧サーバのみに置かれていた。

データの保護には成功したかもしれない。しかし、業務の復旧には失敗している。逆に、どこからでも鍵を容易に復元できる構成は、鍵の漏えいに対する防御が弱いかもしれない。

青葉機材は、復元時に必要な鍵の識別、アクセス権限、操作の記録、鍵の喪失時にできることとできないことを明示する。秘密が漏れた場合、影響する文書と期間を調べる手段も必要になる。鍵の寿命とデータの寿命を一致させないと、問題が起きた後で調査も復旧も難しくなる。

安全な暗号方式の名前を列挙するだけの設計書では、この問題を説明できない。暗号技術が保証する範囲と、人・運用・権限が保証する範囲を分けたとき、初めて方式選定の意味が見える。

知識を答案へ戻す

午前Ⅱ。 AESは共通鍵暗号、署名は鍵と文書の完全性を結び付ける技術、ハッシュは要約、MACは共有鍵に基づく認証である。暗号化・署名・証明書・失効確認の目的を入れ替えない。

午後Ⅰ。 鍵がどこで使われ、誰に読めて、どの障害で失われるかを条件から読み取る。証明書が有効というだけで、業務上の操作権限までは認めない。

午後Ⅱ。 鍵の保持と更新、過去データの参照、漏えい時の影響、バックアップからの復旧まで含め、方式を選んだ理由を説明する。

立ち止まって考える：暗号化したデータだけがバックアップされ、復号鍵は保存されていない。機密性が高いので問題はないか

漏えい耐性の一部は高まっても、保存期間内に業務上復元できるかという可用性を満たせない。鍵の保護と復元の両立を考える必要がある。

出典と照合範囲

[1] コンプリートテキスト第19・20・23章、IPA SAシラバスVer.5.2：暗号方式、署名、証明書、セキュリティ要件を出発点とした。公式シラバス

[2] NIST SP 800-57 Part 1 Rev.5（2020）：鍵素材の保護、鍵管理機能の説明を参照した。青葉機材の保存年数や運用は規定されていない。公式資料

[3] RFC 8446（2018、TLS 1.3）：ハンドシェイクとレコード保護の役割を参照した。TLSの全実装に同一の運用条件があると断定していない。公式仕様

[4] OWASP Cryptographic Storage Cheat Sheet：安全な鍵生成、保管、ローテーションを参照した。独自の暗号方式の実装を勧めるものではない。公式解説