要約
- RFC 5295 は EMSK から用途別・ドメイン別のルートを導出するが、その分離を実運用で成立させるのはラベル、文脈、鍵名、権限、キャッシュ、期限、配送の一貫性である。
- 監査証跡は「異なる値が出た」だけでなく、どの親世代から、誰の要求で、どの範囲へ渡り、旧世代がいつ効力を失ったかを結び付けなければならない。
世代番号のない成功
あるローミング基盤で再認証が完了し、新しい EMSK が成立した。導出サービスは期待どおりの DSRK を返した。ところが利用側のキャッシュキーは加入者と機能名だけだったため、先に保存されたルートが選ばれた。計算結果の照合は成功し、実際の判断は旧世代で行われた。
RFC 5295 は単なる関数定義ではない。EMSK を EAP ピアとサーバー内に留め、明示した用途のためのルートをそこから導出する分離モデルである。USRK は EMSK、用途ラベル、ゼロ区切り、任意データ、出力長を入力とする。区切りはラベルの前方一致による曖昧さを避け、同じ入力は同じ結果を作る。
それでも、受け取ったシステムがその値の世代を理解する保証はない。
ラベルは説明文ではなく座標である
用途ごとに、調整された固有ラベルが必要になる。ラベルは印字可能で大文字と小文字を区別する。任意データは追加文脈を結び付ける。USRK 名は EAP Session-ID と同じラベル・文脈から作ることができ、秘密を開示せずに対象を参照できる。
一方の実装が大小文字を正規化し、別の実装が任意データを捨て、キャッシュがセッションを索引に含めなければ、別々に導出された値が同じ棚へ置かれる。これは暗号衝突ではなく、名前空間の衝突である。
導出の記録には Usage ID、ラベルの正確なバイト列、区切り、任意データのハッシュ、長さ、KDF 版、EAP Session-ID、EMSK 名、結果の鍵名が必要だ。単に成功と記録しても、後から選択を再現できない。
ドメインは配置先ではなく委任範囲である
DSRK は一つの鍵管理ドメインに向けたルートであり、ドメインラベルが導出に入る。その下に、さらに用途を限定した DSUSRK が置かれる。子の範囲は親を越えてはならない。
一用途だけを実行するドメインに DSRK 全体を渡すと、その受け手は枝の他用途まで導出できる。実際には使わないという合意は、技術的な最小権限ではない。必要な能力が DSUSRK で表せるなら、渡す秘密もその幅に絞るべきだ。
ドメイン表記の共有規則も要る。異なる表記から異なる鍵ができる失敗は気づきやすい。正しい DSRK が権限外のプロセスに届く失敗は、値の検査だけでは見つからない。
ローテーションには廃止証明が要る
ルートの寿命は EMSK を越えない。親が期限切れになれば派生ルートも利用から外れ、新しい EAP 交換で EMSK が更新されれば新しいルートへ速やかに移る。子鍵まで同時に交換するかは用途定義に依存する。
つまり、新世代の生成と旧世代の消滅は別の事実である。旧キャッシュ、遠隔コピー、子鍵ごとに所在と廃止イベントを追跡しなければ、ローテーション完了という表示の裏で古い権限が残る。
期限は配送時にも保持されなければならない。値だけ届けば受け側が独自期限を作る。期限だけあっても親世代がなければ別セッションへ結び付く。時間は鍵の意味そのものである。
正しい鍵を返す API も誤る
EMSK は導出点の近くに保持し、外側にはルート取得インターフェースを示す。呼出主体ごとに取得可能な鍵を制限できる。下位層や外部主体が EMSK へ直接触れられると想定してはならない。
しかし API は、正しい値を権限のない呼出主体へ返すことがある。PRF の問題ではなく、認可と出所の問題だ。秘密をログに残さず、呼出主体、要求した用途とドメイン、判断、返した鍵名、親世代を記録する必要がある。
上位アプリケーションがネットワークアクセス鍵だけに依存する設計にも同じ注意が要る。接続方式を変えた途端に安全性と可用性が一緒に崩れる隠れた依存になる。
暗号化された封筒にも宛先の意味が要る
ルートを移送する場合、機密性と完全性、送受信者の認証と認可が必要であり、鍵を特定して利用を制限する文脈や期限も同時に渡す。RFC 5295 は配送プロトコルそのものを規定しない。
暗号化は盗み見を防ぐが、封筒の中身の意味を補わない。鍵名、ドメイン、用途、親セッション、期限が欠ければ、受け手は誤った世代を完全に保護して設置できてしまう。配送記録には両端の主体、認可結果、保護チャネル、ペイロードハッシュ、制約、設置確認が要る。
枝を増やしても親より強くならない
派生鍵の強度は EMSK や EAP 方式の内部マスター鍵を上回らない。ラベルを増やしてもエントロピーは増えない。多数の子を作る用途では、子の導出時に当事者が新しい乱数を供給する必要もあり得る。
複雑な木は権限を狭める道具にはなるが、弱い親、曖昧な名前、広すぎる受け手、消えないキャッシュを修復しない。
分離を証明する台帳
運用上の各利用について、EAP セッション、EMSK 名、用途番号、ラベルと任意データのハッシュ、KDF と長さ、ドメイン、ルート名と子鍵名、親子系譜、作成・失効時刻、キャッシュ索引、置換と廃止、呼出主体、配送両端、チャネル、設置世代、子プロトコルの確認、その後のアクセス結果をつなぐ。
秘密の値は保存しない。台帳が示すべきものは、秘密の周囲で境界が生き続けたという事実である。
Sources
- https://www.rfc-editor.org/rfc/rfc5295.html
- https://www.rfc-editor.org/rfc/rfc5295.txt
- https://www.rfc-editor.org/info/rfc5295/
- https://datatracker.ietf.org/doc/rfc5295/
- https://datatracker.ietf.org/doc/rfc5295/history/
- https://datatracker.ietf.org/doc/rfc5295/references/
- https://datatracker.ietf.org/doc/rfc5295/referencedby/
- https://www.rfc-editor.org/errata/rfc5295
- https://www.rfc-editor.org/rfc/rfc3748.html
- https://www.rfc-editor.org/rfc/rfc5247.html
- https://www.rfc-editor.org/rfc/rfc4962.html
- https://www.rfc-editor.org/rfc/rfc4282.html
- https://www.rfc-editor.org/rfc/rfc1034.html
- https://www.rfc-editor.org/rfc/rfc5296.html
- https://www.rfc-editor.org/rfc/rfc6696.html
- https://www.rfc-editor.org/rfc/rfc7029.html
- https://www.rfc-editor.org/rfc/rfc5448.html
- https://www.rfc-editor.org/rfc/rfc9930.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
