要約

  • RFC 3157は資格情報の移動に機密性と完全性を求めたが、暗号化された保管庫を信頼不要とは扱わなかった。サーバーは秘密を利用できなくても、対象の存在、版、配布、削除を支配し得た。
  • SACREDの要件は、資格情報サーバーと端末間の直接転送をともに残した。前者は永続保管と方針を集中させ、後者はその集中を避ける代わりに、端末発見、相互認証、互換性、受領証拠を必要とした。
  • アップロード、ダウンロード、認証済み受領通知が証明するのは、その名が示す操作だけである。安全な保存、他の複製の消去、移行権限、相手による受容、アプリケーション成功までは証明しない。

一つの暗号上の身元が一台の機械より長生きし始めた

初期のモデルは物理的に分かりやすかった。利用者は一台のコンピューターで鍵対を生成し、公開部分を認証局へ渡し、秘密部分をその機械に残した。端末、保存場所、署名能力の寿命は、ほぼ同じものに見えた。

複数端末の利用は、その重なりを崩した。同じ人物が職場のデスクトップと出張先のノートPCからメールに署名する。電話機や双方向ページャーで復号する。能力不足になったルーターを交換しても、対向装置には従来の公開鍵を信頼させ続けたい。筐体の交換だけを理由に全対向先を再設定することは、暗号方式とは別の調整費用を生む。

RFC 3157はこの問題を資格情報の移動性と呼んだ。対象には秘密鍵、信頼ルート、チケット、Personal Security Environmentの私的部分が含まれる。S/MIME、IPsec、TLSは利用先の例であり、要件文書が作り替える対象ではない。目的は、確立済みのセキュリティ上の身元を別の端末で継続できる材料を安全に運ぶことだった。

ルーターの例で「身元を移す」と言うのは便利だが、文字どおりではない。移ったのは暗号材料と、既存の検証規則に対して継続性を示す能力である。旧端末、新端末、管理者、発行者、対向設定、実際の通信は別の対象のままだ。鍵の複製は一つの暗号関係を保てても、移行を命じる行政権限まで運ばない。

二つの方式は、故障と権力を違う場所へ置いた

RFC 3157はSACREDの枠組みに、資格情報サーバー方式と直接転送方式の両方を要求した。これはネットワーク図の好みではない。誰が長期保管し、誰が到達を妨げられ、どの証拠で操作が完了するかを分ける設計判断だった。

サーバー方式では、端末が保護済み資格情報をリポジトリへ預け、任意の期間後に別の端末が取得する。組織はなじみ深いクライアント／サーバー運用、元端末の寿命から独立した保管、統一方針を適用する場所を得られる。

その便益は依存も集中させる。サーバーは発見または設定され、守られ、復旧可能で、必要な時に稼働していなければならない。中身がすべて暗号文でも、リポジトリは複製、破壊、妨害の価値を持つ。新端末が資格情報を最も必要とする瞬間に、中央サービスへ届かないこともある。

直接転送は仲介者での永続保管をなくす。途中でパケットを運ぶノードが資格情報サーバーになるわけではない。ただし負担は両端へ移る。端末は互いを見つけ、同時に接続でき、対応する転送・認証方式を持ち、形式や能力の違いを処理する必要がある。配送の成否が重要なら、送信側には信頼できる受領通知も要る。

文書はどちらかを普遍解としなかった。この区別によって、サーバーの便利さが拒否権を隠すことも、直接転送の分散性が端末間調整の難しさを隠すことも防いだ。

暗号文になっても、運用権限は残った

一般要件の一つは限定的で明確だった。プロトコルは、最終利用者の端末以外で資格情報を平文にすることを強制してはならない。サーバーは秘密鍵を開かずに、保護された包みを保管または中継できる。

これは機密性の境界であって、サーバーが無力になったという証明ではない。運用者は対象が存在するか、検索できるか、どの版が返るか、アップロードで置換されるか、削除でサーバー上の写しが消えるかを制御できる。秘密鍵から署名を作れない人でも、その写しを利用不能にすることはできる。

「資格情報を消去する」という表現にも範囲がある。リポジトリのレコードを消しても、端末、バックアップ、キャッシュ、エクスポートの複製が消えたとは限らない。対向先は公開鍵を保持し、別の秘密鍵コピーが生き残るかもしれない。証明されたのは、一つの操作が一つのリポジトリを変更したことだけだ。

