Введение

Механизм аутентификации криптографических ключей
Веб-сайт по безопасности в Интернете

В криптографии «сеть доверия» – это концепция, используемая в PGP, GnuPG и других системах, совместимых с OpenPGP, для установления подлинности связи между открытым ключом и его владельцем. Её децентрализованная модель доверия является альтернативой централизованной модели доверия инфраструктуры открытых ключей (PKI), которая полностью полагается на центр сертификации (или иерархию таких центров). Как и в случае с компьютерными сетями, существует множество независимых сетей доверия, и любой пользователь (через свой сертификат открытого ключа) может быть частью нескольких сетей и связывать их между собой. Концепция сети доверия была впервые предложена создателем PGP Филом Циммерманом в 1992 году в руководстве к версии 2.0 PGP:

Обратите внимание на использование слова «эмерджентность» в данном контексте. Сеть доверия использует концепцию эмерджентности.

Работа сети доверия

Все реализации, совместимые с OpenPGP, включают в себя схему проверки сертификатов, призванную помочь в этом; принцип её работы получил название «сеть доверия». Сертификаты OpenPGP (которые содержат один или несколько открытых ключей вместе с информацией о владельце) могут быть цифровым образом подписаны другими пользователями, тем самым подтверждая связь между этим открытым ключом и лицом или организацией, указанными в сертификате. Обычно это делается на мероприятиях по подписанию ключей. Реализации, совместимые с OpenPGP, также включают схему подсчета доверия, которая может использоваться для определения, какой паре «владелец – открытый ключ» пользователь будет доверять при использовании PGP. Например, если три частично доверенных подтверждающих лица засвидетельствовали сертификат (и, следовательно, связь между включенным в него открытым ключом и владельцем), или если это сделал один полностью доверенный подтверждающий, то связь между владельцем и открытым ключом в этом сертификате будет считаться достоверной. Параметры этой схемы настраиваются пользователем (например, можно полностью исключить частичное доверие или установить его максимальный порог в шесть подтверждений) и могут быть полностью отключены при необходимости. Эта схема отличается гибкостью, в отличие от большинства проектов инфраструктуры открытых ключей (PKI), и предоставляет пользователям право самостоятельно принимать решения о доверии. Она не является безупречной и требует от пользователей осторожности и разумного подхода. В отличие от неё, практически все проекты PKI менее гибки и требуют от пользователей следовать доверию, установленному PKI, в сертификатах, подписанных удостоверяющим центром (CA).

Упрощенное объяснение

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

Контраст с типичным PKI

В отличие от WOT, типичная инфраструктура открытых ключей X.509 (PKI) позволяет каждому сертификату быть подписанным только одной стороной: центром сертификации (CA). Сертификат CA может быть подписан другим CA, и так далее, вплоть до "самоподписанного" корневого сертификата. Корневые сертификаты должны быть доступны пользователям, использующим сертификаты CA более низкого уровня, и поэтому обычно широко распространяются. Например, они поставляются вместе с такими приложениями, как веб-браузеры и почтовые клиенты. Это позволяет аутентифицировать веб-страницы, защищенные SSL/TLS, электронные письма и т.п. без необходимости ручной установки корневых сертификатов пользователями. Приложения обычно содержат более ста корневых сертификатов от десятков PKI, тем самым по умолчанию наделяя доверием всю иерархию сертификатов, восходящую к ним. WOT делает ставку на децентрализацию доверенных якорей, чтобы предотвратить компрометацию иерархии CA из-за единой точки отказа.

Потеря закрытых ключей

Сеть доверия OpenPGP по существу не подвержена влиянию таких факторов, как банкротство компаний, и продолжает функционировать с незначительными изменениями. Однако возникает сопутствующая проблема: пользователи – будь то частные лица или организации – которые теряют доступ к своему закрытому ключу, больше не могут расшифровать сообщения, отправленные им и зашифрованные с использованием соответствующего открытого ключа, содержащегося в сертификате OpenPGP. Первые сертификаты PGP не содержали дат истечения срока действия, и срок действия этих сертификатов был неограниченным. Пользователям приходилось заранее готовить подписанный сертификат отзыва на случай потери или компрометации соответствующего закрытого ключа. Один известный криптограф до сих пор получает сообщения, зашифрованные с использованием открытого ключа, закрытый ключ от которого он давно потерял. Он не может сделать ничего с этими сообщениями, кроме как отбросить их после уведомления отправителя о том, что они нечитаемы, и просьбы повторно отправить сообщения, зашифрованные с использованием открытого ключа, для которого у него все еще есть соответствующий закрытый ключ. Более поздние версии PGP и все сертификаты, соответствующие стандарту OpenPGP, включают даты истечения срока действия, что при разумном использовании автоматически предотвращает возникновение подобных проблем (в конечном итоге). Эту проблему также можно легко избежать, используя "назначенных отзывщиков", которые были введены в начале 1990-х годов. Владелец ключа может назначить третье лицо, имеющее право отозвать ключ владельца (в случае, если владелец потеряет свой закрытый ключ и, следовательно, утратит возможность отозвать свой открытый ключ).

