ニュートンのプライバシーレイヤーは、正確なセキュリティ主張をします。つまり、個人データを暗号化してアップロードすると、暗号文は暗号学的に特定のポリシーと特定のチェーンに紐づけられる、ということです。

その同じ暗号化された封筒を別の場所でリプレイしようとしても――別のポリシー、別のチェーン――認証チェックは最初から完全に失敗します。

復号は拒否されます。"紐づけられている"範囲が何をカバーしているのかを正確に見たかったし、同じくらい重要なのは、何をカバーしていないのかもです。

 

こちらが実際の式です。

暗号化に付加される追加認証データは、ちょうど2つの入力から計算されます。ポリシー・クライアントとチェーンIDで、それらを一緒にハッシュします。

そのハッシュは、暗号文そのものと並んで、暗号化アルゴリズムが認証する対象の一部になります。

どちらかの入力が変われば——別のポリシー、別のチェーン——認証タグ全体が壊れて、アルゴリズムは復号を拒否します。

それは強力で、範囲がきちんと絞られた保証です。そして、正当な暗号化ペイロードを持ち出して、本来意図されていない文脈で使い回そうとする相手に対して必要になるであろう種類の防御そのものです。

 

 

しかし、この暗号文を運ぶアップロード呼び出しは、暗号文と、その2つのバインドされた値だけを運ぶわけではありません。

それはまた、タイム・トゥ・リブ(TTL)も運びます。これは、このデータ片が期限切れになる前に、どれくらい有効で、またどれくらい再取得可能であることを意図されているかを決める値です。

そして、実際に認証データの式に何が入るのか確認したところ、TTLはそこに含まれていません。

式はちょうど2つのことを扱っています:ポリシークライアント、チェーンID。ほかは何もありません。

 

それは実際の違いであって、単なる技術的な話ではありません。認証されたフィールドとは、改ざんすると暗号学的な証明が破られて、そうした改ざんが自動的に検知されるものです。

未認証のフィールドとは、暗号化そのものがそれを監視していないため、システムが表明されたとおりに単純に信頼するものです。

ポリシークライアントとチェーンIDは、最初のカテゴリに入ります。

ドキュメントに基づくと、TTLは2つ目にあります。

 

そこで出てくるのは、具体的で検証可能な問いです。つまり、このアップロード要求を傍受または再送できる人が、TTLだけを変更し——暗号文、ポリシークライアント、チェーンIDは一切そのままにした場合——認証チェックはそれに気付くのでしょうか?

記載どおりの式に基づけば、そうなるはずがありません。

暗号文はそのまま、きれいに復号できるでしょう。TTLの操作に関して、アルゴリズムが実際にチェックしている2つの値には何も影響しないためです。

データは、元の送信者が暗号化した内容そのもののままです。変わるのは、その“保管可能期間”だけで、静かに変わってしまうにすぎません。

 

それは、最初に見える以上に重要です。なぜならTTLは単なる見た目のメタデータではなく、セキュリティ制御そのものだからです。

おそらく、それが、機微で暗号化されたデータが、システムがなおも処理し続け、なおも取得し続け、なおも“現在のもの”として扱い続けることができる期間を制限しているのでしょう。

TTLを短くすると、正当なデータが早期に期限切れになり、それに依存するワークフローが静かに失敗する可能性があります。

長くしておけば、元の当事者が重要だと意図した時点を過ぎても、機微データを生きた状態で保持し、適切に再取得できるようになります。

どちらも暗号化を破る必要はありません。

どちらも、システムが実行すると文書で明記されている唯一の完全性チェックには引っかかりません。

 

私は、自分が主張していないことを正確に示したいのです。

このギャップがエンドツーエンドで本当に悪用可能かどうかは分かりません——それは、例えば、ゲートウェイがアップロード時点でTTLをオンチェーンに独立してコミットし、その後は変更できない形になっているか、あるいはアップロード要求自体が、改ざんを到達以前の段階で捕捉できる独自のトランスポート層の完全性保護を備えたチャネルで送られるか、あるいはTTLがそもそもセキュリティ上重要というより助言的に扱われているのか、といった、ドキュメントがカバーしていない要素に依存します。

それらのどれもが、ギャップを完全に塞いでしまう可能性があります。そして、それらはいずれもAADの式自体には現れません。なぜなら、それらはその上に重ねられた防御であって、その中身ではないからです。

 

つまり未解決の問いは、厳密に言うとこうです。TTLの値は、アップロード時点で不変で検証可能な形で、どこかにコミットされているのでしょうか——オンチェーン、あるいは別の何らかの認証された構造の中に——それとも、RPC呼び出しのパラメータとして、未認証の要求フィールドが信頼されるのと同じやり方で、そのまま額面どおりに受け入れられるだけなのでしょうか?

暗号化それ自体が何を守るのかについて、ドキュメントは正確です。

その一方で、その保護がどれくらいの間“持つべきか”を決める、1回限りの時間に結び付いた値を何が保護しているのかについては、何も言っていません。

@NewtonProtocol #Newt $NEWT $SKL $B