问题
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 is correct?
回答1:
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 KEYform 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 KEYform is not encrypted.- The
RSA PRIVATE KEYform is also not encrypted, but that's a PKCS#1 RSAPrivateKey, not a PKCS#8 PrivateKeyInfo.
- The
- 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.
回答2:
If you are using passphrase, of course your key is encrypted !
A passphrase is a word or phrase that protects private key files. It prevents unauthorized users from encrypting them. Usually it's just the secret encryption/decryption key used for Ciphers.
来源：https://stackoverflow.com/questions/43674870/how-is-a-private-key-encrypted-in-a-pem-certificate