Сеть доверия - Web of trust

Информацию о веб-сайте безопасности в Интернете см. Услуги WOT.
Принципиальная схема сети доверия

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

Концепция сети доверия была впервые предложена создателем PGP. Фил Циммерманн в 1992 г. в руководстве для PGP версии 2.0:

Со временем вы будете накапливать ключи от других людей, которых, возможно, захотите назначить надежными посредниками. Все остальные выберут своих доверенных представителей. И каждый будет постепенно накапливать и распространять со своим ключом коллекцию удостоверяющих подписей от других людей, ожидая, что любой, кто ее получит, будет доверять хотя бы одной или двум подписям. Это вызовет появление децентрализованной отказоустойчивой сети доверия для всех открытых ключей.

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

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

Реализации, совместимые с OpenPGP, также включают схему подсчета голосов, которая может использоваться для определения того, какой ассоциации открытого ключа и владельца будет доверять пользователь при использовании PGP. Например, если три частично доверенных индоссатора поручились за сертификат (и, следовательно, включенный в него открытый ключ - владелец привязка ), или, если это сделал один полностью доверенный индоссант, связь между владельцем и открытым ключом в этом сертификате будет считаться правильной. Параметры настраиваются пользователем (например, без партиалов вообще или, возможно, с шестью частями), и при желании их можно полностью обойти.

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

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

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

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

В отличие от типичного PKI

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

WOT выступает за децентрализацию якорей доверия, чтобы предотвратить нарушение единой точки отказа в иерархии CA.[1] Известный проект, который использует WOT против PKI для обеспечения основы для аутентификации в других областях Интернета, - это утилиты Monkeysphere.[2]

Проблемы

Потеря приватных ключей

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

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

Нетехническая социальная проблема с сетью доверия, подобной той, которая встроена в системы типа PGP / OpenPGP, заключается в том, что каждая сеть доверия без центрального контроллера (например, CA ) зависит от доверия других пользователей. Те, у кого есть новые сертификаты (т. Е. Созданные в процессе генерации новой пары ключей), вряд ли будут пользоваться доверием со стороны систем других пользователей, то есть тех, с которыми они лично не встречались, пока они не найдут достаточно подтверждений для нового сертификата. Это связано с тем, что для многих других пользователей Web of Trust будет настроена проверка сертификатов таким образом, чтобы требовать одного или нескольких полностью доверенных лиц, подтверждающих неизвестный в противном случае сертификат (или, возможно, нескольких частично подтверждающих), прежде чем использовать открытый ключ в этом сертификате для подготовки сообщений, верьте подписям, и Т. Д.

Несмотря на широкое использование OpenPGP-совместимых систем и легкую доступность нескольких ключевые серверы, на практике может оказаться невозможным легко найти кого-то (или нескольких человек) для подтверждения нового сертификата (например, путем сравнения физической идентификации с информацией о владельце ключа и последующей цифровой подписи нового сертификата). Например, пользователи в удаленных или неосвоенных районах могут столкнуться с дефицитом других пользователей. И, если другой сертификат также является новым (и без поддержки или с небольшим количеством одобрений со стороны других), то его подпись на любом новом сертификате может дать лишь незначительную выгоду для того, чтобы стать доверенным для систем других сторон и, таким образом, иметь возможность безопасно обмениваться сообщениями с ними. . Ключевые стороны подписания являются относительно популярным механизмом для решения этой проблемы поиска других пользователей, которые могут установить свой сертификат в существующие сети доверия, подтвердив его. Веб-сайты также существуют, чтобы облегчить расположение других пользователей OpenPGP для организации подписания ключей. В Паутина доверия также упрощает проверку ключей, связывая пользователей OpenPGP через сеть доверия в иерархическом стиле, где конечные пользователи могут извлечь выгоду из случайного или определенного доверия кого-то, кто одобрен в качестве представителя, или путем явного доверия к ключу верхнего уровня GSWoT, как минимум, как представителю уровня 2 (ключ верхнего уровня поддерживает представителей уровня 1).

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

