本文とデータ鍵を別に保護する

顧客レポートreport-41をAPP-1から監査部門へ安全に渡すとします。大量の本文をAESで暗号化し、その一回限りの鍵を監査部門の公開鍵で保護する構成です。共通鍵、公開鍵、ハイブリッド暗号、AES、RSA、ECCの仕事を一件の送受信に対応付けます。以下の設定値、鍵ID、ログはすべて架空です。

読む順序は、鍵の役割→暗号化の流れ→検証失敗時の判断→運用と復旧→演習です。科目B（午後）では『公開鍵暗号でレポートを暗号化した』という曖昧な記述から、実際に本文を暗号化した鍵と鍵配送を保護した鍵を分ける必要があります。

1. 何を守るかと、誰が鍵を持つか

用語	この事例での意味と限界
共通鍵暗号	暗号化と復号に同じ秘密の鍵を使う方式。report-41の本文には乱数で作ったデータ鍵DEK-41を使う。計算量の大きいレポートに向くが、受信者へ秘密鍵をどう安全に渡すかが課題。
AES	128ビットのブロックを扱う共通鍵ブロック暗号。AES-128、AES-192、AES-256の数字は鍵長であり、ブロック長ではない。この例はAES-256-GCMを使う。AESという名前だけでは認証付きか分からない。
公開鍵暗号	公開してよい鍵と秘密にする鍵を別に使う仕組み。この例では監査部門の公開鍵でDEK-41を保護し、監査部門だけが持つ対応秘密鍵で復元する。公開鍵を入手しただけでは相手の身元は保証されない。
RSA	整数の素因数分解問題に基づく公開鍵方式。この例の鍵配送にはRSAES-OAEPを使い、RSAでレポート本文を直接暗号化しない。RSA-PSSなどの署名方式とは目的と処理が別。
ECC（楕円曲線暗号）	楕円曲線上の演算を使う公開鍵技術の総称。ECDHは共有秘密の合意、ECDSAは署名に使う。この例のRSA鍵配送を別設計でECDH系の鍵カプセル化へ置き換えることはできるが、『ECC』単体が暗号化方式名ではない。
ハイブリッド暗号	高速な共通鍵暗号で本文を守り、公開鍵方式で共通鍵の安全な受け渡しを助ける構成。秘密鍵の管理と公開鍵の真正性を欠くと成立しない。

送信者APP-1は監査部門の公開鍵を事前に真正な経路で登録し、鍵IDと指紋を照合します。監査部門は対応するRSA秘密鍵をAPP-1へ渡しません。report-41のDEK-41も本番ログや平文設定に残しません。鍵の生成・保管・更新の詳しい運用は別の鍵管理記事で扱います。

本文とデータ鍵を別に保護する

1. DEKで本文を暗号化
2. 公開鍵でDEKを保護
3. 本文を届ける
4. 鍵材料を届ける

本文はAES-GCM、DEKは受信者のRSA公開鍵で保護する。

図では同じ受信者へ二つの成果物を届けます。暗号文だけ届いてもDEKを復元できません。保護したDEKだけ届いても本文はありません。受信者の鍵が正しいことと、送信者がAPP-1であることは別の確認です。送信者の認証が必要なら署名や認証済み通信路を併用します。

2. AES-GCMで本文を保護する手順

APP-1は暗号学的に安全な乱数生成器でreport-41用の256ビットDEK-41を作る。同じDEKの長期使い回しを避け、鍵IDと用途を記録する。
DEK-41の下で再利用しない96ビットのnonceを作る。report-41の識別子と版をAADとして固定し、AES-256-GCMへ平文、nonce、AADを入力する。
AES-GCMから暗号文と認証タグを得る。保存物には方式、nonce、AADの版、暗号文、タグ、鍵IDを含める。秘密のDEK自体は入れない。
監査部門の登録済みRSA公開鍵とRSAES-OAEPでDEK-41を保護する。受信者はRSA秘密鍵でDEKを復元し、同じAADを使ってGCMタグ検証に成功してから平文を利用する。

