1

It seems that the default password based key derivation function that is used by PKCS12 to generate a MAC is this one. It is unique to the standard and probably not used anywhere else. Is it possible to use PBKDF2 instead to generate a MAC? Surely I can use PBES2 scheme with PBKDF2 to protect key bags, but how do I encode this information for the whole file's MAC? Is it possible in principle? So far my attempts to use it resulted in files that are not recognized both by OpenSSL and Windows tools.

2 Answers 2

4

NO. (sorry)

Actually you need all of B not just B.2, and if you try to implement this note the formulas in B.2 step 6 have errors; see https://www.rfc-editor.org/errata_search.php?rfc=7292 .

See section 4 item 3:

... if [MAC] present ... As described in Appendix B, the MAC key is derived from the password, the macSalt, and the iterationCount; as described in Section 5, the MAC is computed from the authSafe value and the MAC key via HMAC [11] [20]. ...

No alternative is allowed for.

Although I don't think it's clearly stated anywhere, the AlgorithmIdentifier in the DigestInfo identifies the hash used in the PBMAC, not the PBMAC itself; in fact it can't identify the PBMAC as there is no OID defined for this PBMAC, whereas there are OIDs (in Appendix C) for the 'password privacy' (encryption) schemes (and also parameters suitable for an AlgorithmIdentifier). Thus there is no place you could provide the information about an alternative PBMAC that the recipient/reader needs to know about and use. (Whereas your PKCS8 shroudedkeybag(s), and also PKCS7-encrypted certbag(s) if you follow the usual practice, can have PBES2+parameters in their AlgorithmIdentifier.)

Confirming this, appendix C says:

This section is here for two reasons: first, to enable backwards compatibility as described in the first paragraph of this section; second, because it is still used in password integrity mode. In order to not use it in password integrity mode, the ASN.1 definitions require updates. This document recommends that future definitions of the PFX structure replace the existing MacData object, optionally present in password integrity mode, with a new object definition that holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication scheme. This change would simplify the requirements for key derivation functions used across all parts of the PFX structure.

which explicitly says your idea is a good one but not presently possible. This paragraph is added relative to the RSALabs original document, and is almost the only such substantive change.

Also, a nit: the MAC doesn't cover the 'whole file', only the AuthenticatedSafe. This excludes the version and the ContentInfo 'wrapper' (tags & lengths & OID), and of course excludes the MAC itself and the outer SEQUENCE tag & length.

0

There is an IETF draft at https://datatracker.ietf.org/doc/draft-kario-pkcs12-pbmac1/ which uses PBMAC1 as MacData in a PKCS #12 file.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .