IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Microsoft s'associe à des fabricants de puces, notamment AMD, pour créer des firmwares inviolables
Et accroitre la sécurité des plateformes Windows 10 dans le cadre de son initiative Secured-core PC

Le , par Christian Olivier

26PARTAGES

22  0 
Diverses études ont montré qu’une seule attaque malveillante peut coûter des millions de dollars aux organisations et nécessiter un temps de récupération important. Avec la recrudescence des attaques malveillantes et l’augmentation du nombre d’employés opérant à distance et connectés à un réseau considéré comme moins sûr que le réseau d’entreprise traditionnel, les systèmes informatiques des employés peuvent être perçus comme un maillon faible de la sécurité et un risque pour la sécurité globale de l’entreprise. À cause de ces nouveaux risques, les fournisseurs de systèmes d’exploitation et de matériel indépendant ont décidé d’investir dans des technologies de sécurité qui permettront aux ordinateurs de mieux résister aux cyberattaques.


C’est dans ce contexte que le géant Microsoft a récemment annoncé son initiative Secured-core qui s’appuie sur les efforts combinés des partenaires OEM, des fournisseurs de puces et de la société elle-même pour fournir du matériel, des microprogrammes et des logiciels dont l’intégration au-delà de leur fonction première devra concourir à accroitre la sécurité des plateformes Windows. L’entreprise AMD, par exemple, de par son statut de fournisseur de premier plan de puces x86 sur le marché des PC, est un partenaire clé dans cet effort à travers la fourniture de processeurs compatibles avec le standard Secured-core.

Dans les systèmes informatiques actuels, le chargeur de démarrage et le micrologiciel de bas niveau sont exécutés en premier lieu pour les besoins de configuration. Par la suite, la gestion du système et de ses ressources ainsi que sa protection est transférée au système d’exploitation. Mais aujourd’hui, les cyberattaques sont de plus en plus sophistiquées et les menaces ciblant les micrologiciels de bas niveau deviennent plus importantes. Compte tenu de l’évolution du paradigme des menaces à la sécurité, il est impératif de fournir aux clients finaux une solution matérielle et logicielle intégrée qui offre une sécurité complète au système.

C’est là qu’intervient l’initiative Secured-core de Microsoft. Une machine certifiée Secured-core doit vous permettre de démarrer en toute sécurité votre système, de protéger votre appareil contre les vulnérabilités affectant le micrologiciel, de protéger le système d’exploitation contre les attaques et d’empêcher l’accès non autorisé aux périphériques et aux données grâce à des contrôles d’accès et systèmes d’authentification avancés.


La société AMD va jouer un rôle vital dans l’activation du Secured-Core sur les dispositifs compatibles, car les caractéristiques de sécurité matérielle des processeurs pour PC de la marque associées aux solutions logicielles devront contribuer à améliorer la protection contre les cyberattaques ciblant les micrologiciels de bas niveau. Avant d’expliquer comment les CPU AMD permettront d’activer le Secured-Core PC dans la prochaine génération de PC, attardons-nous sur certaines caractéristiques de sécurité et certaines capacités des processeurs d’AMD dérivés de l’architecture Zen.

SKINIT

L’instruction SKINIT aide à créer une « ;racine de confiance ;» en lançant un mode de fonctionnement initialement non fiable. SKINIT réinitialise le processeur pour établir un environnement d’exécution sécurisé pour un composant logiciel, appelé le chargeur sécurisé (ou SL pour Secure Loader) d’AMD, et démarre l’exécution du SL d’une manière qui aide à prévenir toute manipulation. SKINIT étend la racine de confiance matérielle au chargeur sécurisé.

AMD Secure Loader (SL)

Le chargeur sécurisé d’AMD (SL) est responsable de la validation de la configuration de la plateforme en interrogeant le matériel et en demandant des informations de configuration au service DRTM.

AMD Secure Processor (ASP)

