Hacker News Reader

Comment by themeek | Hacker News Reader

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.

View on HN

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