How is a private key encrypted in a pem certificate?

As part of trying to debug an issue, I am trying to understand how a private key is encrypted in a pem certificate, because I am wondering whether curl does not manage to decrypt the private key.

I have a -----BEGIN ENCRYPTED PRIVATE KEY----- section in my pem.

Is it encrypted with the passphrase? Is there some other kind of encryption scheme involved?

More precisely

A colleague suggests a private key could be encrypted in a pem even without a passphrase. Is this correct?

Solution

Private keys can have a couple of different forms of being written down, but the most common form is PKCS#8, defined in RFC 5208.

The RFC defines two forms of structure.

PrivateKeyInfo ::= SEQUENCE {
  version                   Version,
  privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
  privateKey                PrivateKey,
  attributes           [0]  IMPLICIT Attributes OPTIONAL }

"The version number for this structure, in case it evolves", "how to identify what parser to use to read privateKey", "some stuff, hope you can read it", "some data about the stuff, maybe".

When PEM encoded a PrivateKeyInfo gets the tag "PRIVATE KEY", as in "BEGIN PRIVATE KEY". You don't have one of these.

The other form is

EncryptedPrivateKeyInfo ::= SEQUENCE {
  encryptionAlgorithm  EncryptionAlgorithmIdentifier,
  encryptedData        EncryptedData }

"How I encrypted stuff", "the encrypted stuff".

EncryptedPrivateKeyInfo comes with the PEM tag "ENCRYPTED PRIVATE KEY", which is what you have.

Looking into one of those:

$ openssl asn1parse -i -dump < rsa.enc.p8
    0:d=0  hl=4 l= 710 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
      0000 - e9 37 68 99 cb 9c 4f 10-                          .7h...O.
   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
      0000 - 16 ad ce 41 47 e8 ba 85-                          ...AG...
   70:d=1  hl=4 l= 640 prim:  OCTET STRING
     <data_omitted />

The data was encrypted under Password-Based Encryption Scheme 2 (PBES2). The input password/passphrase is transformed into key material by Password-Based Key Derivation Function 2 (PBKDF2) with the salt (randomly chosen at encryption time, but must be the same to decrypt) e9 37 68 99 cb 9c 4f 10 and using an iteration count of 2048 (0x800). The key was used for TripleDES encryption in CBC mode with an IV (randomly chosen at encryption time, but must be the same to decrypt) of 16 ad ce 41 47 e8 ba 85. The encrypted content is 640 bytes, and will then be parsed as a PrivateKeyInfo structure.

Aside from PKCS#8 the only real other choice for transmitting private keys is PKCS#12/PFX, but that data structure doesn't have a standard PEM representation. The newest version of PKCS#12 allows for encrypting the data to a certificate, in the style of EnvelopedCMS/PKCS#7.

So, for some succinct answers:

The ENCRYPTED PRIVATE KEY form is encrypted.
- It's 99.999% likely that it's encrypted with a passphrase.
- But someone may have taught OpenSSL about a PBES2 KDF using something other than passphrases :).
The PRIVATE KEY form is not encrypted.
- The RSA PRIVATE KEY form is also not encrypted, but that's a PKCS#1 RSAPrivateKey, not a PKCS#8 PrivateKeyInfo.
If curl doesn't prompt you for a passphrase then it doesn't support encrypted private keys.
While it's not impossible that an encrypted private key could exist sans passphrase, it's definitely not common, and definitely not in a PEM encoded payload.