shim-15.8 for circle linux 8 x64/ia32/aarch64

[rouzer-zhou]

Confirm the following are included in your repo, checking each box:

• completed README.md file with the necessary information
• shim.efi to be signed
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed )
• any extra patches to shim via your own git tree or as files
• any extra patches to grub via your own git tree or as files
• build logs
• a Dockerfile to reproduce the build of the provided shim EFI binaries

---

What is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://github.com/circle-linux/shim-review/tree/circlelinx-8-shim-15.8-ia32-x86_64-aarch64-20240823

---

What is the SHA256 hash of your final SHIM binary?

---

e09f2e4ed95a9ae13f049da759c12e9010a0237c8c60a95f380b2da3ed8daf88 shimia32.efi 1a7e22a6af755ae8e0ab7de8cad76b282359d58f5dbb435aa7736de60833e491 shimx64.efi c7859015269418167ac9aa3e431e6f4c7ac92c4e271444cfcda35bfa950b1362 shimaa64.efi

---

What is the link to your previous shim review request (if any, otherwise N/A)?

---

• shim-15.6: shim-15.6 for circle linux #271

---

If no security contacts have changed since verification, what is the link to your request, where they've been verified (if any, otherwise N/A)?

---

• shim-15.6: shim-15.6 for circle linux #271

[es-fabricemarie]

• Built from original 15.8 without patches
  • a79f0a9b89f3681ab384865b1a46ab3f79d88b11b4ca59aa040ab03fffae80a9 shim-15.8.tar.bz2
• Build reproducible for x64/ia32/aa64:
  • authenticode 9e46400dc7a64551179d25857581af15c8a403cb862bec772d9fc428de1de731 shimia32.efi
  • authenticode ea990c591337ee68f693319110fb927f5c1f2bcff0ba39e6ab89531bffdac36c shimx64.efi
  • authenticode 08c439286bdb22124dae0f119f2f9bec9e1af6a95d8488a327a6d82b7a9e957e shimaa64.efi
• embedded cert is a CA:
  • valid less than 10 years: Not After : Jul 5 05:56:18 2031 GMT
  • 2048 bit RSA key
  • key in HSM
• NX bit disabled (DllCharacteristics 00000000)
• sbat sections looks ok

Question:

• is the 2.02-156.el8 version of grub the latest from upstream?

[steve-mcintyre]

Contacts have previously been verified

[rouzer-zhou]

• Built from original 15.8 without patches

  * `a79f0a9b89f3681ab384865b1a46ab3f79d88b11b4ca59aa040ab03fffae80a9  shim-15.8.tar.bz2`
  

  • Build reproducible for x64/ia32/aa64:

    • authenticode 9e46400dc7a64551179d25857581af15c8a403cb862bec772d9fc428de1de731 shimia32.efi
    • authenticode ea990c591337ee68f693319110fb927f5c1f2bcff0ba39e6ab89531bffdac36c shimx64.efi
    • authenticode 08c439286bdb22124dae0f119f2f9bec9e1af6a95d8488a327a6d82b7a9e957e shimaa64.efi

  • embedded cert is a CA:

    • valid less than 10 years: Not After : Jul 5 05:56:18 2031 GMT
    • 2048 bit RSA key
    • key in HSM

  • NX bit disabled (DllCharacteristics 00000000)

  • sbat sections looks ok

Question:

* is the 2.02-156.el8 version of grub the latest from upstream?

Yes, it is the lateste version of el8.

[aronowski]

I'll need to take a deeper dive into the application, although I've already managed to check, that the builds are reproducible.

Hint: it's about CVE-2024-45678, that is about extracting private keys, given physical access to a hardware token and a specialized equipment:

The keys are stored on a FIPS 140-2 certified HSM. Access to machine used to sign binaries is restricted physically. Only 2 trusted individuals have access to it.

What kind of mitigations have been applied to prevent unauthorized physical access? What access control methods are implemented and who are the people, who can access your HSM physically?

Note: this may not be about the access to the signing machine, if your HSM is stored in a remote location, e.g. a server room guarded by the provider's security guards, and the signing machine can authorize itself remotely.

[rouzer-zhou]

I'll need to take a deeper dive into the application, although I've already managed to check, that the builds are reproducible.

Hint: it's about CVE-2024-45678, that is about extracting private keys, given physical access to a hardware token and a specialized equipment:

The keys are stored on a FIPS 140-2 certified HSM. Access to machine used to sign binaries is restricted physically. Only 2 trusted individuals have access to it.

What kind of mitigations have been applied to prevent unauthorized physical access? What access control methods are implemented and who are the people, who can access your HSM physically?

Note: this may not be about the access to the signing machine, if your HSM is stored in a remote location, e.g. a server room guarded by the provider's security guards, and the signing machine can authorize itself remotely.

