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.- Owner boot stages. This document uses two stages as an example. The Silicon
Owner is free to choose other boot configurations.
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.
|
| Figure: PKI and Device Certificates |
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 updates1.
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:
- The device registry must ensure that only authenticated entities are authorized to insert certificates into the certificate list.
- There must be a mechanism for the Silicon Owner to authenticate the device registry and establish a secure connection to query certificates associated with devices transferred to its ownership.
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.
| Boot Stage | Step |
| Kernel | Queue attestation update command via scratch register write. |
| Issue reset with cause `BOOT_SERVICE_REQUEST`. | |
| System Reset | |
| ROM | Verify ROM_EXT and configure key manager ROM stage inputs. |
| Jump to ROM_EXT | |
| ROM_EXT | Verify BL0 and configure key manager ROM_EXT stage inputs. |
|
Keygen new Owner Identity asymmetric key pair if needed (see
Key Generation section).
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. |
|
| Issue a new Owner Identity certificate to endorse the Owner Identity key (see Owner Identity Certificate section). | |
| The Creator Identity key pair is cleared from memory so that it is not available to later boot stages. | |
| Jump to BL0 and promote the attestation update request by updating the scratch pad register. | |
| BL0 | Verify Kernel and configure key manager BL0 stage inputs. |
| Keygen new attestation asymmetric key pair. | |
|
Issue an attestation certificate to endorse the new attestation key. The
certificate is signed with the Owner Identity key.
Note: The format of the attestation certificate is controlled by the owner and outside of the scope of this specification. |
|
| The Owner Identity key pair is cleared from memory so that it is not available to later boot stages. | |
| Jump to Kernel and promote the attestation update request by updating the scratch pad register. | |
| Kernel | Configure key manager state inputs to unwrap attestation key. |
| Verify attestation chain against attestation key and complete attestation update request by clearing the scratch register. | |
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.MACmessage is a concatenation of the following data:- Owner Identity Certificate.
- Owner Identity Seed: Output from the key manager.
- FixedInfo: Data associated with the Owner Identity keygen operation.
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.
| Name | Value | Description |
| Not Configured | 0 | Use when the security mechanisms of the device have not been fully configured. |
| Normal | 1 |
Device in PROD lifecycle stage running production software.
|
| Debug | 2 | Device in operational state but not fully meeting the criteria of Normal mode of operation. |
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 Identity2.
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.
|
| Self-Generation: Secrets are generated inside the device under test and never leave the device. The public portion of the Creator Identity is exported so that it can be endorsed by the Silicon Creator. |
|
| Injection: This method employs a provisioning appliance, usually built with a certified HSM, capable of generating high-quality secrets at a much faster rate compared to an OpenTitan device. In this method, the secrets and Creator Identity certificate are injected into the device under test. |
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:
- Key pair generation is based on FIPS 186-4 appendix B.4. The example above follows the test candidate key generation method.
- The key size shall provide a security strength as recommended by NIST 800-57 part 1, for example:
| Security Strength | ECDSA |
|---|---|
| 128 | NIST_P256 |
| 196 | NIST_P384 |
| 256 | NIST_P521 |
- The DRBG shall be initialized with a security strength equivalent to the one supported by the asymmetric key conformant to NIST 800-133 section 4.
key_identifieris set to the output of the key manager. See the table below for more details.FIXED_ENTROPY_SEEDis 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.
| Key | Visibility | Key Identifierkey_identifier |
Entropy Generation TimeFIXED_ENTROPY_SEED |
| Creator Identity (UDS) |
ROM_EXT | CreatorKeyIdentifier | personalization (Factory) |
| Owner Identity (CDI0) |
BL0 | OwnerKeyIdentifier | Ownership Transfer |
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.
| Label | Description |
| Creator PubKey ID (UDS_ID) |
MAC_KDM(SALT_ID, CreatorIdentityPubKey, outlength=20, info="ID") |
| Owner PubKeyID (CDI_ID) |
MAC_KDM(SALT_ID, OwnerIdentityPubKey, outlength=20, info="ID") |
The TBSCertificate field contains the subject of the certificate and the CA issue information. The following fields are required:
| Field | Value |
| Version | 3 |
| Serial Number |
Creator public key identifier in ASN.1 INTEGER format.
The result value shall be a positive integer upto 20 octets in size. |
| Signature |
One of the following identifiers matching the signature and digest format.
Note: There are no identifiers available for SHA3-{256|512}. |
| Issuer | This is implementation dependent, and could be the Silicon Creator or the Silicon Owner intermediate CA. Attributes in this field should reference the intermediate CA Subject field ones in order to facilitate the certificate chain validation. |
| Validity |
Not Before: personalization time in GeneralizedTime format. Not After : 99991231235959Z from rfc5280 (no expiration time). |
| Subject |
X520SerialNumber: id
Where id is set to the creator public key identifier in hex encoded format. |
| Subject Public Key Info |
Subject public key information fields associated with ECDSA signature algorithm as defined in rfc5480. |
| Unique Identifiers | These fields are omitted. |
| Extensions |
Extensions for compatibility with Open DICE profile:
OpenTitan Creator Identity custom extension:
|
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.
| Seq. No. | Name | Encoding | Description |
| 0 | Operational Mode | INTEGER |
Operational mode of the device. |
| 1 | Device Identifier | OCTET STR | Device Identifier. |
| 2 | HASH Type | OCTET STR | HASH type used in measurements. |
| 3 | ROM Hash | OCTET STR | ROM contents hash. |
| 4 | ROM EXT Hash | OCTET STR | ROM EXT contents hash. Includes code manifest. |
| 5 | Code Descriptor | OCTET STR | ROM/ROM_EXT versioning information. |
The TBSCertificate field contains the subject of the certificate and the CA issue information. The following fields are required:
| Field | Value |
| Version | 3 |
| Serial Number |
Owner public key identifier in ASN.1 INTEGER format.
The result value shall be a positive integer upto 20 octets in size. |
| Signature |
One of the following identifiers matching the signature and digest format.
|
| Issuer |
X520SerialNumber: id
Where id is set to the creator public key identifier in hex encoded format. |
| Validity |
Not Before: personalization time in GeneralizedTime format. Not After : 99991231235959Z from rfc5280 (no expiration time). |
| Subject |
X520SerialNumber: id
Where id is set to the owner public key identifier in hex encoded format. |
| Subject Public Key Info |
Subject public key information fields associated with ECDSA signature algorithm as defined in rfc5480. |
| Unique Identifiers | These fields are omitted. |
| Extensions |
Extensions for compatibility with Open DICE profile:
OpenTitan Owner Identity custom extension:
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.
| Seq. No. | Name | Encoding | Description |
| 0 | Code Descriptor | OCTET STR | BL0 version and key manager software binding tag information. |
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.
Footnotes
-
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. ↩
-
The Creator Identity is referred to as the Unique Device Secret (UDS) in DICE terminology. ↩