Difference between access condition Conf (0x20) and Int (0x21)

[benma]

Hi

I am reading the docs about Conf and Int. Both reference the pre-shared secret and both talk about the shielded connection.

In 0x21 Int, what is the MAC/integrity check referring to? Does it relate in any way to 0x23 Auto?

The encrypted communication seems to come with a built-in integrity check even with 0x20 Conf - is this correct? If so, what's the use case for 0x21 Int over 0x20 Conf?

Thank you

[koblibri]

Hi,

the Conf/Int/Auto Values can be used for different purposes.
When talking about the "Shielded Connection", only "Int" or "Conf" apply:

• Int is only adding a MAC to the I2C message
• Conf is authenticating and encrpyting the message (AES128-CCM)
• Usually, you want to use "Conf" as a protection measure to read/change/execute objects on the Trust M with an enabled Shielded Connection

"Int/Conf" can also be used for "Protected Updates" on the Trust M. Protected Updates are a feature, where you can sign and optionally encrypt an update blob for a data or key object on the Trust M.
I.e. if you want to change a certificate in OID 0xE0E0 only via a protected update that is both signed (integrity protected) and encrypted (confidentiality protected), you could combine the following metadata statements:
Change (D0):

• Conf with Update Secret (i.e. the encryption key) in OID 0xF1D0 --> 03 20 F1 D0
• AND (FD)
• Int with a Trust Anchor (i.e. the signing key) in OID 0xE0EF --> 03 21 E0 EF
• Final Metadata: D0 09 03 20 F1 D0 FD 03 21 E0 EF

"Auto" is the Authorization Reference, yet another tool to protect the access to a Trust M object (see Section 2.3.11 of the SRM).
In short, you have to calculate a HMAC on both sides (Host & Trust M) based on the same symmetric secret (the Authorization Reference). If the host can prove to the Trust M, that it possesses the correct secret (by coming to the same conclusion), the Trust M can afterwards go into an "unlocked" state and allow access to any objects protected by this authorization reference - until either the authorization is revoked by the host or the Trust M is reset.

~Johannes

[benma]

Thank you very much for the clarification.

I suspected that this was the case, but when I looked at the SDK code, I could only find the part where the response is decrypted (including the auth check):

https://github.com/infineon/optiga-trust-m/blob/5b924c8615f563334136d5a84431f1682cfce3ea/src/comms/ifx_i2c/ifx_i2c_presentation_layer.c#L393

Where is the code where only integrity checking is performed, no decryption, in case the read access is configured with 0x21 Int?

[koblibri]

You are right that you cannot set the "integrity only" option on the host-side.
If the shielded connection is enabled, the message will always be encrypted & MACed.
You can only set the "direction" of the encryption, i.e. Command only (Host -> Trust M), response only (Trust M -> Host) or full (both ways). (Use the Macros here)

[benma]

Thanks!