News YouTuber breaks BitLocker encryption in less than 43 seconds with sub-$10 Raspberry Pi Pico

[TJ Hooker]

So this is a flaw in TPM, not really in BitLocker, specifically ... right?

Depends on how you look at it.

TPM 2.0 implements a feature that can encrypt the key sent over the data bus to the CPU, which would prevent the sniffing attack seen here.
https://trustedcomputinggroup.org/w...Guidance_Passive_Attack_Mitigation_8May23.pdf

But bitlocker seemingly doesn't make use of that feature.

Bitlocker can also be setup such that the TPM won't release the disk encryption key until a PIN and/or startup key are entered by the user (ukperson linked the relevant Microsoft page above). This would also prevent this attack. But bitlocker does not use this setup by default.

Is that a flaw in bitlocker? Or just a known limitation of the default configuration?

 

[minnion]

I swear Tom's Hardware is turning to clickbait crap. This hack only works with external TPM. So basically yea, it would only work on ten-year-old boards. Modern embedded TPM's are immune from this type of attack.

 

[TJ Hooker]

I swear Tom's Hardware is turning to clickbait crap. This hack only works with external TPM. So basically yea, it would only work on ten-year-old boards. Modern embedded TPM's are immune from this type of attack.

The YouTube source claims that discrete TPMs are still common for corporate office machines. I cant say whether that's true or not, but at least my own work laptop does indeed use a discrete TPM, and is less than 5 years old (based on its i7-9850H CPU).

 

[palladin9479]

I am not a software developer and wouldn't know what I am looking at nor do I care to learn it. Have you any reputable 3rd parties that have actually reviewed the entire code and kept up with all changes up until now?

From what I know of even basic software, things can easily get lost in the code when you're not even trying to hide anything.

Unfounded paranoia?

Yes it's unfounded paranoia, especially if your not familiar with coding or how opensource works. There are armies of people who pour over every inch of these code bases because finding vulnerabilities or back doors is major clout in that community. The first person to find something like that would instantly be famous and we'd all hear about it a few days later.

 

[palladin9479]

So this is a flaw in TPM, not really in BitLocker, specifically ... right?

Flaw in any external TPM chip.

Having said that, Bitlocker itself is fundamentally flawed because Microsoft compromised key security to make it more acceptable to enterprises.


Any security system is only as strong as the weakest link, which in all modern system is the key not the algorithm. Attacking the key is how you break any modern encryption system which is why the key security is the most important element. Earlier I explained MEK / KEK and it's the KEK we want to attack as once we have that we can decrypt the MEK at our leisure. TPM is just a black box that holds keys, and those keys are only protected by a very weak PIN code. Furthermore in order for an executives data to be "Recoverable" by the IT department, Bitlocker will also have a master key that can be used to decrypt everything.

So how important is keeping your data away from attackers? Something like bitlocker only protects against low level thieves, who are just going to format your device and sell it anyway. A determined attacker with resources will be able to acquire that master key or find a way to dump the contents of the TPM vault offline.

 

[Math Geek]

folks keep forgetting that the key is not only recoverable by IT depts, but is also uploaded to your MS account for users. so MS has your key and WILL hand it over to anyone who asks and claims to be with some random gov entity. for that reason alone, it is rather useless to anyone who actually cares about their data security. throw in the fact MS will use it for themselves as part of their data mining operations would be a very close second as to why you should go with a 3rd party disk encryption alternative.

any enterprise IT dept relying on this scheme should be fired and black listed from working anywhere but a car wash detailing tires!!

 

[snemarch]

Yes it's unfounded paranoia, especially if your not familiar with coding or how opensource works. There area rmies of people who pour over every inch of these code bases because finding vulnerabilities or back doors is major clout in that community. The first person to find something like that would instantly be famous and we'd all hear about it a few days later.

And this does happen every now and then, like with Debian's ssh key generation "oopsie" back in the day.