The private key is stored in the pesign rpm package. The package is located in a
repository that is inaccessible to the outside world without authorization.
This special pesign package is temporarily installed only when compiling grub,kernel,and
other packages which need signing of the private key.

[es-fabricemarie]

@rouzer-zhou sorry I'm confused. How can your private key be in an HSM if it's part of your modified pesign RPM?

The whole purpose of an HSM is that no one can extract the key throughout its lifetime. If it is in an RPM it means that a disgruntled employee or an attacker could leak it and sign anything with it.

[rouzer-zhou]

@rouzer-zhou sorry I'm confused. How can your private key be in an HSM if it's part of your modified pesign RPM?

The whole purpose of an HSM is that no one can extract the key throughout its lifetime. If it is in an RPM it means that a 》>disgruntled employee or an attacker could leak it and sign anything with it.

The private key is stored in a HSM, In addition it is also stored in a pesign package not released to the public.
This pesign rpm package containing the private key is stored on a controlled internal network server.
We temporarily use this pesign package when compiling grub ,kernel. In other cases we use a pesign
package which is released to the public and only contains the testing signing key.

[SherifNagy]

@rouzer-zhou sorry I'm confused. How can your private key be in an HSM if it's part of your modified pesign RPM?
The whole purpose of an HSM is that no one can extract the key throughout its lifetime. If it is in an RPM it means that a 》>disgruntled employee or an attacker could leak it and sign anything with it.

The private key is stored in a HSM, In addition it is also stored in a pesign package not released to the public. This pesign rpm package containing the private key is stored on a controlled internal network server. We temporarily use this pesign package when compiling grub ,kernel. In other cases we use a pesign package which is released to the public and only contains the testing signing key.

The key is kept clear in an RPM internal? why? what's the technical reason behind not using the HSM to sign the rest of your boot chain?

[steve-mcintyre]

The private key is stored in a HSM, In addition it is also stored in a pesign package not released to the public. This pesign rpm package containing the private key is stored on a controlled internal network server. We temporarily use this pesign package when compiling grub ,kernel. In other cases we use a pesign package which is released to the public and only contains the testing signing key.

If your private key is stored outside of the HSM too, then that negates the point of the HSM. Why are you doing this?

[rouzer-zhou]

If your private key is stored outside of the HSM too, then that negates the point of the HSM. Why are you doing this?

Due to hardware resource restriction, our HSM environment has not been fully set up yet. So, we now temporarily use pesign package containing private key to compile grub and kernel. We will set up HSM environment in the future.

[es-fabricemarie]

@rouzer-zhou when you use the HSM properly (generate the key directly on the HSM with security mode turned on) it will prevent you in the first place from extracting the private key from it. So how can you have the key both in the HSM and in the pesign package?
Did you generate the key on your machine and only then imported the key to the HSM?

[rouzer-zhou]

Did you generate the key on your machine and only then imported the key to the HSM?

Yes, I generated the key from openssl and imported the key to the HSM.

[es-fabricemarie]

@rouzer-zhou this is unfortunately unacceptable. The key needs to be generated on the HSM in secure more: the key will forever be on the HSM and be un-exportable. This is to ensure that no-one ever steals the key. This committee will not approve your shim unless you fix that.

For HSM you can either use a FIPS Yubykey or similar. Or you can use a cloud based HSM.

Using PKCS11, pesign or sbsigntool will be able to instruct the HSM to sign on your behalf, never revealing the key.

[aronowski]

To clarify, the latest discussions were about clarifying what OP has claimed, i.e.:

The keys are stored on a FIPS 140-2 certified HSM. Access to machine used to sign binaries is restricted physically. Only 2 trusted individuals have access to it.

So at this point it's not even about potential vulnerabilities like CVE-2024-45678 anymore. Right now, that statement contradicts what has been said in the ongoing discussions, i.e. that not only the HSM is not even fully set up, but also that the private part just casually resides somewhere easily accessible for a duplication by a malicious actor. Trying to mitigate this by limiting networking access may sound OK, but wouldn't prevent sophisticated malware, tailored even to bridge air-gaps, from exfiltrating the key, even if we assume that only that the 2 fully trusted individuals have access clearance to where the key is used directly.

Remember: trust is hard to earn and easy to lose.

As part of recovering the trust, and also as a learning process, I'd highly recommend contributing to the shim community as suggested in the "What contributions have you made to help us review the applications of other applicants?" question, by writing a guide/walkthrough on how to set up an HSM (the model you have, along with the vendor libraries and SDKs) as part of the signing infrastructure you're still about to set up:

Due to hardware resource restriction, our HSM environment has not been fully set up yet. So, we now temporarily use pesign package containing private key to compile grub and kernel. We will set up HSM environment in the future.

That would come in handy for others, in particular for future applicants who own the exact same HSM as you do, but are struggling with setting it up to work with their tooling.