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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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.

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

13. Backup

14. 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

15. 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

16. 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