Une puce contenant les clés de cryptage qui promet d’être mieux sécurisée que l’actuelle TMP.
Il y a quelques jours, Microsoft a présenté son processeur de sécurité Pluton ; celui-ci succédera à la puce TMP (Trusted Platform Module). Il s’agit toujours d’une solution matérielle intégrée qui stocke les clés de cryptage et contribue donc à améliorer la sécurité. AMD, Intel et Qualcomm intégreront Microsoft Pluton dans leurs prochaines puces. Néanmoins, AMD et Microsoft mettent en avant leur partenariat : en effet, ce processeur de sécurité Pluton s’inspire de l’ASP (AMD Security Processor) inauguré en 2013 avec la console Xbox One.
Comme Microsoft le rappel dans sa publication, le TPM a protégé les PC depuis plus de 10 ans ; il commence donc à sérieusement dater. Surtout, les pirates ont mis au point des attaques physiques comme Meltdown et Spectre capables de cibler son point faible : le bus reliant la TPM au processeur.
Plus de bus à attaquer
Désormais, “la conception Pluton élimine le risque d’attaque de ce canal de communication en intégrant la sécurité directement dans l’unité centrale” ; “les appareils Windows équipés de Pluton utiliseront le processeur de sécurité Pluton pour protéger les informations d’identification, les identités des utilisateurs, les clés de cryptage et les données personnelles. Aucune de ces informations ne peut être retirée de Pluton, même si un attaquant a installé un logiciel malveillant ou est en complète possession physique du PC”. Dans un premier temps, afin d’assurer le support avec les API TPM existantes, telles que BitLocker et System Guard, les PC Windows bénéficiant de l’architecture Pluton émuleront le TPM.
Enfin, comme mentionné plus haut, cette stratégie n’est pas inédite. Elle s’inspire du processeur de sécurité inauguré en 2013 avec la Xbox One ; dans la console, il prend la forme d’un Cortex-A5 de 32 bits, imbriqué dans le SoC, qui contient les clés de cryptage. AMD précise que l’ASP et le Microsoft Pluton coexisteront.
Source : Microsoft
Le truc qui fâche :
Dans un premier temps, afin d’assurer le support avec les API TPM existantes, telles que BitLocker et System Guard, les PC Windows bénéficiant de l’architecture Pluton émuleront le TPM.
Donc on conserve toute les failles via l’émulation ? quand il n’y aura plus d’émulation car décidé par le trio, tous les programme/OS utilisant l’ancien système seront inutilisable ?
@Jack : La rétrocompatibilité ne devrait pas être “le truc qui fâche” s’il est fait intelligemment et que l’on tient compte des vulnérabilités existantes lors de la conception de l’emulation.
Ainsi, comme expliqué dans l’article, l’une des vulnérabilités du TPM étant lié au bus entre la puce TPM et le processeur, le fait que la puce Pluton soit fusionné dans le processeur ne le rend pas vulnérable de la même façon à ce vecteur d’attaque. La conception du type de Pluton qui est intégré dans le processeur pour limiter les accès aux données semble un choix stratégique pertinent s’il résiste aux attaques sur le processeur telles celles existantes depuis quelques années. Une solution qui finira par avoir ses limites voir ses failles, mais qui a l’avantage d’être une montée en game de la sécurité embarqué et qui permettrait peut-être de généraliser l’intégration de ce type de sécurité sur tout type d’appareil.
Cela démontre aussi que la prise de conscience semblent s’opérer sur le concept que la vulnérabilité de plus bas niveau étant au niveau du processeur et de ses échanges/interactions, c’est l’un des éléments les plus névralgiques de la sécurité de demain.
Une émulation bien conçue permettra ainsi une évolution par étape le temps que les “programme/OS utilisant l’ancien système” (pour vous citer) se mettent à jour.
Pour les softwares qui ne se mettraient pas à jour :
– soit l’émulation resterait la solution la plus optimale, corrigeant certains défauts de la solution TPM… sans apporter un optimum de sécurité
– soit le soft serait alors purement obsolète par manque de suivi !
Mais en même temps ne soyons pas dichotomique : On ne peut pas à la fois critiquer la rétrocompatibilité (et ses risques de conserver une approche imparfaite) dans la conception d’une nouveauté, et critiquer en même temps l’obsolescence à venir à terme, quand cette la rétrocompatibilité atteindra ses propres limites.
Cela fait parti du cycle de vie d’un produit informatique que de passer par des étapes de rétrocompatibilité puis à terme d’obsolescence. Les cycles de vie LTS sont dans par ailleurs dans cette logique.
Votre réaction est donc très légitime, mais la réalité de l’évolution de la sécurité des systèmes semble devoir suivre se type de processus pour être fait intelligemment.