AMD Secure Processor fait référence à un matériel dédié – coprocesseur - disponible dans chaque puce qui permet de démarrer en toute sécurité, depuis le BIOS vers l’environnement TEE (Trusted Execution Environment).

AMD-V avec GMET

AMD-V est un ensemble d’extensions matérielles qui permettent la virtualisation sur les plateformes AMD. Guest Mode Execute Trap (GMET) est une fonction d’accélération des performances intégrée aux processeurs Ryzen de la marque qui permet à l’hyperviseur de contrôler efficacement l’intégrité du code et de se protéger des logiciels malveillants.


Sur les processeurs AMD dérivés de l’architecture Zen, le firmware ou micrologiciel est authentifié et mesuré par un bloc de sécurité intégré à la puce. La valeur lue est ensuite stockée en toute sécurité dans le TPM (Trusted Platform Module) pour une utilisation ultérieure par le système d’exploitation, un usage qui inclut la vérification et l’authentification. À tout moment après le démarrage de l’OS, ce dernier peut demander au bloc de sécurité intégré à la puce AMD de refaire les mesures et comparer avec les anciennes valeurs avant d’exécuter certaines opérations. De cette façon, l’OS peut aider à assurer l’intégrité du système dès son démarrage. Ce processus est géré au niveau du CPU AMD par le DRTM (Dynamic Root of Trust Measurement) Servcie Block qui est chargé de créer et de maintenir une chaîne de confiance entre les composantes de ce processus.

Cependant, bien que les méthodes ci-dessus aident à protéger le micrologiciel, il y a toujours une surface d’attaque qui doit être protégée, le System Management Mode (SMM), un autre mode de fonctionnement des CPU x86 théoriquement dédié à l’exécution de routines de maintenance de la plateforme qui sont spécifiées par le concepteur de la carte mère. Ce mode a été introduit dans les années 80 avec la génération de CPU 386 Intel. Le SMM a la particularité d’être exécuté sans que l’OS en soit conscient ou que ce dernier puisse contrôler son activation ou son arrêt. C’est justement tout l’intérêt du SMM, gérer l’alimentation, la configuration matérielle, la surveillance thermique ou agir sur la mémoire et les périphériques sans que l’OS le sache. Lorsque ce mode est activé, toutes les interruptions, exceptions et même les NMIs sont masquées.

Pour faire basculer le CPU en mode SMM, il faut faire appel à une interruption matérielle appelée SMI (System Management Interrupt). En théorie, seuls des événements matériels critiques peuvent déclencher une telle interruption. Cependant, la plupart des chipsets fournissent un registre appelé APMC (Advanced Power Management Control) dans lequel toute écriture déclenche une SMI. La routine de traitement de la SMI est écrite par le concepteur de la carte mère afin de charger l’OS qui en général n’a pas connaissance des spécificités de chaque plateforme. Compte tenu de sa proximité avec le matériel, cette routine a besoin de privilèges élevés pour fonctionner. Le code qui s’exécute en mode SMM dispose de fait d’un accès illimité à la mémoire physique de la machine et à l’ensemble des registres de configuration ou de l’espace mémoire propre des périphériques, quel que soit le mécanisme d’accès utilisé (PMIO, configuration PCI ou MMIO).

Au vu de ses particularités, le mode SMM des processeurs x86 est devenu une cible attrayante pour les attaquants. Il peut être utilisé pour accéder à la mémoire de l’hyperviseur et modifier ce dernier. Puisque le gestionnaire SMI est généralement fourni par un éditeur tiers, le système d’exploitation et le code du gestionnaire SMM fonctionnant avec des privilèges plus élevés ont accès à la mémoire et aux ressources de l’OS / Hyperviseur. Les vulnérabilités exploitables dans le code SMM conduisent à un compromis entre le système d’exploitation Windows et la sécurité basée sur la virtualisation (VBS). Pour aider à isoler le mode SMM de ses processeurs x86, AMD a introduit un module de sécurité appelé AMD SMM Supervisor qui s’exécute immédiatement avant que le contrôle soit transféré au gestionnaire SMI, après qu’un SMI se soit produit. Le SMM Supervisor d’AMD réside dans le DRTM Service Block et ajoute une couche de protection matérielle supplémentaire au PC.


