back to article Raspberry Pi Pico cracks BitLocker in under a minute

We're very familiar with the many projects in which Raspberry Pi hardware is used, from giving old computers a new lease of life through to running the animated displays so beloved by retailers. But cracking BitLocker? We doubt the company will be bragging too much about that particular application. The technique was …

  1. usbac Silver badge

    It's nearly impossible to protect a device that someone else has physical access to. It has never worked trying to lock-down consumer electronic devices, and it never will.

    1. b0llchit Silver badge
      Boffin

      No, storing the key and the data together on the same device without requiring another separate form of input is the real failure.

      Basically, Microsoft allowed violation of the "something you have and something you know" separation principle. And that is, when you think of it, an obvious backdoor.

      1. Anonymous Coward
        Anonymous Coward

        To be fair to Microsoft (did I just say that), the issue is more a hardware design issue than a software one.

        Its a bit like blaming the bank, because the secure parcel company through the check over the wall

        1. This post has been deleted by its author

        2. Jonathan Richards 1
          Joke

          Tunneling

          Tunnelled the cheque through the wall, shurely

      2. Not Yb Bronze badge

        This is one of the failures of DRM, really. If you can give people the data and they decrypt it to watch, it's tough keeping the pirate-types from decrypting a "purchased" video stream, storing it decrypted, and watching it later.

        The Trusted Computing Platform has always been about making your computer something that someone ELSE can trust.

    2. chivo243 Silver badge
      Windows

      yeah, physical access = game over ;-{

      1. mpi Silver badge

        Really?

        Please, do explain: How does physical access assist an attacker in decrypting a LUKS encrypted drive?

        The problem here isn't "physical access". The problem here is an incredibly bad design decision, that requires the encryption key to be passed to the CPU unencrypted.

        1. vekkq

          when you type your pw after the device has been tampered with.

          1. ibmalone

            There are two slightly different threats that physical access can mean though:

            1. Your laptop (or other device) is stolen and you never see it again, the attacker is attempting to gain access to the data (or use it to access another system, an ID card for example) with only access to the laptop or device itself. Good encryption should present a strong barrier to recovering the data (although you have to assume they have as long as they want to clone encrypted data and try to break the encryption, or inspect the hardware and any vulnerabilities), unregistering the device from any access control protects other things.

            2. The attacker has physical access to the device for a period of time, might be with or without your knowledge (stolen and then found vs the cleaner is the attacker). This might allow the attacks available in situation 1. (depending how long they have it for) as well as tampering with it.

        2. Anonymous Coward
          Anonymous Coward

          USB keylogger.

          Next.

          1. mpi Silver badge

            Oh I thought that was clear from context: The attack, similar to the one described in the article, cannot rely on the user typing in his password.

            Nice try though. Next.

        3. Pete Sdev Bronze badge
          Black Helicopters

          Please, do explain: How does physical access assist an attacker in decrypting a LUKS encrypted drive?

          Anecdotally, the FBI "cracked" PGP of a mafia suspect by installing a key logger on his PC while he was out. They thus had the passphrase to the private key that they'd copied over.

          A similar attack (keylogger) could be used against LUKS with a sufficiently resourced adversary. The rule about physical security doesn't come from nowhere.

          The more paranoid check their keyboard connection and motherboard on a regular basis.

          There's also the rubber hose technique, which to avoid requires physical security of the user rather than the device.

          Icon: obvious choice.

        4. AlbertH
          Facepalm

          It's like every Microsoft attempt at "security" - it's a bolted-on afterthought, and like every Microsoft product "feature", it's poorly thought-out.

    3. wyatt

      Bonk user on head, steal unlocked workstation, job done.

      1. heyrick Silver badge

        Phone user, have their significant other then describe the angry looking guy with a lethal weapon in their hands.

        There are many ways to get a password if it's really necessary, only a few of them are technological...

      2. A. Coatsworth Silver badge
  2. Neil Barnes Silver badge

    Less than a minute?

    It would take longer than that to get the covers off, let alone do any soldering!

    1. tfewster
      Joke

      Re: Less than a minute?

      It's still quicker than typing in the BitLocker recovery key if you've locked your laptop

    2. Doctor Syntax Silver badge

      Re: Less than a minute?

      No solder required, at least not at the time. He made a board with a set of spring-loaded contacts spaced for a set of pads on the back of the motherboard. That plugs into the Pi. He has to take the back of the laptop off and move a cover out of the way but then just needs to press the Pi/contacts assembly against the pads while it boots.

      1. Joe W Silver badge
        Pint

        Re: Less than a minute?

        Take that, Lenovo, for making the laptops easy to repair.

        (I actually really appreciate it!)

        1. MrDamage Silver badge
          Pint

          Re: Less than a minute?

          Not to mention, a lot of models have handy drainage holes under their keyboards in case you spill your ----->

    3. Not Yb Bronze badge

      Re: Less than a minute?

      With the laptop in the video, it took less than 43 seconds to get the covers off and acquire the key. Clearly would only work with similarly put together laptops, but at least one such exists.

  3. TimMaher Silver badge
    FAIL

    Hurt Locker

    A great film.

    BitLocker…not so much.

    1. cookieMonster Silver badge
      Trollface

      Re: Hurt Locker

      Wait till you see “User Locker”

      1. Benegesserict Cumbersomberbatch Silver badge

        Re: Hurt Locker

        Being forced to used Micros~1 is a set of manacles in itself.

      2. BBRush

        Re: Hurt Locker

        I'll wait for the sports version: Gym Locker

  4. Pascal Monett Silver badge
    Thumb Up

    A brilliant testament to analysis

    Maybe a Bitlocked drive could resist anything up to brute force, but knowing the mechanism, finding out that the key was transmitted in the clear between CPU and TPM, that was the straw that broke the camel's back.

    And it just goes to show : if you want something encrypted securely, it has to be 100% from start to finish. No gaps allowed.

    And gaps are Borkzilla's specialty. Somebody devised the whole Bitlocker scheme, failed to encrypt comms between CPU and TPM and thought "this is Good EnoughTM".

    Unfortunately, intelligent people are everywhere, and processing power is cheap nowadays. You've been found out.

    Time to tighten your security, with all the inconveniences that entails.

    1. wolfetone Silver badge

      Re: A brilliant testament to analysis

      "Somebody devised the whole Bitlocker scheme, failed to encrypt comms between CPU and TPM and thought "this is Good EnoughTM"."

      Probably did it and thought "hehe, no one in history has ever been as clever as me".

      Remember kids, no matter how smart you think you are there will always be someone cleverer than you out there.

    2. Anonymous Coward
      Anonymous Coward

      Re: A brilliant testament to analysis

      Pretty sure in this instance, the fail is Lenovo's, however I intend to try this on a few other machines over the weekend.

      1. Jonathan Richards 1

        Re: A brilliant testament to analysis

        What is TPM? Typically, it's a separate chip on the motherboard... [emphasis added]

        Source: What is TPM [microsoft.com]

        1. Anonymous Coward
          Anonymous Coward

          Re: A brilliant testament to analysis

          I'm not at all sure what your point is there, are you trying to say that because MS were one of the originators of TPM then any and every implementation failure is their fault too?

        2. John Brown (no body) Silver badge

          Re: A brilliant testament to analysis

          I don't know if it's still done, but I remember back in the day when TPMs where plug in PCBs on a header and when replacing a failed system board you needed to remember to move the TPM to new system board. Most people weren't using Bitlocker then anyway and I'd imagine a new system board with a new UUID would bork the operation anyway requiring a recovery key. Although now I come to think of it, the current HP laser printers (at least the large business ones) also require a TPM to be transferred over when replacing the formatter board.

    3. Elongated Muskrat Silver badge
      Boffin

      Re: A brilliant testament to analysis

      failed to encrypt comms between CPU and TPM

      OK, clever clogs, explain to me how this can be done, securely...

      Many problems (and supposed solutions) in security involve just moving the problem somewhere else.

      To encrypt communication between the CPU and TPM, presumably, they would each have to have access to an encryption key of some sort (or asymmetric key pair). How does one set this up so that the CPU know how to encrypt things that only the TPM can decrypt, and vice-versa? If you use public/private key pairs, how do you ensure that the thing talking to the TPM with its public key is the CPU, and not, say, an attacker who has clamped a probe onto to the tracks on the motherboard and hooked it up to a Raspberry Pi Pico? Presumably the public key has to be known to chip manufacturers, at least. The likelihood of something like that (both widely known, but also secret) not being leaked is so close to zero that we might as well assume it's already broken.

      It's not like you can have some sort of certificate for both the CPU and TPM to authenticate themselves, without having a master registry (in hardware) of all those certificates, or the ability to look them up via, for example, a certificate authority, which means an entirely independent comms channel to the internet. Even then, we know that some certifying authorities we already have for things like SSL are less than reliable. How do you revoke a certificate authority that's hard-baked into hardware? If you can, how do you do that securely, without opening a vulnerability for a bad actor to revoke legitimate ones?

      For some reason, security has a reputation for being Hard, with a capital 'H'. I can't imagine why...

      1. OhForF' Silver badge

        Re: A brilliant testament to analysis

        >failed to encrypt comms between CPU and TPM

        >OK, clever clogs, explain to me how this can be done, securely...<

        E.g. using an encrypted keystore protected by a passphrase that has to be entered before the decryption process can start. See ohter comments about LUKS.

        Having to enter a passphrase for every boot is inconvenient but it provides additional security.

        1. Elongated Muskrat Silver badge

          Re: A brilliant testament to analysis

          This is already a thing, though. My work laptop requires it; my employer required that I set up a "PIN" that only I know so that nobody else can access the laptop.

          The problem is the trust between the TPM and CPU where there is not an external (i.e. user) input of the secret part; this is not required, so the security is broken by design. Without a secret component known only to the user, at some point in this process, the interchange has to be in plain text, or encrypted with known keys, which is, for all intents and purposes, equivalent to plain text (in the same way that ROT13 is).

          1. Oneman2Many

            Re: A brilliant testament to analysis

            This isn't a logon PIN, this is a bitlocker PIN which is different and I suspect no organisations have it switch on.

            1. John Brown (no body) Silver badge

              Re: A brilliant testament to analysis

              Most of the clients I deal with do have it switched on by default. Every boot up starts with the blue bitlocker PIN entry screen.

              Even the default Windows Bitlocker settings that most users might be using has the option in the Bitlocker settings to switch this option on. Although I think this only allows a numerical PIN of 10-20 digits. If you want a passphrase, I think that can only be done using policy settings.

        2. doublelayer Silver badge

          Re: A brilliant testament to analysis

          That method already works with this vulnerability. If there is an additional passphrase, then the overheard component from the TPM is insufficient to decrypt and you're already secure, no need to add additional cryptography to the communication. And any user can set that up with Bitlocker. This happens when they have selected not to do so.

          1. gumbril

            Re: A brilliant testament to analysis

            I've just set it up, you need to be admin to do it, and my users are not admin. I'd also not trust users to go rummaging in group policy editor.. which is required.. and then set the pin via an admin shell. Still, the demo was pretty impressive/scary.

            1. Oneman2Many

              Re: A brilliant testament to analysis

              You don't need GPO setting to show the option but yes the user will need to be a local admin which they aren't on most enterprise workstations.

              1. John Brown (no body) Silver badge

                Re: A brilliant testament to analysis

                On the other hand, most enterprise workstations should not have users changing security settings anyway, no matter who they are. That really is a policy decision that ought to be implemented across the whole org otherwise you have a support nightmare, even if the decision is to have different security policies for different departments or groups of users :-)

        3. Dave Null

          Re: A brilliant testament to analysis

          and if you read the linked MS article, that is exactly what they did when they advised customers with an advanced threat profile to use bitlocker plus PIN. Problem is it's a management nightmare especially if you don't use network unlock.

        4. Updraft102

          Re: A brilliant testament to analysis

          That's just the thing. MS is pushing for passwordless authentication with Windows Hello, using a TPM to store the encryption key that would otherwise be derived from a salted, hashed strong password entered by the user.

          Microsoft claims the TPM is about increasing security, but it really is about increasing convenience. Using face ID or other biometrics for authentication requires that the biometric data and the encryption key be stored on the unit that one is trying to protect, and they have to be on the insecure side of the wall to work. That creates an attack surface that would not otherwise exist.

      2. Bill Gray

        Re: A brilliant testament to analysis

        Perhaps I'm missing something here, but it seems like the usual case where Alice (=CPU) and Bob (=TPM) wish to communicate without Eve or Mallory (=Raspberry Pico) able to learn anything useful. The CPU and TPM use, say, Diffie-Hellman to get a shared private key, and the TPM sends the passphrase encrypted with that key. Eve/Mallory sees lots of data going to and fro, but nothing from which a passphrase can be practicably extracted.

        1. Elongated Muskrat Silver badge

          Re: A brilliant testament to analysis

          What you are missing is a man-in-the-middle attack on the key exchange, performed by pico-Mallory. I believe Diffie-Hellman is just as vulnerable to this as any system where Alice and Bob have starting positions where they know nothing about each other.

          https://www.geeksforgeeks.org/man-in-the-middle-attack-in-diffie-hellman-key-exchange/

          Both Alice and Bob have to provide a message to the other, that can't be spoofed, or intercepted and read, by Mallory. Since Bob must be able to read Alice's initial messages, and Alice must be able to read Bob's, it stands to reason that Mallory can too, and can relay them without detection.

          If Alice says to Bob, "Hi, here's my public key, I'd like you to use it to encrypt message to me, because only I have the private key to decrypt those", and Mallory intercepts that message, and substitutes his public key for Alice's, then Bob will be encrypting his messages with Mallory's public key, and Mallory can then take those, decrypt them, read them, re-encrypt with Alice's public key, which he also knows, and pass them on to Alice, without either Alice or Bob knowing. Unless both Alice and Bob are acutely aware of message timing, and can detect from that, that the messages have been decrypted and re-encrypted in flight, Mallory can read all the messages in plain text.

          1. Blank Reg

            Re: A brilliant testament to analysis

            The key exchange only needs to happen once when the machine is first started, then stored encrypted in some WOM memory on the chips. That isn't foolproof, but tapping into the internals of the TPM or CPU is a lot more difficult than connecting to some pins on the motherboard

          2. SCP

            Re: A brilliant testament to analysis

            From my recollection Diffie-Hellman does not have a problem with messages just being read during the key generation phase since even seeing all the messages Eve (Mallory) cannot construct the final key (subject to discrete logarithms remaining hard to compute).

            In order to break basic Diffie-Hellman Mallory needs to intercept the messages between Alice and Bob and replace them with his own. He then needs to continue relaying messages between Alice and Bob decoding them and recoding them with his spoofed keys.

            To prevent a MitM attack by Mallory an extended protocol that incorporates authentication, or verification that the communication channel has not been subverted, would be needed

          3. JamesTGrant

            Re: A brilliant testament to analysis

            Mallory, who dat? Charlie shurley!

          4. Bill Gray

            Re: A brilliant testament to analysis

            What you are missing is a man-in-the-middle attack on the key exchange, performed by pico-Mallory

            Not missing; I was mis-remembering. You're right; this remains subject to MITM. Back to the drawing board...

            Okay, Alice and Bob are just going to have to have a shared private key, imprinted on the CPU and TPM at the factory. My initial thought was that it'd be a pain for each CPU and each TPM to have a unique number built into it. However, Intel® and some other CPUs have had serial numbers burnt into them (and perhaps still do, for use with the ME?) So it may not be infeasible.

            Or, I suppose you could use Diffie-Hellman only once, the first time the TPM and CPU communicate. If somebody accesses your laptop after that and inserts the Raspberry Pi/Mallory, the TPM and CPU can say : we already have a shared secret, and we aren't telling you what it is.

            All of this, of course, just makes things more difficult rather than impossible to break. As has been repeatedly mentioned, if you don't have physical security, somebody can figure their way around whatever cleverness you've done. (Which isn't an excuse for making it easy to break.)

      3. martinusher Silver badge

        Re: A brilliant testament to analysis

        >OK, clever clogs, explain to me how this can be done, securely...

        The port that he connects to is obviously for use during manufacturing, maybe for downloading or customizing firmware. So the first line of defense would be to make sure that that bus isn't easily accessible, probably by using PGA parts and burying the traces in internal layers. Then you need to separate the programming bus from the data bus -- the TPM could be designed to only use a single line. This still leaves the key in the clear but you can manufacture the board so you effectively have to destroy the board and parts to get at the information.

        This is only Phase 1. Its really a matter of figuring out how deep you want to go down the rabbit hole (how much you're prepared to invest for how much security). I can think of lots more one can do so I daresay that Microsoft and Lenovo could as well, its just a matter of how far do you need to go. (You're welcome to dump my hard disk, for example. You might find it a bit boring, though....no valuable secrets there. My personal TPM is a card index, BTW -- useless if someone steals it but definitely hack proof.)

        1. usbac Silver badge

          Re: A brilliant testament to analysis

          It doesn't matter if you use an internal layer, the chip is still on the surface. It's no problem to collect the signals off of the pins on the chip.

          I tack very small wires on to chips under a microscope all the time when debugging my designs. I watched a friend of mine attach probe wires on to the solder balls under a BGA chip (several rows in) wile it was under x-ray.

          1. Anonymous Coward Silver badge
            Boffin

            Re: A brilliant testament to analysis

            It makes it harder, which in the end is all any scheme can do.

      4. catprog

        Re: A brilliant testament to analysis

        I know nothing about the whole scheme so this is a layman's interpretation.

        Whu do you need to encrypt the communication?

        The cpu encrypts with a key on cpu and that is what is sent to the tpm.

      5. mpi Silver badge

        Re: A brilliant testament to analysis

        > explain to me how this can be done, securely...

        Happy to. Have the encryption key itself encrypted and requiring a passphrase to unlock it. You know, how LUKS works.

        > Many problems (and supposed solutions) in security involve just moving the problem somewhere else.

        Yes, and as it turns out, there is a correct place to move the problems to: user convenience. Aka. make it a little less convenient (for example by requiring a passphrase when booting) and a lot more secure. Even the attack described in the article can be prevented by requiring an unlocking PIN on the device.

        This is not rocket science, and has been known to designers of security systems since basically ever: A curtain is much more convenient to go through than a heavy oak door with a steel lock, however the former is unlikely to be as good as the latter at deterring looters.

        In security as everywhere else, one cannot have their cake and eat it to.

        1. Elongated Muskrat Silver badge

          Re: A brilliant testament to analysis

          This is correct. Sadly, the security model is broken, because by design it allows for the user secret part to be omitted.

      6. drankinatty

        Re: A brilliant testament to analysis

        Made even more ironic by the fact that TPM is one of the reason your computer doesn't meet the requirements of Windows 11... You read something like this and you are just left shaking your head. The supposed trusted name in computing with its "secure" OS providing drive encryption where the key to unlock it is transmitted in the clear. Bugger... Would be interesting to know just what percentage of boxes have a separate TPM chip.

      7. Lipdorn

        Re: A brilliant testament to analysis

        One could load the keys for encryption and authentication (pairing) on the CPU and the TPM during manufacturing or some other time occasion that is presumed secure. Obviously the private parts of the key pairs should not be readable by external devices (or leaked to them). So the private keys ought never to leave the CPU secure enclave (i.e. can't use a debugger to view the registers of the CPU to obtain the keys).

        You don't need CAs since only devices with the private key can decrypt the data. If the CPU can't leak the private key, then only the CPU would be able to decrypt the data.

        Changing the public key on the TPM ought to wipe all information on the module. Though a passphrase + key combination could be used to recover stored information or to enable key changes without wiping of stored information.

        The crux of the problem is storing the private key of the CPU if the CPU does not have secure non-volatile memory. Though perhaps a hardwired unique private key could also suffice.

        1. Elongated Muskrat Silver badge

          Re: A brilliant testament to analysis

          So, when I "manufactured" my home PC, which has a physically separate CPU (which I fitted) and TPM (which I fitted, at a later date), at what point should i have somehow generated and "loaded" private keys into the CPU ad TPM? If they were already present, how should I have obtained them to load one's public key into the other? How would you prevent someone else from extracting the same keys at a later date in the same manner, thus enabling a MitM attack? If I am to load keys myself, how am I to prevent someone else from loading new keys at a later date (and thus knowing them, and being able to perform a MitM attack)? If I can only load them once, what happens if I find out that my keys that I have had to generate myself, are not properly secure (because, as a typical user, I am not security aware) and I need to generate new ones, but cannot? Oh dear, someone has got hold of the plain-text copies of those keys that I generated, and used them to perform a MitM attack!

          Did I mention that security is hard? I am also not a security expert, but am well-read enough on (and have practical experience in) the subject to know what questions to ask...

          1. Lipdorn

            Re: A brilliant testament to analysis

            Issues that have been mostly adequately addressed in most businesses. There will always be some way past, but at least it wouldn't be quite as trivial.

      8. ChoHag Silver badge

        Re: A brilliant testament to analysis

        The hard part is trying to secure devices *from* their users.

        As Apple said, if Wozniak can beat it, it can't be done. So they got rid of Wozniak.

      9. wimton@yahoo.com

        Re: A brilliant testament to analysis

        There are methods of securing the communication to a secure device. One of them is the PACE key agreement protocol. One of the uses is in electronic passports, where an attacker can listen to the wireless communication. A more exotic application is between the security module and the processor in German smart meter gateways.

    4. Updraft102

      Re: A brilliant testament to analysis

      "failed to encrypt comms between CPU and TPM and thought "this is Good EnoughTM"."

      The system is requesting an encryption key for the Bitlockered drive from the TPM, and it is being intercepted in transit. So if you propose for that communication to be encrypted, where is the key to encrypt the transmission of the Bitlocker key going to be stored?

      The basic issue is that Microsoft and many others are pushing this idea that passwords are a thing of the past, but that invariably means that the keys and data used to decrypt and authenticate have to be stored on the same PC that one is trying to protect. That is inherently an insecure setup, even if Microsoft keeps saying that Windows Hello is more secure than using a password. It may be more secure than the way they implement a password, but there can be no doubt that a laptop that requires the user to enter a strong password/passphrase to unlock the encrypted volume(s) is more secure at rest when that key is nowhere to be found on the device.

      That is not to say that other kinds of attacks are not possible, but if you simply have a stolen laptop with an encrypted drive and with the key derived from a salted, hashed, strong password that is not present anywhere on the unit, it is going to be rather difficult to extract the data. A keylogger won't help, since the unit is no longer in possession of anyone who knows the password/phrase. If the stolen laptop was then recovered, it would have to be treated as being compromised, not just returned to service as if nothing happened.

      1. Elongated Muskrat Silver badge

        Re: A brilliant testament to analysis

        Indeed, in order to beat that password, you need to get hold of the laptop while it's still powered on, then grab the memory out of it and dunk it in some dry ice while you read the contents.

    5. Not Yb Bronze badge
      Alert

      Re: A brilliant testament to analysis

      ' When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" '

  5. Missing Semicolon Silver badge

    What about LUKS

    That relies on the secret being typed in to the console, which is then used to decrypt the key from a keystore block. Is the encryption good enough on that to keep a Pi Zero busy for a few hours?

    1. theOtherJT Silver badge

      Re: What about LUKS

      You can do LUKS a lot of ways - including hardware tokens like yubikeys or similar. If you're going with good'ol "Type this password in at boot" then I have to assume it's as good (or bad) as any other purely password based approach. If you an automate feeding the password you can break it in an amount of time determined by the complexity of the password.

    2. Clausewitz4.0 Bronze badge
      Devil

      Re: What about LUKS

      "That relies on the secret being typed in to the console, which is then used to decrypt the key from a keystore block. Is the encryption good enough on that to keep a Pi Zero busy for a few hours?"

      Not the same use-case. In this case, BitLocker relies on a key stored in a chip that can be "easily" sniffed.

    3. david 12 Silver badge

      Re: What about LUKS

      Yes, that's the PIN used to secure the bit locker conversation. If you choose to not use a PIN, then you're depending on people not opening the case. If you are storing child porn or military secrets, and don't want to use a PIN, this weakness (but not your stupidity) can be mitigated by choosing a modern laptop with a modern processor.

  6. js6898

    just out of curiosity - if you are going to buy a laptop what is the best way to find out if the CPU and TPM are on the same chip

    1. Clausewitz4.0 Bronze badge
      Devil

      "just out of curiosity - if you are going to buy a laptop what is the best way to find out if the CPU and TPM are on the same chip"

      Download the datasheet from the vendor's website for that computer. Usually a PDF.

    2. Elongated Muskrat Silver badge

      Find out which processor (exact model number) the laptop has in it. Search for a data sheet on that processor to determine whether it has on-chip TPM.

      1. Roland6 Silver badge

        But as we learnt with W11 hardware requirements, many systems had a discrete TPM chip and disabled the on-cpu-TPM.

        Obviously, with more CPUs incorporating tpm, this ability to intercept TPM communications is going to be harder.

        1. hh121

          Re W11 requiring separate TPM chips...that's what I thought. And I was annoyed when the brand new (2 years ago) Gigabyte X570 board for my son's home build gaming rig didn't include one (according to the upgrade assessment tool), so I thought we were stuck on W10. But unbeknownst to me, when the system asked him for the umpteenth time if he wanted to update to W11 and he said Yes, it automagically enabled the soft TPM (don't ask me what happened, I wasn't there) and allowed the upgrade to proceed.

    3. Anonymous Coward
      Anonymous Coward

      A better question would be "How do I find out if the laptop I intend to buy uses the TPM that's likely built into the CPU-SOC or if it uses an external TPM"

      1. 43300 Silver badge

        I think most laptops have it built into the CPU now, don't they? The separate plug-in module was more a desktop thing.

        1. Anonymous Coward
          Anonymous Coward

          Doesn't have to be a separate module, it could just as easily be a separate chip soldered to the board or an implementation in the embedded controller which is often a separate chip too, so, yeah, while the CPU is highly likely to have an embedded TPM, it still doesn't necessarily mean it's the one being used..

    4. Spamfast

      just out of curiosity - if you are going to buy a laptop what is the best way to find out if the CPU and TPM are on the same chip

      Ideally, the TPM & CPU need to be on the same wafer within the IC package which should also be manufactured in a tamperproof fashion such that any attempt to shave off the top to reveal the wafer will destroy it so that electron microscopy can't be used to observe the internals. Similarly, it should be hardened against voltage rail, EMC & X-ray susceptibilities.

  7. Julian 8

    And I know people who wonder why on my own laptops I have PIN enabled on bitlocker - I just do not trust things that unlock automatically, just like I cannot fathom how MS think me having a silly little PIN is safer on mine, or a company laptop than me using a passphrase.

    Hey ho

    1. Anonymous Coward
      Anonymous Coward

      As a nice little demo to our cybersec guys, I kept a tally of how many user's laptops used 12345678 or some similarly obvious PIN.

      They were quite upset.

      1. Benegesserict Cumbersomberbatch Silver badge
        Mushroom

        I seem to recall JFK had a run-in with Curtis Lemay about nuclear weapons whereby the Prez insisted each individual weapon have an arming code. The General set them all to 00000000.

        1. Anonymous Coward
          Anonymous Coward

          Not really much worse than the UK's home grown nukes, from the BBC:

          Britain is the only nuclear weapons state which does not have a fail-safe mechanism to prevent its submarines launching a nuclear attack without the right code being sent, according to tonight's Newsnight on BBC Two.

          The programme also reveals that until less than ten* years ago, the locks on RAF nuclear bombs were opened with a bicycle lock key.

          https://www.bbc.co.uk/pressoffice/pressreleases/stories/2007/11_november/15/newsnight.shtml

  8. Oneman2Many

    It does need access to the LPC connector, the laptop used had the lanes exposed on a unused connector, other laptops may need chip to be de-soldered to gain access which to do be honest isn't going to stop a determined and semi-skilled bad actor.

    It also needs a discrete TPM chip, which has been integrated with CPU since 6th gen on Intel back in 2015 (wonder why a 10 year old laptop was used ?).

    Finally if you are worried then you can create a Bitlocker PIN which stops the attack however I suspect the majority of users don't do that.

    Suffice to say that it goes to show that if somebody gains physical access to your device then it will be vulnerable.

    1. Elongated Muskrat Silver badge

      My desktop gaming PC has a 9th Gen CORE i5 in it. It also has a separate TPM module so that Windows 11 will run on it (on the rare occasions that I actually need to boot into Win11, but eventually we all know MS will force us to "upgrade" to continue to get security updates). It may be the processor has a built-in TPM, but the motherboard's BIOS doesn't have the option to enable it. However, I think "since 2015" isn't the same as "since 2015 in all processors".

      1. elsergiovolador Silver badge

        Also I would take TPM built inside the CPU with a heap of salt.

        The fact that ME running on those CPUs is not documented and is not open source, invalidates any perceived security of TPM.

        It's highly likely that with the right tools, probably reserved to certain agencies, you can extract keys stored there and decrypt whatever is encrypted with it.

        That's the whole point of TPM. It's cryptographical equivalent of TSA key.

        1. Elongated Muskrat Silver badge

          I reckon that with a spot of laser ablation and a scanning electron microscope, and a fair amount of effort, any chip will give up its secrets with time. I'm assuming that CPUs made on the same die would all have the same baked-in TPM key, but there might be some sort of process to vary the die, or flash the key in later. in those cases, you would probably also need to have some expensive CPU probing kit, but that's probably going to cost peanuts compared to the SEM.

          The same logic applies to separate TPM chips, be they solder onto a motherboard, or on a TPM module. With enough money and finesse, you can pull anything apart to the functional level and work out exactly what every logic gate is doing.

          1. The Oncoming Scorn Silver badge
            Holmes

            My desktop PC at home, doesn't have a TPM chip installed, if I really really wanted one its about $20 US & can be plugged in on a header.

            Which seems to defeat the whole point of it's security especially as this technique would probably allow for the interception of the keys between the module & motherboard.

            1. The Oncoming Scorn Silver badge
              Facepalm

              Missed The Edit Window Due To Work Disrupting My Shirk.

              Also steal the TPM chip when you nick the HDD unless there's some other form of hardware #.

              1. Robin Bradshaw

                Re: Missed The Edit Window Due To Work Disrupting My Shirk.

                Even if you steal the TPM chip you wont be able to recreate the state of the PCR registers in another machine so it wont be able to decrypt the VMK, you'd have to steal the whole computer and then snik the key.

                Use TPM and PIN the TPM enforces anti hammer so you get i think 30 attempts at the pin then it locks for an hour per guess and it wond decrypt the VMK until you get the PIN correct.

            2. Elongated Muskrat Silver badge

              Don't get me wrong; the only reason for having the TPM module is to allow it to run Win11. I don't have Bitlocker enabled on my home desktop PC, because if someone gets in and steals it, the main loss is of the machine, not the data on it. The convenience of being able to remove a disk and read it from another system, for a hardware tinkerer, outweighs the security from having it encrypted. I'd be far more likely to lose access to a disk's data from failure of the TPM module, than from the disk being stolen. One of the things about security is also trade-offs.

              My work laptop, which is currently on the same desk, has PIN-protected bitlocker, because it contains commercially sensitive data that needs to be secured. If my desktop PC did, I'd be encrypting the volumes that held that data.

              1. The Oncoming Scorn Silver badge
                Meh

                I'm running Win 11 quite contently, now I've got it working the way I want without the TPM chip.

        2. Oneman2Many

          I suspect as well that you can access TPM even with it integrated but you are looking at some pretty specialist tools. Looks at what they managed to do with the locked iPhone from the US terrorist.

  9. elsergiovolador Silver badge

    Downvotes

    Remember writing about this ages ago and getting downvotes.

    TPM has been created to give false sense security and for 3 letter agencies to be able to access encrypted data easily.

    1. Anonymous Coward
      Anonymous Coward

      Re: Downvotes

      Prove it.

    2. Michael Kean

      Re: Downvotes

      Would TrueCrypt (long since discontinued) be any better? I'm guessing not as the key would be in RAM.

  10. Anonymous Coward
    Anonymous Coward

    What's the point of having a bitlocker key to type in?

    1. Elongated Muskrat Silver badge

      You can take the disk out of the laptop, or clone it and take away the clone, and decrypt its (supposedly secure) contents.

      1. Roland6 Silver badge

        Which can be handy when the laptop dies, but not the disk, so any data on the disk (eg. Photo library) are not necessarily lost.

    2. david 12 Silver badge

      For removable drives, the bitlocker key isn't stored in a TPM. You can move the drive and type in the bitlocker key. A USB keyboard logger could capture your bitlocker key, analogous to this demonstration.

      For non-removable drives, you can store the bitlocker key in a TPM, and optionally you can also use a non-stored-in-TPM key (PIN) to encrypt TPM handshaking.

      In theory you should be able to get properly encrypted USB, but I've not seen anything -- even the "secure" keyboards only encrypt between the keyboard and the USB plug. The problem is that a keyboard with end-to-end encryption isn't a keyboard -- it's sending encrypted packets instead of keystrokes, so it needs to identify as an encrypted device, not as a keyboard.

  11. StrangerHereMyself Silver badge

    Deliberate

    This can't be a design flaw. This was deliberately designed in this manner.

    It would be obvious to any cryptologist with half a brain to use asymmetric encryption to exchange symmetric keys and subsequently use those to communicate between the TPM chip and the processor.

    1. FIA Silver badge

      Re: Deliberate

      And where do you store those keys? How do you ensure they're valid?

      Fuck me, it's turtles all the way down.

      1. StrangerHereMyself Silver badge

        Re: Deliberate

        Those keys are generated on the fly, obviously.

        1. doublelayer Silver badge

          Re: Deliberate

          Are you a cryptologist? You are aware that generating new keys each time you need to communicate opens you to an attacker intercepting your communication before you've sent the key, substituting their own key, and MITMing all your traffic. The hardware used to read communications along this path can also write them. The way to get around this is to prearrange keys. If the TPM had a bit of memory to store the key, then you'd only need to exchange keys once, although either side losing or compromising the stored key would break it.

          Generating keys on the fly is no more secure than this method when your risk is external access to the communication path.

          1. StrangerHereMyself Silver badge

            Re: Deliberate

            Why would generating new keys open you up to an attacker intercepting the key? The entire reason we have asymmetric encryption is to prevent just what you're describing!

            A shared secret could be used to make MITM impossible in a asymmetric key system.

            1. Elongated Muskrat Silver badge

              Re: Deliberate

              How do two components that know nothing about each other share a secret? Wow! Another Turtle!

              Reading the comments here, it seems that there are an awful lot of people who need to start reading Bruce Schneier's blog, and probably some of his books before putting their ideas into practice.

              One important principle that he talks about often, is the fact that anyone can come up with a method of encryption that they can't defeat themselves, and thus feel is secure. Someone who knows what they are doing can usually come along and defeat it in minutes, if not seconds.

            2. doublelayer Silver badge

              Re: Deliberate

              That is not why we have asymmetric encryption. We have asymmetric encryption to securely identify people, but you can't do that if you've never seen them before.

              Say that we decide to exchange some encrypted communications and I send you my public key in the mail. When you receive an envelope containing a public key, how do you know it is mine? If someone intercepted the message and sent you a different key, how do you know that it wasn't mine? You don't. All you know right now is that you have a public key. If whoever intercepted our mail can't also intercept our other communication path, then you'll figure out that it doesn't match me when I can't read any of your messages. If they can, though, you encrypt something with their public key and they intercept it. They can decode that, know what you said, then encrypt it with my real public key which they got from my letter. They send it on to me, and I assume it's you doing it because they used the public key I gave you (or they intercepted your letter as well, either way works). I therefore use their key as well, and they've effectively obtained access to all our communications even though we think we're being secure.

              There are two ways to get around this. One is to have an external method of validating that the keys belong to. That can be manual key signing or certificates, but either way, you have to have an external chain of trust. That's why HTTPS can use keys you've never seen before, because you can check them against the certificate authorities and you have seen their keys before. Drive encryption can't do that because it doesn't have an internet connection and because it would be too easy to generate a key that gets signed by some authority as being permitted to access anything. The other method is to keep a key stored from the first time, I.E. instead of getting mine in the mail, we meet in person and test each other until we're confident that the keys we're exchanging belong to the right person, then exchange keys physically. That's your best bet here, but it would require the TPM to have a secure storage location for keys which can neither be read or written except when the TPM is configured.

              1. Elongated Muskrat Silver badge

                Re: Deliberate

                Exactly this. I'll just add that a one-time setup will still need a secure channel between CPU and TPM in order to exchange those keys, or some method to enter them manually. At best, you're moving the exact same problem further along the road by one step, and at worst you are introducing a new vulnerability.

                It's also worth pointing out that since CPUs and TPMs are modular, and it's perfectly reasonable to be able to replace one or both, that one-time setup needs to be actually not be one-time, but have a reset or update mechanism too. In this case, real-life requirements for functionality negate the only security you might gain (time-boxing the key exchange activity).

                1. doublelayer Silver badge

                  Re: Deliberate

                  Very good points. The first one is not very concerning to me, as it's pretty easy to set your key when you first encrypt the drive, and since you're the one doing it, you can be pretty sure that nobody has your computer open at the time. It's not perfect, but you only have to do it once. The replacement of a TPM doesn't concern me much, as it would already require setting a new key even without secure communication.

                  However, I start to wonder whether implementing this encrypted communication path is worth doing. Using TPM alone to store keys is giving a piece of hardware the ability to unlock the drive in the same box. People should know what that does (protect against access to data on the drive if you only have the drive), what it doesn't (secure things against someone who has the entire machine) and that they have other options and act accordingly. For example, whether this interchip communication is encrypted or not, the attacker can still turn on the computer, boot the operating system on the encrypted drive, and try to do something at the login screen. If they found a vulnerability at this stage, encryption would not matter and they could gain access that way. If they intercepted communication between the CPU and the RAM, they could do something similar. Hardening one path will not prevent the combination of physical access and all keys stored inside this box and not the user's brain from being less secure than the alternatives that involve getting part of or the entire key from an external input so that physical access to the computer is insufficient to decrypt it.

          2. Missing Semicolon Silver badge

            Re: Deliberate

            Isn't that what Diffie-Hellman is for?

            1. doublelayer Silver badge

              Re: Deliberate

              Not quite. Diffie-Hellman allows you to exchange keys with someone in a public channel, but does not let you prove while doing so that the person you're exchanging keys with is the person you want to. The benefit of it if it's done well, which is not easy but possible, is that if I am watching your communications, I should find it hard to determine your shared key. If I can successfully interpose myself in your conversation, providing my own keys and preventing the person to whom you think you're talking from providing theirs, then I can still impersonate them. If I can simultaneously do that to both of you, then I can impersonate each of you to one another and both eavesdrop on the communication and modify it as desired. An electronic device physically between the chips is capable of doing that, so if they don't start out encrypted, the communication is weak.

  12. PapaPepe
    Holmes

    Plastics?

    One word: Truecrypt 7.1a

    The only thing you must ensure is not that your adversary never gets physical access to your kit (very hard, with some adversaries impossible), but that she does not manage do so without leaving any trace. With just a bit of imagination, that is often surprisingly easy.

  13. Anonymous Coward
    Anonymous Coward

    The (outdated) chipset was defeated. Zero to do with Bitlocker. Also it doesn't work if you actually follow Bitlocker recommendations and set a preauth code / pin.

    1. Anonymous Coward
      Anonymous Coward

      And for his next trick, monitor the SPI bus used to connect external TPM chips on modern boards.

      Take a look at the block diagram for the Intel Z790 chipset for example, that bit in the middle?

      Yeah, that's the TPM, hanging off a SPI bus which anyone with a halfway decent logic analyser (and possibly Raspberry Pi Pico) can sniff.

      The big question, is it still unencrypted...

  14. Scott 26

    Genuine question: What is the solution for non-windows machines? What's the *nix equivalent of BL? And would it be just as vulnerable (MitM sniffing between CPU and TPM)?

    1. Trixr

      LUKS is available with most Linux distros and you can encrypt the disk during setup. Or later, of course - it'll work with passphrases, TPM chips, smart card etc. https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup

      dm-crypt is the underlying disk encryption kernel module that LUKS and there are other methods/products for leveraging dm-crypt, including the very much now-deprecated TrueCrypt. VeraCrypt was originally a fork of TrueCrypt and is still maintained, but doesn't integrate with TPM and stores keys in RAM, so it doesn't operate in the same kind of way as Bitlocker.

  15. Baldy1138

    Hmm ...

    Isn't BitLocker the reason TrueCrypt was discontinued?

    1. Anonymous Coward
      Anonymous Coward

      Re: Hmm ...

      I don't think so.

      Veracrypt is the official continuation of TrueCrypt:

      https://www.veracrypt.fr/en/Home.html

      Veracrypt was subject to several public security audits and so far, most of the known/discovered vulnerabilities were addressed. It also has been updated with support for modern algos, Windows 11, UEFI boot and Unix/Linux support which is now on par with Windows support (IMHO). I have installed/run it on Linux x86 and Raspbian (arm) with no issues. Recently, older algos have been deprecated due to known issues (ex. SHA1).

      I don't profess to know a lot about encryption, but with veracrypt, it doesn't use any external hardware to store keys. The user must provide the pass phrase at startup and then the program goes through various supported algorithms (or combined algos) using the pass phrase until it finds a valid header. For encrypted container files, the user can also optionally identify 1-n number of "key" files (on disk) that are combined with the pass phrase. That way the decryption requires access to the key files being present as well as knowing the passphrase. The key files can be anything, text files, binary files.

      I don't know if the reason why the truecrypt team abandoned their efforts was ever made public. And if someone does know, they ain't sayin.....

      1. Oneman2Many

        Re: Hmm ...

        VeraCrypt doesn't support Active Directory, AFIAK it doesn't offer any support for central key storage or passwords. Probably a major requirement for most enterprises.

    2. Ordinary Donkey

      Re: Hmm ...

      It was the stated reason at the time, but it sounded like an excuse even then. For whatever reason I think that some of the original TrueCrypt devs wanted out.

  16. FIA Silver badge

    Look, I know it's the Reg, and it's a red top, but "Raspberry Pi Pico cracks BitLocker in under a minute" is just wrong.

    But then 'Door opened with key' isn't so sensationalist is it. :)

  17. Malcolm Weir Silver badge

    While it may be unpopular to note this...

    Even with this vulnerability, it is worth noting that using BitLocker with this type of TPM offers security benefits:

    1: Once removed from the PC, the storage device is unreadable without either the TPM or the recovery key.

    2: Purging the TPM renders the storage device unreadable without the recovery key.

    So while imperfect (oh, how imperfect) systems with this TPM/BitLocker setup are pretty good at avoiding the formerly ubiquitous "I bought a job lot of e-waste and now I know your bank details" problem.

    (For any kind of non-trivial security, you need a 2FA approach of some kind, and I'm of the old school which believes that the 2 in 2FA means two factors _in addition to the thing being unlocked_. So a SmartCard and PIN, for example. Somewhat to my horror, I've been seeing people claiming a dongle + a laptop is a 2FA solution, because you need the dongle and the PC to get the data).

    1. david 12 Silver badge

      Re: While it may be unpopular to note this...

      Daily WTF: Wish-It-Was TwoFactor authentication:

      https://thedailywtf.com/articles/WishItWas-TwoFactor-

  18. Lee D Silver badge

    Bitlocker is not "cracked" by any definition.

    If you can sniff the TPM keys in plaintext because of a dumb design, that's not Bitlocker being cracked.

    That's like those people who say their Facebook was "hacked" when their password is the same for everything and about as complex as "password". No, it wasn't.

    Unnecessary hyperbole everywhere about this one.

  19. neverending

    The TPM on my computer is in software; would this be an easy way to thwart this attack?

    It's turned off so the computer has given up on upgrading to 11.

    Vertical taskbars rule!

  20. Screwed

    Virtual TPM

    Where does this leave virtual TPM systems - such as are widely used on Macs running virtual Windows 11?

  21. Mr Dogshit
    IT Angle

    Slow news day?

    So fucking what? This has nothing to do with BitLocker.

    If you have physical access to the data bus to and from the TPM, of course this can be done.

    This is a stupid, nonsensical, clickbait story.

    1. Anonymous Coward
      Anonymous Coward

      Re: Slow news day?

      The story is that the comms on the bus is unencrypted, easily sniffable with a cheap and easy to obtain piece of kit and in a reasonably clever way without access to the LPC clock.

  22. markpearsall82@gmail.com
    Pirate

    Why Go to all that trouble?

    All you have to do is flip the lid and find a post it with the Bitlocker key on it ;)

    1. DJO Silver badge

      Re: Why Go to all that trouble?

      Why bother, just nick the unencrypted back up discs which should be locked in a safe but seldom are.

      1. Anonymous Coward
        Anonymous Coward

        Re: Why Go to all that trouble?

        All mine are encrypted, dunno why yours aren't.

  23. Spamfast
    WTF?

    D'oh!

    Unbelievable.

    As others have pointed out, it's perfectly easy to have an encrypted channel over whatever bus lies between the crypto device and the main CPU doing the on-the-fly en/decryption. At boot, the CPU software & crypto negotiate an encrypted channel with a new set of keys using standard techniques. (Look them up.) The crypto rejects any weak methods from the CPU software. When setting up disk encryption, the CPU hashes the user's credentials and passes these to the crypto module over the encrypted channel. The crypto generates and stores keys with that hash and passes the keys back over the encrypted channel. The CPU encrypts whatever isn't yet encrypted. On subsequent reboot, the CPU software sends the same hash over the new encrypted channel and if it tallies, the crypto returns the keys to the castle over the encrypted channel. As long as the crypto IC is designed to be tamper-proof, if the whole lot is stolen, the perp will still need those credentials to decrypt.

    However, this reminds me of the huge hole in chip'n'pin payment cards. While a lot of the comms between the card and the retailer's POS machine is encrypted, the message that comes from the card to tell the POS that the PIN the user entered is correct is neither signed nor encrypted. So, you steal someone's card and plug it into a reader in your backpack and have an MITM between that and a card with the appropriate dimensions and connections to talk to the POS that simply tells the POS that whatever the customer has typed in is the correct PIN. Someone built a proof of concept rig with wires up his sleeve but you could probably miniturize & make it wireless using short range digital radio modules.

    This is a bit like PS1 mod chips that looked at the bit stream from the CD-ROM and replaced the appropriate section that nornal CD burners couldn't duplicate with the required sequence.

    1. Spamfast

      Re: D'oh!

      Actually, I hadn't realised that the TPM actually gives the CPU software the keys which is inherently insecure even using ephemeral keys. I'd rather assumed that the CPU would pass cipher/plaintext on-the-fly to the TPM and the TPM would return it converted but I guess doing that over the sort of bus they're using would be prohibitively slow.

      I used to work on sat-TV boxes and they have a device called a crypto DMA controller on the system bus with access to the main RAM.

      Instead of the CPU decrypting the data stream from the dish, each chunk in RAM containing both the audo/video & ancilliary crypto TP stream packets that prevent replay attack is passed to the cryptoDMA which decrypts in place if it passes muster. The cryptoDMA has to be periodically unlocked with information both from the TP streams & the user's credentials otherwise it stops playing.

      The point is that symmetric encryption/decryption keys and PKI private keys are generated within the crypto DMA and never, ever leave it. If it's designed suitably tamperproof, there's no way to get those keys simply by getting hold of the device.

      Satellite service provides are very serious when it comes to protecting their content! :-)

  24. 43300 Silver badge

    I've not tested this for a while, but it used to be the case that if you had an autopilot / Intune, device, with the device encryped by policy, then you deleted the device and its enrollment from Intune without wiping it first, the local administrator account on the device would then get enabled, and would allow login with no password. Microsoft confirmed that this was by design, when I asked.

    Hence the need to be careful to wipe devices before removal and/or disposal. What you are supposed to to if one gets stolen and doesn't respond to a wipe request was unclear - leave it on Intune indefinitely in case it calls home at some point?

    Anyone know whether this large hole still exists? Prior to finding it I assumed that if a device was removed from Intune, you couldn't log into it and you hadn't recorded the Bitlocker key from Intune before deleting the device, that would render the data inaccessible - but appearently not.

    1. Anonymous Coward
      Anonymous Coward

      Only if you never set an administrator password on the device. It stays the same.

      1. 43300 Silver badge

        On an Intune device under normal operation, the local admin account is generally disabled, isn't it?

  25. Plest Silver badge
    Facepalm

    So Bitlocker is basically yet another piece of "security theatre" to make us all "feel" more secure but if it's worth it to someone then they will crack it. Glad I never wasted my time with Bitlocker, seems like a pointless exercise now as it's no more secure than a bog standard 8-char alpha password!

    1. doublelayer Silver badge

      You clearly haven't bothered to read the numerous comments here that explain why:

      1. Bitlocker, even in this insecure configuration, is significantly more secure than a simple password on an unencrypted drive.

      2. This is only one configuration, and any of the others would prevent this attack.

      3. Exploiting this attack is only possible on a subset of hardware, and there are large classes of devices where it would not work.

  26. MarkMLl

    Hardly surprising...

    There's been multiple people looking at making use of the LPC bus- which is what accesses the TPM when it's not integrated into the CPU- for a couple of years: some of whom use the Pico.

    https://hackaday.com/2023/06/13/bios-post-card-built-using-raspberry-pi-pico/

    So the real issue here is that BitLocker uses the key from the TPM without combining it with "something /else/ you have" or "something /else/ you know": i.e. a swipeable card or a passphrase to be entered.

    None of which would help in the "Dread Pirate Roberts" scenario where both he and his laptop were taken live, or... (obligatory XKCD) https://xkcd.com/538/

  27. russmichaels

    This article is very clearly misleading, ok just downright lying, as it obviously did not take him less than 1 minute to do this.

    1. MarkMLl

      It took the /Pico/ less than a minute. The point being made- and I think it's fair- is that it didn't involve hours or days of computation to decrypt a key, or some substantial amount of memory to build up rainbow tables.

  28. Mage Silver badge
    Devil

    "provided you have physical access to the device."

    In general, good security is only possible on remote access.

    There are so many routes for the "Evil Maid" or "Untrustworthy Butler". Even a present of a USB mouse or keyboard that installs malware/trojan after the user logs in.

    Or Intel Management Engine or others via JTAG over USB.

  29. Tron Silver badge

    Yeah, but....

    This just speeds up the process of rolling all this into the CPU. At which point, we can only use a state-mandated OS in a state-mandated way on state-mandated hardware. A tech dictatorship.

    We really need a new platform that doesn't have all this in the first place. Something that is low cost, PC peripheral compatible and capable of all the basic computing and networking stuff. Maybe the Pi could do that. Maybe we need something else.

    1. PRR Silver badge

      Re: Yeah, but....

      > At which point, we can only use a state-mandated OS in a state-mandated way on state-mandated hardware. A tech dictatorship.

      Can you say 中国计算机 ?

  30. uqrxur

    stop this nonsense

    Until journalists stop relaying stories on how to defeat Bitlocker installations without a password or PIN, we will keep reading stories of random guys defeating BitLocker installed on a device without a password or PIN.

    Year after year.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like