SE050, how to verify the signature contained in tag 5F37 of the ECKeySessionGetECKAPublicKey?

[MarcoBelli1]

We need some help to understand how to verify the signature contained in tag 5F37 of the ECKeySessionGetECKAPublicKey R-APDU Body, and – more generally – we need help to understand in which conditions establishing an ECKey Applet SCP03 encrypted session also grant the mutual authentication of the 2 peers.

According to NXP application note AN12413 Rev. 2.12 chapter 4.5.4.2 - the R-APDU body of the answer to “ECKeySessionGetECKAPublicKey” SE05x command contains 2 tags (see table 78):

Table 78. ECKeySessionGetECKAPublicKey R-APDU Body

Value	Description
0x7F49	Byte array containing the requested public key (= SE050 Key Agreement public key, either RESERVED_ID_ECKEY_SESSION or RESERVED_ID_EXTERNAL_IMPORT)
0x5F37	Byte array containing the signature over the other (previous) tags

In our understanding verifying the signature contained in tag 5F37 is needed to authenticate the SE05x as a genuine device, and is a fundamental part of the mutual authentication, but we can’t find enough information to carry out this verification.

We also tried to analyze the sss library in the RT1060 dev kit to find a reference implementation by NXP, but we found that the function we identified as the relevant piece of code (the nxECKey_GetVerify_SE_Ecka_Public function in evkmimxrt1060_se05x_vcom\se_hostlib\sss\src\se05x\fsl_sss_se05x_eckey.c) simply skips the signature to reach the SW code, omitting the verification.

Chapter 3.6.3.3 of the same AN reports

“The user calls ECKeySessionGetECKAPublicKey to get the public key from the device’s key pair. Any input key ID except 0x02 will return the public key of the EC key pair with RESERVED_ID_ECKEY_SESSION. The response is signed by the same key pair”.

Unfortunately all our attempts to carry out the verification by using the key contained in tag 0xB0 of the same response failed.

We have the following questions:

1. Is the verification of the signature in tag 5F37 needed to achieve a fully featured mutual authentication between the SE050 chip and the remote host?
2. Is this signature an ECDSA signature made by using a NIST P-256 curve Keypair and SHA256?
3. How is an user of the SE050 chip supposed to perform this signature verification:
1. Which public key shall be used?
2. What is the NXP recommended method for obtaining this key? (it is actually the ECKAPublicKey received together with the signature, it is another secure object onboard a “vanilla” SE050, it can be downloaded from some NXP website, it can be provided by NXP on demand after an agreement …?)
3. In case we use the bare public key for the verification do we still obtain a mutual authentication? Shall we use instead a certificate containing it, and verify the certificate signature according to standard PKI practices?
4. More generally, which are the key steps we shall be sure to perform correctly to obtain a real mutual authentication?

We are also wondering why sss lib silently omits this check, and we would like to ask NXP support how we should treat the items included in the DEV kit and specifically whether all items can be safely used for production code development, or whether - for some of them - some extra caution should be used.

[Kan_Li · Accepted solution]

Hi @MarcoBelli1 ,

the implementation of ECKeySessionGetECKAPublicKey()got updated in the MW version 04.00 which is currently only being online on the SE051 page(https://www.nxp.com/products/security-and-authentication/authentication/edgelock-se051-proven-easy-t... ), but in this case it would make sense to use this version already for SE050. 

The updated MW uses instead of the APDU GetECKAPublicKey which only outputs a self-signed key the function Se05x_API_ReadObject_W_Attst() which lets the key used to sign the public EC session key be specified. By default the MW now uses the pre-provisioned attestation key to verify the read out public key. The check if this attestation key now can be trusted is not implemented on the MW example yet. On SE05xC the attestation key has a certificate so this cert can be used to prove the validity of the attestation key. On SE05xA/B types such a certificate would need to be provisioned by the customer.

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.
-------------------------------------------------------------------------------