私は25年間にわたりシステムを構築してきました。意図的に設計され、運用上もスリムで、重みを持つベクトルだけを持つものを作るのが好きです。
そのアプローチでは、ユーザーのデータを最小限に保管することが常に理にかなっていました。理由は明白なものを超えています。 彼らのデータの主権は重要です。 その下にはもっと単純なものがあります：物はあるべき場所にあるべきです。 私が構築するもののほとんどは処理であり、処理アーキテクチャは他の何かとして機能するべきではありません。 必要のないレコードを保持することは、何も得られないベクトルです。 それを最適化として扱い、コンプライアンス演習としてではなく扱うことが設計を正直に保ちます。そうしたシステムは、規制に対して自動的に良好な立場に立つ傾向があります。規制対象がほとんど残っていないからです。
したがって、Mary Camacho の発表が X のフィードに表示されたとき、私は彼女のアーキテクチャを自分のものと同じように読みました。 彼女はコアをクリエイティブ・コモンズライセンスの下で公開記録に公開し、エンジニアが再構築できる詳細レベルで公開しました。また、彼女はそれが立っている先行技術について率直に述べていました。
シーケンスを通じて、私はサーバー内に対立的なエンティティを配置し、彼が到達できるものを追跡しました。 彼はワーカーを上回ることができました。
後続のほとんどの作業は音声会話として行われました。30 音声メモを通じて、声に出して考え、異なる角度から懸念をテストし、持続するか崩壊するかまで続きました。

私が気づいたこと：デバイスはクレームレコードを書いた人に暗号化します

開示は操作順序を直接指定します。 ワーカーはジョブを主張し、キーを公開し、そして初めてデバイスが暗号化します：
  1. ワーカー → コーディネーション：ジョブをポーリングして主張する（書き込み一度、最初に勝つ）、ワーカーの公開鍵を公開する。
  2. デバイス ← コーディネーション：ポーリングし、ワーカーの公開鍵を取得し、共有秘密を導出し、ペイロードを暗号化する。
— §2.1、データフロー（ジョブごと）
その合意のデバイス側は同等の精度で指定されています：
デバイスはワーカーの公開鍵を学習すると、独自のX25519交換とワーカーの鍵に対するML-KEMカプセル化を実行し、独自の公開寄与（X25519公開鍵 ‖ ML-KEM暗号文）と共有秘密を生成します。
— §4.2、ワーカライフサイクルへのバインディング
学習時に。 19ページ全体で、ワーカーの一時公開鍵に署名はなく、証明書もなく、デバイスが評価する認証書もなく、事前共有秘密もありません。 欠如は意図的であり、強みとして提示されています：モデルは認証書、TPM引用、または測定起動アーティファクトなしで復号をゲートし、事前プロビジョニングされたワーカー秘密を保持しません。
したがってデバイスはクレームレコードにある公開鍵にペイロードを暗号化し、正当なワーカーの鍵を他の誰かの鍵と区別する手段はありません。 先にクレームを書ける者は、デバイスが暗号化する相手となり、信頼されたペイロードは彼らの手で復号されます。
Diagram source
flowchart TB
    subgraph BEFORE["以前：公開されたときの状態"]
        direction LR
        A2{「最初に主張するのは誰？」？} -->|実際のワーカー| A3["本物のキー"]
        A2 -->|他の書き手| A4["攻撃者キー"]
        A3 --> A5["デバイスがそれに暗号化する"]
        A4 --> A5
        A5 --> A6["キー保持者が読むことができる"]
    end
    subgraph AFTER["後：署名されたキー"]
        direction LR
        B2{「署名は有効？」？} -->|はい| B3["検証済みワーカーキー"]
        B2 -->|いいえ| B4["拒否、再試行"]
        B3 --> B5["本当のワーカーだけが読む"]
    end
    A6 ~~~ B2
