Attestation is the mechanism in which software verifies the authenticity and integrity of the hardware and software of a device. OpenTitan supports the following attestation mechanisms:
Creator Based Attestation (Creator Identity Certificate)
It is used to attest the authenticity of the hardware, the configuration of the first two firmware boot stages, as well as the unique device key known as the Creator Identity. The attestation is captured in a certificate signed with a Silicon Creator intermediate Certificate Authority (CA) key, which can be validated using Public Key Infrastructure (PKI). Alternatively, the certificate can be self-signed and verified against the Creator Identity public key and a trustworthy device registry.
Owned Device Attestation (Owner Identity Certificate)
It is used to attest ownership of the device, the BL0 configuration, as well as the Owner Identity key which is used as a root attestation key managed by the Silicon Owner. The attestation certificate is signed with the device's Creator Identity key, forming an attestation chain to the Creator Identity certificate.
A Silicon Owner can endorse the Owner Identity Certificate with its own intermediate CA key as soon as it takes ownership of the device. This way device attestation can be verified against the Silicon Owners' PKI of choice.
Boot stages:
ROM: Metal ROM, sometimes known as Boot ROM.ROM_EXT: ROM Extension. Stored in flash and signed by the Silicon Creator.BL0: Bootloader. Signed by the Silicon Owner.KERNEL: Signed by the Silicon Owner.Device attestation is rooted in two asymmetric keys named Creator Identity and Owner Identity. The Asymmetric Keys section provides details on the cryptographic properties of these keys.
The Creator Identity is generated at manufacturing time and it is endorsed by the Silicon Creator PKI. This key is used to sign certificates endorsing the authenticity of the physical device, the ROM and ROM_EXT configuration (see Creator custom Extension for more details), as well as the Owner Identity public key.
The Owner Identity is generated at ownership transfer time, or whenever there is a change to the BL0 software binding tag. The Owner Identity is used to attest the owner and BL0 configuration, as well as an attestation key used by the Kernel. This key is endorsed by the Creator Identity, but can also be endorsed by the Silicon Owner PKI. Endorsement of the Owner Identity with the Owner's PKI, is covered in detail in the Owner Personalization process described in the provisioning specification.
When using a Silicon Owner PKI, the Owner is expected to maintain a device registry with Creator Identity to Owner Identity certificate mappings to handle certificate revocations issued by the Silicon Creator.
Application specific attestation keys are expected to be endorsed by the Owner Identity and managed by the Kernel. The format of the attestation certificate is outside the scope of this document.
There are two possible attestation chains. Creator based attestation provides a chain to the Creator PKI, which is useful when testing the authenticity of the device. After ownership transfer, the Silicon Owner may opt to switch to its own PKI by endorsing the Owner Identity. On-Device certificates are stored in a flash region accessible to all boot stages including the kernel stage. Additional storage is required to store the Owner Identity certificate endorsed by the Silicon Owner PKI.
The kernel may opt to extend the attestation chain based on application level requirements. See also the Privacy Considerations section for specific cases in which extending the attestation chain is recommended.
The Silicon Creator may opt to implement a self-signed Creator Identity certificate, which must be verified against a device registry. Self-signed certificates can be revoked at a finer level of granularity, and allow for in-field certificate rotation as a result of break-glass ROM_EXT updates[^1].
The Silicon Owner only needs to trust the registry during Creator Based attestation. This is no different than having to trust the Silicon Creator PKI. As a result, the following requirements are imposed on the device registry:
Updates to the attestation chain can be handled via an explicit command during the boot sequence, or via an implicit update-after-check mechanism.
In this case, attestation updates are handled by a command encoded in a scratch register that lives outside of the CPU reset domain. The following table describes the sequence of operations required to update the certificate attestation chain, which may require generation of new attestation keys.
The attestation command requires a BOOT_SERVICE_REQUEST reset to allow the ROM_EXT component to sign the new attestation chain. This is because OpenTitan's isolation model does not provide a way for the ROM_EXT to maintain its secrets isolated from BL0 or the kernel layers. Once the ROM_EXT is done using its secrets, it must wipe them from memory before handing over execution to later stages.
Note: The Creator Identity key is not derived on regular boot flows. It is only derived as a result of the execution of the attestation command.
Note: The format of the attestation certificate is controlled by the owner and outside of the scope of this specification.
The ROM_EXT may trigger automatic attestation updates by performing an Owner Identity attestation check at boot time:
measurement = MAC(KM_VersionedKey, OwnerIdentityCertificate || OwnerIdentitySeed || FixedInfo) update_cert = measurement XOR cached_measurement
The Owner Identity certificate needs to be updated if update_cert evaluates to a non-zero value. The measurement is a MAC operation with the following components:
KM_VersionedKey: Symmetric versioned key extracted from key manager used as MAC key.MAC message is a concatenation of the following data:OpenTitan supports various modes of operation. The mode of operation is encapsulated in the Owner Identity certificate; thus, any given attestation chain is only valid for a single mode of operation. Secure boot makes sure that the attestation chain is only available if the device state matches the expected configuration.
In addition to this, the key manager outputs used to generate the key identifiers depend on system level measurements that reflect the mode of operation of the device. The following definitions are compatible with the OpenTitan device life cycle definitions.
The key manager provides identity values which are used to generate both the Creator and the Owner identity key pairs. The following sections describe the key manager provisioning requirements.
The Silicon Creator is in charge of provisioning the device root secrets used to generate the Creator Identity[^2].
The root secrets are defined as RootKey and DiversificationKey, which are generated by an entropy source with a security strength equivalent to the one provided by the key manager. Random number generation shall follow the recommendations from NIST 800-90A. The number of bits required for each secret is dependent on the key manager implementation details.
In addition to this, the Silicon Creator is also responsible for configuring a statistically unique non-cryptographic Device Identifier used to track the device throughout its lifecycle.
Provisioning is performed in a process referred to as personalization, which occurs at manufacturing time. Personalization is performed in a secure facility that meets the security assurance requirements of the SKU being produced.
There are two alternative methods for personalization described in the sequence diagrams below. Implementation details are outside the scope of this document. See the Device Provisioning specification for more details.
The ROM Extension is in charge of resetting the OwnerRootSecret during ownership transfer or updates to the BL0 software binding tag. The new value shall be generated by an entropy source with a security strength equivalent to the one supported by the key manager. The triggering mechanism for updating the value is covered in the Attestation Updates section.
OpenTitan uses ECDSA attestation keys conformant to FIPS 186-4. Future revisions of this specification may add support for other signature schemes.
Key identifiers are defined as follows, where SALT_CKIand SALT_OKI are 256b values defined in ROM_EXT and BL0 respectively.
CreatorKeyIdentifier = MAC(SALT_CKI, CreatorIdentitySeed) OwnerKeyIdentifier = MAC(SALT_OKI, OwnerIdentitySeed)
The following keygen mechanism employs a DRBG instantiated with a fixed entropy pool.
// Seed length compliant with NIST 800-90A section 10. // For CTR_DRBG with AES-256 the minimum seed length is 384. FIXED_ENTROPY_SEED = least 384b stored in flash // This mode of operation in hardware is being tracked via a feature // request: https://github.com/lowRISC/opentitan/issues/2652 // The implementation may opt for supporting this in a software // based DRBG, as long as performance requirements are met. drbg_ctx = DRBG_init(FIXED_ENTROPY_SEED, key_identifier) do: c = DRBG_generate(drbg_ctx) while c > curve_order - 2 private_key = c + 1 public_key = private_key * G
Requirements:
| Security Strength | ECDSA |
|---|---|
| 128 | NIST_P256 |
| 196 | NIST_P384 |
| 256 | NIST_P521 |
key_identifier is set to the output of the key manager. See the table below for more details.FIXED_ENTROPY_SEED is extracted from the DRBG and stored in flash. The software shall ensure isolation of this value to enforce the visibility settings described in the table below.To avoid the need for a FIXED_ENTROPY_SEED, the attestation keys may be generated directly from a true entropy source fed into the DRBG. Once the key is generated, it has to be wrapped for storage with a key extracted from the key manager. In this approach, the key_identifier parameter does not need to be provided by the key manager.
// Initialize DRBG with True RNG source. drbg_ctx = DRBG_init(personalization_string=key_identifier) do: c = DRBG_generate(drbg_ctx) while c > curve_order - 2 private_key = c + 1 public_key = private_key * G // Initialize the key manager to extract a storage key. kmgr = keymgr_init() // Advance to required key manager stage (one-way state change) keymgr_advance_state(kmgr) // Generate versioned key used to wrap the |private_key|. The // |wrapping_key| may have to be split into shares before loading // into AES. The wrapping key is bound to the key manager software // binding and max key version configuration. wrapping_key = keymgr_generate_vk(kmgr, key_version, key_id) // The wrapping key shall be stored with additional metadata to // facilitate unwrapping. wrapped_key = AES_256_CTR(wrapping_key, iv, private_key)
Certificates stored in the device adhere to standard X.509 format, meeting the profile specification requirements from RFC 5280, and the Open DICE profile specification.
The following key identifiers are generated using a MAC based one-step key derivation function as specified in NIST 800-56C. The SALT_ID parameter is configured by software.
The TBSCertificate field contains the subject of the certificate and the CA issue information. The following fields are required:
The result value shall be a positive integer upto 20 octets in size.
Note: There are no identifiers available for SHA3-{256|512}.
Where id is set to the creator public key identifier in hex encoded format.
Not Before: personalization time in GeneralizedTime format.
Not After : 99991231235959Z from rfc5280 (no expiration time).
Where id is set to the creator public key identifier in hex encoded format.
Subject public key information fields associated with ECDSA signature algorithm as defined in rfc5480.
subjectKeyIdentifier (non-critical). Used to identify certificates that contain a particular public key. Set to the creator public key identifier value.keyUsage> (critical). Describes the purpose of the public key contained in the certificate. Contains only keyCertSign.basicConstraints (critical). Identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths.cA is set to TRUEpathLenConstraint not included.OpenTitan Creator Identity custom extension:
extnID: TBD. Need to determine if we need an OID for OpenTitan, or if we can allocate a new ID under the Google certificate extension domain 1.3.6.1.4.1.11129.2.1.critical: FALSEextnValue: See creator custom extension section.This extension is formatted as an ASN.1 SEQUENCE containing device identifiable information. See Privacy Considerations for additional details on how to handle privacy concerns.
Operational mode of the device.
The TBSCertificate field contains the subject of the certificate and the CA issue information. The following fields are required:
The result value shall be a positive integer upto 20 octets in size.
Where id is set to the creator public key identifier in hex encoded format.
Not Before: personalization time in GeneralizedTime format.
Not After : 99991231235959Z from rfc5280 (no expiration time).
Where id is set to the owner public key identifier in hex encoded format.
Subject public key information fields associated with ECDSA signature algorithm as defined in rfc5480.
authorityKeyIdentifier (non-critical). Used to identify certificates that contain a particular public key.keyIdentifier set to the creator public key identifier value. This is the only field needed.subjectKeyIdentifier (non-critical). Used to identify certificates that contain a particular public key. Set to the owner public key identifier value.keyUsage (critical). Describes the purpose of the public key contained in the certificate. Contains only keyCertSign.basicConstraints (critical). Identifies whether the subject of the certificate of the is a CA and the maximum depth of valid certification paths.CA is set to TRUEpathLenConstraint not included.OpenTitan Owner Identity custom extension:
extnID: TBD. Need to determine if we need an OID for OpenTitan, or if we can allocate a new ID under the Google certificate extension domain 1.3.6.1.4.1.11129.2.1.critical: FALSEextnValue: See owner custom extension section.This certificate may also contain the creator custom extension if the Owner decides to endorse this certificate with its own PKI.
ASN.1 SEQUENCE containing the following fields. The owner can extend this as needed.
The Silicon Creator may opt to implement attestation signatures over a binary manifest containing the endorsed key as well as the measurements described in the creator and owner custom extensions.
The binary manifest format must be standardized at the OpenTitan project level to ensure interoperability between silicon and software layers.
The Silicon Owner software must address any privacy concerns associated with the use of device identifiable information.
The Silicon Owner certificate, for example, is meant to be used exclusively with the Silicon Owner's infrastructure. Use cases requiring multiple identities or attestation services for multiple backends are required to derive application level identities and certificates. Such application level identities must fulfill the privacy requirements of their use cases.
OpenTitan's key manager provides a mechanism to derive multiple application level keys with lineage to the Owner Identity, without making them distinguishable from any random key. These properties allow the software implementation to bind the OpenTitan attestation to any application level attestation flows without precluding the implementation of additional privacy measures at the application level.
[^1]: In-field ROM_EXT updates performed by a Silicon Owner may invalidate the Creator Identity and its associated certificate. Without a federated device registry, new silicon owners are left to trust the Creator Identity certificate provided by the current owner to verify the authenticity of the device.
[^2]: The Creator Identity is referred to as the Unique Device Secret (UDS) in DICE terminology.