Как keytool защищает ключи?

Question

Когда вы создаете хранилище ключей с помощью утилиты Java Keytool, как защищены ключи? Я прочитал документацию и понял, что у каждого закрытого ключа есть пароль ключа, а затем у магазина есть пароль магазина.

Но какой механизм используется для защиты данных? Это шифровальный шифр? Если так, то каков алгоритм? Я сосредоточен именно на том, как keytool защищает при создании файла JKS.

Answer 1

В хранилище ключей JKS Sun по умолчанию используется собственный алгоритм, в основном для экспорта ограничений стандартных алгоритмов. Алгоритм, реализованный в этом классе,

  sun.security.provider.KeyProtector

Описание алгоритма,

Это реализация собственного, экспортируемого алгоритма Sun, предназначенного для использования при защите (или восстановлении версии с открытым текстом) чувствительных ключей. Этот алгоритм не предназначен для шифрования общего назначения. Вот как работает алгоритм защиты ключа: p - пароль пользователя s - случайная соль X - ключ xor P - ключ для защиты Y - защищенный ключ R - что хранится в хранилище ключей Шаг 1: Возьмите пароль пользователя, добавьте к нему случайную соль (фиксированного размера) и хешируйте ее: d1 = digest (p, s) Сохраните d1 в X. Шаг 2. Возьмите пароль пользователя, добавьте результат дайджеста из предыдущего шага и хешируйте его: dn = дайджест (p, dn-1). Сохраните dn в X (добавьте его к ранее сохраненным дайджестам). Повторяйте этот шаг, пока длина X не совпадет с длиной закрытого ключа P. Шаг 3: XOR X и P и сохраните результат в Y: Y = X XOR P. Шаг 4: Сохраните s, Y и дайджест (p , P) в буфере результатов R: R = s + Y + дайджест (p, P), где "+" обозначает конкатенацию. (ПРИМЕЧАНИЕ: дайджест (p, P) сохраняется в буфере результатов, поэтому при восстановлении ключа мы можем проверить, действительно ли восстановленный ключ соответствует исходному ключу.) R хранится в хранилище ключей. Защищенный ключ восстанавливается следующим образом: шаги 1 и 2 такие же, как указано выше, за исключением того, что соль генерируется не случайным образом, а берется из результата R шага 4 (первые байты длины (й)). Шаг 3 (операция XOR) возвращает текстовый ключ. Затем объедините пароль с восстановленным ключом и сравните с последней длиной (дайджест (p, P)) байтов R. Если они совпадают, восстановленный ключ действительно является тем же ключом, что и исходный ключ.

Answer 2

Используемый алгоритм зависит от используемого вами хранилища ключей (например, это может быть SmartCard).

Склад ключей по умолчанию, который Sun поставляется с JDK, создает программный токен (на диске) с тремя вариантами шифрования :

1. по умолчанию: "jks", собственный тип хранилища ключей (формат). Не уверен насчет алгоритма.

2. "jceks", альтернативный проприетарный формат, использующий 3-DES

3. "pkcs12", стандартный формат (OpenSSL может его читать), с несколькими параметрами, но обычно 3-DES для закрытых ключей и RC2-40 для сертификатов.

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