Comment by themeek | Hacker News Reader

Comment by themeek | Hacker News Reader

Bitlocker (well, "Device Encryption") does upload your harddisk keys to OneDrive by default, and OneDrive is onboarded to PRISM for government request.

So in the case that you end up provisioning a computer or device with Bitlocker, the key may very well end up in a database for query.

Outside of this it's not really so speculative to think that Bitlocker has backdoors for gov't access. It's unlikely that Microsoft Bitlocker survived the combined forces of state-of-the-art cryptanalysis, legal compulsion, and company infiltration (exposed by Snowden).

A backdoor for disk encryption need not directly attack the cryptography. It could be something as simple as a means to generate a bunch of predictable blocks on the harddrive - that's enough to break XTS. That is, even if there's no software backdoors or backdoors build into the TPM (Lenovo, for example, has 'key escrow' capabilities to extract Bitlocker keys out of TPMs) or crypto backdoors in HW PRNGs (e.g. Intel RDRAND), etc there are software bugs in other places that could reveal the contents of the hard disk.

So it's merely not a threat model you're ever going to find a solution for. In the very worst case, presuming there were some mystical level of harddisk encryption that was't trivial to backdoor or break by a sophisticated adversary - intelligence folks can use TEMPEST attacks, break into your computer when you turn it on, and/or get rubber hose access. An encrypted disk will not stop Mossad.

There is no disk encryption that will unilaterally prevent USG from accessing your files (you can only make it more expensive).

But as the USG is fond of repeating - you don't need your disk encryption to protect you from the government unless you have something to hide. You only need it to prevent attacks from criminals and for device theft.

Can you explain more carefully the XTS attack you're contemplating here?

The Device Encryption recovery key feature was discussed at length here: https://news.ycombinator.com/item?id=8546524

Certainly, people who are concerned about security should disable/avoid it.

Sure. XTS reuses the sector-block for an IV, and so on a per-block level encryption is deterministic. The flaw here would be a scenario where there are deliberate repeated modifications to blocks of the harddrive (somewhere like within hibernation/wake code). Something carefully designed could, in theory, lead to the compromise at a block level that would allow tweaking of some contents on the disk (say, contents of the registry, or of some boot switches, etc) that would in turn enable the machine to be booted and the disk to be decrypted.

It's also true that the TPM protector for bitlocker uses a pin with max ~20 bits of entropy to shield the bitlocker key from exfiltration. The TPM is supposed to lock out repeated requests to extract they key but given the heavy involvement of the NSA in designing the TPM spec and its similarity to the Clipper Chip in function (so too with Apple's "Secure Enclave"), and its difficulty to audit (as if mom and pop consumers really need protection from adversaries who are going to reverse TPM chips to get computer data), one can't help but to acknowledge that a backdoor could easily exist there.

All of this is hypothetical of course. I don't claim to know that this sort of attack is there or that it is placed deliberately. I'm merely trying to make the point that a backdoor need not be in the harddisk encryption code itself.

I'm still not clear. XTS doesn't have an IV; it has a tweak key. It's deterministic (which also means it can leak data, ECB-style, across successive encryptions of the same sector). The tweak key is simply the product of the encrypted sector number multiplied by a polynomial; I don't understand what tricks you can play with it.

The fundamental attack you seem to be describing --- that an attacker can rewrite the contents of the disk --- applies to practically every sector-level cryptosystem; none of them are authenticated. But XTS can't productively use "patterns" of disk blocks, unless there's a clever attack I don't know about (hence me asking).

No, we're on the same page. I don't have an attack on XTS you are not aware of.

Code (again pretend in hibernate/wake behavior) that deliberately leaks information about important boot blocks on the disk could lead to a full compromise. The attack and back door, of course, would be fairly sophisticated in this instance.

You'll concede that the possibility exists, but that its hard to evaluate. What I'm trying to contribute is not that such a backdoor is currently used (I have no idea) - but that RDRAND/TPM/XTS-leak or other non-Bitlocker backdoor can be used to thwart Bitlocker if we imagine that it hasn't been directly backdoored.

I'm honestly still not following the XTS leak you're talking about. The deterministic leak I'm talking about happens because XTS isn't randomized: as you write and rewrite the same sector, you're doing so against the same set of "tweaks". I think that's a meaningful problem --- particularly if you're using XTS to encrypt something other than a disk, particularly in a cloud setting --- but as a backdoor, it's a pretty crappy one, because it requires your computer not only to be on and "unlocked", but also for you to continuously update the targeted blocks.

It's an especially dumb backdoor for Microsoft, who could literally backdoor the Comic Sans TTFs to greater affect. Why would they tamper with the most sensitive code on the entire system, to get a fifth-rate backdoor, when they could get a first-rate remote backdoor out of virtually any code on the whole system?

Subtextually: I just generally dislike FDE, as anything more than a "my computer got stolen out of the back of my car" mitigation.

If you are worried about attackers with continuous high-touch access to your computer, no FDE system helps you. Reliance on FDE more or less made the DOJ's case against Ross Ulbricht, for instance.

> as you write and rewrite the same sector, you're doing so against the same set of "tweaks".

> but as a backdoor, it's a pretty crappy one, because it requires your computer not only to be on and "unlocked", but also for you to continuously update the targeted blocks.

The hypothetical backdoor in this example would be in boot/hibernate/wake/suspend/whatever code - i.e. not "on and 'unlocked'". That's the entire point of this backdoor. If the computer needs to access encrypted parts of the disk during boot - even if encryption is done by an e-drive rather than in software - code that causes repeated writes (or even a single write) to an important sector could be designed to subvert FDE.

But it doesn't really matter about this particular hypothetical. We both agree that there is plenty of room to backdoor Bitlocker without having to rely specifically on bitlocker code.

> Reliance on FDE more or less made the DOJ's case against Ross Ulbricht, for instance.

I was under the impression that the FDE used by Ulbricht complicated things a lot, and took special measures to get around, and that they were purely lucky to even be able to do so, and he compromised sensible operational security to allow them to do so.

The story goes that they got him in a public place, distracted him momentarily, while someone else swiped the notebook off his desk making sure not to close the lid and kept it from auto locking over time by continuously remaining active with it.

Reply on news.ycombinator.com