Hacker News new | ask | show | jobs
by IngoBlechschmid 26 days ago
Okay, yes, sure. It definitely is the most-used encryption software for Windows.

But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others:

38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM

5 comments

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).

BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.

Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.
Yah, it seems blatantly hostile how much they hide it.

I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.

But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.

For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.

It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.
It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation
"Disk must be in expected hardware environment" versus "Same environment plus PIN" makes a huge difference if a thief simply steals a whole computer.
Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?
Because the TPM effectively rate limits brute forcing of the key.

https://learn.microsoft.com/en-us/windows/security/hardware-...

> For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This totals a maximum of about 4,415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.

In that case, the median would still be just over a month, if the PINs were entered in order of how commonly they are used. Even the worst case of two years is still soon enough for a lot of data still be useful.

Also, how is the time limit enforced? With hardware access, it would be easy to change time or increase the clock rate, as well as many other side-channel attacks that could eliminate the wait altogether.

The time limit is enforced by the TPM itself which defends against tampering.
I found some pictures of TPM modules with crystal oscillators, so those could keep time while powered on, but wouldn't be able to keep time while off. It would be possible to only count time while on, but that would be really annoying to a legitimate user that kept turning off the computer, waiting for the time limit to expire, especially if it doesn't tell the user how much time is left.

Anyway, crystal oscillators connect to one input pin and one output pin, with an internal feedback circuit that causes the crystal to resonate. It's possible to change out the crystal for a higher frequency, or even directly drive the input pin for a much higher frequency. Semiconductor manufacturers often only characterize the limit of the feedback circuit, but not the limit of the internal clock circuitry when directly driven. Considering that the logic design supports an SPI bus running up to tens of megahertz, it's totally possible that the crystal input could be driven at a similar speed, possible a thousand times faster than a normal real-time clock oscillator.

There would be several ways to mitigate such an attack, but a quick search for TPM side-channel attacks brings up multiple much simpler vulnerabilities, so it's not likely that TPM manufacturers are putting any real effort into mitigation.

Most enterprises require a 12 digit code, to meet a specific security standard. Bruteforcing that, with hardware access restricted by TPM, would take a very, very long time.
You're also not restricted to 4 digits. A full passphrase is an option.
Which I wish was more heavily advertised because a passphrase is a lot easier to remember.
> the TPM effectively rate limits

I had a friend working at trusted compute at Microsoft, and he had so many stories.

These TPM firmwares are often written by shitty companies that have no fxcking clue what they are doing.

Most TPM implementations are a clown show, companies just want to check a box on paper so they say "look! We have a TPM!" and move on.

A quick search for "TPM side-channel attack" substantiates that claim.

Looking at the manufacturers of TPM ICs, it makes sense. Most of them make microcontrollers that have code-protect bits in them that are notorious for being susceptible to simple side channel attacks, but also for not being a target simply because no one cares about the object code on any random product's microcontroller.

I worked at a company that sold a microcontroller that executed from external memory, so there was no possible way to have built-in code protect bits, and some potential customers complained until we included a library to encrypt the external memory, run a small unencrypted bootloader which included the a plain-text decryption key, then run the encrypted program. That checked their box, despite doing nothing useful.

No one uses a 4-digit pin for BitLocker. No one who knows what they are doing, anyway.

My employer requires at least an 18-digit PIN, and not just numbers, either.

If you're really serious, you use a strong password, not a PIN.
If you are at all serious about security you don't consider Windows.

Depending on how serious you are you also don't consider MacOS.

And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model

And then depending on how "serious" you are you also don't consider Linux.

But also, threat models and the best way to mitigate them aren't really a linear scale of being <unserious> to <serious>, but a complex consideration of a particular situation.

People just plain suck at opsec. Like Che Guevara might have had a longer career as a revolutionary if he'd used his one time pads only once.

Back in the late 1980s it was clear that it would be no problem at all to hook up a hard drive to a digital phone exchange and record all the calls! I had a strict policy of "don't talk about anything illegal using electronic communication" even when it was rather banal stuff like selling weed.

The carelessness of people at Facebook documenting policies that nobody in their right mind would document boggles my mind: you might as well leave it mysterious why you didn't crack down on scam ads, for instance. When I've been involved in minor conspiracies, say when we had an HR problem with another employee, I've always made the point to meet furtively in person and avoid leaving a paper trail so that I'd never need to explain an email I wrote in front of an unfriendly audience.

>But I would never trust it a second, being proprietary and known for issues

While true if you don't trust the proprietary encryption you shouldn't trust the proprietary OS either. I think bitlocker backdoor or bugs should be the least of your concerns when the OS is literally known for covertly exfiltrating data to the cloud.

If you think for one single second that businesses and governments who rely on a lost disk being secure don’t trust bitlocker, I have oceanfront property in Missouri to sell you.

Bitlocker + PIN is as secure as anything.

A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

> A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.

I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.

BitLocker with PIN works like this:

* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).

* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.

* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.

Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.

Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).

Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).

BitLocker with pin is not vulnerable to that (or any other) attack.

10 points deducted. Try again.

> or any other

last famous words? :D

I appreciate your desire to shit on Microsoft for everything they’ve ever done, but they got BitLocker with PIN right.

Explain how an exploit can decrypt the drive without the portion of the key that the user must enter. The computer doesn’t know the entire key, and can’t decrypt the drive without it, or the recovery key. This is why BitLocker with PIN hasn’t been defeated yet. I don’t understand how it could ever be defeated without entering the PIN.

veracrypt lost their drivers license so afaik you should avoid it since it cannot update its drivers any longer. didnt see any news about them reacquiring that license
Assuming this is what you are referring to, it was resolved within a few days. The incident being resolved just didn't make headlines. https://sourceforge.net/p/veracrypt/discussion/general/threa...
aah cool, thank you..100% missed the update :). thanks! thats good to read honestly lol. not that i use windows much but i felt it was MS trying to undermine it. happy it got restored and there remains an alternative to butlocker.