Results 1 to 2 of 2
Thread: Remotely decrypting a server
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Sep 2010
Remotely decrypting a server
I have a tricky one here where i need to find a way to securely authenticate a decryption mechanism of some sort where the authentication is provided remotely without any user-interaction.
Right now i have a number of boxes that all inform a central server when they are online. When they do this an OpenVPN connection is set up between them and the server.
However, i have been given the task to ensure that the scripts involved in this process are encrypted by default. This requires some form of self-decryption, which to my mind kind of goes against the whole idea of encryption/authentication in the first place.
I need some way to leave decrypted the bare essentials required to boot a box and securely connect to the central server automatically. Then the server would automatically send a key/passphrase and the rest of the files on the box would then be decrypted on the fly.
If anyone knows of any software that provides this (maybe through VMs?) it would be greatly appreciated.
I should add hat i'm also open to the idea of self-encrypting hard disks, but what i've read about these in regards to Linux support has put me off the whole TCG model.
- Join Date
- Sep 2010
Many pointy haired bosses seem to want this sort of thing. The only problem is that password authentication is supposed to be based on "something you know." When you store that data in any way, it's no longer something that you know, it's something that anyone who can access the file knows. It's not authenticating YOU any more, and it's no more secure than your root account, since root can read the file (or password stored as a variable in memory, or most any other way a password can be stored). All you can do is some "security through obscurity," which is generally considered a bad idea. "passwd = `md5 some_file`" technically isn't storing your password in plaintext, but you've gained zero actual security.
The more you tear apart the problem, the more you see it's a logical impossibility under most circumstances. Kind of like... how can you copy protect a video, such that it can never be copied, even with signal degradation? You CAN'T, because someone can always point a video camera at the monitor of an authorized viewer. Similar issue.
In cases where user intervention (like typing in a password) is truly impossible, I have resorted to using mode 400 or 600 files which are owned by reasonably secure accounts. The plaintext storing of passwords or other authentication data is never going to give anyone a warm fuzzy feeling, but let's face it, if root (or daemon, etc) are compromised, you're toast anyway. It won't matter whether it was a plaintext password, or an ssh key which doesn't require a passphrase, or most any similar mechanism. You're just done.
chown root:root sensitive_script.sh; chmod 500 ./sensitive_script.sh
If your PHB and/or policies say that won't cut it, you'll probably have to explore authentication through things like dongles: usbauth.delta-xi.net/doku.php?id=feature_highlights Most of them impress me as incomplete solutions at this stage (or in some cases, snake oil), but that may be sufficient to resolve things from an "office politics" perspective.