L'attaque n'est peut-être pas triviale à réaliser sur une machine donnée, mais une fois que quelqu'un l'aura réalisée, d'après ce qu'indique le chercheur en sécurité qui trouvé le problème, les informations qu'on peut en dériver s'appliqueront à toutes les machines du même modèle, et pourront être utilisées pour faire des choses... intéressantes:
https://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html
indique notamment

An early-stage vulnerability in ROM enables control over reading of the Chipset Key and generation of all other encryption keys. One of these keys is for the Integrity Control Value Blob (ICVB). With this key, attackers can forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect. This is functionally equivalent to a breach of the private key for the Intel CSME firmware digital signature, but limited to a specific platform.

The EPID issue is not too bad for the time being because the Chipset Key is stored inside the platform in the One-Time Programmable (OTP) Memory, and is encrypted. To fully compromise EPID, hackers would need to extract the hardware key used to encrypt the Chipset Key, which resides in Secure Key Storage (SKS). However, this key is not platform-specific. A single key is used for an entire generation of Intel chipsets. And since the ROM vulnerability allows seizing control of code execution before the hardware key generation mechanism in the SKS is locked, and the ROM vulnerability cannot be fixed, we believe that extracting this key is only a matter of time. When this happens, utter chaos will reign. Hardware IDs will be forged, digital content will be extracted, and data from encrypted hard disks will be decrypted.

"Digital content will be extracted" sera une bonne chose, et c'est peut-être d'ailleurs de là que viendront les extractions de Chipset Keys: l'incitation est puissante.
"Data from encrypted hard disks will be decrypted" ne sera pas une bonne chose, même si j'imagine que ça s'appliquera seulement à ceux - nombreux - qui utilisent le chiffrement transparent délégué au firmware du processeur/chipset (et/ou au firmware du disque, même combat), ce qui a toujours été une mauvaise idée, certains l'ont dit bien avant qu'il soit prouvé que c'était fait n'importe comment. BitLocker n'aurait jamais dû les utiliser.
"Forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect" sera encore pire.