SPIRAL Security Protocols for Cerberus Initiated for OCP

SPIRAL: Security Protocols for Cerberus Initiated for OCP by January 2019 1

Outline of Talk • Intel’s Secure Boot, and problem we faced • Solving our problem using Cerberus/USB Authentication Protocol • Optimization opportunities • Practical difficulties encountered in implementation • Options to address difficulties – new SPIRAL protocol

Intel’s Secure Boot on Client and Server • During manufacturing, OEM burns into CSME’s FPF (fieldprogrammable fuses) hash of public key that verifies BIOS signature • During boot • CSME sends the public key hash to CPU • CPU verifies OEM signature on BIOS, sends result to CSME • CSME enforces policy (i. e. , platform reset) During boot, CSME also sends other sensitive messages to CPU

• The goal of a Mit. M attacker between CPU and CSME is to run his own BIOS signed with his own keypair. Our Concern: Man-in-the. Middle Attack • He could achieve his goal using one of two ways 1. Replace OEM_pubkey_hash with attacker’s public key hash 2. Alter Result from failed to passed • Similar case for other secrets Applicable to many other solutions containing a CPU and discrete Ro. T

• Cerberus: CPU authenticates to CSME using DICE credential and Cerberus protocol • Cerberus uses USB Type-C Authentication Protocol • OEM public key hash is sent to only authenticated CPU. • CSME expects to receive BIOS verification result from the authenticated CPU within certain time limit. Searching for a Solution: Cerberus • Before CPU accepts secrets from CSME, CPU needs to be assured that the secrets are coming from a legitimate CSME, not a malicious entity. • We need mutual authentication – applying Cerberus protocol (USB Type-C Authentication Protocol) both ways

• Secure boot is essential in many segments, not just servers: client PC, phones, Io. T, etc. Scaling Cerberus – Beyond Servers • Boot time performance is critical in constrained environments: client PCs, phones, sensors, wearables, etc. • Cerberus could scale to other segments with or without remote attestation. • Scalability Challenges • USB Type-C authentication protocol is not optimized for performance • Requires asymmetric credential on both endpoints • Requires asymmetric cryptography every boot • Not all CPUs can support DICE • No revocation of compromised credentials

Scalability Requirement s • Credentials and algorithms must scale with segment CPU & Ro. T constraints • Multiple credentials & algorithms schemes have to be supported • Most segments can tolerate delays in the first boot or new pairing scenarios. • Asymmetric operations could be tolerated at first boot • Subsequent boots must be faster • Solution – Symmetric operations are typically fast

• CPU as CA-Ro. T owns Cpu. Key derived from part-unique secure fuses. • CPU has no NVM. CSME as PA-Ro. T does. Boot Time Performanc e: Optimized Two-Way Cerberus • Registration: runs only once. The two agreed on a shared key SK. CPU encrypts SK with Cpu. Key and sends to CSME for secure storage. • Every boot: the two exchange SK-wrapped nonces to show both know the same SK. Session keys can then be derived from SK and nonces. • Every boot: No asymmetric operation! PA-Ro. T AC-Ro. T io n t a r t s Re g i mutual authentication + key agreement. Result in shared key SK (SK)Cpu. Key NVM t o o b y Eve r (SK)Cpu. Key, (Csme. Nonce)SK (Cpu. Nonce)SK, Hash(Csme. Nonce) Hash(Cpu. Nonce)

Every boot: Don’t Ever Use SK Itself to Protect Messages: Securely. Optimized Two-Way Cerberus • CSME as PA-Ro. T has to send Csme. Nonce without protection (but it’s OK) • CPU as AC-Ro. T decrypts (SK)Cpu. Key and gets SK • CPU derives Cpu. Hmac. Key from SK and Csme. Nonce • CPU generates Cpu. Nonce and HMAC’ed with Cpu. Hmac. Key • CSME and CPU both derive Csme. Hmac. Key from SK and Cpu. Nonce • AES keys may be derived similarly PA-Ro. T AC-Ro. T Re n o i t a r g ist mutual authentication + key agreement. Result in shared key SK (SK)Cpu. Key NVM t o o b y Eve r (SK)Cpu. Key, Csme. Nonce [Cpu. Nonce]Cpu. Hmac. Key

Why named it SPIRAL? It stands for Security Protocol with Independent Recovery Algorithms Let’s Give It a Short (and Cool) Name: SPIRAL Essentially, SPIRAL = Optimized security protocol designed for Cerberus to protect communication for PA-Ro. T and AC-Ro. T DICE AC-Ro. T Cerberus SPIRAL PA-Ro. T DICE Datacenter SPIRAL PA-Ro. T DICE

Property SPIRAL vs. USB Authenticati on Protocol SPIRAL USB Auth. Prot. Asymmetric operation Only during pairing / first boot Every boot Credential May be DICE or hashbased* DICE Revocation of compromised credentials** Standard X. 509 CRL No solution * See SPIRAL-Lite slides and whitepaper. ** SPIRAL defines a “firmware version” extension to X. 509 cert, allowing efficient revocation of compromised firmware.

• Present to OCP Security forum Next Steps • Distribute SPIRAL specification/whitepaper for OCP review • Incorporate SPIRAL in next revision of Cerberus protocol specification

Backup

We Think All Is Good Until A Bummer. Then We Came up with SPIRALLite • It is very difficult for u. Code to implement DICE and RIo. T Core layer • No hardware ECC accelerator • Extreme requirements on speed and nonblockingness of boot • Especially on client CPUs X DICE CPU (AC-Ro. T) Cerberus SPIRAL CSME (PA-Ro. T) DICE • So we have to use something else as CPU credential • It cannot be built on ECC or other complex crypto • CPU has SHA-NI, so we invented hash cert as CPU credential Hash-cert CPU (AC-Ro. T) Cerberus SPIRAL-Lite CSME (PA-Ro. T) DICE

• Shared secrets SS is derived from CPU secure fuses, CPU firmware versions, and CSME personality (e. g. , public key). SS is different for different CSME instances. • Registration: CSME decrypts (SS)Csme. Pub. Key and stores SS in secure NVM. SPIRALLite at a Glance • Every boot: CSME prompts CPU to derive same SS. Then the two exchange nonces and derive session keys.

Putting it Together • SPIRAL is a security protocol designed for Cerberus. It is built upon two-way Cerberus protocol with optimizations for performance • SPIRAL-Lite is a poor-man’s alternative of SPIRAL. Poorness is in that current client CPU cannot implement DICE as credential. • SPIRAL and SPIRAL-Lite may also be suitable for general AC-Ro. T <-> PA-Ro. T links. • Flexible – use DICE credential, or hash credential where DICE is not available • Lightweight – no asymmetric operations after initial pairing