Перенести русскоязычный документ о PGP keysigning party

[cypherpunks-www.git] / ksp / attending.texi

@node KSP attending
@section Посещение встречи

@strong{Задачи участника}

@itemize
@item Создать пару ключей
@item Послать открытый ключ на сервер ключей (или координатору)
@item Послать координатору информацию для внесения в список
@item Лично прийти на встречу
@item Проверить информацию в списке
@item Проверить информацию о ключах других участников
@item Проверить личность участников, чьи ключи вы хотите подписать
@item Подписать ключи других участников
@item Послать подписанные ключи на сервер ключей (или владельцу ключа)
@end itemize

@strong{Что нужно принести с собой на встречу}

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

@strong{Что не нужно приносить с собой}

@itemize
@item Компьютер
@end itemize

@strong{Почему не нужно брать с собой компьютер}

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

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

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

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

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

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

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

@itemize
@item создание ключей максимально возможной длины для усложнения атак
    перебора
@item создание ключей с ограниченным сроком действия в расчёте на
  возможность радикальных изменений в компьютерных технологиях
@item ключи сохраняются на USB устройстве для защиты от похищения в случае
  кражи компьютера или его взлома через сеть
@item создание отзывающего сертификата для возможности отзыва ключа
  в случае, если он будет утрачен или скомпрометирован
@end itemize

@enumerate

@item
Загрузите последнюю версию
@url{https://www.gnupg.org/download/index.html, GnuPG с сайта}:
@code{gnupg-x.x.x.tar.bz2}

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

@item
Проверьте криптографическую подпись или как минимум контрольную сумму SHA1.

@verbatim
$ gpg --verify gnupg-x.x.x.tar.bz2.sig gnupg-x.x.x.tar.bz2
$ sha1sum gnupg-x.x.x.tar.bz2
@end verbatim

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

@verbatim
$ tar xvzf gnupg-x.x.x.tar.bz2
$ cd gnupg-x.x.x
$ ./configure
$ make
$ su
# make install
# exit
@end verbatim

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

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

@verbatim
# /sbin/mkfs.ext2 /dev/sda1
@end verbatim

@item
Смонтируйте USB диск и создайте на нём каталог для вашей ключницы:

@verbatim
# mount /mnt/usbfs
# mkdir /mnt/usbfs/.gnupg
@end verbatim

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

@verbatim
# chown <your_uid>:<your_gid> /mnt/usbfs/.gnupg
@end verbatim

@item
Создайте символьную ссылку каталога на USB диске в домашний каталог:

@verbatim
$ ln -s /mnt/floppy/.gnupg .gnupg
@end verbatim

@item Создайте ключи GnuPG

@verbatim
$ gpg --gen-key
@end verbatim

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

@verbatim
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>
@end verbatim

@item
Установите длину ключа равной 4096 бит.

@verbatim
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096<return>
Requested keysize is 4096 bits
@end verbatim

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

@verbatim
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>
@end verbatim

@item
Введите ваше имя и адрес электронной почты.

@verbatim
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>
@end verbatim

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

@item
Пошевелите мышкой, нажмите несколько случайных клавиш, запустите
перестройку базы locate или find по большому дереву каталогов. Для
создания ключей GnuPG требуется некоторое количество случайных данных.
Для сбора данных GnuPG читает из @code{/dev/random}; энтропия данных в
@code{/dev/random} увеличивается, среди прочего, за счёт прерываний.

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

@verbatim
$ gpg --list-secret-keys

/home/demo/.gnupg/secring.gpg
----------------------------
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
@end verbatim

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

@verbatim
$ gpg --keyserver <keyserver> --send-key <Your_Key_ID>
@end verbatim

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

@verbatim
    gpg: success sending to '<keyserver>' (status=200)
@end verbatim

@end enumerate

@strong{Пересылка открытого ключа на сервер ключей}

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

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

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

@anchor{KSP revcert}
@strong{Создание отзывающего сертификата}

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

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

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

@ref{KSP own keypair revocation, Раздел содержит} дополнительную
информацию об отзыве ключей.

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

@verbatim
$ gpg --output revcert.asc --gen-revoke <key_id>
@end verbatim

@enumerate 16

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

@verbatim
$ gpg --fingerprint <Your_Key_ID>
@end verbatim

@item
Размонтируйте USB диск и выньте его:

@verbatim
# umount /mnt/usbfs
@end verbatim

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

@item Придите на встречу.

@end enumerate

@strong{Подпись других ключей}

@enumerate

@item Получите копию ключа.

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

@verbatim
$ gpg --keyserver <keyserver> --recv-keys <Key_ID>
@end verbatim

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

@item Проверьте отпечаток ключа.

@verbatim
$ gpg --fingerprint <Key_ID>
@end verbatim

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

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

@item Подпишите ключ.

@verbatim
$ gpg --sign-key <Key_ID>
@end verbatim

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

@verbatim
$ gpg --default-key <Key_to_use> --sign-key <Key_ID>
@end verbatim

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

Версию GnuPG можно проверить такой командой:

@verbatim
$ gpg --version
@end verbatim

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

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

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

@verbatim
$ gpg --keyserver <keyserver> --send-key <Key_ID>
@end verbatim

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

@verbatim
gpg: success sending to '<keyserver>' (status=200)
@end verbatim

@end enumerate

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

@anchor{KSP own keypair revocation}
@strong{Отзыв собственной пары ключей}

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

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

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

@verbatim
$ gpg --output revcert.asc --gen-revoke <key_id>
@end verbatim

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