TK1 Security of nvflash's "fastboot.bin"

Hello,

thanks for uploading the secure boot and fuse documentation documents.

In order to make our platform secure, me and my team were wondering about the possibility of someone putting a board in recovery mode and dumping all the contents of the eMMC to its host, where they could do whatever they want with the data.

More specifically:

from http://http.download.nvidia.com/tegra-public-appnotes/flashing-tools.html :

Generally though, nvflash expects to download NVIDIA’s “fastboot” bootloader, and then communicate with it using an extended nv3p protocol. nvflash can both write portions of the device’s flash, and/or read back parts of the device’s flash to the host machine.

As far as I understood, the binary in recovery mode can’t do anything but wait for NVIDIA’s “fastboot” bootloader, which in turn executes the other commands (flash, download partition to host, etc…). This is reflected by the usage of nvflash (which requires the switch --bl fastboot.bin when flashing)
Is this binary verified prior to loading it? If so, can the key be changed through fuses or something else? Otherwise, if I understood correctly, one could still dump all the eMMc contents without any kind of check.

It’s true that the data could be encrypted (and the key could lie in an encrypted kernel, which itself could be booted from an encrypted u-boot if I understood everything correctly), so the data would still be protected somehow, but we’d like to make sure of our options.

Thank you!

I can’t answer your original question, but FYI, if a full operating system is installed with dd, and if sudo can be used, then anything can be copied even if no recovery mode is used. JTAG may be yet another way in if this is available on your carrier board.

This isn’t part of your topic, but it might be interesting to think about also setting up with SElinux where roles can be enforced (this would slow down eMMC access, but would make getting around certain security issues impossible from a running system even if it is hacked). Currently there are no SElinux components active (I am thankful for that!).

lnardelli,
When system is at its beginning, we need to have a way to put the device in a state so sw can do something about it. You could diagnose the hardware or flash the code to the boot device etc. Recovery mode is Jetson’s mechanism to perform that initial task. Fastboot is only one of the example you could transfer the sw component to device so your host can communicate with the device. In theory, you could load your own monitor code to the device and perform a task you like. This is similar to taking out emmc chip form the board and use gang programmer to read the content :)

Back to secure boot, it’s designed to protect your boot flow via chain of trust from Jetson hardware during boot process. Basically, with secure boot, your key boot components, BCT and bootloader, have to be signed with private key. Both key generation and signing process is to be performed in your secure facility. Your signed image can then be delivered to factory which might not be a secure facility per se.

During boot process, our bootrom will perform key checking and signature verification to ensure the components are authorized. If the checking fails, it won’t boot but back to recovery mode. Hope this helps.