I have a couple of questions regarding the generation of the certificates for UEFI Secureboot. I refer to this doc
The examples set a common name to the generated x509 certificate. For example “/CN=my Platform Key/”" for the PK. Is this necessary? Is the CN somehow used by the UEFI firmware?
There is a ‘caution’ note stating that the certificates generated are self-signed and that one should follow one’s official certificate generation procedure. I am under the impression that UEFI lacks the ability to process certificate chains. As such I was thinking a self-signed certificate is adequate for UEFI secureboot? Could you confirm if my understanding and conclusion are correct?
What and how should we provision the dbx ‘revoked signature database’? There is a UEFI revocation list file for arm64 in the doc, but I am not clear how this is meant to be used.
I am using L4T 36.4 on an Orin AGX devkit as prototyping platform.
I already have UEFI Secureboot implemented. My questions are not about getting Secureboot working but to understand the details involves with certificates so we can safely implement Secureboot in our product.
The examples set a common name to the generated x509 certificate. For example “/CN=my Platform Key/”" for the PK. Is this necessary? Is the CN somehow used by the UEFI firmware?*
I believe the openssl CLI incorporates this into the generated certificate, if you omit this parameter, I think you are asked some questions by the tool.
What and how should we provision the dbx ‘revoked signature database’? There is a UEFI revocation list file for arm64 in the doc, but I am not clear how this is meant to be used.
The dbx is signed with Microsoft’s KEK, if you enroll the Microsoft keys on your device (I think the developer doc has guidance on how this can be done), you should be able to download and update the dbx from the OS.
There is a ‘caution’ note stating that the certificates generated are self-signed and that one should follow one’s official certificate generation procedure. I am under the impression that UEFI lacks the ability to process certificate chains. As such I was thinking a self-signed certificate is adequate for UEFI secureboot? Could you confirm if my understanding and conclusion are correct?
Correct, UEFI itself doesn’t check where the PK came from.
That being said, you/your company could have CA requirements (meaning we don’t want to tell you how you generate your PK).
Hello gmahadevan,
Thanks for the clear answer!
We are building a closed system and we control the updates deployed onto it. We’ve enabled UEFI Secureboot, but I am unclear as to what we should do with the dbx? Should we leave it empty or pre-initialise it with the content of the Microsoft database? Looking at the csv file, none of it seems relevant to our system…
It depends on what UEFI is loading.
The dbx is a list of the compromised programs (OS loaders) known to be malicious. It is updated based on known vulnerability reports (CVEs).
If your deployment will involve running a commercial OS distro (Ubuntu/Windows/etc), then pre-populating the dbx using the revoked list from uefi.org is recommended…
We are using L4TLoader to load our own Linux image built with Yocto. Is pre-populating dbx not useful in this case? NVidida does not appear in this list…
If your systems won’t have the ability to launch a commercial OS distro, then you’re right, the known revoked list is probably not very relevant to your deployments.
(it’s a general, good practice for uefi secure boot (nice to have in your case, but not necessarily must have))