L’une des exigences relatives au Secured-core PC inclut le support de mesures d’intégrité système de base telles que le TPM 2.0. Une protection du noyau comme l’intégrité du code protégée par hyperviseur (HVCI) est également nécessaire. Des mesures sont également prises pour surveiller et restreindre les fonctionnalités potentiellement dangereuses du micrologiciel accessibles via le SMM.

Microsoft a expliqué que cette initiative a été mise sur pied pour prévenir les attaques plutôt que de simplement les détecter sur Windows et que, combinée avec Windows Defender System Guard, elle devrait permettre de fournir garanties uniformes sur l’intégrité de l’OS afin d’atténuer les menaces qui visent la couche firmware. Cette protection avancée du firmware des PC « ;fonctionne de concert avec d’autres fonctionnalités Windows pour garantir que les PC Secured-core offrent une protection complète contre les menaces modernes ;», a précisé Redmond. Notez que le dispositif Surface Pro X de Microsoft est un système certifié Secured-core.

Sources : Microsoft, AMD

Et vous ?

Que pensez-vous de cette initiative ?
La mise en avant d’AMD plutôt qu’Intel dans le cadre de ce projet vous semble-t-elle justifiée ?

Voir aussi

Les processeurs Intel x86 souffrent d'un défaut qui permet d'installer des logiciels malveillants dans l'espace protégé des puces
Les processeurs Intel x86 souffriraient d'un défaut qui exposerait la mémoire noyau et impacterait surtout sur le marché serveur
AMD et Microsoft travaillent ensemble pour améliorer les performances des CPU Ryzen Threadripper et EPYC sur les plateformes Windows
AMD dégaine ses nouveaux CPU de bureau Ryzen Pro 3000 qui offrent un chiffrement complet de la RAM et ciblent le marché des entreprises et celui des professionnels

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 23/10/2019 à 1:12
Que pensez-vous de cette initiative ?
Que c'est encore un truc Windows only qui va faire ch**r avec les autres systèmes.
Que c'est pas en complexifiant encore la plateforme x86 que ça va s'améliorer niveau sécurité.
Que c'est pas en collant rustine sur rustine qu'on finit avec un pneu.

Je suis pas concepteur d'archi, mais il me semble que tous ça pourrait simplement être sécurisé avec une ROM, une EEPROM et deux interrupteurs, sans que ça ne ce transforme en usine à gaz logique (on perdrait effectivement la rétro-compatibilité).
Mais bon, j'ai bien conscience que pour des besoins d’offuscation de la plateforme, ce n'est simplement pas possible.
De toutes façons, je présume que leurs clients réclamant ce niveau de sécurité, ne sont surement pas sur x86 et par conséquent, pas sur Windows non plus.

La mise en avant d’AMD plutôt qu’Intel dans le cadre de ce projet vous semble-t-elle justifiée ?
MS n'as pas le choix niveau x86 c'est soit AMD, soit Intel.
Or pour le coup Intel a très mauvaise presse en ce moment, avec tous les scandales de failles liés à leurs choix d'archi mat (Spectre, Meltdown, ...etc).
Donc c'est logique de choisir le moindre mal, surtout pour une feature touchant à la sécurité système.
6  2 
Avatar de i5evangelist
Membre éclairé https://www.developpez.com
Le 23/10/2019 à 9:05
Que pensez-vous de cette initiative ?
Que c'est encore un truc Windows only qui va faire ch**r avec les autres systèmes.
C'est tout à fait ça ... il faut que la résistance s'organise
(pour donner un ordre d'idée, j'ai encore un clavier sans touche Zindozs entre Ctrl & Alt )
4  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 25/10/2019 à 4:14
Le concepte est pourtant simple en sécurité :
- tout ce qui est reprogrammable en info, est potentiellement corruptible
- tout ce qui est programmé peut potentiellement contenir un bug

