Security

Overview

OpenTitan's mission is to create a trustworthy, vendor-agnostic open source silicon Root of Trust (RoT) widely adopted across the industry. We do this by implementing strong logical security integrity guarantees in the hardware and firmware components, and restricting licensing of the OpenTitan trademark to those implementations conforming to OpenTitan standards.

OpenTitan Security Model Specification

The OpenTitan Security Model Specification defines the logical security properties of the discrete IC. It covers device and software attestation, provisioning, secure boot, chip lifecycle, firmware update, chip identity, and chip ownership transfer.

Logical Security Model

The OpenTitan Security Model provides a high level framework for device provisioning and run-time operations. It starts by enumerating the range of logical entities supported by the architecture, and their mapping into software stages. Runtime isolation properties and baseline identity concepts are introduced in this document.

Secure Hardware Design Guidelines

Silicon designs for security devices require special guidelines to protect the designs against myriad attacks. To that end, the team established Secure Hardware Design Guidelines which are followed when developing OpenTitan security IP.

Functional Guarantees

At the functional level OpenTitan aims to provide the following guarantees:

  • Silicon Owners shall be able to deploy their own Root of Trust (RoT) Public Key Infrastructure (PKI) after taking ownership of the device.
  • Silicon Creators shall endorse the authenticity of the hardware. Endorsement is contingent on the silicon adhering to the physical implementation guidelines and standard requirements stipulated by the project. The endorsement shall be measurable via a Transport Certificate.
  • OpenTitan shall provide full boot attestation measurements to allow Silicon Owners to verify the boot chain configuration. The attestation chain shall be anchored in the Silicon Owner's RoT PKI.
  • OpenTitan shall provide a key manager implementation strongly bound to the boot chain. Only a boot chain signed with the expected set of keys shall be able to unlock stored keys/secrets.
  • OpenTitan shall provide a key versioning scheme with support for key migration bound to the firmware versioning and update implementation.

Use Cases

The security goals of the project are derived from a list of target use cases. The security goals are used to define OpenTitan's threat model, as well as functional and assurance security requirements. Such requirements influence the system architecture, as well as the certification strategy for silicon implementations.

Security Primitives

All hardware security primitives adhere to the OpenTitan comportable peripheral interface specification. Implementations for some of these components are available for reference and may not meet production or certification criteria yet.

Entropy source

Digital wrapper for a NIST SP 800-90B compliant entropy source. An additional emulated entropy source implementation will be available for FPGA functional testing.

CSRNG

Cryptographically Secure Random Number Generator (CSRNG) providing support for both deterministic (DRBG) and true random number generation (TRNG).

The DRBG is implemented using the CTR_DRBG construction specified in NIST SP 800-90A.

AES

Advanced Encryption Standard (AES) supporting Encryption/Decryption using 128/192/256 bit key sizes in the following cipher block modes:

  • Electronic Codebook (ECB) mode,
  • Cipher Block Chaining (CBC) mode,
  • Cipher Feedback (CFB) mode with fixed data segment size of 128 bits,
  • Output Feedback (OFB) mode, and
  • Counter (CTR) mode.

HMAC

HMAC with SHA-2 FIPS 180-4 compliant hash function, supporting both HMAC-SHA256 and SHA256 modes of operation.

Key Manager

Hardware backed symmetric key generation and storage providing key isolation from software.

OTBN

Public key algorithm accelerator with support for bignum operations in hardware.

Alert Handler

Aggregates alert signals from other system components designated as potential security threats, converting them to processor interrupts. It also supports alert policy assignments to handle alerts completely in hardware depending on the assigned severity.