要約

  • 10月27日付の個人Internet-Draftは、BPSecの受信側が保護対象のブロックと必要なサービスごとに、権限を持つSecurity Sourceと対応する鍵を先に定めるよう提案する。別の正規ノードの署名が通っても、その要件を満たしたことにはならない。
  • ペイロードとプライマリブロックを一組として証明するには、ペイロード側のBIBの完全性範囲にプライマリブロックを含める。二つの部分を別々に検証するだけでは、元から同じBundleだったとは言えない。

鍵は本物。任務が違う

通信が途切れることを前提とするネットワークでは、Bundleが複数の中継ノードを渡り歩く。中継ノードも自分の鍵を持ち、ある区間では正当に保護を付け加える。しかし、元の送信者が保護した内容を中継ノードが差し替え、自分の鍵で新しい完全性ブロックを作ったらどうなるか。受信側が「正規の参加者の署名か」だけを調べれば合格し得る。正規の署名者が、別人の役を演じた事実が見えなくなる。

RFC 9172の8.2.2節は、この内部者による置換を説明している。元のBlock Integrity Block（BIB）を正規ノードが自分の鍵によるBIBと交換できる。BIBをさらにBlock Confidentiality Block（BCB）で保護する対策も挙げるが、受信側が外側のBCBを「どの正規発信元でもよい」と扱えば、別の正規ノードが内容ごと包み直せる。暗号の計算が間違っているのではない。計算結果に与えた意味が大きすぎる。

N. D. S. Gupthaaの草案は、受信側の規則を明文化する。対象ブロックに必要な安全サービスごとに、そのサービスを提供する権限のあるSecurity Sourceと鍵素材を受信側のローカル方針へ記録する。受け取ったBIBやBCBは、その記録された鍵で検証できた場合に限り、当該要件を満たす。別の中継ノードが有効な鍵を持っていても、ここでは代理人になれない。

IETF Datatracker上では第00版の個人草案で、RFCの流れにも入っておらず、IETFが承認した文書でもない。受信規則の提案であって、特定の運用網での導入報告ではない。

「信頼できるノード」という雑な役職

草案のR1は、必要なサービスと対象ブロックの組ごとに、期待する発信元と鍵を指定させる。R2は、他の発信元の有効な保護で代用することを禁じる。R3は該当する保護がなければ必要サービスを失敗と扱う。R4は権限の横滑りを止める。ゲートウェイが特定の目的で再保護を許されても、別の発信元の全ブロックに対する権限者にはならない。

ここで「信頼」という単語を細かく分解する必要がある。転送を任せること、ある区間の暗号化を任せること、元の発信元の完全性を証明させることは、それぞれ違う仕事だ。鍵を持つノードを全員「信頼済み」に分類するだけでは、職員名簿はできても決裁規程はできない。受信側が必要としているのは後者である。

受信した安全ブロックに書かれたSecurity Sourceも、権限の証明にはならない。草案はその値を信頼できない検索の手がかりと位置付ける。誰を名乗ったかを読み、その人物が当該サービスの予定された権限者かどうかを既存の方針で照合する。届いたブロック自身に審査規則を選ばせれば、審査は申請者の自己申告書になってしまう。

発信元ごとの鍵があることも前提だ。RFC 9172は、すべてのノードが同じ鍵を共有すると、正規の鍵保有者を互いに区別できず、鍵に関して特権的になると述べる。運用者が鍵の保管を一つに混ぜてしまった後で、受信側だけに細かな権限分離を命じても遅い。

本物二枚を重ねても、一枚の証書にはならない

もう一つの論点は、誰が署名したかより、何を一緒に署名したかだ。ペイロードを保護するBIBと、プライマリブロックを別に保護するBIBが、ともに同じ発信元の真正なものだったとする。それでも別々のBundleから取り出した二つかもしれない。二回の検証成功は、ペイロードとプライマリブロックの組み合わせを証明しない。

草案のR5は、ペイロード自身のBIBにプライマリブロックを完全性の対象として含めるよう求める。RFC 9173の3.3.3節でいう範囲フラグのbit 0がそれに当たり、パラメータを省いた場合の既定値7にも含まれる。プライマリブロックへ独立したBIBを追加しても、二つを一組にする証明は生まれない。RFC 9171が定めるBundleでは、プライマリブロックが識別と処理の情報を、ペイロードブロックがアプリケーションのデータを運ぶ。正しい相手と正しい内容を結び付けるには、両方を同じ保護計算の中で扱う必要がある。

緑の表示に必要な脚注

草案はTamarinによる形式モデルと設定検査器に言及し、成果物は今後公開予定で、現時点では請求に応じるとしている。公開本文からそのモデルや実運用の結果を独立に確認することはできない。受信設定と置換時の再現可能な記録が公開されれば、提案の運用上の効き方をさらに検証できる。

今ある問いは十分に具体的だ。どのサービスが必要で、どのブロックについて、どの発信元と鍵を期待し、実際のBIBはどこまでを一緒に保護したのか。画面に「署名有効」だけを表示するなら、その画面は暗号を褒めながら荷物の持ち主を見失う。

出典