As for VeraCrypt, unlike a lot of open source projects, it went through an external audit – but there's claims the audit wasn't thorough enough (e.g. use of code analysis tools but not enough manual inspection), and the way TrueCrypt (which VeraCrypt is based on) was ended was... bizarre.

I personally do use VeraCrypt for some things (and LUKS for other scenarios) – and I wouldn't say that being mindful of project's history is "unfounded paranoia".

 

[palladin9479]

And this does happen every now and then, like with Debian's ssh key generation "oopsie" back in the day.

As for VeraCrypt, unlike a lot of open source projects, it went through an external audit – but there's claims the audit wasn't thorough enough (e.g. use of code analysis tools but not enough manual inspection), and the way TrueCrypt (which VeraCrypt is based on) was ended was... bizarre.

I personally do use VeraCrypt for some things (and LUKS for other scenarios) – and I wouldn't say that being mindful of project's history is "unfounded paranoia".

It's absolutely unfounded paranoia to inside there is a secret hidden government backdoor inside an opensource project that has had every line inspected by people just begging to become internet famous by being "the one" who found the backdoor. That is wearing tinfoil hats to protect against the government mind control rays level of paranoia. Most of the opensource projects in the world can have their origins traced back to WTF moments. Those moments are usually the entire reason the project forked or went the way it did in the first place.

 

[ingtar33]

Yep. 3900X still experiences issues.

that's not zen3.

 

[CmdrShepard]

The good news is that this flaw appears to be an issue regulated to discrete TPMs. If you have a CPU with a built-in TPM, like the ones in modern Intel and AMD CPUs, you should be safe from this security flaw since all TPM communication occurs within the CPU itself.

For now.

 

[CmdrShepard]

It's absolutely unfounded paranoia to inside there is a secret hidden government backdoor inside an opensource project that has had every line inspected by people just begging to become internet famous by being "the one" who found the backdoor.

Dual_EC_DRBG has entered the chat.

 

[snemarch]

It's absolutely unfounded paranoia to inside there is a secret hidden government backdoor inside an opensource project that has had every line inspected by people just begging to become internet famous by being "the one" who found the backdoor.

Claiming there's hidden government backdoors (without any smoking gun, like Dual_EC_DRBG) is tinfoil hat territory.

Being *mindful* of a project's history, current maintainer state, and what any audits have (and haven't!) covered isn't paranoia, it's due diligence. Please note that I'm not dunking on TrueCrypt, VeraCrypt or the open-source model in general – I have a lot of respect for all of those.

Software development is hard, security-focused development is even harder, and the "many eyeballs" is no *guarantee* that there's no exploitable bugs – sometimes it takes more than a decade before somebody stumbles on one of the nasties. So be mindful, and do the relevant level of threat modelling for your particular scenarios.

 

[palladin9479]

Dual_EC_DRBG has entered the chat.

Again more unfounded paranoia. That was a weak algorithm that a standards body insisted be present. There was no backdoor, no malicious implementation, just another version of DES or WEP.

Claiming there's hidden government backdoors (without any smoking gun, like Dual_EC_DRBG) is tinfoil hat territory.

Being *mindful* of a project's history, current maintainer state, and what any audits have (and haven't!) covered isn't paranoia, it's due diligence. Please note that I'm not dunking on TrueCrypt, VeraCrypt or the open-source model in general – I have a lot of respect for all of those.

Software development is hard, security-focused development is even harder, and the "many eyeballs" is no *guarantee* that there's no exploitable bugs – sometimes it takes more than a decade before somebody stumbles on one of the nasties. So be mindful, and do the relevant level of threat modelling for your particular scenarios.

So much wrong here...
It's impossible to prove a negative. Nobody is going to "prove" there isn't some secret worldwide cabal of evil government dudes who planted a backdoor into a piece of software you don't like. After all Toms could be in on it too, right now they are sending hacking AI powered nanobots over the internet through this web browser to take over your computer. Quick disconnect all your electricity, they can't get you then.

 

