Нил Стивенсон, "Криптономикон": <blockquote>  — Терпеть не могу электронную почту, — говорит Джон. — Идея хороша. Исполнение дурно. Люди не соблюдают элементарных предосторожностей. Когда приходит письмо якобы от Гарварда Ли, они думают, что оно и впрямь от Гарварда Ли. Однако это письмо — всего лишь последовательность намагниченных секторов на вращающемся диске. Кто угодно может его подделать. </blockquote><habracut /> <h4>I. Теория</h4> Криптография умеет много гитик, но главные из них две: сокрытие информации и проверка подлинности. Симметричные криптосистемы в этих смыслах не очень удобны, потому что критическая часть информации — ключ — должен быть передан защищённым способом.

Несмотря на то, что классическое применение криптографии состоит в сокрытии информации, я считаю более распространённым случай установления подлинности оригинального сообщения. В описании модельных случаев принято обозначать легитимных участников коммуникации Алисой и Бобом (удобно обозначать их коротко первыми буквами алфавита), а активного злодея — Труди (созвучно с "intruder").

Например, в симметричном случае Алиса и Боб договариваются о секретном ключе <b>S</b>. Алиса пишет своё сообщение <b>О</b>, отдельно его шифрует ключом <b>S</b>, получая подпись <b>Sig(S, O)</b>. Далее она может отправить пару <b>(O, Sig(S, O))</b> Бобу, а тот, обладая ключом <b>S</b>, может определить, было ли изменено сообщение, проделав то же преобразование, и получив ту же подпись. Но если Труди известен ключ <b>S</b>, то он может перехватить пару <b>(O, Sig(S, O))</b>, модифицировать сообщение в <b>O*</b>, сгенерировать <b>Sig(S, O*)</b>, и отправить <b>(O*, Sig(S, O*))</b> Бобу. Боб в таком случае примет <b>О*</b> за легитимный <b>О</b>.

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

То есть, в асимметричном случае Алиса генерирует пару ключей <b>(P, S)</b>, и отправляет <b>P</b> Бобу. Алиса пишет сообщение <b>O</b>, отдельно шифрует его ключом <b>S</b>, получая подпись <b>Sig(S, O)</b>, и отправляет пару <b>(O, Sig(S, O))</b>. Боб может расшифровать <b>Sig(S, O)</b> при помощи известного <b>P</b>, и если получилось <b>О</b>, то можно говорить, что сообщение действительно сгенерировано Алисой, обладающей <b>S</b>. На деле в подписях используется не само <b>O</b>, а его хэш, что не изменяет сути происходящего, но сильно уменьшает размер подписи.

Казалось бы, все счастливы. Но в теории (и практике) Труди может перехватить первую коммуникацию Алисы и Боба, и предоставить Бобу фальшивый <b>P*</b>. Затем Труди перехватывает <b>(O, Sig(S, O))</b>, модифицирует текст <b>O*</b>, генерирует <b>(O*, Sig(S*, O*))</b>, и отправляет его Бобу. Боб таким образом удостоверяется, что <b>O*</b> сгенерировано человеком, обладающим <b>S*</b>, но Боб не знает, что это <i>не Алиса, а Труди!</i> То есть, срабатывает классический man-in-the-middle.

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

<h4>II. Public Key Infrastructure</h4> Продолжая наш пример, Алиса и Боб могут обменяться ключами по гарантированно надёжному каналу. Надёжность канала обмена публичными ключами в итоге определяет надёжность асимметричной криптосистемы. Поэтому, например, со стороны Боба было бы глупо присылать Алисе электронное письмо с текстом "Алиса, это Самый Настоящий Боб, вот мой ключ!", или публиковать в своём бложике (есть гарантия, что Труди не хакнула ЖЖ Боба?), в соцсетях или форумах. Вообще говоря, глупо обмениваться ключами через каналы, безопасность которых должны быть обеспечена обмениваемым ключом!

Ситуация осложняется ещё и тем, что даже после передачи ключа Труди может вломиться на комп Боба и перезаписать ключ Алисы на свой фальшивый. Поэтому Бобу нужно иметь способ удостовериться, что он до сих пор обладает настоящим публичным ключом Алисы. Один из простых способов в этом убедиться состоит в том, что Боб может <i>подписать</i> публичный ключ Алисы своим ключом, и по валидности <i>своей</i> подписи судить о том, что имеющийся ключ Алисы до сих пор верен.

Вообще говоря, в этом месте мы приехали к понятию <i>Public Key Infrastructure (PKI)</i> — системе способов, инструментов и практик по обмену публичными ключами. Существует несколько ипостасей PKI.

Одна из них — <i>центры сертификации</i>, которые обеспечивают валидность публичных ключей, подписывая их мастер-ключами (их ещё называют корневыми сертификатами). Это способ, по которому пошли технологии, стоящие за HTTPS, SSL, TLS. Поскольку публичные части мастер-ключей известны и меняются очень редко, можно быстро установить валидность любого подписанного им ключа. Понятно, что при компрометации корневого сертификата всё идёт прахом: злоумышленник может нагенерить сколько угодно публичных ключей, которые будут безусловно валидны. Поэтому центры сертификации охраняют их строже смерти кащеевой, и берут за это баснословные деньги.

Вторая, которую выбрала себе PGP — <i>"сети доверия" (Web of Trust, WoT)</i>. WoT использует тот факт, что отношение доверия к публичному ключу транзитивно. Если Боб доверяет ключу Алисы (то есть публичный ключ Алисы подписан Бобом), а Алиса доверяет ключу Чарли (то есть публичный ключ Чарли подписан Алисой), то Боб может транзитивно доверять валидности ключа Чарли.

