a. Starting March 15, 2014, SysDev will begin accepting EV certificates issued by either DigiCert or VeriSign for new submissions and renewals.
b. Existing submitters have until August 15, 2014, to move from existing non–EV code signing certificates to EV code signing certificates. This extension is provided to facilitate frictionless migration.
a. If your submission loads a GRUB or other loaders, it must be SecureBoot enlightened.
For example, the latest GRUB 2 with SecureBoot patches.
b. Developers might assume that secure boot security requirements have been satisfied when their initial boot is complete. However, if a secure boot system permits launch of another operating system instance after execution of unauthenticated code, the security guarantee of secure boot is compromised. If this vulnerability is exploited, the submission might be revoked.
a. Code signing keys must be backed up, stored, and recovered only by personnel in trusted roles, using at least dual-factor authorization in a physically secured environment.
- The private key must be protected with a hardware cryptography module. This includes but is not limited to HSMs, smart cards, smart card–like USB tokens, and TPMs.
- The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2.
If embedded certificates are EV certificates, you meet all of the above requirements. We recommend that you use an EV certificate because this will speed up UEFI CA signing turnaround.
b. Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently.
c. If you lose keys or abuse the use of a key, or if a key is leaked, any submission relying on that key will be revoked.
d. Some shims are known to present weaknesses into the SecureBoot system. For a faster signing turnaround, we recommend that you use source code of 0.8 or higher from shim - GitHub branch .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.