Arch Linux User Repository

This wiki edit (https://wiki.archlinux.org/index.php?title=Dm-crypt/Specialties&oldid=372705) brought to my attention that GRUB's core.img (stage-2) is not stored in the first 440 bytes, and thus is not checked by mkinitcpio-chkcryptoboot. Is this true? And should chkcryptoboot be updated to check core.img as well as the stage-1 MBR code?

Kernel parameter checking works. I'm afraid firmware hashing is beyond my knowledge. I wouldn't be surprised if the more advanced APIs were vendor-specific, so it may become an ongoing effort to create a tool that is compatible with all of them. Such a tool would definitely be helpful in making this hook more secure, though.

@EscapedNull As of yesterday, version 0.0.2 implements the kernel parameter checking. Of course it doesn't prevent you from typing your root password on a compromised machine, but it possibly warn you that you encrypted boot partition wasn't used to unlock your root partition. As I mentioned, all these things are to increase the complexity and prevent you from being the low hanging fruit. I am looking at how to create a hash of your bios nvram and hd firmware. But it is hard to even find decent documentation on these topics, let alone a tool to do that. Looks like I am gonna have to implement one.

@grazzolini Thanks for the explanation of the kernel parameter. I'll test it out once it is implemented. I'm not sure how much security this provides, though, because the root password is required in order to boot from the root filesystem, and if that is known, then all bets are off. I only posted that patch here because it's so small and is somewhat cosmetic, but I'll get involved on Github as soon as I can. I don't own any (U)EFI machines, so I can't test secure boot in a real environment. All of my testing has been done with QEMU using the OVMF firmware, which probably does allow any key to sign EFI stubs, I just don't know how to do that yet. I also have to look into some of the other security technologies that you mentioned. Thanks for writing this hook and for all of the work you do!

@EscapedNull Everything that increases the odd of an attacker being detected should be done. Specially these days. So, BIOS firmware hash/checksuming, hard drive firmware hashing, are all things that could be done to detect attacks. And this is nice, because since your boot partition is encrypted the attacker have to assume you have all these checks in place, therefore, increasing the complexity and detectability of these attacks. I also have big plans for this hook.

@EscapedNull The CMDLINE_NAME and CMDLINE_VALUE is a name=value pair to detect if your encrypted boot partition was bypassed or not. It can be anything, preferably two hashes, something unique to you. That only you could manufacture. That way the encrypted root partition can detect if it was booted from the intended encrypted boot partition or not. It's not working yet, but in the next version will. As for the diff, if it is possible, could you create a pull request on github? I am focusing development there. As for UEFI secureboot, if your bios allows you to reset the keys, it can be used, sure. I am using in my machine. But it your bios only allows microsoft keys, then you need to disable secureboot. Other security measures should complement this, such as a TPM chip, STARK, pepper, tresor, etc. Think of this as something like your last line of defense. There are obvious attacks on this, specifically, if your bootloader was compromised and the attacker has knowledge that you are using this hook, it can try to tamper with it's checking and display a false message. This could be improved in the future, but it will be always a mouse and cat game.

I'm not sure what to set CMDLINE_NAME and CMDLINE_VALUE to. I guess something like CMDLINE_NAME=('root' 'cryptdevice') CMDLINE_VALUE=('UUID=...' '/dev/disk/by-uuid/...') but I don't know how one would specify flags (which have no name, like "rw"), or what advantage this has over a flat comparison of the full kernel cmdline. I also don't know what attacks this protects against, since kernel parameters are stored in /boot/grub/grub.cfg and all bets are off if the /boot partition is compromised anyway. I wrote a small patch that prints the time at which the hash was originally computed, which might help the user decide whether or not to enter the root passphrase (e.g. forgot to run mkinitcpio after grub-install). 10a11 > echo "Checksum was computed at $(stat -c '%y' disk-head.sha256)" 22a24 > echo "Checksum was computed at $(stat -c '%y' /etc/chkcryptoboot/efistub.sha256)" I was also wondering if you could explain how UEFI "secure boot" relates to all of this? For example, is it conceivable that we could generate an EFI stub signing key, have the user manually add it to his firmware, then use it to sign the EFI stub during the install hook? Or would that defeat the purpose of secure boot? I'm just curious if secure boot could complement this hook in any way. I have some big plans for this hook, for example scanning the hardware (PCI bus, USB bus, CPU, disk serial numbers, firmware version, etc) at install time and comparing them at boot time. There's only so much that can be accomplished securely using only software, but if each thing raises the bar just a little bit, then why not? As it is now, I feel much safer than previously using an unencrypted /boot. Keep up the good work!