Я нахожусь в настройке безголового сервера, который создает гибридные приложения Phonegap для Android, используя данные - JS, CSS, HTML + хранилище ключей, предоставленное пользователем. Я хочу установить некоторые основные проверки на стороне клиента, чтобы гарантировать, что загрузочное хранилище ключей действительно. Для файлов JKS я обнаружил, что могу выполнить рудиментарную проверку, гарантируя, что первые четыре байта прилагаемого файла являются MAGIC-номером 0xFEEDFEED
, как указано here. Я понимаю, что это не исключает возможности того, что пользователь поставляет мусор, но он помогает в качестве предварительного экрана на стороне клиента. Я хотел бы реализовать аналогичный скрининг для хранилищ PKCS12 и BKS, но не смог найти никаких объяснений для этих форматов файлов. Я был бы очень благодарен всем, кто мог бы предоставить некоторую информацию по этому вопросу.Форматы файлов JKS, BKS и PKCS12
0
A
ответ
1
Во-первых, две вещи, чтобы принять во внимание:
- JCEKS отсутствует в списке (более безопасная версия JKS, магическое число
0xCECECECE
). - Существует две несовместимые версии BKS. Новая версия была введена с Bouncy Castle 1.47, полностью заменяя старую версию. Следовательно, хранилища ключей BKS, которые были сгенерированы с BC 1.47 или новее, не могут быть прочитаны с BC 1.46 или старше. В BC 1.49 был добавлен новый тип хранилища «BKS-V1», который совместим со старым форматом (см. BC Release Notes).
Формат BKS начинается с номера версии в первых 4 байтах и заканчивается нулевым байтом и хэшем SHA-1 (20 байтов).
PKCS # 12 не так легко обнаружить. Вам придется разобрать его как структуру ASN.1 (см RFC 7292):
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
Если он не может быть разобрано как ASN.1, это не PKCS # 12.
Для более доступного объяснения формата PKCS12 check here.