Введение в PKI: различия между версиями
Содержимое удалено Содержимое добавлено
→Концепции PKI: исправил исправленную опечатку |
ЕссБот (обсуждение | вклад) м замена категории на шаблон для работы полки, removed: Категория:Компьютеры с помощью AWB |
||
Строка 21:
Как понятно из английских названий, публичный (открытый) ключ мы предоставляем публике, а приватный (закрытый) храним <s>у себя в чулане</s> в секрете от всех остальных. Любой желающий может зашифровать некий текст (публично известным) открытым ключом и послать его нам. НИКТО, повторю, НИКТО (даже ФСБ, ФНС, ОБЭБ, ООН, ОБСЭ, МАГАТЕ, МАРДУК, ФБР и т.д.) не сможет расшифровать его (не применив силовые методы к отправителю/получателю, но это уже другой вопрос). НИКТО, у кого нет закрытого ключа НЕ МОЖЕТ расшифровать это сообщение. А владелец закрытого ключа (получатель) - может. Заметим, что пара открытый-закрытый ключ должны быть именно ПАРОЙ, какой попало закрытый ключ шифр от какого попало открытого ключа не сможет расшифровать. Таким образом, дав другу открытый ключ (его можно не прятать, так как обладание им никому ничем не поможет, и "дать другу" можно, например, по электронной почте или выложив на веб-сайте), вы дадите ему возможность отправить вам сообщение в зашифрованном виде, которое расшифровать можете только вы. Кстати, если друг пришлёт вам свой открытый ключ (из своей пары ключей, сохранив в <s>уютной нычке</s> секрете свой закрытый ключ), то вы так же сможете ему отправить сообщение в зашифрованном виде.
Оппа. Лёгкое движение <s>руками</s> мозгом - и у нас защищённый канал связи, который можно прослушивать сколько влезет, но из которого не получится ничего понять (кроме факта шифрованной переписки). Заметим, для установления защищённого канала связи мы даже не предпринимали каких-то серьёзных усилий (вроде передачи шифроблокнотиков резиденту, паролей и явок).
Это и есть суть ассиметричной криптографии.
Строка 27:
=== Подпись ===
Из криптографии мы возьмём ещё одну важную вещь: криптохэш. Что такое хеш? Функция, которая из произвольного набора данных формирует данные заданного размера. Например, и из 1 байта, и из 1024 Гб эта функция сделает, например, 128 бит. По мере возможности, различающиеся в зависимости от входных данных. Понятно, что будут совпадения (например, данные №1 и данные №2 дают одинаковый хэш), но это будет происходить ...м... скажем так, не всегда. Такие совпадения называются ''колллизией''. Что коллизии есть у каждого хэша легко показать: если у нас хеш даёт N-бит из любого набора данных, то всего есть 2<sup>N</sup> различных значений хеша. Очевидно, что если мы на вход дадим 2<sup>N</sup>+1 данных, то хотя бы для двух значений хеш будет одинаковым (т.е. будет как минимум одна коллизия). Заметим, что хеши не идеальны, и обычно коллизий чуть больше, чем хотелось бы.
''Криптохеш'' - это такой хэш, который трудно подобрать. На самом деле требовний к хешу много. Процитируем Википедию:
Требования к криптохешу:
Строка 62:
Проблема получения правильного открытого ключа - это первая проблема. Вторая проблема: предположим, что закрытый ключ пользователя украли. Как ему оповестить всех людей, с кем у него защищённый обмен информацией о краже? А об утрате? Если он это сделает с помощью незащищённых каналов связи, то и злоумышленник может заявить (якобы от лица пользователя): "ключ украли, компьютер сломали, не слушайте больше писем с этим ключом". Т.е. вся защита держится на личном доверии, каких-то других каналах связи? Или вообще ни на чём не держится?
Главная проблема, которую можно выделить из этих примеров: пользователь не имеет возможности проверить, что ключ '''A''' принадлежит пользователю A. Любой другой пользователь (злоумышленник) может сделать то же самое, что пользователь A, и назвать себя пользователем A.
Как решить эту задачу?
Главная "правда" PKI состоит в том, что подобная задача не может быть решена только средствами криптографии. Необходима некая договорённость между использующими ключи людьми о том, как именно доказывать связь ключа и пользователя. Решение этого вопроса - и есть суть PKI. Дополнительно же, помимо "главной задачи" решается ещё несколько очень важных задач, позволяющих обеспечить множество видов дополнительного криптографического сервиса.
Строка 73:
'''Идентичность''' — набор данных о субъекте (не обязательно человеке), позволяющий отличить субъекта от всех остальных возможных субъектов. Это может быть набор паспортных данных (вполне себе идентичность человека) или реквизиты юрлица (аналогично, но для организаций). А ещё это может быть емейл. Глупо? Зато удобно. В суде такое не примут, а вот в большинстве других случаев (например, при шифровке переписки) - емейла вполне достаточно. Ведь он позволяет однозначно отличить один емейл от другого.
Собственно, те, кто выступает в качестве субъектов криптографии (т.е. тех, кто что-то подписывает, шифрует, прячет и т.д.), так и называют ''субъект криптографии''.
'''Доверие''' - это фундаментальная идея всей инфрастрктуры открытых ключей. Все связи внутри инфраструктуры - это указание на то, кто кому что и как доверяет . Точно определить термин "доверие" сложно, и для практических нужд PKI используется следующая: "А доверяет Б, если поведение Б соответствует ожидаемому А". Другими словами, если мы кому-то доверяем (деньги), то мы уверены, что этот человек будет себя вести так, как мы ожидаем (в хорошем смысле).
Заметим, что доверие редко бывает всеобщим. Обычно мы доверяем в каком-то конкретном вопросе (или наборе вопросов).
Эти два понятия "идентичность" и "доверие" являются основой для построения PKI.
=== Сертификат ===
Определение сертификата очень простое:
'''сертификат''' - подписанная доверенной стороной связь между идентичностью и её открытым ключом (-ами).
На самом деле в этом определении очень много того, о чём мы пока не говорили. Оставим в стороне "подписанная доверенной стороной" (об этом позже). Сфокусируемся на "связь между идентичностью и открытым ключом".
Строка 90:
Фактически, сертификат - это ключ, к которому дописали, чей это ключ. Мы открываем сертификат и видим, что он принадлежит Васе Пупкину. Значит, подписи сообщения от Васи Пупкина следует проверять указанным открытым ключом, и шифровать письма Васе Пупкину надо так же этим открытым ключом.
Однако, просто указание на имя (емейл) и открытый ключ не достаточно - такая конструкция ничем не отличается от предыдущей (электронное письмо "мой открытый ключ XXX-XXX-XXX-XXX, С уважением, Вася Пупкин"). Нужны какие-то объективные доказательства того, что ключ Васи Пупкина - это таки ключ Васи Пупкина. И Вася Пупкин - это именно ТОТ Вася, о котором мы думаем.
В принципе, если подумать, то если связь "вася пупкин + открытый ключ" подпишет кто-то из тех, чей ключ мы знаем (уже), то это добавит нам уверенности. Но только в том случае, если этот "кто-то" нам знаком и мы ему доверяем. А если нет?
Строка 101:
'''Удостоверяющий центр''' (УЦ) ({{lang-en|Certificate authority}}) — точка доверия, которая подписывает сертификаты. (то самое "...подписанная доверенной стороной..." из определения сертификата). В чём доверяют УЦ? Это вопрос очень сложный и о нём мы поговорим много позже, пока, для удобства изложения, будем считать, что как минимум, доверяют правильности заполнения полей, описывающих идентичность в сертификате. Т.е. УЦ действительно подтверждает, что сертификат, выданный на имя Васи Пупкина выдан именно Васе Пупкину.
Кстати, нетривиальный момент: что означает "выдан?" (ведь сертификат, как и открытый ключ, вероятнее всего, будет публично доступен) Есть ли разница, кому именно отдадут файл сертификата?
'''Выдача сертификата''' — это заверение цифровой подписью открытого ключа и идентичности. Другими словами, "выдача сертификата", это не передача каких-то данных, а проверка, что у Васи Пупкина есть закрытый ключ, соответствующий открытому ключу в сертификате. В первом (грубом) приближении, УЦ делает две вещи: проверяет (например) паспортные данные Васи Пупкина и проверяет, что Вася Пупкин имеет закрытый ключ, соответствующий открытому ключу, добавляемому в сертификат.
Об УЦ мы будем ещё много говорить (там есть много сложностей и нюансов), а пока примем как грубую модель, что УЦ связывает идентичность и открытый ключ.
'''Сертификат УЦ'''. Есть ещё один важный момент. УЦ подписывает сертификат своим закрытым ключом. Мы хотим проверить сертификат. Это значит, что мы должны иметь открытый ключ УЦ (ну, или, точнее, его сертификат). Откуда он у нас? Есть два варианта:
Строка 111:
# Сертификат УЦ может быть подписан самим УЦ. (конец цепочки).
Самоподписанный (иногда говорят "самовыданный") сертификат — это очень сложная штука. Можем ли мы ему доверять? НЕТ! Любой проходимец может подписать себе сертификат представившись именем крупного банка - и, разумеется, мы не будем ему доверять на этом основании.
... Только если мы не знаем точно, что это сертификат крупного банка. Тогда, разумеется, мы можем ему доверять. Как различить проходимца от настоящего УЦ (которому мы можем доверять)?. '''PKI не даёт ответа о том, каким корневым УЦ следует доверять, а каким нет'''. Этот вопрос следует решить человеку самостоятельно. (Иногда за него думают производители операционных систем, включающих некоторые УЦ в список "доверенных корневых удостоверяющих центров").
Таким образом, самоподписанный сертификат является лишь формальностью (начальной точкой для дерева доверия), но ничего не доказывает с точки зрения PKI. Единственное, что доказывает этот сертификат, что выпускающий самоподписанный сертификат УЦ обладает соответствующим закрытым ключом (т.к. подпись можно сделать только с помощью закрытого ключа). Всё. Все остальные вопросы - правда написана в идентичности сертификата или нет, можно ему доверять или нет - эти все вопросы следует решить ДО начала использования сертификата.
Фактически, наличие самоподписанных сертификатов УЦ, является одним из допущений PKI (наравне с существованием хорошей ассиметричной криптографии и криптохешей), в рамках которой модель PKI действует. Если бы мы были занудными математиками, то мы бы сказали что-то вроде: "Допустим, что у нас есть хорошие криптохеши и работающая ассиметричная криптография. Если пользователь доверяет хотя бы одному доверенному УЦ, то...".
Количество доверенных УЦ у каждого пользователя своё. Кто-то доверяет УЦ компании "Рога и Копыта", а кто-то сомневается. Возможно, есть параноик, который вообще никому не верит. (Кстати, вполне себе PKI, в которой нет ни одного доверенного удостоверяющего центра, одни враги кругом).
Соответственно, понятие "доверенный УЦ" (с упором на слово "доверенный") - это субъективное понятие каждого из субъектов криптографии. Кто-то верит, кто-то нет. Что произойдёт, если мы столкнёмся с подписью, сертификат которой заверен недоверенным УЦ? Поведение может отличаться от программы к программе: кто-то скажет "нет доверия, продолжить?", кто-то молча проигнорирует (как бы если бы подписи не было), кто-то запишет в журнал безопасности кляузу "пользователь А проверил подпись пользователя Б, заверенную УЦ, которому нет доверия".
Каким УЦ следует доверять пользователю? Точнее, кто это решает? На первый взгляд - сам пользователь и решает. Иногда. Но не всегда. Например, работодатель может решить, что пользователь должен доверять некоему УЦ (причём, обязательно). Так тоже бывает.
А бывает так, что пользователь сам себе УЦ (кого подписал, тому доверяешь, кому не подписал - не доверяешь).
Строка 163:
=== Инфраструктура индивидуального УЦ ===
Это самая простая инфраструктура для аморфного сообщества независимых пользователей. Не существует каких-либо единых стандартов взаимодействия, подчинения и доверия. Доверие формулируется каждым пользователем в отношении каждого пользователя самостоятельно (верю/не верю). Доверие может быть не двусторонним (Вася Пупкин верит Президенту, но Президент не верит Васе Пупкину).
(Побочным эффектом личного решения "верю/не верю" является требование глубокого понимания каждым участником принципов работы системы, очевидно, что 90-летний колхозник не сможет внятно ответить на вопрос, доверяет ли он Бабе Мане (85 лет, доярка) право удостоверять личности третьих лиц своей цифровой подписью).
Строка 169:
В такой схеме каждый человек имеет свою пару ключей и самоподписанный сертификат. Получив сертификаты других лиц пользователь решает в отношении каждого из них "верю/не верю" (и если верю, то до какой степени). В принципе, если доверенный друг подписал сертификат постороннего лица, то мы можем поверить, что это таки сертификат постороннего лица. Денег ему мы не дадим, но хотя бы будем уверены, что идентичность лица совпадает с заявленной в подписи. Более того, уровень доверия чужим подписям (чьей подписи на сертификате третьего лица мы верим, а чьей нет) определяет сам пользователь (или ПО исходя из заданных пользователем же весовых коэфицентов: три подписи с уровнем доверия пять, то же самое, что одна подпись с уровнем 10).
Множество пользователей строит множество отдельных "звёзд" доверия. Каждая звезда сходится к пользователю, который, собственно, её и формирует. (У одного будет 3 лучика, у другого сотня с гаком).
Подобная схема используется, например, в системе Gnu PG, где пользователи самостоятельно создают свои сертификаты.
Строка 181:
Первая инфраструктура, в которой можно вообще задуматься о необходимости УЦ. Схема простая: есть УЦ, есть пользователи (серверы и т.д.). УЦ выписывает сертификаты для всех, кого нужно. Все доверяют "своему" УЦ и таким образом могут проверить, что предъявителю сертификат выдан тем же самым УЦ.
Подобная инфраструктура обладает минимальной сложностью в управлении, за что её, собственно, и используют. Главным минусом подобной инфраструктуры является однозначная централизация управления (что в большинстве случаев является благом, а в меньшинстве - критической проблемой). У такого УЦ есть единая точка компрометации (по аналогии с единой точкой отказа) - если закрытый ключ УЦ по халатности или в результате злого умысла похищен, то это СТРОГО эквивалентно похищению всех закрытых ключей всех пользователей сети. В рамках PKI утрата (разглашение) ключа УЦ - это катастрофа, означающая полное прекращение существования инфраструктуры (нужно строить новую, с нуля, выписывать всем новые сертификаты). А для разглашения не так-то и много нужно - например, "утёкший" бэкап сервера, на котором стоит CA.
В большинстве конфигураций, где применяется такая инфраструктура, УЦ администрируется одним лицом (или несколькими, без чёткого разделения полномочий), без сформулированных политик и регламента УЦ (о них чуть позже - но в кратце, это правила, согласно которым действует УЦ).
Строка 196:
Технически, корневой сервер может выпускать сертификаты для пользователей (схема, наподобие единственного УЦ), но, обычно, так не делают: корневой УЦ выписывает сертификаты ТОЛЬКО для подчинённых УЦ. Так как подчинённых УЦ обычно в разы (порядки, etc) меньше, чем пользователей, то использование корневого УЦ (а, значит, вероятность обшибки/компрометации) существенно меньше. Компрометация же ключа подчинённого УЦ обычно решается отзывом ключа "пострадавшего" (об отзыве ключей в следующих главах) - при этом почти никто не страдает (центр доверия - корневой УЦ как был так и остаётся). Единственными пострадавшими оказываются люди, чьи сертификаты оказались скомпрометированы (им нужно получить новые от нового УЦ).
Кажется, разницы в этом никакой? Ну был корневой, стал "второго уровня" - всё равно компрометация режет большую дыру в инфраструктуре (в случае одного УЦ - размером в инфраструктуру).
Тут есть большая разница: если компрометируется ключ промежуточного (подчинённого) УЦ, то при этом инфраструктура сохраняется: во-первых, не нужно менять доверенные сертификаты всюду, где им доверяли (по закону подлости их оказывается на 1-2 больше, чем число мест, где сертификат заменили). Во-вторых, нет никакого механизма оповещения о проблеме (только лично, по телефону или ножками...). В случае же компрометации промежуточного УЦ все во-первых оповещаются о том, что данные сертификаты перестали действовать, во-вторых нет необходимости что-то менять у проверяющих узлов. У тех же, у кого сертификаты перестанут приниматься, будет возможность запросить новые (т.е. пользователи явно получат уведомление о проблеме).
Строка 218:
== Зачем всё это нужно? ==
Основной вопрос: а зачем это нужно в реальной жизни? Если не рассматривать огромные, поросшие бюрократическим мхом, транснациональные корпорации и министерства?
Ответов два: во-первых, полное понимание инфраструктуры (точнее, вариантов построения инфраструктуры) - это лучше, чем неполное понимание или полное непонимание. В определенённые моменты времени может оказаться так, что таки придётся делать кросс-сертификацию для нескольких инфраструктур. В этом случае лучше понимать, что происходит, иначе последствия окажутся сильно хуже, чем кажется (например, неосторожно выписанный сертификат для чужого УЦ можем привести к автоматическому доверию сертификатам тысяч других УЦ, что, например, не есть цель сертификации).
Строка 258:
Первое: мы должны сформулировать понятие "идентичности". '''Идентичность''' — набор данных о субъекте (не обзяательно человеке), позволяющий отличить субъекта от всех остальных возможных субъектов. Это может быть набор паспортных данных (вполне себе идентичность человека) или реквизиты юрлица (аналогично, но для организаций). А ещё это может быть емейл. Глупо? Зато удобно. В суде такое не примут, а вот в большинстве других случаев (например, при шифровке переписки) - емейла вполне достаточно. Ведь он позволяет однозначно отличить один емейл от другого.
Собственно, те, кто выступает в качестве субъектов криптографии (т.е. тех, кто что-то подписывает, шифрует, прячет и т.д.), так и называют ''субъект криптографии''.
Второе: даже если мы можем проверить криптографическую целостность информации, можем ли мы ей ''доверять''? Нет, потому что доверие не строится на математике. Это внематематическая сущность. Точно определить термин "доверие" сложно, и для практических нужд PKI используется следующая: "А доверяет Б, если поведение Б соответствует ожидаемому А". Другими словами, если мы кому-то доверяем (деньги), то мы уверены, что этот человек будет себя вести так, как мы ожидаем (в хорошем смысле).
Заметим, что доверие редко бывает всеобщим. Обычно мы доверяем в каком-то конкретном вопросе (или наборе вопросов).
Эти два понятия "идентичность" и "доверие" являются основой для построения PKI.
== Удостоверяющие центры и сертификаты ==
Как было сказано раньше, у нас не существует методов доказать, что подпись "а" была его подписью на момент получения нами подписанного неким ключём документа. Хотя... В жизни, мы можем распечатать хэш открытого ключа, и у нотариуса, с пописью (а то и личным участием) обладателя закрытого ключа заверить её.
Передовое решение эпохи электронного документооборота, да. (Примерно так же бывает, когда выборку данных сначала распечатывают, потом заверяют печатью, отправляют, получатель эту распечатку сканирует, распознаёт, вбивает в свою базу данных. Глупо и неэффективно).
Строка 273:
Куда интереснее будет, если нотариус заверит ключи отправителя в электронном виде. Своим, электронным ключом. Который мы знаем. На момент подписания (в электронном виде) документа, мы проверим, что ключ, которым подписан, заверен нотариусом. Если человек, подписывавший документ, будет отрицать, что подпись его, то нотариус, заверявший её, сможет подтвердить, что это таки попись обвиняемого.
Заметим, чтобы мы могли проверить, что ключ "а" действительно принадлежит человеку "А", мы должны увидеть не только подпись нотариуса на проверяемых ключах, но и явное доказательство, что эти ключи приналежат "А". Т.е. нотариус должен подписать не только открытый ключ (закрытый подписывать не нужно, т.к. закрытый ключ НИКОМУ не показывается, даже нотариусу), но и какую-то информацию об А. Например, его паспортные данные. Или другую <em>идентичность</em>.
Важно: мы должны ДОВЕРЯТЬ (в том смысле, как было описано ранее) нотариусу, т.е. нотариус ведёт себя так, как мы от него ожидаем: он заверяет идентичность и подпись только проверив их (если нотариус заверит идентичность и подпись не проверив их, то он не оправдает нашего доверия). В принципе, документ подписывается обеими сторонами, т.е. подписывающий тоже должен доверять тому нотариусу, который заверил наши ключи. Проще всего, если это один и тот же нотариус.
Строка 288:
Вот эти отношения доверия - и есть суть PKI. PKI - это не процесс подписи, это процесс проверки того, что подпись принадлежит именно тому лицу, которое должно было подписать документ. Для этого используются удостоверяющие центры, которым мы доверяем.
Остаётся один маленький вопрос: а кто подписывает сертификат адвокатской коллегии? Если у адвокатской коллегии нет вышестоящего удостоверяющего центра, то она просто берёт и сама подписывает свой сертификат. Такой сертификат называется <em>самоподписанным</em> (или самовыданным).
Строка 294 ⟶ 293 :
А что мешает Васе Пупкину подписать свой собственный сертификат самому? Ничего! Берёшь и подписываешь. Только вот Васе Пупкину никто ''не верит''. И его подписи (на самом себе) - грош цена. А вот адвокатской коллегии - верят''. И потому, её сертификат берут и доверяют всему, что было подписано с помощью ключей этого сертификата.
Но если Вася Пупкин подло напишет в сертификате, что он на самом деле коллегия адвокатов и самоподпишет его? Как мы отличим "настоящую" адвокатскую коллегию от фальшивой?
...
Строка 307 ⟶ 306 :
* [[Защита конфиденциальных данных и анонимность в интернете]]
[[Категория:Информационная безопасность]]
| |||