В криптографии сеть доверия — это концепция, используемая в PGP , GnuPG и других OpenPGP -совместимых системах для установления подлинности связи между открытым ключом и его владельцем. Его децентрализованная модель доверия является альтернативой централизованной модели доверия инфраструктуры открытых ключей (PKI), которая опирается исключительно на центр сертификации (или его иерархию). [1] Как и в случае с компьютерными сетями, существует множество независимых сетей доверия, и любой пользователь (через свой сертификат открытого ключа ) может быть частью нескольких сетей и связующим звеном между ними.
Концепция сети доверия была впервые предложена создателем PGP Филом Циммерманном в 1992 году в руководстве для PGP версии 2.0:
Со временем вы будете накапливать ключи от других людей, которых вы, возможно, захотите назначить доверенными представителями. Все остальные будут выбирать себе доверенных представителей. И каждый постепенно будет накапливать и распространять вместе со своим ключом коллекцию удостоверяющих подписей других людей с расчетом на то, что получивший ее будет доверять хотя бы одной-двум из подписей. Это приведет к появлению децентрализованной отказоустойчивой сети доверия для всех открытых ключей.
Обратите внимание на использование слова «эмерджентность» в этом контексте. Сеть доверия использует концепцию возникновения.
Все реализации, совместимые с OpenPGP, включают схему проверки сертификатов , помогающую в этом; ее работу назвали сетью доверия. Сертификаты OpenPGP (которые включают один или несколько открытых ключей вместе с информацией о владельце) могут быть подписаны цифровой подписью другими пользователями, которые этим действием подтверждают связь этого открытого ключа с физическим или юридическим лицом, указанным в сертификате. Обычно это делается на сторонах, подписывающих ключи . [2]
Реализации, совместимые с OpenPGP, также включают схему подсчета голосов, которую можно использовать для определения ассоциации открытого ключа и владельца, которой пользователь будет доверять при использовании PGP. Например, если три частично доверенных индоссанта поручились за сертификат (и, следовательно, в него включена привязка открытого ключа к владельцу ) или если это сделал один полностью доверенный индоссант, связь между владельцем и открытым ключом в этом сертификате будет считаться надежной. правильный. Параметры настраиваются пользователем (например, полное отсутствие партиалов или, возможно, шесть партиалов) и при желании их можно полностью обойти.
Схема является гибкой, в отличие от большинства проектов инфраструктуры открытых ключей, и оставляет решения о доверии в руках отдельных пользователей. Он не идеален и требует как осторожности, так и разумного контроля со стороны пользователей. По сути, все конструкции PKI менее гибки и требуют от пользователей соблюдения доверительного подтверждения сертификатов, созданных PKI и подписанных центром сертификации (CA).
У человека есть два ключа: открытый ключ, который открыт для общего доступа, и закрытый ключ, который скрывается владельцем. Закрытый ключ владельца расшифровывает любую информацию, зашифрованную его открытым ключом. В сети доверия у каждого пользователя есть связка ключей с открытыми ключами других людей.
Отправители шифруют свою информацию открытым ключом получателя, и только закрытый ключ получателя сможет ее расшифровать. Затем каждый отправитель подписывает зашифрованную информацию цифровой подписью своим личным ключом. Когда получатель сверяет полученную зашифрованную информацию с открытым ключом отправителя, он может подтвердить, что она получена от отправителя. Это гарантирует, что зашифрованная информация поступила от конкретного пользователя и не была подделана, и только предполагаемый получатель сможет расшифровать информацию (поскольку только он знает свой закрытый ключ).
В отличие от WOT, типичная PKI X.509 позволяет подписывать каждый сертификат одной стороной: центром сертификации (CA). Сертификат ЦС может быть подписан другим ЦС, вплоть до «самозаверяющего» корневого сертификата . Корневые сертификаты должны быть доступны тем, кто использует сертификат ЦС более низкого уровня, и поэтому обычно широко распространяются. Например, они распространяются вместе с такими приложениями, как браузеры и почтовые клиенты. Таким образом, веб-страницы, сообщения электронной почты и т. д., защищенные SSL/TLS , могут быть аутентифицированы, не требуя от пользователей ручной установки корневых сертификатов. Приложения обычно включают более ста корневых сертификатов из десятков PKI, что по умолчанию обеспечивает доверие по всей иерархии сертификатов, ведущей к ним.
WOT выступает за децентрализацию якорей доверия, чтобы предотвратить угрозу компрометации иерархии ЦС из одной точки отказа. [3]
Сеть доверия OpenPGP практически не подвержена влиянию таких вещей, как сбои компаний, и продолжает функционировать с небольшими изменениями. Однако связанная с этим проблема все же возникает: пользователи, будь то отдельные лица или организации, которые теряют личный ключ, больше не могут расшифровывать отправленные им сообщения, созданные с использованием соответствующего открытого ключа, найденного в сертификате OpenPGP. Ранние сертификаты PGP не имели даты истечения срока действия и имели неограниченный срок действия. Пользователи должны были подготовить подписанный сертификат отмены на тот момент, когда соответствующий закрытый ключ был утерян или скомпрометирован. Один очень известный криптограф до сих пор получает сообщения, зашифрованные с использованием открытого ключа, для которого он давно потерял секретный ключ. [4] Они ничего не могут сделать с этими сообщениями, кроме как отбросить их, уведомив отправителя о том, что они нечитабельны, и запросив повторную отправку с открытым ключом, для которого у них все еще есть соответствующий закрытый ключ. Более поздние версии PGP и все сертификаты, совместимые с OpenPGP, включают даты истечения срока действия, которые автоматически исключают такие проблемы (в конечном итоге) при разумном использовании. Этой проблемы также можно легко избежать, используя «назначенных лиц, отзывающих лицензии», которые были введены в начале 1990-х годов. Владелец ключа может назначить третье лицо, имеющее разрешение на отзыв ключа владельца ключа (в случае, если владелец ключа потеряет свой собственный закрытый ключ и, таким образом, потеряет возможность отозвать свой собственный открытый ключ).
Нетехническая социальная трудность, связанная с сетью доверия, подобной той, которая встроена в системы типа PGP/OpenPGP, заключается в том, что каждая сеть доверия без центрального контроллера (например, центра сертификации ) зависит от доверия других пользователей. Те, у кого есть новые сертификаты (т. е. полученные в процессе генерации новой пары ключей), скорее всего, не будут пользоваться доверием систем других пользователей, то есть тех, с кем они лично не встречались, пока они не найдут достаточно подтверждений для нового сертификата. Это связано с тем, что многие другие пользователи Web of Trust будут иметь настройку проверки сертификатов, требующую одного или нескольких полностью доверенных индоссантов неизвестного в противном случае сертификата (или, возможно, нескольких частичных индоссантов) перед использованием открытого ключа в этом сертификате для подготовки сообщений, полагают подписи, и т. д.
Несмотря на широкое использование систем, совместимых с OpenPGP, и легкую доступность нескольких онлайн- серверов ключей , на практике может оказаться невозможным быстро найти кого-то (или несколько человек), который подтвердит новый сертификат (например, путем сравнения физической идентификации с ключом). информацию о владельце, а затем поставить цифровую подпись на новом сертификате). Например, пользователи в отдаленных или неосвоенных регионах могут столкнуться с дефицитом других пользователей. А если сертификат другой стороны также новый (и не имеет или имеет мало подтверждений со стороны других), то его подпись на любом новом сертификате может принести лишь незначительную выгоду в плане завоевания доверия со стороны систем других сторон и, таким образом, возможности безопасного обмена сообщениями с ними. . Стороны, подписывающие ключи, являются относительно популярным механизмом решения проблемы поиска других пользователей, которые могут установить сертификат в существующих сетях доверия, подтвердив его. Также существуют веб-сайты, позволяющие другим пользователям OpenPGP найти местонахождение для организации подписи ключей. Паучья паутина доверия также упрощает проверку ключей, связывая пользователей OpenPGP через иерархическую сеть доверия, где конечные пользователи могут извлечь выгоду из случайного или определенного доверия к кому-то, кто одобрен в качестве представляющего, или путем явного доверия ключу верхнего уровня GSWoT. как минимум в качестве представителя уровня 2 (ключ верхнего уровня подтверждает представителей уровня 1).
Возможность нахождения цепочек сертификатов часто оправдывается « феноменом маленького мира »: учитывая двух индивидуумов, часто можно найти между ними короткую цепочку людей, такую, что каждый человек в цепочке знает предыдущие и последующие звенья. Однако такая цепочка не обязательно полезна: человек, шифрующий электронное письмо или проверяющий подпись, должен не только найти цепочку подписей от своего закрытого ключа до ключа корреспондента, но также быть уверенным в честности и компетентности каждого человека в цепочке. о подписании ключей (то есть они должны оценить, будут ли эти люди честно следовать рекомендациям по проверке личности людей перед подписанием ключей). Это гораздо более сильное ограничение.
Еще одним препятствием является требование физической встречи с кем-либо (например, на вечеринке по подписанию ключей ) для проверки его личности и владения открытым ключом и адресом электронной почты, что может повлечь за собой командировочные расходы и ограничения по расписанию, затрагивающие обе стороны. Пользователю программного обеспечения может потребоваться проверить сотни программных компонентов, созданных тысячами разработчиков по всему миру. Поскольку основная совокупность пользователей программного обеспечения не может лично встретиться со всеми разработчиками программного обеспечения для установления прямого доверия, вместо этого им приходится полагаться на сравнительно более медленное распространение косвенного доверия. [ нужна цитата ]
Получение ключа PGP/GPG автора (или разработчика, издателя и т. д.) с сервера открытых ключей также представляет риск, поскольку сервер ключей является сторонним посредником , который сам уязвим для злоупотреблений или атак. Чтобы избежать этого риска, автор может вместо этого опубликовать свой открытый ключ на своем собственном сервере ключей (т. е. веб-сервере, доступном через принадлежащее ему доменное имя и надежно расположенном в его личном офисе или дома) и потребовать использования Соединения, зашифрованные с помощью HKPS, для передачи открытого ключа. Подробную информацию см. в разделе «Вспомогательные решения WOT» ниже.
Сильный набор относится к наибольшему набору сильно связанных ключей PGP . [5] Это формирует основу глобальной сети доверия. Любые два ключа в сильном наборе имеют путь между собой; хотя островки наборов ключей, которые подписывают друг друга только в отключенной группе, могут существовать и существуют, только одному члену этой группы необходимо обменяться подписями с надежным набором, чтобы эта группа также стала частью надежного набора. [6] На начало 2015 года размер сильного набора составлял около 55 000 ключей. [7]
В статистическом анализе сети доверия PGP / GnuPG / OpenPGP среднее кратчайшее расстояние (MSD) является одним из показателей того, насколько «доверенным» является данный ключ PGP в сильно связанном наборе ключей PGP, составляющих сеть доверия.
MSD стал общей метрикой для анализа наборов ключей PGP. Очень часто вы увидите, как MSD рассчитывается для заданного подмножества ключей и сравнивается с глобальным MSD , который обычно относится к ранжированию ключей в рамках одного из более крупных ключевых анализов глобальной сети доверия.
Физическая встреча с первоначальным разработчиком или автором всегда является лучшим способом получения, распространения, проверки и доверия ключам PGP/GPG с самым высоким уровнем доверия, и она останется лучшим из наиболее надежных способов. Публикация полного ключа GPG/PGP или полного отпечатка ключа в широко известной (физической/бумажной) книге или вместе с ней первоначальным автором/разработчиком является второй лучшей формой обмена надежным ключом с пользователями и для пользователей. Прежде чем встретиться с разработчиком или автором, пользователи должны самостоятельно изучить информацию о разработчике или авторе в книжной библиотеке и через Интернет, а также узнать фотографию разработчика или автора, работу, отпечаток ключа паблика, адрес электронной почты и т. д.
Однако для миллионов пользователей, которые хотят безопасно общаться или отправлять сообщения, нецелесообразно физически встречаться с каждым пользователем-получателем, а также непрактично для миллионов пользователей программного обеспечения, которым необходимо физически встретиться с сотнями разработчиков или авторов программного обеспечения, чьи программное обеспечение или подпись файла с открытым ключом PGP / GPG , который они хотят проверить, которому можно доверять и в конечном итоге использовать на своих компьютерах. Следовательно, один или несколько типов объектов или групп доверенных сторонних органов власти (TTPA) должны быть доступны для пользователей и доступны для использования пользователями, и такой объект/группа должны быть способны предоставлять услуги доверенной проверки или делегирования доверия для миллионы пользователей по всему миру в любое время.
На практике, чтобы проверить любой загруженный или полученный контент, данные, электронную почту или подлинность файла , пользователю необходимо проверить загруженный основной контент или основные данные/электронную почту или код/файл подписи PGP/GPG основного файла (ASC, SIG). Таким образом, пользователям необходимо будет использовать заслуживающий доверия и проверенный открытый ключ исходного разработчика или исходного автора, или пользователям необходимо будет использовать заслуживающий доверия открытый ключ для подписи файлов, которому доверяет первоначальный владелец этого открытого ключа. И чтобы действительно доверять конкретному ключу PGP/GPG, пользователям необходимо будет физически встретиться с каждым конкретным первоначальным автором или разработчиком, или пользователям необходимо будет физически встретиться с первоначальным выпустившим публичный ключ для подписи файлов, или пользователям потребуется найти другого альтернативного заслуживающего доверия пользователя, который находится в доверенной цепочке WOT (то есть другого пользователя, другого разработчика или другого автора, которому доверяет этот очень конкретный первоначальный автор или разработчик), а затем физически встретиться с этим человеком, чтобы проверить свой настоящий идентификатор с его/ее ключом PGP/GPG (а также предоставить свой собственный идентификатор и ключ другому пользователю, чтобы обе стороны могли подписывать/сертифицировать и доверять ключу PGP/GPG друг друга). Независимо от того, популярно программное обеспечение или нет, пользователи программного обеспечения обычно находятся по всему миру в разных местах. Для первоначального автора, разработчика или распространителя файлов физически невозможно предоставить услуги открытого ключа, доверия или проверки личности миллионам пользователей. Также нецелесообразно, чтобы миллионы пользователей программного обеспечения физически встречались с каждым программным обеспечением, с каждой библиотекой программного обеспечения или с разработчиком, автором или релизером каждого фрагмента кода, который они будут (использовать или) должны будут использовать на своих компьютерах. Даже при наличии нескольких доверенных лиц/лиц (от исходного автора) в доверенной цепочке из WOT физически или практически невозможно каждому разработчику или автору встретиться с каждым другим пользователем, а также невозможно встретиться каждому пользователю. с сотнями разработчиков, программное обеспечение которых они будут использовать или над которым они будут работать. Когда эта модель цепочки WoT, основанная на децентрализованной иерархии, станет популярной и будет использоваться большинством близлежащих пользователей, только тогда физическая встреча, а также процедура сертификации и подписания публичного ключа WoT станут проще.
Вот несколько решений : первоначальному автору/разработчику необходимо сначала установить уровень доверия для подписи/сертификации своего собственного ключа подписи файла. Затем обновленные открытые ключи и обновленные открытые ключи для подписи файлов также должны быть опубликованы и распространены (или сделаны доступными) пользователям через безопасные и зашифрованные онлайн-среды, чтобы любой пользователь из любой точки мира мог получить правильную информацию. и доверенный и немодифицированный открытый ключ. Чтобы убедиться, что каждый пользователь получает правильные и надежные открытые ключи и подписанный код/файл, первоначальный разработчик/автор или первоначальный релиз должен опубликовать свои обновленные открытые ключи на своем собственном сервере ключей и принудительно использовать зашифрованное соединение HKPS, или публиковать свои обновленные и полные открытые ключи (и подписанный код/файл) на своей собственной зашифрованной HTTPS- странице, на своем собственном веб-сервере, на своем собственном основном веб-сайте домена (а не на каких-либо поддоменах, расположенных во внешних доменах). серверы, не из какого-либо зеркала, не из какого-либо внешнего/общего форума/вики и т. д. серверов веб-сайтов, не из какого-либо общедоступного или внешнего/общедоступного облака или серверов службы хостинга), и должны быть расположены и надежно храниться внутри своих собственных помещения: собственный дом, собственный дом-офис или собственный офис. Таким образом, эти небольшие фрагменты исходных ключей/кода будут проходить через Интернет в целости и сохранности, останутся неизмененными во время передачи (из-за зашифрованного соединения) и достигнут места назначения без подслушивания или изменения на стороне пользователя, и их можно рассматривать как заслуживающие доверия. открытые ключи из-за одно- или многоканальной проверки на основе TTPA. Когда открытый ключ получен (с собственного веб-сервера исходного разработчика) через более чем одно защищенное, проверенное и зашифрованное соединение на основе TTPA (доверенного третьего лица), тогда он заслуживает большего доверия.
Когда исходные открытые ключи/подписанные коды отображаются на исходном веб-сервере или сервере ключей исходного разработчика или автора, через зашифрованное соединение или зашифрованную веб-страницу, тогда любые другие файлы, данные или контент могут быть переданы через любой тип незашифрованного соединения. например: HTTP/FTP и т. д. с любого сервера субдомена, с любого зеркала или с любого общего облака/хост-сервера, поскольку загруженные элементы/данные/файлы на основе незашифрованного соединения могут быть аутентифицированы позже с использованием исходных открытых ключей. /signed-codes, которые были получены с исходного сервера автора/разработчика по защищенному, зашифрованному и доверенному (то есть проверенному) соединению/каналам.
Использование зашифрованного соединения для передачи ключей или подписанного кода/кода подписи/файлов позволяет пользователям программного обеспечения делегировать свое доверие с помощью PKI TTPA (доверенный сторонний орган сертификации), например общедоступный CA (центр сертификации), чтобы помочь в обеспечении доверенного соединения между исходным веб-сервер разработчика/автора и миллионы компьютеров пользователей по всему миру в любое время.
Когда доменное имя и сервер имен исходного автора/разработчика подписаны DNSSEC , а при использовании общедоступного сертификата SSL/TLS объявлен/показан в записи ресурса DNS TLSA/ DANE DNSSec (и когда сертификаты SSL/TLS в доверительном управлении цепочки закреплены и используются веб-серверами с помощью технологии HPKP ), тогда веб-страница или данные веб-сервера также могут быть проверены с помощью другого PKI TTPA : DNSSEC и средства обслуживания пространства имен DNS ICANN , отличного от общедоступного центра сертификации. DNSSEC — это еще одна форма PGP/GPG WOT, но для серверов имен; сначала он создает доверенную цепочку для серверов имен (вместо людей/человека), а затем ключи PGP/GPG и отпечатки пальцев людей/человека также могут быть добавлены в DNS-записи DNSSEC сервера. Таким образом, любые пользователи, которые хотят безопасно общаться (или любые пользователи программного обеспечения), могут эффективно получать/получать свои данные/ключ/код/веб-страницу и т. д., проверенные (то есть аутентифицированные) через два (или двойные/двойные) доверенные PKI TTPA/каналы. одновременно: ICANN (DNSSEC) и CA ( сертификат SSL/TLS ). Таким образом, данным ключа/подписанного кода PGP/GPG (или файлу) можно доверять, когда используются такие решения и методы: HKPS, HKPS+DNSSEC+DANE, HTTPS, HTTPS+HPKP или HTTPS+HPKP+DNSSEC+DANE.
Если большое количество групп пользователей создаст свой собственный новый реестр DNSSEC на основе DLV , и если пользователи будут использовать этот новый корневой ключ DLV (вместе с ICANN-DNSSEC) в своем собственном локальном DNS Resolver/Server на основе DNSSEC, и если владельцы доменов также использовать его для дополнительной подписи своих собственных доменных имен, тогда может появиться новый третий TTPA. В таком случае любые данные ключа PGP/GPG/подписного кода или веб-страница или веб-данные могут быть проверены по трем/трем каналам. Сам DLV ISC может использоваться в качестве третьего TTPA, поскольку он все еще широко и активно используется, поэтому доступность еще одного нового DLV станет четвертым TTPA.
Брюс потерял ключ PGP почти десять лет назад; он по-прежнему получает электронную почту, зашифрованную соответствующим сертификатом.