可用性は開示とも独立していた。RFC 3157は資格情報サーバーを重大なサービス拒否攻撃の標的とした。攻撃者に鍵を読ませないことと、利用者が必要時に取得できることは別である。秘密のまま到達不能になった材料でも、署名メールやルーター交換を止められる。

この分離が文書の最も長く残る教訓である。暗号は誰が材料を知り、利用できるかを狭める。しかし、誰が差し止め、置換し、旧版へ戻し、削除し、配布を拒めるかまでは自動的に狭めない。

操作名が受領証拠の限界を決める

サーバー方式に曖昧な「同期」だけでは足りない。RFC 3157は、一覧取得、追加、削除、認証情報変更を求め、自己登録を必須とし、管理者による一括初期化も許容した。

動詞ごとに権限面が異なる。一覧は秘密そのものではなく在庫を露出する。ダウンロードは端末へ対象を渡す。アップロードはサーバー状態を作成または置換する。削除はサーバー側状態をなくす。パスワード変更は将来の認証境界を変える。自己登録はアカウント関係を作る。一つの成功が次の操作を許可するわけではない。

ダウンロード前の利用者認証は、プロトコルのアカウントモデル上で誰が要求したかに答える。サーバー認証は、偽者へ秘密を渡したり偽の対象を受け取ったりする危険を減らす。資格情報の認証は、転送物の置換や破損を検出する助けになる。

それでも、宛先端末の安全は証明されない。正しい利用者が侵害済みソフトウェアから認証することも、正規サーバーが古いが有効な包みを返すこともある。真正な資格情報が、本人の承認しない操作に後から使われることもある。本人性、対象完全性、端末保証、行為の許可は別の判断だ。

後のRFC 3767はサーバー経路を実装する際、アカウントパスワードと資格情報パスワードを区別した。前者はサーバーアクセスを認証し、後者は取得した資格情報の私的部分を守る。一回の検査に双方の意味を与えれば、その証拠の権限を不当に広げる。

形式の不透明性は調整を減らしたが、証明を増やさなかった

RFC 3157は、資格情報の種類と内部形式を転送相手に対して不透明にするよう求めた。すべての秘密鍵、チケット、保護コンテナをプロトコルが解釈する必要はない。利用者認証や下位トランスポートも複数方式を許すべきだった。

これは最小の共通面である。二つのシステムは内部表現を統一せずに、保護対象を移せる。制約の大きい端末も、参加のために相手の全形式を実装しなくてよい。

一方、不透明性は証拠の読み方を厳しくする。サーバーが中身を理解しないなら、アップロード成功は特定のバイト列を受け取ったことしか示さない。正しい鍵か、パスワードで開くか、アプリケーションが取り込めるか、依存プロトコルで使えるかは別だ。対象識別子、版、指紋、完全性証拠を各段階で維持する必要がある。

「最新版」という暗黙の前提も危険である。リポジトリが正常に応答しながら旧版を返すことはできる。秘密を読むことなく、撤回済みの権限、期限切れの鍵、古い方針を復活させるロールバックが可能だ。時間順序と対象同一性も結果の一部だった。

到着と保存と利用結果は三つの出来事だった

直接転送では、受信者が送信者を認証し、送信者が受領通知を得ることが求められた。この通知は重要な問いを閉じる。単なる中間点ではなく、本来の相手がプロトコル上の操作を確認したという問いだ。

ただし受領通知の意味は無限ではない。特定の時刻に特定のプロセスへバイト列が届いたことは示せても、OSが安全に保存した、インポートが完了した、一時メモリーが消去された、後日利用者が開ける、とは限らない。

外部結果も別である。ルーターなら、新装置への鍵の取り込み、身元提示、対向先の受容、通信復旧まで追う必要がある。メールなら、クライアントが署名または復号し、受信者やサービスが結果を受け入れるまで続く。転送は状態遷移であって、成果そのものではない。

この区別は、誤った消去証拠も防ぐ。弱い受領通知だけで送信元が複製を消し、その後宛先の取り込みが失敗すれば、移動は喪失に変わる。反対に永遠に消さなければ、管理されない複製が増える。送信元の処分方針は、受領通知が何を保証したかに依存する。

監査経路が第二の漏えい経路になり得た

