Skip to content

CONFidence 2018: Intel ME: Security keys Genealogy, Obfuscation (Dmitry Sklyarov, Maxim Goryachy)

Dmitry SklyarovMaxim GoryachyMark Ermolov

MalwarePROIDEA Events44 minExpertOpen on YouTube ↗

Presenters detail vulnerability discovery and exploitation in CONFidence 2018: Intel ME: Security keys Genealogy, Obfuscation (Dmitry Sklyarov, Maxim Goryachy).

Summary

### Overview In this CONFidence 2018 presentation, researchers Dmitry Sklyarov and Maxim Goryachy (sharing research conducted alongside Mark Ermolov) present an in-depth analysis of the security architecture, hardware crypto engines, and key derivation genealogy within Intel Management Engine (ME) 11. Running on a separate microprocessor inside the chipset with access to system memory and peripherals, Intel ME operates autonomously even when the main CPU is powered down. Because Intel provides minimal public documentation, the researchers leveraged ROM dumps obtained via a previous buffer overflow exploit, JTAG debugging, and reverse engineering to map out ME's cryptographic internals.

### Key Topics - **Dedicated Security Hardware**: Examination of the internal ME architecture, including its isolated ~2 MB RAM, Huffman decompressor embedded in the flash controller, hardware SHA/HMAC, AES, RSA, and RC4 engines, and Secure Key Storage (SKS). - **Secure Key Storage (SKS) Policies**: Hardware key storage enforcing restricted policies where cryptographic results can be re-routed directly back into key slots rather than plain memory, preventing key leakage even under compromised software execution. - **Security Fuses as Root of Trust**: Hardware fuses burned during manufacturing provide per-platform root secrets that are isolated early during the ROM execution stage. - **Key Genealogy and SVN Rollback Protection**: Key generation pathways for file system protection, fTPM, and runtime operations driven by HMAC derivations tied to Security Version Numbers (SVN) and hardcoded strings. - **ROM Boot Flow and the IDLM Mechanism**: Execution checks across firmware partitions (FTPR, FTUP, DLMP) and the special role of the IDLM module.

### Technical Details ME relies on a multi-stage boot sequence starting from non-modifiable ROM into user-level execution, led by the Bring-Up (BUP) module and Virtual File System (VFS). Cryptographic derivation roots in fuses that are available to ROM only for a brief window before access is permanently locked: - **Hardware Engines & Key Storage**: The flash controller incorporates a hardware Huffman decompressor (for which the researchers reverse-engineered decompression tables) paired with HMAC verification. SKS holds 128-bit and 256-bit keys across designated slots (such as slot 12 and slot 21) and supports policies preventing intermediate or unwrapped keys from ever appearing in plaintext memory. - **Key Derivation Scheme**: ME utilizes a master wrapping HMAC key derived from fuses. Through AES decryption and HMAC hashing with static ASCII strings (such as `CC Wrapping Key` and `CC Internal Root Key`) combined with an SVN byte, it produces wrapping keys. To support anti-rollback without losing user data, ME derives two sets of file system keys—current SVN and previous SVN—so data can be read under older revisions and re-encrypted. - **Hibernate & Boot Partition (IVBP)**: The IVBP partition stores kernel structures for warm starts, encrypted with an AES key and verified by HMAC using unique boot seeds combined with the wrapping key and SVN. - **The IDLM Module**: During ROM initialization, the boot code checks partitions including `DLMP` for a module named `IDLM`. If found at index 0, this module executes *before* fuses are locked and wiped from memory, presenting an architectural capability for early code execution before fuse-locking occurs, provided the partition signature check passes.

### Takeaways The researchers characterize Intel ME's key management architecture as exceptionally rigorous and "paranoid," noting that keys exist in plaintext for mere moments—if at all—before being pushed into secure storage or wrapped. While an exploit allowed arbitrary code execution and selective key recovery on a specific platform at a fixed SVN, the architecture prevents attackers from extending recovered secrets to future SVNs or other machines without obtaining private Intel RSA signing keys or low-level fuse values.

Related talks