Связки ключей

Мы видели, что идентификаторы ключей в PGP очень важны и что два идентификатора ключей включаются в любое сообщение PGP, предполагающее конфиденциальность и аутентификацию. Эти ключи необходимо хранить и организовать некоторым стандартизованным образом для эффективного применения всеми участвующими в обмене данными сторонами. Схема, используемая в PGP, предполагает создание в каждом узле пары структур данных: одну для хранения пар открытых/секретных ключей данного узла, а другую — для хранения открытых ключей других пользователей, известных данному узлу. Эти структуры данных называются соответственно связкой личных ключей и связкой открытых ключей.

Общая структура связки личных ключей показана на рис. 4. Связку можно считать таблицей, в которой каждая строка представляет одну пару открытого/личного ключей, принадлежащих данному пользователю. Каждая строка содержит следующие поля.

■ Метка даты-времени. Дата и время создания данной пары ключей.

■ Идентификатор ключа. Младшие64разряда открытого ключа данной строки.

■ Открытый ключ. Открытый ключ данной пары.

■ Личный ключ. Личный ключ данной пары;это поле шифруется.

■ Идентификатор пользователя. Обычно здесь размещается адресэлектронной почты пользователя (например, [email protected]). Однако пользователь может указать для каждой пары ключей разные имена (например, Stallings, WStaliings, WilliamStallings и т.п.) или использовать один идентификатор пользователя несколько раз.

Рисунок 10.4 - Общая структура связок личных и открытых ключей

Связка личных ключей может быть индексирована либо по полю Идентификатор пользователя, либо по полю Идентификатор ключа; цель такой индексации мы выясним позже.

Хотя предполагается, что связка личных ключей должна храниться только на машине пользователя, создавшего и владеющего соответствующими парами ключей и что она должна быть доступна только этому пользователю, имеет смысл сделать значения личных ключей защищенными настолько, насколько это возможно. Соответственно, сам личный ключ в открытом виде в связке ключей не хранится, а шифруется с помощью CAST-128 (или IDEA, или 3DES). При этом используется следующая процедура.

1. Пользователь выбирает фразу-пароль, которая будет служить для шифрования личных ключей.

2. Когда система с помощью RSA генерирует новую пару открытого/личного ключей, она требует от пользователя указать такую фразу-пароль. Из нее с помощью SHA-1 генерируется 160-битовый хэш-код, а затем пароль удаляется.

3. Система шифрует личный ключ с помощью CAST-128, используя 128 битов хэш-кода в качестве ключа. Хэш-код затем удаляется, а шифрованный личный ключ сохраняется в связке личных ключей.

Впоследствии, когда пользователь обращается к связке личных ключей, чтобы извлечь личный ключ, ему придется снова указать фразу-пароль. PGP извлечет шифрованный личный ключ, вычислит хэш-код пароля и дешифрует личный ключ с помощью CAST-128 с данным хэш-кодом.

Это очень компактная и эффективная схема. Как и в любой основанной на паролях системе, защищенность всей системы зависит от защищенности пароля. Чтобы не поддаться искушению записать пароль, пользователь должен использовать такую парольную фразу, которую угадать нелегко, а запомнить — просто.

На рис. 4.4 показана и общая структура связки открытых ключей. Эта структура данных позволяет хранить открытые ключи других пользователей, известных данному. Пока что давайте проигнорируем некоторые поля, указан-ные в таблице, и опишем только часть из них.

■ Метка даты-времени.Дата и время создания данной записи.

■ Идентификатор ключа. Младшие64разряда открытого ключа даннойзаписи.

■ Открытый ключ. Открытый ключ данной записи.

■ Идентификатор пользователя. Владелец данного ключа.С однимоткрытым ключом можно связать несколько идентификаторов пользователя.

Связка открытых ключей может быть индексирована либо по полю Идентификатор пользователя, либо по полю Идентификатор ключа; цель такой индексации мы выясним позже.

Теперь мы можем показать, как эти связки ключей применяются при передаче и приеме сообщений. Для простоты в следующем примере мы проигнорируем сжатие и преобразование в формат radix-64. Сначала рассмотрим передачу сообщения (рис. 10.5) и предположим, что сообщение должно быть и подписано, и зашифровано. Посылающий сообщение объект PGP выполняет следующие шаги.

Рисунок 10.5 - Создание сообщения PGP (от А к Б, без сжатия и преобразования в формат radix-64)

1. Создание подписи сообщения.

• PGP извлекает личный ключ отправителя из связки личных ключей, используя введенное значение your_userid в качестве ключа поиска. Если соответствующая команда не предлагает значения your_userid, выбирается первый личный ключ в связке.

• PGP запрашивает у пользователя фразу-пароль, чтобы расшифровать личный ключ.

• Создается компонент подписи сообщения.

2. Шифрование сообщения.

• PGP генерирует сеансовый ключ и шифрует сообщение.

• PGP извлекает открытый ключ получателя из связки открытых ключей, используя значение her_userid в качестве ключа поиска.

• Создается компонент сеансового ключа сообщения.

Принимающий объект PGP выполняет следующие шаги (рис. 10.6).

1. Дешифрование сообщения.

• PGP извлекает личный ключ получателя из связки личных ключей, используя в качестве ключа поиска значение поля Идентификатор ключа компонента сеансового ключа сообщения.

• PGP запрашивает у пользователя фразу-пароль, чтобы расшифровать личный ключ.

• PGP открывает сеансовый ключ и дешифрует сообщение.

Рисунок 10.6 - Получение сообщения PGP (от А к В, без сжатия и преобразования в формат radix-64)

2. Аутентификация сообщения.

• PGP извлекает открытый ключ отправителя из связки открытых ключей, используя в качестве ключа поиска значение поля Идентификатор ключа компонента подписи сообщения.

• PGP восстанавливает полученный профиль сообщения.

• PGP вычисляет профиль сообщения для принятого сообщения и сравнивает его с профилем, пришедшим вместе с сообщением, чтобы убедиться в их идентичности.