<h4>III. Web of Trust</h4> WoT, таким образом, пытается быть децентрализованной, надёжной системой проверки подлинности публичных ключей. Применение WoT позволяет хранить все публичные ключи и их подписи на публичных серверах ключей. В этом случае можно легко получить публичный ключ реципиента, проверить его валидность через WoT, и начать им пользоваться для проверки подписей.

Реальная прочность WoT обеспечивается тем, что до конкретного публичного ключа есть несколько маршрутов (цепочек) доверия, поэтому даже если Труди <a href="http://xkcd.com/364/">основательно напоит</a> Чарли, и он подпишет фальшивый ключ Труди, выдающей себя за Алису, к фальшивому ключу Труди будет <i>меньше</i> маршрутов, чем к реальному ключу Алисы в достаточно плотной WoT.

Здравое рассуждение парней из <a href="http://www.lysator.liu.se/~jc/wotsap/">wotsap</a> приводит к тому, что легитимным пользователям нужно не столько влиться в саму WoT, сколько сделать свой ключ достижимым из самой большой компоненты связности в графе доверия, так называемый <i>strong set</i>, и далее закрепляться, получая всё больше и больше подписей.

Некоторые оценки strong set’а существующей PGP WoT <a href="http://people.cs.uu.nl/henkp/henkp/pgp/">делаются</a> <a href="http://pgp.cs.uu.nl/plot/">постоянно</a>, ниже представлен ещё один способ оценить её размеры. Несмотря на то, что все публичные ключи и подписи к ним есть на публичных серверах, и их можно выкачать, по сути нас интересуют только связи между ключами, которые можно представить в достаточно компактной форме. Парни из wotsap это уже сделали за нас, предоставляя <a href="http://www.lysator.liu.se/~jc/wotsap/wots2/">регулярные дампы</a>.

Я взял такой дамп, сконвертировал его в .dot, и открыл в <a href="http://gephi.org/">Gephi</a>. Кое-какие базовые оценки параметров графа приведены ниже: <ul><li>количество вершин (т.е. ключей): ~45K</li> <li>количество ребёр (т.е. подписей): ~470K</li> <li>средний degree (т.е. в среднем подписей на ключе): ~10.2</li> <li>средняя длина минимального пути: 5.069</li> <li>диаметр графа: 18</li></ul> Вот так, кстати, выглядит распределение среднего пути от конкретного ключа до всех остальных:

<img src="http://habrastorage.org/getpro/habr/post_images/50f/ad4/c4e/50fad4c4e4100fed31e463c5ebec46ce.png">

Его среднее есть средняя длина минимального пути, около 5.0.

А вот и сам красавец, отрендерённый на разных значениях прозрачности ребёр. <b>По клику открывается картинка размером 5000х5000, занимающая многие мегабайты (от 10 до 20 Мб):</b> <a href="http://people.apache.org/~shade/articles/pgp-wot/graphs/wot-o01-5K.png"><img src="http://habrastorage.org/getpro/habr/post_images/a51/0d0/fe5/a510d0fe534089e33963a709a50b75eb.jpg"></a> <a href="http://people.apache.org/~shade/articles/pgp-wot/graphs/wot-o05-5K.png"><img src="http://habrastorage.org/getpro/habr/post_images/13c/3e6/81d/13c3e681dbde611fe760df83d03c287b.jpg"></a> <a href="http://people.apache.org/~shade/articles/pgp-wot/graphs/wot-o10-5K.png"><img src="http://habrastorage.org/getpro/habr/post_images/cfb/b22/424/cfbb22424f706a98b6f356afa18c03a7.jpg"></a> <a href="http://people.apache.org/~shade/articles/pgp-wot/graphs/wot-o20-5K.png"><img src="http://habrastorage.org/getpro/habr/post_images/6f6/ae8/02c/6f6ae802c5788803e441aef3b78ecb2e.jpg"></a>

<h4>IV. Способы подписать ключ</h4> Техническая сторона вопроса хорошо освещена в <a href="http://www.gnupg.org/gph/en/manual.html">GNU Privacy Handbook</a>. Вам точно понадобится другой пользователь PGP/GPG, желательно находящийся в strong set’е.

Если у вас в округе нет пользователей PGP, то можно сходить на <a href="http://biglumber.com/">Biglumber</a> и поискать там людей, которые могут подписать ваш ключ, и находятся в физической досягаемости (например, <a href="http://biglumber.com/x/web?so=Russia+(Federation)">в том же городе</a>). Обычно подписывающий ключ незнакомого человека требует предъявления документа, удостоверяющего личность. А некоторые требуют даже два. Обычно достаточно опубликовать свой ключ на сервере ключей, принести с собой на встречу паспорт, а также fingerprint и uid ключа, и готово.

Кроме того, периодически устраиваются <a href="http://en.wikipedia.org/wiki/Key_signing_party">key signing party</a> (KSP), обычно приуроченные к конференциям и другим масштабным попойкам, на которых можно получить десятки и сотни подписей к своему ключу. Если внимательно посмотреть на граф WoT, то можно увидеть хорошую кластеризацию, в этих кластерах я подозреваю KSP.

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

<h4>V. Вместо послесловия</h4> Приватность и проверка подлинности касается не только избранных маргиналов, это необходимый ответ на всеобщую анонимность. Если вам когда-нибудь нужно будет установить свою идентичность, без предварительных телодвижений это будет сделать трудновато. Готовьте сани летом, привыкайте к инструментарию, подходам, вырабатывайте хорошие привычки. Начните подписывать свою почту. Начните требовать цифровых подписей на важной входящей почте. Чтобы, когда припёрло, вы точно знали, что и как делать.

С Новым Годом! Пусть он будет надёжнее.