111–120 of 136 posts
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.
Earlier quoted context omitted.
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. A…
Dropbear is the solution for this.
Earlier quoted context omitted.
> 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. th…
> 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.
Earlier quoted context omitted.
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.
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.
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…
I'm currently working on setting up disk encryption for a new home server and as an additional precaution I'm also working on getting the initrd to do a few additional sanity checks prior to decrypting a LUKS partition and prior to mounting the root file system within. One check which I think will be highly effective is that prior to decrypting the LUKS partition I have the initrd hash the entire LUKS header and make sure it has the expected value before allowing the boot to continue. So far it seems to be working OK but hashing the entire LUKS header is overkill which will require some care to make sure the expected hash value is kept updated if the LUKS header changes for some reason (like changing encryption passwords). I can not recommend this idea for everyone consequently.
We have had not just secure boot but had it better on Linux (and other Unix-like) systems for a very long time.
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
Earlier quoted context omitted.
That's how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4
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…
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
Earlier quoted context omitted.
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…
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.
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-bo…
>> 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..
- There's an executable called /init, link it statically with everything it needs to do.
- Load kernel modules from a list (hardcoded at build time; optional if you include common modules in the generic kernel).
- Mount the root filesystem (hardcoded at build time) and pivot.
- execve("/sbin/init", ...)
I've built a PoC in pure Go that does all of this, the resulting initrd was ~2.5MB plus kernel modules. I simply moved all the boot-time complexity to build-time. It doesn't do LUKS or TPM yet, but that's also further down the roadmap.
OpenBSD went a step further and crammed FDE decryption into the bootloader. It doesn't do TPM but simple is simple.