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

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 (field- programmable 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) Intel’s Secure Boot on Client and Server During boot, CSME also sends other sensitive messages to CPU

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

Searching for a Solution: Cerberus 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

Scaling Cerberus – Beyond Servers Secure boot is essential in many segments, not just servers: client PC, phones, IoT, etc. 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 Requirements Credentials and algorithms must scale with segment CPU & RoT 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

Boot Time Performance: Optimized Two-Way Cerberus CPU as CA-RoT owns CpuKey derived from part-unique secure fuses. CPU has no NVM. CSME as PA-RoT does. Registration: runs only once. The two agreed on a shared key SK. CPU encrypts SK with CpuKey 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! Boot Time Performance: Optimized Two-Way Cerberus PA-RoT AC-RoT mutual authentication + key agreement . Result in shared key SK ( SK ) CpuKey NVM R e g i s t r a o n , CsmeNonce CpuNonce Hash E v y b

Every boot: CSME as PA-RoT has to send CsmeNonce without protection (but it’s OK) CPU as AC-RoT decrypts (SK)CpuKey and gets SK CPU derives CpuHmacKey from SK and CsmeNonce CPU generates CpuNonce and HMAC’ed with CpuHmacKey CSME and CPU both derive CsmeHmacKey from SK and CpuNonce AES keys may be derived similarly Don’t Ever Use SK Itself to Protect Messages: Securely-Optimized Two-Way Cerberus PA-RoT AC-RoT mutual authentication + key agreement . Result in shared key SK ( SK ) CpuKey NVM R e g i s t r a o n , CsmeNonce [ CpuNonce ] CpuHmacKey E v y b

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

SPIRAL vs. USB Authentication Protocol Property SPIRAL USB Auth. Prot. Asymmetric operation Only during pairing / first boot Every boot Credential May be DICE or hash-based* 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.

Next Steps Present to OCP Security forum 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 SPIRAL-Lite It is very difficult for uCode to implement DICE and RIoT Core layer No hardware ECC accelerator Extreme requirements on speed and nonblocking- ness of boot Especially on client CPUs We Think All Is Good Until A Bummer. Then We Came up with SPIRAL-Lite CSME ( PA - RoT ) CPU AC DICE Cerberus SPIRAL X 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 CSME ( PA - RoT ) CPU AC Hash cert DICE Cerberus SPIRAL-Lite

SPIRAL-Lite at a Glance 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)CsmePubKey and stores SS in secure NVM. Every boot: CSME prompts CPU to derive same SS. Then the two exchange nonces and derive session keys. SPIRAL-Lite at a Glance

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-RoT <-> PA-RoT links. Flexible – use DICE credential, or hash credential where DICE is not available Lightweight – no asymmetric operations after initial pairing