Проверка подлинности открытого ключа

Нетехническая социальная сложность, связанная с Web of Trust, подобной той, что встроена в системы типа PGP/OpenPGP, заключается в том, что каждая сеть доверия без центрального органа управления (например, CA) зависит от доверия других пользователей. Пользователи с новыми сертификатами (то есть созданными в процессе генерации новой пары ключей) вряд ли сразу же будут доверяться системами других пользователей, то есть теми, с кем они лично не встречались, пока не получат достаточное количество подтверждений для нового сертификата. Это происходит потому, что многие пользователи Web of Trust настраивают проверку сертификатов таким образом, что требуется одно или несколько полностью доверенных подтверждений для неизвестного сертификата (или, возможно, несколько частичных подтверждений), прежде чем использовать открытый ключ из этого сертификата для подготовки сообщений, проверки подписей и т.д. Несмотря на широкое распространение систем, совместимых с OpenPGP, и легкую доступность множества ключевых серверов в сети, на практике может оказаться сложно найти кого-то (или нескольких человек), кто согласится подтвердить новый сертификат (например, путем сопоставления физических документов, удостоверяющих личность, с информацией о владельце ключа и последующей цифровой подписи нового сертификата). Например, пользователи, находящиеся в отдаленных или недостаточно развитых регионах, могут столкнуться с нехваткой других пользователей. И если сертификат другой стороны также новый (и не имеет или имеет мало подтверждений от других), то его подпись на любом новом сертификате может принести лишь незначительную пользу в плане завоевания доверия со стороны других систем и, следовательно, возможности безопасного обмена сообщениями с ними. Встречи для подписания ключей – относительно популярный механизм для решения проблемы поиска других пользователей, которые могут установить ваш сертификат в существующие сети доверия, подтвердив его. Существуют также веб-сайты, облегчающие поиск других пользователей OpenPGP для организации подписания ключей. Web of Trust Gossamer Spider также упрощает проверку ключей, связывая пользователей OpenPGP посредством иерархической сети доверия, где конечные пользователи могут извлечь выгоду из случайного или намеренного доверия к кому-то, кто одобрен в качестве представителя, или из явного доверия к ключу GSWoT верхнего уровня как минимум представителя второго уровня (ключ верхнего уровня подтверждает представителей первого уровня). Возможность поиска цепочек сертификатов часто обосновывается "феноменом малого мира": учитывая двух людей, часто можно найти короткую цепочку знакомых между ними, где каждый человек в цепочке знает предыдущего и следующего. Однако такая цепочка не обязательно полезна: человек, шифрующий электронное письмо или проверяющий подпись, должен не только найти цепочку подписей от своего личного ключа до ключа корреспондента, но и доверять каждому человеку в цепочке в их честности и компетентности при подписании ключей (то есть, оценивать, насколько вероятно, что эти люди будут честно следовать рекомендациям по проверке личности перед подписанием ключей). Это гораздо более жесткое требование. Еще одним препятствием является необходимость личной встречи с кем-то (например, на мероприятии по подписанию ключей) для подтверждения его личности и права собственности на открытый ключ и адрес электронной почты, что может повлечь за собой расходы на поездки и сложности с планированием для обеих сторон. Пользователю программного обеспечения может потребоваться проверить сотни программных компонентов, созданных тысячами разработчиков по всему миру. Поскольку большинство пользователей программного обеспечения не могут лично встретиться со всеми разработчиками, чтобы установить прямое доверие, им приходится полагаться на сравнительно более медленное распространение косвенного доверия. Получение ключа PGP/GPG автора (или разработчика, издателя и т.д.) с сервера ключей также сопряжено с рисками, поскольку сервер ключей является третьей стороной, которая сама уязвима для злоупотреблений или атак. Чтобы избежать этого риска, автор может вместо этого опубликовать свой открытый ключ на собственном сервере ключей (то есть веб-сервере, доступном по доменному имени, принадлежащему ему, и надежно расположенном в его частном офисе или доме) и требовать использования зашифрованных соединений HKPS для передачи своего открытого ключа. Подробности см. в разделе "Решения, помогающие Web of Trust" ниже.

Сильный набор

