- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF137:DrBrown3
Материал из Linuxformat.
Содержание |
Pretty Good Privacy
- Примените свои новые знания о криптографии на практике, научившись шифровать и подписывать свои письма с помощью GnuPG.
PGP Фила Циммермана принес в массы набор серьезных криптографических технологий в простой для установки форме. На самом деле ПО на вашем компьютере Linux скорее всего принадлежит не перу Циммермана, а было переписано (стандарт OpenPGP) Фондом свободного ПО. Он называется GPG (GNU Privacy Guard – страж безопасности GNU).
Cердце GPG – утилита командной строки gpg, решающая базовые задачи подписи, шифрования и дешифрации сообщений, а также управления ключами. Ею мы и займемся. В вашей программе электронной почты наверняка есть модуль расширения, скрытно применяющий эту утилиту для шифрования, подписи и дешифрации почты. Продемонстрируем его действие, предположив, что Алекс хочет надежно обменяться сообщениями с Бет.
Сперва Алекс генерирует пару открытый/закрытый ключ:
$ gpg --gen-key
В ответ на запрос утилиты он выбирает ключи DSA и Эль Гамаля и размер ключа DSA 2048 бит. Его также просят указать парольную фразу для защиты его закрытого ключа, а также имя, электронный адрес и комментарий, для создания идентификатора пользователя (User ID), определяющего владельца ключа в удобном для чтения виде. Теперь открытый и закрытый ключи Алекса появились в файлах с расширением GPG в каталоге .gnupg. И Алекс экспортирует свой открытый ключ в файл ASCII:
$ gpg --export --armor -o alex.pub Alex
Защита ключа означает его представление в форме ASCII, которую можно, например, напечатать или передать текстом по электронной почте. Последний аргумент (Alex) – фрагмент идентификатора пользователя ключа, достаточный для его распознания. Файл результата – alex.pub – он планирует передать Бет.
Бет делает то же: создает собственную пару ключей и парольную фразу и экспортирует открытый ключ в файл beth.pub, готовый для передачи Алексу.
Процесс обмена открытыми ключами сложен, и я не буду в него вдаваться; пусть Алекс и Бет встретятся лично и обменяются файлами alex.pub и beth.pub на флэшках. Алекс вставляет флэшку Бет в свой компьютер и импортирует его в кольцо ключей GPG:
$ gpg --import beth.pub
Бет, придя домой, импортрирует открытый ключ Алекса в свое кольцо ключей. Выведя список своих ключей, Алекс теперь увидит открытую часть своего ключа и ключа, полученного от Бет:
$ gpg --list-keys /home/alex/.gnupg/pubring.gpg ----------------------------- pub 2048D/B4DF979C 2010-08-02 [expires: 2010-08-30] uid Alex Example (Demo User A) <alex@example.com> sub 2048g/626C246D 2010-08-02 [expires: 2010-08-30] pub 2048D/F6CA4978 2010-08-02 [expires: 2010-08-30] uid Beth Example (Demo User B) <beth@example.com> sub 2048g/07DFB736 2010-08-02 [expires: 2010-08-30]
Алексу нужно сделать еще кое-что. прежде чем отправить Бет конфиденциальное сообщение с помощью ее ключа. Ему нужно подписать ключ Бет, подтвердив: он доверяет тому, что ключ ее.
$ gpg --sign-key Beth
Так как она передала ему ключ лично, сомнений у него нет. Позже я вернусь к вопросу доверия ключам. Теперь Алекс может отправлять Бет шифрованные сообщения с помощью ее открытого ключа. В знак внимания он решает отправить ей стихи:
$ gpg --encrypt --armor --recipient Beth poetry.txt
У него появляется зашифрованный файл poetry.txt.asc для отправки Бет. Он знает, что только Бет сможет его прочесть, потому что только ей известен закрытый ключ, соответствующий открытому ключу, которым зашифровано сообщение.
Тут вы можете спросить, зачем нужна пара ключей Алекса. Ну, он уже воспользовался своим закрытым ключом для подписи (чтобы выразить свое доверие) открытого ключа Бет. Его открытым ключом, разумеется, можно зашифровать ответ Бет Алексу.
Но у Бет есть проблема. Она также дала свой открытый ключ Чарльзу, Дэйву и Эрику, и хотя она ждет письма от Алекса, почта может прийти от любого из ребят. В конце концов, содержимое строки «От кого» (From) в заголовке электронного письма легко подменить. Чтобы доказать подлинность отправителя, Алексу нужно подписать свое письмо цифровой подписью.
Цифровые подписи
Алекс подписывает свое сообщение, создавая его свертку (хэш) и шифруя ее своим закрытым ключом. После приема Бет может расшифровать свертку (с помощью открытого ключа Алекса), вычислить собственную свертку сообщения и сравнить эти свертки. Если они совпадают, Бет может быть абсолютно уверена, что сообщение пришло от Алекса и оно не изменялось с момента подписи. Заметьте, что цифровая подпись не шифрует сообщения. Конечно, gpg скрывает эту сложность за простотой командной строки. Алекс может и зашифровать, и подписать сообщение:
$ gpg --encrypt --sign --armor --recipient Beth poetry.txt
Когда Бет будет расшифровывать его, подпись будет проверена автоматически. Со стороны Бет диалог будет выглядеть так:
$ gpg --decrypt -o poetry.txt poetry.txt.asc You need a passphrase to unlock the secret key for user: “Beth Example (Demo User B) <beth@example.com>” 2048-bit ELG key, ID 07DFB736, created 2010-08-02 (main key ID F6CA4978) gpg: encrypted with 2048-bit ELG key, ID 07DFB736, created 2010-08-02 “Beth Example (Demo User B) <beth@example.com>” gpg: Signature made Mon 02 Aug 2010 03:25:00 BST using DSA key ID B4DF979C gpg: Good signature from “Alex Example (Demo User A) <alex@example.com>”
Здесь gpg сообщает, чьим открытым ключом было зашифровано сообщение, чьим закрытым ключом оно было подписано, и то, что подпись соответствует сообщению.
Управление открытым ключом
Проверка открытых ключей – самая сложная часть PGP. Проблема на самом деле не в передаче ключа – его можно легко отправить друзьям по электронной почте, выложить на сайт или загрузить на сервер ключей, такой как http://pgp.mit.edu. Проблема в гарантии, что открытые ключи действительно принадлежат тому, кому должны принадлежать. Например, поискав «Осама Бин Ладен» на pgp.mit.edu, вы получите несколько ключей сомнительной подлинности.
У протокола SSL (слой защищенных сокетов – вы пользуетесь им, когда подключаетесь к защищенному сайту интернет-магазина) есть похожая проблема: как узнать, что публичный ключ, который вы получаете от его владельца, и вправду принадлежит ему? Для решения этой проблемы используется формальная иерархическая инфраструктура открытых ключей (PKI) с доверенными центрами сертификации, которым платят за подпись сертификатов. Исторически в PGP использовался менее формальный подход, основанный на сети доверия. Алекс говорит, что доверяет своей копии открытого ключа Бет, подписывая его (своим закрытым ключом). У каждого пользователя есть набор подписанных открытых ключей и файл, который называется кольцом или связкой ключей.
Пусть Алекс уверен, что у него настоящие копии ключей Бет и Чарли, и он доверяет им подписать ключи других. Затем, если у него появляется ключ, который должен быть от Дэвида, подписанный Бет и Чарли, он может считать, что ключ Дэвида подлинный. Так образуются сети доверия. Этот процесс можно существенно ускорить на «вечеринках по подписи ключей» [key signing party], которые часто происходят на конференциях или групповых встречах пользователей. На одной из таких встреч Алекс познакомился с Элвином, Фредом, Гордоном и Гермионой. Он поговорил с каждым из них, проверил их личность – наверное, спросил паспорт или просто посмотрел, как они выглядят – и записал «отпечатки пальцев» их ключей. («Отпечаток пальца» – дайджест ключа, достаточно короткий для сравнения вручную, и достаточно длинный, чтобы надежно представлять ключ.) Дома Алекс загружает открытые ключи своих новых знакомых, из различных источников. Он импортирует ключи в свою связку открытых ключей и снова сравнивает их «отпечатки пальцев» с теми, что он записал. Так как они совпадают, он может спокойно подписать ключи. Существует даже протокол для упрощения процесса массовой проверки «отпечатков пальцев» (протокол Циммермана–Сассамана [Zimmermann–Sassaman]).
$ gpg --fingerprint Fred pub 2048D/F6CA4978 2010-08-02 [expires: 2010-08-30] Key fingerprint = D8FE 3466 B0E3 F737 6BBA D711 091E 0365 F6CA 4978 uid Fred Flintsone (Quarry Manager) <fred@bedrock.com> sub 2048g/07DFB736 2010-08-02 [expires: 2010-08-30]
Теперь дело за вами – счастливого шифрования!
Как работает PGP
Любопытно, как все это работает вместе? В PGP используется сочетание симметричных и асимметричных шифров. Создается случайный ключ сессии (только для данного сообщения), затем он шифруется открытым ключом получателя. Результат отправляется как часть сообщения.
Затем ключом сессии шифруется открытый текст отправителя, симметричным шифром (по умолчанию IDEA), и результат присоединяется к сообщению. Получатель расшифровывает ключ сессии своим закрытым ключом, а затем использует полученный открытый ключ для расшифровки основного сообщения.
У этого подхода есть ряд преимуществ: во-первых, симметричные шифры работают гораздо быстрее, и им не нужна такая длина ключа. Во-вторых, если перехватчик взломает ключ сессии, это не поможет ему прочитать все последующие сообщения. Наконец, так как асимметричный шифр используется только для шифрования короткого (и случайного) значения, шансов на то, что он будет взломан криптоаналитиком, не остается почти никаких.
Насколько хорош PGP?
Судя по открытым сведениям, на данный момент используемые в PGP шифры практически невозможно взломать за любое реальное время и с вычислительными ресурсами любой мощности. Всегда возможен вариант, при котором какой-нибудь гений в Управлении национальной безопасности США или Центре правительственной связи Великобритании найдет уязвимость и заставит правительство построить компьютер стоимостью в миллион долларов, чтобы воспользоваться ею. Это был бы уже не первый раз, когда правительство успешно взломало шифр, но помалкивало об этом, чтобы поток поддающихся дешифровке сообщений продолжался. И «довольно хороший» (pretty good) на самом деле означает «почти наверняка за пределами возможностей любого врага, которого надо удерживать от взлома системы, пока важна безопасность».