Dmitry Sklyarov - Intel ME: Security keys Genealogy, Obfuscation and other Magic

The Intel Management Engine (ME) technology was introduced in 2005. Though more than 10 years have passed, it is still very hard to find any official information about ME on the Internet. In my presentation, I will explain in detail how ME 11.x uses platform keys. I will also talk about cryptographic primitives that ME 11.x supports.

Transcript

1. Intel ME: Security keys Genealogy,
   Obfuscation and other Magic
   Dmitry Sklyarov
   Head of Reverse Engineering
   

   View Slide

2. Research Team
   Date Presentation/Paper name Mark Ermolov
   Maxim Goryachy
   Dmitry
   Sklyarov
   2016-12-28 Tapping into the Core +
   2017-03-23 Intel ME: The Way of the Static Analysis +
   2017-04-14 Intel DCI Secrets +
   2017-08-28 Disabling Intel ME 11 via undocumented mode +
   2017-11-09
   Where there's a JTAG, there's a way: obtaining
   full system access via USB
   +
   2017-12-06
   How to Hack a Turned-Off Computer, or Running
   Unsigned Code in Intel Management Engine
   +
   2017-12-06 Intel ME: Flash File System Explained +
   2017-12-06 Recovering Huffman tables in Intel ME 11.x +
   2017-12-27 Inside Intel Management Engine +
   Defcon Russia (DCG #7499) 2
   

   View Slide

3. Agenda
   • Security Hardware Overview
   • Security Fuses
   • Keys Derivation and Storage
   • Fun and Magic
   Defcon Russia (DCG #7499) 3
   

   View Slide

4. ME Position in Computer System
   Defcon Russia (DCG #7499) 4
   Intel AMT Release
   2.0/2.1/2.2
   Architecture
   Management Engine (ME)
   System Management Mode (SMM)
   Hypervisor
   OS Kernel
   User
   Full control
   Limited interfaces
   

   View Slide

5. SECURITY HARDWARE OVERVIEW
   

   View Slide

6. Intel ME: Security Hardware
   AES
   Engine
   [DMA]
   SHA/HMAC
   Engine
   [DMA]
   RSA
   Engine
   Secure
   Key
   Storage
   (SKS)
   SPI Flash
   +Huffman
   [DMA]
   Security
   Fuses
   RAM
   RC4
   Engine
   Defcon Russia (DCG #7499) 6
   

   View Slide

7. SPI Flash + Controller
   • Includes BIOS/UEFI, GbE, ME partition
   • Holds code and configuration
   • Could operate in conjunction with HMAC Engine
   • Has a built-in Huffman Decompressor
   Defcon Russia (DCG #7499) 7
   

   View Slide

8. Secure Key Storage (SKS)
   • Slots 1..11 for 128-bit keys, slots 12..21 for 256-bit keys
   • Key either loaded directly or obtained as a result of
   AES/HMAC
   • Saved keys can’t be extracted into memory (only used
   for AES/HMAC)
   • Usage policy are supported (e.g. result of AES Encrypt
   could be stored into memory or SKS, result of AES
   Decrypt – only into SKS)
   Defcon Russia (DCG #7499) 8
   

   View Slide

9. AES Engine
   • Keys of 128 and 256 bits are supported
   • Supported block chaining modes: ECB, CBC, CTR
   • AES keys could be specified directly or obtained
   from SKS
   • Data could be transferred directly or with DMA
   Defcon Russia (DCG #7499) 9
   

   View Slide

10. SHA/HMAC Engine
    • Supported hash algorithms: SHA-1, SHA-256, SHA-384,
    SHA-512
    • HMAC key length either 128 or 256 bits
    • HMAC keys could be specified directly or obtained from SKS
    • Data could be transferred directly or with DMA
    • Could operate in conjunction with AES Engine (e.g. Decrypt-
    than-HMAC)
    Defcon Russia (DCG #7499) 10
    

    View Slide

11. RSA Engine
    • Capable to perform modular exponentiation
    • Used for verification of Digital Signatures (e.g.
    ROM verifies ME Partition Manifest integrity
    before using any data from that partition)
    Defcon Russia (DCG #7499) 11
    

    View Slide

12. Partition Manifest data
    Module Metadata
    Module Data
    Module Attributes Extension
    SHA256(Module Data)
    Partition Info Extension
    SHA256(Module Metadata)
    Partition Manifest
    SHA256(Module data)
    Header
    RSA Signature
    SHA256(Partition Manifest
    Header + Data)
    RSA Public Key
    ROM
    List of allowed
    signature keys
    SHA256(RSA Public Key)
    RSA Private Key
    RSA Engine Application
    Defcon Russia (DCG #7499) 12
    

    View Slide

13. RC4 Engine
    • Is it really necessary in HW developed in
    2012+?
    • Not used for providing security of ME itself
    • Probably used by ME applications (for
    supporting WiFi, SSL, etc.)
    Defcon Russia (DCG #7499) 13
    

    View Slide

14. SECURITY FUSES
    

    View Slide

15. Security Fuses
    • Initialized at [some] production stage
    • Unique values for each PCH-chip (at least, we believe in that)
    • Can not be overwritten
    • Readable limited number of times (usually just once) after platform
    reset
    • Huge part of ME security is based on confidentiality of fuses (e.g.
    TPM)
    • Partially blocked if JTAG is enabled (even Intel’s engineers can’t get
    fuses)
    Defcon Russia (DCG #7499) 15
    

    View Slide

16. Reading Data from Fuses
    void __cdecl GetKey(T_KeysInfo *pKI) {
    unsigned int size, *pdw;
    GEN_status_reg = 1;
    while ( GEN_status_reg & 1 );
    if ( GEN_status_reg & 8 ) stage_complete(Ev_Gen_BadStatus, GEN_status_reg, 0);
    else {
    size = (GEN_status_reg >> 0x10) & 0x1FF;
    if ( size == 0x9C ) {
    pdw = (unsigned int *)&GEN;
    .... // Copy bytes from GEN to Memory
    }
    else if ( size == 0x10 ) {
    if ( isOrangeUnlock()) { // JTAG for vendor is enabled
    stage_complete(Ev_Gen_NotLoaded,(MEMORY[0xF00B1050] >> 4), 0);
    }
    else {
    *(_DWORD *)pKI->NonIntelKey = *(_DWORD *)GEN.NonIntelKey;
    *(_DWORD *)&pKI->NonIntelKey[4] = *(_DWORD *)&GEN.NonIntelKey[4];
    *(_DWORD *)&pKI->NonIntelKey[8] = *(_DWORD *)&GEN.NonIntelKey[8];
    *(_DWORD *)&pKI->NonIntelKey[12] = *(_DWORD *)&GEN.NonIntelKey[12];
    stage_complete(Ev_Gen_LoadedShort, 0, 0);
    }
    Defcon Russia (DCG #7499) 16
    

    View Slide

17. Security Fuses Layout
    Wrapped HMAC Key Wrapped EPID Key
    0 0x20
    0x40 0x48
    EPID Non Intel Root Key
    fTPM[0..3] CheckSum
    0x70
    fTPM[4..67]
    0x80
    0x40
    0x44 0x4C
    Not used
    0x80
    0xBC
    Completely unknown (for us) value
    We are able to get unwrapped value
    Could be recovered from data available at runtime
    Available on platform that started with JTAG activated
    Defcon Russia (DCG #7499) 17
    

    View Slide

18. KEYS DERIVATION AND STORAGE
    

    View Slide

19. FS Security Keys
    Intel
    Integrity
    Intel
    Confidentiality
    Non-Intel
    Integrity
    Non-Intel
    Confidentiality
    Intel
    Integrity
    Intel
    Confidentiality
    Non-Intel
    Integrity
    Non-Intel
    Confidentiality
    RPMC
    HMAC #0
    RPMC
    HMAC #1
    Current keys
    (for current SVN)
    Previous* keys
    (optional)
    Replay-Protected Monotonic Counter (RPMC)
    is optional feature of SPI Flash chip
    *Previous keys are calculated if
    current SVN > 1 and PSVN partition
    contains valid data.
    These keys are used for migrating files
    created before the SVN was updated.
    There are up to 10 keys involved in FS Security
    Defcon Russia (DCG #7499) 19
    

    View Slide

20. Keys Derivation: File System (ROM)
    AES Decrypt SKS[12]
    WR HMAC Key
    “\x00”*32 (?)
    HMAC
    HMAC
    AES Wrap
    SKS[1]
    Non Intel Root Key HMAC
    “CSE Non-Intel Root Key”+SVN
    AES Wrap
    “CSE Intel Root Key”+SVN
    “CSE Wrapping Key”
    SKS[21]
    curr_keys
    (Intel)
    curr_keys
    (non-Intel)
    Security Fuses
    Key
    Data in RAM
    Key in SKS
    Temporary data
    Data
    Temporary key in SKS
    Defcon Russia (DCG #7499) 20
    

    View Slide

21. Keys Derivation: File System (BUP)
    curr_keys
    (Intel)
    curr_keys
    (non-Intel)
    HMAC
    AES Unwrap Key
    HMAC Key
    AES Wrap
    AES Wrap
    AES Wrap
    AES Wrap
    FS
    Keys
    HMAC
    AES Unwrap Key
    HMAC Key
    “Confidentiality Intel Key”
    “Integrity Intel Key”
    “Confidentiality Non-Intel Key”
    “Integrity Non-Intel Key”
    SKS[21]
    SKS[21]
    Key
    Data in RAM
    Key in SKS
    Temporary data
    Data
    Defcon Russia (DCG #7499) 21
    

    View Slide

22. Keys Derivation: Enhanced
    Privacy ID (EPID)
    AES Decrypt SKS[12]
    WR HMAC Key
    “\x00”*32 (?)
    HMAC
    SKS[1]
    WR EPID Key
    SKS[21]
    epid_keys
    Security Fuses
    AES Decrypt AES Wrap
    HMAC
    “CSE Memory Guard Key”+SVN
    SKS[18]
    “CSE Wrapping Key”
    Defcon Russia (DCG #7499) 22
    Key
    Data in RAM
    Key in SKS
    Temporary data
    Data
    Temporary key in SKS
    

    View Slide

23. Keys Derivation: fTPM Keys
    AES Decrypt SKS[12]
    WR HMAC Key
    “\x00”*32 (?)
    HMAC
    SKS[1]
    fTPM
    “CSE Wrapping Key”
    SKS[21]
    ftpm_keys
    AES Wrap
    HMAC
    “CSE Memory Guard Key”+SVN
    SKS[18]
    HMAC
    “CSE fTPM Root Key”
    Key
    Data in RAM
    Key in SKS
    Temporary data
    Data
    Temporary key in SKS
    Security Fuses
    Defcon Russia (DCG #7499) 23
    

    View Slide

24. Keys Derivation and Storage
    Summary
    • Security keys never holds in memory in plaintext
    • Usually wrapped by SKS[21] or SKS[18]
    • Almost all keys depends on Wrapped HMAC Key (which
    unavailable)
    • Having Code Execution in BUP we could recalculate some
    keys (but not Wrapped/Unwrapped HMAC Key == SKS[12])
    • Even Intel’s engineers (with JTAG) are unable to get HMAC
    key
    Defcon Russia (DCG #7499) 24
    

    View Slide

25. FUN AND MAGIC
    

    View Slide

26. IVBP (IVB Partition)
    • System partition for «warm» starting (like
    hibernation restoration)
    • Encrypted, integrity protected with HMAC
    • Unique for each platform (PCH-chip) and each
    boot
    • If you know IVBP key, you have arbitrary execution
    on this platform
    Defcon Russia (DCG #7499) 26
    

    View Slide

27. Keys Derivation: IVBP Key
    AES Decrypt SKS[12]
    WR HMAC Key
    “\x00”*32 (?)
    HMAC
    SKS[1] SKS[19]
    “CSE Provisioning Base Key” + SVN
    Defcon Russia (DCG #7499) 27
    Security Fuses
    Key
    Data in RAM
    Key in SKS
    Temporary data
    Data
    Temporary key in SKS
    

    View Slide

28. ROM: Boot stages (it’s about IDLM)
    start
    Is partition
    signature OK?
    Find Partition
    BootPart[idx]
    Yes
    idx == 0?
    Yes
    Lock Fuses
    BootPart = {DLMP:idlm,
    FTPR:rbe, FTUP:rbe}
    idx = 0
    idx ++
    Read module
    PartName[idx]
    Is module
    hash OK?
    Derive
    Keys
    Yes
    Execute
    «rbe»
    idx <= 2?
    end
    Yes
    Execute
    «idlm»
    Defcon Russia (DCG #7499) 28
    

    View Slide

29. IDLM module (DLM Partition)
    • The only place (except ROM) where data read from
    Fuses is available
    • IDLM must be signed with RSA-2048
    • SHA-256 for 8 Public RSA Keys are hardcoded in ROM
    • 4 of 8 keys can be used for IDLM signing (on tested platforms)
    • Owner of permitted RSA signing key can extract HMAC
    key with IDLM!
    • IDLM partition seen “in the wild” on ME 11.8 (svn 3)
    releases
    Defcon Russia (DCG #7499) 29
    

    View Slide

30. Conclusion
    • Intel’s engineers implemented complex and well-
    thought-out security model for handling keys
    • Even Code Execution (in any place except ROM) do not
    give an attacker the ability to fully compromise security
    model
    • But IDLM feature looks like backdoor ;)
    • And who knows – are Fuses Data really unique and
    unpredictable?
    Defcon Russia (DCG #7499) 30
    

    View Slide

31. Thank You!
    Dmitry Sklyarov
    Head of Reverse Engineering
    

    View Slide

32. BONUS SLIDES
    

    View Slide

33. ROM bypass vs ROM
    ROM bypass
    ROM
    parity = check_parity(&g_KeysInfo, 8);
    if ( parity == (g_KeysInfo.check & 1) {
    pBuf.pb = (unsigned __int8 *)&g_KeysInfo;
    pBuf.cb = offsetof(T_KeysInfo, unused);
    SHA256(&pBuf, SHAF_Final|SHAF_Init);
    pBuf.pb = hash;
    pBuf.cb = 32;
    SHA256_GetResult(hash, 0);
    b1 = (LOBYTE(g_KeysInfo.check) >> 1) & 1;
    if ( b1 != is_bit((unsigned int *)hash, 32u)
    || (b2 = (BYTE(g_KeysInfo.check) >> 2) & 1, b2 != is_bit(hash, 69u))
    || (b3 = (BYTE(g_KeysInfo.check) >> 3) & 1, b3 != is_bit(hash, 109u))
    || (b4 = (BYTE(g_KeysInfo.check) >> 4) & 1, b4 != is_bit(hash, 239u))
    )
    parity = check_parity(&g_KeysInfo, 0x12);// 0x48 bytes
    if ( odd == (g_KeysInfo.check & 1) ) {
    pBuf.d.pb = (unsigned __int8 *)&g_KeysInfo;
    pBuf.cb = 72;
    SHA256(&pBuf, SHAF_Final|SHAF_Init);
    SHA256_GetResult(hash, 0);
    key.u.pb = hash;
    key.location = KEY_IN_MEM;
    key.cb = 0x20;
    out.location = KEY_IN_MEM;
    out.u.pdw = adw_mask;
    out.cb = 32;
    data.d.pb = "CSE_PART_ID";
    data.cb = 0x20;
    ROM_HMAC_derive_key(&key, &out, 0, &data);
    b1 = (LOBYTE(g_KeysInfo.check) >> 1) & 1;
    if ( b1 != is_bit(adw_mask, 2u)
    || (b2 = (BYTE(g_KeysInfo.check) >> 2) & 1, b2 != is_bit(adw_mask, 28u))
    || (b3 = (BYTE(g_KeysInfo.check) >> 3) & 1, b3 != is_bit(adw_mask, 47u))
    || (b4 = (BYTE(g_KeysInfo.check) >> 4) & 1, b4 != is_bit(adw_mask, 72u))
    )
    Defcon Russia (DCG #7499) 33
    

    View Slide

34. Some Initial Value for AES Engine
    (in ROM)
    Defcon Russia (DCG #7499) 34
    st260 = AES_r_st260;
    st264 = AES_r_st264;
    AES_r_secret[0] = 0xE103F8A3;
    AES_r_secret[1] = 0xA4B79CD6;
    AES_r_secret[2] = 0x56216728;
    AES_r_secret[3] = 0x30E039B6;
    if ( g_gen_cfg[0] & 4 )
    {
    st260 = AES_r_st260 & ~0x12u;
    st264 = AES_r_st264 | 1;
    }
    AES_r_st260 = st260 & ~1u;
    AES_r_st264 = st264;
    

    View Slide

35. Some hardcoded key for AES Engine
    (in Crypto)
    if ( byte_6584F & 1 )
    {
    v6 = getDW_sel(devAES, 0x260u);
    putDW_sel(15, 0x260u, v6 | 4);
    }
    else
    {
    putDW_sel(devAES, key0, 0x09CF4F3C);
    putDW_sel(devAES, key4, 0xABF71588);
    putDW_sel(devAES, key8, 0x28AED2A6);
    putDW_sel(devAES, keyC, 0x2B7E1516);
    }
    putDW_sel(devAES, 0, (*(_BYTE *)a3 == 0) << 6);
    Defcon Russia (DCG #7499) 35
    

    View Slide