> Linux Reviews > Howtos > GnuPG Privacy Howtos >

Как проводить встречи для подписи ключей GnuPG

Этот документ описывает организацию и проведение встречи для подписи ключей PGP с использованием реализации GNU, GnuPG. Он так же объясняет процесс подписи ключей, дает ответы на часто задаваемые вопросы и поясняет, как создать собственную пару ключей и как подписывать ключи других людей.

Как проводить встречи для подписи ключей GnuPG

V. Alex Brennen (vab@cryptnet.net)

Перевод на русский: Vladimir Ivanov (ivlad@unixgods.net)

v1.1.0, 26 November 2003


Этот документ описывает организацию и проведение встречи для подписи ключей PGP с использованием реализации GNU, GnuPG. Он так же объясняет процесс подписи ключей, дает ответы на часто задаваемые вопросы и поясняет, как создать собственную пару ключей и как подписывать ключи других людей.

1. Описание встречи

2. Организация встречи

3. Посещение встречи

4. Список терминов

5. Ссылки на источники дополнительной информации

6. Об этом документе


1. Описание встречи

1.1 Что такое "встреча для подписи ключей?"

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

1.2 Что такое "подпись ключей"?

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

Можно подписывать как собственные открытые ключи, так и открытые ключ и идентификаторы других пользователей.

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

1.3 Что такое сеть доверия?

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

1.4 Пример применения подписей ключей

Пусть, например, Алиса и Борис каждый создали ключи PGP с помощью GPG и провели встречу для подписи ключей. На встрече Алиса и Борис проверили ключи друг друга и впоследствии подписали их. По умолчанию GPG автоматически подписывает открытый ключ каждой вновь созданной пары с помощью соответствующего личного ключа. Таким образом, как Алиса так и Борис, оба имеют как минимум две подписи, подтверждающие их владение соответствующим ключом. Ключ Алисы подписан самой Алисой и Борисом, а ключ Бориса подписан им самим и Алисой.

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

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

Этот пример очень упрощен и в реальной ситуации процесс может выглядеть намного сложнее. Прочтите список ответов на частые вопросы о PGP или какую-нибудь хорошую книгу о PKI - наверняка вы найдете более подробное объяснение и много дополнительной информации. Рассмотренный пример, однако, наглядно показывает принципы и необходимость подписи ключей. Виктории не удалось заставить Бориса использовать поддельную пару ключей для Алисы, поскольку между Алисой и Борисом уже установлен путь доверия.

Однако, наличие подписей и сетей доверия не всегда обеспечивает возможность проверки ключей. Пусть, например, Алиса и Борис впервые познакомились и Викторией в присутствии Дмитрия, знакомого Виктории. Дмитрий может создать поддельные ключи для Алисы и Бориса, подписать их своим ключом, и поддельными ключами Алисы и Бориса. В этом случае он получит три подписи на каждом из поддельных ключей, которые он пошлет Виктории. Настоящие ключи Алисы и Бориса подписаны только их личными ключами; они так же посланы Виктории. Каким образом Виктория может противостоять такой атаке? Пусть, например, весь обмен ключами происходит через сервер ключей. Виктория находит по две копии ключей для Алисы и Бориса. Однако, если ключи Бориса и Алисы подписаны двадцатью участниками во время встречи для подписи ключей. очевидно, что Виктории следует доверять открытым ключам, подписанным 20 раз а не тем, которые подписаны всего 3 раза. В любом случае, уже сам факт существования двух наборов подписей должен насторожить Викторию - в этом случае, она может более тщательно проверить сеть доверия наборов, даты создания и т.п. 20 ключей, использовавшихся во время встречи для подписи ключей сами должны быть подписаны не менее 20 раз, иметь различные даты создания, развитые сети доверия. Этого не случится в том случае, даже если Дмитрий создаст поддельную сеть доверия из 20 ключей.

1.5 Зачем мне проводить встречи для подписи ключей?

Есть три основных причины для проведения встреч для подписей ключей как можно чаще.

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

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

Наконец, такие встречи позволяют расширять сообщество. Они позволяют людям ближе познакомиться друг с другом, общаться на интересующие их темы, как то гражданские свободы, права использовать шифрование, управление Internet. Обсуждения важны, поскольку обсуждение - не только первый шаг но и побуждение к действию. Сейчас, когда я пишу этот документ, в мире не так много больших сетей доверия. Если вы собираетесь создать сеть доверия в круге вашего общения, скорее всего, первыми участниками будут лидеры, организаторы и активные участники сообщества Internet вокруг вас. Они могли бы взять на себя внедрение защищенных коммуникаций в сложившуюся сетевую инфраструктуру. Внедрение такой технологии и протоколов может предотвратить угрозы безопасности частной жизни, связанные с внедрением ФБР системы Carnivore (а МВД - СОРМ).


