Secure Device Recovery Using OCP Recovery

Secure Device Recovery Using OCP Recovery

Eric Spada and Varun Sampath present the OCP Secure Recovery concept and specification. It focuses on how to recover a device when it fails to boot, becomes unresponsive, or is suspected to be in a bad/compromised security state.

Why Secure Recovery Is Needed

• Silicon vendors’ devices can fail to boot or become unresponsive.
• The OCP Security group’s resilience guidance (referred to as OCP Platform Resiliency / “193”) says recovery is important, but it doesn’t provide enough implementation guidance.
• The goal of this OCP recovery work is to define an out-of-band (OOB) recovery mechanism that can:
  • Detect the device is in a bad state
  • Move it back into a known secure state
  • Use a known-good set of firmware
  • Restore compliance, especially when normal firmware update paths may be broken or unsafe

Core Design Goals and Product/Security Features

• Out-of-band recovery mechanism (primary goal of the spec)
• Recovery image security requirements:
  • The recovery image is signed with secure boot keys
  • Includes anti-rollback protection
  • Must be a full production image (not an old vulnerable “stored recovery image”)
• Minimal feature set, targeted to be implemented:
  • In hardware or ROM (to ensure it reaches a known secure anchor)
• Interoperability / coexistence:
  • Works alongside OCP standards and messaging approaches (notably MCTP over SMBus and NVMe-based OOB management patterns are mentioned)
• Not a replacement for normal firmware upgrade:
  • Designed as a last-resort path to restore the device to compliance
• Optional force recovery:
  • The spec allows a force recovery mode mechanism.
  • Encouraged but not required, especially for devices where recovery isn’t safe (e.g., some security-critical devices must be returned/replaced)

What the Recovery Spec Does (High-Level Protocol Behavior)

The spec defines a basic recovery protocol hosted on a recovery interface, enabling:

1. Check device status/health
2. Load a recovery image into a “recovery window” via either:
   • Push: host/controller pushes an image through a memory window
   • Pull: device fetches an image from a stored region
3. Activate/execute the recovery image:
   • Execution relies on authentication using the secure boot process (including immutable ROM authentication)
4. Recovery image then performs a full firmware update to bring the device back to an operational state.

Implementation Model: 3 Logical Components

1. Recovery Agent

   • Orchestrates the recovery flow
   • Coordinates with platform secure boot / root of trust / management controller

2. Recovery Interface

   • The device-side protocol implementation
   • Includes elements like:
     • Recovery window (where the recovery image is pushed)
     • Logging for basic recovery diagnostics

3. Transport

   • Implemented today as I2C / SMBus (I3C and USB2 are discussed as possibilities)
   • PCIe-focused design is described, but other transports can be used; next iteration may refine transport choices.

Temporal Recovery Flow (Agent Perspective)

Varun outlines a step-by-step orchestration example:

1. Health check (using signals like inability to respond or failed attestation)
2. Enter recovery:
   • Either force recovery (if supported)
   • Or implicit recovery (e.g., watchdog timer triggers reboot into recovery)
3. Load/push or program device to pull the recovery image
4. Activate/execute the recovery image:
   • ROM authenticates it per OCP secure boot
5. Recovery image runs the firmware update protocol (examples: PLDM firmware update, NVMe firmware update)
6. Device returns to a full operational state

“Critical Security Parameters” and Recovery Limitations

• Some devices may not be recoverable if critical parameters (per NIST guidance concepts) are missing.
• Example: systems like DICE can rely on provisioned certificates/security state stored on flash. If that state is erased/compromised, recovery may require re-provisioning rather than pure recovery.
• The spec supports modes such as:
  • Critical data intact vs.
  • Critical data not intact, which triggers the need for provisioning

How Secure Boot + Attestation Are Used Together

Recovery restores the device back to a known immutable trust anchor, then secure boot/root of trust:

• Authenticates the recovery image
• Executes recovery firmware update
• Enables subsequent attestation and compliance restoration

Additional points discussed:

• Whether chain-of-trust is re-established and re-attested after recovery (answer indicates DICE/secure boot/platform manifest relationships and spec references)
• How multiple components/ports should be treated: the platform manifest is suggested as the right mechanism for aggregating/attesting different pieces.

Commands and Data Flows

• Recovery commands are described as SMBus commands with arguments up to 255 bytes, covering:
  • Setting image payloads
  • Activating images
  • Reset procedures, etc.
• Two major flows in an example implementation:
  • Recovery data flow (load recovery image)
  • Management data flow (e.g., MCTP + PLDM firmware update, etc.)
• The root of trust processes recovery and can use controllers (e.g., SPI controller) to write firmware to flash.

Status, Availability, and Next Steps

• The spec is described as being at IC committee and reaching near-final 1.0
• Feedback is requested from device manufacturers and integrators
• A compliance checklist is included in the spec; reviewers are encouraged to add missing items
• Working with the OpenBMC community:
  • Seeking an open-source driver
  • Goal: make recovery more automatable and standardized through BMC infrastructure once reference implementations exist

Main Speakers / Sources

• Eric Spada (OCP Security group / presenter)
• Varun Sampath (colleague / presenter)

Primary cited references/standards

• OCP Platform Resiliency / “193”
• OCP Secure Boot
• OCP Attestation
• OCP Open/out-of-station concepts (mentioned as part of broader “three pillars”)
• NIST “critical security parameters” guidance
• DICE (as an example provisioning/security-state system)
• OpenBMC (for driver/integration and automation)
• Firmware update examples: PLDM and NVMe firmware update