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

Об электронной подписи написано довольно много, как в государственных источниках, так и в документации к соответствующим программным продуктам. Здесь мы постараемся очень кратко объяснить, для чего нужен этот механизм и как он устроен, а также рассмотрим способ его применения на примере свободного почтового клиента Thunderbird с расширением Enigmail, использующим утилиту gpg (GNU Privacy Guard).

Сущность электронной подписи

Постановка задачи

Передача информации на расстояние с давних пор в списке важнейших числит проблему аутентификации, то есть установление подлинности авторства. Чем важнее сообщение, тем болезненнее различие между ситуацией, когда получатель интерпретирует "настоящие", исходные данные и ситуацией, когда ему попадают данные "подложные", искажённые. Классический пример атаки на содержимое сообщения приведён в первой части произведения А. С. Пушкина "Сказка о Царе Салтане". В ней злоумышленники (Ткачиха, Повариха и Сватья), опираясь на то, что отправитель (царь Салтан) не обеспечивает в своих сообщениях возможность установить их подлинность, смогли воспользоваться ненадёжностью среды передачи данных (напоили гонца) и несанкционированно подменили сообщение.

Современная среда передачи данных -- сеть Интернет -- ненадёжна по определению. Путь сообщения, например, электронного письма, включает себя до нескольких десятков узлов, передающих друг другу это сообщение или его части. Если к такому узлу получит доступ, допустим, Повариха, кто помешает ей в важном документе поменять пару строк, допустим, "Ждать царёва возвращенья // Для законного решенья" -- вычеркнуть, а "И царицу и приплод // Тайно бросить в бездну вод" -- вписать? Более того, попытки провести дополнительную аутентификацию посредством той же ненадёжной среды передачи данных также обречены на провал. Вспомним, что даже подлинное письмо царя уже было реакцией на подложное письмо (про "неведому зверушку").

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

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

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

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

Асимметричное шифрование и электронная подпись

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

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

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

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

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

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

Сим удостоверяется

В случае бумажного документооборота самым быстрым способом подтвердить аутентичность документа служит собственноручная подпись и печать. Подпись уникальна для каждого человека, а печать служит знаком того, что подписывался именно этот человек. Если используется одна только подпись, процедура усложняется: необходимо иметь заранее запасённый образец этой подписи и сличить его с таковой на документе. Скажем, причудливая закорючка и надпись "к. Гвидон" слева удостоверяется штампом "Е.И.В. Салтанова Канцелярия" справа. В этом случае царь-отец может быть уверен, что бумага именно от Гвидона.

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

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

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

Примечательно, что подписывать чужие ключи (разумеется, только проверенные), полезно. Допустим, некий новый открытый ключ подписан людьми, чьи подписи неизвестны. Однако их ключи, в свою очередь, также кем-то подписаны, и вполне возможно, что среди этого "второго окружения" есть проверенные люди. Следовательно, этот новый ключ получит "индекс доверия 2", что неизмеримо надёжнее, чем ничего. Таким образом формируется т. н. сеть доверия -- множество ключей, которым можно доверять "через вторые" или "через третьи руки".

Использование электронной подписи GPG в почтовом клиенте Thunderbird

Для того, чтобы почтовый клиент Thunderbird научился подписывать сообщения, его функции надо расширить, установив т. н. расширение Enigmail и собственно утилиту для работы с асимметричными ключами -- gpg (The GNU Privacy Guard). Расширение -- это дополнительный модуль к Thunderbird, а утилита gpg -- отдельный программный продукт.

Следует обратить внимание на то, что текст, содержащийся на слайдах, имеет первостепенное значение. Между слайдами приведены необходимые комментарии.

Первоначальная настройка Enigmail

Первым делом необходимо включить поддержку GPG, которая появляется в меню "Учётные записи" после установки Enigmail:

GPGon.png

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

GPGmaster0.png


GPGmaster1.png


GPGmaster2.png

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


GPGmaster3.png

Требование не использовать HTML не такое уж страшное. Электронная почта предназначена для обмена текстовыми сообщениями. Сетевой этикет в строгом варианте требует использования именно формата Plain Text, лишённого всякой разметки, кроме видимой (абзацы, цитирование с помощью "", подпись и т. п.). Далеко не все почтовые клиенты отображают HTML, а само это отображение не всегда одинаково. Отсутствие какого-нибудь шрифта или неаккуратная HTML-разметка могут сделать письмо нечитаемым для получателя. Наконец, очень много нежелательной почты (т. н. "спама") пересылается именно формате HTML, причём с злоупотреблением размером и цветом шрифтов, картинками и другими, менее безобидными, трюками.


GPGmaster4.png

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

GPGmaster4-oops.png

Из сказанного ранее следует, что пароль, защищающий ключ, должен быть достаточно надёжным.


GPGmaster5.png


GPGmaster6.png


GPGmaster7.png

Утечка (компрометация) закрытого ключа -- ситуация опасная, и сам ключ после этого использовать нельзя. В !OpenPGP предусмотрен способ такого оповещение: публикация т. н. "отзывающего сертификата". Прочтя такой сертификат, gpg-клиент начнёт считать соответствующий ключ недействительным.


GPGmaster9.png

Переписав отзывающий сертификат в "надёжное место", не забудьте его удалить из "ненадёжного места"!


GPGmaster9f.png

Подписанная электронная почта

Всякое обращение к GPG начинается с просьбы ввести пароль, защищающий закрытый ключ:

GPGinit.png


Окно, в котором редактируется письмо, теперь декорировано зелёным карандашиком (справа внизу)

GPGletter.png

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


Почта от корреспондента, открытый ключ которого вам неизвестен, выглядит так:

GPGletterUnkn.png

Обратите внимание на то, что сообщение показано в исходном виде, со служебными строчками о подписи и самой подписью (она начинается со строки -----BEGIN PGP SIGNATURE-----)


Если сделать то, что советует Enigmail ("щёлкнуть по ручке"), GPG попытается получить открытые ключ с какого-нибудь публичного сервера:

GPGletterUnkn1.png


GPGletterUnkn2.png


В данном случае адресат свой ключ разместил на сервере, но забыл попросить товарищей подписать его или все они отозвали свои ключи):

GPGletterUnkn3.png


Письмо, подписанное известным ключом, будет отображаться так:

GPGletterUntrust.png

Поскольку этот ключ никем не подписан, и не получен непосредственно при личном контакте, он считается "недоверенным".

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

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


Если вы всё тщательно проверили, вы можете подписать ключ

GPGsignKey.png

выбрав разумный уровень доверия:

GPGsignOB.png


Письмо, подписанное доверенным ключом, отображается по-другому:

GPGletterKnown.png

FrBrGeorge/UsingEnigmail (последним исправлял пользователь FrBrGeorge 2008-11-28 11:54:50)