Contexte et objectifs
Dans chaque rack Oxide, les clés DeviceId et Alias sont gravées dans le Root of Trust (RoT) et servent respectivement à l’identification de la plateforme et à la signature des mesures d’attestation. Une troisième paire de clés hébergée sur le RoT assure l’authentification des échanges Diffie‑Hellman temporaires, ce qui permet aux sleds d’établir des sessions sprockets sécurisées. Ces sessions garantissent la confidentialité, l’intégrité et l’authenticité des messages applicatifs, ainsi que l’attestation du logiciel en cours d’exécution.
L’enjeu principal est d’empêcher un attaquant qui aurait extrait un sous‑ensemble de sleds ou de disques de reconstruire les secrets critiques. La réponse d’Oxide repose sur un Trust Quorum qui utilise le partage secret de Shamir pour protéger un secret de rack partagé.
Mécanisme du quorum de confiance
Le secret de rack, qui n’est pas directement une clé, est découpé en N parts distinctes par un processus dealer. Chaque part est transmise via les sessions sprockets aux agents de bootstrap, accompagnée de l’identité de plateforme du membre du quorum, inscrite dans le certificat public du RoT. Les agents vérifient les certificats, établissent des connexions mutuelles et récupèrent K‑1 parts supplémentaires afin de recomposer le secret à partir de K parts. Sans atteindre le seuil K, aucune information exploitable sur le secret de rack ne peut être dérivée.
Actuellement, les parts sont stockées en clair sur les disques M.2 de chaque sled. Un vol physique nécessite la compromission d’au moins K disques pour reconstituer le secret, ce qui implique un effort logistique important. La feuille de route prévoit de « sceller » ces parts avec le RoT, de sorte qu’elles ne soient déchiffrées qu’au démarrage du sled, augmentant ainsi la barrière d’accès à K sleds entièrement fonctionnels.
Hiérarchie de clés et protection des données
Le secret de rack sert de source d’alimentation à un KDF (Key Derivation Function). À partir de ce KDF, Oxide dérive plusieurs clés : une clé racine pour les certificats internes, des clés de chiffrement ZFS pour chaque dispositif U.2, et des clés de service pour les composants du plan de contrôle. Chaque disque U.2 possède son propre jeu de clés ZFS, stocké hors‑volume, ce qui limite la portée d’une compromission à un seul disque.
Les pools ZFS (un par dispositif U.2) sont chiffrés via la racine du dataset, à l’exception de datasets comme crucible qui gèrent déjà leur propre chiffrement. La rotation des clés est prise en charge par le module noyau ZFS ; le changement de clé utilisateur ne nécessite pas le re‑chiffrement complet du dataset, ce qui réduit le temps d’indisponibilité et évite les coûts de I/O massifs.
Limites et perspectives
Le modèle actuel repose sur le stockage non chiffré des parts sur les disques M.2, ce qui expose le secret de rack à une attaque physique ciblée tant que le seuil K n’est pas atteint. Le futur scellage avec le RoT éliminera ce vecteur, mais dépendra de la robustesse du mécanisme de déverrouillage au boot. De plus, la documentation ne précise pas la taille du secret ni les paramètres de Shamir (valeur de N, K), ce qui complique l’évaluation de la résistance à la collusion d’acteurs malveillants.
Enfin, la hiérarchie de dérivation reste partiellement décrite : les relations exactes entre les clés de certificat, les clés de service et les clés de stockage ne sont pas explicitement cartographiées, ce qui limite la capacité d’auditer les chemins de confiance en cas de compromission. Une spécification détaillée du KDF, des algorithmes de hachage et des formats de wrapping serait nécessaire pour valider la solidité cryptographique de l’ensemble.