保存・送信する項目	意味とチェックポイント
alg=AES-256-GCM	AES本体とGCMモードを組にした指定。AES-256だけではモードや完全性保護の有無は分からない。
key_id=DEK-41	どのデータ鍵を使ったかの識別子。鍵そのものではない。受信側が対応する保護済みDEKを選ぶ。
nonce	同じDEKの下で再利用しない値。秘密にする必要はないが、再利用はGCMの機密性・完全性を破壊し得る。複数ノードの採番衝突を設計で防ぐ。
aad=report-41:v3	暗号化しないがタグで保護する関連データ。識別子・版との結び付きを確かめる。AADの値や符号化が違うと検証は失敗する。
ciphertext / tag	本文の暗号文と改ざん検知用タグ。タグに合わない平文候補をアプリに渡さない。タグ失敗は原因の特定までは示さない。
wrap_alg=RSA-OAEP	DEKを保護した方式。RSA秘密鍵の保有者だけが復号可能という設計だが、鍵の真正性・実装・権限が前提。

架空の送信記録は次のとおりです。暗号文やタグの実バイト列は長いため省略しました。`encrypt_ok`はAPP-1が暗号化結果を生成できたという事実で、受信者が復号したことや、相手の公開鍵が本物だったことは示しません。

text

10:00:02 job=R-41 object=report-41:v3
  content_alg=AES-256-GCM key_id=DEK-41
  nonce_id=NONCE-883 aad_id=report-41:v3
  wrap_alg=RSA-OAEP recipient_key=AUD-RSA-7
  action=encrypt_ok
10:02:19 recipient=auditor object=report-41:v3
  unwrap=ok tag_verify=ok action=accept

`nonce_id`は監査用の識別子で、実際のnonce値ではありません。受信者が正しいAADとタグを使って検証したときだけ`accept`になります。公開鍵の登録元が攻撃者なら、APP-1は攻撃者へ復号可能なDEKを送るため、暗号化成功ログだけでは安全性を証明できません。

3. RSAとECCを取り違えない

RSA-OAEPは受信者へ小さな鍵材料を届ける用途であり、大容量の本文を直接扱う設計ではありません。RSAの鍵サイズ、OAEPのハッシュとラベルなどのパラメータは送受で一致させます。古いRSAES-PKCS1-v1_5暗号を新規設計へそのまま持ち込まず、対応する標準と実装の推奨を確認します。

ECCで同じ目的を実現する場合、ECDHで得た共有秘密をKDFに通して鍵を導出し、AEADでDEKや本文を守る構成になります。HPKEは鍵カプセル化、鍵導出、AEADを組にする標準例です。ECDSAは署名であって鍵の配送方式ではありません。『楕円曲線なのでAESは不要』という理解も誤りです。

方式・操作	秘密にしたいもの／証明したいもの
AES-GCM	共有DEKを持つ相手だけが本文を復号し、タグで同じ鍵に対応するデータの改ざんを検知する。第三者に送信者を証明する署名ではない。
RSA-OAEP	受信者の公開鍵でDEKを保護する。送信者が誰かを証明する処理ではない。
ECDH / ECDHE	二者が共有秘密を合意する。相手の公開値を認証しなければ中間者が入り得る。
RSA-PSS / ECDSA	秘密鍵で署名し、公開鍵で検証する。暗号文の秘匿ではなく署名対象の完全性と鍵の保有を確認する。

4. 異常時：鍵、nonce、AAD、タグのどれが違うか

