15 страница

Рисунок 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 вычисляет профиль сообщения для принятого сообщения и сравнивает его с профилем, пришедшим вместе с сообщением, чтобы убедиться в их идентичности.

Управление открытыми ключами

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

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

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

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

Подходы к вопросу управления открытыми ключами

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

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

Вот несколько вариантов процедуры, которую при этом можно было бы использовать.

1. Получение ключа от В лично (физически). Пользователь В может сохранить свой открытый ключ (KU_b) на дискете и вручить эту дискету пользователю А. Пользователь А затем может загрузить такой ключ с дискеты в свою систему. Это действительно безопасный путь, но он имеет свои очевидные ограничения.

2. Проверка ключа по телефону. Если А может распознать В по телефону, то А может позвонить В и попросить продиктовать ключ в формате radix-64. Еще более удобный вариант выглядит так: В может передать свой ключ пользователю А в виде электронного сообщения. Пользователь А может с помощью PGP и с использованием SHA-1 сгенерировать 160-битовый про филь ключа и представить его в шестнадцатеричном формате; такой про филь называется "отпечатком" ключа. После этого А может позвонить В и попросить продиктовать строку, соответствующую отпечатку его ключа. Если два отпечатка совпадут, ключ считается проверенным.

3. Получение открытого ключа В от внушающего доверие обеим сторонам надежного посредника D. Для этого поставщик D создает подписанный сертификат. Такой сертификат должен включать открытый ключ В, время создания ключа и срок его действия. Сторона D генерирует профиль SHA-1 этого сертификата, шифрует его с помощью своего личного ключа и присоединяет полученную подпись к сертификату. Ввиду того что создать такую подпись в состоянии только D, никто другой не сможет фальсифицировать открытый ключ и заявить» что этот ключ был подписан стороной D. Подписанный сертификат может быть доставлен непосредственно стороне А стороной В или D либо выставлен на электронной доске объявлений.

4. Получение открытого ключа В от надежного уполномоченного узла сертификации. Опять же, сертификат открытого ключа создается и подписывается уполномоченным узлом. Пользователь А может затем получить доступ к такому узлу, указав свое имя пользователя, и получить подписанный сертификат.

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

Использование степеней доверия

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

Базовая схема выглядит следующим образом. Любой элемент в связке открытых ключей является сертификатом открытого ключа. С каждым таким элементом связывается поле соответствия ключа, которое задает степень доверия, с которой PGP будет считать, что истинным владельцем данного открытого ключа является указанный пользователь: чем выше степень доверия, тем сильнее привязка идентификатора пользователя к данному ключу. Это поле вычисляется PGP. С каждым элементом связывается также некоторое (возможно, нулевое) число подписей для данного сертификата, которые были собраны владельцем связки ключей. В свою очередь, с каждой подписью связывается поле доверия подписи, определяющее степень, в которой PGP доверяет данному объекту подписывать сертификаты открытых ключей. Значение поля соответствия ключа выводится из совокупности значений полей доверия подписи для данного элемента связки ключей. Наконец, каждый элемент определяет открытый ключ, связываемый с конкретным владельцем, а соответствующее поле доверия владельцу указывает степень доверия, с которой этот открытый ключ может использоваться для подписи других сертификатов открытых ключей; эта степень доверия определяется и присваивается пользователем. Значения полей доверия подписи можно рассматривать как кэшированные копии значений полей доверия владельцу других элементов связки ключей.

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

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

Таблица 10.2

Содержимое байта флага доверия

этого открытого ключа. Если владельцем является А, и поэтому этот открытый ключ должен появиться также и в связке личных ключей, то полю доверия владельцу автоматически присваивается значение наивысшее доверие (ultimate trust). Иначе PGP спрашивает пользователя А о том, какой уровень доверия следует приписать владельцу этого ключа и А должен ввести подходящее значение. Пользователь может указать, что этот владелец неизвестен, ненадежен, минимально надежен или вполне надежен.

2. Когда добавляется новый открытый ключ, к нему можно добавить одну или несколько подписей. Позже можно включить и другие подписи. Когда добавляется подпись, PGP выполняет поиск в связке открытых ключей, чтобы выяснить, значится ли имя автора этой подписи среди известных владельцев открытых ключей. Если да, то значение поля OWNERTRUST этого владельца присваивается полю SIGTRUST данной подписи. В противном случае соответствующему полю присваивается значение неизвестный пользователь.

3. Значение поля соответствия ключа вычисляется на базе значений полей доверия подписей данного элемента связки. Если по крайней мере одна подпись имеет значение наивысшее (ultimate) в поле доверия подписи, то в поле соответствия ключа устанавливается значение полное (complete). Иначе PGP вычисляет взвешенную сумму значений полей доверия. Для подписей с максимальным уровнем доверия назначается вес 1/Х, а подписям со средним уровнем доверия назначается вес 1/Y, где X и Y являются параметрами, задаваемыми пользователем. Если общая сумма весов поставщиков комбинаций "ключ/идентификатор пользователя" достигает 1, то считается, что соответствие надежно и для поля соответствия ключа устанавливается значение полное (complete). Таким образом, при отсутствии наивысшего доверия для полного соответствия потребуется по крайней мере X подписей с максимальным уровнем доверия, или Y подписей со средним уровнем доверия, или некоторая подходящая их комбинация.

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

