Этот документ описывает организацию и проведение встречи для подписи ключей PGP с использованием GnuPG. Он также объясняет процесс подписи ключей, даёт ответы на часто задаваемые вопросы и поясняет, как создать собственную пару ключей и как подписывать ключи других людей. Этот документ появился как перевод The Keysigning Party HOWTO V. Alex Brennen (vab@cryptnet.net), но со временем несколько видоизменился.
Встреча для подписи ключей - это собрание людей, которые используют систему шифрования PGP, для подписи ключей друг друга. Встречи для подписи ключей позволяют значительно расширить сеть доверия. Кроме того, встречи для подписи ключей предоставляют замечательную возможность обсудить различные общественные и политические проблемы, возникающие в связи с применением сильной криптографии, вопросы свободы личности, личной неприкосновенности или просто возможность поболтать, а может быть, даже придумать новые механизмы шифрования.
Подпись ключей - это процесс электронной подписи открытого ключа и соответствующего ему идентификатора личности. Процесс подписи ключа позволяет убедиться, что открытый ключ и идентификатор пользователя действительно принадлежат владельцу открытого ключа и соответствующего идентификатора.
Можно подписывать как собственные открытые ключи, так и открытые ключи и идентификаторы других пользователей.
Смысл подписи ключей состоит в подтверждении третьим лицом принадлежности открытого ключа и соответствующего идентификатора. Таким образом, подпись ключей позволяет создать сеть доверия.
Термин "сеть доверия" используется для описания отношений доверия между несколькими ключами (точнее - их владельцами). Ключи представляют собой узлы графа доверия, а подписи - рёбра графа. Эти связи между ключами также называются путями доверия. Доверие может быть как двусторонним, так и односторонним. В идеальной сети доверия каждый доверяет каждому. Это означает, что каждый уверен, что все ключи принадлежат своим владельцам. Сеть доверия может рассматриваться как сумма всех путей доверия между всеми владельцами ключей.
Пусть, например, Алиса и Борис каждый создали ключи PGP с помощью GnuPG и провели встречу для подписи ключей. На встрече Алиса и Борис проверили ключи друг друга и впоследствии подписали их. По умолчанию GnuPG автоматически подписывает открытый ключ каждой вновь созданной пары с помощью соответствующего закрытого ключа. Таким образом, как Алиса, так и Борис имеют как минимум по две подписи, подтверждающие их владение соответствующим ключом. Ключ Алисы подписан самой Алисой и Борисом, а ключ Бориса подписан им самим и Алисой.
Допустим, впоследствии Алиса и Борис познакомились с Викторией. Виктория создаёт пару ключей и сообщает Алисе и Борису, что пошлёт им свой открытый ключ. Алисе не нравится Виктория, и она не хочет, чтобы Борис обменивался с Викторией зашифрованными письмами. Алиса также создаёт PGP-ключи от имени Виктории и высылает их Борису. Оба открытых ключа имеют только одну подпись - созданную с помощью соответствующего закрытого ключа. Борис не может проверить, какой из ключей на самом деле принадлежит Виктории.
Виктория узнает, что Борис получил два открытых ключа от её имени. Она подозревает Алису. Желая отомстить, Виктория может попытаться разрушить отношения доверия между Борисом и Алисой. Чтобы достичь результата, Виктория посылает письмо Борису от имени Алисы, сообщая, что Алиса создала новую пару ключей. В письме также содержится "новый ключ" Алисы, созданный Викторией. Однако Борис может легко установить подмену, так как, хотя у него и есть два разных ключа, оба якобы принадлежащих Алисе, один из них подписан несколькими людьми (им самим и Алисой), а другой (поддельный ключ, созданный Викторией) - только собственным закрытым ключом.
Этот пример очень упрощён, и в реальной ситуации процесс может выглядеть намного сложнее. Прочтите список ответов на частые вопросы о PGP или какую-нибудь хорошую книгу о PKI - наверняка вы найдёте более подробное объяснение и много дополнительной информации. Рассмотренный пример, однако, наглядно показывает принципы и необходимость подписи ключей. Виктории не удалось заставить Бориса использовать поддельную пару ключей для Алисы, поскольку между Алисой и Борисом уже установлен путь доверия.
Однако наличие подписей и сетей доверия не всегда обеспечивает возможность проверки ключей. Пусть, например, Алиса и Борис познакомились с Викторией в присутствии Дмитрия, знакомого Виктории. Дмитрий может создать поддельные ключи для Алисы и Бориса, подписать их своим ключом и поддельными ключами Алисы и Бориса. В этом случае он получит три подписи на каждом из поддельных ключей, которые он пошлёт Виктории. Настоящие ключи Алисы и Бориса подписаны только их закрытыми ключами; они также посланы Виктории. Каким образом Виктория может противостоять такой атаке? Пусть, например, весь обмен ключами происходит через сервер ключей. Виктория находит по две копии ключей для Алисы и Бориса. Если ключи Бориса и Алисы подписаны двадцатью участниками во время встречи для подписи ключей, очевидно, что Виктории следует доверять открытым ключам, подписанным 20 раз, а не тем, которые подписаны всего 3 раза. В любом случае уже сам факт существования двух наборов подписей должен насторожить Викторию - в этом случае она может более тщательно проверить сеть доверия наборов, даты создания и тому подобное. 20 ключей, использовавшиеся во время встречи для подписи ключей, сами должны быть подписаны не менее 20 раз, иметь различные даты создания, развитые сети доверия. У поддельных ключей этого не будет, даже если Дмитрий создаст поддельную сеть доверия из 20 ключей. Поддельная сеть доверия Дмитрия будет ограничена по размерам и глубине количеством ключей, созданных или контролируемых Дмитрием. Многоуровневая сеть доверия, содержащая заведомо настоящие ключи, будет веским свидетельством в пользу того, что подлинным ключам Алисы и Бориса можно доверять больше, чем поддельным ключам Дмитрия.
Есть три основных причины проводить встречи для подписей ключей как можно чаще.
Во-первых, частое проведение встреч для подписи ключей позволяет расширять сеть доверия. Чем сильнее связана сеть доверия, чем больше отношений доверия установлено в ней, тем труднее её разрушить. Это может оказаться особенно важно для пользователей и разработчиков открытого программного обеспечения. Разработчики часто используют PGP для криптографической подписи своих программных разработок, писем с сообщениями о критических ошибках и выходе новых версий. Развитость и связанность сети доверия прямо пропорциональна защите, обеспечиваемой PGP.
Во-вторых, встречи для подписи ключей позволяют привлечь новых членов и познакомить их с культурой компьютерной безопасности, помочь им понять принципы работы PGP и относящейся к ней сильной криптографии. Чтобы использовать преимущества, предоставляемые сильной криптографией, люди должны правильно её использовать.
Наконец, такие встречи позволяют расширять сообщество. Они позволяют людям ближе познакомиться друг с другом, общаться на интересующие их темы, как то: гражданские свободы, право использовать шифрование, управление Интернетом. Обсуждения важны, поскольку обсуждение - не только первый шаг, но и побуждение к действию. Сейчас, когда я пишу этот документ, в мире не так много больших сетей доверия. Если вы собираетесь создать сеть доверия в круге вашего общения, скорее всего, первыми участниками будут лидеры, организаторы и активные участники сообщества Интернета вокруг вас. Они могли бы взять на себя внедрение защищённых коммуникаций в сложившуюся сетевую инфраструктуру. Внедрение такой технологии и протоколов может предотвратить угрозы безопасности частной жизни, связанные с внедрением ФБР системы Carnivore (а МВД - СОРМ).
Организовать встречу для подписи ключей не очень сложно. Однако помимо обычных организационных задач вроде приглашения участников, выбора времени и места проведения встречи, координатор несёт ещё ряд специфических для такого рода встреч обязанностей. Они включают в себя создание списка ключей участников и определение порядка проведения встречи.
Есть две основных стратегии проведения встречи для подписи ключей: централизованная и децентрализованная. Выбор стратегии зависит от числа участников и места проведения встречи. Главное требование к организации встречи - чтобы участники могли проверить ключи друг друга и убедиться в том, что другие участники - те, за кого они себя выдают. Если это требование удовлетворено, координатор может комбинировать обе эти стратегии.
Централизованный способ проведения встречи позволяет провести подпись ключей более организованно и подходит для встреч с относительно небольшим числом участников. Участники заранее посылают информацию о их ключах координатору, который составляет список участников. По прибытии каждый участник получает копию списка ключей. Затем каждый участник по очереди вызывается координатором. Каждый участник проверяет правильность отпечатка своего ключа в списке ключей, распространяемом координатором. Если участник уверен, что его информация внесена в список верно, он оглашает отпечаток своего ключа так, чтобы другие участники могли его слышать и проверить правильность отпечатка. Если отпечаток верен, участники отмечают это в своих списках. Эта проверка необходима для защиты от ошибки координатора при создании списка или от намеренного искажения информации в списке. После того как каждый участник убедился в правильности ключа, координатор вызывает следующего участника и так далее. После того как правильность всех ключей проверена, все участники, включая координатора, выстраиваются в ряд, держа свои удостоверения личности перед собой. Участник в начале шеренги проходит всю шеренгу и проверяет удостоверения личности всех остальных участников. Если участник удовлетворён результатами проверки удостоверения личности, он также убеждается, что отпечаток ключа верен. Если это так, проверяющий участник ставит вторую отметку в списке. После того, как ключ прошёл две проверки, он может быть подписан.
На децентрализованной встрече каждый участник должен позаботиться о себе сам. Участники должны сами находить тех, чьи ключи они ещё не проверили. Во время неформального общения участники проверяют правильность своего ключа в списках других участников и проверяют удостоверения личности. Децентрализованный способ проведения встречи удобен в случае относительно большого числа участников, однако недостатком такого способа проведения является то, что скорее всего не все участники проверят ключи друг друга. В этом случае задачей координатора является организовать встречу таким образом, чтобы как можно больше участников (в идеале - все) смогли проверить ключи. В случае проведения децентрализованной встречи создание списков участников необязательно, однако это сильно облегчает организацию встречи.
Централизованные встречи хорошо подходят для проведения на всевозможных конференциях, во время неформальных встреч, домашних вечеринок или во время совместного похода в ресторан и т.д. Децентрализованные встречи лучше проводить на вечеринках, где присутствует большое число людей, в ночном клубе или на дискотеке - там, где централизованную встречу организовать трудно.
Чем больше людей примет участие во встрече, тем лучше. О встрече можно оповестить членов местной группы пользователей GNU/Linux, в популярных списках рассылки или дать объявление в газету или выпустить пресс-релиз.
Если вы только начинаете создание сети доверия в своей местности, попробуйте найти других активных пользователей PGP. Скорее всего, опытные пользователи уже принимали участие в подобных встречах для подписи ключей или сами организуют их в будущем. Попробуйте обратиться к тем людям, в подписях e-mail которых вы видели отпечатки ключа PGP или электронную подпись. Большое число потенциальных участников можно найти среди владельцев адресов электронной почты из университетов или крупных компаний.
Вот примеры объявлений о проведении встречи:
- Web-страница с объявлением
- Объявление по электронной почте
- Пресс-релиз с объявлением о встрече
Если вы собираетесь использовать списки ключей всех участников при проведении встречи, такой список нужно подготовить заранее. Список может выглядеть таким образом:
| Key ID | Key Owner | Key Fingerprint | Key Size | Key Type | Key Info Matches? | Owner ID Matches? |
|---|---|---|---|---|---|---|
| 992A4B3F | V. Alex Brennen vab@cryptnet.net | 0EC8 B0E3 052D FC4C 208F 76EB FA92 0973 992A 4B3F | 1024 | DSA |
Я написал скрипт на Perl, который позволяет создать HTML-документ, содержащий подобную таблицу, из кольца ключей PGP. Этот Perl-скрипт для создания списка участников встречи для подписи ключей доступен на условиях Общественной Лицензии GNU (GPL).
Каждый участник встречи должен иметь бумажную копию этого списка. Координатор может распечатать копии сам, сделать список доступным для скачивания через Web или разослать его через список рассылки, чтобы каждый участник мог распечатать список самостоятельно.
Ничто не вызывает у людей такого интереса, как разноцветные графики. Поэтому построение графического изображения получившейся в результате встречи сети доверия может заинтересовать потенциальных участников и служить наглядной иллюстрацией результатов, достигнутых при проведении встречи.
Построить графическую схему сети доверия очень легко. Для этого можно
использовать скрипт Darxus sig2dot.pl
или более современные варианты sig3
и sig2dot на Python. Все эти скрипты
на основе ключей и подписей в ключнице создают файл в формате dot.
Этот файл впоследствии используется пакетом Graphviz
AT&T Research для создания собственно изображения графа. С построениями
схем сетей, состоящих из нескольких сотен узлов, могут возникнуть
трудности из-за нехватки памяти.
Указания по построению графической схемы сети доверия включены в скрипт
sig2dot.pl, а также их можно найти на странице ключницы Debian.
Здесь расположен пример схемы сети доверия, созданный с помощью
sig2dot.pl и neato. Дополнительную информацию можно найти на странице
построения схемы ключницы Debian.
- Создать пару ключей
- Послать открытый ключ на сервер ключей (или координатору)
- Послать координатору информацию для внесения в список
- Лично прийти на встречу
- Проверить информацию в списке
- Проверить информацию о ключах других участников
- Проверить личность участников, чьи ключи вы хотите подписать
- Подписать ключи других участников
- Послать подписанные ключи на сервер ключей (или владельцу ключа)
- Необходимо явиться лично
- Два удостоверения личности с фото (паспорт, водительские права, студенческий билет, воинское удостоверение и т.д.)
- ID ключа, тип ключа, отпечаток ключа и его размер или копию списка участников
- Ручку или карандаш
- Компьютер
На встрече нельзя пользоваться компьютером, поскольку подмена программы или модификация операционной системы позволяют легко нарушить надёжность PGP.
Если кто-то приносит с собой портативный компьютер и все используют его для цифровой подписи ключей других участников, никто не может гарантировать, что на компьютере не установлена программа записи нажатых клавиш, изменённая версия GnuPG, изменённая версия ядра Linux или модифицированная клавиатура, что позволит раскрыть закрытые ключи тех, кто пользовался этим компьютером.
Если вы используете компьютер на встрече, ваш пароль также могут просто подсмотреть через плечо, GnuPG может быть модифицирована для создания более слабых ключей или даже может быть создан компьютерный вирус, заражающий GnuPG, для дальнейшего раскрытия закрытых ключей.
Создать собственную пару ключей очень просто. Нужно всего лишь запустить
gpg --gen-key. Однако я советую также создать отзывающий сертификат для
созданного ключа на случай, если доступ к закрытому ключу будет
невозможен (например, вы забыли парольную фразу или потеряли закрытый
ключ). Процедура создания отзывающего сертификата описана в разделе 3.7
этого документа.
Не всем могут быть необходимы описанные здесь действия по повышению безопасности. Скажем, если вы читаете всю почту на домашнем или портативном компьютере, вы можете сохранить ключи на жёстком диске. Возможно, вы также захотите создать ключ без истечения срока действия и использовать его для обычных коммуникаций, а для особо секретных (если у вас есть такие) использовать другой ключ. Повторюсь, что пошаговая инструкция, приведённая здесь, нацелена на обеспечение максимального уровня безопасности. Вам не обязательно полностью следовать ей, можно просто создать пару ключей. С другой стороны, если вы (так же, как и я) очень щепетильно относитесь к вопросам безопасности, следование этим инструкциям ненадолго успокоит вас (и вашу паранойю ;) ).
Эти пошаговые инструкции написаны с (довольно параноидальной) точки зрения обеспечения максимальной безопасности, что включает в себя:
- создание ключей максимально возможной длины для усложнения атак перебора
- создание ключей с ограниченным сроком действия в расчёте на возможность радикальных изменений в компьютерных технологиях
- ключи сохраняются на USB устройстве для защиты от похищения в случае кражи компьютера или его взлома через сеть
- создание отзывающего сертификата для возможности отзыва ключа в случае, если он будет утрачен или скомпрометирован
- Загрузите последнюю версию
GnuPG с сайта:
gnupg-x.x.x.tar.bz2
Внимание! Убедитесь, что вы используете GnuPG как минимум версии 1.0.6. Все более старые версии GnuPG содержат как минимум одну весьма серьёзную с точки зрения безопасности недоработку.
-
Проверьте криптографическую подпись или как минимум контрольную сумму SHA1.
$ gpg --verify gnupg-x.x.x.tar.bz2.sig gnupg-x.x.x.tar.bz2 $ sha1sum gnupg-x.x.x.tar.bz2
-
Распакуйте архив, настройте параметры сборки, выполните сборку и установите программу.
$ tar xvzf gnupg-x.x.x.tar.bz2 $ cd gnupg-x.x.x $ ./configure $ make $ su
Если компьютером, где вы устанавливаете GnuPG, пользуются и другие люди, имеет смысл установить GnuPG как SUID root - это позволит GnuPG установить защиту сегментов памяти, где хранится секретная информация, от записи на диск в область подкачки. Если вы решите так поступить, обязательно проверьте подлинность архива с помощью SHA1 или электронной подписи, чтобы быть уверенным, что вы не установите троянскую программу.
-
Возьмите USB диск, на котором вы будете хранить ключи, и отформатируйте его.
4a) Смонтируйте USB диск и создайте на нём каталог для вашей ключницы:
# mount /mnt/usbfs
# mkdir /mnt/usbfs/.gnupg
и (если необходимо, в зависимости от параметров монтирования)
# chown <your_uid>:<your_gid> /mnt/usbfs/.gnupg
4b) Создайте символьную ссылку каталога на USB диске в домашний каталог:
$ ln -s /mnt/floppy/.gnupg .gnupg
-
Создайте ключи GnuPG
$ gpg --gen-key
5a) Выберите тип создаваемых ключей - если вы не знаете, что это, выберите ответ по умолчанию.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? <return>
5b) Установите длину ключа равной 4096 бит.
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096<return>
Requested keysize is 4096 bits
5c) Выберите срок действия ключа. Разумный срок - 5 лет.
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y<return>
Key expires at Fri Nov 5 00:19:43 EST 2014
Is this correct (y/n)? y<return>
5d) Введите ваше имя и адрес электронной почты.
Real name: Demo User<return>
Email address: demo@nonexistent.nowhere<return>
Comment:
You selected this USER-ID:
"Demo User <demo@nonexistent.nowhere>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O<return>
5e) Выберите парольную фразу. Парольная фраза является гарантом сохранности ключей, поэтому она должна быть нетривиальной, достаточно длинной. Не забудьте её. Если вы забыли парольную фразу, вы не сможете дешифровать свой закрытый ключ.
5f) Пошевелите мышкой, нажмите несколько случайных клавиш, запустите
перестройку базы locate или find по большому дереву каталогов. Для
создания ключей GnuPG требуется некоторое количество случайных
данных. Для сбора данных GnuPG читает из /dev/random; энтропия данных
в /dev/random увеличивается, среди прочего, за счёт прерываний.
-
Если это необходимо, измените дополнительные параметры ключа. Например, если вы пользуетесь несколькими адресами электронной почты, вы можете присоединить их к своему ключу.
$ gpg --list-secret-keys
sec 4096R/C01BAFC3 2000-09-21 Demo User demo@nonexistent.nowhere ssb 4096R/7A4087F3 2000-09-21 $ gpg --edit-key C01BAFC3 Command> help [...] Command> adduid [...] Command> save
-
Пошлите ваш открытый ключ на сервер ключей:
$ gpg --keyserver --send-key <Your_Key_ID>
Вы должны увидеть подобное сообщение:
gpg: success sending to '<keyserver>' (status=200)
Необходимо отметить, что некоторые полагают, что сохранение их открытого ключа в секрете повышает безопасность коммуникаций. Это в определённом смысле верно, поскольку сервер ключей может работать неправильно или быть взломан и возвращать по запросу неверные открытые ключи. Также может оказаться, что ключ, хранящийся на сервере, неактуален. Например, ключ владельца мог быть подписан новыми людьми, и эти подписи ещё не отправлены на сервер. Это также верно, поскольку для реализации ряда атак на асимметричную систему шифрования атакующему необходим доступ к открытому ключу. Хотя большинство специалистов полагает, что при достаточно большой длине ключа такого рода атаки скорее всего обречены на провал, поэтому распространение открытого ключа безопасно, факт остаётся фактом - хранение открытого ключа в секрете усиливает надёжность пары. Наконец, публикация открытого ключа и его подписей позволяет атакующим создать граф коммуникаций и, хотя это не является атакой на PGP, вы вправе желать сохранить свой социальный граф в тайне.
Тем не менее я не рекомендую хранить ваш открытый ключ в секрете, поскольку это не даёт возможности другим людям пользоваться PGP при отправлении вам электронной почты. Для того чтобы обезопасить себя от проблем с неправильно работающим сервером ключей, возвращающим неверные открытые ключи, вы можете, например, внести отпечаток ключа в файл .signature или разместить его на своей домашней странице. Для решения проблемы атаки на открытый ключ, если он известен, я бы порекомендовал для очень важных сообщений создавать дополнительные ключи (со сроком действия в несколько часов или дней) и обмениваться ими по защищённому каналу.
Итак, если вы не хотите размещать свой открытый ключ на сервере ключей, можете вместо этого послать его координатору встречи, отметив при этом, что вы не хотите, что бы ваш ключ был размещён на сервере. В этом случае координатор может извлечь необходимую информацию и передать ваш ключ другим участникам встречи по защищённому каналу, отметив, что подписанный ключ должен быть передан его владельцу, а не отправлен на сервер ключей.
Это необязательный шаг.
Создание и хранение отзывающего сертификата позволит вам отозвать свой открытый ключ в любой момент, если вы потеряете доступ к закрытому ключу из-за взлома, кражи, забытой парольной фразы или поломки носителя. Если вы хотите иметь возможность отозвать свой открытый ключ, даже если ваш закрытый ключ станет недоступен, вы должны заранее создать отзывающий сертификат и хранить его в безопасном месте. Сертификат можно также распечатать на бумаге на случай, если носитель данных с электронной копией не будет работать.
Если ваш отзывающий сертификат будет похищен, тот, кто его похитил, сможет обеспечить его распространение, тем самым лишая ваш ключ легитимности. Однако похититель не получит доступа к вашему закрытому ключу, даже если он завладел отзывающим сертификатом. Таким образом, он не будет в состоянии подписывать электронные документы от вашего имени, читать зашифрованные для вас сообщения или выдавать себя за вас другим способом. Таким образом, поскольку единственной опасностью, сопряжённой с хранением отзывающего сертификата, может быть потенциальное нарушение действительности пары ключей, имеет смысл создать его заранее.
Раздел 3.9 содержит дополнительную информацию об отзыве ключей.
Команда GnuPG для создания отзывающего сертификата:
$ gpg --output revcert.asc --gen-revoke <key_id>
-
Напишите электронное письмо координатору, уведомите его о том, что вы желаете принять участие во встрече. Пошлите также вывод следующей команды - он содержит всю необходимую информацию, если ваш ключ уже хранится на сервере ключей. Разумеется, ваше письмо координатору может быть зашифровано.
$ gpg --fingerprint <Your_Key_ID>
-
Размонтируйте USB диск и выньте его:
Вы можете всегда носить USB диск с собой или запирать в сейф, ящик стола и т.п. Крайне не рекомендуется хранить ключи в системе, к которой есть доступ через Интернет.
- Придите на встречу.
- Получите копию ключа.
Обычно вы можете получить ключ с сервера ключей. Однако если вы
подписываете ключ, который не доступен с сервера, вы можете включить его
в вашу ключницу командой gpg --import. Если вы работаете с
сервером, добавьте ключ в вашу ключницу командой
$ gpg --keyserver <keyserver> --recv-keys <Key_ID>
Ошибка чтения, скорее всего, означает, что сервер перегружен. Попробуйте ещё раз через несколько минут.
-
Проверьте отпечаток ключа.
$ gpg --fingerprint <Key_ID>
Вывод команды будет содержать отпечаток только что полученного ключа. Сравните выведенный отпечаток с отпечатком на списке участников. Внимание! Не полагайтесь на отпечаток, который показывает сервер ключей - возможно, для загрузки вам будет предложен один ключ, а отпечаток показан от другого.
-
Подпишите ключ.
$ gpg --sign-key <Key_ID>
Если у вас несколько закрытых ключей, вы можете указать, каким из них вы хотите подписать чужой ключ. Это делается так:
$ gpg --default-key <Key_to_use> --sign-key <Key_ID>
Если у вас возникли проблемы с ключами RSA, вероятнее всего, у вас слишком старая версия GnuPG. Версии GnuPG до 1.0.3 не поддерживали RSA. Возможно, вам будет необходимо удалить версию GnuPG, поставляющуюся с дистрибутивом, если вы собираете более новую версию из исходных текстов. Версию GnuPG можно проверить такой командой:
$ gpg --version
- Пошлите подписанный ключ владельцу или отправьте его на сервер ключей.
Если ваш партнёр не хочет, чтобы его ключ находился на сервере ключей, просто перешлите им их ключи назад - например, по электронной почте с шифрованием. Не следует посылать ключ на сервер без разрешения владельца. Как мы отмечали, распространение открытого ключа незначительно снижает общую безопасность пары, поэтому распространение открытых ключей без разрешения их владельца считается дурным тоном.
Однако обычно вы отсылаете ключи на сервер. Это делается так:
$ gpg --keyserver <keyserver> --send-key <Key_ID>
Если публикация прошла успешно, вы получите подобное сообщение:
gpg: success sending to '<keyserver>' (status=200)
Поздравьте себя, процедура подписи завершена, ваша подпись включена в ключ вашего партнёра и отношения доверия установлены.
Если вы подозреваете, что ваш закрытый ключ скомпрометирован, вы должны немедленно отозвать свой открытый ключ. Отзыв ключа состоит в присоединении т.н. подписи отзыва к открытому ключу. Отзыв ключа означает, что ключ больше не действителен и не должен применяться. Отзыв ключа не может быть отменен.
Поскольку ваш ключ передан многим людям, а не помещён в одном центральном хранилище, вы должны позаботиться о распространении отзывающего сертификата таким же образом, как и вашего открытого ключа. Это обычно означает, что отзывающий сертификат должен быть послан на сервер ключей. Даже если вы не посылали свой открытый ключ на сервер ключей из соображений секретности, посылка отзывающего сертификата может, тем не менее, иметь смысл. В этом случае опасность атаки на открытый ключ может быть менее значимой, чем преимущества быстрого оповещения об отзыве ключа.
Для создания отзывающего сертификата используйте следующую команду:
$ gpg --output revcert.asc --gen-revoke <key_id>
Если вы знаете, как и когда произошло нарушение безопасности вашего закрытого ключа, вы можете создать отзывающий сертификат с указанием причины отзыва, что допускается стандартом OpenPGP. В целом более точное указание причины отзыва ключа может оказаться полезнее, чем отзывающий сертификат без указания причины, который создаётся во время создания ключа.
- Ключ - набор данных, являющихся секретом шифрования;
- Отпечаток ключа - в PGP - значение, использующееся для идентификации ключа; представляет из себя хеш ключа;
- Пара ключей - в криптографии с открытым ключом - пара ключей, открытый и закрытый (секретный), связанные друг с другом специальным отношением;
- Ключница (keyring) - набор ключей;
- Сервер ключей - служба, сохраняющая открытые ключи в базе данных; эти ключи могут быть получены пользователями по запросу в случае, если они ещё не вступали в контакт с владельцем ключа;
- Встреча для подписи ключей - собрание людей с целью подписи ключей друг друга; служат развитию сети доверия;
- OpenPGP - открытый стандарт, описывающий работу PGP;
- Pretty Good Privacy [PGP] - программное обеспечение, обеспечивающее шифрование данных, разработанное Филиппом Циммерманом; включает в себя как симметричную криптографию, так и криптографию с открытым ключом;
- Открытый ключ - в криптографии с открытым ключом - один ключ из пары ключей, известный многим коммуникантам;
- Radix - метод кодирования данных для передачи по каналу, поддерживающему только 8-битные символы, например электронной почте или Usenet;
- Закрытый (секретный) ключ - в криптографии с открытым ключом - ключ, известный только владельцу;
- Путь доверия - набор связей, позволяющих установить отношения доверия через несколько промежуточных узлов; в PGP это соединение между двумя открытыми ключами;
- Сеть доверия - набор открытых ключей и подписей, формирующих пути доверия с точки зрения конкретного пользователя.
##5.2 Ссылки на документы по теме
- The Zimmermann-Sassaman Keysigning Party Protocol Definition
- GnuPG FAQ
- GnuPG Handbook
- GnuPG Mini Howto (English)
- comp.security.pgp FAQ
- Strong Distribution HOWTO
- Guerrilla Software Development HOWTO
- PGP Compromise HOWTO
- Cryptography Dictionary
##5.3 Сопутствующие программы
- Gnu Privacy Guard (GnuPG)
- Wotsap Web of trust statistics and pathfinder
- PGP pathfinder & key statistics
- Graphviz - Graph Visualization Software
##5.4 Web-страницы на сопутствующие темы
- Biglumber - Key Signing Coordination
- Keysigning Party Mailing List
- Keysigning Party Mailing List Archive
- OpenPGP Alliance Home Page
- Jason Harris PGP Keysigning Page
- KeyAnalyze Page
- International PGP Home Page
- The Debian keyring graphing page
- Signature Path Tracing page
- CryptNET
##5.5 RFC, имеющие отношение к теме
##5.6 Фотографии со встреч
Gainesville, Florida, USA [1]
San Francisco, California, USA [1]
Isreal [1][2]
Copyright (c) 2000 - 2003 V. Alex Brennen.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation.
This document lives at http://www.cryptnet.net/fdp/crypto/gpg-party.html
Version 1.0.0, 2000.10.01 Initial Release.
Version 1.0.1, 2000.10.03 Format/Writing changes, private public keys info.
Version 1.0.2, 2000.12.07 HTML (Bad Link) Fix.
Version 1.0.3, 2001.01.14 Simplification revisions, graphing, keyserver security/etiquette information, perl code, announcement examples, additional material, and general fixes.
Version 1.0.4, 2001.06.21 Revocation information added: 3.5, 3.7. RFC info added: 4.4. Keyserver list and web site links updated.
Version 1.0.5, 2003.03.24 Glossary Added: 4. Pictures Added: 5.5. Minor corrections, additional material, and formatting changes.
Version 1.0.6, 2003.03.24 New Content: Zimmermann-Sassaman Method, Brennen Method. General document clean-up.
Version 1.0.7, 2003.05.07 Added German Translation
Version 1.0.8, 2003.05.09 Added Section 5.3 Related Programs
Version 1.0.9, 2003.11.20 Added Spanish and Italian Translations
Version 1.1.0, 2003.11.26 Added Traditional Chinese Translation
6.2 Переводы
This document is currently only available in the following languages:
[en] English
[de] German (Local Mirror)
[es] Spanish (Local Mirror)
[it] Italian (Local Mirror)
[zh-TW] Traditional Chinese (Local Mirror)
[sl] Slovenian (Local Mirror)
If you know of a translation or would like to translate it to another language please let me know so that I can distribute or link to the translated versions.
6.3 Люди, принимавшие участие в создании этого документа
V. Alex Brennen (Principal Author)
Darxus (Graphing Code (sig2dot.pl & sigtrace.pl))
Bostjan Muller (Slovenian Translation)
Gerfried Fuchs (German Translation)
Alex Bergonzini (Spanish Translation)
Cristian Rigamonti (Italian Translation)
chihchun clotho fetag Jedi kcwu pwchi winfred (Traditional Chinese Translation)