Le 1er moyen à mettre en oeuvre pour pondre un produit de qualité, c'est :
1) en premier lieu, arrêter de lancer des produits immatures, pour coïncider avec des dates de lancement préalablement énoncées, pour ensuite les calfeutrer patch après patch dans la précipitation.
2) si la pire crainte c'est la corruption d'un programme critique... il suffit de ne pas le placer dans un matériel reprogrammable.
Quand auparavant on souhaitait changer son BIOS (ou le réparer), on commandait la puce, et on l'échangeait avec l'existant. Revenir à cette méthode serait peut-être une nouvelle avancé en sécurité, dans certains secteurs d'activités (qui de toute manière, ne procèdent pas aux mises à jour de ce genre de matériels).
3  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 23/10/2019 à 23:46
@Aurelien.Regat-Barrel, je croit qu'on c'est mal compris.

comment faire alors ? certainement pas en plaçant un firmware / BIOS buggé en ROM en tous cas !
Je n'est jamais dit qu'il fallait mettre le firmware dans une ROM.
On est bien d'accord que des bugs ne sont pas l'état normale attendue d'un programme/hardware ?
Si oui, alors on est bien d'accord que ça n'as rien à voir avec notre problème de complexification de la plateforme x86.
Non parce que leur "plateforme de sécurité" super complexe/top moumoute ne garanti aucunement le côté "bug free" du bouzin.
Est jusqu'à preuve du contraire, les puces de sécurités intégrés à nos Processeur/Motherboard, ne sont pas MàJ par les fabricants non plus, malgré les bugs.

