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

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

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

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

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

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

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

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

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

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