OPTIGA™ Trust M: Protected Update

[ShivaSai_S]

In this blog, we will discuss about the Protected Update process of an object for OPTIGA™ Trust M.

The metadata of an object can be changed if the Life cycle state Object (LcsO) of the object is not in operational or termination state. If the object is in operational state, use the protected update with necessary access conditions for the metadata update.

The Protected Update feature allows you to make an integrity protected update of any data object (not key objects) on the OPTIGA™ Trust M V1. OPTIGA™ Trust M V3 allows integrity and confidentiality protected update of any data objects including key objects. The following objects are excluded from the integrity protected update:

• Life Cycle Status (Global or Application)
• Security Status (Global or Application)
• Coprocessor UID
• Sleep mode activation delay
• Current Limitation
• Security Event Counter
• Last Error Code
• Maximum Com Buffer Size

Figure 1 shows the high-level structure of the updated data set for data or key objects along with manifest and the connected binary data

Figure 1 Structure of the Manifest

The coding of the structure is according to [CBOR]. The [CDDL] format for the manifest and signature structures are provided in the package.

Manifest is a top-level construct that ties all other structures together and is signed by an authorized entity whose identity is represented by a trust anchor installed in OPTIGA™. The trust anchor is addressed by its unique Object Identifier (OID), which is contained in the metadata of the manifest.

Manifest consists of the metadata in plain text, the payload or fragment binding, and the signature over metadata and payload binding. Data to be updated is organized in the form of fragments. Each fragment consists of data and hash of next fragment except the last fragment. Payload binding is the hash of the first fragment.

The integrity protection of the object data is based on the successful verification of the signature over the metadata and fragment binding hash value. 

The confidentiality protection is based on a shared secret installed at OPTIGA™. See section 6.7.1 of the Solution Reference Manual for the details regarding key derivation, encryption, and decryption.

In order to generate manifest according to [CBOR], you can use the tool present in GitHub.

Manifest generation using the CBOR tool needs inputs such as Trust Anchor OID (the public key for verification), Target OID, private key for signing the manifest, payload type (data or key or metadata), which are described in GitHub. See GitHub for sample update datasets.

Necessary access conditions for update:

1. For Metadata update, Metadata Update Descriptor tag (0xD8) with the respective trust anchor OID must be present in the target OID metadata.
2. For confidentiality protected update, Protected update descriptor tag (0x23) should be the data object type of the shared secret OID.
3. For Metadata update of an object, Reset type tag (0xF0) must be present which determines what will happen to data object.
4. The Trust anchor, which is used for verification of manifest, must contain the data object type tag with the respective tag type. For example, if you are using a 0xE0E3 as Trust Anchor for verification, the data object type tag must be of the Public key certificate type.

Metadata Update Process:

Following is an example of updating the metadata of an object with OID as 0xE0E2 (Public Key Certificate) and whose LcsO status is in operational:

1. Necessary conditions:

• As shown in Figure 2, the data followed by the Metadata Update Descriptor tag (0xD8) and Reset type tag (0xF0) are present in the metadata of the target OID, so that metadata can be updated.
  
  
  

  Figure 2 Metadata of Target OID
  

  
  
• In Figure 3, metadata of 0xE0E8 has a data object type tag (0xE8) with a value of 0x11 (Trust Anchor type), to use the stored public key certificate for signature verification.
  
  
  

  Figure 3 Metadata of Trust Anchor OID

2. Manifest generation:

• Manifest is a structure which contains metadata in plain text, payload binding, and signature over metadata and payload binding.
• Manifest is generated using the CBOR tool as follows:
  
  i.       priv_key: This specifies the path of the private key file (pem format) which is used for signing.
  ii.      trust_anchor_oid: This must containa public key certificate for the corresponding private key specified above.             This certificate stored in trust_anchor_oid is used to verify the signature. Here, we use 0xE0E8 as                                         trust_anchor_oid.
  iii.    sign_algo: This specifies the algorithm to be used for signing.
  iv.    payload_type: This specifies the type of update. Since we are doing metadata update, we specify it as metadata.
  v.     metadata: This specifies the path of metadata file (text format) which contains the metadata that has to be                     updated.
  vi.     content_reset: This specifies what should happen to data in the object if metadata is changed. Here we specify            it to change as per the reset type flag in updated metadata.
• In case of data or key update, manifest generation is done using different options described in GitHub
  
  
  

  Figure 4 Generating Manifest

• Generating Manifest
• Manifest and data fragment is generated upon successful execution as shown in Figure 4.
• Every time you want to update the metadata of a particular object, the payload version must increase. For example, if you update the metadata of an object with payload version as 3, the next time when you update the metadata of the same object, the payload version must be greater than 3.
  
  
  

  Figure 5 Generating Manifest

• Generated Manifest
• Generated manifest and fragments are passed as parameters to the Protected update API’s to start the update of an object as shown in Figure 5.

3. Protected update operations:

• Follow the sequence of operations as shown in Figure 6 for a protected update.
  
  

  
  Figure 6 Generating Manifest

• Protected Update Process
• Further the update process is done by optiga_util - Protected update APIs.
• optiga_util_protected_update_start(optiga_util_instance, manifest_version, manifest, manifest_length):
  
  i.      This operation initiates the protected update of data or key objects in OPTIGA™.
  ii.     The manifest provided will be validated by OPTIGA™.
  iii.    Upon successful validation, it checks whether the access conditions of the object permit protected update or                 not.

• optiga_util_protected_update_continue(optiga_util_instance,fragment , fragment_length): This operation sends the fragments to OPTIGA™. If number of fragments is n, the first (n-1) fragments are sent.
• optiga_util_protected_update_final(optiga_util_instance,fragment , fragment_length): This operation sends the final fragment to OPTIGA™ and finalizes the protected update of OPTIGA™ object.