Verify attestation in practice

[bboozzoo]

I populate the SE05x with a bunch of data and keys. One of the keys is considered to be the primary device key and can be used for attestation. Now I read back some of those properties and ask for attestation with said key, after which all of the data is transferred to the back office.

According to AN12543, there's a bunch of low level inputs being used as inputs for signature with the selected secure object:

It's clear that none of these inputs cannot be easily generated offline in order to be able to verify the attestation signature. So, the question is, how to verify this in practice? What is the recommended way?

[Kan_Li]

Hi @bboozzoo ,

There is no need to generate all of the signature input, you may have them from the APDU command as well as the command response. if you refer to Fig 4 in the same AN, you may find as shown below:

So now you have the signature input as well as the signature which is also a part of the response if the secure object's policy allows attestation, then you may verify them on the host with the public key from the attestation secure object , for example, https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-examples 

Hope that helps,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bboozzoo]

Thanks. I get that. The problem I have is with practical aspects of implementation and I'm really wondering how folks use that in the field.

In a case when a remote system needs to verify that some data provided by the device really comes from SE05x attached to that device, having the command PDU and response PDUs as inputs means that either you'd have to attach both to the message (impractical) or the remote system needs to be able to recreate both PDUs (impossible?). So, I'm not entirely sure of the attack vector this is trying prevent. Perhaps a rouge device attached to I2C pretending to be SE? Perhaps it's only useful when SE operates as I2C master, say in contactless card reader implementation?

Is there a way to to snoop the APDUs when using the MW libraries in order to collect the raw bytes of the command and response PDUs?

[Kan_Li · Accepted solution]

Hi @bboozzoo ,

Actually attestation is mainly to avoid the man-in-the-middle attack, Maybe the following AN gives some use case on this topic, SE05x is able to act as I2C master to connect with some sensor and attestation operation can be used to protect the data out of the sensor. Please kindly refer to  https://www.nxp.com.cn/docs/en/white-paper/SE050-USE-CASE-WP.pdf  for more details.

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------