#Microsoft locks account that #VeraCrypt maintainer uses to sign #Windows bootloaders with no explanation or route for appeal. If they don't fix this, in a few months every Windows computer that uses VeraCrypt whole-disk encryption will stop being able to boot and all the data on it that isn't backed up elsewhere will be lost. 🤦
If this doesn't convince you big tech has too much control, I don't know what will.
h/t @zackwhittaker
https://techcrunch.com/2026/04/08/veracrypt-encryption-software-windows-microsoft-lock-boot-issues/
#infosec #privacy #TechIsShitDispatch
Developer of VeraCrypt encryption software says Windows users may face boot-up issues after Microsoft locked his account | TechCrunch

The maker of the popular open-source file encryption software VeraCrypt said Microsoft locked his online account, which may prevent device owners from booting up their computers.

TechCrunch
@jik @zackwhittaker
Weeeelll, that's a bit too much panic!
Yes, the machines might not boot anymore, but the data is still there.
It can still be read on a normal Linux Live-ISO just fine.
@manawyrm @jik @zackwhittaker wait, so if the certificate expires *existing signed binaries* will no longer run? Does this mean any signed bootloader has an inherent shelf life and will need to be re-signed every so many years even if no changes are being made to it?
@azonenberg @manawyrm @jik @zackwhittaker afaik no. the expiry usually isn't enforced.

@gsuberland @azonenberg @jik @zackwhittaker that's what I would've expected as well, but I'm not 100% sure about how Windows driver signing works.

Either way, the data is perfectly fine :)

@manawyrm @azonenberg @jik @zackwhittaker fairly sure driver signatures don't have an expiry at all; it's only the CA that has an expiry and an expired CA doesn't invalidate an existing valid signature, as long as that signature's date was within the valid time range of the CA.
@manawyrm @azonenberg @jik @zackwhittaker (yes just checked and this is exactly how it works)

@gsuberland @manawyrm @azonenberg @jik @zackwhittaker the certificates used to sign them do have an expiry but timestamps solve both expired cert and expired CA. The only way to revoke it is to add that cert to a CRL and leave it there permanently. I've no idea if the windows kernel checks crls or just maintains a list of blocked certs but I'd expect it to share the logic with windows and keep a cached crl (could be wrong, a long time since I cared much about windows drivers).

UEFI I don't think checks either expiry or timestamps at all. Instead it has the dbx which can contain blocked certificates or hashes of binaries that should not load.

@diagprov @manawyrm @azonenberg @jik @zackwhittaker yup that tracks with my understanding of it. Windows does have a driver cert revocation mechanism and a more general blocklist to prevent loading known-vulnerable drivers, but I haven't studied it in detail.
@gsuberland @manawyrm @azonenberg @jik @zackwhittaker me neither but given how closely uefi code looks to Microsoft C code I bet the mechanism of dbx is very similar to the kernel.
@gsuberland @diagprov @manawyrm @azonenberg @jik @zackwhittaker there are two types of revocation lists, the old one that can revoke certs and binaries by hash (two different lists for boot and drivers), and the new one that's just a CiPolicy and can therefore revoke by anything that a CiPolicy supports.

@gsuberland @manawyrm @azonenberg @jik @zackwhittaker in an ideal world, the boot payload is checked by a secure enclave of your motherboard and if it doesn't look legit, it's refused, device doesn't boot and the secure enclave doesn't provide it's part of the decryption, meaning the data stay locked.

Also, all data on disk would be backed up somewhere safe so it would be simply a matter of wiping the device clean and reinstalling.