2. Организация встречи

2.1 Задачи координатора

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

2.2 Как проводить встречу?

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

Централизованный способ проведения встречи позволяет провести подпись ключей более организованно и подходит для встреч с относительно небольшим числом участников. Участниуки заранее посылают информацию о их ключах координатору, который составляет список участников. По прибытию, каждый участник получает копию списка ключей. Затем, каждый участник по очереди вызывается координатором. Каждый участник проверяет правильность отпечатка своего ключа в списке ключей, распространяемый координатором. Если участник уверен, что его информация внесена в список верно, он оглашает отпечаток своего ключа так, что бы другие участники могли его слышать и проверить правильность отпечатка. Если отпечаток верен, участники отмечают это в своих списках. Эта проверка необходима для защиты от ошибки координатора при создании списка или от намеренного искажения информации в списке. После того, как каждый учстник убедился в правильности ключа, координатор вызывает следующего участника и так далее. После того, как правильность всех ключей проверена, все участники, включая координатора, выстраиваются в ряд, держа свои удостоверения личности перед собой. Участник в начале шеренги проходит всю шеренгу и проверяет удостоверения личности всех остальных участников. Если участник удолетворен результатами проверки удостоверения личности, он так же убеждается, что отпечаток ключа верен. Если это так, проверяющий участник ставит вторую отметку в списке. После того, как ключ прошел две проверки, он может быть подписан.

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

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

2.3 Объявление о встрече

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

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

Вот примеры объявлений о проведении встречи:

2.4 Создание списков ключей

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

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 или разослать его через список рассылки, что бы каждый участник мог распечатать список самостоятельно.

2.5 Построение получившейся сети доверия

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

Построить графическую схему сети доверия очень легко. Необходимо перевести описание сети в файл формата dot, который затем может быть использован программами dot или neato. Скрипт на perl, создающий файл в формате dot на основе ключей и подписей в кольце ключей, написан Darxus и так же доступен на основании лицензии GPL. Что бы построить графическую схему сети доверия, необходим скрипт Darxus sig2dot.pl и пакет graphviz от AT&T Research. С построениями схем сетей, состоящих из нескольких сотен узлов, могут возникнуть трудности из-за нехватки памяти.

Указания по построению графической схемы сети доверия включены в скрипт sig2dot.pl, а так же их можно найти на странице кольца ключей Debian. Здесь расположен пример схемы сети доверия, созданный с помощью sig2dot.pl и neato. Дополнительную информацию можно найти на странице построения схемы кольца ключей Debian.


3. Посещение встречи

3.1 Задачи участника

  1. Создать пару ключей
  2. Послать открытый ключ серверу ключей (или координатору)
  3. Послать координатору информацию для внесения в список
  4. Лично придти на встречу
  5. Проверить информацию в списке
  6. Проверить информацию о ключах других участников
  7. Проверить личность участников, чьи ключи вы хотите подписать
  8. Подписать ключи других участников
  9. Послать подписанные ключи серверу ключей (или владельцу ключа)

3.2 Что нужно принести с собой на встречу

  1. Необходимо явиться лично
  2. Два удостоверения личности с фото (паспорт, водительские права, студенческий билет, воинское удостоверение и т.д.)
  3. ID ключа, тип ключа, отпечаток ключа и его размер или копию списка участников
  4. Ручку или карандаш

3.3 Что не нужно приносить с собой

  1. Компьютер

3.4 Почему не нужно брать с собой компьютер

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

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

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

3.5 Создание собственной пары ключей

Создать собственную пару ключей очень просто. Нужно всего лишь запустить gpg --gen-key. Однако я советую так же создать отзывающий сертификат для созданного ключа на случай, если доступ к секретному ключу будет невозможен (нампример, вы забыли ключевую фразу или потеряли личный ключ). Процедура создания отзывающего сертификата описана в разделе 3.7 этого документа.

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

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

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

1) Загрузите последнюю версию gpg сайта www.gnupg.org: gnupg-x.x.x.tar.gz

Внимание! Убедитесь, что вы используете GnuPG как минимум версии 1.0.6. Все версии более старые версии GnuPG содержат как минимум одну, весьма серьезную с точки зрения безопасности, недоработку.

