A reimagining of hardware-based (DCP) crypto in C++: Decept

S

shawn

Well-known member
Greetings, all. I took the liberty of creating a new library for interacting with the Teensy 4 CPU's DCP crypto module. It's a reimagining of the interface and driver entirely in C++. No C layer, and none of the complexity that's in the NXP SDK.

It's called Decept, and it can be found here:
github.com

GitHub - ssilverman/Decept: A library that makes use of the Teensy's built-in DCP module

A library that makes use of the Teensy's built-in DCP module - ssilverman/Decept
github.com github.com

I tried to distill all the necessary parts into a good API. I included a bunch of tests so that there's some trust.

What's there:
* All the NIST tests (well, maybe not all of them) for the relevant algorithms (I actually wrote a bunch of this a few years ago, so it's whatever was current then)
* HMAC: HMAC, TOTP
* CRC: CRC-32
* Hash: SHA-256, SHA-1
* Encryption: AES-128

What's not there yet:
* A complete non-blocking API; it's only partially done
* No examples
* I still need to complete the CTR DRBG, but I have local Hash- and HMAC-based DRBG's completed that I still need to go through and commit. (Deterministic random bit generators that are cryptographically secure.)
* Some sort of security review by experts more expert than me in the ways of security
* A better way to manage channels
* There's still room for design cleanup

Some asks:
* Don't rely on this for complete security just yet, because while executing the core algorithms is probably correct, it's usually the stuff around and that uses the crypto that isn't quite right for all cases.
* Some code review, especially by security experts more versed than I
* Contributions and suggestions/issues/comments
 
' Brave Search Assistant' said the github for decept does not exist.

CoPilot found it - and got finally to seeing no enum for CRC32, so it wrote the code and offered to provide the code into github, or file edits - getting a zip failed here already past time for sleep
 
Yes, the link is perfect, and got it with github desktop on Windows.

It was interesting that MSFT's CoPilot found it (as noted) no problem (since they own github) - More static Brave 'generic' AI assistant did not have a dynamic connection it seemed.
 
When the reference manual talks about SNVS_LP having "Zeroizable Master Key", which DCP key is that? I'm assuming it's not really a one-time programmable key but rather a key that lives in the battery-backup powered memory and gets wiped when power is lost (so if it was randomized, any data encrypted with it would be irretrievable).
 
jmarsh said:
When the reference manual talks about SNVS_LP having "Zeroizable Master Key", which DCP key is that? I'm assuming it's not really a one-time programmable key but rather a key that lives in the battery-backup powered memory and gets wiped when power is lost (so if it was randomized, any data encrypted with it would be irretrievable).
Click to expand...
If I had to guess, it's either the "OTP key" or the "unique OTP key". Now I wonder if it's zeroizable because of tampering or because of losing power, or even because of a system reset? Let me go read up on SNVS_LP...

Update (after some Google queries): there might be an additional step one has to take to route the SNVS_LP key to one of the key slots with DCP. I'm not familiar with that part just yet.

Update 2: it turns out you can use one of the muxes to route the OTP key SELECTED BY DCP to the one set in SNVS_LP.
 
Last edited:
@jmarsh I found some example code in the NXP SDK: mcux-sdk-examples/evkcmimxrt1060/driver_examples/dcp/dcp.c

It looks like you need to set "OTPKey" (4), and then select which OTP via IOMUXC_GPR->GPR3 and IOMUXC_GPR->GPR10. See the DCP_OTPKeySelect() function.

I'm going to add support for this in the API...
 
I just added two cryptographically-secure DRBG (deterministic random bit generator) classes: HashDRBG and HMACDRBG. Please see the tests for how to use.

When generating cryptographically-secure random numbers, the typical approach is to seed a cryptographically-secure DRBG with some entropy, periodically, and then generate the "random" numbers from the DRBG. The reason is that generating entropy is often slow.

To run the tests in PlatformIO: pio test -v
For a specific test: pio test -v -f test_aes128
Etc.

If anyone is a security expert and can review my implementations (all the classes, not just the DRBG's), that would be very swell. Note that the tests include the NIST test vectors.
 
Last edited:
I should probably add this caveat about my DRBG implementations: While the algorithms are technically secure and my implementations are likely correct (as shown by passing all the NIST test cases), it's possible that my implementation is not actually secure. Security is hard, and there's always something you might not think of, some subtle "insecure entry point", etc. For example, something hanging around in the cache for too long, or forgetting to zero one particular byte and that leaks some information, etc.

In other words: I do not guarantee the security of my implementation.
 
Note: A CTR_DRBG implementation is being worked on, but I'm finding that it's a little harder to implement than the others. I plan to add it, but don't know when that will be.
 
You must log in or register to reply here.
Back
Top