JKS, BKS and PKCS12 file formats

问题

I am in the process of setting up a headless server that builds Phonegap hybrid apps for Android using data - JS, CSS, HTML + a keystore - provided by the user. I want to institute some basic client side checks to ensure that the keystore being uploaded is valid. For JKS files I have found that I can do a rudimentary check by ensuring that the first four bytes of the supplied file are the MAGIC number 0xFEEDFEED as specified here. I realize that this does not eliminate the possibility that the user supplies garbage but it does help as a preliminary client-side screen. I would like to implement similar screening for the PKCS12 and BKS keystores but have been unable to find any explanations for those file formats. I'd be most grateful to anyone who might be able to provide some information on the subject.

回答1:

First, two things to take into consideration:

JCEKS is missing in your list (more secure version of JKS, magic number is 0xCECECECE).
There are two incompatible versions of BKS. The newer version was introduced with Bouncy Castle 1.47, replacing the older version completely. Therefore BKS keystores that were generated with BC 1.47 or newer cannot be read with BC 1.46 or older. In BC 1.49 a new keystore type "BKS-V1" has been added, that is compatible with the older format (see BC Release Notes).

BKS format starts with a version number in the first 4 bytes and ends with a null byte and a SHA-1 hash (20 bytes).

PKCS#12 is not so easy to detect. You will have to parse it as an ASN.1 structure (see RFC 7292):

PFX ::= SEQUENCE {
   version    INTEGER {v3(3)}(v3,...),
   authSafe   ContentInfo,
   macData    MacData OPTIONAL
}

If it cannot be parsed as ASN.1, it's not PKCS#12.

For a more accessible explanation of the PKCS12 format check here.

来源：https://stackoverflow.com/questions/33239875/jks-bks-and-pkcs12-file-formats

标签

android

keystore

jks

pkcs12