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:
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
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.
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:
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:
Figure 2 Metadata of Target OID
Figure 3 Metadata of Trust Anchor OID
Figure 4 Generating Manifest
Figure 5 Generating Manifest
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
By technically required cookies we mean cookies without those the technical provision of the online service cannot be ensured. These include e.g. cookies supporting essential services like a smooth reproduction of video or audio footage. So called ‘functional cookies’ are also assigned belonging to this category. Functional cookies store information in order to provide you comfortable use of our online services (e.g. language selection). The legal basis for the processing of personal data by means of cookies of this category is Infineon’s legitimate interest. This includes, among other things, the interest in having a professional external presentation as well as an optimal balancing of the loads on the server due to technical reasons.
By performance and marketing cookies we mean cookies which are technically not required. We use performance and marketing cookies only if you have given us your prior consent. With such cookies, we collect information about how users interact with our website and which pages have been visited. This helps us to understand user activity on our website on an aggregated as well as on a personal level to provide you relevant content and services.