Идентификаторы ключей

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

Как в этом случае получателю узнать, какой из открытых ключей использовался для шифрования сеансового ключа? Простейшим решением является передача открытого ключа вместе с сообщением. Получатель мог бы тогда удостовериться, что это действительно один из открытых ключей, а затем продолжить обработку сообщения. Эта схема должна работать, но при этом пересылается слишком много лишних данных. Открытый ключ RSA может иметь длину в сотни десятичных разрядов. Другим решением является связывание с каждым открытым ключом некоторого идентификатора, уникального по крайней мере для одного пользователя. Для этой цели вполне подойдет, например, комбинация идентификатора пользователя и идентификатора ключа. Тогда придется пересылать только значительно более короткий идентификатор ключа. Такое решение, однако, порождает проблему управления и перегрузки: идентификаторы ключей должны приписываться и храниться так, чтобы как отправитель, так и получатель могли установить соответствие между идентификаторами ключей и самими открытыми ключами. Это кажется нежелательным и несколько обременительным.

Решением, принятым в PGP, является присвоение каждому открытому ключу такого идентификатора, который с очень высокой вероятностью должен оказаться уникальным для данного пользователя. Идентификатор, связываемый с каждым открытым ключом, размещается в младших 64 разрядах ключа. Это значит, что идентификатор открытого ключа KU_a равен (KU. mod 2^й4). Этой длины достаточно для того, чтобы вероятность дублирования идентификаторов ключей оказалась очень мала.

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

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

Компонент сообщения включает фактические данные, предназначенные для хранения или передачи, а также имя файла и метку даты-времени, указывающую время создания сообщения.

Компонент подписи включает следующие компоненты.

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

■ Профиль сообщения. 160-битовый профиль сообщения,созданный спомощью SHA-1 и шифрованный с использованием личного ключа подписи отправителя. Профиль вычисляется для метки даты-времени подписи, связанной конкатенацией с порцией данных компонента сообщения. Включение метки даты-времени подписи в профиль обеспечивает защиту от атак

Рисунок 10.3 - Общий формат сообщения PGP (от А к В)

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

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

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

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

Компонент сеансового ключа включает сеансовый ключ иидентификатор открытого ключа получателя, который использовался отправителем для шифрования данного сеансового ключа.

Весь блок обычно переводится в формат radix-64.