Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer and has pointed out and successfully exploited a rather obvious weakness in the BitLocker full volume encryption system, which as the linked article says, allows one to simply sniff the traffic between the discrete TPM chip and CPU via an SPI bus. The way Bitlocker works is to use a private key stored in the TPM chip to encrypt the full volume key that in turn was used to encrypt the volume data. This is all done by low-level device drivers in the Windows kernel and is transparent to the user.
The whole point of BitLocker was to prevent access to data on the secured volume in the event of a physical device theft or loss. Simply pulling the drive and dropping it into a non-secured machine or some other adaptor would not provide any data without the key stored by the TPM. However, since that key must pass as plaintext from the TPM to the CPU during the boot sequence, [Guillaume] shows that it is quite straightforward — with very low-cost tools and free software — to simply locate and sniff out this TPM-to-CPU transaction and decode the datastream and locate the key. Using little more than a cheapo logic analyser hooked up to some conveniently large pins on a nearby flash chip (because the SCK, MISO, and MOSI pins are shared with the TPM) the simple TIS was decoded enough to lock onto the bytes of the TPM frame. This could then be decoded with a TPM stream decoder web app, courtesy of the TPM2-software community group. The command to look for is the TPM_CC.Unseal which is the request from the CPU to the TPM to send over that key we’re interested in. After that just grabbing and decoding the TPM response frame will immediately reveal the goods.
What you do next is a matter of convenience, but most security and forensics types would already be sitting tight on a low-level disk image file of the target volume. By using the Linux xxd command to turn that 32-byte hex dump key into a binary key file, the dislocker-fuse FUSE module can create a dynamically decrypted virtual filesystem that you can just mount. If you wanted, you could then write the decrypted volume data to a fresh disk, drop it into a machine, and boot the operating system. You likely couldn’t log in, but as [Guillaume] points out, by overwriting the sticky keys app (sethc.exe) with cmd.exe, you can get to a command prompt just by banging the shift key five times. Good times!
If you actually need TPM support for an older system, in order to install Windows 11 (if you really must) then you could always just make your own. Also, since the LPC interface is on many a motherboard, why not leverage it and use it to hang an ISA bus adaptor to plug in that old classic Soundblaster card you couldn’t bear to junk?
Hmm, old news?
https://labs.withsecure.com/publications/sniff-there-leaks-my-bitlocker-key
Nice read. Thanks.!
“Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer ”
Stop it.
Agree
Agree
Agree
No
Oh heck, who was the idiot who decided that TPM modules didn’t need to negotiate a secure key (RSA style) with the host before handing it keys to other parts of the kingdom. They should be ashamed of themselves, you could see the flaw a mile away.
i was thinking exactly this…but then i realized, it’s not much of a failure.
if the machine needs to be able to boot up unattended (iow, without someone manually providing the secrets on the keyboard) then definitionally if you have the whole thing in your physical posession then you will be able to get unencrypted data into the device’s RAM. and then you’re just relying on (at best!) the OS’s security, which is an enormously broad attack surface.
it’s really a catch 22. i agree they should have done better but since we’re talking about encrypting a large volume on a complicated system, there’s no way to simplify it such that it becomes bulletproof. bitlocker appears to achieve the headline result of making the storage media useless if you don’t have the paired TPM unit. you could do incrementally better but you’ll always be able to find an attack if you have enough access to the whole kit to solder bodge wires onto the motherboard.
As someone who works with machines encrypted in this matter, it basically adds another level of risk if the entire machine were to be stolen or misplaced. With how small generic work computers have become it’s not unrealistic that a person could potentially sneak one out of a secure building. But mostly it just makes it even more of a problem if an entire computer is lost or otherwise unaccounted for.
Concerning the probing:
I find it works quite well to glue (hot snot, sticky tape) or clamp an angular IDC connector to the PCB, and then solder 0.2mm enameled wires between the IDC connector pins and various locations on the PCB.
Curious that Microsoft, who have previously demonstrated a greater amount of competence #(albeit still inadequate) in protecting IP on games machines, should do such an obviously incompetent job here. What is their agenda ? Is it an intentional failure ? Is it just ‘security theatre’, aimed at appearing to strengthen user security for marketing purposes but with no desire to incur the costs of doing it properly ?
Microsoft has for this reason both released the Pluton specification that puts the security processor on the CPU die to prevent bus sniffing attacks, and recommended to prevent such attacks to add a PIN to the BitLocker protector.
This isn’t a glaring flaw, it requires physical access to the host. The usual security caveats apply, if you have physical access, it’s game over.
If you encrypt your laptop with LUKS or VeraCrypt then physical access can not give the attacker access to the data. That’s the whole point of data-at-rest encryption, to protect your data if your device is stolen or lost.
Yes, you could do that, but doesn’t this software enc/dec approach add a layer of performance impact, appart of whatever impact bitlocker is already doing?
Sure it’s common threat assessment. The most common risk associated with a laptop (etc.) being stolen, lost, of inappropriately discarded is covered by bitlocked. For the last usecase bitlocker also covers (most) usecases where technically experienced people with enough time and money try to access the information on the harddrive. So if your working with very secret information where those kind of threat actors are after your data, you might want to consider extra measures link software encrypting a bitlocker disk, etc. You would take the added inconvenience in useability and power consumption for granted, Note however that the chance of locking yourself out increases with every layer of encryption ;)
tl;dr relying on “something you have” instead of “something you know” is a newbie mistake unless your opponent is only a 3rd-world opportunist who combs through e-waste to find personal data for scam operations.
From the article itself:
“To protect against this attack you could either use a fTPM or if the discrete TPM has to be used, then it is necessary to set a PIN or passphrase on BitLocker (as recommmended by Microsoft).”
So basically everybody would be better off dumping that particular form factor and implementing the the microchip three layer design that has a fast drop in chip one that semi customizable by them and then one that’s customizable by you and I think they’ve even fixed the French researchers post x-ray laser hack which got one of their chips to dump the contents but I think they they fix that by implementing some kind of timing issue thing and I think those chipsets are pretty good.
Why is this not implemented like GSM SIM cards, i.e. the TPM chip should verifiy the user PIN before revealing the encryption key? Wouldn’t that be the most obvious way to achieve the second goal?
It is! Unless you choose to disable the PIN-code of bitlocker/tpm which makes it useless.
This is exactly why Microsoft requires a TPM-chip, to do PIN-verification.
The TPM is really just used as storage for the decryption key. It kind of makes sense too, for the intended use case (which is the bad part).
Security is often annoying, and having to type a pin/passphrase/decryption key during every boot is highly annoying. Also, its the bootloader that needs this information very early, iow before the is has actually loaded. So pick your poison. IMO personally I think the TPM is just abused here to be able to say ‘but TPM!!11’.
On my Linux laptops that have full disk encryption, no TPM is involved, I have to supply the ‘something you know’ or could even do a USB stick with ‘something you have’ or even both of course. A TPM could be used still, Luks supports it but IMO beats the purpose for me. Even if we’d use the TPM to decrypt the actual key from, for example something simple as a pin.
I don’t understand why a Tire Pressure Monitor chip is used to control volume.
volume and pressure are related by the ideal gas law “pV=nRT”, which roughly says that pressure times volume is proportional to mass times temperature. so they’re closely related, even if they’re not the same thing.
Thanks! I’d forgotten that from my days in Chem 101!
(Maybe I was researching Beer’s Law too much!)
B^)
Just one point of clarification, once you’ve got the disk decrypted there are tools that can read and write the registry hive files, allowing you to enable an existing local account, inject it into the admins group, and remove the password from it. We do this all the time at work with dislocker and the archived BitLocker recovery keys when we need data off of a device that was removed from the network for various reasons.
I’ve worked with Microsoft before and discussed this exact topic with them. Their point of view at the time was that physical probing of the PCB was outside of the scope for firmware/data security.
The reason being that once you are at this level of hardware access, why not just unsolder the TPM chip?
Bear in mind the SPI port being accessible would be highly dependant on the motherboard, as the traces could easily be routed in internal tracks of the PCB.