2) Проверьте криптографическую сигнатуру или, как минимум, контрольную сумму MD5.

bash$ gpg --verify gnupg-x.x.x.tar.gz.sig gnupg-x.x.x.tar.gz 
bash$ md5sum gnupg-x.x.x.tar.gz 

3) Распакуйте архив, настройте параметры сборки, выполните сборку и установите программу.

bash$ tar xvzf gnupg-x.x.x.tar.gz 
bash$ cd gnupg-x.x.x 
bash$ ./configure 
bash$ make 
bash$ su 
bash# make install 
bash# exit 
bash$ cd

Если компьютером, где вы устанавливаете GnuPG, так же пользуются другие люди, имеет смысл установить gpg как SUID root - это позволит gpg установить защиту сегментов памяти, где хранится секретная информация, от записи на диск в область подкачки. Если вы решите так поступить, обязательно проверьте подлинность архива с помощью MD5 или электронной подписи, что бы быть уверенным, что вы не установите троянскую программу.

4) Возьмите дискету, на которой вы будете хранить ключи и отформатируйте ее.

bash$ /sbin/mkfs.ext2 /dev/fd0 

4a) Смонтируйте дискету и создайте на ней каталог для ваших ключей:

bash$ mount /mnt/floppy 
bash$ mkdir /mnt/floppy/.gnupg 

и, если необходимо (в зависимости от параметров монрирования

bash$ chown <your_uid>:<your_gid> /mnt/floppy/.gnupg 

4b) Создайте символьный линк каталога на дискете в домашний каталог:

bash$ ln -s /mnt/floppy/.gnupg .gnupg

5) Создайте ключи GnuPG

bash$ gpg --gen-key

5a) Выберете тип создаваемых ключей - если вы не знаете, что это выберите ответ по умолчанию.

Please select what kind of key you want: 
(1) DSA and ElGamal (default) 
(2) DSA (sign only) 
(4) ElGamal (sign and encrypt) 
Your selection? <return>

5b) Установите длину ключа равной 2048 бит.

DSA keypair will have 1024 bits. 
About to generate a new ELG-E keypair. 
minimum keysize is 768 bits 
default keysize is 1024 bits 
highest suggested keysize is 2048 bits 
What keysize do you want? (1024) 2048<return> 
Do you really need such a large keysize?  yes<return>

Выберите срок действия ключа. Разумный срок - 5 лет.

Requested keysize is 2048 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) 5y<return> 
Key expires at Sun Sep 21 16:17:15 2005 EDT 
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 по большому дереву каталогов. Для создания ключей, gpg требуется некоторое количество случайных данных. Для сбора данных gpg читает из /dev/random; энтропия данных в /dev/random увеличивается, среди прочего, за счет прерываний.

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

bash$ gpg --list-secret-keys 

/home/demo/.gnupg/secring.gpg
---------------------------- 
sec 1024D/C01BAFC3 2000-09-21 Demo User <demo@nonexistent.nowhere> 
ssb 2048g/7A4087F3 2000-09-21
bash$ gpg --edit-key C01BAFC3 
Command> help 
[...] 
Command> adduid 
[...] 
Command> save 

7) Пошлите ваш открытый ключ на сервер ключей:

bash$ gpg --keyserver <keyserver> --send-key <Your_Key_ID>

Вы должны увидеть подобное сообщение:

gpg: success sending to `<keyserver>' (status=200)

3.6 Пересылка открытого ключа на сервер ключей

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

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

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

3.7 Создание отзывающего сертификата

Это необязательный шаг.

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

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

Раздел 3.9 содержит дополнительнуь информацию об отзыве ключей.

Команда GnuPG для создания отзывающего сертификата:

bash$ gpg --output revcert.asc --gen-revoke <key_id>

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

bash$ gpg --fingerprint <Your_Key_ID>

10) Размонтируйте дискету и выньте ее из дисковода:

bash$ umount /mnt/floppy

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

11) Придите на встречу.

3.8 Подпись других ключей

1) Получите копию ключа.

Обычно, вы можете получить ключ с сервера ключей. Однако, если вы подписываете ключ, который не доступен с сервера, вы можете включить его в ваше кольцо ключей командой gpg --import. Если вы работаете с сервером, включите ключ в ваше кольцо ключей командой

bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>

Ошибка чтения, скорее всего, означает, что сервер перегружен. Попробуйте еще раз через несколько минут.

2) Проверьте отпечаток ключа.

bash$ gpg --fingerprint <Key_ID>

Вывод команды будет содержать отпечаток только что полученного ключа. Сравните отпечаток, полученный в результате команды с отпечатком на списке участников. Внимание! Не полагайтесь на отпечаток, который показывает сервер ключей - возможно, что для загрузки вам будет предоставлен один ключ а отпечаток будет показан от другого.

3) Подпишите ключ.

bash$ gpg --sign-key <Key_ID>

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

bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID>

Если у вас возникли проблемы с ключами RSA, вероятнее всего, у вас слишком старая версия GnuPG. Версии GnuPG до 1.0.3 не включали в себя поддержку RSA. Обратите внимание, что возможно вам необходимо деинсталлировать версию GnuPG, поставляющуюся в комплекте с дистрибутивом, если вы собираете более новую версию из исходных текстов. Версию GnuPG можно проверить такой командой:

bash$ gpg --version

4) Пошлите подписанный ключ владельцу или отправьте его на сервер ключей.

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

Однако, обычно отсылаете ключи на сервер. Это делается так:

bash$ gpg --keyserver <keyserver> --send-key <Key_ID>

В случае, если публикация прошла успешно, вы получите подобное сообщение:

gpg: success sending to `<keyserver>' (status=200)

Поздравьте себя, процедура подписи завершена, ваша подпись включена в ключ вашего партнера и отношения доверия установлены.

3.9 Отзыв собственной пары ключей

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

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

Для создания отзывающего сертификата, используйте следующую команду:

bash$ gpg --output revcert.asc --gen-revoke <key_id>

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


4. Список терминов

Ключ - набор данных, являющихся секретом шифрования;

Отпечаток ключа - в PGP, значение, использующееся для идентификации ключа, представляет из себя хеш ключа;

Пара ключей - В криптографии с открытым ключем, пара - открытый и личный (секретный) ключ, связанных друг с другом специальным отношением;

Кольцо ключей - набор ключей;

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

Встреча для подписи ключей - собрание людей с целью подписи ключей друг друга; служат развитию сети доверия.

openPGP - открытый стандарт, описывающий работу PGP

Pretty Good Privacy [PGP] - программное обеспечение, обеспечивающее шифрование данных, разработанное Филом Циммерманом, включает в себя как симметричную крипрографию, так и криптографию с открытым ключом;

Открытый ключ - в криптографии с открытым ключом, один ключ из пары ключей, известный многим коммуникантам;

Radix - метод кодирования данных для передачи по каналу, поддерживающему только 8-битные символы, например электронной почте или Usenet;

Личный (секретный) ключ - в криптонграфии с открытым ключом, ключ, известный только владельцу;

Путь доверия - набор связей, позволяющих установить отношения доверия через несколько промежуточных узлов; в PGP это соединение между двумя открытыми ключами;

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


5. Ссылки на источники дополнительной информации

5.1 Список общественных серверов ключей

  1. CryptNET Keyserver Network
    1. gnv.keyserver.cryptnet.net
  2. pgp.net
    1. wwwkeys.us.pgp.net
    2. wwwkeys.nl.pgp.net
    3. wwwkeys.ch.pgp.net
    4. wwwkeys.uk.pgp.net
    5. wwwkeys.cz.pgp.net
    6. wwwkeys.de.pgp.net
    7. wwwkeys.dk.pgp.net
    8. wwwkeys.es.pgp.net
  3. http://www.keyserver.net/
    1. search.keyserver.net
    2. seattle.keyserver.net
    3. germany.keyserver.net
    4. belgium.keyserver.net
    5. finland.keyserver.net
    6. thailand.keyserver.net
  4. pgp.ai.mit.edu
  5. pgp.cc.gatech.edu
  6. pgp.es.net
  7. pgp.rediris.es
  8. pgp.uk.demon.net
  9. pgp.uni-mainz.de
  10. pgp.nic.ad.jp
  11. ds.carnet.hr

5.2 Ссылки на документы по теме

5.3 # Сопутствующие программы

5.4 Web-страницы на сопутствующие темы

5.5 RFC, имеющие отношение к теме

5.6 Фотографии со встреч

  • Gainesville, Florida, USA [1]
  • San Francisco, California, USA [1]
  • Isreal [1][2]

6. Об этом документе

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

6.1 Версии

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)

[si] 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)


CryptNET

SVENSKA - SVENSKA - SVENSKA - SVENSKA