14 страница

ЕС — шифрование в схеме традиционного шифрования,

DC — дешифрование в схеме традиционного шифрования,

Н — функция хэширования,

|| — конкатенация,

Z — сжатие с помощью алгоритма ZIP,

R64 — преобразование в формат radix-64 ASCII.

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

Описание работы системы

Сервис PGP, если не рассматривать управление ключами, складывается из пяти функций: аутентификации, конфиденциальности, сжатия,

совместимости на уровне электронной почты и сегментации (табл. 10.1). Мы рассмотрим каждую из них по очереди.

Аутентификация

На рис. 10.1 (а) показана схема сервиса цифровой подписи,

предлагаемая PGP. Эта схема соответствует схеме цифровой подписи. При этом выполняется следующая последовательность действий.

1. Отправитель создает сообщение.

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

Таблица 10.1

Краткая характеристика функций PGP

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

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

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

Комбинация SHA-1 и RSA обеспечивает эффективную схему цифровой подписи. Ввиду надежности RSA получатель уверен в том, что только владелец соответствующего секретного ключа мог создать эту подпись. Надежность SHA-1 дает получателю уверенность в том, что никто другой не мог создать другое сообщение с соответствующим хэш-кодом и, следовательно, с подписью из оригинального сообщения.

Подписи могут также генерироваться с помощью DSS/SHA-1.

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

Рисунок 10.1 - Криптографические функции PGP

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

Конфиденциальность

Другим основным сервисом, предлагаемым PGP, является

конфиденциальность, обеспечиваемая шифрованием сообщений,

предназначенных для передачи или хранения в виде файлов. В обоих случаях можно использовать традиционное шифрование с помощью алгоритма CAST- 128. Альтернативой является применение алгоритмов IDEA или 3DES. Может использоваться и режим обратной связи шифрованных 64-битовых блоков (режим CFB).

Как всегда, необходимо решать проблему распределения ключей. В PGP каждый ключ схемы традиционного шифрования применяется только один раз. Это значит, что для каждого сообщения генерируется новый ключ в виде случайного 128-битового числа. Таким образом, хотя в документации такой ключ называется сеансовым, на самом деле он является одноразовым. Ввиду того, что ключ задействуется только один раз, такой сеансовый ключ присоединяется к сообщению и передается вместе с сообщением. Чтобы защитить ключ, он шифруется с использованием открытого ключа получателя. На рис. 10.1 (б) показана соответствующая схема, которая может быть описана следующим образом.

1. Отправитель генерирует сообщение и случайное 128-битовое число, которое выступает в качестве сеансового ключа только для этого сообщения.

2. Сообщение шифруется с помощью алгоритма CAST-128 (или IDEA, или 3DES) и данного сеансового ключа.

3. Сеансовый ключ шифруется с помощью алгоритма RSA и открытого ключа получателя и присоединяется к началу сообщения.

4. Получатель использует RSA с личным ключом, чтобы дешифровать и тем самым восстановить сеансовый ключ.

5. Сеансовый ключ применяется для дешифрования сообщения.

Чтобы обеспечить альтернативу использованию RSA для шифрования ключа, в PGP предлагается параметр Diffie-Hellman (алгоритм Диффи- Хеллмана). Как уже отмечалось в главе 6, алгоритм Диффи-Хеллмана является алгоритмом обмена ключами. На самом деле в PGP используется вариант этого алгоритма с возможностями шифрования/дешифрования, известный как алгоритм Эль-Гамаля (ElGamal).

В связи с этим можно сделать несколько замечаний. Во-первых, чтобы уменьшить время шифрования, преимущество отдается использованию комбинации традиционного шифрования и шифрования с открытым ключом, а не простому использованию RSA или алгоритма Эль-Г амаля, когда сообщение шифруется непосредственно: CAST-128 и другие алгоритмы традиционной схемы шифрования значительно быстрее, чем RSA или алгоритм Эль-Гамаля. Во-вторых, использование алгоритмов схемы шифрования с открытым ключом решает проблему распределения сеансовых ключей, так как только для получателя оказывается возможным восстановить сеансовый ключ, присоединенный к сообщению. Обратите внимание на то, что в таком случае не требуется использовать протокол обмена сеансовыми ключами типа описанного в главе 6, поскольку здесь не требуется начинать сеанс обмена данными. В этой ситуации, скорее, каждое сообщение является одиночным независимым событием со своим собственным ключом. К тому же вследствие самой природы электронной почты, являющейся системой с промежуточным хранением данных, использование процедуры подтверждения связи для того, чтобы убедиться в идентичности сеансового ключа обеих сторон, не является практически удобным решением. Наконец, использование одноразовых ключей в традиционной схеме шифрования еще более усиливает и без того достаточно надежный алгоритм традиционного шифрования. Только небольшой объем открытого текста шифруется с использованием одного ключа, и между ключами нет никакой связи. Таким образом, вся схема оказывается защищенной в той мере, в какой защищен алгоритм схемы шифрования с открытым ключом. Поэтому PGP предлагает пользователю выбор для длины ключа от 768 до 3072 битов (длина ключа DSS для подписей ограничивается величиной в 1024 бита).

Как показано на рис. 4.1(в), для одного сообщения можно использовать обе службы. Сначала для сообщения в виде открытого текста генерируется подпись, которая добавляется в начало сообщения. Затем открытый текст сообщения и подпись шифруются с помощью алгоритма CAST-128 (или IDEA, или 3DES), а сеансовый ключ шифруется с помощью RSA (или алгоритма Эль-Гамаля). Такая схема предпочтительнее обратной, т.е. схеме, когда сначала шифруется сообщение, а затем генерируется подпись для шифрованного сообщения. В общем случае оказывается более удобным хранить подпись с открытым текстом сообщения. К тому же с точки зрения возможностей трехсторонней верификации, если сначала генерируется подпись, третьей стороне не нужно заботиться о ключе традиционного шифрования, чтобы проверить подпись.

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

