This blog describes writing data into OPTIGA™ Trust M objects. Objects are dedicated slots of memory where data can be read from and written to. Each object can be referenced using the Object Identifier (OID).
Figure 1 OPTIGA™ Trust M (V3): Overview data and key store
OPTIGA™ Trust M V3 supports the following objects as shown in Figure 1. The host device must secure the data objects by moving them into OPTIGA™ Trust M or generate them on OPTIGA™ Trust M itself.
Common data objects
Objects which are common and globally used such as error codes
Cryptographic data and key objects
Objects which are short-lived and used only in sessions and not stored persistently, such as session keys
Application specific data objects
User application on the host MCU (e.g., PSoC™, Arduino) can use and manipulate these objects according to their use cases.
This blog explains the “Write Data” operation by describing each OID in cryptographic data, key objects, and application-specific data.
Note: The following key objects cannot be written using the “Write Data” interface:
2 Cryptographic data objects
Key objects store private keys (asymmetric crypto – RSA, ECC) and secret keys (symmetric crypto – AES). The host device cannot store private or secret keys into these objects using the “Write Data” interface. These keys are stored automatically by OPTIGA™ Trust M when the keys are generated using the “Key Generation” interfaces of OPTIGA™ Trust M. This is a feature and not a bug, as it may compromise the security of OPTIGA™ Trust M.
The following are the cryptographic data objects:
2.1 Public key certs 1-4 (OID 0xE0E0 – 0xE0E3):
The user can write/store up to 1728 bytes of x.509 v3 certificates persistently (in non-volatile memory or NVM). The certificates must be DER (Distinguished Encoding Rules)-encoded, which means that they are in binary format as compared to the PEM (Privacy Enhanced Mail) format, which is in ASCII). A chain of certificates can also be stored in an object.
For example, if one certificate in a chain has 400 bytes, up to four such certificates (total 4*400 byte = 1600 byte) can be stored in the 0xE0E1 object.
In Figure 1, the OID 0xE0E0 is Infineon-provisioned. The OID contains a public key certificate, which is used to identify the device (known as “device identity”) configured by Infineon. The customer can either use this certificate to identify the device or they can provision their own certificate.
These OID slots can store certificates which are used to establish the device identity.
For example, consider an Arduino device as the host and OPTIGA™ Trust M as its secure discrete hardware connected via I2C. This Arduino device intends to use different identities for different use cases. It uses the 0xE0E0 slot to store a single certificate to identify itself to a web server. It uses 0xE0E1 with a certificate chain of depth 4, to identify itself to respective peers on a local area network.
This is how the previously mentioned certificate slots (objects) can be used in a several scenarios.
2.2 Trust Anchors 1-2 (OID 0xE0E8 – 0xE0E9)
The user can write/store up to 1200 byte of x.509 v3 certificate persistently (DER encoded). These objects can store only one certificate up to 1200 byte and not a chain. Trust Anchor slots contain a single certificate that is used for use cases like signature verification and establishing the root of trust.
For example, if the Arduino or PSoCTM host device intends to verify the signature of its new firmware image, it can store the corresponding public key certificate in Trust Anchor objects, which are later referenced during signature verification.
2.3 Trust Anchor 8 (OID 0xE0EF)
Trust Anchor 8 object is a special case of Trust Anchors 1-2. The user can write the Platform Integrity certificate in this object. This OID is used to verify the integrity of OPTIGA™ Trust M during protected update process.
3 Application-specific data objects
The user can write their host-side status in OPTIGA™ Trust M. These objects do not affect OPTIGA™ Trust M’s functionality in any way; they provide more flexibility to the host and maintain their own set of secure data and rules.
To understand how the host can use these objects to enhance their security in their applications, consider the following application-specific data objects:
3.1 Application Lifecycle Status (OID 0xF1C0)
Users can write their application-specific lifecycle status here and use it accordingly. The data in this slot is persistent. An example is when the application must control the access based on the stored lifecycle status.
3.2 Security Status (OID 0xF1C1)
Users can write their application-specific security status. For example, the application sets the security status to ‘0’ to indicate that security state does not qualify for further use.
3.3 Error Codes (OID 0xF1C2)
This object is an outlier for the “Write Data” operation. The user cannot write into this, but can read the error codes provided by OPTIGA™ Trust M.
3.4 Arbitrary Data Type 2 (OID 0xF1E0 - 0xF1E1)
Users can write any arbitrary data to handle securely and persistently. Type 2 can store up to 1500 bytes of data in each object.
For example, the Arduino host can store the Social Security Number of the user's family.
3.5 Arbitrary Data Type 3 (OID F1D0 - 0xF1DB)
Users can write any arbitrary data to handle securely and persistently. Type 3 can store up to 140 bytes of data in each object. This is similar to Type 2, but of lower capacity.
OPTIGA™ Trust M provides a set of conditions to execute, write, and read. For more details access conditions, see the solution reference manual. Visit the GitHub repository for code examples and more details.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.