However, it looks like there is no protection against physical tampering of SPI NOR flash. Anyone who obtained direct access to flash contents could write UEFI variables to arbitrary value, thus bypassing secure boot completely. ‘A Tour Beyond BIOS Implementing UEFI Authenticated Variables in SMM with EDKII’ whitepaper also confirms this: “Physical attacks that replace SPI NOR or use Dediprog to modify the UEFI variables can rollback or add errant entries.”.
Am I correct here? Does Jetson have any protections regarding to this kind of physical attacks?
I can only comment on a tiny part of this, which you might already be aware of (and which might not help)…
Because Jetsons do not have a typical BIOS in hardware, they instead have all of that content in software as partitions. All partitions, other than the rootfs, are signed. Incorrectly signed content is refused. The default is to sign with a NULL key, but you can burn security fuses with a private key, and then only partitions signed with that key are accepted, which is protection against alteration if and only if that content is on one of those partitions. The key itself is protected.
On the other hand, I couldn’t tell you if someone with a high end recording digital storage oscilloscope would or would not be able to “eavesdrop”. I couldn’t tell you if a literal removal of a chip and replacement with an unfused version is possible. I doubt the latter, but I don’t know about the former. It is only a guess, but I’m betting that the signature and signature checking hardware are part of the same chip which has key, and so my thought is that (if this is the case), then replacing the chip would not work unless the chip being replaced does not also replace the eMMC (rendering it more or less useless if the eMMC itself is enforcing this). It’s a fascinating topic, I wouldn’t mind knowing if the above is correct (NVIDIA would have to comment).
I don’t consider attacks on the fuses as part of threat model, for two main reasons:
As you mentioned, this is very hard and expensive
Fuses are root of trust, if you consider them compomised - then everything is compomised, no exceptions.
You cannot replace fused chip with unfused one because fuses also hold symmetrical keys. Unfused chip is unable to decrypt content encrypted with these [now lost] fuse keys.
Threat model considered in this thread is as follows:
UEFI binary is signed with fused public key. This is completely ok.
Kernel (and everything after it) is signed with public key from UEFI variables. This is also more or less ok.
UEFI variables aren’t signed with anything. They are simple stored on QSPI flash. EDK considers UEFI variables to be protected from unauthorized writes and puts such topic out of it’s scope.
You could enroll your keys, change them at runtime, even change the PK (Platform Key, root UEFI secure boot key). No possession of fuse keys is required to perform any of these operations. All protections related to unauthorized changes are specified as “UEFI should not allow to…”.
As I understand, QSPI is a discrete device (but I could be wrong) on module board. You don’t need hi-end oscilloscopes. You could just use regular SPI flash programmer. What should prevent anyone from changing UEFI variables directly on QSPI flash, putting new trusted public keys there?
Orin series support secure flash.
you should use the Secure SPI flash instead of normal SPI flash to avoid hardware hijack.
FYI, we use normal SPI flash since our products are mostly DevKits.
Is the SPI NOR mounted on Orin module directly or on carrier board?
This could be solved more easily (at cost of reduced flexibility) by taking values of critical variables directly from UEFI binary (which is signed by fuse keys) and ignoring SPI NOR contents. I will probably go this way (as it is pure software solution), but it’s sad to see that Orins cannot be secured with their default software.