openPGP в России / Библиотека / Основы и обучение / Сессии заверителей

==Сессии заверителей==

//Встреча заверителей ключей// — это собрание пользователей системы шифрования ((/FAQ/Общие#q1 PGP)) для подписания ключей друг друга. Подобные мероприятия позволяют значительно расширить ((СетьДоверия Сеть доверия)). Кроме того, встречи заверителей предоставляют замечательную возможность обсудить различные общественные и политические проблемы, возникающие в связи с применением стойкой криптографии, вопросы свободы личности, неприкосновенности частной жизни или просто возможность поболтать, а, может быть, даже придумать новые схемы шифрования.

===Описание встречи===

====Что такое подписание ключа?====

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

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

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

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

%%(wacko wrapper=box wrapper_align=right wrapper_width=165) >>(*(file:wot_graph.gif file:wot_graph_tn.png)*) ---**++Рис. 1++**<< %% Термин //"сеть доверия"// используется для описания отношений доверия между несколькими ключами (точнее, их владельцами). Ключи представляют собой узлы несовмещенного графа, а подписи — ребра графа. Эти связи между ключами также называются //путями доверия//, или //путями сертификации//. Доверие может быть как двухсторонним, так и односторонним. В идеальной сети доверия каждый доверяет каждому. Это означает, что каждый уверен, что все остальные ключи принадлежат предполагаемым владельцам. Сеть доверия можно рассматривать как сумму всех путей доверия между всеми владельцами ключей. Возможный пример сети доверия представлен на рис. 1.

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