観測	原因候補と追加調査
unwrap=fail	RSA秘密鍵の不一致、鍵ローテーション時の旧鍵紛失、OAEPパラメータ不一致、保護済みDEKの破損を調べる。本文改ざんだけと決めない。
tag_verify=fail	誤ったDEK、nonce、AAD、暗号文・タグの破損や改ざんが候補。どれが原因かはタグ失敗だけでは分からない。失敗した平文候補を出力しない。
nonce重複	同じDEKの下で同じnonceを使ったかを監査する。GCMでは深刻な設計失敗。影響した暗号文を特定し、新しいDEKで再暗号化する。
公開鍵の差替え	登録済み指紋と実際のrecipient_keyを照合する。差替えられた鍵で暗号化済みなら、受信者への再送だけで漏えい可能性は消えない。
DEKまたは秘密鍵の漏えい	DEK漏えいは対応するデータの復号に直結する。監査部門のRSA秘密鍵漏えいは、その鍵で保護された過去のDEKにも影響し得る。対象範囲を鍵IDで特定する。

攻撃者が保存領域の暗号文だけを読める場合、DEKと受信者秘密鍵が守られていれば平文は通常読めません。攻撃者が保存領域を書き換えられても、タグ検証で改ざんを検出できます。ただし、暗号文全体を古い正当な版へ置き換えるロールバックは、版や文書IDを信頼できる台帳で確認しなければ見逃し得ます。

5. 変更・障害・復旧の運用

新しい受信者公開鍵を登録するときは、証明書チェーンや事前に確認した指紋を使い、鍵所有者と用途を確認する。登録担当と承認担当を分ける。
受信者RSA鍵を更新する際は、旧鍵で保護されたDEKを復元できる期間と、新鍵への再ラップ計画を定める。旧秘密鍵を先に廃棄すると過去データが読めなくなる。
DEKを更新する場合は、単なる再ラップと本文の再暗号化を区別する。DEK自体が漏えいしたなら、旧DEKで守った本文を新DEKで再暗号化する。
タグ失敗や鍵不一致時は復号失敗を利用者へ一律に返し、詳細は制限した監査ログへ残す。失敗の違いを外部へ細かく返して復号オラクルにしない。

復旧条件は『ジョブが再実行できた』だけではありません。登録済み公開鍵の真正性、DEKとnonceの非再利用、対象データの再暗号化、監査部門でのタグ検証、旧鍵の失効と監査記録を確認します。漏えい時は既に流出した平文を回収できないため、閲覧・再配布の影響調査も必要です。

5-1. 複数の監査担当へ渡すとき

同じレポートを監査部門AとBへ渡す場合、本文の暗号文を二つ作る必要はありません。同じDEK-41を、Aの公開鍵とBの公開鍵それぞれで保護した二つの鍵包を用意できます。ただしBを後で追加するには、APP-1がDEKを扱えるか、Aが再共有する権限を持つかを決めておく必要があります。

Aの権限を取り消しても、Aが既に復号済みの本文やDEKを持っていれば、鍵包を削除するだけで閲覧を取り消せません。アクセス制御の失効と、既に受け渡した暗号鍵の知識は別です。機密度が高い場合は新DEKで本文を再暗号化し、許可された受信者にだけ新しい鍵包を発行します。

5-2. nonceをどう重複させないか

GCMのnonceは『乱数なら毎回絶対に違う』という意味ではありません。単一プロセスの乱数生成でも衝突確率があり、複数ノードで同じ鍵を共有すれば採番の競合や障害復旧時のカウンタ巻戻しが起こり得ます。鍵ごとのnonce管理、ノード間の分担、再起動後の状態維持、鍵の利用回数制限を設計します。

APP-1が障害で同じreport-41を再送するとき、以前の暗号文とタグをそのまま再送することと、同じDEK・nonceで平文を再暗号化することは別です。後者を許すと、平文の変更がなくても運用上の重複が隠れます。再暗号化するなら新nonceを確実に確保し、ジョブIDと鍵IDで監査します。

5-3. 監査で見たい四つの記録

