Which encryption algorithm is used in password protected *.pfx/PKCS 12 certificates?

Question

As the title says, I can't find any resources on which encryption algorithm is used in *.pfx/PKCS 12 certificates that are password protected.

Answer 1

If you have a specific .pfx file that you wish to check, you can determine what encryption methods have been used using openssl:

openssl pkcs12 -info -in cert.pfx -noout

This might give you:

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

This requires that you know the password of the .pfx file. If you don't know the password, you can still find the outermost encryption method using:

openssl pkcs12 -info -in cert.pfx -nomacver -noout -passin pass:unknown

This gives, for example:

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048

This particular certificate file was generated by openssl with default parameters, and looks like it has:

• An outer encryption layer using 40-bit RC2 with SHA-1. The outer encryption layer contains the certificate.
• An inner encryption layer using 3DES with SHA-1. The inner encryption layer contains the private key.

I think this is insecure because an attacker can break the outermost encryption with an easy brute force (40-bit encryption plus RC2 has various vulnerabilities), and then use the same password on the inner encryption layer. However, this probably warrants additional investigation.

Answer 2

Mike Ounsworth's answer is correct but incomplete. PKCS #12 specifies a container format but it also specifies some sets of algorithms of its own:

The PBES1 encryption scheme defined in PKCS #5 provides a number of algorithm identifiers for deriving keys and IVs; here, we specify a few more, all of which use the procedure detailed in Appendices B.2 and B.3 to construct keys (and IVs, where needed). As is implied by their names, all of the object identifiers below use the hash function SHA-1.

pkcs-12PbeIds                    OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4           OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4            OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC       OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC        OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}

And if you notice from the above quote, it mentions PKCS #5 for the algorithms. PKCS #5 specifies two kinds of algorithms: PBES1 and PBES2.

The older PBES1 algorithms are a just a list of sets of algorithms:

pbeWithMD2AndDES-CBC OBJECT IDENTIFIER  ::= {pkcs-5 1}
pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER  ::= {pkcs-5 4}
pbeWithMD5AndDES-CBC OBJECT IDENTIFIER  ::= {pkcs-5 3}
pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER  ::= {pkcs-5 6}
pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10}
pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11}

PBES2 allows you to mix and match the encryption and PRF algorithms separately (as opposed to pre-defined sets of algorithms). I'll just list the relevant part from the table of contents here so you can get the idea:

     B.1.  Pseudorandom Functions  . . . . . . . . . . . . . . . . .  28
       B.1.1.  HMAC-SHA-1  . . . . . . . . . . . . . . . . . . . . .  28
       B.1.2.  HMAC-SHA-2  . . . . . . . . . . . . . . . . . . . . .  29
     B.2.  Encryption Schemes  . . . . . . . . . . . . . . . . . . .  29
       B.2.1.  DES-CBC-Pad . . . . . . . . . . . . . . . . . . . . .  30
       B.2.2.  DES-EDE3-CBC-Pad  . . . . . . . . . . . . . . . . . .  30
       B.2.3.  RC2-CBC-Pad . . . . . . . . . . . . . . . . . . . . .  30
       B.2.4.  RC5-CBC-Pad . . . . . . . . . . . . . . . . . . . . .  31
       B.2.5.  AES-CBC-Pad . . . . . . . . . . . . . . . . . . . . .  32

---

Back to PKCS #12, it also specifies MAC algorithms for the whole file (not for individual entries):

This document uses a particular type of MAC called HMAC [11] [20], which can be constructed from any of a variety of hash functions. Note that the specifications in [20] and [11] differ somewhat from the specification in [9]. The hash function HMAC is based on is identified in the MacData, which holds the MAC; for this version of this standard, the hash function can be one of the following: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 [10].

The same MAC algorithms are also specified in PKCS #5:

     B.3.  Message Authentication Schemes  . . . . . . . . . . . . .  33
       B.3.1.  HMAC-SHA-1  . . . . . . . . . . . . . . . . . . . . .  33
       B.3.2.  HMAC-SHA-2  . . . . . . . . . . . . . . . . . . . . .  33

