Bypassing Bitlocker using a cheap logic analyzer on a Lenovo laptop | Hacker News Reader

Bypassing Bitlocker using a cheap logic analyzer on a Lenovo laptop

errno.fr

352 pointsbrohee148 comments

> using a fTPM would solve the problem.

All TPMs support encrypted sessions to prevent these kind of MITM attacks. You use TPM2_StartAuthSession and specify encryption with each session command. But Bitlocker doesn't use one, which is epic fail. Microsoft need to fix it.

Edit: For comparison, systemd uses encrypted sessions when using LUKS disk encryption with the TPM https://github.com/systemd/systemd/commit/acbb504eaf1be51572...

This isn’t even a proper MitM attack, just passive sniffing.

But, I ask as someone unfamiliar with TPM, how do authenticated sessions work? How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet. Or even if the OS verifies the TPM’s identity somehow, even if this is done in a way that it can’t be worked around just by modifying some files on disk, what stops the attacker from running the same routine in an emulator?

I don’t see how you get real security from this approach unless there’s some integration with Intel ME or SGX or other CPU-side ‘secure’ environments, but then you wouldn’t need the TPM to start with.

Agreed. I don't see a way this can be done without one side trusting the other implicitly. If the sniffer/MitM gets either the measured data (to replay) or the unsealed key (to use directly) it's game over.

> I don’t see how you get real security from this approach unless there’s some integration with Intel ME or SGX or other CPU-side ‘secure’ environments, but then you wouldn’t need the TPM to start with.

fTPMs are basically implemented within (or closely working together with) Intel ME reps. AMD PSP.

"Authentication" here is something of a misnomer - it's setting up an encrypted session without any proof of identity. In that form it's sufficient to block passive sniffing and require an active MITM instead. The TPM's side of things can be tied back to the EK and hence can be validated against the vendor-issued EK certificate, so in theory this can be implemented in a way that avoids that risk, but that still involves a mechanism for bootstrapping the trust in the EK signing authorities and if that's not in the signed component of the boot chain then you're going to have problems.

I'm not sure what you're considering in the emulator case. Either the PCR values are going to be different or the TPM is going to be different, and in both cases that means you're not going to receive the decrypted secret.

> even if this is done in a way that it can’t be worked around just by modifying some files on disk, what stops the attacker from running the same routine in an emulator?

this is a question for an TPM expert. I'm a novice at this so take my reasoning with a grain of salt.

A software only emulation shouldn't fool the TPM since part of the secure boot process ties the hash of some PCR banks to the firmware, bootloader and kernel booted, so if you were to modify them in a way that allows you see the key, then it TPM wouldn't be able to produce the correct decryption key. I'm not sure if windows uses those PCR banks to secure bitlocker, but on other OSes you can.

I'm guessing that a hardware mitm would be possible with a discrete tpm, unless you use an aditional factor to boot as it usually recommended to prevent evil maid or cold boot attacks.

You are correct, see section 6.3 https://github.com/nccgroup/TPMGenie/blob/master/docs/NCC_Gr...

MitM covers both passive and active. The traditional model for MitM was Telnet sessions, where a passive MitM would allow you to capture secrets and then initiate new sessions. With active mitm you can take over a session (or more!) but passive enables plenty of successful attacks, which is why you should use encryption, which MS didn't. lolz

> How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet.

Your intuition is sound. The only way for the OS to prove it's identity is to have a secret only it knows, and prove to the TPM it knows it. TPM's do support that, but in this case the OS has nowhere that is robustly secure to store the secret.

Windows could store a obfuscate secret on disk, but it doesn't bother. To be fair, there probably isn't much point - if someone is willing to go to this much work, then it's very likely they would be willing to invest the additional effort to break the obfuscation.

This still gives you a level of protection you wouldn't have without the TPM. The disk can only be read when the TPM is present - so someone stealing disk, or walking away with a bit for bit copy of it won't get them very far. One place that's useful in cloud environments. If the cloud provided replaces a fail disk and doesn't wipe the old one - it's still useless unless someone unless they know what motherboard it was paid with.

Still, I think that's an anti-feature for a laptop. It means if the motherboard fails you've lost the data on the disk even though it's perfectly fine, and indeed that is the case with bitlocker. If you protect the disk with a password you entered on boot up it is immune to this sort of attack, and you can move it between machines. Win, win. That's what I do. But, I don't use Windows to do it.

> Or even if the OS verifies the TPM’s identity somehow

That can be solved using attestation. Attestation is just a secret TPM knows, signed by the manufacturer. Windows could choose to deal only with TPM's from manufacturers it trusts, and presumably a emulated one wouldn't be one of them. Secure boot should prevent you from modifying Windows to accept any manufacturer, so it's secure.

But I'd lay long odds Windows doesn't do this sort of verification.

