This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

cryptocell vs infineon optiga trustx platform

Hi all,

I am not sure if I am on the right track by comparing CryptoCell & Optiga TrustX Platform but I couldn't understand the difference exactly. What I understand is they both provide similar functionalities, so why would I need an extra hardware if have an nRF52840?

https://www.infineon.com/cms/en/product/security-smart-card-solutions/optiga-embedded-security-solutions/optiga-trust/optiga-trust-x-sls-32aia/

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fcryptocell.html&cp=3_0_0_5_5

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.3.0%2Flib_ifx_optiga.html&anchor=lib_ifx_optiga_architecture

A question would be if I can use cryptocell infra as secure storage for secrets in terms of both software and physical. Is there any flash region which can be accessible via only cryptocell on nRF52840, and not accessible from the application code? 

I have a requirement in my project for 802.1AR (Secure Device Identity) standard compatibility. Basically, the standard requires device id and a secret key are bound cryptographically so that the device id cannot be altered or stolen without that secret key. Is cryptocell technology enough to implement that requirement or do I need a TPM module to comply with it? I read some papers where ARM TrustZone and TPM are compared, so I wonder if CryptoCell can be alternative to TPM or not.

https://1.ieee802.org/security/802-1ar/

Any comment or experiences are highly appreciated!

Best regards,
Vedat

Parents
  • Hi,

    You're right in that Cryptocell and Optiga TrustX platform provide similar functionalities. I think the key difference is that TrustX offers tamper proof NVM storage. The nRF52840 is not designed to protect against physical attacks such as decapping of the IC.

    The Cryptocell has secure key slots in a protected always-on domain (secure RAM) to which keys can be written and subsequently used by the Cryptocell core, but never read back. The key must be set in the Cryprtocell's always-on domain after every reset, so it must reside in flash to be persistent.   To protect the keys in the 52840's flash, you can lock down the debug interface by enabling APPROTECT and use the Access control lists (ACL) to prevent read access from other parts of the code (can only be unlocked by reset).

    Best regards,

    Vidar 

Reply
  • Hi,

    You're right in that Cryptocell and Optiga TrustX platform provide similar functionalities. I think the key difference is that TrustX offers tamper proof NVM storage. The nRF52840 is not designed to protect against physical attacks such as decapping of the IC.

    The Cryptocell has secure key slots in a protected always-on domain (secure RAM) to which keys can be written and subsequently used by the Cryptocell core, but never read back. The key must be set in the Cryprtocell's always-on domain after every reset, so it must reside in flash to be persistent.   To protect the keys in the 52840's flash, you can lock down the debug interface by enabling APPROTECT and use the Access control lists (ACL) to prevent read access from other parts of the code (can only be unlocked by reset).

    Best regards,

    Vidar 

Children
  • Hi Vidar,

    Thank you for the insight!

    Is there anything else that I need to be aware of as physical attack types like explained here? Do you have any whitepaper that you can suggest me to read regarding to nrf52840 or any of your products in general which explains security issues? 

    So I can lock any flash region by using ACL at the moment of assigning IDs and keys, and then enable access port protection. I don't know if you have knowledge of 802.1AR (Secure Device Identity) standard, but this technique seems to solve this requirement. Is there any example of ACL and APPROTECT usage with full example of how to enable and disable?

    Best wishes,
    Vedat

  • Hi Vedat,

    We do not have a generic whitepaper on security, unfortunately.

    It should be difficult and costly to hack and reverse engineer the IC even if any side-channel attacks can make it leak information.  I'm not a security expert, so my best suggestion is to try to determine a reasonable security level based on the threat level and potential impact. E.g., how likely is it that someone may consider investing the time and money needed to achieve this? If keys are extracted from one device, will the other units become vulnerable? etc.

    Is there any example of ACL and APPROTECT usage with full example of how to enable and disable?

    We don't have a full example of this. But readback protection is typically enabled by setting the APPROTECT.PALL field through the programmer (APPROTECT can be set at runtime by the FW if necessary).

    With nrfjprog:

    nrfjprog --rbp ALL

    For ACL you either use the HW abstraction layer (\modules\nrfx\hal\nrf_acl.h) or access the ACL registers directly. You may also use our bootloader example as a reference, it uses ACL for flash protection.  

Related