5

PKCS#12 is a convenient way to lump together a private key with its corresponding X.509 certificate into a standardized single file format. However, the specification was published by RSALabs in 1999 and uses only RC4, RC2 and TripleDES for symmetric encryption. Are there any common semi-standard extensions to the scheme that add more encryption algorithms or other key derivation functions? OpenSSL is documented to implement support for AES and Camellia, but a search for a corresponding standard turns up blank, so this seems to be something implementation specific to OpenSSL. Has anyone documented the ASN.1 module and pseudo code for these extensions?

Henrick Hellström
  • 2,556
  • 16
  • 18

1 Answers1

3

PKCS#12 uses building-blocks from other standards.

The recommended encryption-mode is based on password based encryption from PKCS#5 (PBES2). This has been extended with support for SHA-2 and AES in PKCS#5 v.2.1.

When OpenSSL uses AES it does it like this:

 684 30  806:                     SEQUENCE {
 688 30  802:                       SEQUENCE {
 692 06   11:                         OBJECT IDENTIFIER
            :                           pkcs-12-pkcs-8ShroudedKeyBag (1 2 840 113549 1 12 10 1 2)
 705 A0  723:                         [0] {
 709 30  719:                           SEQUENCE {
 713 30   73:                             SEQUENCE {
 715 06    9:                               OBJECT IDENTIFIER
            :                                 pkcs5PBES2 (1 2 840 113549 1 5 13)
 726 30   60:                               SEQUENCE {
 728 30   27:                                 SEQUENCE {
 730 06    9:                                   OBJECT IDENTIFIER
            :                                     pkcs5PBKDF2 (1 2 840 113549 1
5 12)
 741 30   14:                                   SEQUENCE {
 743 04    8:                                     OCTET STRING
            :                   BA 6B 5B B3 47 27 C9 73
 753 02    2:                                     INTEGER 2048
            :                                     }
            :                                   }
 757 30   29:                                 SEQUENCE {
 759 06    9:                                   OBJECT IDENTIFIER
            :                                     aes128-CBC (2 16 840 1 101 3 4 1 2)
 770 04   16:                                   OCTET STRING
            :                   0F 79 79 0A D3 EC C0 3E 20 B8 51 85 2F 2B 6C 29
            :                                   }
            :                                 }
            :                               }

As far as I can read the source, OpenSSL encodes the password as ASCII rather than zero-terminated UTF-16 when using PKCS#5 PBES2.

Rasmus Faber
  • 48,631
  • 24
  • 141
  • 189
  • Well, not exactly. PKCS#12 uses a PBKDF that is specified in appendix B.2 and is different from both PBKDF1 of PBKDF2 of PKCS#5 in several respects. For instance, unlike PKCS#5 PBKDF1 it features key stretching, unlike PKCS#5 PBKDF2 it uses an iterated hash instead of a xor sum of HMAC outputs, and unlike both it formats the salt and password in an unusual way. – Henrick Hellström Mar 09 '12 at 12:42
  • To be more specific: PKCS#12 appendix B.1 specifies that passwords should be viewed as BMPStrings instead of simple OctetStrings. This means that if a PKCS#5 algorithm identifier would be encountered in the encryption algorithm identifier field of a PKCS#12 file, it would be undetermined whether the password should be treated as a BMPString or not. Hence, the processing rules would still have to be specified externally to be unequivocal. – Henrick Hellström Mar 09 '12 at 12:55
  • 1
    @Henrick Hellström: As far as I remember, the PBKDF in appendix B.2 is only for backwards compatibility with the old Microsoft format. If you read the note on page 13, you will notice that it is recommended to use the PKCS#5 mechanisms. – Rasmus Faber Mar 09 '12 at 13:03
  • 1
    @Henrick Hellström: Appendix B.1 applies to all PBKDFs. So as far as I read the standard, it would be clear that the password should be treated as a BMPString. – Rasmus Faber Mar 09 '12 at 13:06
  • Thanks, that's helpful! However, I think Peter Gutmann's rant http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html applies to that footnote as well, since it doesn't say how the passwords should be encoded if the PKCS#5 v2 algorithms are used. BMPString or ASCII? – Henrick Hellström Mar 09 '12 at 13:15
  • I think it is undetermined. The footnote says that appendix B applies only to the algorithms defined in PKCS#12, but on the other hand PKCS#5 doesn't say anything about how a password character string is converted into an octet string, and PKCS#12 B.1 is the only text that says anything about it. – Henrick Hellström Mar 09 '12 at 13:19
  • 1
    @Henrick Hellström: I think you are correct that appendix B.1. should not apply to PKCS#5. So OpenSSL is probably correct in using ASCII for PBES2. – Rasmus Faber Mar 09 '12 at 13:53