How is a secure connection established with Host microcontroller?

[Sharath_V]

Need for a shielded connection

The host microcontroller (like PSoC™ or Arduino) is connected to OPTIGA™ Trust M via the I2C interface. Secure this I2C channel in OPTIGA™ Trust M V3 (not available in V1) by establishing a secure/shielded connection between the host and OPTIGA™ Trust M..

The host device cannot generate private and secret keys outside OPTIGA™ Trust M. However, probing the I2C channel can easily collect the information on communication between the host and OPTIGA™ Trust M. To understand how this poses a serious security risk, consider the following scenario:

The host microcontroller receives an encrypted image of its firmware over-the-air (OTA). It sends this secure image to OPTIGA™ Trust M via I2C, requesting it to decrypt the image. OPTIGA™ Trust M responds to the host with the decrypted/plain-text image. The host reprograms its firmware and now contains the updated version of it. A Man-in-the-middle (MITM) is spying on the I2C channel from the beginning. This MITM also has the full and plain-text version of the host’s updated firmware. This has serious consequences as the MITM now has access to the Intellectual Property (IP) of the host, its functioning, and basically the entire code.

Despite the MITM’s inability to read the secret and private keys, the system is insecure. The MITM Does not have to "read"?, as the plain-text firmware is easily available. Its weakness is the I2C channel, which is not secure.

Securing the I2C channel

Transport layer security (TLS) is used to secure the interaction with websites. Similarly, the interaction between the host and OPTIGA™ Trust M can be secured using shielded connection by following these steps (see Figure 1 )

1. The host generates a random number using Pseudo random number generator (PRNG) or True random number generator (TRNG).
2. The host optionally transforms the random number into another random number, for example, by applying XOR operation on the random number generated in step 1, with another random number on the host side. The result is called Pre-Shared Secret (PreSSec). This will be the shared secret between the host and OPTIGA™ Trust M, using which a secret key is derived for shielded connection.
3. The host stores the previously mentioned shared secret (known as platform binding secret) persistently in NVM (nonvolatile memory).
4. The host triggers OPTIGA™ Trust M to store the PreSSec in 0xE140 object.
5. The host sets the metadata of the object 0xE140 in a secure environment to avoid future modifications of this PreSSec and its reading. Once the PreSSec is written in OPTIGA™ Trust M, it can be updated only via a secure protected update mechanism.
6. The host and OPTIGA™ Trust M now have the same PreSSec. The recommended secret size is 32-bytes (or at least 16-bytes).
   

Figure 1 Pair OPTIGA™ Trust M with host (Pre-shared secret based)

The next step is to understand how this PreSSec is used to derive the key for shielded connection. The IFX_I2C specification contains the details on how this PreSSec is transformed into a symmetric key for encrypting the traffic between the host and OPTIGA™ Trust M. The Presentation layer code of the IFX_I2C library transforms the PreSSec into a symmetric key based on TLS PRF SHA256. After deriving keys (session keys) from the PreSSec, it is used for encryption/decryption. The same key is also used for authentication using MAC (message authentication code). This kind of scheme where both encryption/decryption and authentication are done using the same key is called Authenticated encryption. The scheme used by IFX_I2C Presentation Layer is AES128-CCM8.

Session key derivation and handshake

The session key is derived every time a shielded communication is established between the host and OPTIGA^TM Trust M and therefore, unique on each startup or each session. This makes the symmetric key used unique per session and enhances security, similar to TLS.

Figure 1 Session key derivation using PreSSec and handshake between host and OPTIGA™ Trust M

The following steps are involved in the session key derivation using PreSSec and handshake between the host and OPTIGA™ Trust M (see Figure 2)

The master sends the supported protocol version(s) to the slave with SCTR = 0x00 (Handshake.Hello). The protocol state gets cleared and re-started in case the protocol was already started.

Note:SCTR (Security control), a presentation layer configuration in IFX_I2C; for more details, refer the IFX_I2C spec- chapter 6 Presentation Layer.

1. The slave generates a random value (RND) and SSEQ and returns both along with the chosen protocol version with SCTR = 0x00 (Handshake.Hello).
   
   Note: SSEQ (Slave sequence number), sequence numbers aid in avoiding replay attacks.

2. Master and slave calculating the session secrets, one for master (MasterSsec) and one for slave (SlaveSsec) (MasterSsec and SlaveSsec = TLS PRF (“Platform Binding”, RND || Shared Secret)).
   
   Note: TLS PRF (Transport layer security pseudo random function). This function takes a nonce and key (in this case PreSSec) as input and derives a deterministic key (in this case Session Key).

3. The master uses SSEQ and generates the ciphertext (Generation-Encryption Process as per AES128-CCM8) and sends both to the slave with SCTR = 0x08 (Handshake.Finished).
4. The slave decrypts the ciphertext (Decryption-Verification Process as per AES128-CCM8) and verifies in the payload if the expected values were received and upon success, saves the received sequence number (SSEQ) for further use.
5. The slave generates the MSEQ and the ciphertext (Generation-Encryption Process) and sends both to the master with SCTR = 0x08 (Handshake.Finished).
   
   Note: MSEQ = Master Sequence Number.

6. The master decrypts the ciphertext (Decryption-Verification Process) and verifies in the payload if the expected values were received and upon success, saves the received sequence number (MSEQ) for further use.
7. If both ciphertext validations were successful, the cryptographic link is established between master and slave, which is the pre-condition for a subsequent protected record exchange. In all other cases the handshake must be re-started at step 1.

Conclusion:

Shielded connection provides a layer of security over the I2C channel, by scrambling (encrypting) the messages sent over this otherwise unsecure channel. Since this is based on PreSSec, the security of a shielded connection is only as strong as the PreSSec is maintained and handling at Host side. If the host leaks this PreSSec information to attackers or spies relatively easily (via Side Channels for instance), then the communication between the host and OPTIGA™ Trust M is unsecure.

For more details on shielded communication, see the Solution Reference Manual of OPTIGA™ Trust M.

For code examples, see the GitHub repository.