Due to the way the configuration state machine in the Lattice iCE40 UP device operates, we can't block a warm boot-attack, even though the FPGA bitstream is stored and locked into the on-die Non-volatile configuration memory. However we can, and try to, make it really hard to successfully perform an evil maid attack.
First: all registers and logic (LUTs) will always be cleared during the reset phase of the FPGA configuration. So any secrets stored there will be secure. We store the Unique Device Secret (UDS - the primary asset) in registers. Registers that can also only be read once between power cycling. The block RAMs (EBRs) however can be cleared or retain data based on the configuration <-- these are the ones to worry about.
Right now we have to touch the FW-RAM (implemented using EBRs) with the UDS for a few tens of cycles. After it being used, it is wiped from memory. So a successful exfiltration must trigger the warm boot-reconfiguration during that window of time. In order to make this harder (i.e. more time consuming) we do a few things:
1. We randomize when the UDS is moved to the FW-RAM and thus when the window to hit is. And we should not leak any indication when that is.
2. We use ASLR to randomize where and in which order the UDS is stored in the FW-RAM.
3. We use randomized data scrambling of the contents in the FW-RAM. And yes we do fill the memory with randomized, ASLRed data first.
The randomization control values are all stored in registers, and will be lost as part of the reset phase of the attack. So an exfiltration must:
1. Hit the window of time.
2. Extract the contents of the FW-RAM.
3. Be able to distinguish the random data words that make up the UDS from the other contents of the FW-RAM.
4. Descramble the UDS words and place them in the right order.
It is not an impossible attack, but it should take a long time. And it should not scale easily from one device to all other. One could automate it of course, but the work should be the same (multiple exfiltrations) for each device.
But we still think that the attack IS possible, and it is therefore out of scope of attacks that we mitigate for this version of the TKey. The next version will hopefully be able to keep the UDS in registers only. When we have that working, the threat model will be updated to reflect that.
