Although this is closely related to the recently closed question Evil maids in the server room [closed], I believe that it's more answerable.

I'd like to unlock LUKS volumes on remotely hosted servers, using initramfs with BusyBox, and Dropbear as SSH server. In the answer to the closed question cited above, paj28 notes:

 Remote boot techniques like dropbear are vulnerable to a remote variant of
 the evil maid attack. For example, someone with physical access could tamper
 with the dropbear partition, and have it leak the key on the next reboot.

The attack is also described in LUKS mermaids of remote unlock.

In the BusyBox initramfs environment, I'd like to verify the integrity of a remote server before sending the passphrase for unlocking LUKS. I can verify file integrity by checking sha256 checksums against a local list. But would that detect modification of the initramfs to capture the passphrase?

I can easily get eth0's MAC, and I can use traceroute to detect changes in the network environment. Perhaps I can add hwinfo to the initramfs to confirm the hardware environment. What changes could go undetected by those tests?

I'm not asking for a solution, but if there's an elegant one that I'm missing, please let me know.

Although this is closely related to the recently closed question Evil maids in the server room [closed], I believe that it's more answerable.

I'd like to unlock LUKS volumes on remotely hosted servers, using initramfs with BusyBox, and Dropbear as SSH server. In the answer to the closed question cited above, paj28 notes:

 Remote boot techniques like dropbear are vulnerable to a remote variant of
 the evil maid attack. For example, someone with physical access could tamper
 with the dropbear partition, and have it leak the key on the next reboot.

The attack is also described in LUKS mermaids of remote unlock.

In the BusyBox initramfs environment, I'd like to verify the integrity of a remote server before sending the passphrase for unlocking LUKS. I can verify file integrity by checking sha256 checksums against a local list. But would that detect modification of the initramfs to capture the passphrase?

I can easily get eth0's MAC, and I can use traceroute to detect changes in the network environment. Perhaps I can add hwinfo to the initramfs to confirm the hardware environment. What changes could go undetected by those tests?

I'm not asking for a solution, but if there's an elegant one that I'm missing, please let me know.

Although this is closely related to the recently closed question Evil maids in the server room [closed], I believe that it's more answerable.

I'd like to unlock LUKS volumes on remotely hosted servers, using BusyBox for initrd with Dropbear as SSH server. In the answer to the closed question cited above, paj28 notes:

 Remote boot techniques like dropbear are vulnerable to a remote variant of
 the evil maid attack. For example, someone with physical access could tamper
 with the dropbear partition, and have it leak the key on the next reboot.

The attack is also described in LUKS mermaids of remote unlock.

In the BusyBox initrd environment, I'd like to verify the integrity of a remote server before sending the passphrase for unlocking LUKS. I can verify file integrity by checking sha256 checksums against a local list. But would that detect modification of the initrd script to capture the passphrase?

I can easily get eth0's MAC, and I can use traceroute to detect changes in the network environment. Perhaps I can add lspci and hwinfo to BusyBox to confirm the hardware environment. What changes could go undetected by those tests?

I'm not asking for a solution, but if there's an elegant one that I'm missing, please let me know.

Although this is closely related to the recently closed question Evil maids in the server room [closed], I believe that it's more answerable.

I'd like to unlock LUKS volumes on remotely hosted servers, using initramfs with BusyBox, and Dropbear as SSH server. In the answer to the closed question cited above, paj28 notes:

 Remote boot techniques like dropbear are vulnerable to a remote variant of
 the evil maid attack. For example, someone with physical access could tamper
 with the dropbear partition, and have it leak the key on the next reboot.

The attack is also described in LUKS mermaids of remote unlock.

In the BusyBox initramfs environment, I'd like to verify the integrity of a remote server before sending the passphrase for unlocking LUKS. I can verify file integrity by checking sha256 checksums against a local list. But would that detect modification of the initramfs to capture the passphrase?

I can easily get eth0's MAC, and I can use traceroute to detect changes in the network environment. Perhaps I can add hwinfo to the initramfs to confirm the hardware environment. What changes could go undetected by those tests?

I'm not asking for a solution, but if there's an elegant one that I'm missing, please let me know.