[HN Gopher] Authenticated Boot and Disk Encryption on Linux
___________________________________________________________________
Authenticated Boot and Disk Encryption on Linux
Author : Aissen
Score : 297 points
Date : 2021-09-23 09:41 UTC (13 hours ago)
(HTM) web link (0pointer.net)
(TXT) w3m dump (0pointer.net)
| vbezhenar wrote:
| So basically an issue is that initramfs is not validated. Is it
| even possible to resolve that issue? If new grub version adds
| forced initramfs validation when run under secure boot mode,
| attacker can just install old grub which is still signed, but
| allows for unsigned initramfs.
|
| Of course everything but /boot must just be encrypted, there's no
| reason not to.
| vbernat wrote:
| When upgrading, you have to remove old PCR states, so rolling
| back to an older version is detected.
| zokier wrote:
| You don't need separate initramfs file these days, you can bake
| it into the kernel executable which you can then sign
| cmurf wrote:
| True but this is complicated for users to do themselves.. And
| also complicated for distributions to create, sign, and
| distribute a "universal" or no-host-only initramfs that will
| boot any supported configuration. Plus that universal
| initramfs is quite a lot larger than the more compact host-
| only initramfs.
|
| It should be possible to automate writing out a new fs-verity
| "boot" directory containing the locally-signed files we care
| about, and having the signing regime enforced by a distro
| signed bootloader. Like dm-verity Android images, the Merkel
| tree is signed by asymmetric key pair, with the private key
| tossed immediately after successfully creating and signing
| the tree, with the public key being exposed wherever
| convenient.
| sharmin123 wrote:
| The Best And Easiest Ways To Protect Yourself From Hackers:
| https://www.hackerslist.co/the-best-and-easiest-ways-to-prot...
| maverwa wrote:
| Running the FDE (or partial encryption) of the TPM would include
| the risk that a hardware defect on the mainboard would render the
| disks unreadable, right? Since it would be quite hard to get that
| key out of it.
|
| Guess thats what recovery keys are for...
| ulzeraj wrote:
| This thing right here makes me unconfortable. I don't want
| Microsoft signatures or any other company for what matter to be
| involved in my boot process.
|
| > The UEFI firmware invokes a piece of code called "shim" (which
| is stored in the EFI System Partition -- the "ESP" -- of your
| system), that more or less is just a list of certificates
| compiled into code form. The shim is signed with the
| aforementioned Microsoft key, that is built into all PCs/laptops.
| amarshall wrote:
| Almost all UEFI firmware allows replacing the default public
| keys with your own, and then you can sign everything yourself
| with private keys only you possess.
| Foxboron wrote:
| In theory. But part of the UEFI boot chain is Optional ROM
| files stored on hardware. Most commonly found on dedicated
| graphics cards and other hardware.
|
| All of these files need to be authenticated, and currently
| signed by Microsoft or the OEM vendor. A modern Lenovo
| Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation
| fails for the GFX card you are essentially "soft bricking"
| the device since the GFX card won't work.
| g_p wrote:
| An idea I just had around this, for if you run your own
| PK/KEK/DB chain - is it feasible to "dump" these Option
| ROMs?
|
| If so, you should be able to whitelist their sha256 hashes
| in your DB database, since the DB can contain an allow-list
| of hashes, as well as an allow-list of public keys.
|
| I'm not familiar with how to view relevant Option ROMs, but
| if you can "dump" them in the format they will be verified
| in, you should be able to put those into your DB database.
|
| Perhaps there could even be an open/peer-vouched
| crowdsourced set of such DB entries maintained for popular
| systems?
| Foxboron wrote:
| sysfs doesn't like some optionroms, so using the rom
| files from there wont work in some cases. Apparently they
| can be stored in an ACPI table.. but I haven't looked at
| it.
|
| Another alternative is to read the TPM2 eventlog. It
| should record OptionROM checksums found during boot.
| $ tpm2_eventlog ./t14_eventlog | grep
| "BOOT_SERVICES_DRIVER" | wc -l 7
|
| This is essentially what me and Trammell Hudson has been
| thinking about. But I don't have any available machines
| to test this with, and I haven't gotten around to setting
| up a QEMU vm to test out this theory.
|
| https://github.com/Foxboron/sbctl/issues/85#issuecomment-
| 886...
| g_p wrote:
| Good idea RE the TPM event log - that should show the
| definitive perceived hash of the option ROM.
|
| Will need to see if I have any computers that require an
| Option ROM - somehow I suspect shipped-with-Linux Dell
| XPS laptops aren't going to be good test candidates.
| blibble wrote:
| I completely replace the entire set of secure boot keys
| with my own (no MS keys at all)
|
| for my desktop PC I had to sign the graphics card option
| ROM digest myself (which was a pain)
|
| however for my Thinkpad none of this was necessary as the
| firmware was stored inside the UEFI image
| egberts1 wrote:
| I only wish that package maintainers (outside of OS distro)
| installed directly directly into /usr/local/bin but instead they
| wanted "in" on the /usr/bin placement. So, We lost there as this
| would have facilitated secondary signing of non-OS packages by OS
| distro.
|
| Doesn't help when Fedora started muddling (merging) /bin and
| /usr/bin. So, secondary signing for non-OS vendors just went out
| the window.
| https://freedesktop.org/wiki/Software/systemd/separate-usr-i...
|
| Even systemd is just now complaining about that during boot up
| (if the /usr partition somehow got invalidated during bootup).
|
| This multi-tiered */bin is that hallmark of Unix (and
| continuously the (Linux Filesystem Standard
| https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf ).
|
| -- Althou, systemd designer seems to disagree with this LFS
| approach. (IMHO, he needs to look deeper into the overall aspects
| of package signing architecture by OS-distros, and not just for
| Fedora)
| https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
|
| Now if Debian would just arrest the slide into a singular binary
| directory, all would be good.
|
| Linux Distros are about to be ignoring this future need of multi-
| island/multi-signing of encryption/immutability.
|
| No embedded Linux distro should want to be Windowized, much less
| the desktop Linux, unless they too seek this single island
| approach for immutably-verified/encrypted binaries of OS,
| vendors, and customers.
| wereHamster wrote:
| Yeah, let's move to the complete opposite side: one /bin for
| each package. You can have that today, in NixOS.
| egberts1 wrote:
| We know that package containerization (a la Apple, or NixOS)
| didn't expand well either for the vendors/maintainers who
| want to include their products into multiples of OS distros.
|
| And currently this probably would be very difficult to
| implement a signed-immutable binaries with regard to multi-OS
| distros vs multi-vendors.
|
| So, the nice sweet convergence is probably hovering around
| hardware/OS/vendor grouping somewhere.
| amarshall wrote:
| The problem is: where is the line drawn? Everything (and I mean
| everything) in many Linux distros (including Fedora) is just a
| package. There's no base system, unlike in most BSDs.
|
| Further, each of those packages can (and often are) updated
| independently of each other, confounding somewhat attempts at
| signing the root of that hierarchy. macOS signs the whole base
| system, but that also means that updating a single bit in it is
| a big lift (not that that's bad, but it's certainly different).
|
| Personally, I agree that have some signed base system is
| valuable, but I also struggle to find attack vectors it
| prevents that a signed initrd (in a sense, it's a base system)
| doesn't.
| egberts1 wrote:
| Yes, initd is essentially a clone of /bin, et al.
|
| Initd's /bin probably is going to be needing to be signed
| differently from main root mount point.
| amarshall wrote:
| initrd is a (very) small subset, far from a clone.
| losingom wrote:
| >Authentication of boot loaders is done via cryptographic
| signatures [...] the cryptographic certificates that may be used
| to validate these signatures are then signed by Microsoft
|
| This is what concerns me. While Microsoft are indeed dominant,
| surely them signing these is a conflict of interest? Why can't
| there be an external body that signs these, including those for
| Microsoft?
| mjg59 wrote:
| > Why can't there be an external body that signs these,
| including those for Microsoft?
|
| There can be, and I strongly suspect Microsoft would _prefer_
| there to be - reviewing and signing all the UEFI drivers
| consumes significant resources. Nobody else with sufficient
| resources to do this job has stepped forward.
| dane-pgp wrote:
| > Why can't there be an external body that signs these
|
| Just wait a few years, and it will be the government that
| decides which OSes can run on your hardware. Hint: It will be
| OSes that only allow "approved" apps to run.
| g_p wrote:
| The "default" boot chain is using a Microsoft CA key, but you
| can easily change it. In fact, the "root" for your system is
| the platform key, which is most probably signed by your OEM.
|
| Pragmatically speaking, I'd be more worried about my OEM's
| platform key being compromised when someone leaks their UEFI
| firmware build tree through a ransomware attack or similar.
|
| The biggest issue of the Microsoft "CA root", is that they sign
| everything - there was a good example [1] of them signing a
| Kaspersky rescue CD that could effectively break the secure
| boot chain.
|
| The good news is you can load your own keys into your
| motherboard. It's only really a solution for enterprises or
| tech-savvy individuals, but it at least is a viable option and
| helps you to "own" your own platform.
|
| [1] https://habr.com/en/post/446238/
| gautamcgoel wrote:
| Does FreeBSD do a better job addressing the issues he raises?
| vermaden wrote:
| I did not read the article but the FreeBSD bsdinstall(8)
| installer gives you the option to use the GELI full disk
| encryption with ZFS on top of it.
|
| Its kinda similar to LUKS on Linux and will ask you for
| password in the bootloader.
|
| Here are the details:
|
| https://docs.freebsd.org/en/books/handbook/disks/#disks-encr...
|
| Regards.
| sam_lowry_ wrote:
| After taking over the process #1, Lennart Poettering decided to
| go deeper and take over kernel, initrd and bootloader.
|
| I sometimes wonder whether he is on the NSA payroll. Lennart
| Poettering and Moxie Marlinspike are two people NSA should really
| strive to buy and/or intimidate.
| fmajid wrote:
| Signal is partly funded by the US government:
|
| https://www.opentech.fund/results/supported-projects/open-wh...
| sam_lowry_ wrote:
| This is all totally unsubstantiated, but...
|
| Sinal's reliance on phone numbers and their point on
| encrypted e2e communication facilitates meta-information
| gathering for the governments of the world.
|
| As for Pottering, he is an old-time RedHat employee, and
| RedHat is supplying virtually all governments of the world.
| selfhoster11 wrote:
| So is Tor. Is there any other reason to suspect foul play?
| [deleted]
| amarshall wrote:
| > take over kernel, initrd and bootloader
|
| Huh? There are not really any Kernel or bootloader changes
| proposed here, just signing them and using existing
| functionality within them. (Okay, I guess he proposes adjusting
| the Kernel to optionally have a way to authenticate parameters,
| but is that really "taking over"?)
|
| As for initrd, he's just talking about adjusting the way their
| generated to be more static and modular to simplify signing.
| Yes, there's some tooling to do this proposed as part of the
| systemd organizational umbrella, but systemd isn't a monolithic
| thing.
|
| Regardless, and just like systemd, you don't have to use any of
| this if you don't want to.
| dbrgn wrote:
| Instead of attacking the person (ad-hominem), how about
| discussing the technical merits and deficiencies of the
| proposed solution to a real problem that no Linux distro has
| tackled so far?
|
| I'm sure the NSA is happy about unauthenticated initrds. I'd be
| very surprised if such manipulation was never used in practice.
| 0xdeadb00f wrote:
| Their accusations are bold and brash, but this is not an ad-
| hominem.
| dbrgn wrote:
| Instead of discussing the ideas presented, the _person_
| behind the ideas is discussed. In my book, that's pretty
| close to an ad-hominem, even if the accusations are only
| implied.
| selfhoster11 wrote:
| I don't think it's an ad hominem, because this is a viable
| attack vector. What better way to get access to countless
| systems than by compromising the supply chain?
| BrightGlow wrote:
| Which operating system doesn't have this attack vector? Is
| there one that somehow doesn't have a supply chain?
| bloopernova wrote:
| Is it possible to set up an encrypted+authenticated boot that
| relies on a hardware token being present? In other words, only
| boot this OS if the Yubikey is inserted?
| kevincox wrote:
| It definitely is. The easiest way is to set up the token in
| challenge-response mode (supported by yubikey). The disk has a
| key which is sent to the token and the response is used to
| decrypt the disk.
| sam_lowry_ wrote:
| Does not LUKS already work with Yubikeys [1]?
|
| [1] https://github.com/cornelinux/yubikey-luks
| kevincox wrote:
| Based on the description of that repo it does exactly what
| I suggested you can do.
| maverwa wrote:
| According to the docs ([0], [1]) systemd-cryptenroll and
| crypttab support FIDO2 and PKCS#11, both should be supported by
| the yubikey as well.
|
| So without having tested it: I think yes, it should generally
| be possible, at least for encryption.
|
| [0]:
| https://www.freedesktop.org/software/systemd/man/crypttab.ht...
| [1]: https://www.freedesktop.org/software/systemd/man/systemd-
| cry...
| nsajko wrote:
| See my top-level comment. Just put the initrd and secret on the
| external device.
| egberts1 wrote:
| Did you just assumed that /bin and initd are separate by the
| virtue of "cloning-by-initd" and thusly needing to be
| differently signed by necessity?
| MayeulC wrote:
| I haven't read the whole essay (stopped at "In detail"). So far,
| I agree with most of what Lennart said, it matches my analysis,
| except perhaps this:
|
| > _3. The OS configuration and state (i.e. /etc/ and /var/) must
| be encrypted, and authenticated before they are used. The
| encryption key should be bound to the TPM device; i.e system data
| should be locked to a security concept belonging to the system,
| not the user._
|
| Not sure you actually need a TPM for this, there are a few
| alternatives:
|
| - Use a generic system configuration until you get to the user
| prompt. This doesn't require encrypting the partition, only
| authenticating it.
|
| - After user authentication, either unlock the shared /etc
| configuration from a password stored in the encrypted user
| partition (could be protected by the TPM to avoid users leaking
| it).
|
| - Or, the better (IMO) option is to get rid of that "shared"
| /etc, and allow each user to have a unique, system-wide set of
| parameters (with a "safe mode" in case they need to recover). Not
| allowing users to install arbitrary software while there are
| tools like overlayfs is a bit backwards IMO, unless there's a
| company policy, but in that case capabilities can be dropped
| before, or the user can be limited on a case-by-case basis.
| phh wrote:
| Every time I read stuff about secure boot, "evil maid" attack
| scenarios come up. And every time, they fail to mention the
| easiest one.
|
| The attack described here involves dismantling the victim's hard
| drive. I have an attack that isn't defeated by secure boot, and
| doesn't even require dismantling anything.
|
| Steal the original laptop. Take another physically identical
| unit. Replace it. Copy the login screen of original laptop on a
| brand new laptop, and have it log the password when the victim
| types it to you over wifi.
|
| There. I stole your data. Without any security flaw. In the exact
| same threat model described.
| uuidgen wrote:
| > Copy the login screen of original laptop on a brand new
| laptop, and have it log the password when the victim types it
| to you over wifi.
|
| This is why you need mutual authentication. The easiest is with
| 2 passwords. You enter a password, this authenticates you to
| the system. Now system presents you some secret. It may be a
| passphrase, something not obvious like a password prompt with a
| typo, or a splash screen with some pixels a bit off that are
| visible at the right angle. Something that a casual shoulder-
| surfing won't gather. Only when the system is authenticated to
| you then you enter the 2nd password o actually unlock the
| filesystem.
|
| As for "identical replacement" of a system - good luck. A bit
| of glitter and nail polish on screws and it will cost a fortune
| to do so. If you have those capabilities you probably have the
| capabilities to "nicely ask me for the password".
| rcthompson wrote:
| If someone is considering an "evil maid" style attack, the
| objective is to compromise your security without you knowing
| (so that you will continue using the device believing it is
| still secure). "Asking nicely" isn't going to accomplish
| that.
| WaitWaitWha wrote:
| We used glitter glue on ports for certain traveling
| individuals. Took pictures of the hardened glue. Very hard
| for a maid to replicate, be it evil or really good.
| vbezhenar wrote:
| I think that this attack is not possible to prevent without
| hardware tokens. At least user will be immediately aware that
| something's not quite right.
| markjenkinswpg wrote:
| The solution is to use an HSM such as the Nitrokey/Purism
| Librem Key (same thing) that has a LED that lights up if boot
| integrity is fine, including a TPM secret matching (maid can't
| clone that).
|
| https://www.youtube.com/watch?v=O_3Xf3gTzEE
|
| https://www.youtube.com/watch?v=K1O-33pi33M
|
| https://www.youtube.com/watch?v=SB82Ul_A1js
| rcthompson wrote:
| This is essentially the same solution, right? It boils down
| to having a single device that verifies the integrity of
| everything and never letting that device out of your sight.
| It's just marginally easier to do that when the device in
| question is an HSM rather than a laptop.
| nsajko wrote:
| Replicating the chassis (including the scratches, etc.) and
| other laptop parts is the hardest part of your attack. I assume
| you don't know about the nail-polish with glitter based
| protection?
|
| Even "copying the login screen" is not necessarily easy.
| phh wrote:
| You know the scratches on the chassis of your laptop? I
| definitely don't. If someone replaces my laptop with a brand
| new one, I'll notice something is off, but I wouldn't be
| surprised I'd notice /after/ typing my password. If rather
| than brand new, it's replaced another laptop with
| approximately same age/usage, I would most definitely not
| notice.
|
| > I assume you don't know about the nail-polish with glitter
| based protection?
|
| Nope, can you explain?
|
| But okay, you may extend my attack by saying that you
| exchange the motherboard between the victim and the attacker
| laptop, so that you don't need to replicate the chassis.
|
| > Even "copying the login screen" is not necessarily easy.
|
| Personally my login screen is ubuntu's default FDE screen
| untouched, so there is literally no work involved to attack
| me there. I have absolutely no idea how to customize FDE
| screen. But even if I did, I'd expect that it would be pretty
| easy to plug in an HDMI capture to have a close-enough
| duplicate of the screen.
| nsajko wrote:
| This is what I meant: https://www.wired.com/2013/12/better-
| data-security-nail-poli...
| Foxboron wrote:
| >But okay, you may extend my attack by saying that you
| exchange the motherboard between the victim and the
| attacker laptop, so that you don't need to replicate the
| chassis.
|
| Modern computers has tamper detection and if you open them
| you'll need to type the BIOS password.
|
| However, replacing the motherboard is going to replace the
| TPM. This is easily detectable with something like
| tpm2_totp in the bootchain.
|
| https://github.com/tpm2-software/tpm2-totp
| phh wrote:
| Now we're talking proper security, thanks.
|
| > Modern computers has tamper detection and if you open
| them you'll need to type the BIOS password.
|
| Is that somehow configurable from Linux distribution's
| setup, or it will require user to manually set a BIOS
| password? (and it requires the user to set a different
| bios password. if the user sets the same password for fde
| and for bios, then back to square 1)
|
| > However, replacing the motherboard is going to replace
| the TPM. This is easily detectable with something like
| tpm2_totp in the bootchain.
|
| That sounds interesting. Though it still sounds totally
| impossible for the vast majority of users.
|
| At that point, I don't really know what's the goal of
| TFA. If it's for extreme power users who want best
| security, it is missing the various counter-measures
| mentioned in this thread. If it's about pushing
| distributions to have better defaults, then I think it's
| quite moot, because secure boot won't improve security
| much to average users.
| Foxboron wrote:
| >Is that somehow configurable from Linux distribution's
| setup, or it will require user to manually set a BIOS
| password? (and it requires the user to set a different
| bios password. if the user sets the same password for fde
| and for bios, then back to square 1)
|
| Not yet? And when I said "modern computers" i should
| probably clarify I'm thinking about more enterprise grade
| computers. Such as Thinkpads.
|
| Thinkpads also recently got the feature to set the
| password from Linux userspace. But I forget where I read
| that, and where the patch is located :)
|
| >That sounds interesting. Though it still sounds totally
| impossible for the vast majority of users.
|
| It is. But this is why threat modelling is important. If
| a realistic threat scenario is someone replacing your
| motherboard, then tpm2_totp should be something you
| setup.
|
| Listing all possible attack scenarios and assuming any
| generic distribution protect fully against them is a pipe
| dream. There needs to be some compromise between
| usability and security.
| WaitWaitWha wrote:
| >> I assume you don't know about the nail-polish with
| glitter based protection?
|
| >Nope, can you explain?
|
| You take clear, semi-liquid glue that hardens. The glue has
| various colored Mylar flexes (aka glitter) floating in it.
| Slather it onto a device (we did it for exposed ports on
| devices). The glue is semi-liquid so it will flow
| reasonably. Once the glue hardens, the orientation,
| distribution, coloring and such of the flex are set. Take
| picture(s) of the hardened glue. (just search for glitter
| glue)
|
| Reproducing the complexity of the glue plus glitter is very
| hard. Possible attacks is attempting to remove it, and
| inserting it back in. The right glitter glue is quite
| brittle so hard to remove it. Heating it will make it hazy
| before pliable, and cooling it makes them even more
| brittle. Breaks show up as while surface inclusion in the
| glue.
| remuskaos wrote:
| That's what those countless convention stickers are for,
| they're basically a cryptographic hash of all the leet stuff
| you've attended.
| orthecreedence wrote:
| I can just count the missing screws on the bottom.
| LeifCarrotson wrote:
| This or the 'glitter nail-polish' pseudo-holographic
| identifiers both ignore that if you have a physically
| identical laptop save cosmetics, you can swap in the
| motherboard and hard disk from the replacement unit.
| Externally, it's identical, internally it's all compromised.
| egberts1 wrote:
| We haven't found a l33t who can swap an macOS motherboard
| in 15 minutes.
| NavinF wrote:
| Hmm it took me 2 hours when I had to do this a few years
| ago, but I'm pretty sure I could do it in 15 minutes if I
| practiced a few times and had 3 drills with two torx and
| one phillips driver bits.
|
| Swapping the SSD and adding a keylogger to the ribbon
| cable would be a lot faster too, maybe 5 minutes with
| practice.
| miloignis wrote:
| If you put the nail polish on the screws or seams, you
| could make it where you couldn't take apart the laptop to
| replace the motherboard without damaging them, right?
| dane-pgp wrote:
| Presumably the laptop could be designed such that opening
| the case would separate some contacts in a circuit, which
| in turn would clear some important secret value from
| memory.
|
| If you have a separate authentication device, it could warn
| you that this had happened, to prevent the attack of
| someone opening the case to add a circuit which broadcasts
| your key presses, for example.
|
| This still only reduces the problem from keeping your
| laptop with you at all times to keeping your authentication
| device with you at all times, though.
| noahbliss wrote:
| A significant issue is being able to protect your initramfs and
| your cmdline options during boot while still keeping the
| convenience of auto-unlock. By using the TPM to handle
| validation, you also cut yourself out of the mix by not knowing
| the password. Of course this comes with the risk of hardware
| attacks, but there is always a risk. Current distribution
| implementations DO NOT, EVEN WITH SECUREBOOT ON, verify the
| integrity of the initramfs, which can be repacked to include
| malicious code that will execute during boot, potentially
| intercepting your LUKS key. There have been a number of attempts
| to solve this problem, but the most complete appear to be Mortar
| (a project I head) and safeboot.dev
|
| I highly recommend taking a look at either of these projects if
| you want be able to improve both your convenience through auto
| unlocking, and security through broadened scope of audit.
|
| https://github.com/noahbliss/mortar
|
| https://safeboot.dev
| richardfey wrote:
| I would have preferred that the post started with the scenarios
| against one wants to fortify/harden, rather than an "everything
| on Linux sucks" one. Everything sucks depending from the
| perspective, Windows, Mac or Android are not perfect either.
| teddyh wrote:
| If your attacker is both sophisticated _and_ able to access your
| hardware directly, the game _is_ over; nothing we can do can
| currently avoid this.
|
| What we can do is address the scenarios in which an attacker is
| either _unsophisticated_ or _remote_. Normal network security
| takes care of the latter case, and for unsophisticated attackers,
| a good FDE (Full Disk Encryption) system covers it nicely. For
| laptops you can either live with typing in a password at every
| boot, or get a USB key of some kind. For _servers_ with FDE you
| might want to use something to enable remote and unattended
| reboots, like (shameless plug) Mandos1.
|
| 1. https://www.recompile.se/mandos
| [deleted]
| colek42 wrote:
| The issue isn't compromise of the remote system, but trust of
| that remote system. TPM 2.0 gives us the ability to make
| measurements before establishing trust.
| gear54rus wrote:
| How does one go about breaking FDE tho? If it's secured by a
| password that's only in your mind.
| xvedejas wrote:
| Keylogging? Depending on the bar for sophistication, I'm told
| this could be done by a microphone at the other end of town,
| or by measuring the power consumption of your building from
| the grid... but there's probably something at the middle
| point between these paranoid risks and something simple
| anyone could place in your computer case / keyboard.
| smoldesu wrote:
| > If your attacker is both sophisticated and able to access
| your hardware directly, the game is over; nothing we can do can
| currently avoid this.
|
| This, _particularly_ if your hardware has Thunderbolt
| capabilities. It 's been proven that Thunderbolt can be
| exploited to give an attacker direct memory access[0], and
| there's really no recourse for it in the spec. Physical access
| is going to be game-over for a very long time, unfortunately.
|
| [0] https://thunderspy.io/#affected-apple-systems
| mjg59 wrote:
| > there's really no recourse for it in the spec
|
| There's not only a recourse for it, modern firmware
| implements it. You just use the IOMMU to restrict Thunderbolt
| devices to being able to access their own buffers.
| [deleted]
| kobalsky wrote:
| > If your attacker is both sophisticated and able to access
| your hardware directly, the game is over; nothing we can do can
| currently avoid this.
|
| I think with blanket statements like this it's important to
| define sophisticated.
|
| For example, what kind of resources are required to break the
| disk encryption of a computer protected with tpm 2.0 +
| secureboot + luks w/tresor* ?
|
| I'm of course not talking about social engineering or fooling
| the user into typing their password on a fake system, since
| this is preventable.
|
| * https://www.cs1.tf.fau.de/research/system-security-
| group/tre...
| infogulch wrote:
| GP already made space for this analysis by admitting a
| sophisticated/unsophisticated axis, thus the contrary stance
| of your comment is unnecessary.
|
| You don't really make an argument on where your example
| should fall on that axis, which is what I would have
| preferred to see.
| kobalsky wrote:
| I think it's a fair doubt.
|
| In this case, I don't know if sophistication could mean an
| evil maid attack with a breadboard and $15 worth of
| electronic components (which was required to break the tpm
| 1), or something better than what the FBI has since they
| struggled to unlock a terrorist's phone. I can worry about
| the former, and relax about the later.
|
| I'm not an expert and when someone throws that statement
| with authority I'd like to know if I'm vulnerable to geek
| or to the CIA
| mnd999 wrote:
| It's certainly possible to MITM a TPM, this is why MS
| built all the keys into the CPU on the Xbox One[1].
|
| [1]
| https://www.platformsecuritysummit.com/2019/speaker/chen/
| hulitu wrote:
| > For example, what kind of resources are required to break
| the disk encryption of a computer protected with tpm 2.0 +
| secureboot + luks w/tresor* ?
|
| Intel ME and the equivalent AMD PSP.
|
| > I'm of course not talking about social engineering or
| fooling the user into typing their password on a fake system,
| since this is preventable.
|
| As other pointed out when the atacker has physical access it
| is game over. Also network access is insecure due to
| management engines.
| imwillofficial wrote:
| Again, Blanket statements. What ME flaws?
| belorn wrote:
| > For example, what kind of resources are required to break
| the disk encryption of a computer protected with tpm 2.0 +
| secureboot + luks w/tresor* ?
|
| There are two main vector of attacks to get access to the
| data. The simpler version are those that attempt to get they
| key by recording it when the user type it in, like hooking
| into the keyboard. No real need to try make it a fake system
| since no keyboard that I know of has security built in to
| prevent MITM attacks. If we are asking what spy agencies do,
| I would also suspect that the camera on a laptop could be
| replaced with a look-alike with a transmitter.
|
| The other main attack vector is to target the hardware while
| it is running and without waiting for the owner to type in
| the password. Get access to the main bus would be the primary
| target if the ram is not vulnerable (usb vulnerabilities,
| debug pins on the mother board, and so on). Vulnerabilities
| of the software is also an alternative, and if time is not a
| problem one could in theory wait until a vulnerability is
| found. I would assume that all internal connections are to a
| degree vulnerable to malicious designed hardware in mass
| consumer laptops, sever and desktops, but the main question
| is how to do it hot without crashing the machine.
| HanaShiratori wrote:
| Wait, did I miss something or how does a sophisticated attacker
| break encryption with ~100+ bit password entropy?
| droopyEyelids wrote:
| if they have access to your device, they don't have to.
| They'll just snoop on whatever you use to enter your key.
| Matt3o12_ wrote:
| I believe OP is referring to the fact that a sophisticated
| attack has access to the hardware and you continue using it
| afterwards. They could, for example, change the unencrypted
| /boot partition to log the password you use to decrypt your
| partition. Or, if you sign the boot partition, they could
| install a hardware key logger, or do any other kind of
| hardware modification that defeats the security. Preventing
| this kind of attack is incredible difficult. They are many
| means to prevent those kind of attacks but, for the most
| part, it just making it harder for the attacker so that the
| attacker needs to become even more sophisticated.
|
| Full disk encryption only helps if you are worried that your
| hardware gets stolen
| GekkePrutser wrote:
| Just wanted to add that this is generally referred to as
| the "Evil Maid" scenario in case someone wants to Google
| it.
|
| It can be mitigated somewhat with secure boot, tpm
| technologies etc but due to the breadth of possible attacks
| it's really hard to do against a serious attacker.
|
| Even the sound of the keyboard is often enough to give your
| password away.
| jkepler wrote:
| Or encrypt the boot partition. Libreboot supports this.
|
| (Though to be fair, Libreboot only runs on a very limited
| number of old devices).
| mikepurvis wrote:
| No amount of software complexity defeats a hardware
| keylogger, though... or like, a no-touch version of that,
| such as a spycam in the room that records the sight and
| sound of you typing your password.
| vbezhenar wrote:
| Security token defeats all that.
| markenqualitaet wrote:
| And glitter nail polish :)
| jonathanstrange wrote:
| Well, you can probably annoy at least some attackers by using
| tamper-proof seals on your PC case and act accordingly if they
| are broken, because that would likely prevent them from
| conducting the first physical attack. But that won't help in
| the long run.
|
| Outstanding locks on a reinforced door and a combination of
| visible and hidden cameras in the hallway are probably more
| effective.
| panarky wrote:
| All tamper-evident devices can be defeated by a sophisticated
| attacker with physical access.
|
| https://www.slideshare.net/MichaudEric/how-to-steal-a-
| nuclea...
| imwillofficial wrote:
| This is incorrect
| mjg59 wrote:
| > nothing we can do can currently avoid this.
|
| Unless you scope "sophisticated" as "can compromise hardware we
| currently believe is secure", we can get to the point where the
| only mechanism is a hardware keylogger (which is something made
| far more complicated by, eg, using a Bluetooth keyboard). This
| has a few problems:
|
| 1) It's relatively easy to detect - you're adding a new
| physical object 2) You're only seeing a small amount of what
| you want to see - you have no ability to inspect the data on
| the disk, and if the user is using MFA then getting their
| passwords doesn't get you much 3) Exfiltrating the data isn't
| easy. Either you need further physical access to extract the
| object, or you need it to broadcast data occasionally and
| that's another thing that's going to make it easier to be
| detected
|
| If you're able to move from "A physically present adversary can
| compromise the system in a way that gives them complete access"
| to "A physically present adversary can log your keystrokes",
| that's a _win_.
| fidesomnes wrote:
| apparently nobody has introduced you to Intel vPro.
| colek42 wrote:
| The Linux kernel's Integrity Measurement Architecture can be used
| with the TPM to establish trust of the filesystem. ref:
| https://www.redhat.com/en/blog/how-use-linux-kernels-integri...
| contingencies wrote:
| Set up a new laptop for Ubuntu recently and opted for ZFS
| encryption, impressed it was now a mainstream install option.
| Sadly amused after setup that it suspends indefinitely without
| requiring the passphrase, ie. keeps unlocked volumes in memory.
| This makes the encryption basically pointless. (NB. This category
| of issue was highlighted in the recent interview by the
| resurfaced Alpha Bay operator, specifically after his former
| associate Cazes was bagged in Bangkok after an international
| police sting allegedly created a server issue explicitly to
| require him to log in to the so they could access his credentials
| unencrypted. The resurfaced operator's reported solution was
| apparently to always power down, even on a bathroom break.)
| privacyxpert wrote:
| Just a heads up, you should be aware that ZFS encryption leaks
| considerably more metadata than full LUKS block encryption.
| yyyk wrote:
| This is a thoughtful post, yet it is useful to think again about
| the threat scenarios.
|
| Poettering mentions three: The obvious 'basic' one, and two
| advanced scenarios focused on a thief stealing the computer and
| then returning it. I recall exactly one case close to the these
| latter two scenarios: When Mossad stole a Syrian laptop allegedly
| containing nuclear weapon program information and returned it[0].
|
| However, I do not think Poettering's proposal is going to even
| annoy Mossad-level operations. The same people who can steal your
| harddrive and put it back in without notice, can for example
| replace your mouse with a BadUSB device and get all the info that
| way. Once they got hardware access, and were able to return it
| without the owner noticing, they have multiple ways of getting
| what they want. On Linux we can't be assured of controlling the
| hardware Apple-style.
|
| So this is a proposal which probably doesn't stop the advanced
| and rare scenarios it thinks it stops. In return, we get more
| complexity by splitting the system into at least three
| components*, and going back into the partitioning mess ("You only
| gave 300GB to /home, in order to download the ISO you want you
| need to repartition the system").
|
| IMHO, the cost-benefit ratio for splitting the system isn't good
| enough. We should try a simpler solution with the main purpose of
| stopping the basic scenario. Maybe dm-crypt everything, despite
| the minor speed loss? Or use fs-level authentication/encryption
| a-la fscrypt? Either solution still allows people who want to
| split the system to do so.
|
| [0]
| https://www.theregister.com/2009/11/06/mossad_syria_trojan_h...
|
| * The authenticated base system, the encrypted base system, and
| at least one encrypted home directory. In most system there will
| also be an encrypted swap partition.
| JonathonW wrote:
| > In return, we get more complexity by splitting the system
| into at least three components*, and going back into the
| partitioning mess ("You only gave 300GB to /home, in order to
| download the ISO you want you need to repartition the system").
|
| Is there anything akin to APFS containers [1] in the Linux
| space? APFS's ability to share space between multiple
| filesystems is, among other features, how Apple is able to get
| away with splitting the filesystem up similarly to Poettering's
| proposal. (They don't go quite as far; they have a signed,
| sealed system volume plus a single user volume rather than
| Poettering's multiple user volumes, but the split is still
| there and therefore runs into the same issue of space
| allocation.)
|
| [1]
| https://en.wikipedia.org/wiki/Apple_File_System#Partition_sc...
| yyyk wrote:
| I think btrfs subvolumes can do this? However btrfs doesn't
| (yet?) support encryption.
| Iolaum wrote:
| I am using BTRFS and FDE encryption right now on Fedora
| Silverblue for a year if not more.
|
| And like the post says, I am typing two passwords.
| yyyk wrote:
| I'm talking about filesystem level support, not block
| level support. FDE is block level and of course will work
| on any supported filesystem including btrfs.
|
| What btrfs doesn't do is support encryption inside the
| filesystem a la fscrypt - where we can encrypt specific
| directories - or ZFS encryption, where we can encrypt
| specific filesystems inside a pool.
|
| If I understand btrfs right, supporting
| encryption/verification on subvolume or directory levels
| would allow splitting the system so only part of it is
| encrypted/verified (so we get Poettering's performance
| gains), while avoiding space issues between the
| subvolumes.
|
| Also, using only one password is easy on fscrypt style
| systems, though this may not suit everyone's threat
| model.
| curt15 wrote:
| fscrypt support for btrfs is apparently under
| development; see the most recent comments at
| https://github.com/btrfs/btrfs-todo/issues/25
| uzakov wrote:
| > IMHO, the cost-benefit ratio for splitting the system isn't
| good enough.
|
| A while ago I wrote a guide on a system that has good cost-
| benefit ratio in terms of security and amount of effort
| required. It is a bit outdated for 2021 but overall still good
| imho https://uzakov.io/2017/05/08/pretty-good-setup-pgs/
| amarshall wrote:
| I'm pleasantly surprised to realize this is from Poettering, as
| it gives me hope that it may actually find its way to being
| adopted. What he says is right: Linux is _way_ behind others
| (except maybe the BSDs) in authenticated boot.
| royragsdale wrote:
| Two projects that are interesting and relevant work to address
| portions of this space are safeboot (https://safeboot.dev/) and
| heads (https://osresearch.net/).
| mschuster91 wrote:
| > Some corners of the community tried (unfortunately successfully
| to some degree) to paint TPMs/Trusted Computing/SecureBoot as
| generally evil technologies that stop us from using our systems
| the way we want. That idea is rubbish though, I think.
|
| It's not as rubbish as the author wants to think. Just look at
| the current state of Android SafetyNet attestation - a myriad of
| apps refuse to run entirely (banking apps, games) or with reduced
| quality (Netflix) on unlocked bootloader / rooted systems. There
| are workarounds but these are a) a constant cat-and-mouse game
| and b) the only known workaround against online SafetyNet
| attestation (pretending that the device does not have a TrustZone
| element, forcing SafetyNet to Basic attestation) is bound to fail
| as soon as Google is reasonably certain that there is no hardware
| floating around that has the latest Android but no TrustZone
| element.
|
| Additionally, look at what happened to Microsoft's ARM
| adventures. Locked down to the point of being utterly useless, on
| top of MS not providing a Rosetta equivalent.
|
| The problem is that here the interests of hackers (who either
| want as-open-as-reasonably-possible devices or, like the author,
| as-secure-as-possible devices) and big corporate interests (who
| want to keep license holders happy like Netflix, want a way to
| reduce successful "my device got pwned, someone stole my money,
| refund me!!!" claims like banks or fight against cheaters)
| collide in a position that's hard to make something decent out
| of.
| no_time wrote:
| I would LOVE tpms and every other hardware security feature if
| the had an user override that allows me (and only me) to
| control what the device does. Basically the opposite of the
| current and forseeable landscape.
| aseipp wrote:
| The modern Windows ARM laptops all(?) use standard x86 Secure
| Boot/UEFI rules, as far as I know. You can install Linux on
| them pretty easily; I know at least Fedora/Anaconda supports
| ARM64 pretty well. The bigger problems come after that but are
| more of the same stuff, i.e. lack of drivers for peripherals,
| you're dealing with Qualcomm, etc.
| clipradiowallet wrote:
| In other news, operational security is just as important as
| technological security measures. This means _not_ leaving your
| device unattended, and if you do, implementing tamper detection
| of some variety. This can be as simple as a battery operated
| motion activated video recorder hidden and aimed at your
| equipment. You can pick one up for $25 on amazon.
| hsbauauvhabzb wrote:
| I kinda think the claims about not encrypting /use are fairly
| dubious. What's to stop an attacker replacing a lib with a
| signed+known vulnerable lib? As far as I know there's no
| mechanism for revocation.
|
| What's to stop this occurring to the kernel and/or boot loader?
| Maybe the TPM but idk
| amarshall wrote:
| From the article:
|
| > The OS binary resources (i.e. /usr/) must be authenticated
| before being booted into. (But don't need to be encrypted,
| since everyone has the same anyway, there's nothing to hide
| here.)
|
| Authentication prevents manipulation. Encryption is not
| necessary to do so (encryption often also authenticates).
| Foxboron wrote:
| Keeping it on a seperate blockdevice allows dm-verity to
| authentice the device. This value would be signed and secured,
| so injecting a signed+known library wouldn't work. It would
| refuse to mount.
|
| It should be noted that keeping it unencrypted is only for the
| traditional linux package manager usecase.
| cmurf wrote:
| Can a TPM be shared by two operating systems? As in, dual boot
| configurations? Is any sort of deconfliction required and does
| the relevant spec account for this?
| mjg59 wrote:
| > Can a TPM be shared by two operating systems?
|
| Yes.
|
| > Is any sort of deconfliction required
|
| No.
| nebulous1 wrote:
| There's definitely something to be said about assumptions here.
|
| I knew all/most of the mentioned high level details regarding
| SecureBoot and the TPM. However, I would have assumed that a TPM-
| enabled linux distro would have authenticated everything up to
| the FDE password prompt at a minimum as not doing so would seem
| to completely defy the point! Turns out this assumption is wrong.
| weinzierl wrote:
| Only had time to skim it, but even without all the details it is
| an excellent overview of the state of the art regarding secure
| boot chain. You can learn many of the points by looking into the
| Android boot sequence but this is a more generic and _'
| everything in a single place'_ write-up. Especially the
| mechanisms behind _dm-verity_ seem to be not widely known and -
| in my view- underappreciated.
|
| > *This is all so desktop/laptop focused, what about servers?
|
| I know that some of the more powerful and Linux based automotive
| embedded systems use a similar design. While important for
| desktop/laptop and servers the mentioned points are crucial for
| systems where physical security of the hardware is limited.
|
| Oh, and BTW, if _0pointer.net_ i doesn 't ring a bell: The author
| is _Lennart Poettering_.
| [deleted]
| codedokode wrote:
| Sadly, the described scheme doesn't protect from hardware
| backdoors. Let's say someone confiscates your laptop, installs a
| backdoor that sends all keypresses using GSM, and returns it to
| you. Now the attacker has all your passwords.
| nimbius wrote:
| "The shim is signed with the aforementioned Microsoft key, that
| is built into all PCs/laptops."
|
| this is a non-starter for me. the sheer number of microsoft
| products and programs dedicated to or endorsing a backdoor for
| third parties makes it untenable for any security purpose.
| selfhoster11 wrote:
| Strip the signature and sign with your own key? It's possible
| as a part of the Secure Boot model.
| stragies wrote:
| That ^^ feels like an important part of the HowTo. Is there
| one, that includes this step already?
| selfhoster11 wrote:
| I imagine that this is a documented generic process that
| works for all UEFI boot binaries. I can't point to any
| specific guide because I don't use UEFI in Secure Boot
| mode.
| nsajko wrote:
| An option that wasn't at all considered in the article is to have
| the initrd and (optionally) the secret key used for decrypting
| the disk on a separate device (or devices), for example on an 1
| GB USB drive. This way the big disk can have full, real FDE (not
| LUKS). To an attacker not in possesion of the USB drive the big
| disk just looks like random data. And the USB drive can be kept
| on one's own person and easily destroyed if necessary.
|
| The main part is having the initrd on an external, small, device.
| The secret can be either a regular passphrase, or stored
| somewhere on the small device.
|
| Works fine on my Archlinux. I mount the initrd file system to
| /boot when I need to update it.
| SkyMarshal wrote:
| _> This way the big disk can have full, real FDE (not LUKS)._
|
| I thought LUKS was the only way to do FDE in Linux. What other
| options for FDE are there?
|
| But yes, putting /boot on an external USB drive is the only way
| I know of get FDE on your hard drives. Possible with UEFI, not
| BIOS/MBR.
| nsajko wrote:
| LUKS leaves encryption metadata unencrypted. For real FDE,
| use "plain dm-crypt" with cryptsetup:
| https://security.stackexchange.com/questions/109223/what-
| doe...
|
| > Possible with UEFI, not BIOS/MBR.
|
| Why do you think that? I have this setup on a modern (UEFI)
| computer, but I use the old BIOS/MBR interface.
| teddyh wrote:
| > _LUKS leaves encryption metadata unencrypted._
|
| Except for ruling out plausible deniability, what problem
| does this pose?
| adgjlsfhk1 wrote:
| Metadata includes file names. If you have a file on your
| computer called proof_nsa_is_doing_illegal_stuff.pdf,
| that would significantly help a prosecutor trying to
| convict a wistleblower even if they can't get the file.
| Unklejoe wrote:
| No it doesn't. LUKS encrypts a block device, and then the
| filesystem is instantiated on that encrypted block
| device. No file names are visible.
| teddyh wrote:
| No, the LUKS header includes only _encryption_ metadata,
| not file system metadata.
| SV_BubbleTime wrote:
| Which is kinda funny on a laptop. If some authority told
| you to unlock a device and it did have a plausible
| deniability encryption system - no one is going to
| believe that anyway.
|
| For a USB drive or a file, sure, feature. For a laptop,
| "duh, it's encrypted" is going to be the first thing
| anyone considers. Not "well, I guess the laptop has no
| data on it at all!"
| r-w wrote:
| Hence, "plausible".
| deckard1 wrote:
| > LUKS leaves encryption metadata unencrypted.
|
| You can detach the header and store it on a USB drive, and
| boot from the USB drive. No one will know you're using LUKS
| at that point.
| SkyMarshal wrote:
| Huh, I thought BIOS/MBR required /boot to be on a partition
| at the beginning of the MBR and nowhere else, whereas UEFI
| allows it to be anywhere on the disk as long as its labeled
| with ESP.
|
| So with UEFI, you just label /boot on USB as ESP. How does
| it work with BIOS/MBR?
| mjevans wrote:
| That was an issue with older BIOS versions which also
| often didn't fully support LBA indexed sectors.
|
| Any system with a UEFI BIOS that has 'CSM' (compatibility
| support mode IIRC) should support arbitrary placement of
| the /boot partition.
|
| Today the main reason to put /boot early is for migrating
| to larger drives later, the start sector of many
| filesystems (including windows) can be left in place, and
| the size of the last partition, the data/system partition
| can then just be expanded.
| vladvasiliu wrote:
| Technically you boot form the USB, so the BIOS is happy.
| lugged wrote:
| Does this matter?
|
| I once went through the waste of time of getting /boot
| encrypted. Would rather avoid needless pain.
| nsajko wrote:
| It matters for deniability and for reliability. If you
| have LUKS, you really don't want to corrupt the header.
| sillystuff wrote:
| For servers that you need to unlock remotely, you will
| need to leave /boot unencrypted. But, for things like a
| laptop, grub has supported encrypted /boot for a while
| now (and it works well). But, the release versions still
| only support luks v1 (it was good enough for all those
| years, probably still fine for most folks mostly just
| worried about their laptop getting misplaced / stolen).
|
| add to /etc/default/grub to enable encrypted /boot
| support: GRUB_ENABLE_CRYPTODISK=y
|
| After encrypting /boot, you don't need anything besides
| ensuring that the less than 2MB of unencrypted grub
| bootloader that is installed before the first partition
| on BIOS machines or into /boot/uefi on uefi machines is
| verified to ensure that 100% of the boot process is
| trusted (and all your data too since 100% of the disk is
| encrypted except for < 2MB of boot loader).
|
| A simple way (if your threat model isn't mosad/nsa) is
| just checking a hash of this tiny bit of data whenever
| something sketchy has occurred with your laptop e.g., it
| is left unattended with airport security. Just boot from
| a thumb drive, and check the hash (it will only change if
| you e.g., change your filesystem type or grub gets
| patches). If OK, then boot is still trusted (at least
| what is on disk; if threat model makes you a possible
| target for hardware manipulation this nor Pottering's
| proposal will help you).
|
| Nice if this simple check of less than 2MB could be
| automated, but not in a complex and fragile way that
| removes freedom from the nominal owner of the computer as
| Pottering is suggesting.
| guipsp wrote:
| It matters for deniability. Whether this matters for you
| or not depends on your use case.
| geofft wrote:
| What does a laptop with a bunch of random data on its
| disk and a lot of evidence of use (grime, worn keys,
| etc.) let you deny that the same laptop with a generic
| Linux boot partition followed by random data does not let
| you deny?
| nsajko wrote:
| Let's put it this way: say you want to prevent somebody
| from getting the data on a disk. Wouldn't writing random
| data over the entire disk be a good idea?
| cmurf wrote:
| blkdiscard /dev/nvme0n1
|
| No need to write anything. Better would be to use nvme
| tools to securely erase it ("format" is the terminology
| used)
| lugged wrote:
| The idea is to give you the plausible deniability, you
| can tell the cops you wiped it with random data, there is
| no password.
|
| Your flash drive can't then be used as evidence that you
| haven't wiped it yet.
|
| The initrd on the drive would be evidence you haven't
| wiped the drive.
|
| Whether that gets you out of a jam and not in trouble for
| destroying evidence is another question.
| throwaway41597 wrote:
| So have one drive with FDE and a USB drive with /boot but
| in no explicit way configured to boot the first drive?
|
| Or maybe a better setup is an internal drive with /boot
| and a system stripped from sensitive files then somewhere
| in the drive an hidden partition (not sure how to avoid
| the vanilla OS overwriting the hidden partition), then
| you can either boot the vanilla OS or map the hidden
| partition and boot from it.
| selfhoster11 wrote:
| Now we are back to boot floppies of yore. Oh how the wheel of
| IT turns.
| rwmj wrote:
| Clevis/Tang ("network-bound disk encryption") is likely better:
| https://www.redhat.com/en/blog/easier-way-manage-disk-decryp...
| lifeisstillgood wrote:
| do you have any more details. My first thought is "how simple"
| then "what am I missing"?
| mkj wrote:
| Have to lug a usb stick around with you and guard it 24/7 for
| equivalent security?
| pengaru wrote:
| I use a datatraveler 2000 to store my kernel+initrd, only
| inconvenience is having to unlock and insert it whenever I
| boot my laptop.
|
| If I use the keyfile feature, the dt2000 boot will
| automatically unlock my FDE, making the inconvenience a bit
| of a wash with arguably improved overall security. It's
| also nice that I can unlock the dt2000 in private or
| otherwise independently from the laptop, since it has a
| battery. Think bathroom break to unlock, insert to boot on
| return kind of thing. It also supports a read-only mode,
| requiring switching to writable whenever updating the
| kernel/initrd.
| SkyMarshal wrote:
| Not necessarily. If this is for a desktop computer you can
| just leave the USB plugged in and the computer running, as
| normal. The threat model isn't too different between that
| and a normal home/office computer - in both cases you have
| to trust the physical security of your home/office.
|
| For a laptop, you're already lugging it around anyway, just
| remove the USB drive whenever you shut it down.
| WaitWaitWha wrote:
| Or, instead of a USB, you have a remote, networked, secure
| repository that behaves as such.
| nsajko wrote:
| Firstly, you'd probably want to make backups of the USB
| device with the initrd, in case one of them fails.
|
| To mount the decrypted disk during boot, it's necessary to
| make the kernel aware of the fact that it's something that
| should be mounted. There are several ways to do this, two of
| which are:
|
| 1. The most preferable way, I think, would be to use
| something like kpartx from multipath-tools. Kpartx is a very
| simple C program, and device mapper is used directly in that
| case. You could also use partprobe. So the command is
| something like `kpartx -a disk` or `partprobe disk`.
|
| 2. Another option is to use LVM, like described here:
| https://wiki.archlinux.org/title/Dm-
| crypt/Encrypting_an_enti... (there are also other encryption
| options described there). Using LVM is a solution that works
| more out-of-the-box, but, of course, then you always depends
| on LVM, which may not be something you want.
| lugged wrote:
| (slightly) slower boot time. Risk of data loss if your USB
| fails, more complicated backup procedures.
| pengaru wrote:
| There's nothing hard to replace in a kernel or initrd, it's
| just a matter of going back to the trusted source you
| originally used.
| SkyMarshal wrote:
| Yes, you should use a higher quality USB drive for this, or
| possibly an SLC NAND one with high write endurance. And
| make a backup copy or two and store them in faraday bags in
| a safe.
| deckard1 wrote:
| you're only going to write to the USB drive when you
| upgrade your kernel.
|
| all these worries are completely overblown. I've been
| using USB boot method for close to 10 years now. It's
| just another folder/mountpoint to backup along with your
| normal backup.
| SkyMarshal wrote:
| Anecdote != data. And unlike the other folders, if you
| lose this one you lose the whole system. And it's not
| just writes we care about, but bit flips for any reason.
| deckard1 wrote:
| > Anecdote != data
|
| Thank you Captain Obvious.
|
| > And unlike the other folders, if you lose this one you
| lose the whole system
|
| Yeah, that's how encryption works.
|
| > but bit flips for any reason
|
| Way to move the goalposts. Your typical laptop/desktop
| does not have ECC RAM. You're also not using mirrored ZFS
| anyway. So not only will you never detect corruption, but
| you have no way to correct it either. Which, again, is
| totally overkill for the average user.
| jvanderbot wrote:
| In the case you are mugged, that USB key is going with the
| mugger. (see also police raids or airport "inspections" e.g.,
| entering or leaving bad states) I prefer memorized keys, with,
| ideally, a duress passphrase for this reason.
|
| But, hypothetical scenarios without reasonable threat modelling
| is a losing man's game. You can never one-up a mythical
| adversary. Protecting against the easy 80% of threats takes
| only 20% effort.
| privacyxpert wrote:
| There are basically zero scenarios where using raw dm-crypt is
| recommendable over using LUKS(2) with a detached header.
|
| Some (good) distros even have built-in support for detached
| headers, even. I actually use detached headers on a number of
| my system and it just basically works out-of-box, compared to
| what I'd imagine you had to do to make raw dm-crypt work.
|
| Also, what is it with people that are determined to be smarter
| than LUKS? I've met another person online that was quite
| insistent that dm-crypt must be safer. Strangely, they stopped
| replying when I asked how they were securely storing a properly
| long AES key that they were then entering at boot, remotely or
| otherwise.
| simias wrote:
| >Unfortunately not at all. Because distributions set up disk
| encryption the way they do, and only bind it to a user password,
| an attacker can easily duplicate the disk, and then attempt to
| brute force your password.
|
| I think this "not at all" is a bit strong. With a good enough
| passphrase and a slow key derivation algorithm bruteforcing the
| key should be impossible in practice.
|
| The key derivation takes about 2s for my root partition for
| instance, fast enough that it really doesn't make a difference
| for a legitimate user but slow enough to be hugely impractical to
| bruteforce, especially given that I use a long, random
| passphrase.
|
| On the other hand the author is entirely right that this setup is
| rather simple to backdoor for a sophisticated attacker, but it
| does a good job of protecting the data at rest.
| jimsi wrote:
| https://github.com/xmikos/cryptboot/blob/master/README.md
| Foxboron wrote:
| I don't think a 5 year old project linked without context is
| appropriate when talking about modern boot chain security.
|
| It doesn't even support stubs so it fails at the first threat
| scenario described in this post.
| selfhoster11 wrote:
| I disagree. UEFI boot security is not that recent, and it
| hasn't changed so much as to render earliest approaches less
| secure.
| Foxboron wrote:
| It is less secure. The initramfs is not signed, along with
| the microcode.
| cesarb wrote:
| On a quick skim, I could see three issues with this proposal:
|
| 1. While each home directory is individually encrypted, since
| /home itself is not encrypted (unlike with current uses of full
| disk encryption), the user login names can be found unencrypted
| on the disk.
|
| 2. Since each home directory is individually encrypted, backup
| systems like borgbackup running as root can no longer easily
| backup everything.
|
| 3. As far as I could understand, this proposal does not have a
| mechanism to share disk space between the system and the user
| directories. This goes in the opposite direction of for example
| https://fedoraproject.org/wiki/Changes/BtrfsByDefault in Fedora
| 33, which allowed the whole disk to be used for files in /home,
| instead of always reserving IIRC 50 gigabytes exclusively for
| files outside /home.
| michaelt wrote:
| Also, once you've got per-user encryption on
| ~/.ssh/authorized_keys you'll need some other mechanism for
| users to log in.
|
| And don't think of having the users do their own backups -
| locking users' home directories mean they won't be able to run
| their own cron jobs.
| predakanga wrote:
| > Also, once you've got per-user encryption on
| ~/.ssh/authorized_keys you'll need some other mechanism for
| users to log in.
|
| OpenSSH supports this through the AuthorizedKeysFile
| directive - it'd be quite simple for the homedir mounting
| tool to sync that file from the user's authorized_keys file
| on unmount.
|
| You could also use SSH certificates, but that requires a CA -
| not ideal for the home user.
| aaronmdjones wrote:
| You can also store the file anywhere else, a la
| AuthorizedKeysFile /etc/ssh/authorized_keys/%u
|
| (For example, /etc/ssh/authorized_keys/bob)
| Nextgrid wrote:
| > backup systems like borgbackup running as root can no longer
| easily backup everything
|
| If you're using LUKS-encrypted volumes for home directories
| nothing prevents you from enrolling an extra key file entrusted
| to the backup program, or to the TPM (which the backup program
| can be allowed to access).
| kevincox wrote:
| But that defeats the whole point as now decrypting the system
| is enough to access all of the home directories. You are
| basically back to a FDE home partition with extra complexity.
| BiteCode_dev wrote:
| Are other people experiencing too many corruption problems on
| encrypted disks?
|
| I have a veracrypt drive, and I regularly have to run a scan and
| fix on it because it's very sensitive to power cut, brutal
| restart, etc.
|
| Also, it's slow. I put my firefox conf folder in it, but it slows
| the browser down.
|
| Once I went full encrypted disk, but one day corruption happened,
| and it stopped booting. So I went back.
| lathiat wrote:
| I've not used verycrypt, only normal Linux LUKS device mapper
| encryption, ZFS encryption and windows bitlocker full disk
| encryption with a paraphrase entered on boot (no tpm). But I
| haven't had this problem with any of those.
|
| I'd suggest either your SSD just loses data on power off which
| is a problem with some SSDs or it's some veracrypt specific
| issue that I wouldn't be familiar with.
|
| Id encourage you to try out one of the above options.
| vbezhenar wrote:
| I started using full disk encryption (except /boot) this year,
| so far no problems at all. I'm using ordinary luks on Fedora.
| withinboredom wrote:
| You probably have some fun disk caching turned on in the OS or
| your disk has a built in cache that it's not properly flushing.
| I've seen this before with cheap SSDs.
| BiteCode_dev wrote:
| Maybe, I don't know enough about this, but I've been using
| this veracrypt disk on 6 machines, now, and I have the
| problem with each of them.
|
| Also, I don't have any problem with non encrypted data.
| blablablub wrote:
| Looks like a veracrypt problem then.
| orthecreedence wrote:
| Maybe a dumb question, but are you on windows? Check that
| Defender isn't scanning every single time data is written
| to your veracrypt drive. When I was on windows, the most
| painful slowdowns were almost invariably caused by Windows
| Defender.
| deckard1 wrote:
| Never had a problem with LUKS over a decade of usage.
|
| In fact, I'm actually having the opposite issue: I have a drive
| that is failing and LUKS is still able to decrypt it by some
| miracle.
|
| > Also, it's slow.
|
| Modern CPUs have AES instructions built-in. I would check to
| make sure you're utilizing them. You should not see any
| slowdown when using encryption.
| snassar wrote:
| The better solution to these kind of problems is having a
| backup concept with an implementation and regular testing of
| backups.
|
| The encryption exposed a problem with your disks or system in
| general. Depending on what the problem was, the problem is
| still there but you are not seeing it. Now you have a possible
| problem and unencrypted files.
| BiteCode_dev wrote:
| I have a backup, but this is not a solution. Only a crutch. I
| had those problems on several machines, including brand new
| ones.
| theandrewbailey wrote:
| No. I run a server in my basement, and for the past 5+ years,
| every one of its drives have been LUKS encrypted, including
| external backup drives. I've had no issues with encryption
| (corruption, speed, or otherwise), only disk hardware failing
| outright.
| BiteCode_dev wrote:
| Servers and consumer laptop are very different beast though,
| so not sure the comparison hold. You don't shut them off
| often, they don't go to sleep, rarely undergo shock, plane
| travel or forced shut down...
| privacyxpert wrote:
| Friend, LUKS is reliable. LUKS doesn't just eat data in
| those edgecases you talk about, there would be tons of
| reports if that were the case. LUKS is used all over the
| place for non-server uses too.
|
| I can count at least 3 devices that are all LUKS-encrypted
| that are used as consumer devices daily. I trip over the
| power cord, I let the battery die, I drop it, I fly
| regularly, etc, etc. Never once had a single issue.
|
| In fact, the single time that I've had FS issues under
| Linux was running under Hyper-V but that's because of the
| slowly-being-uncovered serious issues w/ Hyper-V.
| amarshall wrote:
| Don't generalize your problems with a specific software
| (Veracrypt) to all drive encryption software. Plenty of drive
| encryption solutions are fast, reliable, and resilient. (You
| could also be having a hardware problem exacerbated by adding
| an abstraction layer.)
|
| I've used LUKS, GELI, ZFS encryption, FileVault, and BitLocker
| across numerous drives over the past decade (albeit in
| different individual proportions and timelines) with no
| corruption problems.
| supperburg wrote:
| "With LUKS, the encryption is as good as your password is
| strong." Well that was anticlimactic. I thought my entire setup
| would have to be overhauled.
| amarshall wrote:
| Did you read the whole thing? LUKS (or FDE in general) is not
| enough for the attacks presented. Partly because FDE is rarely
| ever the "full" disk.
| cmurf wrote:
| A keylogger in the initramfs seems like a pretty obvious weakness
| to try and exploit. From there the attacker eventually gets the
| password manager master password, as well as any disk encryption
| passwords.
|
| We could soon get to signed grub being able to read and
| authenticate from as fs-verity /boot on which initrd resides.
| Ext4 and recently btrfs support fs-verity and its more flexible
| than dm-verity.
| thayne wrote:
| On most linux distros the initrd is dynamically generated, and
| depends on the specific hardware. So it isn't possible for the
| initrd to be signed by the vendor. Is it possible for the TPM to
| verify such a dynamically created file during boot?
|
| Also, requiring a TPM for decrypting the hard drive has a
| security/usability tradeof. If the TPM dies, or possibly other
| components of the computer (like the motherboard), then you lose
| the ability to access the data on the drive altogether. While if
| it isn't you can still recover the data from the drive.
| psanford wrote:
| The TPM 2.0 spec has the ability to duplicate keys from one TPM
| to another for this type of use case. It of course requires the
| key policy to allow for duplication, so you have to plan ahead
| of time, but it is possible.
| tkfu wrote:
| The article already mentions both of those challenges, and
| outlines practical solutions/mitigations to both--can you be
| more specific about what you didn't like?
___________________________________________________________________
(page generated 2021-09-23 23:00 UTC)