[snemarch]

Again more unfounded paranoia. That was a weak algorithm that a standards body insisted be present. There was no backdoor, no malicious implementation, just another version of DES or WEP.

No, the algorithm itself has backdoorable properties – this has been a known fact for a couple of decades. The Snowden leaks made it clear that this is almost guaranteed to be by design rather than mistake – that's about a decade ago by now. The Wikipedia article covers the issue pretty well, and you should note it's not tinfoil paranoiacs, but information from respectable people like Matthew Green and
Daniel J. Bernstein.

I think it's a bit unfair that Dual_EC_DRBG was brought into the discussion, as it's one of the clearest examples we have of in-the-open backdooring, and I don't personally believe the TC codebase was compromised. OTOH, it shows the lengths that natsec agencies will go to, so it's relevant for threat modelling.

So much wrong here...
It's impossible to prove a negative. Nobody is going to "prove" there isn't some secret worldwide cabal of evil government dudes who planted a backdoor into a piece of software you don't like. After all Toms could be in on it too, right now they are sending hacking AI powered nanobots over the internet through this web browser to take over your computer. Quick disconnect all your electricity, they can't get you then.

Hey, this is turning into quite a bit of a straw man.

Turning "you should critically evaluate the products you're using, and even without backdoors software development is hard and there's multiple instances of decade-spanning exploitable bugs" into "[...] secret worldwide cabal of evil government dudes [...]" is... a bit of a stretch 😅

 

[palladin9479]

No, the algorithm itself has backdoorable properties

No.

Crypto algorithms do not have code in them. It's not possible to have a "back door" because there is no code to present as an attack vector. Instead we call it a weak cipher, the fact that it's weakness was deliberate vs accidental makes no different. Backdoors are deliberate pieces of code that open a vector for an attacker to exploit a weakness in a security system.

The cipher itself wasn't a "back door", it was merely a cipher with an engineered weakness. A clumsy attempt by a government agency to bypass what they perceived as their greatest obstacle, strong encryption. That everyone knew about it and knew not to use it is the perfect example of how such weakness's are quickly discovered.

 

[snemarch]

Crypto algorithms do not have code in them. It's not possible to have a "back door" because there is no code to present as an attack vector. Instead we call it a weak cipher, the fact that it's weakness was deliberate vs accidental makes no different. Backdoors are deliberate pieces of code that open a vector for an attacker to exploit a weakness in a security system.

A cipher can be weak for several options, usually it's because of unintentional design flaws, or the field of cryptanalisys advancing.

I don't know which field you work in, but among the software developers and cryptographers I know, it's pretty uncontroversial that a backdoor isn't confined to a piece of malware planted on a server, or naughty lines of source code – it's any mechanism for gaining entry that subverts the normal authorization, usually by intentional design, but flaws can also be used for backdoor access. I'm not trying to do a full, pedantic, all-dictionary-entries definition here, but I don't know any software developers or security professionals who would disagree with this definition in the context of software/computer systems.

The Clipper system had a government backdoor from it's key escrowing design, while the Skipjack algorithm itself used by the system seemd to be sound. (I wonder if Clipper would have had any success if the US government hadn't been so blunt about the backdoor aspect).

The Dual_EC_DRBG algorithm has a backdoor by design – this is an uncontroversial fact. The Wikipedia entry has sources. Bruce Schneier's "The Strange Story of Dual_EC_DRBG" post has information. The Bernstein, Lange, and Niederhagen "Dual EC: A Standardized Back Door" paper is a good read, and so are Matthew Green's blog posts in the "Dual EC" category.

Heck, the backdoor is even part of the patent application – citing the "Dual EC: A Standardized Back Door" paper, so you don't have to taint yourself with reading patents:

The Canadian company Certicom (now part of Blackberry) has patents in mul-
tiple countries on
– Dual EC exploitation: the use of Dual EC for key escrow (i.e., for a deliberate
back door) and
– Dual EC escrow avoidance: modifying Dual EC to avoid key escrow.

