Vérifié dans votre navigateur.
Scellé pour l’enclave.

En bref

Undergrove exécute des modèles à poids ouverts dans des enclaves matérielles opérées par Tinfoil. Une partie de ce que cela implique, votre navigateur la vérifie lui-même ; une partie relève de la déclaration de Tinfoil ; et une partie repose sur nous. Voici ce qui relève de quoi.

Rien de tout cela n’a encore été évalué de façon indépendante.

01 · Attestation

La puce se porte garante du code.

Une enclave matérielle est une partie d’un serveur dans laquelle son propre hôte ne peut pas regarder : le processeur chiffre la mémoire de l’enclave et en tient le logiciel de l’hôte à l’écart. À lui seul, ce ne serait qu’une promesse. Ce qui le rend vérifiable, c’est l’attestation. Au démarrage de l’enclave, le processeur mesure le code chargé et signe un rapport de cette mesure avec une clé dont le fabricant de la puce se porte garant. Le rapport nomme aussi la clé publique avec laquelle l’enclave déchiffrera.

Avant votre premier message, l’espace de travail récupère ce rapport pour l’enclave routeur de Tinfoil, en passant par notre serveur, et y applique le vérificateur open source de Tinfoil dans votre navigateur. Le faire passer par nous ne change rien : nous ne pouvons pas falsifier la signature de la puce, et un rapport qui ne se vérifie pas arrête tout.

Les contrôles du vérificateur, dans l’ordre

1. Trouver la version que Tinfoil a publiée pour ce code.
2. Vérifier le rapport d’attestation matérielle de l’enclave avec les clés de signature du fabricant de la puce.
3. Vérifier l’enregistrement de build signé de la version (Sigstore, depuis GitHub).
4. Comparer : le code mesuré dans l’enclave doit être exactement cette version.
5. Vérifier que la clé de chiffrement est celle que nomme l’attestation de l’enclave.

Nous ne pouvons pas falsifier la signature de la puce, et un rapport qui ne se vérifie pas arrête tout.

Un rapport vérifié est réutilisé jusqu’à dix minutes, dans cet onglet ou un autre onglet de ce site, et seulement s’il est exactement le même, d’après son SHA-256. L’espace de travail montre chaque contrôle sous Vérifié, et la page d’architecture montre le code qui l’exécute.

02 · Scellement

Seule l’enclave peut l’ouvrir.

Une fois l’enclave vérifiée, chaque requête réelle est scellée dans votre onglet avant d’en sortir. Son corps est chiffré avec EHBP, le protocole de Tinfoil pour chiffrer les corps HTTP, avec la clé nommée par l’attestation. EHBP utilise HPKE, une norme pour chiffrer à destination de la clé publique de quelqu’un : votre onglet crée une nouvelle paire de clés pour la requête, la combine avec la clé de l’enclave en un secret partagé, et chiffre avec AES-256-GCM.

La nouvelle moitié publique voyage à côté du texte chiffré, comme clé encapsulée. Seule la clé privée de l’enclave, qui ne quitte jamais l’enclave, peut la retransformer en secret. La réponse revient de la même façon, en trames scellées que votre onglet ouvre au fil de leur arrivée.

03 · Le relais

Des octets qu’il ne peut pas lire.

Les requêtes scellées passent par notre relais, une fonction sur Vercel, plutôt que d’aller directement chez Tinfoil. Il vérifie qui fait la demande et que son quota le permet, et place la clé Tinfoil d’Undergrove sur la requête, pour que vous n’ayez pas besoin d’un compte chez Tinfoil. Il refuse tout ce qui n’est pas adressé à l’un des hôtes de Tinfoil ou ne porte pas de clé encapsulée.

Il ne peut pas compter vos mots : il estime donc le coût de chaque requête à partir de la taille du texte chiffré, en arrondissant vers le haut. Il ne garde aucune copie, et ses journaux ne contiennent que des noms de routes, des codes d’état et des durées.

04 · Reçus

Deux enclaves, et un reçu pour chaque réponse.

L’enclave routeur vérifiée par votre navigateur n’exécute pas le modèle. Elle ouvre votre requête et la transmet à l’enclave où le modèle tourne avec ses GPU, que le routeur vérifie lui-même, selon son code publié, et nomme dans un en-tête de réponse.

