[HN Gopher] Breaking Bitlocker - Bypassing the Windows Disk Encr...
       ___________________________________________________________________
        
       Breaking Bitlocker - Bypassing the Windows Disk Encryption [video]
        
       Author : tkems
       Score  : 35 points
       Date   : 2024-02-03 18:36 UTC (4 hours ago)
        
 (HTM) web link (www.youtube.com)
 (TXT) w3m dump (www.youtube.com)
        
       | aquova wrote:
       | Very interesting video. For those who can't watch, he creates a
       | PCB with a RPi Pico and some data pins which can sniff the
       | BitLocker key as it's sent from the TPM chip back to the CPU. I
       | was surprised to see that this was sent in plaintext, so although
       | his board probably will only work for that particular
       | motherboard, the method would be sound for other computers as
       | well.
       | 
       | I'll leave the comments about MS requiring TPM chips for Win11 to
       | others.
        
         | ghostpepper wrote:
         | It's a bit of a chicken-egg problem when the TPM is the root of
         | trust for the entire system. Sure you can encrypt the data on
         | the bus, but where do you store that key?
        
           | mjg59 wrote:
           | You don't need to store that key anywhere, just like you
           | don't need to store any keys to validate TLS connections.
        
           | northern-lights wrote:
           | TPM can always store the (root) private key inside the TPM,
           | but where will the other side of the channel (CPU, HD etc.)
           | store their private key?
        
           | H8crilA wrote:
           | You use a Diffie-Hellman key exchange, signed by a cert
           | stored in the CPU on one side and verified by the TPM on the
           | other. CPUs already have such secret certs inside of them,
           | for example for Intels' SGX.
           | 
           | But as you can read in the article linked by /u/osy, the TPM
           | ecosystem is a victim of design by committee where such
           | things as a threat model are not a thing. They were focused
           | on building a "generic security solution" or some other
           | nonsense, instead of making a threat model, then a protocol,
           | then a verification of the protocol under the threat model -
           | like people did for example with TLS 1.3.
        
           | briHass wrote:
           | Exactly. An attacker that has full access to the device can
           | get past encrypted TPM parameters, it would just slow them
           | down. The best method is pre-boot auth where the TPM itself
           | requires a PIN to release the keys. Windows doesn't use that
           | by default, but it can be enabled.
        
         | p_l wrote:
         | TPM 2.0 provides encrypted sessions specifically to handle this
         | problem.
         | 
         | Of course you need to first use them...
        
       | matsz wrote:
       | This is particularly interesting considering that TrueCrypt
       | recommended migration to BitLocker as the main option for
       | Windows: https://truecrypt.sourceforge.net/
       | 
       | IIRC Apple's version of TPM (Secure Enclave) should be immune to
       | such attacks (since it's on the SoC, but I'm not sure whether the
       | communication is encrypted or not), and the main data encryption
       | method for GNU/Linux (LUKS) does not utilize TPM by default
       | (might depend on distro though).
       | 
       | EDIT: I believe that the method in the video only works for
       | volumes that aren't password/PIN-protected.
        
         | dist-epoch wrote:
         | If you worry about someone sniffing your hardware buses, you
         | should also worry about them intercepting your keyboard
         | connection when you type the TrueCrypt password.
        
           | 0cf8612b2e1e wrote:
           | Does seem laughably easy to intercept the keyboard
           | connection.
        
         | p_l wrote:
         | TPM 2.0 supports encrypted sessions, which block this kind of
         | attack (TPM 2.0 is wholly different beast than TPM 1.x series).
         | 
         | I do not recall if cryptsetup's TPM2 support sets up encrypted
         | session, but for BitLocker just setting it to require PIN
         | breaks this attack (the PIN is used as part of TPM policy
         | preventing automatic decryption).
         | 
         | Additionally, some laptops at the very least _attempt_ to erase
         | TPM on case open.
        
       | bugbuddy wrote:
       | I predict that this will necessitate an upgrade to TPM 3.0 with a
       | key exchange handshake mitigation along with it being a
       | requirement to upgrade to Windows 12. That's fine though because
       | it will help with economic growth and all the relevant companies'
       | bottom lines.
        
         | p_l wrote:
         | TPM2 already has encrypted session support which does exactly
         | that.
        
       | linarism wrote:
       | Worth noting that modern AMD CPUs incorporate the TPM
       | functionality in the CPU itself, not sure about Intel.
        
         | Kluggy wrote:
         | AMD calls it fTPM (Firmware TPM I believe) and Intel calls it
         | PTT (Platform Trust Technology)
        
         | dist-epoch wrote:
         | The most recent AMD CPUs, Zen4 also incorporate Pluton, the TPM
         | designed by Microsoft based on Xbox security experience.
        
           | Arnavion wrote:
           | Also given AMD's repeated bungling of the fTPM, Pluton is
           | probably the better option if you must enable one.
        
       | jsmith99 wrote:
       | Nothing new. This attack is demonstrated here many times and the
       | Microsoft docs discuss a similar attack using self encrypting
       | drives. The counter measure is to use a virtual TPM built into
       | the CPU or to use TPM+PIN (which is standard practice for
       | security).
        
         | p_l wrote:
         | Another piece is to use encrypted session where the traffic
         | between OS and TPM is encrypted as well.
        
       | osy wrote:
       | TPM is insecure against physical attacks by design:
       | https://gist.github.com/osy/45e612345376a65c56d0678834535166
       | 
       | The only secure implementation is called D-RTM which requires a
       | level of chip, OEM, and OS support that's not done in practice.
        
         | mike_hock wrote:
         | I hope this attempt at shoving hardware DRM down our throats
         | tanks just like the last one did.
        
           | p_l wrote:
           | It's not actually used for DRM, that's part of Intel ME and
           | why AMD PSP is closed source. Both of those are involved in
           | setting up "protected media path" which is all about setting
           | up encrypted channel between display and media player to
           | prevent sniffing.
           | 
           | TPM could be used for DRM in the sense that DRM software
           | could refuse to run on system that isn't approved, but it's
           | not going to stop you from enjoying a DRM free system - in
           | fact it can help by explicitly supporting clearing of TPM
           | state by owner.
        
         | shawnz wrote:
         | Having a non-zero attack surface doesn't mean your security
         | system provides "zero practical security". This is at best
         | equally as hyperbolic as the vendors' own marketing claims that
         | you are arguing against.
        
         | mjg59 wrote:
         | Not really? Encrypted sessions block the trivial attack of just
         | watching the secret go across the bus. Pushing people to MITM
         | attacks is already an improvement, and while generating initial
         | trust in the TPM for that purpose isn't straightforward, it's
         | not impossible. The almost universal _implementation_ of TPM-
         | backed secret management isn 't secure against physical attack,
         | but that's very different to "insecure by design". All the
         | primitives to make this work reasonably are there, OS and
         | firmware vendors just aren't using them.
        
           | Arnavion wrote:
           | >All the primitives to make this work reasonably are there,
           | OS and firmware vendors just aren't using them.
           | 
           | To be precise, both Windows (according to the article) and
           | Linux+systemd (since systemd v251) support letting the user
           | specify a TPM PIN and then use parameter encryption. But yes,
           | both make it optional.
        
         | northern-lights wrote:
         | There is nothing that is safe against physical attacks
         | practically. You can always find a point where you can do a
         | MITM attack as the communication channels between the TPM and
         | anything else is almost always insecure.
        
           | FirmwareBurner wrote:
           | _> There is nothing that is safe against physical attacks
           | practically._
           | 
           | This! If security is your prime directive in your line of
           | work(government, highly sensitive data, etc), then as long as
           | your device has been outside your physical possession and in
           | the hands of an untrusted third party, then it's
           | automatically considered compromised and gets wiped or
           | discarded by your IT department.
           | 
           | Because no amount of marketing security fluff from Microsoft,
           | Apple, Google can stand against targeted attacks of state
           | actors or knowledgeable motivated well funded actors with
           | freshly acquired zero days.
           | 
           | The security they provide is only good enough against the
           | average thief off the street, which I guess covers 98% of
           | Average Joe's threats.
           | 
           | Even CC security certifications never judge a device whether
           | it's hackable or not, but only on how long it takes for it to
           | be hacked by an accredited lab, because nothing with outside
           | physical access is ever unbackable. With enough time and six
           | figure equipment off the publicly available commercial
           | market, everything reveals its secrets eventually. And that's
           | without zero days off the black market.
        
             | Terr_ wrote:
             | Also, physical security is sometimes the best thing because
             | it maps well to all of our human intuitions and senses for
             | enforcing it and detecting when it was violated.
        
       | whyoh wrote:
       | To decrypt a drive with a _TPM-only_ key you just need to _turn
       | on the PC_. So what 's the big deal here?
       | 
       | It's disappointing that TPM-only is the _default_ for Bitlocker,
       | but you can just use something else (pin /password, key file,
       | ...).
        
         | shawnz wrote:
         | These kinds of attacks aside, the intent is that you need to
         | turn on the PC and then actually boot to the intended operating
         | system, which is then protected with a login screen
        
           | ale42 wrote:
           | Except that if you can sniff the encryption keys, you can
           | tamper with the OS and for example remove the password...
        
             | shawnz wrote:
             | That's why I caveated my explanation with "these kinds of
             | attacks aside": this video describes such a bus sniffing
             | attack
        
           | whyoh wrote:
           | Yeah fair enough. The login screen should still provide good
           | protection in a TPM-only scenario. (Although it had some
           | vulnerabilities in the past:
           | https://secret.club/2021/01/15/bitlocker-bypass.html)
        
       | briHass wrote:
       | No big deal here. This attack looks like it's using a crusty old
       | TPM 1.2 laptop, so encrypted parameters to the TPM aren't
       | supported. Even with Win11 and TPM2.0 (required for Win11),
       | encrypted parameters to the TPM would just slow down an attacker.
       | 
       | You need to use pre-boot auth, like a PIN. Obviously, the TPM
       | needs to have some kind of authentication to release the key, not
       | just the default mode where Windows just needs to request it.
       | This is all outlined in MS documentation:
       | https://learn.microsoft.com/en-us/windows/security/operating...
        
       | jpalomaki wrote:
       | Does Microsoft Pluton [1] help here? I noticed at least some
       | recent ThinkPad AMD models support it.
       | 
       | [1] https://learn.microsoft.com/en-
       | us/windows/security/hardware-...
        
       ___________________________________________________________________
       (page generated 2024-02-03 23:00 UTC)