Processeurs : Intel annonce la fin de son chiffrement historique
Le Xeon 7 sera le dernier processeur à intégrer la technologie de chiffrement SGX. Pour Intel, il s’agit de s’adapter aux usages du cloud. Implicitement, il reconnaît au bout de neuf ans qu’AMD avait fait un meilleur choix pour les hébergeurs.
Intel va abandonner SGX, la technique historique de ses processeurs Xeon pour chiffrer des applications en mémoire, au profit de TDX, une version plus récente et qui travaille à un niveau plus global. À savoir celui de la machine virtuelle qui exécute l’application, plus toutes ses bibliothèques.
La décision d’Intel n’est pas anodine. Le fournisseur avait pour ainsi dire inventé le chiffrement des exécutables en mémoire, en 2015, puis incité toute une génération de développeurs à tirer profit de SGX pour garantir la sécurité des codes qu’ils souhaitaient exécuter depuis le cloud. Onze ans plus tard, il lui faut dire à tous ces développeurs qu’ils doivent débarrasser leurs codes des instructions SGX, sans quoi leurs applications ne fonctionneront plus sur les prochaines générations de processeur.
« L’industrie s’est progressivement rassemblée autour des technologies d’isolation de machines virtuelles comme Intel TDX, car elles offrent l’évolutivité, la facilité de déploiement et le modèle opérationnel dont les clients ont besoin pour une adoption généralisée », justifie Mike Ferron-Jones, le responsable des programmes Platform Security and Integrity chez Intel, dans un billet de blog.
Il explique que le Xeon 7 (alias Diamond Rapids), normalement commercialisé l’année prochaine, sera le dernier processeur pour serveurs à supporter encore les instructions SGX.
La discipline ici concernée s’appelle l’informatique confidentielle. Son enjeu est d’empêcher une personne ayant accès à l’ordinateur qui exécute un code d’espionner les données traitées par ce code. En clair, pour qu’un hébergeur ne puisse pas voler les informations de ses clients.
En substance, même quand les utilisateurs envoient des données chiffrées en ligne pour qu’elles y soient traitées, il reste normalement possible à un administrateur mal intentionné de geler ou de détourner le fonctionnement d’un serveur, afin d’en extraire ce qui s’est déchiffré en entrant dans sa mémoire. Avec l’informatique confidentielle, le chiffrement subsiste dans la mémoire du serveur.
Laisser les hébergeurs sécuriser les containers
Selon Mike Ferron-Jones, TDX s’impose, car « les entreprises souhaitent utiliser davantage de données sensibles, dans plus d’endroits, pour des services plus critiques, dans des clouds et des IA qui préservent la confidentialité, selon des exigences de réglementations et de souveraineté des données. »
Traduction : il vaut mieux passer par TDX, car, quand on l’utilise, le développeur n’a pas à insérer des lignes de code pour garantir la confidentialité des traitements. C’est l’hébergeur qui s’occupe de tout. Ce serait beaucoup plus simple et bien plus universel. Surtout dans le contexte des applications modernes, du cloud ou de l’IA, qui sont livrés dans un format container pour simplifier leur déploiement sur n’importe quelle infrastructure.
« Les entreprises souhaitent utiliser davantage de données sensibles, dans plus d’endroits, pour des services plus critiques, dans des clouds et des IA qui préservent la confidentialité [...]. »
Mike Ferron-JonesResponsable des programmes Platform Security and Integrity, Intel
D’un côté, Intel a proposé des bibliothèques pour que les développeurs produisent des containers qui se chiffrent en mémoire grâce aux instructions SGX. Mais la contrainte est que ce container ne peut fonctionner que si le serveur qui l’exécute repose sur un processeur Intel Xeon. Donc il faut au préalable connaître l’architecture sous-jacente. Par ailleurs, pour qu’un container chiffré avec SGX puisse communiquer des containers qui ne le sont pas, le développeur de l’application doit jongler avec une kyrielle de bibliothèques.
De l’autre, avec TDX, le développeur n’a rien à faire. Son container fonctionnera sur tous les Kubernetes, quel que soit le serveur sous-jacent. Et il lui appartient juste de choisir des hébergeurs qui proposent d’exécuter son container dans une enclave qui chiffrera ses traitements. Le principe technique est celui des Kata Containers, que les développeurs d’OpenStack ont lancé à la fin de l’année 2017. Il s’agit d’exécuter chaque pod de containers depuis une micro-VM chiffrée avec des clés générées au sein du processeur et auxquelles l’hébergeur n’a pas accès.
9 ans plus tard, la reconnaissance définitive du meilleur choix fait par AMD
Mais l’histoire ne s’arrête pas là. Cet abandon de SGX signe en creux la reconnaissance très tardive par Intel d’une erreur stratégique qui a sans doute participé à la perte de son leadership dans les processeurs pour serveurs.
Car c’est AMD, le concurrent direct d’Intel, qui a implémenté le premier une technique de chiffrement des VM en mémoire, sous le nom SEV, dans ses processeurs Epyc, dès 2017. Soit six avant l’arrivée de TDX dans les Xeon. Or, quelque part, l’existence originelle de SEV dans les Epyc explique une part du succès explosif d’AMD dans les serveurs des hébergeurs, au détriment d’Intel qui n’a jamais vraiment compris comment il avait pu être détrôné à ce point dans les datacenters.
Depuis lors, les processeurs ARM pour serveurs se sont également dotés d’un dispositif similaire à TDX et SEV, le CCA, implémenté dans le jeu d’instruction ARMv9. Il est utile de noter que les processeurs ARM implémentent aussi un dispositif similaire à SGX, mais uniquement, eux, sur les modèles destinés aux appareils mobiles.
Notons par ailleurs que les GPU de Nvidia implémentent depuis trois générations (depuis les H100) le support de toutes ces technologies pour échanger avec quelque processeur que ce soit des données chiffrées lors des traitements d’IA en ligne. Les GPU d’AMD ne le font que depuis le MI455X annoncé cette année. Auparavant, ils n’étaient compatibles qu’avec la technologie SEV d’AMD.
