[HN Gopher] Dumping Memory to Bypass BitLocker on Windows 11
___________________________________________________________________
Dumping Memory to Bypass BitLocker on Windows 11
Author : supermatou
Score : 120 points
Date : 2024-12-30 18:43 UTC (4 hours ago)
(HTM) web link (noinitrd.github.io)
(TXT) w3m dump (noinitrd.github.io)
| tnetenbaa wrote:
| BitLocker is crazy easy to bypass if you have physical access to
| the device. I work IT, and had to demonstrate to our head of
| security, that if you just pop in a Linux USB and boot from it,
| the drive is completely open.
| Grazester wrote:
| Then the drive wasn't encrypted!
| connicpu wrote:
| Presumably they chose the weakest option where it can boot
| without a pin/password just using a key stored in the TPM.
| dogma1138 wrote:
| Even if you are using Transparent Operation Mode then it
| still will not work as bitlocker will not decrypt the drive
| and lock itself into recovery mode if you make changes to
| the boot order or any other BIOS / UEFI changes.
|
| It uses secure boot and it's pretty darn decent at
| detecting any form of tampering.
|
| TPM 2.0 isn't particularly resilient against physical key
| extraction attacks but believe it or Microsoft did threat
| model this...
| BuyMyBitcoins wrote:
| This happened to me once. Sadly I had wiped the flash
| drive containing the recovery key months before the
| lockout without realizing it. Chide me if you must, but I
| certainly learned my lesson.
|
| I tried a few non-hardware exploits, even CVE-2022-41099
| about WinRE but to no avail.
|
| I'm not a security pro, but I assume once it is in
| recovery mode lockout you're pretty much out of luck.
| From what I can tell most other exploits require it to be
| unlocked in the first place. Even the hardware hacks seem
| to require a drive being in a non-lockdown state in order
| to sniff things during boot.
|
| That NVMe drive is just a keepsake now. I plan to frame
| it and put it on my wall as a memento.
| dogma1138 wrote:
| This is why i use the key backup to OneDrive option.
|
| My threat model is a lost or stolen device or RMA/repair.
|
| If someone wants my data so badly that they'll be able
| get into my OneDrive account that is protected with a
| passkey or a 32 char password + MFA and also have
| physical access to my devices let them have it.
|
| Anyone who is that determined and capable can always
| resort to rubber hose cryptography and I want none of
| that in my life.
| dogma1138 wrote:
| You should've enabled bitlocker first then...
|
| The only thing that would be unencrypted is the system restore
| partition.
| simondanerd wrote:
| Correct, ran into this last night. Dislocker works though:
| https://github.com/Aorimn/dislocker
| dogma1138 wrote:
| Dislocker does require you to have the keys tho it's not a
| bypass.
| davemtl wrote:
| This sounds like BitLocker wasn't enabled on the drive. All of
| the laptops I've deployed with BitLocker are very good at
| detecting tampering and will immediately go into lockdown mode.
| A Linux USB most likely requires Secure Boot to be turned off
| to boot, if so, the TPM tamper will trigger and BitLocker will
| require the recovery key at next boot.
| 3eb7988a1663 wrote:
| What was the hardware on which this was running? I thought DDR5
| would be more resistant to this type of RAM attack.
| Arnavion wrote:
| This is not "attacking" RAM. A UEFI binary (or Linux kernel in
| the CCC demo which uses a different method to retain the key in
| memory) already has access to all the extents of physical
| memory. It just has to search it for the scribble leftover from
| the bootloader.
|
| See https://github.com/NoInitRD/Memory-Dump-
| UEFI/blob/db4888dc05... and onwards.
|
| Edit: Ah, I guess you're referring to the fact that the reboot
| preserves RAM contents? DDR5 doesn't change anything about that
| AFAIK.
| dogma1138 wrote:
| Indeed, however it should be noted that this is only a single
| attempt attack and which will trigger the tamper protection.
|
| Changing the boot order, making changes to the BIOS or
| booting from an unsigned bootloader would trigger a bitlocker
| lockout.
|
| This means that if you don't get the keys on the first
| attempt you can't just pass the machine back to the user and
| try again later since the next time it will boot it would
| boot into bitlocker recovery.
|
| And even if the attack is successful the user will still be
| aware that something did happen so you are still better off
| with other physical attacks if they are still possible.
| mjg59 wrote:
| Why? You're not booting Windows again, and restoring the
| secure boot state and boot order to the original values
| will result in the PCR values being what they were before,
| so what's changing that would force recovery mode?
| dogma1138 wrote:
| The TPM tracks the state of the secure boot and the bios,
| that log is stored in the TPM itself the next time you'll
| try to boot into windows it will see that something
| happened and bitlocker will lock itself out.
|
| Do this experiment.
|
| Boot into any Linux live CD on a machine with bitlocker
| enabled.
|
| Reboot and see what happens.
| mjg59 wrote:
| No, the TPM doesn't retain PCR measurements over reboots,
| and the log (rather than the composite PCR value) is
| handled by the firmware and the OS and the TPM has no
| idea it exists.
| vel0city wrote:
| I did that last night. It didn't have any issues booting
| back into Windows after booting to a live USB.
|
| I didn't change any parameters of the Windows boot option
| or the rest of the system.
| MoreMoore wrote:
| It doesn't matter if you change the settings back. I
| don't know how it works, but something non-user
| configurable is changed that prompts Windows to require a
| reset of the TPM keys.
| mjg59 wrote:
| This is entirely defeated by
| https://trustedcomputinggroup.org/resource/pc-client-work-gr... -
| if enabled, if the OS isn't cleanly shut down (giving it an
| opportunity to wipe encryption keys) the firmware will pause to
| wipe RAM before booting anything else on next boot. Does Windows
| not make use of this, or did the tested system not implement it?
| cyberax wrote:
| This still won't prevent yoinking the entire RAM modules and
| dumping them offline.
|
| Ideally, the keys should just remain inside the SRAM cache on
| the CPU, never even going outside of the CPU die.
| bangaladore wrote:
| > This still won't prevent yoinking the entire RAM modules
| and dumping them offline.
|
| Theoretically no, but realistically I doubt even intel
| agencies can pull this off.
|
| > Ideally, the keys should just remain inside the SRAM cache
| on the CPU, never even going outside of the CPU die.
|
| The real solution is putting the keys somewhere with a
| guarantee they will be gone prior to possibly executing
| untrusted code. In my mind the only real solution is UEFI
| APIs to support this (or wiping the ram as shown here). But
| then you have to trust the UEFI vendors which don't exactly
| have stellar track records.
| bri3d wrote:
| > Theoretically no, but realistically I doubt even intel
| agencies can pull this off.
|
| For older LPDDR3 it's completely practical, see
| https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely
| gets harder with newer systems, though.
|
| > In my mind the only real solution is UEFI APIs to support
| this (or wiping the ram as shown here). But then you have
| to trust the UEFI vendors which don't exactly have stellar
| track records.
|
| This already exists: it's the MOR bit and it's supposed to
| be in play here.
|
| I actually think that having a CPU scratchpad key area
| which is guaranteed to be wiped across any reset action is
| a much better idea than trusting any dumpster fire UEFI
| implementation of anything, ever. At least you're trusting
| a few CPU vendors with something you can audit that way,
| rather than a million different cobbled-together junky
| firmware blobs.
| bangaladore wrote:
| > I actually think that having a CPU scratchpad key area
| which is guaranteed to be wiped across any reset action
| is a much better idea than trusting any dumpster fire
| UEFI implementation of anything, ever. At least you're
| trusting a few CPU vendors with something you can audit
| that way, rather than a million different cobbled-
| together junky firmware blobs.
|
| True. Given that the CPU is what's resetting and running
| the UEFI code, you better hope it could recognize and
| clear a scratchpad reliably.
| zebra_bong3 wrote:
| The issue is that any memory readable by a software directly
| has some kind of risks, including SRAM. Here is something
| something you might find interesting: https://forte-
| research.com/UnTrustZone/ There is no absolute security, but
| keeping secure memory away from software provides much better
| solution.
| mjg59 wrote:
| Just have the CPU microcode clear SRAM whenever the CPU is
| booted
| bri3d wrote:
| Purportedly Windows makes use of this, FWIW:
| https://learn.microsoft.com/en-us/windows/security/operating...
|
| "BitLocker uses the TCG Reset Attack Mitigation, also known as
| MOR bit (Memory Overwrite Request), before extracting keys into
| memory."
|
| I would extremely not trust most platform implementation of TCG
| Reset Attack Mitigation, though. I've never seen a UEFI
| platform that is even close to correctly implemented in any
| form. It would be interesting to know which platform this
| researcher was working with, and whether it purports to support
| the MOR bit or not.
| bangaladore wrote:
| > "BitLocker uses the TCG Reset Attack Mitigation, also known
| as MOR bit (Memory Overwrite Request), before extracting keys
| into memory."
|
| (Edit: No this is a UEFI request to clear memory. Below is
| incorrect.)
|
| I don't think this is what the commenter was mentioning. I
| think this essentially makes it only possible to extract the
| key from the TPM once and then the TPM needs to be powered
| off and back on to get it again.
|
| The TPM has no control over whats in the system memory, so if
| they key is in system memory, no TPM mitigations are going to
| help.
|
| UEFI firmware must support clearing the keys from RAM.
| mjg59 wrote:
| This is exactly what I was mentioning. Despite being a TCG
| spec, it's implemented in firmware and has no hard
| requirement on a TPM at all.
| bangaladore wrote:
| Okay, thanks for the correction.
|
| The naming there is definitely confusing. Particularly as
| it sounds like a key attribute bit.
| arghwhat wrote:
| That's a very stupid mitigation as you can mess with RAM during
| the overwrite. Heck, see how Team Tweezers originally exploited
| the Wii.
|
| The real mitigation is the memory encryption feature of modern
| CPUs. Being on-die means tweezers won't reach, and being just a
| key means the wipe is instant and very difficult to mess with
| even if it survived a power cycle.
| mjg59 wrote:
| It would entirely prevent the described attack. Related
| attacks may still be possible, but are also significantly
| harder than simply booting off USB.
| bri3d wrote:
| After reading the article again, I think this might be an
| actual interesting Windows vulnerability - rather than a
| platform issue with MOR, I think this might be bad Windows
| code where the key is left over in places that aren't
| protected by MOR. It's quite unclear the more I think about
| it what's going on here, and the article lacks detail.
|
| I'm surprised given that the article mentions stepping into
| the boot process and `SymCryptSessionDestroy` that they
| didn't look more deeply into this; it's not how I really
| intended to spend my new years but I might have a new
| debugging project now...
| jandrese wrote:
| Fundamentally I don't understand BitLocker's security model. In
| most installs it seems like you power on the machine by pressing
| the power button and it boots into Windows.
|
| So if someone steals you machine with an encrypted hard drive
| they need to...just turn it on? That can't be right, but at the
| same time I have no idea how this particular attack is defeated.
| I have to assume the traffic over the SPI bus is encrypted so the
| key can't just be dumped like that, but it seems like the machine
| is going to give up the key pretty easily regardless.
|
| With LUKS it at least has a password prompt to unlock the drive.
| bri3d wrote:
| > I have to assume the traffic over the SPI bus is encrypted so
| the key can't just be dumped like that
|
| It's not. For some reason, Microsoft don't use TPM parameter
| encryption, even though every year or two some security
| researcher or another comes up with another stunt TPM-sniffing
| device to parade around.
|
| > With LUKS it at least has a password prompt to unlock the
| drive.
|
| Configuration dependent. You can set up Linux to do the same
| thing as Windows here (I have my home video-security server set
| up this way, as it needs to reboot silently - I know that I'm
| vulnerable to warm/coldboot attack and software attack surface,
| but at least if someone yoinks the drive I'm safe), and Windows
| can also be configured to prompt for a password or use PIN-
| authenticated TPM sealed keys.
|
| > Fundamentally I don't understand BitLocker's security model.
|
| Minus the parameter encryption / bus-sniffing issue, it moves
| the boundary from "anyone can read your drive" to "someone
| needs to either perform a platform-level attack to access the
| contents of memory, or hack whatever services are running at
| the login screen to read your drive." It's a decent security
| improvement, actually, because it protects very well against
| stuff like "someone stole our financial data off of a random
| recycled hard drive."
| raron wrote:
| > It's not. For some reason, Microsoft don't use TPM
| parameter encryption, even though every year or two some
| security researcher or another comes up with another stunt
| TPM-sniffing device to parade around.
|
| AFAIK it is useless, there is no way the TPM could
| authenticate the CPU. You could always desolder the TPM chip,
| send the correct data for updating PCRs and get the sealed
| key.
| bri3d wrote:
| It's one of those "useless in theory but extremely
| meaningful in practicality" things, IMO. Getting the
| correct PCRs is going to be a whole lot harder than putting
| a sniffer on the LPC. It takes the attack from something
| that random TikTok security "influencers" sell devices for
| to something which requires meaningful effort.
| raron wrote:
| Using Bitlocker with a PIN solves that.
|
| Anyways on many modern system the TPM is often just part
| of the firmware running on a secure part of the CPU and
| probing the signals in the chip is probably outsider of
| the budget of TikTok influencers.
| bri3d wrote:
| > Using Bitlocker with a PIN solves that.
|
| At an enormous cost of having to remember and enter a PIN
| - not practical for corporate IT due to the propensity
| for forgetting and not practical for offline server use.
|
| > Anyways on many modern system the TPM is often just
| part of the firmware running on a secure part of the CPU
|
| On AMD this is almost 100% prevalent, yes.
|
| On Intel platforms a physical TPM is still common and PTT
| (firmware TPM) is usually disabled by default for some
| reason - a user/manager would usually have to re-select
| it in the BIOS. On desktop platforms I think PTT runs
| externally in the PCH, too, which is off-package and
| connected over DMI (I think on most mobile parts PCH is a
| separate on-package die). I don't think anyone has done
| research on how the fTPM part of PCH <-> CPU comms work
| on modern Intel platforms; this has always seemed like a
| fun topic for a deep dive and talk to me, but I've never
| had the time.
|
| I don't think either of these things excuses the lack of
| encrypted parameter support from BitLocker, though. I'd
| love to know why Microsoft continue not to use it. The
| only reason I've ever seen given is "it was deemed too
| complex / has an attack surface," which is an interesting
| idea but quite bunk when UEFI is already in the picture
| IMO.
| p_ing wrote:
| The Intel PCH is on-package exposed via [DMI] PCIe lane
| while AMD's fTPM is on-die.
|
| It would be unusual for any current device to have a
| discrete TPM, at least in the consumer space given
| current x86 processors have an fTPM.
| tremon wrote:
| That's the same kind of useless as "I don't have a front
| door. You could always drive through it with your car and
| get inside that way", right?
| sebazzz wrote:
| > So if someone steals you machine with an encrypted hard drive
| they need to...just turn it on? That can't be right, but at the
| same time I have no idea how this particular attack is
| defeated.
|
| Yes, but the idea is that from the login screen (winlogon) you
| really can't do much unless you actually have account
| credentials on the computer - or are bio-metrically enrolled
| into the computer* - and if you attempt to reboot to safe mode,
| or reboot to a different OS (or firmware update utility, etc)
| you do need to enter the Bitlocker recovery key.
|
| * I'm not sure how it works in terms of "hacking" fingerprint
| sensors or face recognition webcams.
| rzzzt wrote:
| You also can't look at the encrypted drive's contents if you
| connect it to a different machine.
| bangaladore wrote:
| The primary purpose of Bitlocker (when used with a PIN + TPM)
| is it makes a powered off computer or a drive itself as good as
| a brick. Assuming the TPM doesn't have any key extraction
| vulnerabilities.
|
| Keyword is powered off.
|
| With any general purpose drive encryption, the TPM doesn't
| actually decrypt the bulk of the data as its too slow so the OS
| eventually ends up with a key that is extractable.
| rzzzt wrote:
| BitLocker volumes can have multiple protectors; you can use a
| key file, a passphrase, PIN or TPM storage:
| https://learn.microsoft.com/en-us/windows-server/administrat...
|
| In Pro editions it is also possible to require an interactive
| step at boot time via group policy (this also works if you have
| no TPM available), then it will ask for a password on each
| startup.
| tonetegeatinst wrote:
| While I am aware of bitlocker in general, I don't have a full
| grasp of it. Just how secure is it from a software of
| hardware attack?
|
| It was my understanding that veracrypt was considered more
| tested than bitlocker due to the lack of backdoors or
| workarounds. Can anoyone point me at some good resources
| regarding this?
| mjg59 wrote:
| It depends on the mode you're using. If you use the
| transparent unlock functionality (the default) then it's
| vulnerable to hardware key extraction. If you use anything
| else (PIN, password, whatever) then I'm not aware of any
| weaknesses or workarounds. I'm certainly not aware of any
| backdoors.
| buran77 wrote:
| > With LUKS it at least has a password prompt to unlock the
| drive.
|
| BitLocker should ideally be used with a PIN/password too. This
| means the key isn't decrypted until the correct PIN is entered.
| No SPI sniffing, UEFI exploits, or memory dump would help the
| attacker in this preboot state. BitLocker with TPM and PIN is a
| pretty powerful combination.
|
| But by default, without any second factor, BitLocker is two
| parts convenience and one part security. Probably the price of
| user adoption.
| jeroenhd wrote:
| > So if someone steals you machine with an encrypted hard drive
| they need to...just turn it on?
|
| That'd bring them to a login screen. Without your password or
| biometrics, they're not getting past that. They'll have to
| figure out some kind of workaround (like a RCE exploit, or
| booting an old, vulnerable Windows bootloader somehow) because
| they can't do the usual "replace the software keyboard with
| cmd.exe" workaround as the drive remains locked.
|
| Without Bitlocker, you can plug a Windows drive into your PC
| and browse all the files. With Bitlocker, you need to faff
| about with exploits and vulnerable Microsoft software and
| dumped memory, and even that doesn't always work.
|
| With Bitlocker configured in TPM+PIN mode, you can't even do
| that, as you don't have the password to unlock the TPM. You
| could also put Bitlocker in password-only mode, but that's much
| easier to brute-force. Same goes for LUKS, by the way, which
| also supports TPM and TPM+PIN in most Linux distros these days.
| maxo133 wrote:
| Too bad the author did not provide hardware specs. Such attack is
| even harder on DDR4 and DDR5 memory and most publications refer
| to legacy ram such as DDR3
|
| > In my experience I have had the most success restarting the
| system while Windows is loading but before the login screen has
| appeared, at least in the case of finding FVEK keys.
|
| So what is this? It was supposed to be memory attack and he's
| dumping the keys after someone unlocked it and it's booting?
|
| So this is just another theoretical attack where perfect
| conditions must be met.
| bri3d wrote:
| This attack has nothing to do with the memory type; memory is
| never made cold or allowed to decay. The system is hot-
| restarted into UEFI. Ideally no memory refreshes are skipped.
|
| I do wish they provided the hardware specs too, though, as this
| reflects an incorrect UEFI platform implementation of MOR.
| maxo133 wrote:
| You are right, but i still have no idea what is the point of
| this article.
|
| The guy unlocked the bitlocker, then restarted PC just before
| login screen appeared. He said that's when he had most
| success. What sense does it make to restart and start looking
| for key in memory, when bitlocker has been just unlocked.
| bri3d wrote:
| > What sense does it make to restart when bitlocker has
| been just unlocked.
|
| You steal a laptop. You turn on the laptop. You reboot it
| into UEFI and steal the keys. This is bad for BitLocker.
| Ideally this is not possible because the MOR bit should
| cause the keys to be erased by the platform initialization
| before boot-from-USB is possible.
| mjg59 wrote:
| I steal your Windows laptop. I want your data. I don't have
| your credentials, so can't login to Windows. I let your
| laptop boot to the point where Bitlocker is automatically
| unlocked, perform a hard reboot, dump the RAM, extract the
| keys, and can now decrypt your drive and extract your data.
| watermelon0 wrote:
| Bitlocker is unlocked before you reach the login screen.
|
| If I understand correctly, you need to start the PC, reboot
| just before the login screen appears, and boot to an USB
| application, which will copy the memory content.
| tsimionescu wrote:
| You seem to think it's common to require a separate BitLocker
| unlock step. In reality, this is extremely rare: the vast
| majority of users have no idea about any of this and have
| BitLocker set to automatically unlock during system power on.
|
| So this is a viable attack on many, many real-world systems.
| Adding a BitLocker password/PIN is a mitigation that prevents
| this attack.
|
| Note that BitLocker is still very useful even in this mode: it
| guarantees that someone who steals your laptop can't just
| connect the disk to another system and read everything on it,
| unless they can actually extract the keys from RAM, or bypass
| Windows authentication - this attack allows them to do the
| former relatively easily.
| jansommer wrote:
| I think you get the biggest advantage from BitLocker when you use
| TPM (PCR 7+11) with a PIN. That should mitigate the exploit
| because the FVEK should never be read without the PIN, and if
| BitLocker does it right (which I think it does) too many wrong
| PIN's results in the TPM going into dictionary attack lockout
| mode.
|
| Now I've been trying for months to do the same for Linux. There's
| systemd-cryptsetup/cryptenroll, but it's only for LUKS and I'm
| trying to encrypt a few sensitive directories on a super slow
| internal eMMC with fscrypt (keys for secure boot and /home). The
| TPM is _EXTREMELY_ hard to code for when things go beyond the
| basics:
|
| 1. Bind to PCR 7
|
| 2. Bind to changing PCR 11 (changes whenever the kernel, init,
| cmdline etc. is updated)
|
| 3. Use a PIN - but not the AuthValue, because I want to use the
| same authorization policy for resetting the DA lockout counter on
| login, and also have a long password/AuthValue for resetting the
| counter manually.
|
| 4. Make it all work with PCR 11 signatures and public keys
| provided by systemd-stub.
|
| Maybe this isn't the right place to ask, but there's almost
| nothing but basic TPM guides out there, so if you're an expert I
| could really use your help. It's just for a personal project, but
| I'll write about it once I'm done - if I ever figure it out!
| varispeed wrote:
| Isn't TPM just a honeypot of sorts? It seems strange to me that
| after successful open source encryption software, there was a
| shift to TPM, like you'll have a notion of super secure storage
| provided by big corporations and you should just not worry
| about it and not question.
|
| Surely there must be a backdoor access for three letter
| agencies to just download all the pins and passwords and then
| take a dip in the data, no worries.
| jansommer wrote:
| Should be good enough for a personal tablet used for mail and
| browsing. If I drop it and someone curious finds it, I'd like
| to make it impossible for them to extract anything useful.
| cheschire wrote:
| I prefer to think of TPM as equivalent to the chip in a smart
| card.
| eddythompson80 wrote:
| I encourage you to read what a TPM is. A TPM isn't an
| "encryption" software/hardware. It's completely orthogonal to
| "successful open source encryption software".
|
| "successful open source encryption software" don't solve the
| main usability problem with encryption: "Where do I store my
| super secure 4096-bit private key so it's both secure and
| convenient to use"
| jeroenhd wrote:
| I don't see why a TPM couldn't be open? Nobody makes open-
| source TPMs (because they're put inside CPUs or attached to
| motherboards with specific pins and protocols) but in
| theory you could just do it. All you need to do is make
| sure any secrets stored get wiped permanently whenever you
| flash new firmware.
|
| It'd be similar to secure boot: usable by default, but
| reconfigurable so that you can bring your own keys and
| signatures, putting you in complete control of your
| hardware, to the point where even the manufacturer no
| longer has a say in what's running and what isn't.
| eddythompson80 wrote:
| You can make your own HSM using a raspberry pi pico
| https://www.picokeys.com/pico-hsm/
|
| > usable by default, but reconfigurable so that you can
| bring your own keys and signatures, putting you in
| complete control of your hardware, to the point where
| even the manufacturer no longer has a say in what's
| running and what isn't.
|
| You can control what's your TPM. That's how they work
| today. Sure their software isn't "open source" but there
| aren't that many 100% "open source hardware" options
| around. If you want to be able to flash it, build your
| own HSM. I don't know if there is a market for a prebuilt
| microcontroller with something like picokeys
| preinstalled. I know that the market for "open" hardware
| is tough.
| raron wrote:
| > I don't see why a TPM couldn't be open? Nobody makes
| open-source TPMs
|
| The main advantage of the TPM is how it is made
| physically. It should be designed to make it hard or
| impossible to read the secrets out of it and those things
| depends on how the components are manufactured on the
| silicon wafer.
|
| Maybe the manufacturing process could be published, but I
| don't think it would help much.
|
| You could probably write your own TPM emulator or modify
| swtpm a bit and compile it to any microcontroller, but in
| that case the chip could be easily decapped to make all
| the secrets readable.
| varispeed wrote:
| That's a definition of security by obscurity.
| tremon wrote:
| An open TPM does exist:
| https://www.qemu.org/docs/master/specs/tpm.html#the-qemu-
| tpm...
|
| The TPM emulation offers a full TPM implementation in
| software, for providing TPM functionality to a virtual
| machine when the host doesn't have one (or, when the TPM
| needs to be virtualized for other reasons, e.g.
| migration).
| varispeed wrote:
| I am sorry I wasn't clear. I am aware that TPM is a key
| storage. Just I am not convinced they keys it stores are
| secure. It smells of security by obscurity and all big
| corporations are happy clappy to use it and government is
| silent about it, which likely means they have a backdoor.
| jeroenhd wrote:
| Maybe it's different for you, but I don't think any three
| letter agencies have some kind of TPM backdoor (they don't
| need to with how often TPM chips end up being vulnerable to
| common software exploits, the firmware being written in
| unsafe languages and all). If a government was going after me
| with enough force to use their TPM bypass trick, I'd probably
| be in jail for years on fake allegations regardless of
| encryption status.
|
| TPMs work great against things like common thieves and
| probably corporate espionage, if set up well. When
| implemented well, they provide no additional friction (except
| for having to store a recovery key somewhere) but all the
| security against a laptop being stolen at the airport you
| could wish for.
| arghwhat wrote:
| It's not a honeypot, and it does have value when used
| properly.
|
| Their main purpose is to generate and store keys that cannot
| leave the device, instead performing signing operations as
| needed internally and only returning the result, and only if
| attestation passed. This is a lot better than just having
| private keys on disk.
|
| People just forget that security isn't absolute, and each
| solution has a threat model it is appropriate for. In case of
| full disk encryption, neither a TPM nor user input can
| protect against evil maid on its own for example - the TPM
| will unlock for anyone, while user input might be collected
| by a modified and malicious bootloader. Having both, however,
| works well.
|
| "TPM" is a bit dated as a term as it's all directly built
| into the processor nowadays, including for smartphones and
| such. Another modern feature in that catalogue is memory
| encryption, which rules out the attack described by OP as the
| rebooted machine would be unable to read old memory content.
| tchebb wrote:
| Surely Windows keeps the FVEK in RAM regardless of whether the
| TPM requires a PIN to initially obtain it. Otherwise, wouldn't
| you need to enter your PIN every time a block from the disk
| needs decrypting? Not to mention the performance impact of
| calling the TPM on every disk operation.
|
| This attack reads the key from RAM, so I don't see how a TPM
| PIN would mitigate it.
| jansommer wrote:
| If you can short the reset pins while the computer is running
| and make it restart without losing power, then yes, I agree.
| But if you have to shut down to make your modifications, then
| you won't get past the PIN prompt.
| derekerdmann wrote:
| Correct, unless you're using a self-encrypting drive the FVEK
| sits in RAM once it's been released by the TPM during boot.
| The TPM is only a root of trust; for fast crypto operations
| without keeping the key in kernel memory you would need
| something like Intel SGX or ARM TrustZone.
| p_ing wrote:
| BitLocker no longer leverages SED by default due to
| vulnerabilities in drive manufactures firmware as of Sept
| 2019.
|
| > Changes the default setting for BitLocker when encrypting
| a self-encrypting hard drive. Now, the default is to use
| software encryption for newly encrypted drives. For
| existing drives, the type of encryption will not change.
|
| https://support.microsoft.com/en-
| us/topic/september-24-2019-...
|
| https://nvd.nist.gov/vuln/detail/CVE-2018-12037
| MoreMoore wrote:
| Holy crap.
|
| https://threadreaderapp.com/thread/1059435094421712896.ht
| ml
|
| This is amazing.
|
| > The encrypted SSD has a master password that's set to
| ""
|
| HN discussion here:
| https://news.ycombinator.com/item?id=18382975
|
| Original paper here: https://cs.ru.nl/~cmeijer/publicatio
| ns/Self_Encrypting_Decep...
| BobbyTables2 wrote:
| Might need most of PCRs 0-7. Isn't PCR 4 used to measure the
| EFI executable booted by UEFI?
|
| Avoid GRUB, difficult to secure with it.
|
| Kernel updates will also be painful...
| slicktux wrote:
| Why are more people not using self encrypting drives?
| varispeed wrote:
| Ages ago I had an external drive that had a controller with
| built in keys that encrypted the data in and out. Problem was
| that the controller was poorly made and one time upon
| connecting to the PC, the controller chip died and so the keys
| with it. It was impossible to recover the data, but the disk
| itself was perfectly fine. I bought a damaged drive with
| working controller and swapped it out and my drive worked
| again, however I had to format it, because new board had
| different keys. Since then I preferred to use software
| encryption and steered clear of drives that use any sort of
| hardware encryption. The risk of losing data was not worth it.
| arghwhat wrote:
| All SSD's with OPAL are _always_ encrypting your data.
| "Enabling" the feature just means that you change from a
| random on-device key to a key encrypted with your passphrase.
|
| (Whenever you wipe the drive through OPAL, you're just
| overwriting the key.)
| TiredOfLife wrote:
| After this https://borncity.com/win/2018/11/06/ssd-
| vulnerability-breaks...
|
| Microsoft patched out support for self encrypting drives.
| arghwhat wrote:
| Quite dumb considering this was an issue with pretty much a
| single, low-cost consumer vendor (Crucial?).
|
| If nothing else, use it in combination - the encryption of
| OPAL drives is always active anyway, all that changes when
| the feature is "active" is whether the key is stored as-is on
| the controller or whether its protected by a passphrase.
| OptionOfT wrote:
| It's actually still in there.
|
| Now, drives with eDrive, as MS calls it, are becoming harder
| to find. It is no longer advertised (as native 4k sectors
| aren't either...). Soon it'll be dropped all together.
| vel0city wrote:
| Seems like most of the big drive makers had pretty poor quality
| on the whole self encrypting part of it, at least last I saw a
| few years ago.
| kotaKat wrote:
| I blame the mess that was Wave Systems and the shitty
| meddlingware they built to try to manage it all.
|
| The support experience was one of the absolute worst I've
| ever seen -- and I was the guy on the end of the phone that
| had to say "thank you for calling Wave Systems Gold Support"
| having been given _zero documentation into what the product
| even did_ , but being told we had to log tickets into MS
| Dynamics and pray that a Wave engineer would call a panicked
| locked out user back "soon".
| PhilippGille wrote:
| Related 38C3 talk about Windows 11 BitLocker bypass:
| https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...
| layer8 wrote:
| It's fairly well known that BitLocker only really protects a
| computer that is turned off, and also only if you configure
| BitLocker to require a boot password [0].
|
| [0]
| https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
| medlazik wrote:
| Step 3: Boot from the USB Device
|
| Game over, any laptop with data worth stealing will have this
| disabled in bios
| RachelF wrote:
| Windows has a proposed memory encryption option along with memory
| compression.
|
| Both Intel and AMD are working on embedding this into their CPUs.
|
| However, the target use appears to be servers with multiple VMs,
| not laptops.
| p_ing wrote:
| Intel has this via their Total Memory Encryption feature today.
| Yes, geared towards VMs in the Windows ecosystem.
|
| https://techcommunity.microsoft.com/blog/windowsosplatform/m...
|
| Memory compression has been around for ages, at least since
| Windows 10 RTM. All major operating systems have implemented
| this feature -- it has no relation to security, though.
___________________________________________________________________
(page generated 2024-12-30 23:00 UTC)