A ma connaissance, le seul moyen de limité les bug d'un système est de limité la surface d'attaque potentiel au maximum.
Hors ils font exactement l'inverse BIOS -> puce TMP -> Intel ME/AMD PSP -> EFI -> UEFI -> SecureBoot -> Secured-Core.
Maintenant je veut bien qu'on m'explique en quoi c'est plus sur maintenant avec leur truc super complexe qu'avant avec le BIOS.
Même si on est tous d'accord pour dire que les 2-3 implémentations (AMI, Phoenix) bugué communes à tous les fabricants, n'ont jamais étaient la panacée (développé en ASM x86, sans revues de sécurités et avec des morceaux datant du 8086 et intouchable pour des raisons d'IP).
Au temps des premiers IBM PC, les sources du BIOS étaient livrées dans le manuel. (ce qui c'est perdu malheureusement)

Tu imagines devoir changer les 10.000 machines de ton parc parce qu'il y a une faille incorrigible ? Les PC (et autres Amiga) ont commencé sur ce modèle dans les années 80, mais aujourd'hui les entreprises doivent gérer des milliers de laptop de leurs employés ou machines mises à disposition au public via le cloud.
Et ...Ça ne change rien.
Il est de notoriété publique qu'il y a des failles incorrigibles (Hard/Soft, pas de jaloux ) dans tous les PC/Server en fonctionnement.
Que ce soit les contrôleurs réseaux (qui ont leurs propres OS), leurs co-pro de sécurité/management ou même dans leurs processeurs.
Pense tu qu'au vu du niveau de complexité atteint il soit possible de faire "bug free" ? LOL.

Avec leur truc en plus, ça ne fera que rajouter une couche d'insécurité supplémentaire (de nouvelles possibilités de failles).
Si ta chaine de sécurité Hardware/Software à un/des problème/s, bonne chance à toi et tes 10.000 machines inutilisable.
Pour rappel, la gestion (sécurisé) d'un parc de machine n'as rien avoir avec la complexification inutile du processus de boot dont il est question depuis qu'ils veulent nous vendre de la sécurité.

Enfin le BIOS est originaire des IBM PC Compatible quand même et les Amiga n'en ont jamais eu à ma connaissance.
Par contre les Amiga avaient quelque chose de sympa avec le "kickstart" (le firmware/bootloader copié depuis la ROM vers la RAM pour être exécuté en RO sans exécution intermédiaire de code, donc infiniment plus sécure que ce que l'on a là 40 ans après).

Et le coup de l'interrupteur, d'une certaine manière ça existe déjà sous de multiples formes logicielles : sudo, authentification, token, et autre validation d'installation (Android...). Mais le problème est toujours le même : l'utilisateur active l'interrupteur sur un logiciel qui se fait passer pour légitime et qui infecte ainsi sa machine. C'est tellement vieux comme problème, ne parle pas de Cheval de Troie pour rien.
Oui, mais le gros problème de ces solution est qu'elles peuvent toujours être contourné, puisque logiciel.
Moi j'évoquais de véritables interrupteurs qui s'ils ne sont pas enclenchés à un certain moment, bloquerait la réécriture de la conf des EEPROM contenant les firmwares/clés et/ou ça MàJ.
De cette façon un accès physique serait requis pour un accès bas niveau au système.
Ce qui normalement n'est plus nécessaire pour la gestion de parc, passé la conf par le SI à la réception.

P.S. : Une plateforme idéale serait d'avoir un Certificat dans une ROM, le firmware dans une EEPROM et la configuration de celui-ci dans une autre.
Pour flasher le firmware il faudrait obligatoirement appuyer sur un interrupteur, qui forcerait la vérification du nouveau firmware avec le certif présent en ROM, avant le début du flashage.
Si le nouveau firmware est validé par le certif en ROM, on flashe, sinon, c'est que le firmware vient d'une source inconnue et on le refuse.
Pareil pour le changement de config du firmware sur l'autre EEPROM et pour le démarrage de l'OS (signé avec un certif contenu dans l'EEPROM contenant la conf du firmware, pour qu'il soit gérable par le SI).
Et si l'on veut empêché matériellement toutes modif de la conf, on retire simplement la ROM, ainsi plus de validation possible.
Là on est blindé niveau sécurité et ce serait beaucoup plus simple que ce que l'on a présentement il me semble (mais je peut me tromper ).
2  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 23/10/2019 à 16:22
Citation Envoyé par defZero Voir le message
Que c'est pas en complexifiant encore la plateforme x86 que ça va s'améliorer niveau sécurité.
comment faire alors ? certainement pas en plaçant un firmware / BIOS buggé en ROM en tous cas ! Tu imagines devoir changer les 10.000 machines de ton parc parce qu'il y a une faille incorrigible ? Les PC (et autres Amiga) ont commencé sur ce modèle dans les années 80, mais aujourd'hui les entreprises doivent gérer des milliers de laptop de leurs employés ou machines mises à disposition au public via le cloud.

Et le coup de l'interrupteur, d'une certaine manière ça existe déjà sous de multiples formes logicielles : sudo, authentification, token, et autre validation d'installation (Android...). Mais le problème est toujours le même : l'utilisateur active l'interrupteur sur un logiciel qui se fait passer pour légitime et qui infecte ainsi sa machine. C'est tellement vieux comme problème, ne parle pas de Cheval de Troie pour rien.

à part ça le bon lien vers l'article de MS ça doit être celui là:
https://www.microsoft.com/security/b...mware-attacks/

en fait ce sont des fonctionnalités hardware développées par tout le monde et pas juste AMD, Intel et Qualcomm le font aussi, donc pas que du x86. Et les constructeurs de PC sont aussi dans le game: Dell, Dynabook, HP, Lenovo, Panasonic, ... Microsoft explique juste sous quelle forment ils intègrent cette feature dans leur OS pour exploiter ce hardware spécifique, qui semble déjà exister chez Apple. Perso je vois pas où est le problème.
1  0