2015-10-20 9 views
0

Я нахожусь в настройке безголового сервера, который создает гибридные приложения Phonegap для Android, используя данные - JS, CSS, HTML + хранилище ключей, предоставленное пользователем. Я хочу установить некоторые основные проверки на стороне клиента, чтобы гарантировать, что загрузочное хранилище ключей действительно. Для файлов JKS я обнаружил, что могу выполнить рудиментарную проверку, гарантируя, что первые четыре байта прилагаемого файла являются MAGIC-номером 0xFEEDFEED, как указано here. Я понимаю, что это не исключает возможности того, что пользователь поставляет мусор, но он помогает в качестве предварительного экрана на стороне клиента. Я хотел бы реализовать аналогичный скрининг для хранилищ PKCS12 и BKS, но не смог найти никаких объяснений для этих форматов файлов. Я был бы очень благодарен всем, кто мог бы предоставить некоторую информацию по этому вопросу.Форматы файлов JKS, BKS и PKCS12

ответ

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.