Допустим, что Анна и Борис создали собственные ключи PGP с помощью своих ((/FAQ/Общие#q2 OpenPGP))-совместимых программ и провели встречу для заверения ключей. На встрече Анна и Борис проверили ключи друг друга и впоследствии подписали их. По умолчанию ((/FAQ/Общие#q1 PGP)) и ((/FAQ/Общие#q2 GnuPG)) автоматически подписывают открытый ключ каждой вновь созданной ключевой пары с помощью соответствующего закрытого ключа. Таким образом, как Анна, так и Борис, оба имеют как минимум две подписи, подтверждающие их владение соответствующим ключом. Ключ Анны подписан самой Анной и Борисом, а ключ Бориса подписан им самим и Анной.

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

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

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

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

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

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

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

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

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

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

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

Если вы собираетесь использовать списки ключей всех участников при проведении встречи, такой список нужно подготовить заранее. Список может выглядить таким образом:
%%001   [ ] Fingerprint OK
pub   1024D/794B784D 2007-12-11
      Key fingerprint = D912 8596 7099 90D4 10FA 5F72 6E61 4EB0 794B 784D
uid                  Vasia Pupkin <vasia@mail.net>%%

Cкрипт для создания списка можно взять ((СессииЗаверителей/СозданиеСписковКлючей тут)).

Каждый участник встречи должен иметь бумажную копию этого списка. Координатор должен сделать список доступным для скачивания через Web или разослать его через список рассылки.

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

%%(wacko wrapper=box wrapper_align=right wrapper_width=165) >>(*(file:pgp_signing_party1.jpg file:pgp_signing_party1_tn.jpg)*) ---**++Рис. 2++**<< --- >>(*(file:pgp_signing_party2.jpg file:pgp_signing_party2_tn1.jpg)*) ---**++Рис. 3++**<<%% Существуют две основные стратегии проведения сессии заверителей: централизованная и децентрализованная процедура. Выбор оптимального способа зависит от числа участников и места проведения встречи. Основным требованием к организации встречи является возможность участникам проверить ключи друг друга и убедиться в том, что другие участники — те, за кого они себя выдают. Координатор может комбинировать обе эти стратегии.

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

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

Движение шеренг при чётном количестве участников (n):
Участник с номером 1 (в списке) становится напротив участника с номером n;
Участник с номером 2 (в списке) становится напротив участника с номером (n-1) и т.д.
При такой расстановке происходит первая проверка личностей между соответствующими парами.
#||
*|1|2|3|...|n/2-2|n/2-1|n/2|*
*|n|n-1|n-2|...|n/2+3|n/2+2|n/2+1|*
||#
Далее происходит сдвиг на одного участника и вторая проверка. 1-й и (n/2+1)-й участники ждут.
#||
*|1|2|3|...|n/2-1|n/2|-|*
*|-|n|n-1|...|n/2+3|n/2+2|n/2+1|*
||#
1-й и (n/2+1) участник меняют шеренги. Снова происходит сдвиг на одного участника и третья проверка.
#||
*|2|3|4|...|n/2-1|n/2|n/2+1|*
*|1|n|n-1|...|n/2+4|n/2+3|n/2+2|*
||#
Такое движение будет происходить на протяжении n проверок. В результате получается, что:
1-й участник сверяется с (n)-м, ждёт, (2)-м, ..., (n-1)-м;
2-й участник сверяется с (n-1)-м, (n)-м, (1)-м, ждёт, (3)-м, ..., (n-2)-м и т.д.

Движение шеренг при нечётном количестве участников аналогично:
#||
*|-|1|2|...|(n-1)/2-2|(n-1)/2-1|(n-1)/2|*
*|n|n-1|n-2|...|(n+1)/2+2|(n+1)/2+1|(n+1)/2|*
||#

#||
*|1|2|3|...|(n-1)/2-1|(n-1)/2|-|*
*|n|n-1|n-2|...|(n+1)/2+2|(n+1)/2+1|(n+1)/2|*
||#
и т.д.

%%(nb)Если вы решили __не подписывать__ какой-либо ключ или идентификатор, то ставьте соответствующую отметку, чтобы навернека исключить это.%%

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

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

%%(nb)На сесии заверителей вы проверили только два идентификатора (фото и личность), все остальные идентификаторы проверяются иначе.%%

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

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

В качестве подобной схемы может выступать //((/Сервисы/Keyserver групповая матрица сертификации))//. Это простая двумерная матрица, где в столбцах отложены ключи, создающие подпись, а в рядах — ключи, на которых создают подпись (заверяемые ключи). Ячейки могут либо содержать отметку с типом подтверждающей подписи, либо быть пусты, что означает отсутствие подписи на ключе из ряда от ключа из столбца.

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

===Проведение встречи===

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

1. Создать пару ключей.
  2. Отправить открытый ключ на сервер ключей (или координатору).
  3. Получить список, сформированый и подписаный координатором.
  4. Проверить информацию о себе и посчитать хэш-значение SHA1(или другое, указаное координотором) списка. Если список приведён в формате gpg, то можно воспользоваться программой gpgsigs((*)). Вывод файла с фотографиями (файл должен быть написан только на латинице) %%gpgsigs --latex <ID_ключа> <файл_списка> | latex%% Вывод файла без фотографий (любая кодировка) %%gpgsigs -f <кодировка файла> -t UTF-8 <ID_ключа> <файл_списка> > <файл_для_распечатки>%% Данная команда посчитает хэш-значение и обозначит уже подписанные вами идентификаторы.
  5. Лично прийти на встречу.
  6. Проверить достоверность списка (хэш-значение).
  7. Проверить личности участников, чьи ключи хотите подписать.
  8. Подписать ключи других участников.
  9. Отправить подписанные ключи владельцам ключей.

====Что нужно взять с собой на встречу====

1. Себя.
  2. Два удостоверения личности с фото (паспорт, водительские права, студенческий билет, воинское удостоверение и т.п.).
  3. Для децентрализированой встречи: ID своего ключа, его тип, отпечаток и размер. Эту информацию можно напечатать на бумаге((*)).%%gpg-key2ps -p A4 <ID_ключа> > <ID_ключа>.ps%%
  4. Для централизированой встречи: копию списка участников и его хэш-значение.
  5. Ручку.

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

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

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

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

===Заверение ключей===

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

Обычно, вы можете получить ключ с сервера ключей. Однако, если вы подписываете ключ, который не доступен с сервера, то можете импортировать его из файла на свою связку ключей командой: 
  %%gpg --import <файл_ключа>%% 
  Если вы работаете с сервером, то импортировать ключ на связку можно командой:
  %%gpg --keyserver <сервер_ключей> --recv-keys <ID_ключа>%%
  Пользователи PGP для аналогичных целей могут воспользоваться средствами менеджера PGPkeys.

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

%%gpg --fingerprint <ID_ключа>%%
  Вывод команды будет содержать отпечаток только что полученного ключа. Сравните отпечаток, полученный в ответ на команду, с отпечатком в списке участников.

%%(nb)Не полагайтесь на отпечаток, который показывает сервер ключей — возможно, что для загрузки вам будет предоставлен один ключ, а отпечаток будет показан от другого.%%

3. //Подпишите ключ и __сделайте проверку оставшихся идентификаторов__.//

На сессии заверителей была проведена проверка двух идентификаторов (фото и личность), но на связке ключей обычно присуствуют один или несколько почтовых ящиков, jabber и т.д. Владение этими идентификаторами необходимо проверить. Проверка электронных контактов сводится к следующему алгоритму:
     a) подпись идентификатора (только одного).
     b) шифрование подписи ключём владельца.
     c) отправка результата по адресу этого идентификатора.
  Если человек получил сообщение и расшифровал его, значит он действительно имеет доступ к этому контакту.
  
  %%(nb)Подписывайте идентификаторы, все компоненты которого могут быть проверены (имя, адрес, комментарий).%%