Сильный набор — это крупнейшая коллекция сильно связанных ключей PGP. Он является основой глобальной сети доверия. Для любых двух ключей в сильном наборе существует путь между ними; хотя изолированные группы ключей, которые подписывают только друг друга, могут существовать, достаточно, чтобы один участник такой группы обменялся подписями с сильным набором, чтобы вся группа стала его частью. В начале 2015 года размер сильного набора составлял около 55000 ключей.

Средняя кратчайшая дистанция

В статистическом анализе PGP/GnuPG/OpenPGP Web of trust среднее кратчайшее расстояние (MSD) – это одна из мер, определяющих степень "доверия" к данному ключу PGP внутри сильно связанной компоненты ключей PGP, формирующей Web of trust. MSD стало распространенной метрикой для анализа наборов ключей PGP. Зачастую MSD вычисляется для определенного подмножества ключей и сравнивается с глобальным MSD, который обычно подразумевает ранжирование ключей в рамках одного из масштабных анализов глобальной Сети доверия.

Помощные решения WOT

Физическая встреча с оригинальным разработчиком или автором всегда является наилучшим способом получения, распространения, проверки и установления доверия к ключам PGP/GPG с максимальным уровнем доверия, и останется таковым. Публикация полного ключа GPG/PGP или полного отпечатка ключа в широко известной (физической/бумажной) книге оригинальным автором/разработчиком является вторым по эффективности способом обмена доверенным ключом с пользователями и для пользователей. Перед встречей с разработчиком или автором пользователи должны самостоятельно изучить информацию о нем в библиотеках и в интернете, ознакомиться с его фотографией, работой, отпечатком открытого ключа, адресом электронной почты и т.д. Однако физическая встреча с каждым получателем непрактична для миллионов пользователей, желающих безопасно общаться или обмениваться сообщениями, и также непрактична для миллионов пользователей программного обеспечения, которым необходимо лично встречаться с сотнями разработчиков или авторов, чьи программные продукты или файлы они хотят проверить, удостовериться в их подлинности и в конечном итоге использовать на своих компьютерах. Поэтому пользователям должна быть доступна одна или несколько организаций или групп, функционирующих как доверенные третьи стороны (TTPA), и эти организации/группы должны быть способны предоставлять услуги доверенной проверки или делегирования доверия миллионам пользователей по всему миру в любое время. На практике, для проверки подлинности загруженного или полученного контента, данных, электронной почты или файла, пользователю необходимо проверить PGP/GPG подпись (ASC, SIG) основного загруженного контента, данных, электронной почты или файла. Таким образом, пользователям потребуется использовать доверенный и проверенный открытый ключ оригинального разработчика или автора, либо доверенный открытый ключ для подписи файлов, которому доверяет оригинальный владелец этого ключа. Чтобы по-настоящему доверять конкретному ключу PGP/GPG, пользователям необходимо лично встретиться с каждым оригинальным автором или разработчиком, либо с оригинальным распространителем ключа для подписи файлов, либо найти другого надежного пользователя, входящего в доверенную цепочку WOT (также известного как другой пользователь, разработчик или автор, которому доверяет конкретный оригинальный автор или разработчик), и затем лично встретиться с этим человеком для подтверждения его личности и ключа PGP/GPG (а также предоставить свои собственные данные и ключ для взаимной подписи/сертификации и установления доверия). Независимо от популярности программного обеспечения, пользователи обычно находятся в разных точках мира. Физически невозможно для оригинального автора, разработчика или распространителя файлов предоставлять услуги проверки открытого ключа, доверия или идентификации миллионам пользователей. Также непрактично для миллионов пользователей программного обеспечения лично встречаться с каждым разработчиком или автором каждого программного продукта, библиотеки или фрагмента кода, который они будут (использовать или) должны использовать на своих компьютерах. Даже при наличии нескольких доверенных лиц (указанных оригинальным автором) в доверенной цепочке WOT, физически или практически невозможно для каждого разработчика или автора встретиться с каждым пользователем, и также невозможно для каждого пользователя встретиться с сотнями разработчиков, чье программное обеспечение они будут использовать или разрабатывать. Только когда эта децентрализованная иерархическая модель цепочки WoT станет популярной и будет использоваться большинством пользователей, физические встречи и процедуры сертификации и подписания ключей в WoT станут проще. Некоторые решения: оригинальный автор/разработчик должен сначала установить уровень доверия для подписи/сертификации своего ключа для подписи файлов. Затем обновленные открытые ключи и ключи для подписи файлов также должны быть опубликованы и распространены (или сделаны доступными) пользователям через безопасные и зашифрованные онлайн-каналы, чтобы любой пользователь из любой точки мира мог получить правильный, доверенный и неизмененный открытый ключ. Чтобы гарантировать, что каждый пользователь получает правильные и доверенные открытые ключи и подписанный код/файлы, оригинальный разработчик/автор или распространитель должны публиковать свои обновленные открытые ключи на своем собственном сервере ключей и принудительно использовать зашифрованное соединение HKPS, или публиковать свои обновленные полные открытые ключи (и подписанный код/файлы) на своей собственной зашифрованной веб-странице HTTPS, расположенной на своем собственном основном домене, (а не на каких-либо поддоменах, расположенных на внешних серверах, не на каких-либо зеркалах, не на каких-либо внешних/общих форумах/wiki и т.д., не на каких-либо публичных или внешних/общих облачных или хостинговых серверах), и они должны быть надежно защищены в пределах своей собственной территории: дома, домашнего офиса или офиса. Таким образом, эти небольшие фрагменты оригинальных ключей/кода будут передаваться через интернет неповрежденными и останутся неизменными во время передачи (благодаря зашифрованному соединению) и достигнут места назначения без перехвата или изменения, и могут рассматриваться как доверенные открытые ключи благодаря верификации на основе одной или нескольких TTPA. Когда открытый ключ получен (с собственного веб-сервера оригинального разработчика) через более одного TTPA (доверенной третьей стороны) на основе защищенного, проверенного и зашифрованного соединения, он считается более надежным. Когда оригинальные открытые ключи/подписанный код отображаются на собственном веб-сервере или сервере ключей оригинального разработчика или автора через зашифрованное соединение или зашифрованную веб-страницу, любые другие файлы, данные или контент могут быть переданы по любому незашифрованному соединению, такому как HTTP/FTP и т.д., с любого поддоменного сервера или с любого зеркала или с любого общего облачного/хостингового сервера, поскольку загруженные элементы/данные/файлы, передаваемые по незашифрованному соединению, могут быть аутентифицированы позже с использованием оригинальных открытых ключей/подписанного кода, полученных с сервера оригинального автора/разработчика через защищенное, зашифрованное и доверенное (т.е. проверенное) соединение/канал. Использование зашифрованного соединения для передачи ключей или подписанного кода/файлов позволяет пользователям программного обеспечения делегировать свое доверие PKI TTPA (доверенной третьей стороне), такой как общедоступный ЦА (Центр сертификации), чтобы помочь в обеспечении доверенного соединения между веб-сервером оригинального разработчика/автора и компьютерами миллионов пользователей по всему миру в любое время. Когда доменное имя и DNS-сервер оригинального автора/разработчика подписаны DNSSEC, и когда используемый SSL/TLS публичный сертификат указан/отображен в записи ресурса DNS TLSA/DANE DNSSEC, (и когда SSL/TLS сертификаты в цепочке доверия закреплены и используются с помощью техники HPKP веб-серверами), тогда веб-страница или данные веб-сервера также могут быть проверены с помощью другой PKI TTPA: DNSSEC и поддерживающего DNS-пространство ICANN, помимо общедоступного ЦА. DNSSEC является еще одной формой WOT PGP/GPG, но для DNS-серверов; он создает доверенную цепочку для DNS-серверов в первую очередь (вместо людей/лиц), а затем ключи PGP/GPG и отпечатки пальцев людей/лиц также могут быть добавлены в DNS-записи DNSSEC сервера. Таким образом, любой пользователь, желающий безопасно общаться (или любой пользователь программного обеспечения), может эффективно получить/получить свои данные/ключ/код/веб-страницу и т.д. проверенными (т.е. аутентифицированными) одновременно через два (т.е. двойных) доверенных PKI TTPA/канала: ICANN (DNSSEC) и ЦА (SSL/TLS сертификат). Таким образом, ключу PGP/GPG/подписанным данным (или файлу) можно доверять, когда используются такие решения и методы: HKPS, HKPS+DNSSEC+DANE, HTTPS, HTTPS+HPKP или HTTPS+HPKP+DNSSEC+DANE. Если большое количество пользовательских групп создадут свои собственные новые реестры DLV на основе DNSSEC, и если пользователи будут использовать этот новый DLV (вместе с корневым ключом ICANN DNSSEC) в своем собственном локальном DNSSEC-совместимом DNS-разрешителе/сервере, и если владельцы доменов также будут использовать его для дополнительной подписи своих доменных имен, то может появиться третья TTPA. В этом случае любой ключ PGP/GPG/подписанные данные или веб-страница или веб-данные могут быть проверены по трем каналам. Сам ISC DLV может быть использован в качестве третьей TTPA, поскольку он все еще широко используется и активен, поэтому наличие другого нового DLV станет четвертой TTPA.