{"id":543,"date":"2015-12-02T10:38:49","date_gmt":"2015-12-02T18:38:49","guid":{"rendered":"http:\/\/unmitigatedrisk.com\/?p=543"},"modified":"2015-12-05T09:44:14","modified_gmt":"2015-12-05T17:44:14","slug":"pkcs12-needs-another-update","status":"publish","type":"post","link":"https:\/\/unmitigatedrisk.com\/?p=543","title":{"rendered":"The PKCS#12 standard needs another update"},"content":{"rendered":"

PKCS#12<\/span><\/a> is the defacto file format for moving private keys and certificates around. It was defined by RSA and Microsoft in the late 90s and is used by Windows extensively. It was also recently added to <\/span>KIMP<\/span><\/a> as a means to export key material.<\/span><\/p>\n

As an older format, it was designed with support for algorithms like MD2, MD5, SHA1, RC2, RC4, DES and 3DES. It was recently standardized by <\/span>IETF RFC 7292 <\/span><\/a>and the IETF took this opportunity to add support for SHA2 but have not made an accommodation for any mode of AES.<\/span><\/p>\n

Thankfully PKCS #12 is based on <\/span>CMS<\/span><\/a> which does support AES (see <\/span>RFC 3565<\/span><\/a> and <\/span>RFC 5959<\/span><\/a>). In theory, even though RFC 7292 doesn\u2019t specify a need to support AES, \u00a0there is enough information to use it in an interoperable way.<\/span><\/p>\n

Another standard used by PKCS#12 is PKCS #5 (<\/span>RFC 2898<\/span><\/a>), this specifies the mechanics of password-based encryption. It provides two ways to do this PBES1 and PBES2, more on this later. <\/span><\/p>\n

Despite these complexities and constraints, we wanted to see if we could provide a secure and interoperable implementation of PKCS#12 in PKIjs<\/a> since it is one of the most requested features. This post documents our findings.<\/span><\/p>\n

Observations<\/span><\/h1>\n

Lots of unused options<\/span><\/h2>\n

PKCS#12 is the swiss army knife of certificate and key transport. It can carry keys, certificates, CRLs and other metadata. The specification offers both password and certificate-based schemes for privacy and integrity protection.<\/span><\/p>\n

This is accomplished by having an outer \u201cintegrity envelope\u201d that may contain many \u201cprivacy envelopes\u201d. <\/span><\/p>\n

When using certificates to protect the integrity of its contents, the specification uses the CMS SignedData message to represent this envelope. <\/span><\/p>\n

When using passwords it uses an HMAC placed into its own data structure.<\/p>\n

The use of an outer envelope containing many different inner envelopes enables the implementor to mix and match various types of protection approaches into a single file. It also enables implementers to use different secrets for integrity and privacy protection.<\/span><\/p>\n

Despite this flexibility, most implementations only support the following combination:<\/span><\/p>\n

    \n
  1. Optionally using the HMAC mechanism for integrity protection of certificates<\/span><\/li>\n
  2. Using password-based privacy protection for keys<\/span><\/li>\n
  3. Using the same password for privacy protection of keys<\/span><\/li>\n<\/ol>\n

    NOTE<\/b>: OpenSSL was the only implementation we found that supports the ability to use a different password for the \u201cintegrity envelope\u201d and \u00a0\u201cprivacy envelope\u201d. This is done using the \u201ctwopass\u201d option of the <\/span>pkcs12<\/b> command.<\/span><\/p>\n

    The formats flexibility is great. We can envision a few different types of scenarios one might be able to create with it, but there appears to be no documented profile making it clear what is necessary to interoperate with other implementations.<\/span><\/p>\n

    It would be ideal if a future incarnation of the specification provided this information for implementers. <\/span><\/p>\n

    Consequences of legacy<\/span><\/h2>\n

    As mentioned earlier there are two approaches for password based encryption defined in PKCS#5 (<\/span>RFC 2989<\/span><\/a>). <\/span><\/p>\n

    The first is called PBES1, according to the RFC :<\/span><\/p>\n

    PBES1 is recommended only for compatibility with existing<\/span><\/i>
    \n<\/span><\/i>applications, since it supports only two underlying encryption<\/span><\/i>
    \n<\/span><\/i>schemes, each of which has a key size (56 or 64 bits) that may not be<\/span><\/i>
    \n<\/span><\/i>large enough for some applications.<\/span><\/i><\/p><\/blockquote>\n

    The PKCS#12 RFC reinforces this by saying:<\/span><\/p>\n

    The procedures and algorithms<\/span><\/i>
    \n<\/span><\/i>defined in PKCS #5 v2.1 should be used instead.<\/span><\/i>
    \n<\/span><\/i>Specifically, PBES2 should be used as encryption scheme, with PBKDF2<\/span><\/i>
    \n<\/span><\/i>as the key derivation function.<\/span><\/i><\/p><\/blockquote>\n

    With that said it seems, there is no indication in the format on which scheme is used which leaves an implementor forced with trying both options to \u201cjust see which one works\u201d.<\/span><\/p>\n

    Additionally it seems none of the implementations we have encountered followed this advice and only support the PBES1 approach.<\/span><\/p>\n

    Cryptographic strength<\/span><\/h2>\n

    When choosing cryptographic algorithm one of the things you need to be mindful of is the minimum effective strength. There are differing opinions on what each algorithm’s minimum effective strength is at different key lengths, but normally the difference not significant. These opinions also change as computing power increases along with our ability to break different algorithms.<\/span><\/p>\n

    When choosing which algorithms to use together you want to make sure all algorithms you use in the construction offer similar security properties If you do not do this the weakest algorithm is the weakest link in the construction. It seems there is no guidance in the standard for topic, as a result we have found:<\/span><\/p>\n

      \n
    1. Files that use weak algorithms protection of strong \u00a0keys,<\/span><\/li>\n
    2. Files that use a weaker algorithm for integrity than they do for privacy.<\/span><\/li>\n<\/ol>\n

      This first point is particularly important. The most recently available guidance for minimum effective key length comes from the German Federal Office for Information Security, BSI. These guidelines, when interpreted in the context of PKCS #12, recommend that a 2048-bit RSA key protection happens using SHA2-256 and a 128-bit symmetric key. <\/span><\/p>\n

      The strongest symmetric algorithm specified in the PKCS #12 standard is 3DES which only offers an effective strength of 112-bits. \u00a0This means, if you believe the BSI, it is not possible to create a standards compliant PKCS#12 that offer the effective security necessary to protect a 2048-bit RSA key. <\/span><\/p>\n

      ANSI on the other hand, currently recommends that 100-bit symmetric key is an acceptable minimum strength to protect a 2048-bit RSA key (though this recommendation was made a year earlier than the BSI recommendation).<\/span><\/p>\n

      So if you believe ANSI, the strongest suite offered by RFC 7292 is strong enough to \u201cadequately\u201d protect such a key, just not a larger one.<\/span><\/p>\n

      The unfortunate situation we are left with in is that it is not possible to create a \u201cstandards compliant\u201d PKCS12 that support\u00a0modern cryptographic recommendations.<\/span><\/p>\n

      Implementations<\/span><\/h1>\n

      OpenSSL<\/span><\/h2>\n

      A while ago OpenSSL was updated to support AES-CBC in PKCS#8 which is the format that PKCS#12 uses to represent keys. \u00a0In an ideal world, we would be using AES-GCM for our interoperability target but we will take what we can get.<\/span><\/p>\n

      To create such a file you would use a command similar to this:<\/span><\/p>\n\n\n\n
      rmh$ openssl genrsa 2048|openssl pkcs8 -topk8 -v2 aes-256-cbc -out key.pem<\/span><\/p>\n

      Generating RSA private key, 2048 bit long modulus<\/span><\/p>\n

      ……………+++<\/span><\/p>\n

      ……………….+++<\/span><\/p>\n

      e is 65537 (0x10001)<\/span><\/p>\n

      Enter Encryption Password:<\/span><\/p>\n

      Verifying – Enter Encryption Password:<\/span>
      \nrmh$ cat key.pem <\/span><\/p>\n

      —–BEGIN ENCRYPTED PRIVATE KEY—–<\/span><\/p>\n

      \u2026<\/span><\/p>\n

      \u2026<\/span><\/p>\n

      …<\/span><\/p>\n

      —–END ENCRYPTED PRIVATE KEY—–<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      If you look at the resulting file with an <\/span>ASN.1 parser<\/span><\/a> you will see the file says the Key Encryption Key (KEK) is <\/span>aes-256-cbc<\/span><\/a>. <\/span><\/p>\n

      It seems the latest OpenSSL (1.0.2d) will even let us do this with a PKCS#12, those commands would look something like this:<\/span><\/p>\n\n\n\n
      openssl genrsa 2048|openssl pkcs8 -topk8 -v2 aes-256-cbc -out key.pem<\/span><\/p>\n

      openssl req -new -key key.pem -out test.csr<\/span><\/p>\n

      openssl x509 -req -days 365 -in test.csr -signkey key.pem -out test.cer<\/span><\/p>\n

      openssl pkcs12 -export -inkey key.pem -in test.cer -out test.p12 -certpbe AES-256-CBC -keypbe AES-256-CBC<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      NOTE<\/b>: If you do not specify explicitly specify the certpbe and keypbe algorithm this version defaults to using <\/span>pbewithSHAAnd40BitRC2-CBC<\/span><\/a> to protect the certificate and <\/span>pbeWithSHAAnd3-KeyTripleDES-CBC<\/span><\/a> to protect the key. <\/span><\/p>\n

      RC2 was designed in 1987 and has been considered weak for a very long time. 3DES is still considered by many to offer 112-bits of security though in 2015 it is clearly not an algorithm that should still be in use.<\/span><\/p>\n

      Since it supports it OpenSSL should really be updated to use aes-cbc-256 by default and it would be nice if \u00a0support for AES-GCM was also added.<\/span><\/p>\n

      NOTE<\/b>: We also noticed if you specify \u201c-certpbe NONE and -keypbe NONE\u201d (which we would not recommend) that OpenSSL will create a PKCS#12 that uses password-based integrity protection and no privacy protection.<\/span><\/p>\n

      Another unfortunate realization is OpenSSL uses an iteration count of 2048 when deriving a key from a password,\u00a0<\/span>by today\u2019s standards is far too small<\/span><\/a>.<\/span><\/p>\n

      We also noticed the OpenSSL output of the pkcs12 command does not indicate what algorithms were used to protect the key or the certificate, this may be one reason why the defaults were never changed — users simply did not notice:<\/span><\/p>\n\n\n\n
      rmh$ openssl pkcs12 -in windows10_test.pfx <\/span><\/p>\n

      Enter Import Password:<\/span><\/p>\n

      MAC verified OK<\/span><\/p>\n

      Bag Attributes<\/span><\/p>\n

      \u00a0\u00a0\u00a0localKeyID: 01 00 00 00 <\/span><\/p>\n

      \u00a0\u00a0\u00a0friendlyName: {4BC68C1A-28E3-41DA-BFDF-07EB52C5D72E}<\/span><\/p>\n

      \u00a0\u00a0\u00a0Microsoft CSP Name: Microsoft Base Cryptographic Provider v1.0<\/span><\/p>\n

      Key Attributes<\/span><\/p>\n

      \u00a0\u00a0\u00a0X509v3 Key Usage: 10 <\/span><\/p>\n

      Enter PEM pass phrase:<\/span><\/p>\n

      Bag Attributes<\/span><\/p>\n

      \u00a0\u00a0\u00a0localKeyID: 01 00 00 00 <\/span><\/p>\n

      subject=\/CN=Test\/O=2\/OU=1\/emailAddress=2@2.com\/C=<\\xD0\\xBE<\/span><\/p>\n

      issuer=\/CN=Test\/O=2\/OU=1\/emailAddress=2@2.com\/C=<\\xD0\\xBE<\/span><\/p>\n

      —–BEGIN CERTIFICATE—–<\/span><\/p>\n

      \u2026<\/span><\/p>\n

      …<\/span><\/p>\n

      —–END CERTIFICATE—–<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Windows<\/span><\/h2>\n

      Unfortunately, it seems that all versions of Windows (even Windows 10) still produces PKCS #12\u2019s using <\/span>pbeWithSHAAnd3-KeyTripleDES-CBC<\/b> for \u201cprivacy\u201d of keys and privacy of certificates it uses <\/span>pbeWithSHAAnd40BitRC2-CBC<\/b>. It then relies on the HMAC scheme for integrity.<\/span><\/p>\n

      Additionally it seems it only supports PBES1 and not PBES2.<\/span><\/p>\n

      Windows also uses an iteration count of 2048 when deriving keys from passwords which is far too small<\/span>.<\/span><\/p>\n

      It also seems unlike OpenSSL, Windows is not able to work with files produced with more secure encryption schemes and ciphers.<\/span><\/p>\n

      PKIjs<\/span><\/h2>\n

      PKIjs has two, arguably conflicting goals, the first of which is to enable modern web applications to interoperate with traditional X.509 based applications. The second of which is to use modern and secure options when doing this.<\/span><\/p>\n

      WebCrypto has a similar set of guiding principles, this is why it does not support weaker algorithms like RC2, RC4 and 3DES.<\/span><\/p>\n

      Instead of bringing in javascript based implementations of these weak algorithms into PKIjs we have decided to only support the algorithms supported by webCrypto (aes-256-cbc, aes-256-gcm with SHA1 or SHA2 using PBES2.<\/span><\/p>\n

      This represents a tradeoff. The keys and certificates and exported by PKIjs will be protected with the most interoperable and secure pairing of algorithms available but the resulting files will still not work in any version of Windows (even the latest Windows 10 1511 build).<\/span><\/p>\n

      The profile of PKCS#12 PKIjs creates that will work with OpenSSL will only do so if you the -nomacver option:<\/span><\/p>\n\n\n\n
      openssl pkcs12 -in pkijs_pkcs12.pfx -nomacver\u2028<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      This is because OpenSSL uses the older PBKDF1 for integrity protection and PKIjs is using the newer PBKDF2, as a result of this command integrity will not be checked on the PKCS#12.<\/span><\/p>\n

      With that caveat, here is an example of how one would generate a <\/span>PKCS#12 with PKIjs<\/a>.<\/span><\/p>\n

      Summary<\/span><\/h1>\n

      Despite its <\/span>rocky start<\/span><\/a>, PKCS#12 is still arguably one of the most important cryptographic message formats. An attempt has been made to modernize it somewhat, but they did not go far enough.<\/span><\/p>\n

      It also seems OpenSSL has made an attempt to work around this gap by adding support for AES-CBC to their implementation.<\/span><\/p>\n

      Windows on the other hand still only appear to support only the older encryption construct with the weaker ciphers.<\/span><\/p>\n

      That said even when strong, modern cryptography are in use we must remember any password-based encryption scheme will only be as secure as the password that is used with it. As a proof point,\u00a0consider these tools for <\/span>PKCS#12<\/span><\/a> and <\/span>PKCS#8<\/span><\/a> that make password cracking trivial for these formats.<\/span><\/p>\n

      We believe the storage and transport of encrypted private keys is an important enough topic that it deserves a modern and secure standard. With that in mind recommend the following changes to RFC 7292 be made:<\/span><\/p>\n