Having a sterile VM to do all of the cert generation is a good idea. But can you guarantee, in these days of logging and versioned filesystems, that the unencrypted key file data block will in fact be overwritten by the encryption? Or will it remain intact, with a new data block allocated for the new content?
(Also, I'm trying to generalize good security principles to the design of a non-specific script. I now see that you have a particular scenario with a particular threat model in mind, and disclaim the creation of a solution for general utility.) -Kyle H On September 9, 2014 3:27:27 PM PST, Gregory Sloop <gr...@sloop.net> wrote: >@Kyle: I'm the admin for the OpenVPN system setup and config, and >generate all the server/client certs, CA etc., and if my machine is >infested with malware, then well, the CA's compromised, along with >everything else. IOW, game over. > >It's not that I disagree with you particularly, but I doubt that the >short time a private key is "exposed" before it gets re-encrypted, will >matter much, especially in the very controlled situation I'm >contemplating. [Which is actually inside a sterile VM.] > >--- >@Michael: Yeah, I can use the EasyRSA tool to initially create the >Key+CSR without a password [encryption-less] and then add the aes-256 >re-key in the second process. [Like so: # easyrsa build-client-full >somefilename nopass ] As I was writing up the post last night, I >thought about describing that process, but thought it would confuse >things further since I hadn't opened the thread that way... > >But yet, that will make it easier as I only have to input the password >once into the terminal, instead of on both passes. > >And you're right in regards to modifying the EasyRSA script; it's more >work than I'm able to do at the moment, and while I'm not terrible at >bash, I'd be hesitant in making fairly major mods to [security >critical] code in fear of introducing ill effects that won't get caught >in a cursory peer-review. > >The current code can be made to work without too much hassle and has >been around for a while and has been real-world tested. Unless the >current maintainer is willing to do it, it's probably better to leave >it the way it is now with the minor change I suggest. > >Again thanks all for the excellent help, ideas and suggestions. It's >been a pleasure. >[And that's an uncommon compliment - far more than can be said of many >listservs.] > >-Greg > > >Sure, if that's a better fit to your threat model. (I certainly >wouldn't recommend changing "openssl req" to make -nodes the default.) >I was just suggesting possibilities for Gregory. > >Personally, I'd probably go with generating an encrypted private key >with "openssl genpkey" first, but that might be more changes to the >EasyRSA script than he's inclined to make. He has a working solution >now which seems fine for his purposes. > >A cipher option for "openssl req -newkey" wouldn't be a bad idea, but >it's not a high priority, so I wouldn't expect it to happen anytime >soon unless someone wants to submit a patch. > >Michael Wojcik >Technology Specialist, Micro Focus > > >From: Kyle Hamilton [mailto:aerow...@gmail.com] >Sent: Tuesday, 09 September, 2014 13:43 >To: openssl-users@openssl.org; Michael Wojcik >Subject: RE: Certificate pass phrase brute force... > >At least 3DES is *some* encryption. The issue is that peoples' >computers are usually infested with malware; it's better to assume (for >a software distribution) that the disk is compromised, and always >encrypt it before writing. > >Perhaps there should be a cipher option for the req -newkey option? > >-Kyle H >On September 9, 2014 8:58:08 AM PST, Michael Wojcik ><michael.woj...@microfocus.com> wrote: >As far as I know, openssl req doesn't let you specify the encryption >cipher for the private key. > >You can generate the key file first, with openssl genpkey, which does >let you specify the encryption cipher; and then use -key to tell >openssl to use your existing key rather than creating a new one. > >You can also do what you describe below, but not encrypt the private >key the first time, by using the -nodes option with openssl req; that >saves decrypting it before encrypting it with your preferred cipher. > > >Michael Wojcik >Technology Specialist, Micro Focus > > >From: owner-openssl-us...@openssl.org >[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop >Sent: Tuesday, 09 September, 2014 01:19 >To: openssl-users@openssl.org >Subject: Re: Certificate pass phrase brute force... > >I used the asn1parse command [thanks Dave!] and while the key looks >"old style" it parses as follows: > >50:d=4 hl=2 l= 8 prim: OBJECT :des-ede3-cbc > >Which appears to equate to: des-ede3-cbc Three key triple DES EDE >in CBC mode > >The full asn parse is: >--- > 0:d=0 hl=4 l=2446 cons: SEQUENCE > 4:d=1 hl=2 l= 64 cons: SEQUENCE > 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 > 17:d=2 hl=2 l= 51 cons: SEQUENCE > 19:d=3 hl=2 l= 27 cons: SEQUENCE > 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 > 32:d=4 hl=2 l= 14 cons: SEQUENCE >34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA >(REDACTED) > 44:d=5 hl=2 l= 2 prim: INTEGER :0800 > 48:d=3 hl=2 l= 20 cons: SEQUENCE > 50:d=4 hl=2 l= 8 prim: OBJECT :des-ede3-cbc >60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA >(REDACTED) >--- >[I don't know if I needed to redact those fields at all, but I don't >think it matters.) > >So, if I've read that properly, the encryption method is 3DES. > >--- >While this isn't really relevant to OpenSSL, and more relevant to the >EasyRSA script from OpenVPN - I thought I'd share a solution that >appears to work and do what I want. > >It doesn't appear easy to modify the EasyRSA script to use aes-256 [or >any non 3DES cypher] in the script. From my look at the syntax of a >"openssl req -new -newkey ..." command, you don't get to specify the >cypher it will use in encrypting the private key. This appears to be a >result of generating both the key and the signing request in a single >step - in this case you don't appear to get to choose what crypto is >used to encrypt the private key. [I'd be glad to be shown a way you can >specify it - it doesn't appear possible from the command-line options >at least.] > >However, as I pointed out there is code in the EasyRSA tool to >re-encrypt the private key with a new password, or remove the password. >You can edit the script to use aes256 as follows: [or any of the other >cyphers here: https://www.openssl.org/docs/apps/rsa.html#] >In the easyrsa bash script: >Look for the line: [ local crypto="-des3" ] (It's line 861 in the >current EasyRSA version) >Change it to: [ local crypto="-aes256" ] > >Now when you issue the command easyrsa set-rsa-pass, and issue the >"old" encryption key, along with a new one [you can certainly use the >same key for the old and "new"] it will re-encrypt it with aes-256. > >Looking at the key file it does appear to indeed work and re-encrypts >it with AES-256. > >#cat somekey.key >-----BEGIN RSA PRIVATE KEY----- >Proc-Type: 4,ENCRYPTED >DEK-Info: AES-256-CBC ... > >--- >Thus, this is the best work-around for the tool I can find. >Unfortunately it requires a "redundant" step unless someone can show me >a way to put the encryption type for private keys in a config file or >specify it as part of a "openssl -req ..." command > >But at least it works the way I want it to, and makes the task of >setting up keys and certs a bit easier than raw openssl commands. > >Hope that helps someone else too. And thanks again for all the pointers >and tips! > >[Ya'll are probably going to chuckle and say "If you'd just dumped that >lousy 'playskool' EasyRSA tool and run openssl like a real man, you'd >have avoided all this hoopla in the first place!" And yeah, you're >probably right - but I trust a good script to do it right more often >than I trust myself - but perhaps that trust is misplaced in this >case.] > >Again, glad for any follow-up advice - it's been an interesting thread >- at least for me. > >-Greg > > >For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY) >just look on the DEK-Info: header line. > >For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do > openssl asn1parse <key.pem >and the third line will be an OBJECT (really OID) in the form >pbeWith<hash>and<cipher>. > > >From: owner-openssl-us...@openssl.org >[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop >Sent: Monday, September 08, 2014 20:58 ><snip> >--On that note: Is there a way to determine from an encrypted key-file >what encryption was used to encrypt it? [I have the password, so it >doesn't need to be a blind test.] > > >-- >Click here to report this email as spam. > >This message has been scanned for malware by Websense. www.websense.com > >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
