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 …
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.
This post has been deleted by its author
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.
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.
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.
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.
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.
"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.
What is TPM? Typically, it's a separate chip on the motherboard... [emphasis added]
Source: What is TPM [microsoft.com]
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.
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...
>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.
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).
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.
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.
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 :-)
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.
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.
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.
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
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
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.)
>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.)
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.
> 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.
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.
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.
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...
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.
"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.
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.
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.
"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.
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.
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.
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..
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.
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
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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...
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.
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.....
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).
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.
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.
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! :-)
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.
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!
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.
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/
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
