Que sait-on des capacités du processeur sécurisé AMD?
J'ai trouvé pas mal de recherches sur ce que fait ME d'Intel, y compris le "Intel x86 considéré comme nuisible (le chapitre 4 parle de ME)" papier d'enquête de Joanna Rutkowska, mais j'ai beaucoup plus de difficulté à trouver des informations sur le processeur sécurisé d'AMD (anciennement connu sous le nom de PSP).
Certaines personnes ont affirmé que AMD PSP est "aussi mauvais que" ou "pire que" le ME. (Par exemple, il y a un page souvent citée sur le site du projet libreboot qui réclame beaucoup de choses sur PSP, mais je n'ai pas encore trouvé de corroboration indépendante de beaucoup de ces réclamations, et la perspective de libreboot est clairement différent de celui d'un chercheur pratique en sécurité.)
En fin de compte, ce que je veux répondre par moi-même est: si le modèle de menace suppose que AMD n'a pas pré-backdooré ses CPU/APU en usine, à quel point le processeur sécurisé est-il risqué en tant que vecteur de futures backdooring (comme le "ring - 3 rootkits "démontrés sur Intel), soit par AMD ou par un tiers, et cette menace est-elle atténuable?
Mais de manière moins subjective, j'aimerais savoir quelles capacités ont déjà été vues sur le processeur sécurisé et comment cela se compare à ce que l'on sait sur ME:
- A-t-il été utilisé pour une gestion à distance similaire à l'AMT d'Intel?
- Est-il connu d'avoir sa propre pile réseau?
- At-il un micrologiciel pouvant être mis à jour par logiciel, et comment ce micrologiciel est-il sécurisé?
- Y a-t-il déjà eu des exploits connus le ciblant, ou des recherches publiques sur son firmware?
- Pour quelles raisons pourrait-on dire que la situation avec AMD PSP est "meilleure" ou "pire" qu'avec Intel ME?
Donc, ce que je dirais, c'est que tout ce qui fournit un accès direct à la mémoire et essentiellement le traitement au nom du processeur est un tout autre ensemble de surfaces de menace que vous introduisez sur la plate-forme informatique. Je dirais donc que la surface de la menace est similaire sinon la même.
La façon dont la PSP est censée fonctionner, à bien des égards imite ME, mais elle participera également aux opérations cryptographiques étant donné que cela semble être son objectif principal. Il n'y a pas encore d'attaques en cours dans la nature sur la plate-forme dont on parle.
La partie qui m'amène à croire qu'il sera probablement exploité de cette manière est un teaser: logiciel anti-vol est l'une des fonctionnalités que PSP est censée activer ... Presque tous les cas en profitent de ME ou de cales UEFI grossières, si cela est censé être plus ou moins le même, je suppose que certaines capacités de gestion résident/hors ligne pour le système PSP sur puce.
Il n'y a rien dans la spécification qui parle directement à une pile de mise en réseau, mais il y a un appel à interagir avec "IO", ce qui pourrait être un talon pour cela.
Cela me surprendrait également si AMD ignorait une fonctionnalité de son principal concurrent qui existait depuis près de dix ans. Mais ce n'est pas concluant.
J'étais intéressé par le même problème et j'ai fait quelques recherches préliminaires. Je vais essayer de répondre à certaines des questions, mais en tant qu'ingénieur non AMD, je ne peux pas en être certain.
A-t-il un micrologiciel pouvant être mis à jour par logiciel?
Oui. Ce micrologiciel fait partie de AGESA (AMD Generic Encapsulated Software Architecture), un blob binaire distribué d'AMD aux fournisseurs de micrologiciels UEFI. Aussi pour coreboot, où ils viennent avec notes de version La section PSP mentionne les numéros de version PSP pour différentes plates-formes. Cela suggère qu'ils peuvent être mis à jour.
et comment ce firmware est-il sécurisé?
Je n'ai pas pu extraire le code du firmware et je ne sais pas comment il est protégé. Une indication possible serait la façon dont le firmware SMU est protégé: avec un HMAC-SHA dans l'en-tête, avec une clé secrète cachée (voir la présentation de Rudolf Marek ).
- Pointeur pour une analyse plus approfondie: blobs de PSP stoney ridge dans coreboot .
A-t-il été utilisé pour une gestion à distance similaire à l'AMT d'Intel?
Il est impossible de savoir à quoi il a servi. Cependant, mes résultats suggèrent que la gestion à distance n'est pas l'objectif principal (contrairement au ME d'Intel). Ce que j'ai trouvé:
La PSP joue un rôle dans le processus de démarrage du CPU (c'est souvent cité, donc je ne répéterai pas).
La PSP propose l'API fTPM (firmware based TPM) pour la gestion des clés privées.
La PSP gère les clés pour SEV (Secure Encrypted Virtualization API), VM cryptage mémoire. Cela utilise un API pour la PSP . Pour voir les écrous et boulons, il y a un correctif Linux RFC pour introduire le support.
Le PSP peut être utilisé pour le déchargement cryptographique. La prise en charge de cela a atterri dans le noyau Linux sous
drivers/crypto/ccp.
Cependant: il est prouvé que le code peut être chargé dynamiquement,
- Chargement de "trustlets" dans coreboot. Pointeur pour une analyse plus approfondie: bibliothèque PSP dans coreboot
- Un commentaire "Commande pour charger le binaire de l'application approuvée dans le système d'exploitation PSP" dans
drivers/gpu/drm/AMD/amdgpu/psp_gfx_if.hdans le noyau Linux. Cela peut concerner une PSP différente sur la puce GPU, mais comme il s'agit du code AMD, même alors, il peut y avoir des chevauchements.
Est-il connu d'avoir sa propre pile réseau?
Non, il n'est pas connu d'avoir une pile réseau dans la configuration de stock. Toutes les API semblent faire face au CPU, pas au monde extérieur.
Sachant comment ces processeurs sont conçus avec des spécifications vagues de la part des "clients entreprise" et des fournisseurs de DRM, il peut être possible de charger des modules de gestion à distance, avec une pile réseau. Cependant, rien de ce que j'ai trouvé ne le prouve de manière concluante.
Y a-t-il déjà eu des exploits connus le ciblant, ou des recherches publiques sur son firmware?
Il y a vulnérabilité publique dans l'API fTPM . Je n'ai trouvé aucune recherche publique sur le firmware.
Pour quelles raisons pourrait-on dire que la situation avec AMD PSP est "meilleure" ou "pire" qu'avec Intel ME?
Au moins le processeur de sécurité AMD ne fournit pas une API de gestion à distance prête à l'emploi (à notre connaissance), contrairement à Intel ME. Pour le transformer en porte dérobée d'écoute réseau, le logiciel du système d'exploitation doit fournir d'autres modules, ou peut-être même le compromettre.
Cependant, comme nous l'avons constaté, il s'agit d'une boîte noire avec très peu de recherches publiques. En cryptographie, un système gagne en confiance après avoir été souvent analysé et aucune vulnérabilité n'a été trouvée. La sécurité par obscurité n'est pas acceptable. Malheureusement, personne ne tient les processeurs de sécurité au principe de Kerckhoffs.