重大度はモデルが持つものから来る。 このアーキテクチャは、人々が最も読まれたくないデータを正確に保持するために存在し、問題の難しい半分を解決する：完了したジョブは、オペレーターを含む誰にも復号できない。 ギャップは、デバイスが誰と通信しているかを確立しなければならない1ステップにある。

暗号化は安全で、導入は未認証である

攻撃者は何も壊さない。 X25519 と ML-KEM-768 は両方とも指定どおりに機能する。 攻撃者はキーを供給し、合意の正当な当事者になる。
これは未認証鍵合意であり、その失敗モードは分野で最も古い結果である。 単純なディフィー・ヘルマンは誰も認証せず、代わりに自分の公開鍵を置き換える当事者に落ちる。 キーカプセル化メカニズムはその性質を継承するため、RFC 9180 は受信者の公開鍵の真正性を自分自身の範囲外に置き、周囲のアプリケーションが証明書、キー・ディレクトリ、またはオフバンド検証を通じてそれを確立すると仮定している。 このモデルは周囲のアプリケーションであり、受信者キーを配布するために使用されるチャネルは自分自身の信頼モデルで不信任とラベル付けされたコンポーネントである。
開示は隣接攻撃を予測し、それを閉じる：
主張は一度書き込み/最初に勝つであり、後続のワーカーはジョブの鍵交換を乗っ取ることができません。
— §6, 参照実装
その推論は合理的であり、メカニズムは言ったとおりに機能する。 それは2つの対称ケースのうちの1つをカバーします。
脅威書き込み一度限りの主張で処理されます
2番目のワーカーが既存の主張を上書きしますはい — 書き込みは拒否されます
未承認の当事者が最初に主張を書き込みますいいえ — 最初の書き込みが勝ちます
First-wins はレースです。 ルールは勝者が仕事を保持することを保証し、勝者が誰であるかについては何も言いません。
もう1つの主張は引用する価値があります、発見がそれに反するためです：
中間者（ゲートウェイ、調整、ストレージ、モニター）は決してどちらかの秘密を導出するのに十分な鍵材料を保持しません。 調整またはストレージを侵害した攻撃者は、オープックなブロブと公開鍵のみを取得します。
— §4.3、独立した方向別キー
最初の文は正確です。 2番目は読み取る攻撃者を説明しています。 書き込む攻撃者は、デバイスがポーリングする前に主張レコードに選択された公開鍵を配置し、正当な秘密を導出する必要がなくなります、相手方になるよう手配できる当事者にとって。 そのレコードの内容を管理する者はペイロードを読むことができる者を管理し、調整層を機密性のための信頼できるコンポーネントにします — §3 が言う唯一のものは、デバイスとワーカー以外のコンポーネントが決して存在しないことです。
主張に対する正直な上限：これは今日、オープンインターネット上の誰もがこのデータを読むことができるという意味ではありません。 実際の展開では、主張を書き込む能力はクラウドネットワーキングと認証情報の背後にあり、開示はデバイス経路上の認証ゲートウェイを説明します。 正確な問題は、機密性が今やその周囲に依存していることです、同時にアーキテクチャの中心的な約束は、デバイスとワーカーの間のコンポーネントを信頼せずに保持されることです。

2つの設計特性が結果を複合します

結果は同じ対立者が仲介する2番目の合意の下でデバイスに戻り、したがって傍受されたジョブが完了し、ユーザー側からは普通に見えます。
耐久ジョブと結果台帳の意図的な欠如 — 同じ欠如が非保管を生み、規制表面を縮小する — は、調査者が後で再構築するために使用するほとんどを除去します。 調整記録は約1時間で期限切れになります。 通常の場合にデータを保護する特性は、対立的な場合に法医学記録を薄くします。

ギャップはモデルの最良判断によって投げかけられた影である

