要約

  • COSEのkidは、調べる鍵の集合を絞るための非構造・非一意の値であり、公開鍵の指紋、端末の本人性、操作権限をそれ自体では証明しない。
  • 検証記録には、検索した名前空間、全候補、実際に成功した鍵の完全な指紋、署名対象、本人との結び付き、権限判断、実行結果を別々に残す必要がある。

ある検証器が、非保護ヘッダーにkid = 0x19を持つCOSE_Sign1を受け取ったとする。鍵ストアを引くと二本が返る。一方は更新期間中の旧鍵、もう一方は別のテナントで使う鍵だ。最初は失敗し、次が署名を検証する。

ここで「0x19が署名した」と記録すれば、短い札が主体に化ける。どのストアを、どの範囲で、いつ検索したのか。どの鍵が候補で、どれが成功したのか。その鍵を誰に結び付け、どの規則で操作を許したのか。必要な問いは一つも短い値に収まらない。

これは実在する製品事故の報告ではない。規格が許す正常な重複を、監査設計が異常な唯一性へ変換する危険を示すための場面である。

kidが返すのは候補である

RFC 9052は、現在のCOSE構造と処理を定める。共通ヘッダーパラメーターでは、整数ラベル4、型bstrがkidに割り当てられる。その値は、必要な暗号鍵を探す入力の一つであり、COSE_Keyの同名メンバーなどと照合できる。

同RFCは一意性を仮定してはならないと明記する。同じkidに複数の鍵が関連し、すべて試す必要が生じ得る。値の内部構造も規定されない。COSE_Key側では利用者が選んだバイト列でも、公開鍵から計算した値でもよいが、異なる鍵オブジェクトに同じ値が現れてよい。

したがって検索記録には、アプリケーション、発行者やテナント、鍵ストアの版、時刻、受信した生の値が要る。結果は候補集合である。検証に成功した完全な鍵の指紋は、検索後に得られる別の事実だ。短いkidを指紋の省略形として逆算してはならない。

IANAのCOSEレジストリも、kidをラベル4の鍵識別子として登録する。別のラベルにはkid contextがある。すべてのプロファイルが後者を使うわけではないが、識別子の値とその文脈を別に扱える設計は確認できる。

非保護でよいのは、結論ではないからだ

COSEのセキュリティオブジェクトには、保護ヘッダーと非保護ヘッダーがある。保護側のパラメーターは認証される構成に入る。非保護側はオブジェクトと一緒に運ばれるが、そのことだけでは暗号保護を受けない。

RFC 9052はkidを鍵選択の手掛かりと位置付け、セキュリティ上の決定的フィールドではないため非保護側に置けるとする。この許可を「信用してよい」と読み替えてはいけない。値を変えれば、検索量を増やし、誤った名前空間に誘導し、ログを混乱させることはできる。だからこそ検索数を制限し、テナントを隔離し、候補と試行順を残す。

ただし、非保護のkidを書き換えただけで無関係な鍵の署名が有効になるわけではない。最後には具体的な鍵を使って、正確な署名対象を検証しなければならない。手掛かりの運用リスクと、署名の暗号学的成立を同じ判定にしてはならない。

緑の印が覆う範囲を限定する

署名処理では、RFC 9052のSig_structureが使われる。そこには署名コンテキスト、本文の保護パラメーター、構造に応じた署名者の保護パラメーター、アプリケーションから渡される外部認証データ、完全なペイロードが入る。符号化したToBeSigned、アルゴリズム、実鍵、署名が検証の入力だ。

監査証跡は、デコード後の見栄えだけでなく、保護ヘッダーの元バイト列、external_aadの作り方、処理したペイロードのハッシュ、構造種別を保持すべきである。候補鍵ごとに完全な指紋、来歴、利用制限、成否を結ぶ。未知のcriticalパラメーターや不正なmapで拒否したなら、暗号計算に入らなかった理由も残す。

画面上の配置にも同じ境界が必要だ。署名成功の緑色を非保護のkidまで広げれば、利用者は表示上の近さを署名範囲だと誤解する。

本人性と権限は検証後に始まる

RFC 9052は署名アルゴリズムの成功だけで処理を終えない。アプリケーションは、使った鍵が署名者の本人性と正しく組になっているか、その本人が行動を許されているかを確かめてから操作しなければならない。

鍵と主体の結び付きは、証明書、プロビジョニング記録、ハードウェア証明、アカウント台帳などから得られる。権限は、対象資源、役割、用途、時点、ポリシー版を含む別の判断である。過去の署名は数学的に有効なままでも、現在の操作権限は失われ得る。更新中の二本の鍵が同じ札を持っていても、許可期間まで同じとは限らない。

さらに、許可と実行結果も別だ。認可エンジンが許してもアプリケーションがcommitに失敗することがあり、内部commitが成功しても外部装置が期待どおり変化したとは限らない。

ACEでも短い値は権限にならない

RFC 9052のプロファイル章は、利用するメッセージ、サービス、ヘッダー、アルゴリズム、交渉方法を各アプリケーションに委ねる。共通構造は薄く、運用上の権限は具体的なプロトコルが引き受ける。

RFC 9200は、制約環境向けACE OAuthで同じ限界を実例化する。Proof-of-PossessionのCOSE_Keyを含む応答について、kidは鍵の索引と取得を簡単にするためだけに使われ、clientのdomainでもResource Serverのdomainでも一意と仮定してはならないとする。

認可を扱うプロファイルでさえ、短い値を権限に昇格させない。記録にはプロファイル版、Authorization Serverや発行者、client、Resource Server、audience、鍵用途、ポリシー結果が必要になる。

Schaadの署名と運用権限を混ぜない

Jim Schaadは2017年の初版COSE規格RFC 8152の著者である。後のRFC 9052は構造と処理を置き換え、アルゴリズムはRFC 9053に分かれた。RFC 9052の著者欄にもJ. Schaadが記載される。IETF Datatrackerの人物ページは、この仕事をより広いRFC活動の中に位置付ける。

ただしRFCはIETFの合意文書であり、一人の命令ではない。著者であることは、各社の実装、配備、鍵管理を支配する権限を意味しない。Oregon Wine Pressの追悼記事に掲載されたクレジット付き写真は、今回の人物イラストで本人性を保つための参照資料であり、COSEの技術証拠ではない。

失敗した鍵も履歴に残す

最初の受領記録には、COSEオブジェクトのハッシュ、構造、保護・非保護ヘッダー、外部データ、ペイロード参照を保存する。検索は別レコードとし、名前空間、ストア版、時刻、受信kid、全候補を記す。

各候補には完全な指紋、供給元、有効期間、許可用途、検証結果を付ける。成功した鍵からToBeSignedのハッシュへ線を引き、その後に本人性の根拠、認可判断、アプリケーションの結果を接続する。

失敗した候補を消すと、更新期間に二本あった理由や、ノードごとに答えが違った理由が失われる。残せば結論を段階ごとに言える。この鍵がこのバイト列を検証した。この資料が鍵をこの主体に結び付けた。このポリシーが操作を許可または拒否した。そして、この結果が観測された。短いkidは、その出発点にだけ置かれる。

情報源