RPMB est une partition spéciale dans eMMC 4.5. Des recherches sur Internet suggèrent qu'il est utilisé pour enregistrer des clés et qu'il s'agit de la seule partition spéciale qui répond à des commandes comme READ, WRITE. etc. Quelqu'un peut-il m'expliquer comment utiliser RPMB et comment il peut réellement atténuer les attaques par rejeu?
RPMB peut être utilisé à l'aide de mmc-utils
.
Il peut résister aux attaques de relecture en exigeant une clé pour écrire dans cette région. Le rpmb a une clé qui peut être programmée une fois. Plus tard, l'hôte lit une valeur de compteur dans le rpmb. Il utilise cette valeur de compteur et la clé programmée pour générer un MAC. L'appareil vérifie ensuite le MAC donné par rapport au MAC qu'il a calculé à l'aide de la même clé, et s'il correspond, l'accès en écriture est accordé ( référence , diapositive 4).
En règle générale, avant tout accès (par exemple en lecture ou en écriture) à la partition RPMB, une clé d'authentification RPMB doit être programmée dans le contrôleur RPMB dans le périphérique eMMC/UFS ou NVMe.
Notez que cette clé ne doit être programmée qu'une seule fois (au moins selon la spécification RPMB), et dans la commande/demande de programmation, la clé RPMB doit être envoyée en texte clair, elle doit donc normalement être provisionnée dans un environnement sûr (par exemple l'usine fabrication ou l'environnement de micrologiciel de confiance sur le terrain après le remplacement d'eMMC/UFS/NVMe par un nouveau).
Après la programmation, cette clé RPMB doit également être bien protégée, donc généralement l'utilisation de RPMB doit être fournie avec un TEE (environnement d'exécution fiable), comme OP-TEE , Google Android Trusty ou ici pour la plate-forme Intel x86 Cependant, un tel environnement TEE n'a normalement pas de pilote RPMB, mais il a la clé RPMB, et garde cette clé en sécurité à l'intérieur du TEE (ou monde sécurisé) pour la protection, tandis que le pilote RPMB lui-même devrait être dans un monde non sécurisé normal comme Linux (voir Tomas Winkler pilote RPMB en amont ).
Ensuite, prenons l'accès en écriture à RPMB comme exemple, TEE utilisera la clé RPMB pour signer les données RPMB et enverra les données RPMB avec la signature d'authentification HMAC-SHA256 (MAC) à Linux via IPC = (entre le monde sécurisé TEE et le monde non sécurisé Linux), le pilote du noyau Linux est responsable de l'envoi de ce morceau de données (alias trame RPMB) ensemble vers le périphérique physique RPMB pour l'écriture d'authentification.
Quant à la protection REPLAY, elle peut être obtenue comme ceci pour l'accès en lecture/écriture: le compteur d'écriture monotone intégré du contrôleur de stockage H/W est utilisé pour la protection contre la lecture sur l'accès WRITE, chaque fois qu'une écriture authentifiée réussit, l'écriture H/W le compteur est augmenté de 1 (initialement, il est nul), donc tout accès en écriture relu sera rejeté car le compteur d'écriture ne peut jamais être diminué. Cela peut garantir la fraîcheur des données, cependant, une fois que le compteur atteint sa valeur maximale (32 bits), tout accès en écriture sera refusé (cela signifie que le RPMB sera un stockage en lecture seule);
Bien que le numéro aléatoire généré par le logiciel (nonce) soit utilisé pour la protection contre la lecture lors de l'accès en lecture, car lors de l'accès en lecture, le logiciel dans TEE est responsable de l'authentification des données et de la vérification de leur actualité, il ne doit jamais utiliser le même nonce ou un mauvais aléatoire générateur de nombres pour générer un nonce pour empêcher la relecture des données pour l'accès en lecture.
Pour plus de détails, vous pouvez voir mon discours dans Linux Security Summit Europe 2018: Implement Android Stockage sécurisé inviolable et sécurisez-le dans la virtualisation), dans cette diapositive, en passant, il parle également d'une des solutions de virtualisation RPMB en plus de hyperviseur si cela vous intéresse.
J'espère que cela t'aides.