I wonder if that oversight is intentional and what would be the reason for it.

I would hazard a guess that it's probably because BitLocker predates TPM by at least two years, and Microsoft wants to avoid bricking old BitLocker secured data because most users just aren't going to be on top of this stuff.

authenticated sessions are practically useless on anything but a fully integrated device, because there is no guarantee of the SRK's identity - MITM is still possible.

Another write up from 2021

https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole...

One aspect of this is that some laptop manufacturers provide a setting to erase the TPM if the laptop is opened. You opened that laptop to see if you can add more RAM? Better hope you can access the bitlocker key or have a good backup.

It’s good practice to have a copy of the recovery key somewhere.

Lots of people and small companies just buy a windows laptop and are unaware that the harddrive/ssd is encrypted with bitlocker.

People who avoid making a Microsoft account to log on to a windows computer, or who don't have access to the email address they used can find themselves in difficulty later when windows won't boot or it wants the bitlocker key for some reason. You can't get their files off the drive by connecting it to another machine because the bitlocker key is not available.

Yes, people should have backups and copies of their keys but they very commonly don't.

I was under the impression that BitLocker does not default to being on, even with a Microsoft account. That's kind of dangerous if they have changed that without at least a warning.

If you do a volume order, I think you can ask for it to be turned on by default.

I recently got a new MSI laptop, came with Windows 11 - I immediately wiped the drive and installed Windows 10(Home edition), few days later installed a new BIOS update and the laptop asked me for a bitlocker key......but I never encrypted the drive??? What's even weirder is that I logged into the Microsoft recovery thing and it had the recovery key for it????? So it does seem to be the default behaviour now.

This makes absolutely 0 sense. Bitlocker cannot be setup on Windows 10 Home edition.

Well I upgraded to Pro about two days later, so maybe the upgrade did it? But either way, there was absolutely zero indication that the drive is getting encrypted or that it's going to save my recovery key to my Microsoft account.

It's called "device encryption" which seems to do the same thing and they allow it for Windows 10 home. It's confusing.

It's bitlocker but only activates if you log into a MS account in which case it:

* silently activates

* silently sends the key to MS.

And this is the only way to have it on home.

Ah. Which is probably what happened to me as I've signed into my MS account.

Windows marks the device as bitlocker enables somewhere in the EFI partition or GPT disklabels. I needed to wipe the whole disk to have windows cease with bitlocker bootscreens.

I can say from personal experience that for at least five years it has been common for small companies to buy a laptop direct from Dell and for it to have a bitlocker encrypted drive without anyone choosing that.

IME with win 11 pro, it won't encrypt the drive if you (jump through hoops to) create a local account. But as soon as you link it to MS, it will encrypt it.

It is default on in win 11, which is probably a huge privacy improvement for a majority of users. The recovery is sent to microsoft with your microsoft account, but against 99% of attacks (petty criminals stealing your laptop) this suffices.

If you fall into the category of users that distrust microsoft with their key, you can take active action and configure bitlocker yourself.

Most small companies will login with a microsoft account and have the key saved by default to https://myaccount.microsoft.com/

If you don't sign in with a microsoft account bitlocker isn't enabled by default. When you setup bitlocker it "forces" you to make a backup of the key

Well no kidding

> One aspect of this is that some laptop manufacturers provide a setting to erase the TPM is the laptop is opened.

Do you mean like if you remove the screws and get inside a laptop?

Could they gain access by cutting the plastic instead (maybe Matrix parasite extraction style).

Could also use a light sensor or check if a circuit that runs on the inside of the case is broken.

