1 / 16

January 2019

SPIRAL: Security Protocols for Cerberus. January 2019. Initiated for OCP by. 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

makaio
Download Presentation

January 2019

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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) During boot, CSME also sends other sensitive messages to CPU

  4. Our Concern: Man-in-the-MiddleAttack • 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 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. • 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. PA-RoT AC-RoT mutual authentication + key agreement . n o i t a r t s Result in shared key SK i g e R ( SK ) CpuKey NVM t o o ( SK ) CpuKey , ( CsmeNonce ) SK b y r e v E ( CpuNonce ) SK , Hash ( CsmeNonce ) Hash ( CpuNonce ) 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!

  9. PA-RoT AC-RoT mutual authentication + key agreement . n o i t a r t s Result in shared key SK i g e R ( SK ) CpuKey NVM t o o ( SK ) CpuKey , CsmeNonce b y r e v E [ CpuNonce ] CpuHmacKey Don’t Ever Use SK Itself to Protect Messages:Securely-Optimized Two-Way Cerberus 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

  10. DICE Cerberus SPIRAL SPIRAL PA-RoT PA-RoT AC-RoT Datacenter DICE DICE 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

  11. SPIRAL vs. USB Authentication Protocol * 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. X DICE CPU CSME Cerberus SPIRAL ( AC - RoT ) ( PA - RoT ) DICE Hash - cert CSME Cerberus SPIRAL-Lite CPU ( PA - RoT ) ( AC - RoT ) DICE 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 • 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

  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.

  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

More Related