Подписать и зашифровать отдельный идентификатор можно следующим образом (пункты "a" и "b"):
  %%gpg --default-key <ключ_подписи> --edit-key <ID_ключа>
  Command> <номер идентификатора>
  Command> sign
  Really sign? (y/N) y
  Command> save
gpg --export -a <ID_ключа> | gpg -ear <ID_ключа> > <ID_ключа>.asc%%
  Отправляем полученый файл (<ID_ключа>.asc) по указаному в адресу (e-mail, jabber и т.д.), тем самым исполняя пункт "c".
  
  Теперь необходимо удалить свою подпись, т.к. она может быть отослана с подписью следующего идентификатора или случайно опубликована в сети. В любом случае идентификатор не получит необходимой проверки.
  %%gpg --edit-key <ID_ключа>
  Command> <номер идентификатора>
  Command> delsig
  (будет предложено удаление для кажной подписи и самоподписи по порядку, удаляем свою)
  Delete this good signature? (y/N/q)y
  Command> save%%
  
  Процедуру проверки необходимо провести для всех идентификаторов, которые вы хотите подписать.

Если на ключе только один идентификатор, его можно подписать так:
  %%gpg --default-key <ключ_подписи> --sign-key <ID_ключа>%%

Для автоматизации проверки почтовых адресов существует программа caff((**)).
  %%caff -R -m ask-yes -u <ключ_подписи> <ID_ключа>
  Really sign all user IDs? (y/N) N
  Command> <номер идентификатора (эл. почтовый ящик)>
  Command> <номер идентификатора (второй эл. почтовый ящик и т.д.)>
  Command> sign
  Really sign? (y/N) y
  Command> save
 Mail signature for <идентификатор> to '<почтовый ящик>'? [Y/n] y (для каждого ящика)%%

??//[[/Проект/ToDo ToDo]]:// Добавить скрипт для проверки jabber.??

4. //Загрузка открытого ключа на сервер ключей//

Публиковать подписаный вами ключ на сервере нельзя по двум причинам:
     a) Идентификаторы ключа не проходят достаточной проверки.
     b) Распространение открытого ключа, без разрешения владельца, незначительно снижает общую безопасность пары, поэтому считается дурным тоном.
     !!Примечание: публикация ключа на сервере возможна при согласии владельца в ситуации, когда __на ключе имеются только идентификаторы личности и фото__ (т.к. вы проверили их на сессии заверителей). Отсуствие почтовых адресов или других контактов маловероятно, поэтому вам врядли придётся загружать на сервер чужие открытые ключи.!!

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

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

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

Для публикации __своего открытого ключа__ или обновления подписей используйте следующую команду:
  %%gpg --keyserver <сервер_ключей> --send-key <ID_своего_ключа>%%
  В случае, если публикация прошла успешно, вы получите подобное сообщение:
  %%gpg: success sending to '<сервер_ключей>' (status=200)%%

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

((#*))Программы gpg-key2ps, gpgsigs входят в пакет signing-party (Debian GNU/Linux). Для формирования списка с фотографиями необходим пакет imagemagick (Debian GNU/Linux).
((#**))Программа caff входит в пакет signing-party (Debian GNU/Linux), но для её успешной работы должен быть запущен почтовый сервис или установлен пакет sendmail. Для создания файлов конфигурации первый запуск сделайте без параметров.

Ваше имя:
	Запомнить псевдоним (сохранить в cookie)
	OpenPGP-подписанный текст в кодировке Помощь
	Сохранить параметры OpenPGP в cookie

Для корректной работы разрешите в своем браузере показ изображений.

Пожалуйста, напишите, кого/что вы видите
на изображенной слева картинке. Если
там несколько персонажей/предметов,
перечислите их в именительном падеже
через пробел (одинаковых приводите во
множественном числе).

(осталось попыток на решение теста: 3)

Поддержка BBCode включена