Orin security questions about Secureboot and Disk encryption

So after reading parts of the security sections for our L4T release, we had the following questions:

Nvidia secure boot

  1. should every device we flash get its own unique PKC and SBK key?
  2. which “parts” exactly are covered by the PKC signing? (e.g. bootloader)
  3. If we use a unique PKC for every device, do we have to sign every update to the “parts that are covered” by the PKC so that we have to generate a custom update for every device?

UEFI secure boot

  1. whats the highest allowed bit-length for the RSA keys? the documentation only states 2048
  2. are ECC keys allowed?

Disk encryption

  1. do we have to consider side effects when generating a unique encryption key for every device? e.g. will this affect updates in any way, like e.g. if we ship the same initrd to every device?

Questions for all of the above

  1. is it possible to prepare a BSP tarball beforehand so that there is no private key/certs/passphrases/etc required to flash a device?
  2. if 1) is possible: is that also possible if rootfs a/b is activated?
  3. if 1) is not possible: is there some HSM integration in the flash-script so that we do not have to expose private key/cert/etc on the machine that is flashing the device?

hello brootux,

please refer to developer guide, you may check Security chapter for details.
let me reply each of your question as followoing.

Nvidia secure boot
>>Q1
as mentioned by developer guide, it’s suggest to generate a truly random number key, use the Hardware Security Module (HSM).

>>Q2
it’s bootloader binaries they’re signed by PKC keys.

>>Q3
it’s followed by above, you may used HSM for key management.

UEFI secure boot
>>Q1
as mentioned by shim with key section.

Note: It seems that shim will not support adding a 4096 RSA key to the MokList (it might freeze when loading and verifying the grubx64.efi binary), so make sure you use a 2048 key for now.

>>Q2
it’s not supported. but, may I have more details.

Disk encryption
>>Q1
please see-also Manufacturing process,
it’s now able to create encrypted images with a generic key.
here’s also forum thread for you reference, Topic 291335.

Questions for all of the above
>>Q1
it’s supported.
but… what’s the real use-case?
for instance,
there’s script files, nvmassfusegen.sh to create blob for fusing multiple Jetson devices simultaneously.
please dig into readme file for details. i.e. $OUT/Linux_for_Tegra/bootloader/README_Massfuse.txt
or,
you may check Flashing to Multiple Jetson Devices to efficiently flash Jetson devices in a factory environment.

>>Q2
it’s possible.

>>Q3
no. it’s depends-on your own key management.

Thank you very much for answering. Here are some follow-up questions.

Nvidia secure boot
Q2/3:
We just want to make sure: if every flashed device has its own PKC we also have to sign each bootloader-capsule-update individually for every device?

Disk encryption
Q1:
that unfortunately doesnt answer our question. We are trying to find out what problems we may face when we create keys/certs/etc individually for every sensor and want to later update things (e.g. bootloader, kernel, initrd, …) in field. So what parts do we have to keep in mind when upgrading a device but everyone has its own unique encryption key?

Questions for all of the above
Q1:
the real use-case for us is that we like to build a whole tarball with secureboot (nvidia+uefi), disk encryption, and rootfs A/B on a secure system so that we do not have to expose any secrets on the production-floor systems which flash the image.

hello brootux,

Nvidia secure boot
>> Q2/3:
yes, you’ve to create (to sign) the image blob individually.

Disk encryption
>> Q1:
is it related to OTA?
due to each device have different UUID, you needs to generate individual OTA payloads per device.

Questions for all of the above
>> Q1:
you may dig into readme file, $OUT/Linux_for_Tegra/tools/kernel_flash$ vim README_initrd_flash.txt
please refer to [Workflow 8] for reference.

We will read into the READMEs you linked, thank you very much