アドバイジング：PIE非保管コンピュートモデルにおける重要な発見
モデルはジョブが終了するとオペレーターが何も復号できないようにします。 デバイスは未検証の公開鍵に暗号化し続けます。公開鍵はモデルが不信任と指定した1つのコンポーネントによって公開されます。
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
私は25年間にわたりシステムを構築してきました。意図的に設計され、運用上もスリムで、重みを持つベクトルだけを持つものを作るのが好きです。そのアプローチでは、ユーザーのデータを最小限に保管することが常に理にかなっていました。理由は明白なものを超えています。 彼らのデータの主権は重要です。 その下にはもっと単純なものがあります：物はあるべき場所にあるべきです。 私が構築するもののほとんどは処理であり、処理アーキテクチャは他の何かとして機能するべきではありません。 必要のないレコードを保持することは、何も得られないベクトルです。 それを最適化として扱い、コンプライアンス演習としてではなく扱うことが設計を正直に保ちます。そうしたシステムは、規制に対して自動的に良好な立場に立つ傾向があります。規制対象がほとんど残っていないからです。したがって、Mary Camacho の発表が X のフィードに表示されたとき、私は彼女のアーキテクチャを自分のものと同じように読みました。 彼女はコアをクリエイティブ・コモンズライセンスの下で公開記録に公開し、エンジニアが再構築できる詳細レベルで公開しました。また、彼女はそれが立っている先行技術について率直に述べていました。シーケンスを通じて、私はサーバー内に対立的なエンティティを配置し、彼が到達できるものを追跡しました。 彼はワーカーを上回ることができました。後続のほとんどの作業は音声会話として行われました。30 音声メモを通じて、声に出して考え、異なる角度から懸念をテストし、持続するか崩壊するかまで続きました。私が気づいたこと：デバイスはクレームレコードを書いた人に暗号化します#
開示は操作順序を直接指定します。 ワーカーはジョブを主張し、キーを公開し、そして初めてデバイスが暗号化します：その合意のデバイス側は同等の精度で指定されています：— §2.1、データフロー（ジョブごと）
- ワーカー → コーディネーション：ジョブをポーリングして主張する（書き込み一度、最初に勝つ）、ワーカーの公開鍵を公開する。
- デバイス ← コーディネーション：ポーリングし、ワーカーの公開鍵を取得し、共有秘密を導出し、ペイロードを暗号化する。
デバイスはワーカーの公開鍵を学習すると、独自のX25519交換とワーカーの鍵に対するML-KEMカプセル化を実行し、独自の公開寄与（X25519公開鍵 ‖ ML-KEM暗号文）と共有秘密を生成します。— §4.2、ワーカライフサイクルへのバインディング学習時に。 19ページ全体で、ワーカーの一時公開鍵に署名はなく、証明書もなく、デバイスが評価する認証書もなく、事前共有秘密もありません。 欠如は意図的であり、強みとして提示されています：モデルは認証書、TPM引用、または測定起動アーティファクトなしで復号をゲートし、事前プロビジョニングされたワーカー秘密を保持しません。したがってデバイスはクレームレコードにある公開鍵にペイロードを暗号化し、正当なワーカーの鍵を他の誰かの鍵と区別する手段はありません。 先にクレームを書ける者は、デバイスが暗号化する相手となり、信頼されたペイロードは彼らの手で復号されます。
flowchart TB
subgraph BEFORE["以前：公開されたときの状態"]
direction TB
A2{「最初に主張するのは誰？」？} -->|実際のワーカー| A3["本物のキー"]
A2 -->|他の書き手| A4["攻撃者キー"]
A3 --> A5["デバイスがそれに暗号化する"]
A4 --> A5
A5 --> A6["キー保持者が読むことができる"]
end
subgraph AFTER["後：署名されたキー"]
direction TB
B2{「署名は有効？」？} -->|はい| B3["検証済みワーカーキー"]
B2 -->|いいえ| B4["拒否、再試行"]
B3 --> B5["本当のワーカーだけが読む"]
end
A6 ~~~ B2Copy source暗号化は安全で、導入は未認証である#
攻撃者は何も壊さない。 X25519 と ML-KEM-768 は両方とも指定どおりに機能する。 攻撃者はキーを供給し、合意の正当な当事者になる。これは未認証鍵合意であり、その失敗モードは分野で最も古い結果である。 単純なディフィー・ヘルマンは誰も認証せず、代わりに自分の公開鍵を置き換える当事者に落ちる。 キーカプセル化メカニズムはその性質を継承するため、RFC 9180 は受信者の公開鍵の真正性を自分自身の範囲外に置き、周囲のアプリケーションが証明書、キー・ディレクトリ、またはオフバンド検証を通じてそれを確立すると仮定している。 このモデルは周囲のアプリケーションであり、受信者キーを配布するために使用されるチャネルは自分自身の信頼モデルで不信任とラベル付けされたコンポーネントである。開示は隣接攻撃を予測し、それを閉じる：主張は一度書き込み/最初に勝つであり、後続のワーカーはジョブの鍵交換を乗っ取ることができません。— §6, 参照実装その推論は合理的であり、メカニズムは言ったとおりに機能する。 それは2つの対称ケースのうちの1つをカバーします。
| 脅威 | 書き込み一度限りの主張で処理されます |
|---|---|
| 2番目のワーカーが既存の主張を上書きします | はい — 書き込みは拒否されます |
| 未承認の当事者が最初に主張を書き込みます | いいえ — 最初の書き込みが勝ちます |
中間者（ゲートウェイ、調整、ストレージ、モニター）は決してどちらかの秘密を導出するのに十分な鍵材料を保持しません。 調整またはストレージを侵害した攻撃者は、オープックなブロブと公開鍵のみを取得します。— §4.3、独立した方向別キー最初の文は正確です。 2番目は読み取る攻撃者を説明しています。 書き込む攻撃者は、デバイスがポーリングする前に主張レコードに選択された公開鍵を配置し、正当な秘密を導出する必要がなくなります、相手方になるよう手配できる当事者にとって。 そのレコードの内容を管理する者はペイロードを読むことができる者を管理し、調整層を機密性のための信頼できるコンポーネントにします — §3 が言う唯一のものは、デバイスとワーカー以外のコンポーネントが決して存在しないことです。主張に対する正直な上限：これは今日、オープンインターネット上の誰もがこのデータを読むことができるという意味ではありません。 実際の展開では、主張を書き込む能力はクラウドネットワーキングと認証情報の背後にあり、開示はデバイス経路上の認証ゲートウェイを説明します。 正確な問題は、機密性が今やその周囲に依存していることです、同時にアーキテクチャの中心的な約束は、デバイスとワーカーの間のコンポーネントを信頼せずに保持されることです。