2

I need to move user cryptographic identity between several user devices. In the operating system I have only one option: use password-protected PKCS #12 to import the identity to the OS secure store.

I’m wondering how secure PKCS #12 is. Can the p12 file be distributed over the insecure channel? How secure is it compared to the solution where a fixed password is used for the p12 (just because the API requires that), but then the result is encrypted using the combination of PBKDF2 + AES-256 in CBC + HMAC.

Bruno Rohée
  • 5,221
  • 28
  • 39
eofster
  • 205
  • 1
  • 6

1 Answers1

4

PKCS#12 is an extremely flexible format, so any answer to your question is relative to what the archive producer decided to do: which algorithms, which parameters...

Normally, when doing password-based encryption, you will end up with 3DES or AES, and the key derivation algorithm is PBKDF2 with a cost parameter that you do not get to choose. To make the story short, this will be as safe as these things can be IF (and that's a big "if") the used password is strong.

For a specialized use case, you can generate the "password" as an actual big key: take your favourite cryptographically secure PRNG (e.g. /dev/urandom on Linux and MacOS X) and use it to produce a sequence of 24 random hexadecimal digits. This will offer 96 bits of entropy, and things will be fine. The confidentiality of the private key in the PKCS#12 file will be maintained, and the integrity will be reliably verified.

A simple way to generate such a random "password" on a Linux system is:

(dd if=/dev/urandom bs=16 count=1 2>/dev/null) | sha1sum | cut -b 1-24

On Windows you can use PowerShell:

$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$buf = New-Object byte[] 12
$rng.GetBytes($buf)
([System.BitConverter]::ToString($buf) -replace "-", "").ToLowerInvariant()

If you really want to add an extra layer, the reasonable way is not to assemble a symmetric encryption algorithm and a MAC yourself: these things are deceptively hard, meaning that it is easy to make something which works, much harder to make something which is strong, and very much harder to make something that can be ascertained to be strong. Instead, use an existing protocol which is supported by an existing, well-vetted implementation. I suggest GnuPG (the OpenPGP format implemented by GnuPG supports both symmetric and asymmetric encryption).

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • If the OS API that supports import and export to and from PKCS#12 uses 3DES, does only this fact automatically mean that it is considered to be weak or other facts must be taken into account? Specifically, I’m talking about iOS. It has the only function in the native API for importing p12, and it looks like it supports only 3DES. – eofster Apr 03 '14 at 14:52
  • 3
    3DES is not weak. The best known attack uses a ludicrous amount of memory (almost a million terabytes) and an outrageously high amount of CPU (2^112, way beyond that which is doable with Earth technology). If 3DES is the weakest point of your system, then you are very lucky indeed; more likely, 3DES is the _strongest_ element, and that's not through it that you will get hacked. – Tom Leek Apr 03 '14 at 15:22
  • In some cases, even when 3DES is used to encrypt the private key, PKCS#12 PBE is used for key derivation and not PBKDF2. You would have to look inside the PKCS#12 to see what is used. I'll post an answer to this question with one way to check. – Jim Flood Sep 07 '15 at 21:30