5 ms·

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 (

• selfhoster11 5y ago
  Now we are back to boot floppies of yore. Oh how the wheel of IT turns.
• SkyMarshal 5y ago
  > 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 5y ago
    LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-does-luks-header-contain 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.
    • lugged 5y ago
      Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.
      • guipsp 5y ago
        It matters for deniability. Whether this matters for you or not depends on your use case.
        • geofft 5y ago
          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 5y ago
            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 5y ago
              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 5y ago
                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 5y ago
                  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.
    • SkyMarshal 5y ago
      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?
      • vladvasiliu 5y ago
        Technically you boot form the USB, so the BIOS is happy.
      • mjevans 5y ago
        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.
      • fuzzfactor 5y ago
        I like to have each Linux distro on a standard type 83 partition if in BIOS mode, or its corresponding 0FC63DAF-8483-4772-8E79-3D69D8477DE4 GUID if in UEFI. These are neutral dedicated storage designations for later EXTx formatting. With Windows to be on partitions of BIOS type 07 or UEFI GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. Once again neutral dedicated storage designations, for later NTFS formatting. Each distro is entirely self-contained on its own single volume, no separate /usr /home swap or anything else. This is analogous to a Windows install. But as intended, bootfiles can function properly from many different storage locations. In BIOS you will need boot files on a primary partition and it will need to be the primary which is marked "active" (bootflag 80 rather than inactive default 00). You will also only be allowed to have a maximum of 4 primary partitions in BIOS. But with correct bootfiles on an active partition you can boot to OS's that are on logical partitions too if you want to put them on your bootmenu. In BIOS you can have a /boot folder on the same primary that your distro is on and it can boot solely to the distro on that primary (no boot menu appears), or you can have more than one bootentry on the GRUB or Extlinux bootmenu, which triggers the bootmenu to appear and then you can boot to any other partition on the menu whether primary or not. Analogous to Windows in BIOS when the BOOT folder is on the same active NTFS volume as the OS folders. In BIOS Windows will boot Linux using a BOOTMGR entry pointing to a copy of the Linux volume bootsector, stored on the NTFS (or FAT as often seen when a commonly found "hidden" partition1 is used for Windows bootfiles) filesystem in the form of a file. Windows will not address files on type 83 or 0FC63DAF-8483-4772-8E79-3D69D8477DE4 volumes so they are hidden from Windows naturally without having to possess the hidden attribute. These partitions will be sensibly handled in diskmanagement, 0FC63DAF-8483-4772-8E79-3D69D8477DE4 will show as OEM rather than a blank table entry. Linux can mount FAT (FAT32's preferred type is usually type 0C) or NTFS whether it is marked hidden or not. Type 1C is hidden FAT32, type 17 hidden NTFS. In BIOS Linux can boot Windows if you want to put it on your GRUB bootmenu. It can be seen that you could have 4 primary partitions, each containing an independent Linux or Windows OS, with 4 specific boot folders, one dedicated to each OS on the same volume the OS is on. Whichever one of these partitions you designate with the bootflag will be the one that boots, and the other partitions if unhidden can then be mounted as ordinary storage volumes. You would never see a bootmenu and would have to change which primary has the bootflag in order to choose which OS to boot to. This is good when you need to boot to something different and do a comprehensive backup of a working volume but in its static dormant state, whether bitwise or file-based backup. Sometimes there are no spooks trying to cause mayhem, and the most reliable rapid backup & recovery methods need to be constantly rehearsed and revalidated foremost. However, in any one (or more) of these BOOT folders on any of the primaries you can trigger the display of its multiboot menu simply by adding a second (or more) bootentry of your choice to its default boot configuration file. You could even have identical full multiboot menus in identical BOOT folders on each volume, and even on an external bootable USB volume too. This gets analogous to UEFI where you only use one /EFI/BOOT folder on a special C12A7328-F81F-11D2-BA4B-00A0C93EC93B GUID ESP partition (but if not found then the first FAT volume the firmware recognizes), formatted FAT32 and readable by all. But in the EFI\BOOT folder there is just a .EFI file or 3 (like BOOTX64.EFI) which is what each OS install strategically renames its EFI bootfile as, which then points to its own specific \EFI\Microsoft or \EFI\debian ect. subfolder which takes it from there. The Microsoft subfolder will contain its bootmenu, better Linux distributions have it this way too (ie you can edit its GRUB bootmenu when booted to Windows because you can see it in the desired EFI\Linux subfolder), but some distros only link (during bootup) from their subfolder to their bootfiles on their EXT partition and can only be edited when booted to Linux. Now in UEFI I have not found a way to get Windows bootmenu to boot Linux. There should be a BCDEDIT switch that should do this like there is with BIOS BOOTMGR. If Microsoft starts to get serious about interfacing Linux this would be the first deficiency they will correct, so we will know if that occurs. It can be seen that Microsoft SecureBoot was developed in quite a stifling way when it comes to Linux. For instance if you need a live Linux distro to be bootable on any default PC which has Microsoft SecureBoot enabled, you definitely need to have a Microsoft-signed shim or something like that. Machine owner keys are good for all the top-secret operators and serious geeks but ordinary power users want things like that to just work with the same default Microsoft-signed key that Windows uses without having to insert custom keys into the mainboard firmware. The only key that's built into every modern PC is signed by Microsoft, simply because it's a PC not a MAC. Often the Microsoft-signed Linux SecureBoot shim will be renamed to BOOTX64.EFI which is what the firmware is looking for and from there the next bootfiles are signed by the distro. The problem is that not every Linux distro uses the same key/signature so there are some different shims, one from each major distro that overcame the SecureBoot obstacle by having a shim signed by Microsoft. This really makes UEFI highly defective when it comes to running live distros or multibooting, compared to how usefuil the same electronics is when SecureBoot is disabled or in BIOS mode. Except for those PCs that actually can enable SecureBoot in BIOS mode, how thoughtful. What's really needed from the author is fundamentally to get all distros onto the same shim first of all, so the Microsoft-signed spare keys for future Linux use built into the UEFI firmware do not all get blacklisted as fast in case events like that come along more often. In that case it's a lot more sensible to blacklist a single key for all distros rather than a bunch of keys at once because each major distro has a different one. Then move on to address much further the deep security needs of the most sensitive users, whether they are using Microsoft-signed shims, or their own machine owner keys which negate the need for shims when they are in use. Edit: corrected BOOTYMGR
    • teddyh 5y ago
      > LUKS leaves encryption metadata unencrypted. Except for ruling out plausible deniability, what problem does this pose?
      • adgjlsfhk1 5y ago
        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 5y ago
          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 5y ago
          No, the LUKS header includes only encryption metadata, not file system metadata.
      • SV_BubbleTime 5y ago
        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 5y ago
          Hence, “plausible”.
    • deckard1 5y ago
      > 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.
• lifeisstillgood 5y ago
  do you have any more details. My first thought is "how simple" then "what am I missing"?
  • lugged 5y ago
    (slightly) slower boot time. Risk of data loss if your USB fails, more complicated backup procedures.
    • SkyMarshal 5y ago
      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 5y ago
        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 5y ago
          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 5y ago
            > 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.
• rwmj 5y ago
  Clevis/Tang ("network-bound disk encryption") is likely better: https://www.redhat.com/en/blog/easier-way-manage-disk-decryption-boot-red-hat-enterprise-linux-75-using-nbde https://www.redhat.com/en/blog/easier-way-manage-disk-decryp...
  • er4hn 5y ago
    Clevis/Tang are really cool technologies that enable a new way of doing FDE. I'm surprised they aren't talked about more. With Clevis you can use Shamir Secret Sharing to divide the FDE key into multiple parts. The parts can them be put in multiple places: the devices TPM, a server that will only reply to devices on the local network (Tang), a hardware token, etc. If you put one part of the key on the TPM and the other on the Tang server, you now have a device that can be automatically rebooted in a data center without needing to enter an unlock password at boot. But if the device is removed from the data center its contents will be encrypted. Pretty neat!
• jvanderbot 5y ago
  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 5y ago
  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.