J’ai regardé aujourd’hui la documentation sur l’inférence privée, et l’architecture à deux sauts m’a fait perdre du temps plus longtemps que prévu.
Quand vous envoyez un prompt via l’inférence privée d’OpenGradient, deux entités totalement distinctes prennent en charge différentes parties de votre requête. Le relais voit votre adresse IP, mais ne reçoit qu’un bloc chiffré qu’il ne peut pas lire. L’enclave déchiffre votre prompt, mais ne voit que l’adresse IP du relais, jamais la vôtre. Aucune des deux parties, prise seule, ne peut relier qui vous êtes à ce que vous avez dit.
Cette séparation semble simple. L’implémentation en dessous ne l’est pas. Votre prompt est scellé avec HPKE sur votre appareil à l’aide d’une clé publique liée à une version d’enclave attéstée spécifique. Seul ce matériel d’enclave détient la clé privée, et celle-ci ne quitte jamais la mémoire de l’enclave. Le relais transmet des octets opaques qu’il ne peut pas lire. L’enclave déchiffre, exécute l’inférence, signe la réponse à l’intérieur de la limite matérielle, puis la renvoie sous forme scellée.
Ce qui a réellement changé ma façon de penser, c’est l’étape d’attestation avant que tout cela ne commence. Avant que votre appareil ne chiffre quoi que ce soit, il récupère la clé publique de l’enclave et la vérifie à l’aide d’un document d’attestation AWS Nitro, puis compare cette attestation au registre TEE on-chain. Vous ne faites pas confiance au fait que cette clé appartient à une enclave légitime. Vous la vérifiez cryptographiquement avant qu’un seul octet de votre prompt ne soit chiffré.
Le point sur lequel il vaut la peine de s’attarder est ce que la documentation indique explicitement comme étant hors périmètre. Le timing et le volume du trafic restent visibles pour un observateur réseau qui surveille les deux sauts. Le contenu et l’identité sont protégés. Les métadonnées concernant quand et combien vous envoyez ne le sont pas. Pour la plupart des applications, cette concession est acceptable. Pour des déploiements réellement sensibles, c’est l’écart à planifier.
Si votre prompt est invisible mais que le schéma de votre trafic ne l’est pas, quelle quantité de confidentialité la protection du contenu apporte-t-elle réellement dans la pratique ?
@OpenGradient
#opg $OPG
Quand vous envoyez un prompt via l’inférence privée d’OpenGradient, deux entités totalement distinctes prennent en charge différentes parties de votre requête. Le relais voit votre adresse IP, mais ne reçoit qu’un bloc chiffré qu’il ne peut pas lire. L’enclave déchiffre votre prompt, mais ne voit que l’adresse IP du relais, jamais la vôtre. Aucune des deux parties, prise seule, ne peut relier qui vous êtes à ce que vous avez dit.
Cette séparation semble simple. L’implémentation en dessous ne l’est pas. Votre prompt est scellé avec HPKE sur votre appareil à l’aide d’une clé publique liée à une version d’enclave attéstée spécifique. Seul ce matériel d’enclave détient la clé privée, et celle-ci ne quitte jamais la mémoire de l’enclave. Le relais transmet des octets opaques qu’il ne peut pas lire. L’enclave déchiffre, exécute l’inférence, signe la réponse à l’intérieur de la limite matérielle, puis la renvoie sous forme scellée.
Ce qui a réellement changé ma façon de penser, c’est l’étape d’attestation avant que tout cela ne commence. Avant que votre appareil ne chiffre quoi que ce soit, il récupère la clé publique de l’enclave et la vérifie à l’aide d’un document d’attestation AWS Nitro, puis compare cette attestation au registre TEE on-chain. Vous ne faites pas confiance au fait que cette clé appartient à une enclave légitime. Vous la vérifiez cryptographiquement avant qu’un seul octet de votre prompt ne soit chiffré.
Le point sur lequel il vaut la peine de s’attarder est ce que la documentation indique explicitement comme étant hors périmètre. Le timing et le volume du trafic restent visibles pour un observateur réseau qui surveille les deux sauts. Le contenu et l’identité sont protégés. Les métadonnées concernant quand et combien vous envoyez ne le sont pas. Pour la plupart des applications, cette concession est acceptable. Pour des déploiements réellement sensibles, c’est l’écart à planifier.
Si votre prompt est invisible mais que le schéma de votre trafic ne l’est pas, quelle quantité de confidentialité la protection du contenu apporte-t-elle réellement dans la pratique ?
@OpenGradient
#opg $OPG
strong privacy 🔏
0%
partial privacy 🔏
0%
false privacy 🔏
0%
0 Votes • Vote fermé