Каковы преимущества JKS vs PKCS12 для подписания кода?
при покупке сертификата подписи кода, каковы преимущества начала с pkcs12 против сертификата JKS? Некоторые поставщики дайте инструкции по запуску с запросом подписи сертификата JKS или PKCS12. Мы хотели бы иметь максимальную гибкость в использовании приобретенного сертификата, особенно учитывая стоимость. Например, мы можем подписывать больше, чем просто Java-код (например, iPhone или Android-код). Какие технические соображения следует учитывать при выборе любой подход?
2 ответов
Если вы работаете в Java, то хранилище ключей Java является довольно естественным местом для хранения закрытых ключей.Приложения Java обычно ожидают получить необходимые ключи от JKS, и к ним легко получить доступ из ваших собственных приложений Java. Однако JKS недоступен (без прыжков через несколько обручей) извне Java.
PKCS#12 (aka PFX) файлы, с другой стороны, являются нейтральным языком для хранения зашифрованных закрытых ключей и сертификатов и существует достаточно долго, что это поддерживается практически везде. Обратите внимание, однако, что формат файла ужасно сложный и общий - посмотрите на "PFX-How Not to Design a Crypto Protocol/Standard" Питера Гутмана (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).
если у вас есть хранилище ключей 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 с двумя ключами с псевдонимами certforsigning и certforencryption
и вы также можете конвертировать ключи от PKCS12 в JKS с помощью Keytool