Shim 15.2 for BCWipe Total WipeOut

[Jetico]

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
  https://github.com/Jetico/shim-review
• completed README.md file with the necessary information
  https://github.com/Jetico/shim-review/blob/master/README.md
• shim.efi to be signed
  https://github.com/Jetico/shim-review/blob/master/shimx64.efi
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
  https://github.com/Jetico/shim-review/blob/master/pub_cert.der
• binaries, for which hashes are added do vendor_db ( if you use vendor_db and have hashes whitelisted )
• any extra patches to shim via your own git tree or as files
  https://github.com/Jetico/shim-review/blob/master/shim.patch
• any extra patches to grub via your own git tree or as files
• build logs
  https://github.com/Jetico/shim-review/blob/master/shim_build.log

What organization or people are asking to have this signed:

Jetico Inc. Oy (www.jetico.com)

What product or service is this for:

BCWipe Total WipeOut ( https://www.jetico.com/data-wiping/wipe-hard-drives-bcwipe-total-wipeout )

What is the origin and full version number of your shim?

https://github.com/rhboot/shim/tree/15.2

What's the justification that this really does need to be signed for the whole world to be able to boot it:

BCWipe Total WipeOut is full disk erasure solution users worldwide rely on to protect their privacy when donating, repurposing or selling their PCs. For a security-oriented tool like BCWipe Total WipeOut support for Secure Boot is essential.

Jetico, the vendor of BCWipe Total WipeOut has 25+ years of spotless reputation developing data security products. Jetico products are trusted by government and military agencies, all of the top 10 U.S. defense contractors, many national laboratories, as well as various other enterprises and a wide global base of home and small business users

How do you manage and protect the keys used in your SHIM?

It is stored on e-Token
Physically isolated
Only one person has access to it

Do you use EV certificates as embedded certificates in the SHIM?

Yes

If you use new vendor_db functionality, are any hashes whitelisted, and if yes: for what binaries ?

No

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a linux kernel ?

Yes, we use kernel 5.4.69 with this patch included

if SHIM is loading grub2 bootloader, is CVE CVE-2020-10713 fixed ?

Yes, we use the latest code from the GRUB git repo, which includes the required patches.

Did you change your certificate strategy, so that affected by CVE CVE-2020-10713 grub2 bootloaders can not be verified ?

Yes. We are now utilizing OpenSSL's ability to create and verify files' digests. That allows us to sign every file that it part of the boot process, including GRUB, Linux kernel, etc and to check the signature thereof. Thus if a file is replaced by an attacker, it will be detected.

What is the origin and full version number of your bootloader (GRUB or other)?

https://git.savannah.gnu.org/git/grub.git master branch
2df291226638261d50fadcab1f5edb6c12ab6cfd

If your SHIM launches any other components, please provide further details on what is launched

Only grub

How do the launched components prevent execution of unauthenticated code?

The modules loaded by our SHIM are signed by Jetico EV certificate. Our shim loader verifies the signatures of all the files before loading them. This is implemented in the following code:"

https://github.com/Jetico/shim-review/blob/master/shim.patch

When our shim starts, it looks for the efi_boot.lst file, which is also signed and thus can be verified. This file lists the names of all components involved in the download process. Each component should have the digest file with the name in the form comp_name.dgst. If such a file was not found or the digest it contains does not match the calculated shim, the download stops and an error is reported.

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No, our SHIM loads only the modules that are signed by Jetico EV certificate (GRUB)

What kernel are you using? Which patches does it includes to enforce Secure Boot?

Kernel 5.4.69 with patches
1957a85b0032a81e6482ca4aab883643b8dae06e
75b0cea7bf307f362057cc778efe89af4c615354

What changes were made since your SHIM was last signed?

It was not signed yet

What is the hash of your final SHIM binary?

sha256 786afedbecd50617ed9de95655461e5302b6ac1f4c2a5f4631a04667f1f3253a

[Jetico]

To whom it may concern,
There had been no progress with our submission for over 20 months now. 18 months for the original ticket and over 2 for the newer one, both receiving no review.
The lack of compatibility with Secure Boot is affecting our reputation as a data security software vendor.
What can be done to help get our boot loader reviewed sooner?

[Jetico]

To whom it may concern,
There had been no progress with our submission for over 20 months now. 18 months for the original ticket and over 2 for the newer one, both receiving no review.
The lack of compatibility with Secure Boot is affecting our reputation as a data security software vendor.
What can be done to help get our boot loader reviewed sooner?

[julian-klode]

As has been pointed out 2 months ago in the pinned issue #120, shim signing is on hold for an undefined duration while work is ongoing to implement new revocation mechanisms. No shim submitted so far will be signed, and how future shims will be signed is a topic yet to be explored.

[martinezjavier]

@Jetico please update this request to use the shim 15.4 release. Or close this issue and file a new one based on that version.

[Jetico]

Is there any changes in the shim review process? We are waiting for review more then two years already and this our second ticket. Is there any reason to post new one and wait for years?

[Doncuppjr]

If you want to wait for years, I guess you could, but I see no reason to do that. Try reviewing someone else and see if that doesn't get things moving for you.

[miray-tf]

@Jetico Shim 15.4 added a new revocation mechanism. Shims older than that version will not get signed.
The Grub version you referenced has issues that allow to circumvent validation, so you need to update that as well. Grub 2.06-rc1 would be a good starting point for that.

You use a custom mode to verify images loaded by shim. Can you explain why? Do you think there is anything missing in the way Shim validates files?

[steve-mcintyre]

@Jetico sorry you've had a bad experience here. Especially in the last few monthst we've had a massive amount of work to do on shim upstream. That has cumlminated in latest 15.4 release, and even then there are a few recommended patches on top (see #165). We're catching up on a lot of reviews now.

As others have said, a build of 15.2 will not meet the requirements for signing any more so I'm afraid you'll have to move forwards to 15.4. I'm therefore closing this review now.

I'm trying to steer shim development discussions into being more open, and we have a mailing list now: https://lists.einval.com/cgi-bin/mailman/listinfo/efi