i.MX RT 1060 SCP03 and DCP

[TomGibson]

Hello,

Is there a straightforward example of leveraging the i.MX RT 1060 DCP Internal Memory for storing AES-128 keys to hold the three AES keys needed for SCP03 Authentication to the SE050?

All the code sample use the #defined factory keys, but I would like to be able to load in random keys to the DCP and then have the host crypto call through to the DCP and use these keys to authenticate. I can see that internally the code calls through to MbedTLS library functions that the use the hardware DCP acceleration so it should be possible, I just need to know how to configure the code samples to use the correct handle to a key already stored in the DCP Internal Memory rather than the #defined factory key.

Thanks,

Tom

[Kan_Li]

Hi @TomGibson ,

Looks like it is a topic regarding integration of DCP and MbedTLS, and seems they have already been integrated together.

Please kindly refer to the SDK package for more details.

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

[TomGibson]

Hi Kan,

Thanks for your message.

The issue is really that I can't see a way in the SE050 sss APIs to specify to use the alternative key slots because it's a platform specific feature that's abstracted away. The kSDK integration with Mbed defaults to using DCP Slot0, and the SCP03 authentication operations are therefore leveraging the DCP with the key in Slot0 for SCP03 authentication. So that's good, but the issue is that it seems to constantly write the key it wants to currently use for a particular operation into that single slot because that's the default slot the static dcp_handle uses and it's never configured to use another slot. Therefore, Slot0 is being repeatedly updated depending on which of the three SCP03 keys its using at the time.

The Mbed AES context really needs to be initialised with a handle to the existing key before the AES operation is started so the key isn't repeatedly written - if the context already has a loaded key then DCP_AES_SetKey won't be called. But the problem is it would need to be configured to use the appropriate keyslot before trying to do an encrypt or decrypt operation, and unfortunately the sss APIs don't really offer a way that I can see to configure that because it's a platform specific configuration. I could change the lower level code to chose the appropriate slot and ensure the context is already initialised, but as it's all library code I don't really want to mess with it because the next release from NXP would then necessitate the same changes being made.

Ideally what I would like is to write the three keys to the DCP slots 1-3 on boot and then not need to handle them in memory again, but this seems impossible with the current code because there's no way to configure it in the generic sss API.

Thanks,

Tom

[Kan_Li]

Hi @TomGibson ,

Please kindly have my comments as below:

The issue is really that I can't see a way in the SE050 sss APIs to specify to use the alternative key slots because it's a platform specific feature that's abstracted away. The kSDK integration with Mbed defaults to using DCP Slot0, and the SCP03 authentication operations are therefore leveraging the DCP with the key in Slot0 for SCP03 authentication. So that's good, but the issue is that it seems to constantly write the key it wants to currently use for a particular operation into that single slot because that's the default slot the static dcp_handle uses and it's never configured to use another slot. Therefore, Slot0 is being repeatedly updated depending on which of the three SCP03 keys its using at the time.

-I understand you concerns , but actually the SDK driver has not provide an API to configure the slot used by  the static dcp_handle, so I don't think it would make sense to implement such functionality in SSS API layer.

The Mbed AES context really needs to be initialised with a handle to the existing key before the AES operation is started so the key isn't repeatedly written - if the context already has a loaded key then DCP_AES_SetKey won't be called. But the problem is it would need to be configured to use the appropriate keyslot before trying to do an encrypt or decrypt operation, and unfortunately the sss APIs don't really offer a way that I can see to configure that because it's a platform specific configuration. I could change the lower level code to chose the appropriate slot and ensure the context is already initialised, but as it's all library code I don't really want to mess with it because the next release from NXP would then necessitate the same changes being made.

- Indeed the sdk driver checks the Mbed AES context if it is something used before, otherwise load the key and store this context for further usage, but still the key slot is fixed by the static dcp_handle, so SSS APIs could do nothing on the top unless you change the low layer driver code. I think you may use some kind of version control tool to ignore such driver code during the update.

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