Каковы преимущества JKS против PKCS12 для подписи кода? - PullRequest
21 голосов
/ 05 октября 2010

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

Ответы [ 2 ]

40 голосов
/ 14 октября 2010

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

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

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

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

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

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

5 голосов
/ 23 апреля 2013

Если у вас есть хранилище ключей 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

...