Still seems not to difficult to bypass (if you know it's there).

Chassis intrusion is almost always just a small switch pushing against the side panel of the case. And yes there's a million ways you could bypass that.

Which sounds potentially unreliable on a laptop. Seems like a hard knock or even just normal material fatigue might be enough to release the switch.

One laptop of mine has such a sensor, but not for bitlocker.

After I opened it, it would just refuse to turn on, probably a safeguard when repairing and not wanting it to run anything.

But I did not know and thought I broke it, but after closing it again and tightening one screw in the middle, it worked and so I found that sensor. It is a very simple, but reliable push button and before it breaks, the screen will be broken long before that.

I’ve never seen a consumer device with chassis intrusion enabled by default. Were these maybe volume orders for a business account? Those can come with whatever configuration IT wants.

From all the computers that I've seen with intrusion detection on by default, they only give you a warning from what I've seen.

That's probably just relying on a push-button tamper switch which could be easily bypassed by cutting the back plastic instead. I doubt they are doing anything very fancy like running wires over the whole case.

Off topic -- The joke is that you can hardly find a laptop with upgradable RAM these days. Not even on some ThinkPad lines. Gaming laptops often do.

https://frame.work/ is there for you.

There's nothing new in this. The default configuration doesn't require a PIN but the Microsoft documentation explains the various attacks and recommends setting a Bitlocker PIN which completely prevents this. The PIN can be quite weak because the TPM prevents brute forcing. See eg https://learn.microsoft.com/en-us/windows/security/operating...

Also amusingly, as far as I'm aware, Windows Defender now by default blocks any accessibility-based escalation attacks -- Behavior:Win32/AccessibilityEscalation.

I would expect the TPM to wipe key material after X failed attempts, is that not the case?

I would like to take the chance to ask about something that I never understood from Bitlocker and this kind of encryption, in general, where the decryption key is provided automatically by the system. Let's say, if my laptop (I mean, the whole device) is stolen, which security does Bitlocker provide? From an attacker POV, the system will boot and it will ask for my user account password. So, to my understanding, it will protect my data if my hard disk is extracted from the laptop and attempted to run it from a different system.

Worth mentioning that this probably silly misconception is what makes me to always set a password for Bitlocker that I have to type manually which is what I've always done on LUKS.

Am I totally wrong?

My guess: if you didn't set a password for the disk encryption, you have no protection for that scenario.

Not entirely wrong, but may be missing how the key is now exportable adding risk to the scenario.

As you mention decryption key is provided automatically to the system. This means it's in RAM ready for export and re-use by bad actor against your encrypted disk. Cold boot attacks[1] are one of the attack vectors you'd want to read more on to figure out if this is valid for your threat model.

[1] https://en.wikipedia.org/wiki/Cold_boot_attack

Windows is not supposed to let anyone access the files until they enter the correct account password. So the disk will decrypt in this computer, but then Windows prevents access.

It requires the attacker to bypass the login, extract the key from memory from the system, or potentially with a physical TPM this style of attack. This is probably a lot more sophisticated of an attack than a random thief trying to make a quick buck stealing an expensive computer. Chances are they'll just end up wiping the drive and try to sell it rather than actually try a cold boot attack, but it all depends on your threat profile.

Personally I mostly use FDE on personal machines so I don't have to care much about physical destruction when I need to get rid of storage devices. If a hard drive fails I don't need to actually tear it apart to make sure my data is gone. My device is usually in sleep mode when I'm out and about so if they were going to do a cold boot attack they could do it anyways.

Since the key traverses the shared bus, does that mean that every component in the system could intercept the key just as easily as this logic analyzer does? Sounds like a supply chain security nightmare.

It's shared between a couple of components, but not nearly all of them. These days pretty much just the boot flash and the TPM (and the CPU itself as the bus master) are sitting on that SPI bus.

The point of this kind of encryption is that a removed hardrive can be sold or repurposed without data risk.

Anyone can boot the laptop and get to the decrypted hard drive, what does it matter if they sniff the key first? They always had access to the end result of they can boot the laptop.

Well you will boot the laptop but still have to get past the login screen. Intercepting the key permits to read/write whatever you want on the disk, and thus backdoor the OS (as he does).

Dude. Bypassing the login screen is as simple as pressing shift five times. That’s like some kindergarten stuff.

If I remember correctly, you needed to replace the accessibility executable with cmd.exe for that to work.

Can't do that if the machine is encrypted. And if it's unencrypted there are better ways to reset the passwords.

Well that's what I described. The drive was encrypted but there was no PIN so I just snooped the key, decrypted the drive and mounted it on another machine where I replaced sethc with cmd.

Doesn't this method imply booting from an external disk, thus not decrypting the HDD, thus not being able to modify what needs to be modified in order to bypass the login screen?

If you can trick the computer into decrypting the disk, why does it matter which disk you actually boot from?

The point made earlier was that if you boot Windows, it automatically decrypts the disk, but if you boot from another disk, it doesn't. I don't know much in this, except that I think I know that the TPM has an "owner" and that only that owner can read and modify the content of the TPM.

If you could just plug your USB drive, boot from it and automatically decrypt the Windows partition to edit CMD.exe, I just see this whole Bitlocker and TPM thing as completely moot.

I really hate to be the one to point this out, but its clear you didn't read the article since this is exactly what they did: boot windows, steal the key from the TPM, boot into different OS entirely, inject the key to decrypt the disk, replace sethc, reboot into windows and push shift five times ... and there you go.

I read the article (and skimmed some parts, as I'm not interested in the technical details of how the signals were decoded).

As I understood the conversation thread we're in, we were talking in the context of someone simply booting up the laptop, not someone opening it and plugging wires to tap the TPM bus.

Of course, once you've tapped the TPM with the technique described in the article you can do whatever you want with the disk, but in this case I don't see why you would bother bypassing the login, just mount the partition and get the data you need.

Edit: specifically in this case, my comment was a reaction to this but from psychphysic : > what does it matter if they sniff the key first? They always had access to the end result of they can boot the laptop => if you didn't sniff the key first, you can't decrypt the disk offline, and can't have access to CMD on the login screen. That's why it matters.

BitLocker is mostly worthless if you don't also password UEFI, disable booting off any other disk than the main one, and enable SecureBoot.

If you booted anything but the OS that set up BitLocker, wouldn't the TPM refuse to release the key?

That is correct.

read the article.

Can't do this attack if BitLocker is protected by PIN/passphrase, which is rarely the case.

If you want Bitlocker to protect against someone stealing your laptop, you should be using a password anyway (and disable non-hibernation sleep modes).

The first point was not entirely obvious before this—your laptop being stolen is essentially the weakest[1] class of threats against which full-disk encryption makes sense, and Windows makes a big deal against not requiring anything but your usual account password for that. Is the “trusted” hardware in the TPM even doing anything now? Is boot measurement also spoofable?

(Also, this is just offensive levels of dumb—why is the key material just strolling along the bus here in plain view? There isn’t even a key exchange protocol or anything.)

[1] People are also talking about secure erase here, which, okay, is weaker, but FDE + a EEPROM in a socket that you can pull out and physically destroy does that part just as effectively.

The windows password is not required for Bitlocker. It doesn't work like macos' filevault.

You can configure a dedicated password for bitlocker, or a pin (can be alphanumeric) in addition to the tpm, but there's no link between that and your windows account once the os is booted.

I think MS' point about the standard bitlocker setup is that people can't just steal the drive and mount it in their own PC, they need your specific PC. And also, that windows is secure enough that if you have the correct PC with the drive and the OS boots, you can't open the windows session (which by default requires a password). So in this context, bitlocker adds some security while being "transparent".

Windows supports multiple accounts, hence an account password doesn’t apply to Bitlocker, which encrypts the main Windows partition as a whole. You need a separate Bitlocker password that the boot loader requests from the user before Windows proper is loaded, and before any accounts come into play.

I am aware (and my point of comparison is LUKS, where the separate password is extremely in-your-face). But my impression from Windows was that, in the default FDE configuration, the (measured?) OS boots up, pulls the FDE key from the TPM with no user input, then presents the user with a login screen. So in ideal world the data is exactly as secure against a thief as the account password or passwords, thus my mention of them.

This article, however, says that this setup does not protect the data at all against a thief willing to pay $100 lifetime (not per machine), which seems an absurdly low bar. (And I’d wager you can go even lower by wiring up a cheap devboard—basically everything has a SPI peripheral these days.) I mean, liquid nitrogen is not exactly expensive either, but it does require some fuss, whereas the attack in TFA could be made essentially as easy as opening the case.

I’d say that as soon as Windows fully boots up, you have a much larger attack surface anyway, even if you can’t log in due to the account password. Though I can’t point at anything specific off the top of my head.

Is there anything you could access from the keyboard or touchpad? Seems easy enough to only accept the inputs that the login screen needs and nothing else.

Only DMA comes to mind but it requires a non-hardened configuration which isn't that common on recent laptops + OS.

Very rarely are drivers, including USB drivers, written to assume a hostile device (see e.g. the PS3). Frankly, they rarely seem to be written by people who care about software at all. (I still can’t get over the very first Zenbook, which suffered spontaneous deaths under Linux because the ACPI bytecode in the firmware tried to initialize a nonexistent IDE controller. And people say it’s Linux that has a hardware support problem.) So this is a somewhat valid concern.

But I still can’t get over the idea where the default configuration of BitLocker is completely useless for basically anything except working around storage devices that will lie to you and not erase things you told them to. I just refuse to accept that’s in any way sane.

What software was used to turn the raw signal into zeros and ones? I've had a similar project since forever (reading digital data off 80s-era cassette tapes), I have pretty good .wav versions of the tapes, but I haven't found the right tool (or library) to turn it into zeros and ones :( Of course the fun part will begin once I can start decoding the zeros and ones...

EDIT: I know how the bits are encoded, it's Frequency Shift Keying[0]. What I don't know is what to use to decode this into a stream of bits I can process further (with custom code).

[0] https://en.wikipedia.org/wiki/Frequency-shift_keying

Pulseview https://github.com/sigrokproject/pulseview and probably other parts of Sigrok project https://github.com/sigrokproject .

Or since author mentioned DSlogic possibly the corresponding forks of those programs from the company making the logic analyzer.

Indeed I used DSView which is a fork of pulseview.

This is a a major field called Digital Signal Processing, and it's fundamentally what a modem or the ADC in your sound card is doing.

I'm not aware of any single algorithm or software that can turn any raw signal to bytes. You need to figure out which modulating scheme the signal uses, and either find a decoder for it, or write your own.

Generally it's going to involve filtering, and other mathematical algorithms. But they tend to be pretty short and simple programs for basic decoding.

It's a pretty neat skill to learn because you can use the same techniques for all sorts of things. For example, once I learned a bit of DSP it unlocked a lot of abilities with Radio communication, Music and Sound design, image, and video processing.

GNU radio has all the bits to do signal processing from raw analog data to symbols to bytes.

For example, I can use my SDR to record various signals in my neighborhood, make a guess that it's manchester encoded, then pass that signal to a symbol demodulaor, pass the symbols through a manchester decoder, then on to a protocol decoder (IIRC my tires have batteries and transmitters to send their pressure level to my car). GNU radio has bits for all these steps, but yeah, you kind of need to know the modulation schema and the codec scheme to make sense of it.

Here's a nice example: https://bkerler.github.io/OregonDecoder/

This is not DSP, this is just digital communication. DSP is digital manipulation of a sampled signal, whether that is infinite/finite impulse response filters (IIR, FIR), discrete fourier transform, discrete wavelet transform etc..

The article makes it sound easy. When the clock goes from low to high, the current level of the data line is the bit value, and you look for a one and seven zeros to find the start.

For decoding old FSK tapes, look into sliding Goertzel filters. They're easy to implement filters that extract the amplitude of a frequency bin within a sliding window, and are often referenced in literature about DTMF decoding. Compare the outputs of a pair of these to produce a digital output. You can also use a sparse sliding DFT, but interpolating between frequency bins is more of a hassle, whereas the Goertzel filter handles that for you.

The loading routines from that era just count the number of DC zero-crossings and convert X crossings into a 0 and Y crossings into a 1, they don't care about frequency or amplitude (the raw signal is usually fed into a Schmitt trigger to implement hysteresis for a stable edge). That way, the polarity of the tape signal and the variation of the motor is compensated for.

>The use of a discrete (physical) TPM actually decreases the security

My laptop from 2015 didn’t have physical TPM and it prompted me when I tried to enable it: “Allow BitLocker without a compatible TPM (requires a password or a startup key on a USB flash drive)” and I thought it’s less secure.. the irony! Good thing I don’t use bitlocker anyway.

I find the fact that the old elementary school trick of renaming Command prompt to the accessibility handler still works as well as it used to in the Windows Vista days incredibly funny. You would imagine Windows would authenticate something that runs with admin perms with no login required. Windows seems to be 75% security theather and about 25% other types of theather.

Same technique described in 2021: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-in...

This is a non-issue for me, as I use LUKS2 (the recent version of LUKS which is much better). If I need to use Windows, for whatever reason, I jail Windows in a VM typically to use certain software that has no Linux equivalent.

I don't trust Bitlocker. Read somewhere Bruce Schneier uses Bitlocker for his daily computing, but I still don't trust it. After all, this is Microsoft we're talking about, who are in cahoots with the NSA, and Redmond has NSA on speed-dial. Avoid Bitlocker if you really want to protect sensitive data.

(If you are going to use LUKS, use LUKS2 with a seven word passphrase). Currently this is the state-of-the-art for encrypting disks.

luks2 and Tang+Clevis is a pretty tidy solution. I have a host boot that I connect into the VPN and unlock the inner container volumes of code. I would like if it was built upon less shell scripts.

Reality check. If US-based Big Tech is undoubtedly pwned by USGov interests, why should you think that non-US-based tech is any different? Do you really think that MI5/6 leaves Canonical alone? Red Hat is IBM and US-based too. Are the Finnish/Scandinavian authorities just patting Linus on the head and saying "do whatever you want bro!"

I think that it takes significant leaps of logic, yeah even with pervasive F/OSS, that non-US intelligence is somehow weaker or less interested than US-based ones. In fact, your typical Linux supply chain and SBOM is far, far more complex than anything Windows can serve up. There are so many juicy opportunities in there.

Fun stuff. I only ever use Linux under Hyper-V precisely because I could not find a reliable way to set up disk encryption that does not ask for password while giving the same protection as Bitlocker (e.g. you can keep your system automatically updated, and as long as your TPM and OS login screen are not vulnerable nobody can steal the machine and decrypt the drives).

Even Fedora (which I think is in the better shape than most) does not set that up by default and the only tutorials I found require you to manually reconfigure TPM on every kernel update.

could anyone tell me that what if (actually is) i dont have tpm on my pc? would it be risky for these attacks? i configured bitlocker without tpm.

Now that the TPM has been proven to be security theater Microsoft should drop the TPM requirement for Windows 11 and allow older machines to upgrade.

My previous job let me keep their 2016 laptop with an Intel i7 CPU, 32 GB RAM, and 512 GB SSD. Wonderful little bedtime laptop that is stuck on Windows 10.

Bitlocker is the Windows one, that's essentially known to be compromised, right?

Not saying that it's useless, might be fine for certain work environments, but I wouldn't rely on it for anything truly personal.

>Bitlocker is the Windows one, that's essentially known to be compromised, right?

It's not compromised if you set a PIN/passkey, aka use it correctly.

Technically, the lock on your house door is also compromised since any pro locksmith can open it within a few minutes, but that doesn't mean it's now useless to keep locking your door since most casual thieves aren't pro locksmiths and laptop thieves aren't gonna be black-hat hackers/security researchers.

Such security solutions are there to discourage low hanging fruits of amateur bad actors(99,99% of them) and make them give up and use their time somewhere else.

> It's not compromised if you set a PIN/passkey, aka use it correctly.

The issue is that you have to go out of your way to set it up this way. Last I checked, you couldn't just add a PIN. You had to enable it through GPO.

IIRC you can set a PIN without fiddling with security settings or GPOs, but if you want to use a password instead of a PIN, then you've got to jump through some hoops to enable that. It always struck me as a very, very strange design choice - why make it so difficult?!

Just checked on my up-to-date win 11 22h2 pro. I can't set a pin by default.

> Computer Config / Admin templates / Win components / Bitlocker / Os Drive / Require additional authentication at startup

> If you disable or do not configure this policy setting, users can configure only basic options on computers with a TPM.

This enables tpm + pin and / or password unlock. But only numeric pins. If you want alphanumeric, or "enhanced", pins, you have to enable a separate GPO in the same place: allow enhanced pins for startup.

> If you disable or do not configure this policy setting, enhanced PINs will not be used.

It's on for corporate users, but I assume because it would be a terrible UX for consumers, having users always enter a PIN code at boot/re-boot and would make them throw their PCs out the window.

It's even worse if you use a Bluetooth keyboard as that doesn't work at BIOS level so you'd have to plug in an USB keyboard just to enter your PIN on boot. Would be maddening and people would just turn it off.

I'm not aware of any proven compromise of Bitlocker. There are some bugs (Bitlocker disabling itself during certain updates and not re-enabling it after a BSOD during the update process) but I haven't heard of any way for an attacker who doesn't have full code execution already to bypass encryption. If you set a PIN you should be safe, otherwise the attacker can try to use various exploits or other methods to access the drives.

For fTPM based encryption, the entire system should be safer because the keys don't traverse an accessible bus like this.

The vulnerability also applies to other encryption systems using the TPM, like LUKS disk encryption.

It sends escrow keys to your employer in enterprise environments.

I’d be a bit surprised if the azure compromise a few weeks ago didn’t also give the attackers access to the escrow keys for customer vms, etc.

That's not a bypass, though, that's part of the design. If you're storing critical business info on company hardware that your boss can't access when you leave/get hurt, encryption becomes a business risk.

I don't know if key escrow is also fucked as well after the recent breach, but so far I haven't heard anything about it.

> The vulnerability also applies to other encryption systems using the TPM, like LUKS disk encryption.

No, this is a Bitlocker problem. Systemd LUKS disk encryption uses encryption on the bus by enabling TPM encrypted sessions: https://github.com/systemd/systemd/commit/acbb504eaf1be51572...

I stand corrected, I'm glad systemd finally implemented encrypted TPM communication. I really don't understand why Microsoft is still allowing their keys to be MITM'd.

I really should switch from Grub to systemd but the lack of boot time configuration (and, slightly less importantly, theming support) still makes me prefer Grub.

>I'm glad systemd finally implemented encrypted TPM communication.

Note that, as far as I am aware, it never implemented unencrypted TPM communication.

That's Microsoft-specific insanity.

Microsoft implementation is vulnerable to eavesdropping as the submitted article shows.

systemd would be vulnerable to MITM, but you don't MITM the SPI bus with some $100 hobbyist tooling.

> might be fine for certain work environments, but I wouldn't rely on it for anything truly personal

Funny, I feel the same way but to an opposite conclusion.

Hardware-locked encryption is basically the last thing I want on my notes/projects/code/pictures/etc.

so the answer is yes, yet downvoted to zero. weird.

So again, I'm right and still downvoted. Anyway, I hadn't done much homework on it, but the thing that let me presume this pretty well was when Truecrypt was likely canaried and they told us to go to Bitlocker.

So, Hacker News, gonna do anything about your pro MS trolls? Would be nice.

>The use of a discrete (physical) TPM actually decreases the security of the system, using a fTPM would solve the problem.

Errr... no. Using no TPM of any kind decreases your security.

The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data.

Unencrypted communications over any channel, SW or HW are bad and dTPM never claimed it would protect you from that, but it's still better than no-TPM, and have your keys in system memory or on the disk where it could be accessed through software vulnerabilities.

Of course fTPM, is the next step up in security, even though that's also not impenetrable to attackers with the right side channel analysis equipment and expertise, but security threat model is anyway a matter of time and budget of your attackers, nothing can ever be 100% invulnerable to everything.

Wouldn't the keys for LUKS/Bitlocker be stored in memory regardless of TPM/no TPM?

This is highly misleading.

fTPM is more secure against _this_ kind of attack, with physical access to the bus wires. However, since fTPM is a Firmware-TPM, it is vulnerable to all kinds of attacks on the system's firmware, even remotely, even via the network, even maybe if the computer is switched off. Remember all those (even unauthenticated, remote) XML-parser exploits in the Intel ME? fTPM is just one more ME module, and of course vulnerable to those exploits.

So overall, I consider fTPM a huge step back, because you might even get access without physical presence. For an fTPM, attack surface is far larger (because all of the ME software), minimum attack complexity may be smaller (because there will one day be a metasploit module for all those software problems, whereas HW hacking is always a certain hurdle), required attacker privileges are less (prolonged unobserved physical presence vs. network). Thus objectively worse in all aspects.

What would be better would be a dTPM that is integrated e.g. into a SoC, such that there are no exposed wires anywhere without decapping the SoC. Some systems such as phones work like that, but this is hard to tell even from the technical specs.

>fTPM is more secure against _this_ kind of attack, with physical access to the bus wires. However, since fTPM is a Firmware-TPM, it is vulnerable to all kinds of attacks on the system's firmware, even remotely

Yes, fTPM is more vulnerable in theory to remote attacks, but fTPM could always be patched, while it's more difficult to de-solder the TPM chip off your motherboard and replace with a non-vulnerable one and there are vulnerable dTPM chips out there.

Both solutions have their own pros and cons you have to weigh in the context of cost, convenience and threat model.

>What would be better would be a dTPM that is integrated e.g. into a SoC

Isn't that what fTPM is? The TPM spec firmware runs on the security microcontroller (Intel PTT and AMD PSP) built in the same SoC as the CPU.

What would be better is having the TPM be removable from the machine, like the YubiKey. Currently, dTPM and fTPM are basically like having your YubiKey always plugged in and glued to your machine. Convenient for authenticating you, but not secure from guys stealing your machine and probing it in a lab.

> but fTPM could always be patched

dTPMs can also be patched, the TPM in my Dell laptop is discovered by fwupd as being updatable.

What threat model assumes it is easier to attack fTPM than the OS that is running?

Once you are online Bitlocker does nothing and you can just attack the OS and bypass all of its protections trivially...

Your threat model here assumes arbitrary code execution as a starting point of an exploit, the security game is up for the PC once that occurs.

Any thread model should take firmware into account. There have been examples of unauthenticated remote code execution against Intel ME[0]. This isn't theoretical, this isn't an assumption, this has happened. Those exploits are independent of the OS running, with certain configurations the system doesn't even need to be switched on, just plugged in. With fTPM as an ME module (not all fTPMs are such) this provides an additional huge attack surface.

[0] https://mjg59.dreamwidth.org/48429.html

That vulnerability allowed unauthenticated access to AMT, not arbitrary code execution on the ME. I agree that an ME-based fTPM has a larger attack surface than a dTPM, but we haven't seen many cases where that's had real-world poor outcomes.

> What would be better would be a dTPM that is integrated e.g. into a SoC, such that there are no exposed wires anywhere without decapping the SoC. Some systems such as phones work like that, but this is hard to tell even from the technical specs.

That’s Microsoft’s Proton chip, I believe.

Pluton rather than Proton, but yes.

Yes, that’s right, thanks!

I was always under the impression that once an attacker got physical access: all bets were off. Literally anything is possible at that point.

For large symmetric operations like disk encryption, the MVK is still in memory.

TPMs are slow and have rather restricted memory. They are fine for PCRs and some asymmetric operations.

But here they only unseal a key that is then used in software for speed. It's worse than something protected by a high entropy password. Which is still better than 90% of users would be otherwise

that's still less secure, though. without a TPM you have no guarantee of the underlying state of firmware on the device. this enables a persistent backdoor.

TPM with no PIN is practically bitlocker with no password. A high entropy PIN happens to solve this entire attack.

For the claim of GGP (stealing out of memory) it's worse, as that's still possible, and there's a bus the key travels over.

The PCRs attest system state to the OS, yes. Though the verified boot (PSB/Secure Guard + Secure Boot) chain is supposed to provide the same security there. Provided we assume security features aren't broken by design...

At least TME-MK and its AMD equivalent are supposed to address in memory key stealing/memory bus snooping (even if it's still unclear to me how the key are generated/stored). There is still decapping and probing the CPU itself but given the size of features is that even remotely doable?

Yes and no. Mostly no IMO

The memory encryption features are a solution to very specific problems.

If the CPU is able to access the memory, then any exploit that gains the execution context of the legitimate user can also access the memory. If it doesn't, the normal memory access control should be enough.

I'm iffy on how well they protect against the various side channels. Mostly because I haven't looked far enough into it.

IME it protects against cold boot attacks, a theoretic attack of a logic analyzer on the memory bus, and potentially to some degree unbounded reads. But the latter only with very limited gadgets.

Yeah I was unclear, it's supposed to address the physical attacks part. If no key leaves the CPU unwrapped, it's down to software exploits and decapping the CPU...

Gotcha. Yes

There's also this project https://www.cs1.tf.fau.de/research/system-security-group/tre... which reserves some CPU registers (iirc. A hardware aes accelerator on one core) to prevent key leakage.

Should protect against warm boot attacks since the key is supposed to be reset on CPU reboot.

Author here.

> Errr... no. Using no TPM of any kind decreases your security.

You're right, I wrote too fast, sorry about that. What I meant to say is that it discrete TPM with no PIN is an inferior solution compared to PIN/passphrase or fTPM. Also I should have added that it gives the illusion of security which I hinted at in the foreword. I'm leaving it as is for now, the discussions here are interesting.

Some months ago my company (in the 200k+ employees big) decided to remove pin requirement to “enhance UX while staying secure”. Many objections from quite a few people, mine included pointing to PoC key extractions from TPM etc. and… nothing . Seems that a multi billion company with no-ask money for cybersecurity misses the basics

> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data.

I’m always very confused by this. TPM offers encrypted sessions (setup with the Endorsement Key) for exactly this kind of attack. Why couldn’t the firmware get the keys over an encrypted session? Is it for reliability in case certificate verification goes wrong?

>> The discrete TPM's threat model was never designed to cover you from attackers using oscilloscope to probe your laptop's SPI bus during the boot process for unencrypted data.

This is not really true. All TPMs (or at least since v2.0, but no matter if discrete or not) support encrypted session against passive eavesdroppers. There is also the possibility to protect against MiTM attacks, but that is more complex (since you then need to setup credentials).

See here [0]:

"Encryption sessions are useful for when the path to a TPM is not trused, such as when a TPM is a remote TPM, or when otherwise the path to the TPM is not trusted."

The issue is that the OS / Bootloader does not implement such mechanism.

[0] https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Int...

TLDR if you actually want to act upon that :

Takeaways

The use of a discrete (physical) TPM actually decreases the security of the system, using a fTPM would solve the problem.

If the discrete TPM has to be used, then a PIN or passphrase on BitLocker is necessary.

> If the discrete TPM has to be used, then a PIN or passphrase on BitLocker is necessary.

I always considered that BitLocker without a PIN is 80% convenience and 20% security.

IIRC earlier versions of bitlocker would rely upon SSD firmware implementations for drive encryption. They stopped doing that when it was revealed many of these hardware encryption systems in common drives didn't actually work.

    void encryptSector(struct context *c, long sector_no, unsigned char *data, size_t data_len) {
      // TODO
    }

This is also something to keep in mind when resale of SSDs is discussed and people recommend using the secure erase function of the SSD!

It's only securely erased after I've put about six 5/8" holes with my drill in it

Yup, when I was working desktop support a few years ago my manager told me to just format the drive and send it back to dell at the end of the lease, they’d secure erase it anyway and the data was safe, I never trusted that and used dd to overwrite every bit of the ssd twice with junk data, I’m sure it decreased the longevity of the drive but wasn’t my problem and it felt cool to be the only desktop support guy who knew any Linux.

SSD wear leveling mechanism would create new writes into different physical sectors so it was highly probable you were not in fct overwriting at least a proportion of the data

I can imagine the wear levelling function on some SSDs looks pretty similar to the encryptSector function

Wasn't it tremendously naive of Microsoft to trust that SSDs did encryption correctly? So naive that it borders incompetence and/or malice?

> The use of a discrete (physical) TPM actually decreases the security of the system, using a fTPM would solve the problem.

Since only dTPM can be FIPS certified, I don't see how an uncertifiable piece of hardware can be more secure.

Because security isn't certifications.

FIPS certification doesn't make something more secure. Just more certified.

It's incredibly slow to adapt to new technology.

fTPM has a different attack surface, and protects against this specific attack. It's most likely better than dTPM for hardware based attacks, but there's known attacks as well

fTPMs (firmware TPMs) are also very bad advice, because they have been remotely exploited using only software techniques.

OTOH they can be patched and to exploit them locally you either need software code exec or do a physical side-channel attack which is miles beyond a simple bus snooping.

Hardware TPMs can also be patched.

Deleted

Reply on news.ycombinator.com