Open policorp-dev opened 5 months ago
I'm not an official reviewer, but I just want to help reduce the work load of official reviewers.
policorptecnologia-shim-x64-20240327
, on commit point 547786a9bdc788cae2e8dfe3aa39675bd0382128
git clone --recursive -b 15.8 https://github.com/rhboot/shim.git
4aa025926083ae419fa8faa002a257c47603c674509616d6275d7e3922cafbc7 shimx64.efi
C = BR, ST = Amazonas, L = Manaus, O = Policorp Tecnologia Ltda., CN = Secure Boot Signing, emailAddress = contato@policorp.com.br
Do you use EV certificates as embedded certificates in the SHIM?
you replied yes, when in fact the certificate above is self-signed.shim sbat section does not add a vendor specific line at the end of it:
objcopy -j .sbat -O binary shimx64.efi /dev/stdout
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
NX compat is disabled
objdump -p review/shimx64.efi | grep DllCharacteristics
DllCharacteristics 00000000
Thanks for your comment, about the signing keys, yes they are stored on software, according to your comment we gonna change our repo.
Huge thanks to @es-fabricemarie for the help!
Reviewing.
I couldn't find the public keys listed in the application. However, another thing that bothers me is that the primary contact is, as far as I'm aware, a group email for the whole development team.
Is the whole development team involved with bootloader security? Otherwise I think it'll be worthwhile to compartmentalize it, so only the people involved with bootloader security have the clearance and technical means to decrypt the emails with the signed shim binary provided by Microsoft.
The keys used in our SHIM for Secure Boot are managed and safeguarded through a rigorous process that involves strict access controls, encryption, and regular audits. Access to these keys is limited to authorized personnel only, with multi-factor authentication and role-based permissions in place to prevent unauthorized access.
This comment mentions software-based storage of private keys. I don't think Microsoft is going to approve of that - see the Tech Community entry on UEFI Signing Requirements as of April 9, 2024:
i. 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. ii. The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2.
The answer regarding GRUB2 binary's global SBAT generation number claims that it's been set to 4
, but later on there's a contradictory answer, saying that it's actually 3
- your entries appear to be:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,3,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2
grub.policorp,1,Policorp Tecnologia,grub2,2.06-13,contato@policorp.com.br
(see the grub,3
line).
The upstream Debian SBAT entries are correct, so I guess this is a typo. See for yourself (the bookworm
branch you wrote as it being the origin of Policorp's GRUB2).
I'll need to check the GRUB2 modules in the future carefully. In the provided list, ext2
is duplicated, among other curiosities that bother me.
Thanks for your review, i would like to provide some corrections and clarifications regarding some issues raised recently:
Addition of Public Key A public key generated in .PEM format was added.
Contact Email Update The contact email has been modified to direct to the person responsible for managing our system's subscription process. This change will ensure more effective and direct communication regarding this critical aspect of our project.
Key Management Method There was a misunderstanding on our part regarding the key management method. We do not use software for this purpose; instead, we rely on a USB Token exclusively designated for this purpose. Furthermore, we have a machine dedicated exclusively to this functionality. Only authorized personnel have access to these devices, thus ensuring adequate security and control.
Correction regarding GRUB2 Global SBAT Regarding the answer related to GRUB2 Global SBAT, there was a typo. The standard we follow is that of Debian, and not the one mentioned previously. GRUB2 Modules Loaded on Our System: There was a mistake regarding the modules loaded on our system. The above information was obtained from a discontinued version of our system. We currently use the modules loaded by default in the Debian Bookworm version
Addition of Public Key A public key generated in .PEM format was added.
Please export the public key in a PGP public key block format with blatantly available armor boundary. The current policorp.pem
file is either malformed or I don't know, how to decode it properly.
Thanks for the answer.
We already updated, adding our PGP keys in two separate files .pub, the keyserver link is on Readme.md
While the keys have been attached, there are some things that make me worried:
Thanks for the answer
We changed our .pub files, now our keys are 4096 bit key and we prolong the validate date
- The other one is valid only for a year, therefore the verification process will need to be repeated most likely when a new shim version comes out. Is this the intended process?
just chiming in from the side-lines here: having a short expiration date is actually a good thing! it means that if you lose access to the key and the revocation certificate (which should not happen, but you never know), it will become unusable on its own. extending the expiration date is easily done, and does not require revalidating the key and doesn't change its fingerprint (it does require access to the key that signed it). of course, you do have to remember to both extend the key and published the extended version, else other people won't be able to contact you.
Contact verification emails sent - please respond here as instructed.
Thanks for the answer.
Message for our primary contact(Lucas Adriano Salles): coiffure Ionics riced extemporized engravings keenly Della styling dotage.
Message for our second contact(Luiz Henrique da Silva de Oliveira): confrontations software Wiley shadowiest cannot Marylou stinger safaris starling waterline
Contacts verified OK
All the most crucial details have been taken care of, as far as I'm aware. If no curiosities, that need to be discussed, will be found, I think everything's alright and the application can be accepted. We just need one more official reviewer confirm this.
Binaries are producible by running "docker build ." (Ok)
hash value is matched
NX is disabled (Ok) /efi-boot-shim# objdump -x shimx64.efi | grep -E 'SectionAlignment|DllCharacteristics' SectionAlignment 00001000 DllCharacteristics 00000000
sbat seems ok
objcopy --only-section .sbat -O binary shimx64.efi /dev/stdout
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.policorp,1,Policorp Tecnologia,shim,15.8,contato@policorp.com.br
bat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2
use ephemeral key (good)
Certificate Validity (?) : 20 years + 2048 bits + EKU codesign openssl x509 -in policorp.der -inform der -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
05:3f:35:68:a5:79:45:73:1a:a3:aa:17:b1:b2:0f:72:83:61:f3:6d
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = BR, ST = Amazonas, L = Manaus, O = Policorp Tecnologia Ltda., CN = Secure Boot Signing, emailAddress = contato@policorp.com.br
Validity
Not Before: Aug 23 15:24:22 2023 GMT
Not After : Aug 18 15:24:22 2043 GMT
Subject: C = BR, ST = Amazonas, L = Manaus, O = Policorp Tecnologia Ltda., CN = Secure Boot Signing, emailAddress = contato@policorp.com.br
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
...........
X509v3 extensions:
X509v3 Subject Key Identifier:
90:86:68:CE:7B:1A:DE:11:67:90:19:41:CA:42:A1:13:ED:92:44:5C
X509v3 Authority Key Identifier:
keyid:90:86:68:CE:7B:1A:DE:11:67:90:19:41:CA:42:A1:13:ED:92:44:5C
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
Code Signing, 1.3.6.1.4.1.311.10.3.6, 1.3.6.1.4.1.2312.16.1.2
Netscape Comment:
.............
Question about your last validity year 2043. Because NIST deems RSA 2048 sufficient until 2030, that is to say 2048 bit keys will be valid up to about the year 2030. May I suggest you change the last year to 2030 next time ? Otherwise any code you sign with a 2048 bit key today will have to be re-signed with a longer key in the year 2029.
conclusion: This task has been reviewed by many experts, like @steve-mcintyre, @aronowski and @es-fabricemarie. Contact verification is ok. The global generation number of sbat of grub has been fixed. The RSA public key length has been changed from 1024 to 2048 bits, but the last validity year is dangerous. Hope to change that minor error next time. It seems everything is fine. Accepting.
Thanks for the review, we have a question, when we go to Microsoft's file subscription service, they ask for a .cab file, what should this .cab contain? We got stuck on that part.
On 2024.06.19 10:10:39, policorp-dev wrote:
Thanks for the review, we have a question, when we go to Microsoft's file subscription service, they ask for a .cab file, what should this .cab contain? We got stuck on that part.
It should contain only your shim binary, which got accepted as per this application. When opening the archive, the binary should be instantly visible, i.e. no nested directories or any other files.
-- Reply to this email directly or view it on GitHub: https://github.com/rhboot/shim-review/issues/405#issuecomment-2179187795 You are receiving this because you were mentioned.
Message ID: @.***>
@policorp-dev and you should sign your cab file with your corporate EV certificate to certify it comes from you. Requirements/docs are here: https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/file-signing-reqs
@policorp-dev did you get a signed shim back?
Confirm the following are included in your repo, checking each box:
What is the link to your tag in a repo cloned from rhboot/shim-review?
https://github.com/policorp-dev/shim-review/tree/policorptecnologia-shim-x64-20240327
What is the SHA256 hash of your final SHIM binary?
677f300cc3c019d0909af41229309d0016f62e962df534781a83560ca5e352ae shimx64.efi
What is the link to your previous shim review request (if any, otherwise N/A)?
N/A