要約

  • 個人草案Oblivious CoAPでは、転送するプロキシーは送信元を見られるが暗号化された内容を読めず、ゲートウェイは内容を読めるが送信元アドレスを受け取らない。
  • 草案の第7.1節はプロキシーなどが要求を容易に再送できると明記する。状態を変える処理では、受信側が最初の封入値と後続の保護された連番を使って重複を見分けられる。

手紙を開封しなくても配達は二度できる。28日付のOblivious CoAP草案は、暗号化と実行回数の違いをそこに置く。小型機器が送り主を宛先へ知らせずに問い合わせることはできる。中継者が同じ暗号文を再び送ることもできる。受信側にとって二通目は紙ではなく、再度動くかもしれない命令だ。

CoAPは制約のある機器の要求と応答に使われる。草案はDNS照会、匿名の診断送信、資源ディレクトリーへの問い合わせを例に挙げる。クライアントはHPKEでゲートウェイ向けに内容を暗号化し、CoAP転送プロキシーへ渡す。プロキシーは発信元アドレスを知るが内容を読めない。ゲートウェイは内容を解くが、プロキシーからアドレスを受け取らない。両者がログや運用主体を一つにすれば、この分担の意味も変わる。

構造はOblivious HTTPに近いが、草案は同じHPKE文脈で複数の関連要求を数えるCoAP固有の選択肢を置く。協力するゲートウェイが必要で、どのCoAPサービスにも後付けできる仕掛けではない。そして第7.1節は、中継プロキシーや外部の攻撃者が保護された要求を容易に再送できると明記する。

本当に安全な方法であり、サーバーが再処理しても安全だと確認できれば、重複を許容する道がある。状態を変える要求なら重複を検出して、不適切な再処理を止める。初回の要求ではHPKEの封入値enc、またはそのハッシュが識別材料になる。同じ暗号文脈を使う後続要求では、改ざんから守られたOCoAPのcountを、その文脈に結び付く再送判定窓と照合できる。保護されたEchoオプションも鮮度確認を強める。

つまり匿名化した宛先に、受け取った封筒の記憶が要る。診断報告が二度数えられれば集計は変わり、状態変更が二度走れば効果も繰り返され得る。草案は保存期間、容量、再起動後の復元を実測していない。どの処理を安全と分類し、重複の記録をいつまで持ち、失った場合にどうするかは、ゲートウェイとアプリケーションの運用判断だ。

IETFの登録情報では個人の標準化提案としてI-D Existsだ。まず暗号化した要求を一通送り、複製を送り、同じ会話に属する次の要求を送る。その途中でゲートウェイを再起動し、実行回数と残った判定材料を確かめる試験が必要だ。