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