When I was reading the doc, it was not clear initially how can a device with Soft-CPU implemented on FPGA can be secure? Surely someone can replace CPU implementation with the one with full debug capabilities, and then use that to decrypt stored secrets?
Turns out, there is no such thing as "stored secrets", and the device has no non-volatile memory at all, other than FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection. The mechanism that is normally used to prevent device duplication is instead used to protect cryptographic secrets. Replacing bitstream is all-or-nothing affair, so a hypothetical "CPU with debug capabilities" will not have access to UDS.
This means all storage must be on PC and some classes of things are are absolutely impossible - for example an anti-bruteforce counter that clears secrets if too many wrong attempts are entered.
> how can a device with Soft-CPU implemented on FPGA can be secure?
> FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection.
Correct. Here are some more interesting details:
- we're using the Lattice iCE40 UltraPlus FPGA, which is supported by open tooling and has been for a long time. During the course of the project we also had the configuration and locking protocol reverse engineered so that one can configure and lock the FPGA with open tooling.
- the iCE40's Non-Volatile Configuration Memory (NVCM) uses anti-fuse technology for storing the configuration bits, where the 0s and 1s are stored in vias on the die. The physics of how these vias are modified to represent a 0 or a 1 make it very hard to read out information using X-ray, unlike on-die storage implemented using "horizontal" e-fuses. That's the gist of it.
- the FPGA's boot state machine is unfortunately designed such that you can get it to boot an external bitstream from SPI even after you've configured and locked NVCM, and the state of EBRs (block memory) is retained across warm reboots of the FPGA. We took several steps to mitigate this limitation, which, now that I think about it, would make several interesting blog posts. The UDS memory itself is in LCs, you can mix in key material from the host, the exact timing of that is randomized, RAM (implemented in EBR) is has both address and data randomization... and a few more things.
- physical security is hard, and the TKey won't be able to stand up against any and all physical attacks, but I don't think there is any security hardware in the world that is as open and inspectable as the TKey.
If you want to delay, you don't even need something that complicated, just run your favorite PBKDF function as a part of your app.. Or maybe not even add, add a plain "sleep()" call before trying to decode input data.
Turns out, there is no such thing as "stored secrets", and the device has no non-volatile memory at all, other than FPGA configuration (NVCM). The only secret is UDS, 256 random bits that are baked into FPGA configuration stream, and they are protected by FPGA's read-out protection. The mechanism that is normally used to prevent device duplication is instead used to protect cryptographic secrets. Replacing bitstream is all-or-nothing affair, so a hypothetical "CPU with debug capabilities" will not have access to UDS.
This means all storage must be on PC and some classes of things are are absolutely impossible - for example an anti-bruteforce counter that clears secrets if too many wrong attempts are entered.