Habe heute die privaten Inferenz-Dokumente geprüft, und die Two-Hop-Architektur hat mich länger aufgehalten als erwartet.
Wenn du einen Prompt über die private Inferenz von OpenGradient sendest, behandeln zwei völlig getrennte Entitäten unterschiedliche Teile deiner Anfrage. Der Relay sieht deine IP-Adresse, erhält aber nur einen verschlüsselten Blob, den er nicht lesen kann. Das Enklave-Programm entschlüsselt deinen Prompt, sieht dabei aber nur die IP des Relays, nie deine. Keine der beiden Parteien kann allein verknüpfen, wer du bist, mit dem, was du gesagt hast.
Diese Trennung klingt einfach. Die Implementierung darunter ist es nicht. Dein Prompt wird auf deinem Gerät mit einer öffentlichen Taste (Public Key) versiegelt, die an eine bestimmte attestierte Enklaven-Implementierung gebunden ist. Nur diese Enklave- Hardware hält den privaten Schlüssel, und er verlässt nie den Enklave-Speicher. Der Relay leitet inhaltslose Bytes weiter, die er nicht lesen kann. Die Enklave entschlüsselt, führt die Inferenz aus, signiert die Antwort innerhalb der Hardware-Grenze und sendet sie dann wieder versiegelt zurück.
Was meine Denkweise tatsächlich verschoben hat, war der Attestation-Schritt, bevor überhaupt irgendetwas davon passiert. Bevor dein Gerät irgendetwas verschlüsselt, ruft es den öffentlichen Schlüssel der Enklave ab und prüft ihn anhand eines AWS-Nitro-Attestation-Dokuments. Anschließend vergleicht es diese Attestation mit dem On-Chain-TEE-Registry. Du vertraust nicht darauf, dass der Schlüssel zu einer legitimen Enklave gehört. Du verifizierst ihn kryptografisch, bevor auch nur ein einzelnes Byte deines Prompts verschlüsselt wird.
Der Punkt, der es wert ist, länger zu bedenken, ist, was die Dokumente ausdrücklich als nicht im Umfang (out of scope) markieren. Zeitpunkt des Datenverkehrs und Volumen sind weiterhin für einen Netzwerbbeobachter sichtbar, der beide Hops überwacht. Inhalt und Identität sind geschützt. Metadaten darüber, wann und wie viel du sendest, nicht. Für die meisten Anwendungen ist dieses Trade-off in Ordnung. Für wirklich sensible Deployments ist es die Lücke, die man einplanen muss.
Wenn dein Prompt unsichtbar ist, aber das Muster deines Datenverkehrs nicht: Wie viel Privatsphäre liefert der Schutz des Inhalts in der Praxis tatsächlich?
@OpenGradient
#opg $OPG
Wenn du einen Prompt über die private Inferenz von OpenGradient sendest, behandeln zwei völlig getrennte Entitäten unterschiedliche Teile deiner Anfrage. Der Relay sieht deine IP-Adresse, erhält aber nur einen verschlüsselten Blob, den er nicht lesen kann. Das Enklave-Programm entschlüsselt deinen Prompt, sieht dabei aber nur die IP des Relays, nie deine. Keine der beiden Parteien kann allein verknüpfen, wer du bist, mit dem, was du gesagt hast.
Diese Trennung klingt einfach. Die Implementierung darunter ist es nicht. Dein Prompt wird auf deinem Gerät mit einer öffentlichen Taste (Public Key) versiegelt, die an eine bestimmte attestierte Enklaven-Implementierung gebunden ist. Nur diese Enklave- Hardware hält den privaten Schlüssel, und er verlässt nie den Enklave-Speicher. Der Relay leitet inhaltslose Bytes weiter, die er nicht lesen kann. Die Enklave entschlüsselt, führt die Inferenz aus, signiert die Antwort innerhalb der Hardware-Grenze und sendet sie dann wieder versiegelt zurück.
Was meine Denkweise tatsächlich verschoben hat, war der Attestation-Schritt, bevor überhaupt irgendetwas davon passiert. Bevor dein Gerät irgendetwas verschlüsselt, ruft es den öffentlichen Schlüssel der Enklave ab und prüft ihn anhand eines AWS-Nitro-Attestation-Dokuments. Anschließend vergleicht es diese Attestation mit dem On-Chain-TEE-Registry. Du vertraust nicht darauf, dass der Schlüssel zu einer legitimen Enklave gehört. Du verifizierst ihn kryptografisch, bevor auch nur ein einzelnes Byte deines Prompts verschlüsselt wird.
Der Punkt, der es wert ist, länger zu bedenken, ist, was die Dokumente ausdrücklich als nicht im Umfang (out of scope) markieren. Zeitpunkt des Datenverkehrs und Volumen sind weiterhin für einen Netzwerbbeobachter sichtbar, der beide Hops überwacht. Inhalt und Identität sind geschützt. Metadaten darüber, wann und wie viel du sendest, nicht. Für die meisten Anwendungen ist dieses Trade-off in Ordnung. Für wirklich sensible Deployments ist es die Lücke, die man einplanen muss.
Wenn dein Prompt unsichtbar ist, aber das Muster deines Datenverkehrs nicht: Wie viel Privatsphäre liefert der Schutz des Inhalts in der Praxis tatsächlich?
@OpenGradient
#opg $OPG
strong privacy 🔏
0%
partial privacy 🔏
0%
false privacy 🔏
0%
0 Stimmen • Abstimmung beendet