[Cryptech Core] security model for upgrades

[Paul Selkirk]

tl;dr: We don't have signature protection for firmware/bitstream
upgrades, and here's why. Just so it doesn't come as a surprise in Berlin.


What we have now is pin-based login for all file uploads (bitstream,
firmware, bootloader). CRC-32 protects against accidental corruption in
the upload process, but of the 3, we only act on crc32 failure in the
firmware upload (projects/bootloader/dfu.c); for bitstream and
bootloader, we report the failure but leave the image in flash. We
should probably decide if that's really what we want to do.

This protects the device against malicious upgrades of a configured
device (where the SO password has been set, because only SO can upload
files). But what about a man in the middle attack on an unconfigured
device? Say it's intercepted by Pottsylvanian agents, on its way to a
customer. They could log in as wheel with the default pin, set the SO
pin, upload back-doored firmware, wipe the keystore, and send it on. The
device trusts that anyone who can log in is an authorized user.

We discussed having a signature check on all images, so the device could
trust they came from an authorized party. The cryptech public key would
be compiled in, but the SO could install additional signing keys to
supplement or even replace the cryptech key. However, I wasn't able to
get this all working this weekend. Plus, thinking about it now, it has
exactly the same MITM problem - Boris logs in as wheel with the default
pin, installs his own signing key, uploads the back door, wipes the
keystore, and sends it on. So maybe it's all security theater after all,
and additional checks make upgrade more likely to fail without any real
benefit. (And I do worry about failing in front of an audience.)

Not to mention that anyone who has physical access to the device has
access to the st-link header, and can reprogram the firmware and
bootloader with a $10 ST board. If he has a Xilinx jtag cable, he can
rewrite the fgpa configuration memory as well, more efficiently than
going through the cli.

Since we don't have real tamper circuitry, this would be undetectable.
Even if we did, we don't log tamper events, or anything else. (Logging
is on my list of post-Berlin features, if we still have funding. Should
make a ticket for it.)

Anyway, we can talk about ways to strengthen DFU, but these are the
facts on the ground for Berlin.

				paul