Сжатие

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

Очень важным оказывается выбор места применения алгоритма сжатия, обозначенного на рис. 1 как Z при сжатии и как Z'¹ при распаковке данных.

1. Подпись генерируется до сжатия по следующим причинам.

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

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

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

В качестве алгоритма сжатия применяется ZIP.

Совместимость на уровне электронной почты

При использовании PGP шифруется по крайней мере часть передаваемого блока. Если требуется только цифровая подпись, то шифруется профиль сообщения (с использованием личного ключа отправителя). Если имеет место сервис конфиденциальности, шифруется (с использованием одноразового симметричного ключа) сообщение плюс подпись (при наличии последней). Таким образом, часть или весь выходной блок сообщения представляет собой поток произвольных 8-битовых байтов. Однако многие системы электронной почты позволяют использовать только блоки, состоящие из символов текста ASCII. Чтобы удовлетворить такому ограничению, PGP обеспечивает сервис конвертирования сырого 8-битового двоичного потока в поток печатаемых символов ASCII.

Для этого используется схема конвертирования radix-64. Каждая группа из трех байтов двоичных данных преобразуется в четыре символа ASCII, к которым присоединяется контрольная сумма (CRC), позволяющая обнаружить ошибки при передаче данных.

Конвертирование в формат radix-64 увеличивает длину передаваемого сообщения на 33%. К счастью, сеансовый ключ и порция подписи сообщения относительно компактны, а открытый текст сообщения сжимается. Фактически сжатие с избытком компенсирует расширение, получаемое вследствие перевода в формат radix-64. Например, сообщается о среднем коэффициенте сжатия для ZIP около 2,0. Если игнорировать относительно небольшую подпись и компоненты ключа, типичное полное влияние сжатия и расширение для файла длины X должно быть приблизительно равно 1,33 х 0,5 х X = 0,665 х X. Таким образом, имеет место общее сжатие примерно на одну треть.

Заслуживающим упоминания аспектом алгоритма radix-64 является то, что он слепо конвертирует входной поток в формат radix-64, невзирая на содержимое, даже если ввод оказывается текстом ASCII. Таким образом, если сообщение подписано, но не шифруется и конвертирование применяется ко всему блоку, то выходной поток данных будет непонятен случайному наблюдателю, что уже обеспечивает определенный уровень

конфиденциальности. PGP можно сконфигурировать так, чтобы

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

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

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

(а) Общая схема отправки (на стороне А) (б) Общая схема получения (на стороне В)

Рисунок 10.2 - Отправка и прием сообщений PGP Сегментация и обратная сборка сообщения

Средства электронной почты часто ограничивают максимально допустимую длину сообщения. Например, многие средства электронной почты, доступные через Internet, допускают пересылку сообщений длиной не более 50000 байтов. Любое более длинное сообщение должно быть разбито на сегменты меньшей длины, каждый из которых посылается отдельно.

Чтобы соответствовать такому ограничению, PGP автоматически разбивает слишком длинные сообщения на сегменты, достаточно малые для того, чтобы их можно было переслать с помощью электронной почты. Сегментация проводится после выполнения всех других операций, включая преобразование в формат radix-64. В результате компоненты ключа и подписи появляются только один раз, в начале первого сегмента. На стороне получателя система PGP должна отбросить заголовок электронной почты и вновь собрать весь оригинальный блок сообщения перед выполнением шагов, показанных на рис. 10.2(6).

Криптографические ключи и связки ключей

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

1. Наличие средств генерирования непредсказуемых сеансовых ключей.

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

2. Каждый объект системы PGP должен поддерживать файл собственных пар открытых/личных ключей, а также открытых ключей корреспондентов.

Рассмотрим эти требования по порядку.

Генерирование сеансовых ключей

Каждый сеансовый ключ связывается с одним сообщением и используется только для шифрования и дешифрования этого сообщения. Вспомните, что шифрование/дешифрование сообщения выполняется с помощью алгоритма симметричной схемы шифрования. При этом алгоритмы CAST-128 и IDEA используют 128-битовые ключи, a 3DES — 168-битовый ключ. В дальнейшем обсуждении мы предполагаем использование CAST-128.

Случайные 128-битовые числа генерируются с помощью самого алгоритма CAST-128. Ввод для генератора случайных чисел складывается из 128-битового ключа и двух 64-битовых блоков, которые рассматриваются как открытый текст, подлежащий шифрованию. Используя режим шифрованной обратной связи, шифровальщик CAST-128 порождает два 64-битовых блока шифрованного текста, которые связываются конкатенацией, в результате чего формируется 128битовый сеансовый ключ. Алгоритм, который при этом используется, основан на алгоритме, описанном в документе ANSI XI2.17.

"Открытый текст" для генератора случайных чисел, формируемый из двух 64-битовых блоков, извлекается из рандомизованного потока 128-битовых чисел. Эти числа строятся на основе ввода с клавиатуры от пользователя. Для создания рандомизованного потока используются как время между нажатиями, так и информация о фактически нажатых клавишах. Таким образом, если пользователь нажимает случайные клавиши в своем обычном темпе, будет порожден достаточно "случайный" поток для ввода. Этот случайный ввод объединяется с предыдущим сеансовым ключом, выданным алгоритмом CAST-128, чтобы сформировать данные для ввода генератору. В результате, ввиду хороших перемешивающих свойств CAST-128, порождается последовательность сеансовых ключей, которая оказывается практически непредсказуемой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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