-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Apr 10, 2016 at 11:46:36PM +0000, Thierry Laurion wrote:
> Le dim. 10 avr. 2016 à 16:07, Marek Marczykowski-Górecki <
>
marm...@invisiblethingslab.com> a écrit :
> > On Sun, Apr 10, 2016 at 04:57:41PM +0000, Thierry Laurion wrote:
> > > Le lun. 28 mars 2016 à 22:13, Thierry Laurion <
thierry...@gmail.com>
> > a
> > > écrit :
> > > > Le lun. 28 mars 2016 21:02, Marek Marczykowski-Górecki <
> > > >
marm...@invisiblethingslab.com> a écrit :
> > > The attached diff contains all the required functional changes (unsexy)
> > to
> > > bypass anaconda requirements in having unencrypted boot partition outside
> > > of a luks container so that coreboot/libreboot GRUB2 payload can search
> > > that container and load grub.cfg from there.
> > >
> > > I would need help to understand what else needs to be changed so that the
> > > internal initrd and dracut scripts don't include modifications to try to
> > > open the luks container itself from within the initrd, since it was
> > already
> > > opened externally from the libreboot/coreboot.
> >
> > Linux kernel somehow must obtain disk encryption key. It can be handed
> > over from libreboot (not sure how), or simply embedded into initramfs
> > (keyfile) as initramfs itself will be on encrypted partition. The later
> > should be simpler, I would look into rd.luks.key option (man
> > dracut.cmdline).
> >
> The passphrase is obtained by grub2 from the keyboard and unlocks the luk
> container from within libreboot/coreboot's GRUB2, reveiling the lvms
> inside. From my understanding, the kernel needs to know the underlying
> filesystem types, but doesn't need to know the existence of the container,
> since it refers to root already as being a lvm.
But if the blocks on the disk are encrypted, kernel needs to know how to
decrypt them. Grub2 doesn't play any role as soon as kernel is loaded,
so it can't help there.
It looks like it prompt for the passphrase the second time:
https://wiki.parabola.nu/Mkinitcpio#Using_encrypted_root
"Using LUKS volumes
If you use LUKS for hard disk encryption, the init script will detect
the encryption automatically if the encrypt hook is enabled. It will
then ask for a passphrase and try to unlock the volume.
"
https://wiki.parabola.nu/Installing_Parabola_on_Libreboot_with_full_disk_encryption_%28including_/boot%29
"HOOKS="base udev autodetect modconf block keyboard keymap consolefont
encrypt lvm2 filesystems fsck shutdown"
Explanation: keymap adds to initramfs the keymap that you specified in
/etc/vconsole.conf; consolefont the font specified in
/etc/vconsole.conf; encrypt to unlock your LUKS encrypted disks at boot
time;"
So, for me it looks like "encrypt" hook simply prompt for the
passphrase.
But of course there may be some clever trick (for example one of those
pointed out before). I can't find "encrypt" hook in the repository, so
can't verity that.
Ok, found which one:
https://wiki.parabola.nu/Installing_Parabola_on_Libreboot_with_full_disk_encryption_%28including_/boot%29#Bonus:_Using_a_key_file_to_unlock_.2Fboot.2F
"By default, you will have to enter your LUKS passphrase twice; once in
GRUB, and once when booting the kernel.
(...)
A workaround is to put a keyfile inside initramfs, with instructions for
the kernel to use it when booting."
I doubt its being really tamper proof, a lot of things can go wrong there.
Generally all kind of Evil Maid attacks. Some example ideas:
- a second /boot (even unencrypted), which will mimic the original one
to intercept disk passphrase (probably already available somewhere in
RAM)
-
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-019-2015.txt
Having coreboot+grub2 may make EM style attacks harder, but I
wouldn't assume (without some deep analysis) it would be much harder.
In worst case it would require reflashing coreboot payload. Even when
password grub2 is password protected and doesn't allow booting from USB,
you can swap the drive to very similar one (with encrypted system) and
boot that. Or simply use SPI flasher.
Surely it rises the bar, but using AEM does it too.
Just those two.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXCv1yAAoJENuP0xzK19csezoH/3usLyPdI7lXhkm2+FrsrAwS
CyZ/BPiPGVpaIFalmGPDxu74YAIsjf9cQTO7aVrFWLkVxP2bUE412Tvi2VtUk0hK
4N8129/D4d31pM9gdi66vpE8NDcpUWkj44YLVIclzjxe0ZfAKG11j2c51T4ieDhj
YpA4PsM/W12ZQJumVMQ/mYGbCO63c3HEhlsm55VsGpyEonL2WuqaESdj6POFrWbj
BrlpuJWHVUcnktwEsh/xQbNrI+YpeWjqqn53F/Yfv85jQ1BxHPM2SlTmulpged8m
2Eya5nsIQ9xhlm0tf47ta+yt5+RBNAzIQILqhS18eOLgN/HFi/w1Bf66ZlrAZhc=
=dxl0
-----END PGP SIGNATURE-----