Cfrtjryk

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?

I'm not going to answer your nominal question because there's too little information to answer. There's no particular reason why you'd need to refer to the boot partition differently from the initramfs. If the normal name doesn't work, it means the initramfs is using different paths, or hasn't loaded the driver yet at the point where you're running this command. If you want to get help with this, you have to explain in detail how you're building the initramfs and where you're adding this command.

I'm posting this as an answer and not as a comment to tell you not to bother.

What you're trying to do is fundamentally impossible. If an attacker can change your boot partition, they'll just change the initramfs to remove this check.

Doing the check from the encrypted partition isn't much better, but it's actually very slightly harder to attack. The adversary would have to either set up an emulated environment (technically possible, but difficult to do in a way that you wouldn't notice) or restore the boot partition to the expected state before loading your main OS (possible, but the attacker only gets one shot).

There is no way to protect against an evil maid attack if you can't trust your bootloader all the way. If there is a single untrusted step, everything that comes after it is untrusted. The only way to protect against an evil maid attack is to have a full secure boot chain, where every step verifies the next step. Each step must either halt the boot if the next step isn't authentic (and up-to-date if you're concerned about downgrade attacks), or must record the state of the next step and then send it to a third-party trusted verifier. If there is a gap in this chain of trust, then you have no way to know that the subsequent steps are reporting genuine data.

This is impossible to do on a Raspberry Pi because the ROM doesn't verify what it loads. You can't help trusting your boot partition unless you're willing to use different hardware. I unfortunately don't have a recommendation: the market isn't good for trusted boot for hobbyist projects on Arm platforms.

By the way, even if your command worked, it has a couple of flaws.

• 
  dd if=/dev/mmcblk0p1 | sha1sum is the same as sha1sum </dev/mmcblk0p1. With no parameters other than if and of, dd just copies its input to its output. Beware that with certain parameters, dd actually corrupts the data! Don't use dd unless you really need to and you're sure that the way you're using it doesn't risk corruption.


• SHA-1 is broken. It's not broken for all use cases, and it would be hard to exploit in your case (someone would have to arrange to plant some crafted, harmless content into the legitimate boot partition), but it is irresponsible to use SHA-1 in a new design. Use sha256sum.