The Nitrokey 3C NFC pre-order page now states " LPC55S6x or nRF52 microprocessor". Is there any guarantee that the LPC55S6x will be used in my pre-order from March~April? IMHO the nRF52 is a massive downgrade compared to the LPC55S6x considering it’s a Cortex-M4 base instead of a Cortex-M33 and would be a reason for me to cancel my pre-order. How do you ensure feature parity and future proofing for both hardware architectures, considering how different they are? Will the nRF52 result in features not being offered anymore, considering it doesn’t have a TrustZone and has lower performance based on its architecture? How will this impact security based on the fact that the M33 architecture does provide an updated MPU implementation?
Sorry for the delay. I am passing a reply from our engineering team below.
Also related (for the future reference):
At the moment, it’s impossible to get reliable information about future availability of the lpc55 series. We have obtained as much stock as we could, and reserved future deliveries, but we cannot currently get any guarantees as to when we will actually receive new deliveries when our current LPC55S69 stock runs out. This is why we have decided to expand our options to multiple microcontrollers, to ensure we can deliver products even if one of the parts is not available.
TrustZone is not an M33-specific feature, and the NRF52840 which we are looking at as an alternative to the LPC55S69 does in fact support TrustZone (and ARM CryptoCell) and has an MPU, just like the first core of the LPC55S69 does. You’re right that the lower-end parts in the NRF52 series do not support this, but we’re not considering using those. Both the LPC55S69 and NRF52840 have a hardware root of trust, both platforms have a secure boot implementation to prevent firmware update attack vectors, and there’s no reason any of the planned future Trussed ® features would not be portable across platforms. In fact, Trussed ® does not currently use the cryptographic accelerator for cryptographic functionality, as the software implementations perform better and are more auditable. Rust abstracts the functional differences between the M4 and M33 cores pretty well, so the only downside to the M4 in this case is worse performance per watt (higher power consumption). That said, we’re including an external hardware root of trust chip in all NK3 devices (SE050), which we intend to use as secure key storage as an extra layer of security, regardless of the microcontroller that’s in use.
If the current availability situation persists we might need to expand to even more platforms, but we will not consider any platform that is a security downgrade. Feature parity is important to us and none of the planned functionality depends on the platform we use - or, rather, any platform we end up using is selected to ensure feature parity.