You might disagree on the definition of "backdoor", which is fair. I've tried to explain what I understand by the term, but I won't split hairs if you want to use a more narrow definition – that might make sense in the contexts you operate in. But it's well-documented that Dual_EC_DRBG isn't just a "oh oops, we dun goofed" weak design, it has deliberate weaknesses, and NSA pushed hard for NIST to mandate it as a standard algorithm with provided curve parameters.

I realize the references above can be seen as appealing to authority, but the mentioned people are domain experts in the field of security 🤷‍♂️

 

[digitalgriffin]

No.

Crypto algorithms do not have code in them. It's not possible to have a "back door" because there is no code to present as an attack vector. Instead we call it a weak cipher, the fact that it's weakness was deliberate vs accidental makes no different. Backdoors are deliberate pieces of code that open a vector for an attacker to exploit a weakness in a security system.

The cipher itself wasn't a "back door", it was merely a cipher with an engineered weakness. A clumsy attempt by a government agency to bypass what they perceived as their greatest obstacle, strong encryption. That everyone knew about it and knew not to use it is the perfect example of how such weakness's are quickly discovered.

*sighs* yes and no.

Lets say this is your original message:
"This Is A Test Message"

And after encryption it's

"EGASSEm TSEt a Si SIHt"

Backdoor nope
Easy to decrypt: yep. And that could be by design.

A paper by the N S A about 10 years back wrote how the could reduce the number of potential encryption possibilities. It was written by a PhD Mathematician working for the N S A. Therefore, an intentionally poor written encryption might provide encryption like WEP. But the encryption math used might be intentional made to make it look strong, when it's actually weak.

Interestingly about 20 years back I wrote a note on a public forum talking how T O R / O N I O N relays asking if enough jump nodes fell into the hands of enemy actors, could the traffic be traced. This discussion became reality within a couple years as the gov't populated the network with nodes at a major university they controlled to reverse where traffic came from and where is went.

 

[snemarch]

@digitalgriffin : also keep in mind that Dual_EC_DRBG isn't an encryption cypher, it's a CSPRNG – Cryptographically Secure (😉) Random Number Generator... i.e. the kind you use when you "really need something like random static noise, but can't hook up a hardware radiation decay sensor" rather than "simulate a random dice roll in a game".

The TL;DR; story is that if Dual_EC_DRBG is used for the important random bits of TLS, an attacker that knows the secret curve parameters can deduce enough state that they'll be able to decrypt TLS sessions by sniffing just a few packets.

And that's the whole raison d'être of Dual_EC_DRBG – it's slow compared to other CSPRNGs, and doesn't even offer better randomicity.

 

[palladin9479]

Backdoor nope
Easy to decrypt: yep. And that could be by design.

Which is my point. Backdoors are deliberately pre-planted access methods that an attacker can exploit. Weak security implementations are not backdoors, they are just weak implementations. Avoid using weak implementations by sticking with well defined and tested ciphers coupled with opensource software. That combo will ensure that no attack vectors are opened systemically, now the user can always screw up with key management since the key is usually the weakest link in the chain.

Back to the topic at hand, the reason TPM implementations are weak is that the key is exposed via the recovery method provided to IT administrators. The goal behind this implementation is to provide token protection against opportunistic data theft. An adversarial actor with resources will be able to bypass it, frequently with something as simple as a piece of paper.

 

[digitalgriffin]

Which is my point. Backdoors are deliberately pre-planted access methods that an attacker can exploit. Weak security implementations are not backdoors, they are just weak implementations. Avoid using weak implementations by sticking with well defined and tested ciphers coupled with opensource software. That combo will ensure that no attack vectors are opened systemically, now the user can always screw up with key management since the key is usually the weakest link in the chain.