На рис. 7 показана примерная схема связывания доверия подписи и соответствия ключа. На рисунке отображена структура связки открытых ключей. В данном случае пользователь получил несколько открытых ключей, какие-то непосредственно от их владельцев, а какие-то от третьей стороны, например с сервера ключей.

Вершина, обозначенная на рисунке "Вы", представляет элемент связки открытых ключей, соответствующий данному пользователю. Этот ключ, очевидно, соответствует владельцу, поэтому значением поля OWNERTRUST является наивысшее доверие. Для любой другой вершины поле OWNERTRUST в связке ключей имеет значение неопределенное доверие, если только пользователем не задано некоторое другое значение. В данном примере пользователь указал, что он всегда доверяет подписывать другие ключи пользователям D, E, F и L. Частичное доверие подписывать другие ключи получили пользователи А и В.

Таким образом, закраска или отсутствие таковой для вершин на рис. 10.7 указывает уровень доверия, определенного для этих пользователей. Древовидная структура говорит о том, какими пользователями были подписаны соответствующие ключи. Если ключ был подписан пользователем, чей ключ также присутствует в данной связке ключей, от подписанного ключа к подписавшему данный ключ пользователю идет стрелка. Если ключ подписан пользователем, ключа которого в данной связке ключей нет, стрелка идет от подписанного ключа к знаку вопроса, означающему, что подписавшая ключ сторона данному пользователю неизвестна.

© — ключ, считающийся вами соответствующим владельцу Рисунок 10.7 - Пример модели доверия PGP

На рис. 10.7 проиллюстрированы следующие моменты.

1. Обратите внимание на то, что все ключи, владельцам которых полностью или частично доверяет данный пользователь, были подписаны этим пользователем, за исключением вершины L. Такая подпись пользователя не всегда необходима, как здесь это имеет место для вершины L, но на практике большинство пользователей, скорее всего, подпишут ключи большинства владельцев, которым они доверяют. Поэтому, например, даже если ключ Е уже был подписан надежным поставщиком F, пользователь решил подписать ключ Е лично.

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

3. Ключ может быть определен как надежный, если он подписан одной вполне надежной или двумя частично надежными сторонами, но может оказаться, что пользователю этого ключа не доверяется подписывать другие ключи. Например, ключ N является надежным, поскольку он подписан стороной Е, которой данный пользователь доверяет, но подписывать другие ключи стороне N не доверяется, поскольку данный пользователь не присвоил N соответствующее значение уровня доверия. Поэтому, хотя ключ R и подписан стороной N, система PGP не считает ключ R надежным. Такая ситуация имеет совершенно определенный смысл. Если вы хотите послать секретное сообщение некоторому адресату, совсем не обязательно, чтобы вы доверяли этому адресату хоть в какой-то степени. Необходимо только, чтобы вы были уверены в том, что имеете надежный открытый ключ соответствующего пользователя.

4. На рис. 7 показан также пример отдельной "вершины-сироты" S, с двумя неизвестными подписями. Такой ключ мог быть получен с сервера ключей. PGP не может считать этот ключ надежным только потому, что этот ключ пришел с имеющего хорошую репутацию сервера. Пользователь должен объявить этот ключ надежным, подписав его лично или сообщив PGP о том, что он готов полностью доверять одной из сторон, уже подписавших данный ключ.

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

Отзыв открытых ключей

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

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

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

Сжатие данных с помощью ZIP

В PGP используется пакет сжатия данных, называемый ZIP, авторами которого являются Жан-луп Галли (Jean-loup Gailly), Марк Адлер (Mark Adler) и Ричард Уэлз (Richard Wales). ZIP является свободно распространяемым пакетом, написанным на языке С, выполняемым как утилита на UNIX и в некоторых других системах. ZIP функционально равноценен PKZIP, широко доступному условно бесплатному пакету для систем под управлением Windows, разработанному PKWARE, Inc. Алгоритм ZIP обеспечивает, возможно, наиболее часто используемую технику сжатия данных, позволяя межплатформенный обмен данными: бесплатные и условно бесплатные версии ZIP доступны для Macintosh и других систем так же, как для Windows и UNIX.

Алгоритм ZIP и ему подобные появились в результате исследований Джейкоба Зива (Jacob Ziv) и Абрахама Лемпела (Abraham Lempel). В 1977 году они описали технологию, основанную на использовании буфера скользящего окна, содержащего текст, обработка которого выполнялась последней. Этот алгоритм обычно называют LZ77. Версия именно такого алгоритма используется в схеме сжатия ZIP (PKZIP, gzip, zipit и т.д.).