アーキテクチャは、オペレーターが正当に保持できるデータと、決して保持すべきでないデータを分離する。 連絡先データは人が誰であるかと連絡方法を示す。 信頼されたデータは彼らが自分自身について明かすものだ。 従来のシステムは両方を1つのデータベースに保存し、これはアカウントテーブルを誰かの私生活の記録に変える動きである。 構造的回答は1行である：連絡先を保持し、信頼されたものを保持できない。
中央オーケストレーターを削除することはそれを直接実現する。 ジョブをワーカーに割り当てるコンポーネントは必然的に誰が何をしているかを学び、その知識はモデルが保持を拒否する正確な資産である。 それを削除すると、通常ワーカーの身元を保証するコンポーネントも削除され、残ったすべてのワーカー認証ルートは独立して却下され、各々が擁護可能な理由を持つ。
結果は、保管について実際の厳密さで推論し、問題の形が認証である唯一のポイントで保管推論を適用する設計である。 信頼モデルは各コンポーネントが保持しているものを尋ね、正しく答えます。 そこに必要な質問は、各コンポーネントが何を 代替できる かです。 これらは2つの独立した信頼問題であり、どちらかを解決してももう一方が解決されたことはない。

ワーカーの一時公開鍵に署名を施すことでそれを閉じます

ワーカーは起動時に一時鍵ペアを生成し、現在と同じ方法で行います。 その鍵がクレームに公開される前に、長期オペレーター鍵で署名され、公開部はアプリケーションとともに配布されます。 デバイスは署名を検証し、署名されていないか無効な鍵を拒否します。 復旧はすでに定義されており、クライアント主導の再試行と新しいジョブおよび新しい鍵協議がモデルの標準的な失敗経路です。
決定的な特性は、署名鍵は何も復号しないことです。 オペレーターの署名鍵が破られた場合、将来のワーカーのなりすましが可能になりますが、完了したジョブを一つも読むことはできません。各ジョブ鍵はワーカーとともに破棄されるためです。 非保管、空の鍵ボールト、そして事後復号の不可能性はすべて完全に残ります。 これが設計の完了を意味します。
署名者は設計で除去されたオーケストレーターになることを避けます。 署名者は、オペレーターが起動したワーカーの一時公開鍵が属していることを証明するだけで十分で、どのジョブがそのワーカーに属するかを知る必要はありません。 既存のモニターは自然な場所です：すでにワーカーをプロビジョニングし、収穫し、ユーザーデータも鍵も保持せず、設計上ジョブをルーティングまたは割り当てません。
再送はチェックが必要です。ジョブ情報を知らない署名者は、署名をジョブ識別子に結び付けることができません。 攻撃者が正規の署名済みワーカー鍵を別のクレームレコードにコピーしても、対応する秘密鍵がないためペイロードは読めません。 結果は誰も処理できないジョブ、つまりサービス拒否であり、機密性は保たれます。
まだ三つの制限が残り、開示はそれらすべてを示します：ジョブ実行中にワーカーのメモリに平文が存在し、ジョブタイミングがメタデータを漏らし、鍵導出構造は著者によって改善が示唆されています。

アドバイザリー

この発見は、アーキテクチャがコミュニティに置かれたために存在します。 公開が独立した評価を可能にし、ここでギャップが表れたのはインシデントレポートではなく、公開された情報が原因です。 このシステムの独自バージョンも同じ問題を抱え、誰もそれを指摘できません。
貢献に感謝し、モデルは招かれた検証に値します。 中央の主張は正しく、私はより多くのシステムが取るべき形です。なぜなら、機密データを保持しないアーキテクチャは、保持するものよりも規制面での表面積が少ないからです。
推奨は狭いです：デバイスが暗号化する前にワーカーの一時公開鍵を認証します。 デバイスで検証された1つの署名は、モデルを採用する価値を生む何も費用をかけずに済みます。 上記は、30 ノート以上にわたる音声からテキストへの会話から出てきました。公開された開示と照合し、要約ではなく実際の情報を確認しました。 これらの発見が彼ら側で検証されれば、対処は簡単です。