Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I was rotating my AWS X.509 certificate and private key (not to be confused with ssh private / public key pair) today and decided I wanted to set a pass-phrase on my private key to better protect it. So I did a bit of research and ran :

openssl rsa -in awsprivatekey.pem -des3 -out awsprivatekey.pem.new

and entered a pass-phrase for the private key. After I attempted to use the ec2 api tools I got an error :

java.io.IOException: DER length more than 4 bytes

This became obvious when I researched the topic and found out this link ec2 api tools don't support a private key with a password

I'm troubled by the lack of information about this and the status-quo of having un-protected private keys with something as crucial as Amazon EC2.

Any suggestions on how to better protect my private key?

share|improve this question
    
As far as I'm aware, there's no session tokens or other authentication state tracking with Amazon's API, so do you really want to be entering a passphrase for every single command you execute? –  SmallClanger Jul 1 '11 at 12:34
    
Good point...I guess I'll just keep it on an encrypted volume as suggested and rotate the key every so often. I am only using it interactively so it won't make that much of a difference workflow wise. –  Hilt86 Jul 2 '11 at 4:35

2 Answers 2

I've been doing the same due diligence and I too am concerned that all of the client tools and documentation seems to promote bad security best practices. I response to the question "do you really want to be reentering a pass phrase for every single command you enter?" -- yes, or at least I'm happy to have a tool like ssh-agent enter it for me. I don't ever want to find any of my private keys or pass phrases sitting around in plane text on my filesystem. I'm amazed that the standard response is just "encrypt your whole filesystem".

Even if I mount and encrypt just an .ec2 directory and stash everything in there, I still have to be careful not to follow the documentation which suggests setting my secret key as an environment variable in my bash_profile script. So maybe I just put it in a script on my .ec2 directory and pass it in on the command line -- oh wait, now my password is sitting in my history (I still can't believe os x isn't nice enough to skip storing lines that I prefix with a space). So really I need to encrypt my entire user directory just to be safe. And why exactly is it that the asymmetric process of using x.509 certs is being deprecated and replaced with the "secret key" authentication process? At least the former allows me to store the private key in a file -- the latter requires me to pass it in as an argument (the value of which gets plastered all over my history and scripts).

The problem is that there are all these great security protocols, but nobody wants to take the time to understand them. Instead they just want to get things to work -- as a result they blindly follow some step by step documentation that was written by somebody who blindly followed somebody else's step by step documentation. Nobody questions any of this because they don't understand it and they just want it to work. The result is the proliferation of really bad security practices.

share|improve this answer

Keep them on TrueCrypt encrypted disk. They will be stored secure while you don't need them, and you would mount it only once you really need to use them. TrueCrypt creates a file, which then is mounted as virtual disk.

Edit: If you need to protect it in a code which is not interactive, you could obviously encrypt the private key and decrypt it you application code. There is a plenty of samples how to decrypt file with Java.

share|improve this answer
    
Or encfs or ecryptfs. –  mgorven Apr 19 '12 at 1:12

Your Answer

 
discard

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.