記録	確認できる範囲
鍵登録履歴	AUD-RSA-7の所有者、用途、公開鍵指紋、承認者、登録・廃止時刻。差替え攻撃を調べる根拠になる。
暗号化ジョブ	report-41の版、使用したDEK ID、nonce識別子、AAD版、生成された暗号文の識別子。鍵素材そのものをログに残さない。
鍵包の発行	どの受信者公開鍵でどのDEKを保護したか。複数受信者の権限撤回範囲を特定する。
受信者の検証	unwrapとタグ検証の結果。平文を読んだ人物やダウンロード後の再配布まで保証しない。

暗号文のバックアップを復元したときは、暗号文、タグ、nonce、AAD、保護済みDEKを一組として復元します。一つでも違えば復号やタグ検証に失敗します。秘密鍵が失われた場合、暗号文が完全でも復号できません。鍵のバックアップと復旧試験は、データのバックアップと同じく可用性に直結します。

5-4. 方式を変えるときの境界

将来RSA-OAEPからHPKE系へ鍵配送を変えるなら、暗号文の方式と鍵包の方式を別フィールドで持ちます。`content_alg=AES-256-GCM`を変えずに`wrap_alg`だけを移行できる構造なら、本文の再暗号化と鍵包の再作成を混同しません。旧データの復号に必要な旧秘密鍵をいつ廃止するかも計画します。

アルゴリズム名をメタデータに置くだけで任意の古い方式を受け入れると、攻撃者の指定で弱い処理へ落ちる危険があります。許可する方式をアプリ側で固定し、署名や認証済みのメタデータとして方式を結び付けます。方式の廃止日は互換性だけでなく、残るデータと再処理の進捗で決めます。

6. 科目B（午後）での読み方と演習

構成図では、鍵を生成する主体、本文を暗号化する鍵、DEKを保護する鍵、秘密鍵の保管者、タグ検証者を線で追います。ログでは`encrypt_ok`と`tag_verify=ok`の意味を分けます。問題文にない鍵漏えいを事実として追加しません。

演習1：本文を暗号化した鍵

条件：APP-1はAES-256-GCMでreport-41を暗号化し、RSA-OAEPでDEK-41を保護した。質問：本文を暗号化したのはどの鍵か。解答：DEK-41。誤答『RSA公開鍵』は本文とDEKの保護を取り違えている。

演習2：AES-256の256

条件：仕様書にはAES-256とある。質問：256ビットは何の長さか。解答：鍵長。AESのブロック長は128ビット。誤答『ブロック長』はAESの規格と混同している。

演習3：タグ失敗

条件：監査部門で`tag_verify=fail`。質問：直ちに改ざんと断定できるか。解答：できない。誤った鍵・nonce・AADや保存破損も候補。誤答『攻撃確定』は失敗原因を一つに決め付けている。

演習4：受信者公開鍵の差替え

条件：攻撃者がAPP-1の登録済み公開鍵を自分の鍵へ差し替えた。質問：暗号化成功でも何が起きるか。解答：攻撃者がDEKを復号し得る。誤答『公開鍵だから差替えは無害』は公開鍵の真正性を無視している。

演習5：秘密鍵漏えい後の鍵更新

条件：監査部門のRSA秘密鍵が漏えいし、過去の保護済みDEKも保存されていた。質問：新しいRSA鍵を登録するだけで十分か。解答：不十分。過去のDEKと暗号文の影響を調べ、必要なら新DEKで再暗号化する。誤答『新鍵で今後は安全』は過去分の露出を無視する。

演習6：ECCの用途

条件：設計をECC系へ変更する。質問：ECDSAでDEKを暗号化できるか。解答：できない。ECDSAは署名であり、鍵合意にはECDH、暗号化にはAEADを組み合わせる。誤答は楕円曲線技術を単一用途と誤解している。

7. 一次資料

NIST FIPS 197：AESの鍵長とブロック長

NIST SP 800-38D：GCMと認証タグ

RFC 8017：RSAES-OAEPと署名方式

RFC 9180：HPKEと鍵カプセル化

共通鍵・公開鍵・ハイブリッド暗号とAES・RSA・ECC