Since I cannot receive email directly from my home server, I need an external device to receive messages for me and deliver them to my MTA via another port or via VPN. Instead of renting a VPS just for this, I was thinking about purchasing an unexpensive ARM board and deploying it to one of my friend's house, which has a static IP and can receive email from the outside (no port 25 blocked by his ISP). I would encrypt the root partition, allowing remote unlocking via VPN and SSH intramfs. I would save the SSH fingerprint locally before giving the machine to him.

Of course I trust him, but what could he possibly do?

Things that come to mind, from the easiest to the most difficult:

  • He could wipe the SD card, but of course I would notice it
  • He could forward the external port 25 of its router to his rogue mail server, but could he read my email?
    E.G. by responding to STARTTLS requests saying that no encryption is available, or offering them a self-signed certificate for mail.example.org, while the official CA-issued certificate for mail.example.org is stored in the encrypted partition.
    If yes, is there a way to tell external MTA to only deliver through Submissions (AKA SMTPS, usually sender->MTA on port 465), or at least veryfing the issue of the certificate (CAA record, trusted CA...) and eventually alerting me of such a spoof?
  • Can he read the wireguard intramfs configuration? If so he could use the peer key to connect to VPN
  • Can he add his SSH key to tinyssh, or they have to be added with mkinitcpio? Is it useless or he could install something that leaks the passphrase once I enter it?
  • Can he brute force local TTY login when the machine is powered on? How could I prevent this, either disablying local login or rate limiting login attempts? What software could he use (E.G. hydra for http-basic auth)
  • Is there a way to protect from cold boot attacks?
  • Other paranoid things I'm missing?

I'm 100% sure none of this will happen, it's just a theoretical exercise

1 Answer 1


Ten immutable Laws of Security, Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

You are susceptible to the Evil Maid Attack.

He has the SD Card, he can clone it, change the initrd to log LUKS password, and with the LUKS password in hand it's game over. Shutdown your Pi, clone the card, replace the initrd, say there was a power outage here, and as soon as you send the key remotely, he has too. Another "power outage" and all your binaries are backdoored, or there's another root user, or a suid bash somewhere.

He could forward the external port 25 of its router to his rogue mail server, but could he read my email?

He now has the certificate, he can forward the emails to his own server, save a copy, send it back to your server. You cannot detect this, because he is using your certificate.

He can setup a proxy that does a reverse lookup on every connection to the port 25, checks if it's from a MX record, and says "TLS not implemented" and saves everything before sending data to your server. If you try to connect, he passes straight to your daemon, so if you test it from any non-MX IP, it will show you the correct certificate. He can even create a list with the largest SMTP sending services (major email providers, major list services, and so on) and sniff only those.

Can he read the wireguard initramfs configuration? If so he could use the peer key to connect to VPN

He can. He now has the LUKS key.

Is there a way to protect from cold boot attacks?

No. He has unrestricted physical access. Pull the plug, every single software protection is dead. The Pi does not have any hardware protection.

Other paranoid things I'm missing?

You cannot protect your Pi. Not even against basic attacks.

  • "change the initrd to log LUKS password", can you elaborate more on this part (or point a good article about it)? As far as you know, could he read the VPN key and most importantly receive email without having to decrypt the disk, with the methods I mentioned? Is there a way to mitigate TTY login brute forcing?
    – Polizi8
    Jul 20, 2020 at 14:41
  • Searching online for "LUKS Backdoor" brings lots of articles. Usually PTY allows 3 login tries before closing.
    – ThoriumBR
    Jul 20, 2020 at 15:19
  • "There was a power outage". Sadly, already heard about Jul 20, 2020 at 15:41
  • @usr-local-ΕΨΗΕΛΩΝ I know, disgusting at least. Did they obtain any success in their legal battles after the crackdown?
    – Polizi8
    Jul 20, 2020 at 16:05
  • @ThoriumBR Thank you, I found interesting stuff. One of the tools suggests as mitigation to encrypt /boot with LUKS, and I just discovered that Grub now supports LUKS2. A setup with also /boot encrypted would require local unlocking, right? What could an evil maid do in this case?
    – Polizi8
    Jul 20, 2020 at 16:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .