Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

2006 г.

Руководство GNU по обеспечению конфиденциальности

© FSF 1999-2005. Перевод — Павел Шайдо

Страницы: предыдущая :: оглавление :: 1 :: 2 :: 3 :: 4 :: 5 :: 6 :: 7 :: 8 :: 9 :: 10 :: 11 :: 12 :: 13 :: 14 :: 15 :: 16 :: 17 :: 18 :: 19 :: 20 :: 21 :: 22 :: 23 :: 24 :: 25 :: 26 :: 27 :: 28 :: 29 :: 30 :: 31 :: следующая

Проверка достоверности ключей

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

GnuPG решает эту проблему при помощи механизма именуемого сеть доверия (web of trust). В модели сети доверия ответственность за проверку открытых ключей возложена на людей, которым Вы доверяете. Например, предположим

  • Элис подписала ключ Блэйка, а

  • Блэйк подписал ключи Хлой и Дхармы.

Если Элис уверена, что Блэйк проверяет достоверность ключей, которые он подписывает, то Элис может быть уверена, что ключи Хлой и Дхармы достоверны не проверяя их лично. Она просто использует свою достоверную копию открытого ключа Блэйка для проверки его подписи на ключах Хлой и Дхармы. Вообще, предполагая, что Элис совершенно уверена, что все правильно проверяют ключи, перед тем как их подписать, то любой ключ, подписанный достоверным ключом, будет достоверным.

Доверие владельцу ключа

На практике доверие субъективно. Например, ключ Блэйка достоверен, т.к. Элис подписала его, но она может не быть уверена, что Блэйк правильно проверяет ключи, которые он подписывает. В этом случае, она не будет считать ключи Хлой и Дхармы достоверными, основываясь на подписи Блэйка. Модель сети доверия решает эту задачу связывая с каждым открытым ключом в Вашем наборе значение указывающее уровень Вашего доверия владельцу ключа. Имеется пять уровней доверия.

unknown (неизвестное)

Ничего не известно о политике подписания ключей данным владельцем. Ключам в Вашем наборе, кроме Вашего собственного, первоначально присваивается этот уровень доверия.

none (нет)

Известна недобросовестность этого лица при подписи чужих ключей.

marginal (граничное)

Понимает смысл подписания ключей и проверяет их достоверность перед тем, как подписывать.

full (полное)

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

ultimate (безоговорочное)

Владельцу данного ключа Вы верите как самому себе.

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

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

alice% gpg --edit-key blake

pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: -/f
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Command> trust
pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: -/f
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?

 1 = Don't know
 2 = I do NOT trust
 3 = I trust marginally
 4 = I trust fully
 5 = I trust ultimately
 i = please show me more information
 m = back to the main menu
 
Your decision? 3
                
pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: m/f
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Доверие владельцу ключа и достоверность ключа выводятся справа от ключа, когда выводится ключ. Доверие владельцу выводится первым, достоверность ключа второй[5]. Пять уровней доверия/достоверности обозначаются символами: неизвестный (q), нет (n), граничный (m), полный (f), безоговорочный (u). В этом случае, ключ Блэйка полностью достоверен, т.к. Элис сама подписала его. Изначально установлено неизвестное доверие относительно правильности подписи Блэйком ключей, но Элис решает установить граничный уровень доверия.

Использование доверия для проверки достоверности ключей

Сеть доверия позволяет использовать весьма гибкий алгоритм для проверки достоверности ключа. Если прежде достоверными считались только те ключи, которые Вы подписали лично, то теперь используется следующий алгоритм. Ключ K считается достоверным, если он удовлетворяет следующим двум условиям:

  1. он подписан достаточным количеством достоверных ключей, т.е.

    • Вы подписали его лично (или обладатель ключа, которому Вы безоговорочно доверяете),

    • он был подписан ключом владельцу которого Вы полностью доверяете, или

    • он был подписан тремя ключами с граничным уровнем доверия владельцу; и

  2. цепочка подписанных ключей начинающаяся с K и заканчивающаяся Вашим ключом не длиннее пяти ключей.

Длина цепочки, число требуемых ключей с граничным уровнем доверия и число ключей с полным доверием может быть изменено при помощи параметров --max-cert-depth, --marginals-needed и --completes-needed. Цифры приведенные выше - значения используемые GnuPG по умолчанию.

Рисунокљ3.1, Пример сети доверия рассмотрим сеть доверия начинающуюся с Элис. Граф иллюстрирует кто подписал чей ключ. Таблица показывает ключи, которые Элис признает достоверными основываясь на доверии другим членам сети. Этот пример предполагает, что для признания другого ключа достоверным требуется два ключа с граничным доверием или один с полным. Максимальная длина цепочки равна трем.

При вычислении достоверности ключей, в этом примере, ключи Блэйка и Дхармы всегда считаются полностью достоверными, т.к. они подписаны Элис. Достоверность других ключей зависит от доверия. В первом случае, доверие Дхарме полное, что делает ключи Хлой и Фрэнсиса полностью достоверными. Во втором случае, доверие Блэйку и Дхарме граничное. Т.к. два ключа с граничным доверием требуется для подтверждения достоверности ключа, ключ Хлой будет признан полностью достоверным, но достоверность ключа Фрэнсиса будет только частично подтверждена. В случае граничного доверия Хлой и Дхарме, ключ Хлой будет частично достоверен, а ключ Дхармы полностью достоверен. Ключ Фрэнсиса будет частично достоверен, т.к. только полностью достоверный ключ может быть использован для подтверждения достоверности других ключей, а единственный полностью достоверный ключ, которым подписан ключ Фрэнка, это ключ Дхармы. После добавления граничного доверия Блэйку ключ Хлой становится полностью достоверным и может быть использован для полного подтверждения достоверности ключа Фрэнсиса и частичного подтверждения достоверности ключа Елены. Наконец, если доверие Блэйку, Хлой и Елене полное, этого все еще не достаточно для подтверждения достоверности ключа Джефа, т.к. максимальная длина цепочки подтверждения равна трем, но путь от Джефа к Элис равен четырем.

Модель сети доверия реализует гибкий подход к проблеме безопасного обмена ключами. Она позволяет настраивать GnuPG в соответствии с Вашими потребностями. Вы можете требовать много коротких цепочек от Вашего ключа до ключа K для признания его достоверным. С другой стороны, Вы можете быть удовлетворены одной длинной цепочкой. Требование многочисленных коротких цепочек - сильная гарантия того, что ключ K принадлежит тому, на кого указывает его идентификатор пользователя. Цена за такую надежность, конечно, выше, т.к. Вы лично должны проверить и подписать большее количество ключей, чем в случае когда Вас устраивает небольшое число длинных цепочек.

Рисунок 3.1. Пример сети доверия

Граф, показывающий кто подписал чей ключ.
довериедостоверность
граничноеполноеграничнаяполная
љДхармаљБлэйк, Хлой, Дхарма, Фрэнсис
Блэйк, ДхармаљФрэнсисБлэйк, Хлой, Дхарма
Хлой, ДхармаљХлой, ФрэнсисБлэйк, Дхарма
Блэйк, Хлой, ДхармаљЕленаБлэйк, Хлой, Дхарма, Фрэнсис
љБлэйк, Хлой, ЕленаљБлэйк, Хлой, Елена, Фрэнсис


[5] GnuPG перегружает слово ``доверие'' используя его в смысле доверия владельцу и в смысле доверия ключу. Это может вызвать путаницу. Иногда доверие владельцу указывается прямо. В основном, в этом руководстве, термин ``доверие'' используется в смысле доверия владельцу ключа и термин ``достоверность'' для обозначения уверенности в том, что ключ принадлежит человеку указанному идентификатором пользователя.

Страницы: предыдущая :: оглавление :: 1 :: 2 :: 3 :: 4 :: 5 :: 6 :: 7 :: 8 :: 9 :: 10 :: 11 :: 12 :: 13 :: 14 :: 15 :: 16 :: 17 :: 18 :: 19 :: 20 :: 21 :: 22 :: 23 :: 24 :: 25 :: 26 :: 27 :: 28 :: 29 :: 30 :: 31 :: следующая

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...