RFC 3157は、とりわけサーバーにセキュリティ関連事象の監査を求めた。時刻、アカウント、操作、結果は、試行と完了、利用者による削除とリポジトリ障害、通常停止と攻撃を区別する手掛かりになる。

同時に、監査は保護対象の秘密を収集してはならないと警告した。利用者が誤ってパスワードをユーザー名欄へ入力することがある。生入力をそのままログへ写せば、秘密は最も複製され、広く閲覧される場所に残る。

「すべて記録する」では解けない。長期に使える受領証拠は調査に十分な本人・操作文脈を持ちつつ、パスワード、秘密鍵、再利用可能な秘密を除かなければならない。ログ自身にもアクセス制御、完全性、保存期限、時刻証拠が要る。

「ダウンロード成功」という一行だけでは、どの保護対象がどの保存面へ入ったか分からない。完全な調査は、対象指紋、プロトコル記録、宛先端末、ローカル取り込み、後続利用、アプリケーション結果を結ぶ。

ハードウェア封じ込めは別の問いに答えた

付録はスマートカードなどのハードウェアトークンを検討した。秘密が携帯可能なハードウェア内部にとどまれば、ホスト間で複製せず、対応する読み取り装置の間を移動できる。環境によっては強い封じ込め境界になる。

しかし普遍的な代替ではない。すべての端末に読み取り装置があるわけではなく、費用、互換性、故障、復旧の問題も残る。SACRED型プロトコルは、トークンを管理者へ物理返却せずに中の資格情報を更新する補完手段にもなり得た。

そのため主要要件はソフトウェア資格情報に限定され、異なる安全姿勢が認められた。正直な比較は「ハードウェアは安全、ソフトウェアは危険」ではない。何がどの境界を離れ、どの端末が参加し、誰が継続を止められ、故障からどう戻るかである。

RFC 3157はスマートカード、電話、ページャー、ワークステーションの安全を証明しなかった。物理的封じ込めが使えない、または不足する時に、将来方式が扱うべき構造を示した。

後続仕様は要件空間の一経路を選んだ

RFC 3760は後に抽象枠組みを示し、RFC 3767はXMLメッセージとBEEPプロファイルを使う資格情報サーバープロトコルを定義した。TLSおよび／またはDIGEST-MD5を用い、通常の取得と任意のアカウント管理操作を区別した。

この系譜は、問題から枠組み、具体プロトコルへ仕様作業が進んだことを示す。RFC 3157の全要件が配備されたこと、直接転送が一般化したこと、特定製品が正しく守ったことは示さない。

RFC 3767がオフライン辞書攻撃を懸念した点も、証明の境界を表す。盗聴者に有用なパスワード検証材料を渡さないプロトコルでも、パスワード品質、端末ソフトウェア、サーバー可用性、資格情報暗号化へ依存し続ける。一攻撃への耐性は、普遍的なアカウント安全ではない。

RFC 3157の歴史的価値は、関連する概念を一つへ押し込めなかったことにある。転送の秘匿、リポジトリ権力、持続的可用性、端末認証、受領、保存、同一性の継続、後続利用は、どれも互いの同義語ではなかった。

移動可能な資格情報は証拠面を広げた

一台だけのモデルは危険を一か所に集め、経緯を単純にした。移動性は復旧性と利便を高める一方で遷移を増やした。アップロード、リポジトリ変更、ダウンロード、直接引き渡し、取り込み、利用の各点で、同一性は複製、差し止め、置換、誤解の対象になる。

耐久性のある監査は、発行者と保護対象の指紋から始まる。サーバー型か直接型かを明示し、利用者・サーバー・端末認証を分け、要求操作を名付け、版と完全性を保存し、リポジトリ状態と可用性を記録し、宛先端末と信頼前提を識別し、依存プロトコルとサービス結果まで追跡する。

ルーターの対向先が旧鍵を受け入れ通信が戻れば、成功したダウンロード以上のことが分かる。新端末に保存されても対向先が拒めば、同一性は回復していない。無権限の管理者が移行を開始したのに対向先が受け入れたなら、暗号上の継続性は行政権限を与えていない。

RFC 3157の持続する洞察は、鍵を旅行させたことだけではない。移動中の秘密を守っても、到着、生存、有用な結果を左右する制度と機械は消えない。サーバーは平文を必要とせず、なお力を持っていた。

出典