java keystore и его особенности

Данные надо защищать. А важные данные надо защищать хорошо! Одним из самых распространённых способов защиты - во все времена и в различных сферах - является шифрование данных. Криптография, симметричное и асимметричное шифрование, ключи, сертификаты и многое другое связано с этой задачей. Далее в посте немного о так называемом keystore - месте хранения ключей и сертификатов в java.
 

1) Итак, keystore - это специализированное хранилище секьюрных данных, которое используются java-приложениями. Вместе с jdk разработчикам доступны три реализации хранилища.

Стандартный тип - файл с расширением jks ("java key storage"). Он установлен по умолчанию, а потому применяется наиболее часто.

Следующий вариант - jceks - альтернативная реализация, которая использует более сильное шифрование на основе triple DES. Можно обновить имеющееся jks-хранилище до jceks командой типа "keytool -keypasswd -alias signkey -storetype jceks" - см. подробнее инструмент keytool.

И ещё один вариант - это pkcs12, основанный на RSA PKCS#12: Personal Information Exchange Syntax Standard (этот стандарт прежде всего предназначается для хранения или переноса закрытых ключей пользователя, сертификатов и пр.).

При необходимости возможна и собственная реализация.

2) Каждая запись в keystore имеет уникальный псевдоним (alias), благодаря которым ими удобно оперировать. Чувствительность к регистру псевдонима зависит от реализации (в реализации jks в jdk 6 регистр не учитывается). Поэтому чтобы избежать проблем, рекомендуется не использовать в keystore псевдонимы, которые отличаются только регистром.

3) В стандартной реализации каждый ключ в хранилище защищается паролем; кроме того, всё хранилище целиком может быть защищено отдельным паролем.

4) Стандартное хранилище доверенных CA-сертификатов лежит в jre/lib/security/cacerts (пароль - changeit).

5) Вообще говоря, секьюрная информация может быть сгруппирована в две различные категории: ключевые записи (пары "приватный ключ + открытый ключ") и доверенные сертификаты. Ключевая запись состоит из идентификационных данных объекта и его закрытого ключа, и может использоваться для множества криптографических целей. Напротив, доверенный сертификат содержит только открытый ключ в дополнение к идентификационным данным объекта. Таким образом, запись с доверенным сертификатом не может использоваться в тех случаях, где закрытый ключ требуется (например, в javax.net.ssl.KeyManager).

В реализации "jks" keystore может содержать и ключевые записи, и сертификаты. Как же поступать - использовать одно хранилище для всего или как-то разделять записи?
Думается, что правильно работать с двумя различными keystore-файлами: один для собственных ключей, а другой для доверенных сертификаторв, включая сертификатры Центров сертификации (CA). Такой подход позволяет реализовать более чистое разделение логического различия между собственными сертификатами (и соответствующими закрытыми ключами) и сертификатами других. Также можно обеспечить более высокую защиту для своих закрытых ключей в отдельном keystore с ограниченным доступом, а доверенные  сертификаты оставить в более свободном доступе.

6) В стандартной поставке из-за экспортных ограничений java не поддерживает сильную криптографию (с большой длиной ключей). Также при попытке использовать ключи, созданные в другой среде (не-java) может возникнуть исключение Illegal Key Size. Чтобы решить проблему, можно скачать и установить Java Cryptography Extension Unlimited Strength Jurisdiction Policy Files (2 небольших jar-файла, которые нужно скопировать в инсталляцию java).