[HN Gopher] Bypassing disk encryption on systems with automatic ...
___________________________________________________________________
Bypassing disk encryption on systems with automatic TPM2 unlock
Author : arjvik
Score : 180 points
Date : 2025-01-17 03:00 UTC (20 hours ago)
(HTM) web link (oddlama.org)
(TXT) w3m dump (oddlama.org)
| acheong08 wrote:
| I don't understand why anyone would use passwordless disk
| encryption. It just seems inherently vulnerable, especially with
| the threat model of physical compromise.
|
| Entering a password on boot isn't even that much work
| pclmulqdq wrote:
| On servers, it protects against someone stealing your disks (or
| stealing the raw bytes from your disks) and then booting them
| in a copy of your machine.
| mcny wrote:
| > Entering a password on boot isn't even that much work
|
| It is on fedora. I wabt the latest packages and I want to
| install them with dnf offline upgrade but now I need to put in
| password twice once for the updates d again for next boot. If
| it is a server, I don't want to keep a monitor attached to it
| just to enter the password. I want the computer to just boot.
|
| There has to be a better way.
| bpye wrote:
| Is the boot time password unlock occurring in GRUB or after
| the Linux kernel has started? If the latter you should be
| able to setup an SSH server to run in that early boot
| environment, that's how I can remote unlock drives on NixOS.
| keeperofdakeys wrote:
| > There has to be a better way.
|
| Probably Clevis and Tang, network disk decryption that can
| only decrypt if most of your servers are online.
| https://github.com/latchset/clevis
| https://github.com/latchset/tang
|
| Or network decryption (SSH into initrd).
| https://github.com/gsauthof/dracut-sshd
| johnisgood wrote:
| There is: https://news.ycombinator.com/item?id=42734841.
| webstrand wrote:
| There is, I use kexec to boot a modified cpio containing the
| fde password, since cpio can be extended by concatenation. ht
| tps://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...
|
| It's the same technique grub uses to forward the FDE password
| to the initramfs after its own initial decryption (to read
| the kernel and initramfs). This works to reboot remote
| servers with FDE, without needing a vnc or earlyboot-sshd.
| prmoustache wrote:
| I also use a fedora.
|
| Typically I use offline upgrade if I mean to poweroff but
| otherwise I just run `sudo dnf update -y && sudo systemctl
| reboot` in a terminal if I want a quick update&reboot.
|
| On another laptop I am using silverblue (well bluefin) and
| the atomic upgrades solve the issue completely.
| Hakkin wrote:
| If a disk is encrypted, you don't have to worry about the
| contents if you eventually have to RMA or dispose of the disk.
| For this use case, it makes no difference how the encryption
| key is input.
| tommiegannert wrote:
| I'd guess the most common scenario is for someone giving away
| the entire computer, not fiddle with components. Or theft of
| the full machine.
|
| This feels like one of those half-security measures that
| makes it feel like you're safe, but it's mostly marketing,
| making you believe *this* device can be both safe and easy to
| use.
| megous wrote:
| Encrypted data are noise now, maybe, but may be decryptable
| in the future with advances in computing.
|
| So all this depends on what you worry about.
| HPsquared wrote:
| Most of this concern is around certain public key
| cryptography algorithms which depend on math problems being
| extremely hard to solve but could in theory be
| mathematically solved (decrypted without the key) with a
| good enough quantum computer.
|
| Disk encryption (AES etc) is symmetric and still only
| brute-force would work which can be made infeasible with a
| long enough key.
| Avamander wrote:
| Brute-forcing symmetric encryption is a somewhat silly
| concept anyways, because each decryption is equally
| valid.
| tibordp wrote:
| That's only true for information theoretically secure
| algorithms like one-time pad. It's not true for
| algorithms that are more practical to use like AES.
| cesarb wrote:
| > Brute-forcing symmetric encryption is a somewhat silly
| concept anyways, because each decryption is equally
| valid.
|
| Each decryption is equally valid _as long as the key has
| the same size as the data_. What happens, in practice, is
| that the key is much smaller than the data. Take a look
| at your filesystem, it should have hundreds or thousands
| of bytes of fixed information (known plaintext), or an
| equivalent amount of verifiable information (the
| filesystem structure has to make sense, and the checksums
| must match). That is: for a large enough filesystem
| (where "large enough" is probably on the order of a
| small floppy disk), decrypting with the wrong key will
| result in unrecoverable garbage which does not make sense
| as a filesystem.
|
| To give an illustration: suppose all filesystems have to
| start with the four bytes "ABCD", and the key has 256
| bits (a very common key size). If you choose a key
| randomly to decrypt a given cyphertext, there's only one
| chance in 2^32 that the decryption starts with ABCD, and
| if it doesn't, you know it's the wrong key. Now suppose
| the next four bytes have to be "EFGH", that means only
| one in 2^64 keys can decrypt to something which appears
| to be valid. It's easy to see that, once you add enough
| fixed bytes (or even bits), only one key, the correct
| one, will decrypt to something which appears to be valid.
| dangero wrote:
| Depends on the use case. If boot requires a password, the
| computer can never lose power or be rebooted without human
| presence. That's not always practical.
| prmoustache wrote:
| That is what remote kvm are for and if you do that on
| commodity hardware you can start a tiny ssh server starting
| up from an initrd. Having said that an attacker with local
| access could change the initrd without your knowledge so that
| it logs the password you enter so it is not necessarily the
| most secure solution.
| deno wrote:
| You've answered it yourself. Without TPM you have no idea
| if you can provide the secret to the system or if it's
| compromised. Whether that secret comes from TPM or network
| is secondary.
| tucnak wrote:
| Google: IPMI, BMC
| teddyh wrote:
| You can reboot your full-disk-encryption server while you
| sleep. Obligatory plug: <https://www.recompile.se/mandos>
|
| Disclosure: I am a co-author of Mandos.
| prennert wrote:
| Has this solution been audited? In particular, is it safe
| to replay attacks by actors listening in to the network
| traffic?
|
| Also from the diagram it looks like the secret key is
| stored unencrypted on the server, or do I read it wrong?
| teddyh wrote:
| > _Has this solution been audited?_
|
| Only insofar as everybody that I've asked over the years
| has failed to find anything wrong with it. But no formal
| verification has been done.
|
| > _In particular, is it safe to replay attacks by actors
| listening in to the network traffic?_
|
| Yes, it is safe, since we make sure to only use TLS with
| PFS.
|
| > _Also from the diagram it looks like the secret key is
| stored unencrypted on the server, or do I read it wrong?_
|
| No, the secret is stored encrypted on the server,
| encrypted with a key which only the client ever has.
|
| For more information, see the introduction and FAQ:
| <https://www.recompile.se/mandos/man/intro.8mandos>
| gerdesj wrote:
| Thank you for this. I will almost certainly be deploying
| that.
| sedatk wrote:
| Because I don't expect a random thief to go to the lengths of
| identifying OS level vulnerabilities to bypass the login prompt
| in order to decrypt the disk contents. The potential gains for
| them are marginal compared to the time and effort spent there,
| not to mention technical expertise needed. I expect them to
| steal it, and if it's encrypted, just sell it for parts, or
| wipe it and sell it anew.
|
| Entering a password can be a lot of work if you use a strong
| password (and if you don't, why bother with a password?). Typos
| can take a toll too because of all the delays included.
| _blk wrote:
| A weak password is always better than no password. It's like
| using a cheap lock on your door or not locking it.
| Practically, if a thief wants to get through he'll get
| through but your insurance and sentencing will look
| different.
| sedatk wrote:
| As I said before, if someone's determined enough to spend a
| lot of time find OS level vulnerabilities and exploit them
| to decrypt my disk, they will certainly have enough time
| and determination to break a weak password.
| prmoustache wrote:
| > Entering a password can be a lot of work if you use a
| strong password (and if you don't, why bother with a
| password?).
|
| So does-it means you do not setup a password/passphrase for
| your user account?
| nick__m wrote:
| I use auto login (control userpassword2 still work to set
| that up on Windows11) on my gaming computer in the living
| room! If I could that user account wouldn't have a
| password.
|
| But my work computers requires a pin to boot and a password
| that only my yubikeys (bind the static password to the long
| press) knows to login. different policy for different
| context...
| sedatk wrote:
| No, I use biometrics login for the same reasons. I have a
| strong password, but 99% of the time, I don't need it.
| userbinator wrote:
| Between consciously encrypting with a user-supplied password,
| and not encrypting at all, automatic encryption seems more like
| a nuisance/hazard for recovery than anything else.
|
| Consciously encrypting with a password implies an understanding
| of the risk of permanent loss. Leaving it unencrypted implies
| an understanding of the risk of disclosure. Having your drive
| silently encrypted feels like the worst of both worlds. "I
| never encrypted or locked it, what do you mean my data is
| encrypted and gone forever!?"
| cyberax wrote:
| > I don't understand why anyone would use passwordless disk
| encryption.
|
| I'm using it on my home server that I'm using for self-hosting.
| This way, if it's stolen, the thief won't be able to easily get
| to my data. At the same time, I don't have to physically enter
| the password if my server reboots.
| jvdvegt wrote:
| They'll have your data if they just take the whole server...
| cyberax wrote:
| And then what? They will be faced with a login prompt.
| Reading from disks is useless. My login password is strong.
| udev4096 wrote:
| It's just not practical. How are you going to manually enter
| the password for let's say 10 servers?
| johnisgood wrote:
| USB pendrive with random key, no need to enter anything and
| is more secure and gives you plausible deniability through
| many different means.
| cedilla wrote:
| Going around 10 servers with a USB drive sounds just as
| tedious, and what happens when you lose the key or the
| attacker gets it?
| coppsilgold wrote:
| Passwordless TPM FDE effectively "pairs" your HDD(s) with the
| TPM module such that the data on the drive(s) is inaccessible
| without it or a strong LUKS password if added.
|
| Using even a weak pin/password will allow you to both "pair"
| and "secure" assuming the TPM is configured to destroy the key
| on multiple failed attempts.
|
| You should also add a strong (high entropy) LUKS password to
| allow data recovery in case the TPM chip is lost or the keys
| are destroyed.
|
| Note that the bits of the encryption keys are present somewhere
| in the TPM and could in theory be extracted with an exploit or
| with scanning probe microscopy perhaps.
| johnisgood wrote:
| You do not even need to enter a password.
|
| Use a randomly generated key. Retrieve it from an USB drive at
| boot (it does it automagically), which contains everything,
| giving you full plausible deniability without it. It means
| literally everything you need to boot up is on the USB drive,
| and if you so want it, you can use 2 separate USB drives.
|
| This is for computers you have physical access to, of course.
| You will need to carry the USB disk if it is a laptop, but you
| choose: you want to enter a password (which by itself gives you
| no plausible deniability BTW), or you want plausible
| deniability and/or you don't want to enter a password. And
| while we are at it, laptops (and even desktops) today have SSD,
| and encryption and plausible deniability is different for an
| SSD, but again, you choose. Right tool for the job.
|
| https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti...
| fulafel wrote:
| Try having a chat with a HCI person. Or in a pinch ask a LLM to
| emulate one for you. It's a useful perspective to have for a
| lot of stuff.
| logifail wrote:
| > I don't understand why anyone would use passwordless disk
| encryption
|
| You want to install and operate a device at a remote site with
| restricted (or no) VPN access and where you don't trust the
| local staff?
| artiscode wrote:
| A remote KVM, i.e TinyPilot will help avoid dealing with lack
| of trust in local staff. Additionally connection to the KVM
| can be done over LTE/Cellular if you don't trust the local
| connection too.
| logifail wrote:
| I set up a server last year which is at a remote site which
| is completely air-gapped from the Internet, it's allowed to
| see one local LAN and that's all. For any kind of admin
| task someone has to drive to site.
|
| There is precisely zero chance that the relevant IT
| security goons would allow any kind of remote KVM/LTE
| connection.
| nh2 wrote:
| How does this make sense?
|
| Any change the untrusted local staff could make to the
| server, they could also make to the KVM machine (e.g. turn
| it into a keylogger).
|
| Now you have the same problem but with a smaller computer.
|
| You cannot turn untrusted systems into trusted systems by
| adding more untrusted systems.
| usr1106 wrote:
| Some systems need to boot without a (trusted or skilled) user
| present.
| michaelt wrote:
| Imagine a big corporate workplace, where the infosec team
| wasn't comprised of freewheeling anarchic hacker types who've
| dedicated their career to mastering the intricacies of the
| Linux boot process, but instead by compliance folks who've
| dedicated their career to mastering the intricacies of global
| privacy laws and passing SOC2 compliance audits.
|
| _From their perspective,_ "Secure Boot" has the word "Secure"
| right in the name. And they've looked up details about the TPM
| - Microsoft says the TPM avoids systems being tampered with,
| and addresses the threats of data theft or exposure from lost,
| stolen, or inappropriately decommissioned devices.
|
| If you don't know the intricacies involved, that stuff all
| sounds great! So they put a line into the corporate IT policy
| that TPM use is mandatory.
| jrockway wrote:
| It's always felt like the best way to lock myself out of my own
| machine. While I don't really keep any important data on it
| that's not backed up, I also don't build my workstation image
| from a config file or anything, so some time will be lost. The
| thing that's always bugged me is that before AMD had a TPM
| built into the CPU, the TPM was just a poorly-secured dongle
| hanging off the motherboard (at least with Asus motherboards)
| and it just seems like something that's going to break
| randomly. That breaks, then what. Meanwhile, the CPU owning the
| keys also doesn't feel great. Sometimes you swap your CPU and
| now there is an 800 step process to disable decryption before
| you do that, which is certain to be forgotten as you excitedly
| unpack your new CPU purchase. (Even if you're completely
| rebuilding the computer, the number of times I've put a new
| disk into a new build is approximately zero.)
|
| Just typing a passphrase at boot seems like a pretty decent
| compromise. I've done it for years and it's never caused a
| problem.
| vladvasiliu wrote:
| I sympathize with your points, especially rebuilding the box
| from scratch.
|
| But all the "passwordless" schemes I've seen support at least
| an additional "master key" which you can type in.
|
| So if you're ok with the security tradeoffs of passwordless
| tpm, it's only an added convenience on top of your approach.
| _verandaguy wrote:
| This was actually a problem for me on my current gaming PC
| build!
|
| I had switched to a new AM4 mobo a few years back and decided
| to spring for a pluggable TPM chip (since the CPU I have
| doesn't come with TPM onboard). Plugged it in, set everything
| up pretty seamlessly in windows, no fuss, no muss, boot
| drive's encrypted transparently. The lack of a password was a
| bit jarring at first, but it's a gaming PC, so if things go
| pear-shaped it's not the end of the world.
|
| Fast forward six months and my PC suddently refuses to boot;
| turns out the pluggable TPM thing was defective and stopped
| working (without any warning that got surfaced to me).
|
| It was just my boot drive, and reinstalling windows isn't a
| huge hassle, but it definitely cemented my mixed feelings
| about passwordless FDE. Had that been the drive I use for my
| photo library, or my software projects, or work-related
| documents (tax slips, employment contracts, whatever), that
| would've been _devastating._
|
| It's actually made me rethink the strategy I use for my
| laptop's backups, and I think I'm in a better place about
| that now.
| foepys wrote:
| Don't all AM4 CPUs feature fTPM which is a firmware-based
| TPM? Bitlocker at least accepts this as secure enough to
| boot Windows 11.
| _verandaguy wrote:
| Frankly, it's possible; I don't remember at this point.
| At the time, I just decided to go for a separate chip
| since I hadn't heard of fTPM being available at the time.
| The chip in question's a 3900X and it's still running
| smoothly.
| sedatk wrote:
| You can add alternative Bitlocker decryption mechanisms
| including a strong password using manage-bde CLI tool.
| Also, Bitlocker gives you the opportunity to save your
| recovery data externally in case you lose all your
| authentication mechanisms. I'm surprised that you lost your
| data.
| AzzyHN wrote:
| I believe with software-based encryption (LUKS and the like),
| the decryption key ends up being stored in RAM, which will
| always present a risk.
|
| And TPM-based solutions don't have this problem. Could be wrong
| though.
| kevincox wrote:
| I think most TPM based solutions still use software
| encryption. Most TPMs don't have the bandwidth to actually
| decrypt all disk data as it is read. (I think Apple devices
| do actually do something like this, but I don't think it is
| common.)
|
| I believe when using TPM with LUKS the TPM just decrypts the
| master key and that is handed back to the OS and used in
| software. So the primary key does end up in RAM.
| toast0 wrote:
| I would consider it for my hosted server.
|
| Entering a password on boot is a lot of work, because I need to
| vpn in, and run a java webstart kvm application (serial over
| ipmi would work better, but it doesn't work well on the
| hardware I have).
|
| Encrypted disks is a requirement because I don't trust the
| facility to wipe disks properly. But I assume I would be able
| to clear the TPM (if present) when I return the machine. And I
| could store a recovery key somewhere I think is safe in case of
| hardware issues (although, last time I had hardware issues, I
| simply restored from backup to new to me disks)
| cuu508 wrote:
| > Encrypted disks is a requirement because I don't trust the
| facility to wipe disks properly.
|
| Couldn't you wipe the disks yourself?
|
| Or are you thinking of cases where the disk breaks, gets
| replaced, and the removed disk does not get properly
| destroyed?
| toast0 wrote:
| Sometimes yes, but if there's a hardware issue, I may not
| be able to.
|
| Ex: the first server I had failed and they ended up
| replacing it with a different server with similar specs,
| but the drives werem't moved. In this case, the failure was
| gradual (resetting by itself) and as part of debugging it,
| I wiped the drives and installed a new OS, but towards the
| end, the amount of time between resets was very short, and
| I wouldn't have had a chance to wipe it if I had started
| later.
|
| Yes, this isn't great service, but it's personal hosting
| and it's cheap and I get a whole (very old) machine.
| gizmo wrote:
| Dropbear is the solution for this.
| toast0 wrote:
| Well, if the FreeBSD installer would set that up for me, I
| probably would have done it that way, but lazy, and I don't
| reboot that often.
| pg5 wrote:
| Fully agree, especially for a laptop. A password that combines
| three unrelated words and a few numbers takes about 3 seconds
| to type in.
|
| I shut it down every day, so type in the password every day
| too. Short of a concussion, I'm not going to get locked out.
| booi wrote:
| So.. it is possible...
| pg5 wrote:
| Yes.. it is...
|
| It's a risk I'm fine with. Anything I care about is backed
| up separately.
| keeperofdakeys wrote:
| You can mitigate this by including PCRs that sign the kernel and
| initrd, however it means whenever you update you need to unlock
| manually. On Redhat-based distros this can be done with PCRs 8
| and 9, though IIRC this may change on other distros.
|
| Also AFAIK there is no standard way to guess the new PCRs on
| reboot so you can't pre-update them before rebooting. So you
| either need to unlock manually or use a network decryption like
| dracut-sshd.
| XorNot wrote:
| It's ridiculous that there's no software implementation to do
| this, it's a huge problem.
|
| Auto update should be able to include the kernel, initrd and
| grub cmdline from the running system I have no idea what's
| holding this back since evidently code already exists somewhere
| to do exactly that.
| Vogtinator wrote:
| That's the design with sdbootutil in openSUSE
| (https://en.opensuse.org/Systemd-fde,
| https://github.com/openSUSE/sdbootutil).
| jansommer wrote:
| You can use tpm2_policyauthorize and allow the PCR to change
| without having to manually unlock. This was not supported in
| TPM 1.2.
|
| You can use it with Systemd.
|
| https://github.com/tpm2-software/tpm2-tools/blob/master/man/...
| saljam wrote:
| > You can mitigate this by including PCRs that sign the kernel
| and initrd
|
| nope! the trick the article is describing works even if the
| kernel and initrd is measured. it uses the same kernel, initrd,
| and command line.
|
| the reason this trick works is that initrds usually fall back
| to password unlock if the key from the tpm doesn't work. so the
| hack replaces the encrypted volume, not the kernel, with a
| compromised one. that is:
|
| 1. (temporarily) replace encrypted volume with our own,
| encrypted with a known password.
|
| 2. boot the device.
|
| 3. the automated tpm unlock fails, prompting for a password.
|
| 4. type in our password. now we're in, using the original
| kernel and initrd, but it's our special filesystem, not the one
| we're trying to decrypt.
|
| 5. ask the tpm again for the key. since we're still using the
| original kernel, initrd, and command line, we should now get
| the key to unlock the original encrypted volume.
|
| the way to fix this is to somehow also measure encrypted volume
| itself. the article points to suggestions of deriving a value
| from the encryption key.
| dist-epoch wrote:
| > 3. the automated tpm unlock fails, prompting for a
| password.
|
| > 4. type in our password.
|
| In a serious security conscious setup this should be a big
| red flag to investigate. Any unexpected boot password prompt.
| saljam wrote:
| yes of course - but in this case the "unexpected" prompt is
| presented to the attacker, not the user.
| Vogtinator wrote:
| > You can mitigate this by including PCRs that sign the kernel
| and initrd.
|
| No, that's not an effective mitigation. The signed
| kernel+initrd would still boot into the impersonated root.
|
| > however it means whenever you update you need to unlock
| manually. On Redhat-based distros this can be done with PCRs 8
| and 9, though IIRC this may change on other distros. > Also
| AFAIK there is no standard way to guess the new PCRs on reboot
| so you can't pre-update them before rebooting. So you either
| need to unlock manually or use a network decryption like
| dracut-sshd.
|
| With some logic to update the values on kernel updates and re-
| seal the secret this can be handled transparently. That's the
| design with sdbootutil in openSUSE
| (https://en.opensuse.org/Systemd-fde,
| https://github.com/openSUSE/sdbootutil).
| jakogut wrote:
| At least for PCR 7, it's well specified and documented how the
| digest is generated. You can dump the component digests of a
| PCR using `tpm2_eventlog`, and I've written a tool that can be
| used to populate the requisite data structures for hashing.
|
| https://github.com/balena-os/tcgtool
| huslage wrote:
| The other option is to have an intrusion prevention switch or two
| in the case so the TPM locks itself in some way and the machine
| refuses to boot at all without some PKI attestation.
| nicman23 wrote:
| depends on the threat model. a rot saw will hack it :P
| staff3203 wrote:
| On my system, I used `tpm2-measure-pcr=yes` in
| `/etc/crypttab.initramfs`, then used `--tpm2-pcrs=0+2+7+15:sha256
| =0000000000000000000000000000000000000000000000000000000000000000
| ` with `systemd-cryptenroll`.
|
| As soon as a volume is decrypted, initrd will write `volume-key`
| to PCR 15, so any further executables can no longer access the
| data stored in the TPM.
| usr1106 wrote:
| Yes, that seems a good extra level of defense. Allow unsealing
| only once. We extend a PCR with random data.
| dist-epoch wrote:
| This is what Bitlocker does. There was a recent article about
| it.
| oddlama wrote:
| This is great if you only have a single disk, but if you have
| multiple encrypted disks that are unlocked in the initrd this
| way, then if you can gain control flow by faking data on the
| last decrypted disk you can still gain access to all the
| previously unlocked partitions.
|
| Of course you cannot unseal the secret from the TPM anymore.
| bean-weevil wrote:
| If you have tpm encryption on your boot disk, then you can
| simply store decryption keys for your otyer disks on it.
| staff3203 wrote:
| What to do for a single root fs spanned over 2 encrypted
| partitions on 2 separate disks?
| ARob109 wrote:
| Seems like this could be easily mitigated with a read only root
| filesystem using dm verity
|
| Store the root hash of the dm verity formatted rootfs in the PCR.
| If a malicious partition is presented to initrd, its root hash
| will not match the trusted one stored in the TPM.
|
| Or if you need a writeable rootfs, use fs verity and store the
| signature of init into the PCR. The trusted init signature won't
| match signature of malicious init.
|
| LUKS for encryption and verity for integrity/verification.
| yx827ha wrote:
| That's how ChromeOS does it.
| https://m.youtube.com/watch?v=iO6cb90WiQ4
| ARob109 wrote:
| Android too in a way via Android Verified Boot. I think
| ChromeOS uses AVB as well.
|
| Android Verified Boot extends the System on chip Hardware
| based secure boot to the kernel and rootfs. Root of trust is
| fused into the SoC, and second stage bootloaders are signed.
| Second stage boot loader eg uboot,UEFI/edk2 contains a public
| key that is used to verify a signed AVB partition. This
| signed partition contains signed rootfs dm verity metadata
| and signed hash of the kernel(+initrd). AVB validates kernel
| hash with expected hash and loads kernel if good. It provides
| the trusted rootfs verity hash to kernel via cmdline. Then
| when kernel reads rootfs, the dmverity system will calculate
| hash and check if matches the expected one. If not, the
| system reboots and the AVB metadata is flagged to indicate
| tampering/failure of the rootfs.
|
| edit to add: If the SoC supports hardware based full disk
| encryption, the filesystem can be encrypted as well, with the
| key being stored in Androids secure key store. Android though
| has moved away from FDE in favor of file based encryption.
| bigfatkitten wrote:
| The ingredients are there as Chrome OS and Android have
| shown, but robust hardware-bound disk encryption has just
| never been a priority for the general purpose distros.
| highwaylights wrote:
| I'm not sure if this is the exact process for openSUSE Aeon,
| but it's very close philosophically so I image the rest is a
| question of hardening this over time.
| ChocolateGod wrote:
| > If a malicious partition is presented to initrd
|
| The fact the initramfs is not signed/verified on any desktop
| Linux distro means secure boot is completely pointless right
| now on Linux, and is very dissapointing.
|
| I know Fedora has been musing with shipping prebuilt initrds,
| but it raises problems with things like Nvidia where you need
| the driver to be in the initramfs to have a proper boot screen.
| There's also UKIs that have the kernel + initramfs in the same
| EFI binary (and thus signed) for booting by secure boot, but
| they can become too big for the small EFI partition computers
| ship with.
| blucaz wrote:
| > The fact the initramfs is not signed/verified on any
| desktop Linux distro means secure boot is completely
| pointless right now on Linux, and is very dissapointing.
|
| It is not. There are other, very real and very important
| problems with that fact and reasons why it should be fixed,
| but this is not it. The point of SecureBoot is to protect the
| firmware from userspace. It works very well for that purpose,
| as evidenced by the facts that exploits to bypass it have to
| continuosly be found.
| oneplane wrote:
| That's similar to how Apple does it. The base system is signed
| (and has a tree of signatures so you don't need to strictly re-
| calculate the entire RO volume your base OS sits on), and the
| signature is recorded in the boot configuration.
|
| Granted, you could disable that, but they have thought of that
| too, you can only disable it from a recovery OS that is signed
| the same way. But disabling that doesn't disable it for the
| recovery OS, so you can't evil maid the recovery OS later to
| make it appear as if it is still enabled.
| tommiegannert wrote:
| Very nice exploit.
|
| So if you use this PCR state machine, the problem is that the
| step before initrd doesn't require the correct password to move
| the PCR forward? It accepts any password that decrypts the next
| stage, which didn't have its integrity verified here.
|
| Seems there are multiple ways of solving this, and adding
| integrity checks is only one. It could also let the TPM verify
| the disk decryption password (when it's needed.)
| michaelt wrote:
| _> It could also let the TPM verify the disk decryption
| password (when it 's needed.)_
|
| The design intent is basically:
|
| 1. The TPM is very sensitive, and errs on the side of not
| unlocking your disk.
|
| Booting into recovery mode to fix a driver? Reinstalled your
| distro? Added a MOK so you can install the nvidia drivers?
| Toggled certain options in your BIOS? The expected-computer-
| state checksums are wrong, better not unlock the disk as it
| could be an attack.
|
| 2. When this happens, you key in the password instead.
|
| You can't rely on the TPM to verify the manually entered
| password, as the intent of the manually entered password is to
| recover when the TPM is in a broken state.
| fguerraz wrote:
| The "mitigation" itself is still not very safe if you're paranoid
| about governments or very motivated organisations. The extra step
| of checking PCR12 is performed by the initrd that you trust
| because it's signed by a private key that has probably leaked to
| every serious hacking corp / government. They can just boot their
| own signed initrd and kindly ask the TPM that will oblige.
|
| I personally replace the firmware certificates (PK, KEK, db, dbx,
| ...) with my own and sign every kernel/initrd update, I also
| unlock my disks with a passphrase anyways, but I'm on the fence
| WRT if it's more secure than TPM.
|
| Yes in theory TPM key extraction is feasible (and even easy if
| it's performed by a chip other than your CPU
| https://pulsesecurity.co.nz/articles/TPM-sniffing ) but it is
| harder than filming/watching you type the passphrase or
| installing a discrete key-logger ?
| dist-epoch wrote:
| > sign every kernel/initrd update
|
| If you believe that the those SecureBoot private keys were
| leaked, why not also believe that the linux kernel signing keys
| were also leaked and that you are downloading a backdoored one.
| jakogut wrote:
| It's quite easy to generate your own signing keys which you
| use to sign a kernel you've built yourself.
| kopirgan wrote:
| Any idea how this works in the Windows world with bitlocker? I
| hope it's not same vulnerability
|
| I recently changed motherboard on my laptop, had the bitlocker
| key if not I was told I'll have to reinstall Windows all over
| again.
|
| Even with the key, one must decrypt and re-encrypt.
| dist-epoch wrote:
| > Even with the key, one must decrypt and re-encrypt.
|
| That's not true, the unlock key will be regenerated, but the
| disk contents will not be re-encrypted, because it's encrypted
| with another immutable key.
| kopirgan wrote:
| Thanks may be I didn't know the exact steps. It kept
| prompting key at every startup until I disabled and re-
| enabled bitlocker.
| mateusz834 wrote:
| Personally i would like a way to use TMP2 (with PIN) + password.
| (i.e. mode where PIN is derived from the password, but is also
| used to encrypt), so that i do not have to trust the TPM
| manufacturer.
| highwaylights wrote:
| This can be done. Not sure how on Windows/bitlocker but
| certainly with cryptenroll. Essentially you'd wrap this in your
| bootscript, though.
|
| So password (or pin) encrypts passphrase, passphrase encrypts
| LUKS and goes to TPM, then you need to reverse the process for
| your init script (request password, decrypt passphrase,
| exchange with TPM to decrypt LUKS), but it depends on your
| appetite for planning that out.
| mateusz834 wrote:
| Wouldn't this work with some kind of PKDF instead?
|
| Like: Password ---> PKDF ---> PIN
|
| And then Password XOR (Key from TPM) -> LUKS
|
| But i guess this kind of logic is not for a bootscript, but
| for tools like systemcd-cryptenroll.
| shitter wrote:
| This is mitigated if your initramfs + kernel are measured into
| the TPM, right?
|
| Edit: never mind, I think it's still vulnerable.
| jakogut wrote:
| Your edit is correct. The kernel and initramfs are exploited
| unmodified to boot a tampered root filesystem, which allows
| userspace tools to extract data from the TPM, as the PCRs used
| to protect data like the LUKS passphrase have not changed.
| rollcat wrote:
| When I first read about TPM-based FDE on Linux[0], I was excited
| that the systemd guys were finally taking a step in the right
| direction - BitLocker/FileVault were standard on Windows/macOS
| for a long time by that point. FDE should be secure by default,
| dead-simple to set up (e.g. a checkbox in the installer that
| defaults to "enabled"), and painless for everyday use.
|
| [0]: https://0pointer.de/blog/brave-new-trusted-boot-world.html
|
| Then I read about the implementation details[0], and it's a
| complex bloody mess with an unending chain of brittle steps and
| edge cases, that are begging for a mistake and get exploited. So
| here we are.
|
| I'm convinced that "measure the kernel" into "measure the initrd"
| into "show login screen" is all it should take.
| snailmailstare wrote:
| >> we can confuse the initrd into executing a malicious init
| executable.
|
| This hash the next link method is always as flawed as the
| weakest link..
| tiberious726 wrote:
| TPM+PIN is pretty great, is a shame it's nearly never used.
| jdoss wrote:
| Hah, my gist from 2022 is on this post as a "broken guide". I'd
| disagree in saying it is broken. It works just fine and I flat
| out say at the top to not use it if you are worried about a cold
| boot attack on your hardware.
| blastrock wrote:
| Very clever!
|
| I am the author of one of the older guides
| https://blastrock.github.io/fde-tpm-sb.html .
|
| I was wondering about the solution you propose which seems a bit
| complicated to me. Here's my idea, please tell me if I'm
| completely wrong here.
|
| What if I put a file on the root filesystem with some random
| content (say 32 bytes), let's name it /prehash. I hash this file
| (sha256, blake2, whatever). Then, in the signed initrd, just
| after mounting the filesystem, I assert that hash(/prehash) ==
| expected_hash or crash the system otherwise. Do you think it
| would be enough to fix the issue?
| lxgr wrote:
| > You are safe if you additionally use a pin to unlock your TPM
|
| Does the default configuration _not_ somehow tangle a user-
| entered password to authentication against the TPM?
|
| That's still not perfect (i.e. how do you make PIN/password entry
| non-keyloggable), but anything else, in particular extending the
| trusted computing base to _the entire kernel and the hardware it
| runs on_ and hoping that they will both be bug-free and
| impossible to impersonate, seems like a bad idea.
|
| The TPM is also in a much better position to properly velocity
| check PIN/password entries than the OS.
| varispeed wrote:
| How do you deal with something like this in a NAS? There is no
| way to enter password during boot.
|
| If someone steals the NAS how easily can they get to the data?
| Assuming volumes are encrypted, but the are automatically mounted
| on boot?
|
| How to ensure the data is safe in case of theft.
___________________________________________________________________
(page generated 2025-01-17 23:01 UTC)