Votre navigateur vérifie ensuite aussi cette enclave nommée, avec le même vérificateur, par rapport au dépôt que le routeur de Tinfoil fixe pour ce modèle. Ce qu’il trouve est conservé avec la réponse sous forme de reçu : l’enclave, le code mesuré dedans, la version correspondante et la clé avec laquelle la requête a été scellée. Un reçu est l’enregistrement propre de votre navigateur, signé ni par nous ni par Tinfoil ; l’attestation qui le fonde est signée par AMD et GitHub, donc chacun peut la vérifier à nouveau.

05 · L’API développeurs

Un autre chemin, dit franchement.

Le code qui appelle l’API développeurs envoie sa requête en HTTPS à notre passerelle, qui la lit : pour la vérifier, appliquer les limites et exécuter des outils. Elle la lit en mémoire et ne la stocke ni ne la journalise jamais. La passerelle fait ensuite ce que fait votre navigateur dans l’espace de travail : elle vérifie l’enclave avec le SDK de Tinfoil et scelle la requête pour elle.

Sur ce chemin, vous nous confiez donc la requête tant que la passerelle la détient. Ce que vous pouvez encore vérifier, c’est l’enclave : chaque réponse de la route Tinfoil porte des en-têtes qui nomment le paquet d’attestation vérifié par la passerelle, pour que vous le vérifiiez à nouveau. La documentation développeurs explique comment.

06 · Cette page

Vérifier le code qui vérifie.

Tout ce qui précède tourne dans du code que ce site envoie à votre navigateur, donc ce code compte aussi. Chaque build écrit un manifeste : le SHA-256 de chaque fichier servi par le site, et le commit dont il est issu.

Une page ne peut pas entièrement se porter garante d’elle-même : un contrôle qui s’exécute dans la page n’est honnête que si la page l’est. Le contrôle le plus solide se passe entièrement de nous : refaites vous-même le build du commit dans l’environnement figé et comparez les manifestes.

07 · Limites

Ce que cela ne prouve pas.

• Les déclarations de Tinfoil restent celles de Tinfoil. Qu’il ne peut pas accéder à ses enclaves, que rien de ce qu’elles contiennent ne subsiste entre deux redémarrages et que ses GPU fonctionnent en mode informatique confidentielle, c’est ce que dit Tinfoil. Votre navigateur vérifie que le matériel est authentique et exécute le code publié.
• Le matériel fait partie de ce à quoi vous faites confiance. La protection vaut ce que valent les processeurs, leur firmware et les clés des fabricants de puces, et des vulnérabilités d’enclaves matérielles ont déjà été publiées.
• Une étape repose sur du code publié. Que votre requête soit passée du routeur à l’enclave du modèle repose sur le code publié du routeur. Votre navigateur ne peut vérifier l’enclave du modèle que sur AMD SEV-SNP ; sur Intel TDX, elle est notée comme non vérifiée.
• Le relais voit l’extérieur. Votre compte, votre adresse IP, les tailles, les heures et le modèle qui a répondu.
• Publié n’est pas synonyme de relu. Le vérificateur montre quel code s’exécute, pas que ce code est sans défaut.
• Pas encore d’évaluation indépendante. Aucun auditeur n’a examiné cette conception ni son code jusqu’ici.

Pour savoir qui pourrait voir quoi, observateur par observateur, lisez le modèle de menace.

08 · Aller plus loin

Voir chaque partie à l’œuvre.

• ArchitectureLes quatre étapes d’un message, ce que chacune voit, et le code qui le fait.
• Scellez-le vous-mêmeTapez un message et regardez-le se faire sceller pour l’enclave, étape par étape.
• Essayez de le déchiffrerUne requête chiffrée, octet par octet, telle que notre relais l’a vue.
• Modèle de menacesQui pourrait voir quoi : notre hébergeur, nous, Tinfoil, le réseau, une décision de justice.
• Vérifier cette pageCalculer l’empreinte du code chargé par cette page et la comparer avec le build.
• TransparenceLe nombre de requêtes chiffrées et de vérifications d’enclave, et le commit en production.