I have an opensource airgapped raspberry pi project seen at the following link: www.privatekeyvault.com

I have provided a method for installing LUKS full disk encryption seen at the following: https://github.com/johnshearing/PrivateKeyVault#setup-luks-full-disk-encryption

I am trying to mitigate against a Maid in the Middle Attack explained at following: https://github.com/johnshearing/PrivateKeyVault#preventing-the-evil-maid-or-maid-in-the-middle-attack

The concern is someone could install a malware keylogger on the boot partition and collect the password when logging into the encrypted partition while still running initramfs

Once logged into my encrypted partition, I can run the following command to see the sha1sum of the boot partition: dd if=/dev/mmcblk0p1 | sha1sum

I compare this against a previously recorded sha1sum to see if the boot partition has changed. It should never change.

I want to get the sha1sum of the boot partition before logging into the encrypted partition. In other words, before providing my password. This is while I am still running under initramfs. I understand that this is folly because anyone installing a keylogger could also install a false sha1sum program so perhaps it is best to run the sha1sum command after logging into the encrypted partition where it is not possible to change the sha1sum program. Still, I am curious if it is possible to do.

The challenge is that when running the command (df), /dev/mmcblk0p1 does not show up so my command (dd if=/dev/mmcblk0p1 | sha1sum) will not work.

Any ideas how to refer to the boot partition while in initramfs?

Also, any other ideas on how to check if someone has tampered with the boot partition before logging into the encrypted partition?

Thanks for the help.


Verification from inside the potentially compromised system is pointless. If a program is missing from the initramfs you could add it manually via initramfs hook scripts. But just running sha1sum /dev/mmcblk0p1 should do the trick and work out of the box. You can get a list of the partitions by running blkid. However, as raspberrys usually boot from SD cards the best solution would be to always carry it with you. Or verify the checksum on another system.

| improve this answer | |
  • Thanks weaselwords. Previously I had been using lsblk. I am going see what blkid returns now. Thanks again for the help. – John Shearing Dec 13 '18 at 1:29

The technique you are describing will not be capable of mitigating evil maid attacks. As you say, a malicious bootloader could just replace any hash checking code you use. Rather than trying to hash it anyway, you should consider TPM-based measured boot. There are several techniques for doing this:

  • AEM - Probably the best technique and the easiest to use, from Qubes OS.

  • Heads - A newer technique optimized for Coreboot payloads to verify the BIOS and bootloader.

  • MARK* - For x86 systems, but can probably be modified to work for Raspberry Pi.

* The link appears to be down at this time. The page has been archived here.

| improve this answer | |
  • Thanks forest, Trying to keep this open source project simple and cheap so that more people can have it. Perhaps tamper evident packaging for the device and the card is the best way to go. Still, I am looking forward to learning more about MARK. – John Shearing Dec 13 '18 at 1:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.