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.
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 )
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.
The session key is derived every time a shielded communication is established between the host and OPTIGATM 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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.