Infrastructure de portefeuille et modèle de sécurité
Contexte du secteur
Les systèmes de portefeuille reposent généralement sur une ou plusieurs méthodes cryptographiques fondamentales pour protéger les clés privées. Comprendre ces approches donne le contexte du modèle de sécurité décrit dans ce document.
Shamir's Secret Sharing (SSS)
SSS divise une clé privée en plusieurs parts, en exigeant un seuil minimal pour reconstruire l’original. Il assure une confidentialité parfaite — tout nombre de parts inférieur au seuil ne révèle rien sur la clé. SSS est mature, bien outillé et rapide (signature en 20–40 ms). Le compromis est que la clé privée doit être entièrement réassemblée pour signer, ce qui crée un point de défaillance unique au moment de la reconstitution.
Threshold Signature Schemes (TSS)
TSS (souvent appelé MPC) permet à plusieurs parties de produire conjointement une signature sans jamais réassembler la clé privée. Cela supprime le risque de reconstitution de SSS. Le compromis est l’immaturité — le premier protocole ECDSA efficace à deux parties n’est apparu qu’en 2017 — et les performances : chaque signature implique des allers-retours réseau, introduisant une latence pouvant atteindre plusieurs secondes.
Trusted Execution Environments (TEE)
Les TEE exécutent des opérations cryptographiques dans des enclaves matérielles, garantissant que le matériel de clé n’est jamais exposé et que seul le code autorisé s’exécute. Les clients peuvent vérifier les opérations via des attestations. Les TEE passent bien à l’échelle et évitent la latence des allers-retours du TSS, mais leur sécurité dépend de l’intégrité de l’enclave, qui a historiquement été vulnérable aux attaques par canaux auxiliaires.
WebAuthn PRF Extension
L’extension WebAuthn PRF (Pseudo-Random Function) dérive un secret déterministe à partir du matériel passkey de l’utilisateur — Secure Enclave sur les appareils Apple, TPM sur Windows, Titan chip sur Android. Ce secret est lié à l’appareil et à la biométrie ou au PIN de l’utilisateur, calculé sur l’appareil lors de l’authentification, et jamais transmis. Elle permet une catégorie de conceptions de portefeuille où le matériel de clé peut être chiffré avec un secret qu’aucun serveur n’a jamais vu.
Protection des clés à trois parties
Vue d’ensemble
Les clés privées dans ce système ne sont jamais stockées entières — ni sur les appareils des utilisateurs, ni sur nos serveurs, nulle part. À la place, le matériel de clé est réparti cryptographiquement entre trois parties indépendantes selon un schéma de partage de secret 3-sur-3. Les trois parties doivent coopérer pour reconstruire une clé. Moins de trois ne révèle mathématiquement aucune information sur la clé privée.
Il s’agit d’un modèle hybride : il combine le chiffrement côté client basé sur la passkey (PRF-as-KEK), le partage de secret et une enclave serveur isolée en une seule architecture. La construction obtenue atteint la même garantie de sécurité informationnelle que le partage de secret de Shamir — aucun sous-ensemble de parties sous le seuil n’obtient d’information sur la clé — tout en liant une part au matériel d’authentification physique de l’utilisateur, de sorte qu’aucun compromis côté serveur seul ne peut reconstruire la clé.
C’est le modèle de sécurité par défaut pour tous les appareils modernes (tous les navigateurs majeurs sur iOS, macOS, Android et Windows).
Les trois parties
Partie 1 — L’authentificateur de l’utilisateur
Le matériel passkey de l’utilisateur calcule un secret déterministe lié à cet appareil et à la biométrie ou au PIN de l’utilisateur. Cette sortie — appelée une sortie PRF — est produite sur l’appareil lors de l’authentification et n’est jamais transmise nulle part. Elle n’est pas stockée. Elle n’est pas journalisée. Elle n’existe en mémoire que pendant la durée de l’opération de signature.
Ce secret est la contribution de l’utilisateur à la reconstruction de la clé. Sans lui, les deux autres parties ne détiennent rien permettant de produire une clé privée utilisable.
Partie 2 — L’API
L’API stocke une copie chiffrée du matériel de clé de l’utilisateur. Elle est chiffrée avec le secret dérivé par PRF de l’utilisateur, que l’API n’a jamais vu. L’API contrôle l’accès — elle ne libère ce contenu chiffré que pour une requête présentant une assertion WebAuthn valide signée par la passkey enregistrée de l’utilisateur. Elle ne peut toutefois pas déchiffrer le contenu elle-même.
L’API agit comme un mécanisme de livraison authentifié, pas comme un dépositaire de clés.
Partie 3 — L’enclave crypto
Un système séparé et isolé — fonctionnant indépendamment de l’API avec ses propres clés de chiffrement et son infrastructure — détient la part de clé côté serveur. Cette part est chiffrée au repos avec un secret connu uniquement de l’enclave. L’enclave ne libère la part déchiffrée qu’après validation de l’assertion de la requête, et uniquement pour être combinée avec la part de l’utilisateur à l’étape finale de signature.
L’enclave ne voit jamais la sortie PRF de l’utilisateur, la part de clé de l’utilisateur ni la clé privée assemblée.
Propriétés de sécurité
Pas de point de défaillance unique
| Scénario | Conséquence |
|---|---|
| Appareil utilisateur volé | L’attaquant ne peut pas reproduire la biométrie/le PIN ; la sortie PRF n’est pas obtenable |
| API entièrement compromise | L’attaquant n’obtient que du texte chiffré avec un secret qu’il n’a jamais vu |
| Enclave entièrement compromise | L’attaquant obtient une part de la clé ; l’autre part n’est sur aucun des systèmes compromis |
| API et enclave toutes deux compromises | L’attaquant obtient le contenu utilisateur chiffré et la part serveur — mais ne peut toujours pas déchiffrer le contenu utilisateur sans la sortie PRF de l’authentificateur physique |
Le dernier scénario est le critique. Même une compromission complète de toute l’infrastructure côté serveur est insuffisante pour reconstruire une clé privée. L’authentificateur de l’utilisateur est la barrière cryptographique qu’aucune brèche côté serveur ne peut contourner.
Sécurité informationnelle
Le modèle hybride hérite de la même classe de garantie de sécurité que le partage de secret de Shamir : la répartition de la clé n’est pas seulement calculatoirement sûre — elle est informationnellement sûre. Un attaquant disposant d’une puissance de calcul illimitée et détenant le matériel de deux des trois parties n’obtient aucune information sur la clé privée. Il n’existe aucun algorithme, quel que soit le temps ou le matériel, capable de dériver la clé à partir des seules données de deux parties. C’est la même garantie qu’offre un one-time pad.
Non custodial par conception
Nous exploitons à la fois l’API et l’enclave. Malgré cela, nous ne pouvons pas accéder unilatéralement aux fonds des utilisateurs. La sortie PRF de l’utilisateur est la pièce manquante — elle est produite dans le matériel de l’utilisateur et jamais transmise. Notre incapacité à accéder aux fonds n’est ni une politique ni un engagement contractuel. C’est une contrainte mathématique qui demeure quels que soient les contrôles d’accès internes, la pression réglementaire ou la compromission de l’infrastructure.
Comment une transaction est signée
Toute la signature a lieu sur l’appareil de l’utilisateur. La clé privée n’est jamais assemblée sur un serveur.
- L’utilisateur approuve une transaction dans l’application. L’appareil authentifie l’utilisateur par biométrie ou PIN.
- L’appareil calcule localement son secret PRF lié au matériel. Ce secret ne quitte jamais l’appareil.
- L’application récupère le contenu utilisateur chiffré auprès de l’API et la part serveur auprès de l’enclave. Aucun de ces éléments n’est utilisable seul.
- Sur l’appareil de l’utilisateur, en mémoire : le secret matériel déchiffre le contenu utilisateur, produisant la part de clé de l’utilisateur. Les deux parts sont combinées en la clé privée complète.
- La clé privée signe la transaction — entièrement sur l’appareil.
- La clé privée est immédiatement effacée de la mémoire. Elle n’est pas mise en cache, pas persistée, pas journalisée.
La clé privée complète n’existe que quelques millisecondes, uniquement sur l’appareil de l’utilisateur, et uniquement pendant l’opération de signature. Aucun serveur ne la voit jamais.
Export de la clé privée
Si un utilisateur choisit d’exporter sa clé privée — par exemple pour migrer vers un autre portefeuille — le même principe s’applique. La clé est reconstruite et livrée entièrement sur l’appareil de l’utilisateur. Le serveur fournit les parts chiffrées, mais le déchiffrement et l’assemblage ont lieu localement. À aucun moment de l’export la clé privée ne transite ni ne devient visible pour un serveur.
Synchronisation des passkeys et accès multi-appareils
Les plateformes modernes — iCloud Keychain chez Apple, Google Password Manager sur Android — synchronisent les passkeys entre les appareils d’un utilisateur. Le secret lié au matériel utilisé pour la reconstruction de la clé fait partie du matériel passkey synchronisé, ce qui signifie que la même sortie PRF est reproductible sur tout appareil du groupe de synchronisation de l’utilisateur. Cela préserve le modèle de sécurité à trois parties entre appareils : tout appareil synchronisé peut participer à la signature sans modification de l’architecture côté serveur.
Les utilisateurs sont informés si leur passkey a été synchronisée vers leur compte cloud, afin d’avoir toujours une visibilité sur la récupérabilité de leur portefeuille.
Le support PRF est disponible sur iOS 18+, macOS Sequoia 15.4+, Android 14+ et la série YubiKey 5. Pour les plateformes sans support PRF, une solution de repli de signature côté serveur est utilisée.
Comparaison avec la sécurité des portefeuilles classiques
| Modèle | Emplacement de la clé privée | Qui peut accéder aux fonds |
|---|---|---|
| Auto-garde standard (phrase de récupération) | Stockée par l’utilisateur | Toute personne disposant de la phrase de récupération |
| Custodie d’exchange / portefeuille hot | Stockée par l’opérateur | L’opérateur (et toute personne qui compromet l’opérateur) |
| Portefeuille matériel | Stocké sur l’appareil | Toute personne avec l’appareil physique + PIN |
| Ce système | Jamais stockée entièrement | Exige simultanément l’authentificateur actif de l’utilisateur et l’infrastructure serveur |
Synthèse
Ce modèle hybride — combinant le chiffrement côté client basé sur PRF, le partage de secret et une enclave isolée — répartit la confiance entre trois parties réellement indépendantes, de sorte qu’aucun sous-ensemble de deux ne peut reconstruire une clé privée, avec la même garantie de sécurité informationnelle que le partage de secret de Shamir. Le secret matériel lié à la biométrie de l’utilisateur est l’ancrage cryptographique de l’ensemble du système. L’infrastructure côté serveur, quelle que soit l’ampleur de sa compromission, ne peut produire une signature valide sans la participation physique de l’utilisateur.