[HN Gopher] Bypassing Bitlocker using a cheap logic analyzer on ...
___________________________________________________________________
Bypassing Bitlocker using a cheap logic analyzer on a Lenovo laptop
Author : brohee
Score : 287 points
Date : 2023-08-24 15:02 UTC (7 hours ago)
(HTM) web link (www.errno.fr)
(TXT) w3m dump (www.errno.fr)
| kosasbest wrote:
| 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.
| Already__Taken wrote:
| 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.
| NoZebra120vClip wrote:
| 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.
| layer8 wrote:
| If you want Bitlocker to protect against someone stealing your
| laptop, you should be using a password anyway (and disable non-
| hibernation sleep modes).
| mananaysiempre wrote:
| 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.
| layer8 wrote:
| 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.
| mananaysiempre wrote:
| 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.
| layer8 wrote:
| 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.
| gquere wrote:
| Only DMA comes to mind but it requires a non-hardened
| configuration which isn't that common on recent laptops +
| OS.
| mananaysiempre wrote:
| 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.
| plonk wrote:
| 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.
| vladvasiliu wrote:
| 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".
| pgraf wrote:
| Same technique described in 2019:
| https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-in...
| FirmwareBurner wrote:
| _> 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.
| c4mpute wrote:
| 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.
| Guvante wrote:
| 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.
| c4mpute wrote:
| 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
| mjg59 wrote:
| 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.
| FirmwareBurner wrote:
| _> 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.
| auguzanellato wrote:
| > but fTPM could always be patched
|
| dTPMs can also be patched, the TPM in my Dell laptop is
| discovered by fwupd as being updatable.
| etna_ramequin wrote:
| > 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.
| mjg59 wrote:
| Pluton rather than Proton, but yes.
| etna_ramequin wrote:
| Yes, that's right, thanks!
| withinboredom wrote:
| I was always under the impression that once an attacker got
| physical access: all bets were off. Literally anything is
| possible at that point.
| [deleted]
| ongy wrote:
| 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
| logical_person wrote:
| 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.
| ongy wrote:
| 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...
| brohee wrote:
| 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?
| ongy wrote:
| 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.
| brohee wrote:
| 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...
| ongy wrote:
| 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.
| etna_ramequin wrote:
| > 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?
| zimmerfrei wrote:
| >> 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...
| gquere wrote:
| 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.
| gbil wrote:
| 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
| candiddevmike wrote:
| Wouldn't the keys for LUKS/Bitlocker be stored in memory
| regardless of TPM/no TPM?
| als0 wrote:
| > 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...
| logical_person wrote:
| 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.
| jfim wrote:
| I wonder if that oversight is intentional and what would be the
| reason for it.
| Dalewyn wrote:
| 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.
| comex wrote:
| 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.
| Vogtinator wrote:
| 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.
| mjg59 wrote:
| "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.
| kobalsky wrote:
| > 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.
| 0xbadcafebee wrote:
| 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
| voxic11 wrote:
| You are correct, see section 6.3 https://github.com/nccgroup/
| TPMGenie/blob/master/docs/NCC_Gr...
| ggambetta wrote:
| 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
| mike_hock wrote:
| 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.
| Karliss wrote:
| 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.
| gquere wrote:
| Indeed I used DSView which is a fork of pulseview.
| ack_complete wrote:
| 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.
| matja wrote:
| 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.
| aeonik wrote:
| 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.
| dekhn wrote:
| 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/
| 4gotunameagain wrote:
| 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..
| Octabrain wrote:
| 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?
| itscrush wrote:
| 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
| tedunangst wrote:
| 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.
| Rygian wrote:
| My guess: if you didn't set a password for the disk encryption,
| you have no protection for that scenario.
| vel0city wrote:
| 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.
| jrm4 wrote:
| 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.
| FirmwareBurner wrote:
| _> 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.
| vladvasiliu wrote:
| > 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.
| FirmwareBurner wrote:
| 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.
| GordonS wrote:
| 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?!
| jeroenhd wrote:
| 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.
| hedora wrote:
| 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.
| jeroenhd wrote:
| 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.
| als0 wrote:
| > 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/acbb504ea
| f1be51572...
| jeroenhd wrote:
| 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.
| snvzz wrote:
| >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.
| shuntress wrote:
| > 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.
| jrm4 wrote:
| so the answer is yes, yet downvoted to zero. weird.
| brohee wrote:
| 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.
| als0 wrote:
| fTPMs (firmware TPMs) are also very bad advice, because they
| have been remotely exploited using only software techniques.
| gquere wrote:
| 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.
| buran77 wrote:
| > 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.
| yomlica8 wrote:
| 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.
| veave wrote:
| Wasn't it tremendously naive of Microsoft to trust that
| SSDs did encryption correctly? So naive that it borders
| incompetence and/or malice?
| blibble wrote:
| void encryptSector(struct context *c, long sector_no,
| unsigned char *data, size_t data_len) { // TODO
| }
| yomlica8 wrote:
| 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!
| dylan604 wrote:
| It's only securely erased after I've put about six 5/8"
| holes with my drill in it
| vxNsr wrote:
| 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.
| heavenlyblue wrote:
| 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
| blibble wrote:
| I can imagine the wear levelling function on some SSDs
| looks pretty similar to the encryptSector function
| ExoticPearTree wrote:
| > 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.
| ongy wrote:
| 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
| monocasa wrote:
| Because security isn't certifications.
| salad-tycoon wrote:
| Deleted
| jsmith99 wrote:
| 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...
| kotaKat wrote:
| Also amusingly, as far as I'm aware, Windows Defender now by
| default blocks any accessibility-based escalation attacks --
| Behavior:Win32/AccessibilityEscalation.
| ballenf wrote:
| 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.
| monocasa wrote:
| 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.
| psychphysic wrote:
| 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.
| gquere wrote:
| Can't do this attack if BitLocker is protected by
| PIN/passphrase, which is rarely the case.
| brohee wrote:
| 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).
| withinboredom wrote:
| Dude. Bypassing the login screen is as simple as pressing
| shift five times. That's like some kindergarten stuff.
| sznio wrote:
| 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.
| gquere wrote:
| 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.
| cafeinux wrote:
| 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?
| withinboredom wrote:
| If you can trick the computer into decrypting the disk,
| why does it matter which disk you actually boot from?
| brohee wrote:
| BitLocker is mostly worthless if you don't also password
| UEFI, disable booting off any other disk than the main
| one, and enable SecureBoot.
| plonk wrote:
| If you booted anything but the OS that set up BitLocker,
| wouldn't the TPM refuse to release the key?
| als0 wrote:
| That is correct.
| kristjank wrote:
| 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.
| tamimio wrote:
| >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.
| controversial97 wrote:
| 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.
| o1y32 wrote:
| 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.
| ComputerGuru wrote:
| 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.
| ixwt wrote:
| 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.
| brunoqc wrote:
| > 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).
| redox99 wrote:
| 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.
| sublinear wrote:
| 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.
| hutzlibu wrote:
| 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.
| Ian678 wrote:
| Could also use a light sensor or check if a circuit that runs
| on the inside of the case is broken.
| michaelmior wrote:
| Still seems not to difficult to bypass (if you know it's
| there).
| morpheuskafka wrote:
| 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.
| layer8 wrote:
| It's good practice to have a copy of the recovery key
| somewhere.
| controversial97 wrote:
| 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.
| Crontab wrote:
| 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.
| bootsmann wrote:
| 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.
| vladvasiliu wrote:
| 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.
| withinboredom wrote:
| If you do a volume order, I think you can ask for it to
| be turned on by default.
| controversial97 wrote:
| 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.
| gambiting wrote:
| 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.
| ixwt wrote:
| This makes absolutely 0 sense. Bitlocker cannot be setup
| on Windows 10 Home edition.
| wbkang wrote:
| It's called "device encryption" which seems to do the
| same thing and they allow it for Windows 10 home. It's
| confusing.
| temac wrote:
| 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.
| gambiting wrote:
| Ah. Which is probably what happened to me as I've signed
| into my MS account.
| gambiting wrote:
| 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.
| ysleepy wrote:
| 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.
| gnopgnip wrote:
| 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
| 0xDEF wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-24 23:01 UTC)