JKS、BKS 和 PKCS12 文件格式

我正在设置一个无头服务器，该服务器使用用户提供的数据（JS、CSS、HTML + 密钥库）为 Android 构建 Phonegap 混合应用程序。我想进行一些基本的客户端检查，以确保上传的密钥库有效。对于 JKS 文件，我发现可以通过确保提供的文件的前四个字节是 MAGIC 数字来进行基本检查0xFEEDFEED作为指定here http://metastatic.org/source/JKS.java。我意识到这并不能消除用户提供垃圾的可能性，但它作为初步的客户端屏幕确实有所帮助。我想对 PKCS12 和 BKS 密钥库实施类似的筛选，但无法找到这些文件格式的任何解释。我将非常感谢任何能够提供有关该主题的信息的人。

首先，需要考虑两件事：

• 您的列表中缺少 JCEKS（JKS 的更安全版本，幻数是0xCECECECE).
• BKS 有两个不兼容的版本。新版本随 Bouncy Castle 1.47 一起推出，完全取代了旧版本。因此，使用 BC 1.47 或更高版本生成的 BKS 密钥库无法使用 BC 1.46 或更早版本读取。在 BC 1.49 中添加了新的密钥库类型“BKS-V1”，它与旧格式兼容（请参阅BC 发行说明 https://www.bouncycastle.org/releasenotes.html).

BKS 格式以前 4 个字节中的版本号开始，以空字节和 SHA-1 哈希（20 个字节）结束。

PKCS#12 并不那么容易检测到。您必须将其解析为 ASN.1 结构（请参阅RFC 7292 https://www.rfc-editor.org/rfc/rfc7292):

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

如果文件无法解析为上述 ASN.1 结构，则它不是 PKCS#12。

有关 PKCS12 格式的更易于理解的说明检查这里 http://www.emc.com/collateral/white-papers/h11301-pkcs-12v1-1-personal-information-exchange-syntax-wp.pdf.