Каковы достоинства JKS vs PKCS12 для подписи кода?

При покупке сертификата подписи кода, каковы преимущества запуска с PKCS12 по сравнению с сертификатом JKS? Некоторые поставщики дают инструкции по началу работы с запросом на подпись сертификата JKS или PKCS12. Мы хотели бы иметь максимальную гибкость при использовании купленного сертификата, особенно с учетом стоимости. Например, мы можем подписывать больше, чем просто код Java (например, подписание iPhone или Android). Какие технические соображения следует учитывать при выборе подхода?

Ответ 1

Если вы работаете в Java, то Java Key Store является довольно естественным местом для хранения секретных ключей. Приложения Java обычно ожидают получить нужные им ключи от JKS и легко получить доступ к вашим собственным приложениям Java. JKS недоступен (не перепрыгивая через несколько обручей) из-за пределов Java.

Файлы PKCS # 12 (aka PFX), с другой стороны, являются нейтральным для языка способом хранения зашифрованных закрытых ключей и сертификатов и были достаточно длинными, чтобы поддерживать его практически везде. Однако обратите внимание, что формат файла ужасно сложный и чрезмерно общий - посмотрите на Питера Гутмана "PFX - как не разработать криптовый протокол/стандарт" (http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html) для беззаботного взгляда на проблемы.

Обратите внимание, что использование одного или другого из этих форматов хранения действительно представляет собой проблему с тем, как ваше приложение будет хранить зашифрованные закрытые ключи локально. Поставщик, который продает вам ваш сертификат, никогда не увидит закрытый ключ, поэтому ему все равно, какой формат вы используете. Вы отправляете ему (поставщику/ЦС) запрос сертификата PKCS № 10 (содержащий открытый ключ и подписанный с использованием закрытого ключа, но НЕ содержащий закрытый ключ), и он отправляет вам сертификат (который вы можете хранить в JKS или в файл PKCS # 12 или и то, и другое, или где-либо еще, что заставляет вас задуматься).

Технически ни один формат не идеален, так как он защищает закрытый ключ, шифруя его ключом, полученным из пароля; это не делает ни один лучше, чем другой. Безопасность (хотя и не удобство) лучше, если вы можете использовать смарт-карту или другое решение для хранения аппаратного ключа.

Основным фактором, определяющим ваш выбор, должно быть то, как вы планируете использовать закрытый ключ - то есть: какие приложения должны будут использовать закрытый ключ и какой формат хранилища ключей они уже обрабатывают. PKCS # 12 является более гибким вариантом... но если вы намерены использовать ключ только с кодом, который вы пишете сами (интероперабельность не требуется), то вы также можете рассмотреть использование контейнеров PKCS # 8 или PKCS # 15.

Я не могу рекомендовать писать собственный код для обработки PKCS # 12 (я сделал это, а не весело) - используйте проверенную стороннюю библиотеку (например, OpenSSL).

Ответ 2

Если у вас есть хранилище ключей JKS, вы можете конвертировать в PKCS12, используя приведенные ниже команды.

keytool -importkeystore  -srckeypass secret -destkeypass meow123  -srcstorepass secretstore -deststorepass secretstore  -srcalias certforsigning -destalias certforsigning  -srcalias certforencryption -destalias certforencryption -srckeystore my_java_keystore.jks -destkeystore PFX_keystore.pfx  -deststoretype PKCS12

где my_java_keystore.jks - это хранилище ключей Java, которое имеет два ключа с псевдонимом сертификация и certforencryption

и вы также можете преобразовать ключи из PKCS12 в JKS с помощью Keytool