Architecture / architecture · 05
Zero Trust Bootstrap Protocol
À la première initialisation, l'appareil génère une paire de clés à l'intérieur de son trusted execution environment. La clé privée ne quitte jamais. La clé publique est enregistrée auprès du backend opérateur via un canal d'onboarding contrôlé par l'opérateur — un chemin qui ne nous inclut pas.
Ce que “zero trust” veut dire ici
Il n’y a pas de secret partagé installé en usine. Il n’y a pas de clé que nous détenons pour le compte de l’opérateur. Il n’y a pas d’escrow. À la première initialisation, l’appareil génère sa propre paire de clés à l’intérieur de son trusted execution environment — TEE sur Android, Secure Enclave sur iOS, HSM sur le terminal. La clé privée est générée là et vit là. La clé publique, et seulement la clé publique, quitte l’appareil.
outcomes
Ce que cela vous permet de faire aujourd'hui que vous ne pouviez pas avant
-
Onboarder des appareils sans secrets pré-partagés
Pas de clés à provisionner en usine, pas de credentials statiques partagés à roter. La paire de clés apparaît à la première init, sur l'appareil, dans la frontière de trust.
-
Tenir la souveraineté des clés sur le cycle de vie de l'appareil
YinkoShield ne voit jamais une clé privée. Les opérateurs ne dépendent pas des pratiques d'escrow d'un fournisseur pour leur propre posture d'audit.
-
Détecter le re-bootstrap comme un signal, pas comme un redémarrage silencieux
Un appareil wipé ou restauré génère une nouvelle paire de clés. L'opérateur voit le changement explicitement et applique la policy — exigeant typiquement une ré-attestation de l'identité utilisateur.
-
Éviter l'overhead de compliance lié à l'escrow
Aucune partie du substrat ne stocke de clés privées, ne les transmet, ou n'a accès pour les recouvrer. Votre périmètre de compliance se réduit en conséquence.
-
Onboarder à la cadence PKI-conforme
L'infrastructure PKI existante pour enregistrer et roter les clés publiques fonctionne sans changement. Le bootstrap rentre dans le flow standard de device-identity-binding de l'opérateur, pas à côté.
Comment l’enregistrement fonctionne
La clé publique est enregistrée auprès du backend de l’opérateur via le canal d’onboarding de l’opérateur — typiquement le même canal qu’il utilise pour toute étape de device-identity-binding dans son processus existant. Nous ne sommes pas dans ce chemin. Nous ne voyons pas la clé publique. Nous ne stockons pas le mapping device-vers-opérateur.
À partir de ce moment, l’opérateur possède le matériel de vérification. Chaque événement futur signé par l’appareil peut être vérifié par l’opérateur avec la clé publique enregistrée, et seulement par les parties auxquelles l’opérateur choisit d’accorder la clé publique.
properties
Ce que vous obtenez quand le bootstrap tourne
-
·01 Génération in-TEE
Paire de clés créée à l'intérieur du secure element de l'appareil — TEE sur Android, Secure Enclave sur iOS, HSM sur les terminaux. Rien dans l'user-space ne voit la clé privée.
-
·02 Enregistrement à sens unique
La clé publique quitte l'appareil exactement une fois, via le canal d'onboarding de l'opérateur. La clé privée ne quitte jamais.
-
·03 Pas d'escrow, nulle part dans la stack
Pas de backup, pas de clé de recouvrement, pas de master key. Un appareil qui a perdu son matériel privé re-bootstrap depuis zéro.
-
·04 Mapping device-vers-clé possédé par l'opérateur
L'opérateur le stocke. Nous ne le faisons pas. Nous ne l'avons pas. Le périmètre d'audit le reflète.
-
·05 Opération PKI-conforme
L'enregistrement, la rotation, et la révocation des clés publiques suivent les patterns PKI standards. Pas de protocole de gestion de clés bespoke.
-
·06 Détection de re-bootstrap
Un appareil présentant une nouvelle clé publique avec le même identifiant d'appareil remonte comme un changement d'état sur lequel l'opérateur peut agir.
Pourquoi cela compte
Sovereign verification — la propriété selon laquelle toute partie disposant de la clé publique peut vérifier l’evidence indépendamment, sans endpoint YinkoShield dans le chemin — est établie par ce bootstrap, pas par le vérificateur. Si le bootstrap nous mettait dans le chemin de la clé, le vérificateur ne pourrait pas être sovereign quelle que soit la façon dont il serait implémenté. Les deux sont couplés : ZTBP est la propriété à l’enregistrement, sovereign verification est la propriété à l’utilisation.
Ce qui est hors-périmètre pour le bootstrap
- L’authenticité de l’appareil. Le TRP mesure ce qu’il peut sur l’état runtime de l’appareil au bootstrap, mais un appareil qui présente une identité matérielle contrefaite est un problème séparé que l’opérateur gère dans son flow d’onboarding.
- Re-bootstrap après wipe ou transfert d’appareil. Un appareil qui a été wipé génère une nouvelle paire de clés. L’opérateur peut détecter cela et appliquer la policy — exigeant typiquement une ré-attestation de l’identité utilisateur — mais le bootstrap lui-même est identity-of-device, pas identity-of-user.
Où en lire plus
Le protocole bootstrap, les garanties TEE, et la spécification de l’interface d’onboarding vivent dans YEI-001 §6.6, partagés avec les régulateurs et partenaires qualifiés sous NDA.