Crash Key, WPBT blocking, PPL support & Encrypted EFI

The issue proposes four broad features but names no source files, tests, or entry points. Start by reading the project’s bootloader and platform-specific code to assess which proposal, if any, is in scope. Done is not defined; the proposals need maintainer discussion and a narrower, actionable issue before implementation.

Crash Key, WPBT blocking, PPL support & Encrypted EFI
I would like to suggest the above ideas that I will explain in detail just incase it might attract the interest of some VeraCrypt project contributors who might actually know how to implement them, and might find them useful.

Crash Key
Starting with the first idea, the Crash Key is a key combo (hotkey) that should work immediately right after the VeraCrypt password prompt appears on the pre-boot decryption screen.

This hotkey when pressed immediately causes secure erasure of the entered password data in the password field if the password wasn't validated yet (presssing enter) then crashes the boot environment (freeze of the PC or brutal shutdown).

If the password has been validated and the operating system starts booting, the hotkey should still work even while the operating system is booting, so that the OS cans be crashed at any time as described above incase of attackers trying to exploit the time needed to fully boot the system to initiate an assault against the device owner.

Scope: All operating systems (Linux, Mac OS, Windows).
Importance: High.

WPBT blocking
Many of you know about Microsoft's deliberate vulnerability that they implemented forcefully, named Windows Platform Binary Table.
I say forcefully implemented because they did not specify that the computer vendor must provide the ability to disable it directly within the EFI firmware setup.

And because it's enabled by default on Windows, it allows the manufacturer of a computer to insert untrusted binaries into the encrypted system drive, then these get executed automatically before getting deleted after execution; leaving no visible traces of it for the user.

BIOS updates might as well bring a new WPBT binary, with perhaps more vulnerabilities inside.

The general rule of an encrypted system drive is that it should not be possible, by principle, to automatically insert inside after decryption anything that the user didn't intentionally cause themselves.

Malware cans be argued to be the user's fault for running dodgy programs, but in the case of the Windows Platform Binary Table this is different; the appropriate registry key for DisableWPBT in the Session Manager branch of the registry should automatically lead to being disabled by VeraCrypt when the system drive is encrypted.

Scope: Windows.
Importance: Low.

PPL support
PPL stands for Protected Process Light, which many security vendors seem to be able to make work on their security products such as antiviruses, and seemingly even game developers seem to be eligible for making their games use PPL.

So I was thinking, why not perhaps consider starting to use Protected Process Light attributes on the VeraCrypt binaries, since Idrixx even has an EV code signing certificate for the VeraCrypt kernel driver.

I don't myself exactly know how Protected Process Light should be implemented if it's possible for VeraCrypt, but it would be interesting to have it since whenever Microsoft will improve PPL, then VeraCrypt will automatically benefit from their improvements.

Not having it is not really that much of an issue but more like a bonus though.

Scope: Windows.
Importance: Low.

Encrypted EFI
That's one thing that I'm interested in, Encrypted EFI partition for protecting potentially vulnerable boot configuration files from tampering.

For example, on Windows when using BitLocker, the BCD registry hive containing sensitive boot configuration settings such as testsigning or even the kernel and osloader directives, is automatically protected by integrity checks (measured boot).

But when using third-party FDE solutions, OS-specific pre-boot configurations might not actually be protected from tampering.

The way an Encrypted EFI partition would work, is that if the user opts in to using this feature, then the operating system's current partition is shrunk by 300MB (with appropriate safeguards) and a new EFI partition is created (second one), where all current EFI files are moved.

Then a separate, and dedicated shim based on the original DCS / UEFI bootloader for VeraCrypt is placed in the original EFI partition.

Then the second EFI partition gets encrypted, with the same password as the system drive's own.

VeraCrypt then adds to the top of the UEFI Boot Order list its own Encrypted EFI partition bootloader shim, but leaves other entries unchanged (no need to alter them).

Then at the next boot, the user must actually enter a password that will be tested against both the second encrypted EFI partition and the system drive; if any of them fails to decrypt, a generic error message 'wrong password.' is shown (not specifying which partition failed to decrypt, thus not revealing the use of an encrypted EFI partition unless an evil maid takes the risk of e.g. physically opening a computer, which might have tamper seal stickers).

If the password is correct and decrypts both partitions (each their own volume header), then VeraCrypt now reads the UEFI Boot Order list except its own entry then takes the highest-priority one, locates it from the original path corrected to the new 2nd EFI partition path, and boots that EFI file.

VeraCrypt, depending on the operating system used might want to apply some BCD corrections or equivalent grub configuration corrections to facilitate this scenario.

I don't know if that would actually be possible on a Mac OS system though.

It might actually be possible to build an UEFI DXE driver to directly support encrypted EFI partitions, which would need to be included in an UEFI firmware image (BIOS mod).
No idea whether people would actually care about it or have enough experience themselves to do it safely.

Scope: Windows, and perhaps Linux.
Importance: Low.
Potential limits: Consideration of Hidden Volumes, SecureBoot compatibility, multi-boot scenarios (e.g. both Windows & Linux installed on the same drive), compatibility with Windows updates (if they need to update EFI files), compatibility with external WinRE partition booting, ability to reset the computer to factory state via external WinRE partition.

That's it
These were my suggestions so far, I hope that atleast one (Crash Key) will pick up the interest of the VeraCrypt project maintainers.

Thanks