Back to the topic at hand, the reason TPM implementations are weak is that the key is exposed via the recovery method provided to IT administrators. The goal behind this implementation is to provide token protection against opportunistic data theft. An adversarial actor with resources will be able to bypass it, frequently with something as simple as a piece of paper.

Yes. I agree with both of you. But an intentionally KNOWN weak random number generator was stuck into the cypher, and this by definition is a backdoor. If you know ahead of time it's easy to decrypt, then you have created a back door.

Of course this will never be admitted to. (Culpabile deniability) But now the cat is out of the bag, the curve random # gen won't be used by professionals.

 

[TJ Hooker]

Back to the topic at hand, the reason TPM implementations are weak is that the key is exposed via the recovery method provided to IT administrators. The goal behind this implementation is to provide token protection against opportunistic data theft. An adversarial actor with resources will be able to bypass it, frequently with something as simple as a piece of paper.

This may be how TPM is used in office environments, but that doesn't mean it has to work that way. TPM can be used on personal devices, and isn't going to automatically send recovery keys to a 3rd party (or use keys already known by a 3rd party). Although I think bitlocker might automatically upload the recovery key to your MS account, not sure if that can be disabled, or what happens if you you enable bitlocker offline and/or without an MS account.

Not to say that a TPM can't be compromised by a motivated, well funded attacker. But it's not like they'll just have the recovery key on hand like your IT admin would for a corporate machine.

I imagine you understand all this, but others reading may not.

 

[digitalgriffin]

This may be how TPM is used in office environments, but that doesn't mean it has to work that way. TPM can be used on personal devices, and isn't going to automatically send recovery keys to a 3rd party (or use keys already known by a 3rd party). Although I think bitlocker might automatically upload the recovery key to your MS account, not sure if that can be disabled, or what happens if you you enable bitlocker offline and/or without an MS account.

Not to say that a TPM can't be compromised by a motivated, well funded attacker. But it's not like they'll just have the recovery key on hand like your IT admin would for a corporate machine.

I imagine you understand all this, but others reading may not.

That's why you always bypass your MS account. Thankfully there are still backdoor ways of doing this when installing windows. Then make everything else local accounts with non-admin priv

View: https://www.youtube.com/watch?v=VU9L0udNV9M&pp=ygUdZGlzYWJsZSB3aW5kb3dzIDExIHRlbGVtZXRyeSA%3D

 

[CmdrShepard]

Again more unfounded paranoia. That was a weak algorithm that a standards body insisted be present. There was no backdoor, no malicious implementation, just another version of DES or WEP.

Did you even read the wiki article I linked?

In September 2013, The New York Times reported that internal NSA memos leaked by Edward Snowden indicated that the NSA had worked during the standardization process to eventually become the sole editor of the Dual_EC_DRBG standard, and concluded that the Dual_EC_DRBG standard did indeed contain a backdoor for the NSA. In response, NIST stated that "NIST would not deliberately weaken a cryptographic standard", but according to the New York Times story, the NSA had been spending $250 million per year to insert backdoors in software and hardware as part of the Bullrun program.

Emphasis added by me -- there's no paranoia. It has been proven.

NIST response that amounts to "it's just an honest mistake y'all" is particularily telling unless you somehow can make yourself believe that people who are supposed to set such critical tech infrastructure standards can be so incompetent, in which case I have a bridge to sell you.

The cipher itself wasn't a "back door", it was merely a cipher with an engineered weakness. A clumsy attempt by a government agency to bypass what they perceived as their greatest obstacle, strong encryption. That everyone knew about it and knew not to use it is the perfect example of how such weakness's are quickly discovered.

"Your honor, we haven't broken into defendant's apartment to conduct illegal search without a warrant, we merely used a door lock with an engineered weakness which we previously trojan-horsed into a national door lock standard to get in."

Try that defense in court, see if it works.

Look, it's even listed under List of known backdoors so no, you are wrong on that too.

I'd advise you to drop the shovel and stop digging yourself deeper into this particular hole.