Алгоритм LZ77 и его варианты основаны на том факте, что слова и фразы внутри потока текста (или структуры изображения в случае GIF), вероятнее всего, повторяются. Когда это имеет место, повторная последовательность может быть заменена коротким кодом. Программа сжатия находит такие повторения и строит коды прямо по ходу выполнения, чтобы заменить повторную последовательность. В дальнейшем коды применяются повторно, чтобы обработать новые последовательности. Алгоритм должен быть определен таким образом, чтобы программа декомпрессии данных могла построить правильное отображение кодов в последовательности исходных данных.

Перед тем как приступить к детальному описанию LZ77, рассмотрим простой пример. Возьмем бессмысленную фразу

the brown fox jumped over the brown foxy jumping frog,

длина которой равна 53 октетам (байтам), или 424 битам. Алгоритм обрабатывает этот текст слева направо. Сначала каждый символ отображается в 9-битовый двоичный код, складывающийся из двоичной единицы, далее следует 8-битовый ASCII-код символа. В ходе дальнейшего выполнения алгоритм ищет повторяющиеся последовательности. Когда встречается повторение, алгоритм продолжает сканирование до конца повторяющейся последовательности. Другими словами, каждый раз, когда встречается повторение, алгоритм включает в повторяющуюся последовательность столько символов, сколько максимально возможно. Здесь первой найденной последовательностью является the brown fox. Эта последовательность заменяется указателем на предыдущую последовательность и данными о длине последовательности. В данном случае встретившаяся выше последовательность the brown fox находится на 26 символов раньше и длина этой последовательности равна 13 символам. Для данного примера выберем два варианта кодирования: 8-битовый указатель и 4-битовое значение длины или 12-битовый указатель и 6-битовое значение длины; 2-битовый заголовок указывает, какой вариант был выбран: значение 00 обозначает первый вариант, а 01 — второй. Таким образом, второе вхождение последовательности the brown fox кодируется в виде <00_bx26_d><13_d>, или 00 00011010 1101.

Оставшаяся часть сжатого сообщения складывается из буквы у, последовательности <00_b><27_d><5_d>, которая заменяет последовательность из символа пробела и следующих за ним символов jump, а также последовательности символов ing frog.

Соответствующее отображение сжатия представлено на рис. 10.8. Сжатое сообщение состоит из 35 9-битовых символов и двух кодов, в сумме это 35x9 + 2 х 14 = 343 бита. В сравнении с 424 битами несжатого сообщения это дает коэффициент сжатия, равный 1,24.

Алгоритм сжатия

Алгоритм сжатия для схемы LZ77 и его варианты используют два буфера. Скользящий буфер предыстории содержит N символов источника, обработанных последними, а буфер упреждающей выборки содержит следующие L символов,

^L 27-

the brown fox jumped over o_b26_di3_d у o_b27_ds_ding

Рисунок 10.8 - Пример использования схемы LZ77

которые должны обрабатываться следующими (рис. 10.9(а)). Алгоритм пытается найти два или большее число символов из буфера упреждающей выборки в строке из скользящего буфера предыстории. Если совпадений не найдено, первый символ из буфера упреждающей выборки выводится как 9-битовый символ, сам этот символ перемещается в скользящее окно, а самый старый символ из этого окна выталкивается. Если совпадение обнаружено, алгоритм продолжает просматривать символы в поиске совпадающей последовательности наибольшей длины. Затем совпадающая строка выводится в виде трех значений (индикатор, указатель, длина). Для строки из К символов самые старые К символов из скользящего окна выталкиваются, а К символов кодированной строки сдвигаются в это окно.

На рис. 10.9(6) показано действие этой схемы на последовательности из нашего примера. На иллюстрации изображено 39-символьное скользящее окно и 13-символьный буфер упреждающей выборки. В верхней части иллюстрации уже обработано 40 первых символов и последние 39 из них в несжатом виде находятся в скользящем окне. Остальная часть данных источника находится в буфере упреждающей выборки. Алгоритм сжатия определяет следующее повторение символов, перемещает пять символов из буфера упреждающей выборки в скользящее окно и выводит код соответствующей строки. Состояние буфера после этих действий показано в нижней части иллюстрации.

Схема LZ77 является эффективной и адаптирующейся к природе вводимых данных, и, тем не менее, она имеет определенные недостатки. Алгоритм использует ограниченное окно для поиска совпадений в предыдущем тексте. Для очень длинных блоков текста в сравнении с размерами окна много потенциальных совпадений будет проигнорировано. Размер окна может быть увеличен, но за это придется платить следующим: (1) увеличением времени выполнения алгоритма ввиду того, что необходимо выполнять сравнения строк из буфера упреждающей выборки с каждой позицией в скользящем окне и (2) увеличением длины поля <указатель> ввиду необходимости указывать более длинные переходы.