I am well aware of the fact that physical insecurity in principle means no security. But let´s say I own a root server with full disk encryption which is unlocked/booted via dropbear ssh. In which ways can an attacker with physical access (e.g. the hosting provider) gain access to my data and what countermeasures can I take to prevent the attacks or to slow him down? He could retrieve the encryption keys from the RAM. Tresor stores the key in CPU registers and this might mitigate the risk. But I guess the usage of tresor is also detectable. The attacker might modify the boot partition or kernel. Is it possible to perform a checksum over the network of /boot in order to determine someone has tampered with it? Maybe colocation in combination with TPM could help? Also Mandos and homomorphic encryption (though it might take some years to be practically usable) could be useful. Any more ideas for implementing attacks and protection against them?

closed as too broad by TildalWave, Lucas Kauffman, Xander, Adi, NULLZ Nov 24 '13 at 21:46

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


The most common solution to this is to create physical security: you have a dedicated rack, and use a secure, lockable cabinet.

You can also create physical security for a single box by locking the case. There are some subtleties to getting this right: securing the BIOS, firewire ports, etc.

Disk encryption is an effective technique, although it is susceptible to advanced attacks. 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.

TPM-based disk encryption could work well. It doesn't require a password on boot, but instead only reveals the encryption key to a trusted boot image. I've not seen this done on a server, but I think it would work. I expect an advanced attacker can get around this too.

An attacker with physical access can only read RAM if they are quite highly skilled - at least, assuming you secure the basics like firewire. Given advanced attackers have other routes in, I don't think Tresor buys you much. Mandos sounds like an automated way of supplying the boot password remotely; I expect it has the same risks as dropbear.

Ultimately, to make proper decisions you need to consider the threat profile of a specific system. In practice, if you don't trust your hosting provider, maybe the best option is to switch to one you do trust - even if this means bringing your data centre in-house.

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