Еще одно препятствие - это необходимость физически встретиться с кем-то (например, в вечеринка для подписания ключей ) для проверки своей личности и владения открытым ключом и адресом электронной почты, что может повлечь за собой командировочные расходы и ограничения расписания, затрагивающие обе стороны. Пользователю программного обеспечения может потребоваться проверка сотен программных компонентов, созданных тысячами разработчиков по всему миру. Поскольку основная масса пользователей программного обеспечения не может лично встретиться со всеми разработчиками программного обеспечения для установления прямого доверия, они должны вместо этого полагаться на сравнительно более медленное распространение косвенного доверия.[нужна цитата ]

Получение ключа PGP / GPG автора (или разработчика, издателя и т. Д.) С сервера открытых ключей также представляет риски, так как сервер ключей является сторонним. посредник, сам уязвим для злоупотреблений или атак. Чтобы избежать этого риска, автор может вместо этого опубликовать свой открытый ключ на своем собственном сервере ключей (т. Е. Веб-сервер, доступный через принадлежащее ему доменное имя и надежно расположенный в его личном офисе или доме) и потребовать использования Соединения с шифрованием HKPS для передачи своего открытого ключа. Подробнее см. Вспомогательные решения WOT ниже.

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

В сильный набор относится к самой большой коллекции сильно связанный PGP ключи.[4] Это формирует основу глобальной сети доверия. Любые два ключа в сильном наборе имеют путь между ними; в то время как островки наборов ключей, которые подписывают друг друга только в отключенной группе, могут существовать и существуют, только один член этой группы должен обмениваться подписями со строгим набором, чтобы эта группа также стала частью строгого набора.[5] На начало 2015 года сильный набор имел размер около 55000 ключей.[6]

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

Изображение с объяснением доверия на основе MSD
Объяснение доверия на основе MSD

В статистическом анализе PGP /GnuPG /OpenPGP Сеть доверия среднее кратчайшее расстояние (MSD) является одним из показателей того, насколько «доверенным» является данный ключ PGP в прочно связанном наборе ключей PGP, составляющих сеть доверия.

MSD стал обычным показателем для анализа наборов ключей PGP. Очень часто вы увидите, что MSD вычисляется для данного подмножества ключей и сравнивается с глобальный MSD что обычно относится к ранжированию ключей в рамках одного из более крупных ключевых анализов глобальной сети доверия.

Вспомогательные решения WOT

Физическая встреча с первоначальным разработчиком или автором - это всегда лучший способ получить, распространить, проверить и доверять ключам 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 публичный сертификат объявлен / показан в TLSA /ДЕЙН 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) в своем локальном DNS-резолвере / сервере на основе DNSSEC, и если владельцы доменов также используют его для дополнительной подписи своих собственных доменных имен, тогда там может быть новая третья ТТПА. В таком случае любые данные PGP / GPG Key / подписанного кода или веб-страницы или веб-данные могут быть трех- или трехканальными. ISC Сам DLV может использоваться в качестве третьего TTPA, поскольку он все еще широко и активно используется, поэтому доступность еще одного нового DLV станет четвертым TTPA.

Смотрите также

Рекомендации

  1. ^ Соловей, Джонатан. "Поддельный сертификат * .google.com". Получено 29 августа 2011.
  2. ^ "Проект" Обезьянья сфера ". Получено 13 декабря 2016.
  3. ^ Фергюсон, Нильс; Шнайер, Брюс (2003). Практическая криптография. Вайли. п. 333. ISBN  978-0471223573. Брюс потерял ключ PGP почти десять лет назад; он по-прежнему получает электронную почту, зашифрованную с помощью соответствующего сертификата.
  4. ^ Пеннинг, Хенк. "в сети доверия apache.org". В архиве из оригинала 14 декабря 2013 г.. Получено 13 декабря 2013.
  5. ^ Стрейб, М. Дрю. «Объяснение этого анализа связки ключей». Архивировано из оригинал 3 февраля 2009 г.. Получено 13 декабря 2013.
  6. ^ Пеннинг, Хенк П. "анализ сильных сторон сети доверия PGP". Получено 8 января 2015.

дальнейшее чтение

внешняя ссылка