В криптографии сеть доверия — это концепция, используемая в PGP , GnuPG и других совместимых с OpenPGP системах для установления подлинности привязки открытого ключа к его владельцу. Ее децентрализованная модель доверия является альтернативой централизованной модели доверия инфраструктуры открытого ключа (PKI), которая опирается исключительно на центр сертификации (или иерархию таковых). [1] Как и в компьютерных сетях, существует множество независимых сетей доверия, и любой пользователь (через свой сертификат открытого ключа ) может быть частью и связующим звеном между несколькими сетями.
Концепция сети доверия была впервые предложена создателем PGP Филом Циммерманном в 1992 году в руководстве к PGP версии 2.0:
Со временем вы накопите ключи от других людей, которых вы, возможно, захотите назначить доверенными поручителями. Все остальные выберут своих собственных доверенных поручителей. И каждый постепенно накопит и распространит вместе со своим ключом коллекцию удостоверяющих подписей от других людей, ожидая, что любой, кто его получит, будет доверять хотя бы одной или двум подписям. Это приведет к появлению децентрализованной отказоустойчивой сети доверия для всех открытых ключей.
Обратите внимание на использование слова «возникновение» в этом контексте. Сеть доверия использует концепцию возникновения.
Все OpenPGP-совместимые реализации включают схему проверки сертификатов , помогающую в этом; ее работа была названа сетью доверия. Сертификаты OpenPGP (которые включают один или несколько открытых ключей вместе с информацией о владельце) могут быть подписаны в цифровой форме другими пользователями, которые этим актом подтверждают связь этого открытого ключа с лицом или организацией, указанной в сертификате. Это обычно делается на вечеринках по подписанию ключей . [2]
Реализации, совместимые с OpenPGP, также включают схему подсчета голосов, которая может использоваться для определения того, какой ассоциации открытый ключ – владелец будет доверять пользователю при использовании PGP. Например, если три частично доверенных индоссанта поручились за сертификат (и, следовательно, его включенную привязку открытый ключ – владелец ) , или если это сделал один полностью доверенный индоссант, ассоциация между владельцем и открытым ключом в этом сертификате будет считаться правильной. Параметры настраиваются пользователем (например, вообще без частичных значений или, возможно, шесть частичных значений) и могут быть полностью пропущены при желании.
Схема гибкая, в отличие от большинства проектов инфраструктуры открытых ключей, и оставляет решения о доверии в руках отдельных пользователей. Она не идеальна и требует как осторожности, так и разумного надзора со стороны пользователей. По сути, все проекты PKI менее гибкие и требуют от пользователей следовать доверительному одобрению сгенерированных PKI, подписанных центром сертификации (CA), сертификатов.
Есть два ключа, относящихся к человеку: открытый ключ, который предоставляется открыто, и закрытый ключ, который удерживается владельцем. Закрытый ключ владельца расшифрует любую информацию, зашифрованную его открытым ключом. В сети доверия у каждого пользователя есть связка ключей с открытыми ключами других людей.
Отправители шифруют свою информацию открытым ключом получателя, и только закрытый ключ получателя может ее расшифровать. Затем каждый отправитель ставит цифровую подпись на зашифрованную информацию своим закрытым ключом. Когда получатель проверяет полученную зашифрованную информацию открытым ключом отправителя, он может подтвердить, что она от отправителя. Это гарантирует, что зашифрованная информация поступила от конкретного пользователя и не была подделана, и только предполагаемый получатель может расшифровать информацию (потому что только он знает свой закрытый ключ).
В отличие от WOT, типичный X.509 PKI позволяет подписывать каждый сертификат одной стороной: центром сертификации (CA). Сертификат CA может быть подписан другим CA, вплоть до «самоподписанного» корневого сертификата . Корневые сертификаты должны быть доступны тем, кто использует сертификат CA более низкого уровня, и поэтому обычно широко распространяются. Например, они распространяются с такими приложениями, как браузеры и почтовые клиенты. Таким образом, защищенные SSL/TLS веб-страницы, сообщения электронной почты и т. д. могут быть аутентифицированы без необходимости для пользователей вручную устанавливать корневые сертификаты. Приложения обычно включают более сотни корневых сертификатов из десятков PKI, таким образом, по умолчанию предоставляя доверие по всей иерархии сертификатов, которые ведут к ним.
WOT выступает за децентрализацию якорей доверия, чтобы предотвратить компрометацию иерархии CA из-за единой точки отказа. [3]
Сеть доверия OpenPGP по существу не подвержена влиянию таких вещей, как сбои компаний, и продолжает функционировать с небольшими изменениями. Однако возникает связанная с этим проблема: пользователи, будь то частные лица или организации, которые теряют след закрытого ключа, больше не могут расшифровывать отправленные им сообщения, созданные с использованием соответствующего открытого ключа, найденного в сертификате OpenPGP. Ранние сертификаты PGP не включали даты истечения срока действия, и эти сертификаты имели неограниченный срок действия. Пользователи должны были подготовить подписанный сертификат отмены на тот момент, когда соответствующий закрытый ключ был утерян или скомпрометирован. Один очень известный криптограф до сих пор шифрует сообщения с использованием открытого ключа, для которого он давно потерял след закрытого ключа. [4] Они не могут сделать многого с этими сообщениями, кроме как отбросить их, уведомив отправителя о том, что они нечитаемы, и запросив повторную отправку с открытым ключом, для которого у них все еще есть соответствующий закрытый ключ. Более поздние PGP и все сертификаты, совместимые с OpenPGP, включают даты истечения срока действия, которые автоматически исключают такие проблемы (в конечном итоге) при разумном использовании. Эту проблему также можно легко обойти, используя «назначенных отзывающих», которые были введены в начале 1990-х годов. Владелец ключа может назначить третью сторону, которая имеет разрешение отзывать ключ владельца ключа (в случае, если владелец ключа потеряет свой собственный закрытый ключ и, таким образом, потеряет возможность отзывать свой собственный открытый ключ).
Нетехническая, социальная трудность с Web of Trust, подобной той, что встроена в системы типа PGP/OpenPGP, заключается в том, что каждая сеть доверия без центрального контроллера (например, CA ) зависит от других пользователей в плане доверия. Те, у кого есть новые сертификаты (т. е. созданные в процессе генерации новой пары ключей), вряд ли будут легко доверять системам других пользователей, то есть тем, с кем они лично не встречались, пока они не найдут достаточно подтверждений для нового сертификата. Это связано с тем, что многие другие пользователи Web of Trust будут иметь проверку сертификатов, требующую одного или нескольких полностью доверенных подтверждающих лиц неизвестного сертификата (или, возможно, нескольких частичных подтверждающих лиц) перед использованием открытого ключа в этом сертификате для подготовки сообщений, проверки подписей и т. д.
Несмотря на широкое использование совместимых с OpenPGP систем и легкую доступность многосерверных ключей в режиме онлайн , на практике может оказаться невозможным легко найти кого-то (или нескольких человек) для подтверждения нового сертификата (например, путем сравнения физической идентификации с информацией о владельце ключа, а затем цифровой подписи нового сертификата). Например, пользователи в отдаленных или неразвитых районах могут обнаружить, что других пользователей мало. И если сертификат другого также новый (и без или с небольшим количеством подтверждений от других), то его подпись на любом новом сертификате может дать лишь незначительную выгоду для того, чтобы стать доверенным для систем других сторон и, таким образом, иметь возможность безопасно обмениваться сообщениями с ними. Стороны, подписывающие ключи, являются относительно популярным механизмом для решения этой проблемы поиска других пользователей, которые могут установить ваш сертификат в существующих сетях доверия, подтвердив его. Также существуют веб-сайты для облегчения поиска других пользователей OpenPGP для организации подписания ключей. Паутина доверия Gossamer [ нерабочая ссылка ] также упрощает проверку ключей, связывая пользователей OpenPGP через иерархическую сеть доверия, где конечные пользователи могут извлечь выгоду из случайного или определенного доверия к тому, кто одобрен в качестве поручителя, или путем явного доверия ключу верхнего уровня GSWoT как минимум в качестве поручителя уровня 2 (ключ верхнего уровня одобряет поручителей уровня 1).
Возможность нахождения цепочек сертификатов часто оправдывается «феноменом маленького мира »: если взять двух людей, то часто можно найти короткую цепочку людей между ними, так что каждый человек в цепочке знает предыдущие и последующие ссылки. Однако такая цепочка не обязательно полезна: человек, шифрующий электронное письмо или проверяющий подпись, должен не только найти цепочку подписей от своего закрытого ключа до ключа своего корреспондента, но и доверять каждому человеку в цепочке, чтобы быть честным и компетентным в вопросе подписания ключей (то есть, они должны судить, будут ли эти люди честно следовать указаниям о проверке личности людей перед подписанием ключей). Это гораздо более сильное ограничение.
Другим препятствием является требование физической встречи с кем-либо (например, на вечеринке по подписанию ключей ) для проверки его личности и права собственности на открытый ключ и адрес электронной почты, что может повлечь за собой расходы на поездку и ограничения по графику, затрагивающие обе стороны. Пользователю программного обеспечения может потребоваться проверить сотни компонентов программного обеспечения, созданных тысячами разработчиков по всему миру. Поскольку основная масса пользователей программного обеспечения не может лично встретиться со всеми разработчиками программного обеспечения, чтобы установить прямое доверие, им вместо этого приходится полагаться на сравнительно более медленное распространение косвенного доверия. [ необходима цитата ]
Получение ключа PGP/GPG автора (или разработчика, издателя и т. д.) с сервера открытого ключа также представляет риск, поскольку сервер ключа является сторонним посредником , который сам по себе уязвим для злоупотреблений или атак. Чтобы избежать этого риска, автор может вместо этого выбрать публикацию своего открытого ключа на своем собственном сервере ключей (т. е. веб-сервере, доступном через доменное имя, принадлежащее ему, и безопасно расположенном в его личном офисе или дома) и потребовать использования зашифрованных HKPS соединений для передачи своего открытого ключа. Подробности см. в разделе WOT Assisting Solutions ниже.
Сильный набор относится к самому большому набору сильно связанных ключей PGP . [5] Это формирует основу для глобальной сети доверия. Любые два ключа в сильном наборе имеют путь между ними; в то время как острова наборов ключей, которые подписывают друг друга только в несвязанной группе, могут существовать и существуют, только одному члену этой группы нужно обменяться подписями со сильным набором, чтобы эта группа также стала частью сильного набора. [6] Сильный набор имел размер около 55000 ключей в начале 2015 года. [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 и т. д. с любого сервера поддоменов или с любого зеркала или с любых общих облачных/хостинговых серверов, поскольку загруженные элементы/данные/файлы на основе незашифрованного соединения могут быть позже аутентифицированы с помощью оригинальных открытых ключей/подписанных кодов, которые были получены с собственного сервера автора/разработчика по защищенным, зашифрованным и доверенным (т. е. проверенным) соединениям/каналам.
Используя зашифрованное соединение для передачи ключей или подписанного/подписанного кода/файлов, пользователи программного обеспечения могут делегировать свое доверие PKI TTPA ( доверенному стороннему органу сертификации), например, публичному CA (центру сертификации), чтобы обеспечить надежное соединение между исходным веб-сервером разработчика/автора и миллионами компьютеров пользователей по всему миру в любое время.
Когда доменное имя и сервер имен исходного автора/разработчика подписаны DNSSEC , и когда используемый открытый сертификат SSL/TLS объявлен/отображается в записи ресурса DNS TLSA/ DANE DNSSec (и когда сертификаты SSL/TLS в цепочке доверия закреплены и используются веб-серверами с помощью техники HPKP ), то веб-страницу или данные веб-сервера также можно проверить с помощью другого PKI TTPA : DNSSEC и обслуживающего пространства имен DNS ICANN , отличного от открытого центра сертификации. DNSSEC — это еще одна форма PGP/GPG WOT, но для серверов имен; он сначала создает доверенную цепочку для серверов имен (вместо людей/персон), а затем ключи PGP/GPG и отпечатки пальцев людей/персон также можно добавить в записи 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-резолвере/сервере на основе DNSSEC, и если владельцы доменов также используют его для дополнительной подписи своих собственных доменных имен, то может быть новый третий TTPA. В таком случае любые данные ключа PGP/GPG/подписанного кода или веб-страницы или веб-данных могут быть проверены по трем/трем каналам. Сам DLV ISC может использоваться в качестве третьего TTPA, поскольку он по-прежнему широко используется и активен, поэтому наличие другого нового DLV станет четвертым TTPA.
Брюс потерял ключ PGP почти десять лет назад; он до сих пор получает электронную почту, зашифрованную с помощью соответствующего сертификата.