1

I have a folder with a private key file, certificate file, and a subfolder with several root certificate files.

I have concatenated the latter into the file $DIR/Root Certificates/all.crt. If I create a pkcs12 certificate out of this using:

openssl pkcs12 -out WILDCARD_clientco_com.pfx -export -passout file:password.txt -aes256 \ 
-in WILDCARD_clientco_com.crt -inkey private.key -certfile Root\ Certificates/all.crt \
-name 'Wildcard ClientCo' -caname 'Intertrust' -caname 'RootTrust' -keyex -macalg sha512 -CSP 'Inicorp'

Then it will fail to import on a windows-PC using Microsoft's own tools with the message that the password is invalid. If I instead execute this command:

openssl pkcs12 -out WILDCARD_clientco_com.pfx -export -passout file:password.txt -aes256 \ 
-in WILDCARD_clientco_com.crt -inkey private.key -certfile Root\ Certificates/all.crt \
-name 'Wildcard ClientCo' -caname 'InterTrust' -caname 'RootTrust' -keyex -CSP 'Inicorp'

Then the pkcs12 cert imports successfully.

Now the default value for the argument macalg is sha1. This has been deprecated as a digest/mac algorithm. Standard recommendation is to now use sha2. Typically sha256 or stronger. Is the fact that Windows certificate import only seems to accept sha1 hashes, failing when I try the value sha256, sha384 or like in the example sha512:

  • A bug/omission in the windows certificate store?
  • A bug in openSSL?
  • Does the command need to be modified in some other way to make that work?
  • Or is it not used for security, just for e.g. a hash table lookup, and therefore it's fine/better to use the faster sha1 anyway?

Edit: Tried this with multiple versions of openSSL. Both 1.0.2, 1.1.0, and 1.1.1 have the same issue.

aphid
  • 273
  • 1
  • 6

1 Answers1

2

PKCS#12 uses the MAC hash function as part of HMAC. The weakness of SHA-1 (and likewise for MD5 and even MD4) is that it's possible to construct collisions in practice. This matters a lot for some applications, such as certificate-based authentication. For the password integrity value in PKCS#12, in order to take advantage of hash collisions, a lot of things have to hold:

  • The attacker needs to know the MAC key, which is derived from the password.
  • The attacker needs to be the one who constructed the original encrypted data.
  • Someone has to care about the MAC value in itself, and not just the fact that it matches the data inside one PKCS#12 blob, for example to identify the blobs by their MAC value.

Each of these conditions would be unusual, and they all have to hold for an attack to be at least theoretically possible.

PKCS#12 also uses a hash algorithm (a different one, specified with -keypbe and -certpbe) as part of a key stretching (a.k.a. password-based key derivation, a.k.a “PBE” if you're old-fashioned like PKCS#12) function. For this purpose, the weaknesses in MD5 and SHA-1 don't matter. For key stretching, collisions are irrelevant, what matters is mostly that it's impossible to find preimages and that the output is statistically well-distributed, and these properties are still true. A faster hash is actually a downside for key stretching, but the effect is negligible compared to upping the iteration count.

The MAC is an optional feature of PKCS#12 anyway. Its only intended purpose is to ensure that the system won't use bad data in case the password is incorrect. This is statistically likely anyway because the decrypted data has to be in a specific format and a bad password will result in pseudorandom data (the attempt to parse this pseudorandom data could trigger a parser bug though — but it would be difficult to exploit since the attacker would have no control over the output of the decryption).

So don't even worry about -macalg if you don't worry about the PBE algorithm. And if you worry about the PBE algorithm, you should use a PKCS#5 algorithm instead of the antiquitated one from PKCS#12.

I have no idea what Windows supports. It's possible that it doesn't support more modern hashes in PKCS#12 PBE because it doesn't matter for security, only compliance, and modern applications should use PKCS#5 anyway.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • If by blobs you mean bags like CertBag and ShroudedKeyBag, the P12 PBMAC is not applied to (an) individual bag(s) but to the whole file. But I don't see why 'caring about the MAC value' is needed to do a collision attack -- unless you mean that an attacker knowing the key could ordinarily forge arbitrary data and would only _attempt_ collision if the MAC value is checked/used? (Otherwise concur all.) – dave_thompson_085 Jul 21 '21 at 11:16
  • @dave_thompson_085 It's not necessary that someone cares about the MAC value to find a collision. But if nobody cares about the MAC value, the existence of a collision is irrelevant, it's not an attack. Probably the best-known use of hashes is as part of signing certificates, where a hash essentially identifies a certificate, and there collisions are critical because they mean someone can have their certificate signed for a certain site name and then substitute a different site name which results in a certificate that looks the same to verifiers. – Gilles 'SO- stop being evil' Jul 21 '21 at 11:32