---

Finally, as Mike Ounsworth's answer states, you can choose any algorithm you want, even if it's not in PKCS #12 or PKCS #5. However, it must have a OID for use in the ASN.1 representation of the p12 file.

Answer 3

All the specs for the PKCS#12 format are defined in RFC7292.

The short summary is that a .p12 file (and I assume also Microsoft's older PFX format, but I've never worked with them) is just a container format that specifies the structure of this file, but says nothing about what kind of data should go into it.

To use a very bad analogy, the spec for Microsoft Excel's .xlsx format specifies the structure of an Excel save file, but does not tell you anything about what data or formulas it is allowed to contain; that is controlled by which version of Excel you're running.

---

If you were to pop open a .p12 in a hex editor, you would find that one of the fields in the header is AlgorithmIdentifier: _____ where the program that created the .p12 records A) which encryption algorithm was used to encrypt the data, and B) which hash algorithm was use to turn the password into a key. As far as I know, there is no definitive list of what is allowed here; the program creating the .p12 can use any AlgorithmIdentifier it wants, including making up one.

For example, if I was writing software to read and write password-protected .p12 files, I could set AlgorithmIdentifier: AES256WithPBKDF2 and that would be fine. But I could also set AlgorithmIdentifier: MikesCipherWithCatDoodles, and as long the software at the other end known what to do with that, it's still fine.

---

TL;DR: The PKCS#12 format only specifies the structure of the file, it does not list which algorithms are legal, so the actual encryption algorithm used will depend on which software was used to create the .p12 file.

If you want to know which algorithms are used to protect your .p12 files, look up documentation on the software you are using to read / write them.

Answer 4

Since this was necroed, for completeness: OpenSSL can parse a PKCS12 file, in several steps, to find the information about the algorithms used, without the password. As an example:

$ openssl req -newkey rsa:1024 -nodes -keyout se152866.key -x509 -subj /CN=example.net -out se152866.crt
$ openssl pkcs12 -export -in se152866.crt -inkey se152866.key -passout pass:sekrit -out se152866.p12
$ openssl asn1parse -inform der -in se152866.p12 -i
    0:d=0  hl=4 l=1521 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :03
    7:d=1  hl=4 l=1463 cons:  SEQUENCE
   11:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-data
   22:d=2  hl=4 l=1448 cons:   cont [ 0 ]
   26:d=3  hl=4 l=1444 prim:    OCTET STRING      [HEX DUMP]:(long,omitted)
 1474:d=1  hl=2 l=  49 cons:  SEQUENCE
 1476:d=2  hl=2 l=  33 cons:   SEQUENCE
 1478:d=3  hl=2 l=   9 cons:    SEQUENCE
 1480:d=4  hl=2 l=   5 prim:     OBJECT            :sha1
 1487:d=4  hl=2 l=   0 prim:     NULL
 1489:d=3  hl=2 l=  20 prim:    OCTET STRING      [HEX DUMP]:8B3C863D73B51E41CADC9272E1696740B885E69E
 1511:d=2  hl=2 l=   8 prim:   OCTET STRING      [HEX DUMP]:5992FE887D9EA8A3
 1521:d=2  hl=2 l=   2 prim:   INTEGER           :0800

Comparing this to the ASN.1 for outer PFX in PKCS12 sec 4 and 4.1 we see that the 'authSafe' is encoded in the value of the OCTET STRING item at offset 26 with header length (hl) 4 giving 30. Ignoring the (PB)MAC and looking at that:

$ openssl asn1parse -inform der -in se152866.p12 -i -strparse 30
    0:d=0  hl=4 l=1440 cons: SEQUENCE
    4:d=1  hl=4 l= 671 cons:  SEQUENCE
    8:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-encryptedData
   19:d=2  hl=4 l= 656 cons:   cont [ 0 ]
   23:d=3  hl=4 l= 652 cons:    SEQUENCE
   27:d=4  hl=2 l=   1 prim:     INTEGER           :00
   30:d=4  hl=4 l= 645 cons:     SEQUENCE
   34:d=5  hl=2 l=   9 prim:      OBJECT            :pkcs7-data
   45:d=5  hl=2 l=  28 cons:      SEQUENCE
   47:d=6  hl=2 l=  10 prim:       OBJECT            :pbeWithSHA1And40BitRC2-CBC
   59:d=6  hl=2 l=  14 cons:       SEQUENCE
   61:d=7  hl=2 l=   8 prim:        OCTET STRING      [HEX DUMP]:2333FBA5F3B3DCC8
   71:d=7  hl=2 l=   2 prim:        INTEGER           :0800
   75:d=5  hl=4 l= 600 prim:      cont [ 0 ]
  679:d=1  hl=4 l= 761 cons:  SEQUENCE
  683:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-data
  694:d=2  hl=4 l= 746 cons:   cont [ 0 ]
  698:d=3  hl=4 l= 742 prim:    OCTET STRING      [HEX DUMP]:(long,omitted)

we see two ContentInfo's -- one at offset 4 within authSafe (34 in the file) which is password-encrypted with pbeWithSHA1And40BitRC2-CBC and the shown salt and 2048 iterations, and one at offset 679 (709) which is not encrypted at this level. We'd have to decrypt the first one to definitively determine its type, but I happen to know pbe-RC2-40 is always used for certbags, plus it happens to be the correct size for my (example) cert. For the second one we can decode its content part at 702 (732) another level to get SEQUENCE of SafeBag:

$ openssl asn1parse -inform der -in se152866.p12 -i -strparse 732
    0:d=0  hl=4 l= 738 cons: SEQUENCE
    4:d=1  hl=4 l= 734 cons:  SEQUENCE
    8:d=2  hl=2 l=  11 prim:   OBJECT            :pkcs8ShroudedKeyBag
   21:d=2  hl=4 l= 678 cons:   cont [ 0 ]
   25:d=3  hl=4 l= 674 cons:    SEQUENCE
   29:d=4  hl=2 l=  28 cons:     SEQUENCE
   31:d=5  hl=2 l=  10 prim:      OBJECT            :pbeWithSHA1And3-KeyTripleDES-CBC
   43:d=5  hl=2 l=  14 cons:      SEQUENCE
   45:d=6  hl=2 l=   8 prim:       OCTET STRING      [HEX DUMP]:F75E440A3D7429C7
   55:d=6  hl=2 l=   2 prim:       INTEGER           :0800
   59:d=4  hl=4 l= 640 prim:     OCTET STRING      [HEX DUMP]:(long,omitted)
  703:d=2  hl=2 l=  37 cons:   SET
  705:d=3  hl=2 l=  35 cons:    SEQUENCE
  707:d=4  hl=2 l=   9 prim:     OBJECT            :localKeyID
  718:d=4  hl=2 l=  22 cons:     SET
  720:d=5  hl=2 l=  20 prim:      OCTET STRING      [HEX DUMP]:644ED94520BF6A45B81C70F73AE2143DE123A620

which we can see is a pkcs8ShroudedKeyBag which in turn is an EncryptedPrivateKeyInfo from PKCS8 and contains the privatekey encrypted with pbeWithSHA1And3-KeyTripleDES-CBC and the shown salt and 2048 iterations, plus one PKCS12Attribute, localKeyID.

Answer 5

As mentioned before,

the PKCS#12 format only specifies the structure of the file

So it may be encrypted with any of the following algorithms, by the standard:

• 128 bit RC4 with SHA1
• 40 bit RC4 with SHA1
• 3 key 3DES with SHA1 (168 bit)
• 2 key 3DES with SHA1 (112 bit)
• 128 bit RC2 with SHA1
• 40 bit RC2 with SHA1

But, as Mike Ounsworth mentioned before, it can be any custom algorithm as well.