Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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 Aug 6 '12 at 12:42

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.

share|improve this answer
+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 '12 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 '12 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 '12 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 '12 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 '12 at 8:39

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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