БУМАЖНЫй НОМЕР
![]() |
01.10.2001
Филип ЗИММЕРМАНН
Для начала немного элементарной терминологии. Предположим, вы желаете отправить сообщение своей коллеге Алисе и хотите, чтобы никто, кроме Алисы, не смог его прочитать. Как показано на рис. 1, вы можете зашифровать (или закодировать), то есть преобразовать сообщение безнадежно сложным образом, зная, что никто, кроме вас и Алисы, не сможет его прочитать. Вы применяете для шифрования криптографический ключ, а Алиса должна использовать тот же ключ для его расшифровки (или раскодирования). По крайней мере, так это выглядит при применении обычной криптографии с секретным ключом.
Один и тот же ключ используется как для шифрования, так и для расшифровки сообщения. Это означает, что ключ должен быть сначала передан по надежному каналу, дабы обе стороны знали его до того, как передавать зашифрованное сообщение по ненадежному каналу. Но если у вас есть надежный канал, которым вы можете воспользоваться для обмена ключами, спрашивается, зачем вам вообще нужна криптография?
Криптография с открытым ключом
Как показано на рис. 2, при использовании криптографии с открытым ключом каждый обладает парой дополняющих друг друга ключей: открытым и закрытым. Любой из ключей, входящих в пару, подходит для расшифровки сообщения, зашифрованного с применением другого ключа из той же пары. Зная открытый ключ, закрытый вычислить невозможно. Открытый ключ может быть опубликован и широко распространен по сетям коммуникаций.
Такой протокол обеспечивает приватность без необходимости обладания надежным каналом, которого требует обычная криптография с секретным ключом.
Кто угодно может использовать открытый ключ получателя для того, чтобы зашифровать сообщение. Получатель затем использует соответствующий закрытый ключ для его расшифровки. Никто, кроме получателя, не может расшифровать сообщение, так как никто больше не имеет доступа к закрытому ключу. Даже тот, кто зашифровал сообщение с помощью открытого ключа, не сможет его расшифровать.
Поскольку алгоритм шифрования с открытым ключом значительно медленнее алгоритма обычного шифрования, использующего один ключ, шифрование лучше всего выполнять используя процесс, показанный на рис. 3.
Для шифрования сообщения используется качественный и быстрый алгоритм обычного шифрования с секретным ключом. В оригинальной, незашифрованной форме сообщение называется «открытым текстом». В ходе процесса, не видимого пользователю, для обычного шифрования открытого текста используется временный случайный ключ, сгенерированный специально для этого «сеанса». Затем случайный ключ шифруется с помощью открытого ключа получателя. Этот, зашифрованный с использованием открытого ключа «сеансовый ключ», отправляется получателю вместе с зашифрованным текстом («шифровкой»).
Как показано на рис. 4, процесс расшифровки является обратным по отношению к шифрованию. Закрытый ключ получателя используется для восстановления врйменного сеансового ключа, который, в свою очередь, используется при запуске быстрого обычного алгоритма с секретным ключом для расшифровки основного тела сообщения.
Цифровая подпись
Цифровая подпись (рис. 5) накладывается для обеспечения аутентификации сообщения. Закрытый ключ отправителя используется для зашифровки дайджеста сообщения, таким образом «подписывая» сообщение. Дайджест сообщения - это 160- или 128-битная криптографически стойкая односторонняя хэш-функция. В чем-то она похожа на «контрольную сумму» или код обнаружения ошибок CRC, который компактно представляет сообщение и используется для проверки сообщения на наличие изменений, но формируется таким образом, что злоумышленник не может сгенерировать поддельное сообщение с тем же дайджестом. Дайджест сообщения передается в зашифрованном закрытым ключом отправителя виде, составляя цифровую подпись сообщения.
Получатель (или кто-либо другой) может проверить правильность цифровой подписи, используя открытый ключ отправителя для расшифровки дайджеста сообщения. Это доказывает, что тот, кто указан в качестве отправителя сообщения, является его создателем и что сообщение не было впоследствии изменено другим человеком, так как только отправитель владеет своим закрытым ключом, использованным для формирования цифровой подписи.
Угроза подмены ключа
В криптосистемах с открытыми ключами вам не нужно защищать открытые ключи от несанкционированного доступа. Наоборот, чем шире они распространяются, тем лучше. Однако важно защитить открытые ключи от подделки, чтобы быть уверенным, что ключ действительно принадлежит тому, чье имя он несет. Давайте сначала взглянем на потенциальную опасность такой подмены, а затем посмотрим, как ее избежать.
Предположим, вы хотите отправить приватное сообщение Алисе. Вы подгружаете открытый ключ Алисы с какой-нибудь электронной доски объявлений 1, шифруете письмо Алисе ее открытым ключом и отправляете его по электронной почте.
К несчастью, незаметно для вас и Алисы другой пользователь, по имени Виктор, генерирует открытый ключ, несущий идентификатор пользователя «Алиса», и помещает его на эту доску объявлений. Виктор тайно подменяет своим фальшивым ключом настоящий открытый ключ Алисы. Вы неосторожно используете фальшивый ключ, принадлежащий Виктору, вместо открытого ключа Алисы. Все выглядит нормально, потому что фальшивый ключ несет идентификатор пользователя «Алиса». Теперь Виктор может расшифровать сообщение, предназначенное Алисе, поскольку обладает секретным ключом из фальшивой пары. Он даже может снова зашифровать расшифрованное сообщение настоящим ключом Алисы и отправить ей, так что никто ничего не заметит.
Единственный способ предотвратить такую неприятность - исключить возможность подделки открытых ключей. Если вы получили открытый ключ непосредственно от Алисы, проблем не возникает. Но это может быть затруднительным, если она находится за тысячу миль или, по другим причинам, с ней невозможно встретиться лично.
Архитектура сертификации ключей
Возможно, открытый ключ Алисы может передать вам ваш общий друг Генри, которому вы оба доверяете и который знает, что обладает подлинным ключом. Генри может подписать открытый ключ Алисы, ручаясь, таким образом, за его целостность. Для подписи он должен использовать собственный закрытый ключ.
Эта процедура создает подписанный сертификат открытого ключа, который подтверждает, что ключ Алисы не был подделан. Конечно, для проверки подписи Генри необходимо, чтобы у вас была заведомо правильная копия его открытого ключа. Возможно, Генри может также передать Алисе подписанную копию вашего ключа. Генри, таким образом, будет служить «посредником» между вами и Алисой.
Подписанный сертификат открытого ключа Алиса или Генри могут подгрузить на доску объявлений, откуда вы можете его скопировать. Так как вы проверили подпись Генри с помощью его открытого ключа, вы можете быть уверены, что это - действительно ключ Алисы.
Пользующееся широким доверием лицо может даже специализироваться на
«посредничестве» между пользователями, заверяя своей подписью сертификаты их
открытых ключей. Это пользующееся доверием лицо может считаться «доверенным
сертификатором». Любому публичному ключу, заверенному подписью уполномоченного
сертификатора, можно доверять в том смысле, что он принадлежит тому, чье имя
несет. Все пользователи, желающие участвовать в реализации такой сети
распределенного доверия, должны обладать заведомо верной копией ключа
уполномоченного сертификатора, дабы подпись последнего могла быть проверена. В
некоторых случаях доверенный сертификатор может поддерживать сервер ключей,
давая
пользователям сети возможность искать открытые ключи с помощью запросов к
серверу ключей, однако не обязательно, чтобы тот, кто поддерживает сервер
ключей, был и тем, кто их сертифицирует.
Единый уполномоченный сертификатор особенно подходит для больших централизованно управляемых организаций - правительственных или корпоративных. Некоторые организационные среды используют иерархии доверенных сертификаторов.
Для децентрализованных сред более походящим, чем создание централизованного доверенного сертификатора, вероятно, будет предоставление всем пользователям возможности действовать в качестве «посредников» 2.
Задача защиты открытых ключей от подделки составляет единственную серьезную проблему практического приложения криптографии с открытыми ключами. Она является ахиллесовой пятой этой технологии, и сложность программного обеспечения в основном связана именно с ее решением.
Вам следует использовать чей-либо открытый ключ только после того, как вы убедитесь, что это настоящий ключ, а не подделка, что он принадлежит именно тому лицу, чье имя несет. Вы можете быть уверены в этом, только если получили сертификат открытого ключа непосредственно от его хозяина или если он подписан кем-либо, кому вы доверяете, и заведомо правильная копия ключа которого у вас уже есть. Идентификатор пользователя ключа должен нести полное имя владельца, а не только его первое имя.
Как бы велико ни было искушение, вы никогда не должны полагаться на случайность и доверять подлинности ключа, если он не подписан кем-нибудь, кому вы доверяете. Несертифицированный открытый ключ может оказаться подделкой, выполненной кем угодно.
Если вас просят подписать сертификат чьего бы то ни было открытого ключа, убедитесь, что он действительно принадлежит этому лицу. Ведь ваша подпись на чужом ключе есть ручательство того, что ключ принадлежит его владельцу. Те, кто вам доверяет, примут к использованию этот ключ, потому что он несет вашу подпись. Полагаться на слухи чрезвычайно неосмотрительно: не подписывайте открытых ключей, если вы не уверены в том, что они действительно принадлежат их хозяевам. По возможности вы должны подписывать их, только если получили их непосредственно от хозяев.
Чтобы подписать открытый ключ, вы должны быть уверены в его принадлежности хозяину в гораздо большей степени, чем если просто собираетесь использовать его для шифрования сообщения. Подписи на сертификате, сделанной надежным посредником, обычно достаточно, чтобы использовать сертифицированный ключ для шифрования. Но чтобы подписать чей-либо ключ, вы должны обладать независимым знанием из первых рук о том, кому этот ключ принадлежит. Можно позвонить владельцу ключа и продиктовать ему отпечаток ключа - удостоверившись, конечно, что вы разговариваете именно с ним.
Имейте в виду, что ваша подпись на сертификате открытого ключа представляет собой ручательство за целостность ключа и его принадлежность действительному владельцу, а отнюдь не за самого владельца. Вы ничем не рискуете, подписывая открытый ключ социопата, если уверены, что этот ключ действительно ему принадлежит. Другие примут ключ, проверив вашу подпись на нем (если они, конечно, вам доверяют), но из этого не будет следовать доверия к его обладателю.
Совсем неплохо иметь под рукой свой собственный открытый ключ, сертифицированный подписями различных «посредников», поскольку большинство корреспондентов доверяет хотя бы одному из тех, кто ручается за целостность вашего ключа. Вы можете опубликовать свой открытый ключ вместе с набором удостоверяющих подписей.
Перевод с англ. - М.О. Публикуется с любезного разрешения
автора.
Статья представляет собой адаптированный фрагмент статьи
«Особенности модели безопасности и уязвимые места», входящей в документацию по
PGP.
Полный текст статьи можно найти на
www.computerra.ru/offline/1997/225/925,
а полный перевод документации на довольно старую (5.0) версию PGP -
на
ftp.kiarchive.ru/pub/windows/crypto/pgp/pgp50manual-ru.rar.
Безопасная передача данных в Linux
Чаще всего задача защиты данных от несанкционированного изменения (authenticity), а также от просмотра посторонними (privacy) возникает при их передаче - начиная от электронной почты и копирования файлов и до TCP-туннелей и трафика в целом.
Электронная почта
Обмен сообщениями посредством электронной почты, пожалуй, самый распространенный способ передачи информации. Для обеспечения безопасной переписки разрабатывалось несколько технологий, из которых одна - PGP (Pretty Good Privacy) - получила наивысшее признание и легла в основу соглашения о формате PGP-сообщений (OpenPGP Message Format).
Свободно распространяемые решения для защиты переписки построены на GPG (GnuPG - the GNU Privacy Guard) - свободной реализации стандарта OpenPGP. Собственно GPG - это утилита с текстовым интерфейсом, предназначенная для шифрования данных, создания цифровых подписей и управления ключами.
Бесплатных почтовых клиентов, в той или иной мере поддерживающих защиту переписки при помощи GPG, довольно много (см., например), однако лишь в нескольких из них поддержка OpenPGP реализована в полной мере. Среди почтовых клиентов с текстовым интерфейсом - это Mutt и Mew, с графическим - GNUS, Sylpheed и TkRat. Эти программы, помимо множества других почтовых функций
позволяют отправлять сообщения, подписанные цифровой подписью, и проверять подпись у таких сообщений;
позволяют отправлять зашифрованные сообщения и расшифровывать сообщения;
предоставляют возможность выбирать ключи, используемые для подписи или шифрования сообщений;
предоставляют возможность автоматически получать новые ключи с серверов;
реализуют полную поддержку PGP/MIME.
Воспользоваться PGP-возможностями клиентов очень просто. Для этого, как правило, достаточно включить соответствующие параметры в конфигурации программ (иногда они включены по умолчанию), и можно отправлять и принимать подписанные или зашифрованные письма. Разумеется, чтобы подписывать сообщения, нужно обладать ключом. Его можно сделать с помощью менеджера ключей, каковым является сам GnuPG (с текстовым интерфейсом), а также несколько графических утилит-интерфейсов к нему; из последних самым мощным на данный момент средством является GPA (GNU Privacy Assistant).
Помимо обычной электронной переписки, OpenPGP в последнее время все больше применяется для управления почтовыми роботами, такими как списки рассылок электронной почты. Основная идея этого метода проста: почтовый робот, принимая сообщение, проверяет подпись, определяя тем самым адресата, и на этом основании принимает решение о дальнейшей обработке сообщения. И наконец, PGP используется для безопасного копирования файлов. Так, при распространении программного обеспечения нередко к файлам архивов прилагаются файлы цифровых подписей, позволяющие установить как целостность, так и аутентичность скачанного ПО.
Копирование файлов и TCP-туннели.
Передача данных, очевидно, не ограничивается электронной почтой. Интерактивный обмен информацией требует других технологий обеспечения безопасной передачи данных, и здесь на помощь приходит SSH (Secure Shell). Первоначально предназначенный для защиты удаленных сеансов (что сохранилось в названии протокола), SSH превратился в мощное средство построения защищенных TCP-туннелей (TCP forwarding), с помощью которых без дополнительных затрат легко получить:
безопасные удаленные сеансы - непревзойденное средство для удаленного администрирования;
туннелирование X Window (X11 forwarding) - метод запуска удаленных графических клиентов на локальном X-сервере;
безопасное копирование файлов с помощью утилит scp и sftp;
защищенную доставку почты по SMTP, POP, IMAP;
защищенный доступ по HTTP;
защищенное зеркалирование файловых архивов и восстановление с помощью rsync;
защищенные технологии разработки на основе CVS;
и многое, многое другое.
Аутентификация в SSH осуществляется, в зависимости от конфигурации SSH-сервера, одним или несколькими методами, из которых приемлемую степень безопасности предоставляет аутентификация по паролю, а наибольшая степень безопасности может быть получена при использовании ключей достаточной длины. Метод аутентификации по ключу при помощи утилиты ssh-agent позволяет также реализовать неинтерактивный обмен данными по SSH.
Трафик в целом
Впрочем, и SSH порой бывает недостаточно. Например, если возникает потребность защитить весь трафик, включая UDP и даже IP. В этом случае применяется протокол IPSEC (IP Security), обеспечивающий аутентичность и/или приватность (в зависимости от конфигурации) на уровне IP, а значит, и всех протоколов, реализованных поверх IP. Свободной реализацией IPSEC для Linux является FreeS/WAN, входящий в большинство современных дистрибутивов Linux. Самыми распространенными моделями защиты сетевого трафика при помощи FreeS/WAN являются:
Virtual Private Network (VPN): позволяет двум статическим сетям, соединенным между собой третьей сетью (ненадежной с точки зрения безопасности), безопасно обмениваться данными.
Road Warriors: позволяет из дома, гостиницы, самолета и т. п. устанавливать безопасное IP-соединение с офисом.
Opportunistic encryption: позволяет двум произвольным шлюзам FreeS/WAN обеспечивать защищенный трафик между собой без предварительных контактов и без востребования информации друг о друге.
Поскольку защита трафика при помощи IPSEC происходит на более низком уровне в иерархии сетевых протоколов, чем SSH и OpenPGP, последние можно использовать независимо от того, применяется IPSEC или нет. Поэтому совмещая все эти методы обеспечения безопасной передачи данных можно добиться максимальной безопасности.
Безопасное хранение данных
Иногда данные могут быть увиденными или измененными не только при передаче. Например, носитель может попасть в чужие руки, и тем самым все данные на нем будут скомпрометированны. Чтобы этого не случилось, применяют шифрование файлов или целых файловых систем, на которых расположены нуждающиеся в защите данные. В последних дистрибутивах Linux поддержка шифрования файловых систем интегрирована в ядро и утилиты, управляющие специальными loopback-устройствами, посредством которых и происходит работа с шифрованными файловыми системами. Поддерживаются все свободные стойкие симметричные алгоритмы шифрования: Rijndael (AES), Twofish, Blowfish и др.
При защите особо конфиденциальных данных следует подключать файловую систему, на которой они находятся, ровно на то время, когда к ним осуществляется доступ. Например, при резервном копировании таких данных следует подключать файловую систему непосредственно перед началом процедуры и отключать сразу по ее окончании.
Дмитрий Левин
[ldv@alt-Linux.org]
К Windows припарка
В отличие от других систем операционки, выпускаемые компанией Microsoft, обычно не предлагают расширяемый набор функциональности - «конструктор», из которого администратор или пользователь может собрать нужную конфигурацию. Это относится и к такому «шумному» приложению, как криптографическая защита данных и связи: с 2000 года Microsoft декларирует доступность основных пользовательских криптографических приложений - защиту электронной почты, Web-коммуникации и шифрования локальных данных, а также IPSec и некоторые другие менее известные приложения.
Формально эта декларация выполняется. К примеру, если вы возьмете «офисный» комплект из MS Windows 2000 и MS Office 2000, то обнаружите, что в свойствах каталогов файловой системы NTFS есть флажок шифрования, почтовый клиент MS Outlook поддерживает формат защищенной почты S/MIME (претендующий, наряду с OpenPGP, на статус стандарта защиты почты), а встроенный Web-браузер Internet Explorer - защиту Web-трафика с помощью SSL. Всё на месте.
При внимательном рассмотрении обнаруживаются два «но». Во-первых, Microsoft, в силу как своей величины, так и склонности к авантюрам, периодически увязает в политических противоречиях. Так, во всеуслышание объявив о доступности крипто с декларированной стойкостью для пользователей во всем мире (это стало возможным после снятия США большей части ограничений на «экспорт» крипто), корпорация заключила частное соглашение с Федеральным агентством правительственной связи и информации РФ (ФАПСИ), по которому в Россию поставляется версия с искусственно «кастрированной» длиной ключа.
Предполагается, что пользователь, желающий получить декларированную стойкость выше маргинальной, должен, заплатив один раз за лицензию на Windows 2000 (в стоимость которой «вырезанные» модули уже входят), отстегнуть еще и одной из аффилированных с ФАПСИ коммерческих организаций, поставляющих «сертифицированные средства». (На русских страницах сервера Microsoft вы найдете массу рекламы таких «средств», но не информацию о том, что недостающие в «русской» поставке модули можно просто загрузить из секции Downloads того же сервера.)
Во-вторых, Microsoft (как и ее партнеры из числа друзей ФАПСИ) придерживается стратегии сокрытия исходных текстов от публики, поэтому обратите внимание на слово «декларированная». Независимый анализ безопасности закрытых продуктов - дело долгое, но история соответствия деклараций с их результатами показывает, что Microsoft в этом отношении - «дама с прошлым», и относиться к заявленной стойкости серьезно не стоит.
Закрытая ОС - сама по себе бомба, заложенная под безопасность решения, а использование закрытой ОС и закрытых средств обеспечения ее безопасности от одного поставщика - вообще безвыигрышная лотерея.
Не вдаваясь в анализ эффективности паллиативных решений, хочется порекомендовать пользователям, озабоченным приватностью, но применяющим Windows, обратить внимание на следующие моменты:
Так что, при всем богатстве выбора, альтернатива всегда есть.
Максим Отставнов
[maksim@otstavnov.com]
1 (обратно к тексту) - Сегодня для обмена
ключами обычно используются выделенные глобальные, региональные или
корпоративные серверы ключей. - Здесь и далее прим. ред.
2 (обратно к тексту) - Эта возможность
реализована пока лишь в самых продвинутых криптосистемах, таких как OpenPGP.