Confiance
Ne faites pas confiance. Vérifiez.
Le Private Cloud d’Alice fonctionne sur l’infrastructure de calcul confidentiel de Venice : vos messages sont chiffrés sur votre appareil et ne sont déchiffrés qu’à l’intérieur d’un matériel confidentiel que l’app essaie de vérifier. Voici exactement ce qui se passe, ce que chaque partie peut voir et, honnêtement, ce qui est prouvé aujourd’hui et ce qui ne l’est pas encore.
Ce que « privé » veut dire
Votre message est chiffré sur votre appareil avant de partir. Il transite sous forme chiffrée par le proxy d’Alice et l’infrastructure de Venice, et n’est déchiffré qu’à l’intérieur d’une enclave matérielle (Intel TDX) qu’Alice essaie de vérifier. La réponse revient chiffrée et est déchiffrée sur votre appareil. Vous préférez que rien ne sorte ? Faites fonctionner Alice entièrement en Local.
Ce que chaque partie peut voir
| Ce qui quitte votre appareil | L’identifiant du modèle, les métadonnées réseau ordinaires (IP, minutage, tailles), et vos prompts et réponses, uniquement sous forme chiffrée. |
|---|---|
| Le proxy d’Alice (Cloudflare) | Le contenu chiffré, l’identifiant du modèle, les tailles et le minutage, et la clé Venice qu’il ajoute. Il ne peut pas déchiffrer, il ne détient aucune de vos clés, et n’enregistre jamais le corps des messages. |
| Venice, hors de l’enclave | Le contenu chiffré et les métadonnées, jamais votre texte en clair. |
| Phala / PCCS | Uniquement les éléments publics d’attestation (certificats, informations TCB). Aucun prompt, aucune réponse. |
| L’enclave (Intel TDX) | Le texte en clair, le seul endroit où le déchiffrement a lieu. L’attestation est notre élément de preuve sur ce qui y tourne. |
Échec fermé, aucun repli silencieux
Pour Private Cloud, chacun de ces cas est un refus, jamais un repli vers un modèle non chiffré :
Vous voyez un message clair, « La vérification de Private Cloud a échoué. Aucun message n’a été envoyé. » Local et l’IA personnalisée continuent de fonctionner.
État : ce qui est vérifié, ce qui ne l’est pas
Nous n’affirmerons pas plus que ce que nous pouvons prouver. Voici l’état honnête aujourd’hui.
| Chiffrement (AES-256-GCM · ECDH · HKDF) | Implémenté + vérifié, par des allers-retours avec la production |
|---|---|
| Déchiffrement en flux, échec fermé, aucun texte en clair affiché | Implémenté + vérifié |
| Nonce neuf à chaque envoi · anti-rejeu | Implémenté + vérifié |
| Vérification de la quote DCAP (signature + TCB) | Implémenté, une attestation réelle a renvoyé « UpToDate » |
| Politique TCB stricte + rejet du mode debug | Implémenté + vérifié |
| Liaison clé ↔ attestation | Implémenté + vérifié ; la version déployée attend la confirmation de Venice |
| Mécanisme d’épinglage des mesures | Implémenté + vérifié |
| Valeurs de référence des mesures | Bloqué de l’extérieur, nécessite des données de gouvernance de Venice / dstack |
| Attestation GPU NVIDIA | En attente, non implémenté ; échec fermé quand elle est exigée |
Pas prêt à afficher « E2EE vérifié » : l’épinglage des mesures n’est pas actif (pas encore de valeurs de référence) et l’attestation GPU n’est pas implémentée ; l’assurance atteignable est donc attested-unpinned.
Limites et hypothèses restantes
- Les valeurs de référence des mesures ne sont pas encore disponibles : l’épinglage n’est donc pas actif.
- L’attestation GPU NVIDIA n’est pas vérifiée.
- La vérification DCAP réduit, sans la supprimer, la confiance accordée à la disponibilité de Phala et aux racines d’Intel et de NVIDIA.
- Nous avons contacté Venice pour obtenir les valeurs de référence des mesures et la confirmation de liaison d’attestation mentionnée plus haut, et nous attendons leur réponse.
Le code source est public sous licence AGPL, ce qui permet à chacun de vérifier ces affirmations de façon indépendante : lire le code.