4

When running a fully encrypted linux system using dm-crypt, the /boot partition has to be unencrypted to boot, as far as I know. I've setup a server that can be unlocked remotely by connecting to a pre-boot ssh server that is running from initrd.

One attack vector I'd like to close is installing a keylogger in the initrd.

I reasoned like this: I cannot prevent changes to the /boot partition as the adversary has access to it in a hosted environment. But I can detect changes using checksums from within the encrypted system using simple sha512sum or tripwire. Also I can monitor the server for reboot (which might indicate changes).

What mitigation methods come to your mind?

Improve this question
1
  • 2
    I'd be more afraid of a kernel substitution than an initrd change. The kernel is the ideal place to hide any tampering and implement anti-detection measures.
    – Gilles 'SO- stop being evil'
    Aug 6, 2012 at 12:42

2 Answers 2

Reset to default
6

This is exactly the problem that Secure Boot was created to solve. The problem is that if you don't have a chain of trust going all the way back to POST, then you can't guarantee that there hasn't been tampering. (And even then, "guarantee" is an exaggeration).

You can checksum the boot partition at startup; perhaps use the checksum as part of the key for the next step. It's not completely tamper-proof, but without hardware-based crypto integration nothing will be. Just do your best with the tools you have and make sure you understand the limitations.

Improve this answer
7
  • 2
    +1 for going to the heart of the problem - you can't verify anything absolutely, just do the best you can with the tools and information you have.
    – Polynomial
    Aug 6, 2012 at 6:09
  • Thats what I'm trying, getting the most out of what I can do. Secure Boot is not a present practical solution, AFAIK. Currently I think of two solution: Checksum from encrypted root OR copy checksum program to initrd on every boot and store checksums off-site. That way I can at least detect tampering, as long as the kernel doesn't lie which is even harder than getting a keylogger in there.
    – Peter Meyer
    Aug 6, 2012 at 8:31
  • @PeterMeyer - Except in most cases it is practical solution. I certainly trust it more then anything you alone can come up with.
    – Ramhound
    Aug 6, 2012 at 13:23
  • I'd suggest building a custom extension into your kernel (not as a module) to act as the canary and do the checksumming, etc. An initrd is easy to modify, but a kernel is usually replaced rather than modified. Not to say that it's impossible, it's just easier to recompile than patch.
    – tylerl
    Aug 8, 2012 at 4:13
  • tyler, can you elaborate on that? I guess a first step in your direction would be building a kernel without modules and checksumming that. In addition checking which software is running in the initrd. If you have a helpful link for your suggestion, don't hold back. Currently I'm solving this problem by copying over a checksum software to initrd and checksumming away with checksums saved to remote pc.
    – Peter Meyer
    Aug 8, 2012 at 8:39
-1

After remotely SSHing to the server, you could kexec into a kernel supplied from a secure location. Also make sure you supply your own hash/kexec binaries as they could be tempered with as well. Make sure modules are loaded from a secure location as well.

Improve this answer
1
  • This makes no sense. Your solution would be trivial to defeat. The real way to perform remote attestation is with something like a TPM.
    – forest
    Jan 18, 2018 at 20:34

You must log in to answer this question.

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