Онлайн словарь
& . 1 2 3 4 5
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Μ
А Б В Г Д Ж З И К Л М Н О П Р С Т У Ф Х Ц Ч Ш Э Ю Я
ВА ВВ ВЕ ВЗ ВИ ВО ВТ ВЫ

Введение в PKI

[loadfile: templates/common/google_ads.txt is empty]
 
"PKI" (lang-en
public key infrastructure) — Инфраструктура_открытых_ключей. В рамках этого учебника будет объяснено, что это такое, для чего оно применяется и как с ним правильно работать. Этот учебник не освещает вопросы криптографии, лежащей в основе концепции открых ключей, но объясняет то, как эта криптография применяется. В отличие от криптографии, в которой царствует объективная математика, в PKI очень много условностей (соглашений, между сторонами). Административная часть PKI сложнее, чем техническая.
= Открытые ключи =
Перед пониманием того, что есть 'инфраструктура' открытых ключей, нужно чётко представлять себе что есть 'открытые ключи'. В этом учебнике не будет ничего про криптографию, результаты криптографии принимаются 'как есть'. Хотя, часть криптоалгоритмов может страдать уязвимостями, быть быстро взламываемыми и т.д., но они воспринимаются как данное (т.е. без анализа устойчивости). Все случаи взлома, раскрытия, подделки и т.д. мы отнесём к одной категории - 'компрометации ключей'. Это не совсем верно, т.к. компрометация алгоритма делает невозможным некоторые функции PKI, но в первом приближении об этой проблеме можно не думать.
Итак, что нам нужно из криптографии?
Во-первых, концепция криптофункции.
'Криптофункция' — функция, позволяющая из текста и ключа сделать шифр, такого типа, что даже имея несколько пар 'текст-шифр' невозможно угадать ключ, и такой, что воссоздать текст из шифра можно только с помощью ключа. (Ключ, вообще, очень хорошее название, оно более ёмкое, чем 'пароль' - ключ похож на обычный железный ключ - мы можем иметь много открытых и закрытых замков, но открыть данный конкретный замок мы можем только имея данный конкретный (подходящий к этому замку) ключ).
Криптография (использование криптофункций) бывает двух видов: симметричное и несимметричное (т.е. с открытыми и закрытыми ключами). В симметричной криптографии ключ для расшифровки такой же, как для шифровки. Этот тип криптографии нас не интересует.
Криптография ассиметричная же (являющаяся основой PKI) использует разные половинки ключа для шифровки и расшифровки. Половинки равноценны: если мы ключ разделили на две половинки A и B, то зашифровав с помощью A, мы можем расшифровать с помощью B. Зашифровав с помощью B мы можем расшифровать с помощью A (и только!). Мы не можем расшифровать шифр, созданный с помощью A, используя A. И наоборот, зашифрованное B не может быть расшифровано с помощью B. Более того (и это есть основа криптографии), ничем, кроме соответствующей половинки ключа, шифр не может быть расшифрован. Если B - шифровало, то ТОЛЬКО A может расшифровать. Если А шифровало, то ТОЛЬКО B может расшифровать.
Более того, процесс создания половинок A и B таков, что они могут быть созданы только вместе, одновременно. Нельзя сначала сделать A, а потом B. И наоборот - точно так же. (Соотвественно, мысль: если мы посеяли одну половинку ключа, то вторую не удастся восстановить).
Мы своим произволом (административным решением, не имеющим под собой технического обоснования) объявляем одну половинку ключа 'открытым ключом', а вторую, ей соответствующую, 'закрытым ключом'. Комбинацию открытого и закрытого ключа мы назовём 'ключевой парой'. С точки зрения математики не имеет разницы кто есть кто. С административной же важно не то 'кто есть кто', а чтобы использование (хранение и т.д.) открытых/закрытых ключей было 'разным'. На самом деле, именно это - идея, что открытый и закрытый ключ используются с разными целями, и есть истиная цель ассиметричной криптографии. Термины 'закрытый' и 'открытый' ключи немного неудачны. Им соответствуют более точные английские термины: 'private key' (закрытый ключ) и 'public key' (открытый ключ). Эти термины точнее, их дословный перевод: частный (личный) ключ и общественный ключ, соответственно.
Как понятно из английских названий, публичный (открытый) ключ мы предоставляем публике, а приватный (закрытый) храним у себя в чулане в секерете от всех остальных. Любой желающий может зашифровать некий текст (публично известным) открытым ключом и послать его нам. НИКТО, повторю, НИКТО (даже ФСБ, ФНС, ОБЭБ, ООН, ОБСЭ, МАГАТЕ, МАРДУК, ФБР и т.д.) не сможет расшифровать его (не применив силовые методы к отправителю/получателю, но это уже другой вопрос). НИКТО, у кого нет закрытого ключа НЕ МОЖЕТ расшифровать это сообщение. А владелец закрытого ключа (получатель) - может. Заметим, что пара открытый-закрытый ключ должны быть именно ПАРОЙ, какой попало закрытый ключ шифр от какого попало открытого ключа не сможет расшифровать. Таким образом, дав другу открытый ключ (его можно не прятать, так как обладание им никому ничем не поможет, и 'дать другу' можно, например, по электронной почте или выложив на веб-сайте), вы дадите ему возможность отправить вам сообщение в зашифрованном виде, которое расшифровать можете только вы. Кстати, если друг пришлёт вам свой открытый ключ (из своей пары ключей, сохранив в уютной нычке секрете свой закрытый ключ), то вы так же сможете ему отправить сообщение в зашифрованном виде.
Оппа. Лёгкое движение руками мозгом - и у нас защищённый канал связи, который можно прослушивать сколько влезет, но из которого не получится ничего понять (кроме факта шифрованной переписки). Заметим, для установления защищённого канала связи мы даже не предпринимали каких-то серьёзных усилий (вроде передачи шифроблокнотиков резиденту, паролей и явок).
Это и есть суть ассиметричной криптографии.
= Подпись =
Из криптографии мы возьмём ещё одну важную вещь: криптохэш. Что такое хеш? Функция, которая из произвольного набора данных формирует данные заданного размера. Например, и из 1 байта, и из 1024 Гб эта функция сделает, например, 128 бит. По мере возможности, различающиеся в зависимости, от входных данных. Понятно, что будут совпадения (например, данные №1 и данные №2 дают одинаковый хэш), но это будет происходить ...м... скажем так, не всегда. Такие совпадения называются 'колллизией'. Что коллизии есть у каждого хэша легко показать: если у нас хеш даёт N-бит из любого набора данных, то всего есть 2N различных значений хеша. Очевидно, что если мы на вход дадим 2N+1 данных, то хотя бы для двух значений хеш будет одинаковым (т.е. будет как минимум, одна коллизия). Заметим, что хеши не идеальны, и обычно коллизий чуть больше, чем хотелось бы.
'Криптохеш' - это такой хэш, который трудно подобрать. На самом деле требовний к хешу много. Процитируем Википедию:
Требования к криптохешу:
* Стойкость к 'коллизиям первого рода': для заданного сообщения ~M должно быть практически невозможно подобрать другое сообщение
~M', имеющее такой же хеш. Это свойство также называется 'необратимостью' хеш-функции.
* Стойкость к 'коллизиям второго рода': должно быть практически невозможно подобрать пару сообщений ~(M, M'), имеющих одинаковый хеш.
Для криптографических хеш-функций также важно, чтобы при малейшем изменении аргумента значение функции сильно изменялось. В частности, значение хеша не должно давать утечки информации даже об отдельных битах аргумента. Это требование является залогом криптостойкости алгоритмов шифрования, хеширующих пользовательский пароль для получения ключа.
Чтобы не ломать голову, сформулируем требования к криптохешу в простом виде: хеш сообщения не подделать. И под заданный хеш не получится подобрать другое сообщение.
Теперь, предположим, что мы для заданного сообщения сделаем криптохеш, зашифруем только хеш своим ЗАКРЫТЫМ ключом и положим результат в подпись письма. И отдадим другу. У которого есть наш открытый ключ. Как мы сказали раньше, открытый ключ и закрытый строго обратны друг для друга (открытым можно расшифровать то, что зашифровано закрытым). Друг, приняв сообщение, сделает ту же самую хеш-функцию. После чего он расшифрует хешиз подписи. Если они совпали, то сообщение именно то, которое было подписано.
Можно ли подделать подпись? Для этого нужно каким-то образом зашифровать хеш сообщения тем самым ЗАКРЫТЫМ ключом, второй половинкой которого (соответствующим открытым ключом) будут пытаться расшифровать. А где ж его взять-то, если он в чулане спрятан секретный? Значит, подделать подпись не получится.
Второй вопрос: можно ли поменять уже подписанное сообщение, так, чтобы вместо $10 там было $100? (дописать нолик, или даже, чуть меньше, заменить единичку на двойку). Что при этом мы должны сделать? Подпись мы подделать не можем. Значит, мы должны так поменять сообщение (например, добавив пробелов, лишних запятых и т.д.), чтобы хеш изменённого сообщения был такой же, как у исходного. А подпись тогда будет та же самая. Но мы же чуть раньше сказали, что подобрать сообщение под заданный хеш очень сложно (потому-то он 'криптохеш' и называется). А 'очень сложно' у математиков означает 'невозможно' в реальной жизни.
Т.е. подписанное сообщение невозможно подделать.
Таким образом, два друга могут переписываться не только скрыв текст писем от окружающих, но и точно проверяя, что сообщение не было подделано (заметим, это не спасёт от пропажи сообщения, потому что нет ни письма, ни хеша...). И более того, это не спасёт от повторной передачи того же самого сообщения. Но об этом позже.
= Итог главы: подпись и шифрование =
Основная функция, которую берёт PKI из криптографии, это функция подписи. Для выполнения этой функции создаётся пара ключей: открытый и закрытый, при этом открытый публикуется, а закрытый прячется. Заметим, что с точки зрения 'инфраструктуры' шифрование второстепенная функция. Отношения доверия выстраиваются, в первую очередь, основываясь на подписях. В то же самое время, область применения PKI очень тесно связана с шифрованием (т.к. в распоряжении пользователей уже есть ключи, пригодные для шифрования, то грех ими не воспользоваться).
= О потребности в инфраструктуре =
= Проблемы использования открытых/закрытых ключей =
Как мы уже сказали раньше, использование несимметричных алгоритмов шифрования и криптохешей позволяет защитить (казалось бы) передаваемую информацию от подслушивания и изменения.
Однако, условием этого является обмен открытыми ключами между сторонами (участвующими в обмене информацией). А как пользователь С сможет проверить, что полученный ключ - это ключ D, а не злобного E (который перехватил оригинальное письмо D, а вместо него отправил письмо со своим открытым ключом, и получая все сообщения от D, он их расшифровавает/меняет, шифрует/подписывает своим ключом и отправляет дальше к C)? Каким образом мы можем узнать, что данный ключ принадлежит данному пользователю? Опять шифроблокнотики, личные встречи и бумаги с печатами? (Кстати, это не самый сложный метод: люди обмениваются нотариально заверенными бумагами с распечатанными открытыми ключами - и никакой 'злобный Е' не сможет притвориться одним из них. Главная проблема подобного метода - плохое масштабирование. Если 300 человек решат так сделать со всеми остальными 299 человеками, то потребуется 300*299=89700 нотариально заверенных распечаток откртых ключей).
Проблема получения правильного открытого ключа - это первая проблема. Вторая проблема: предположим, что закрытый ключ пользователя украли. Как ему оповестить всех людей, с кем у него защищённый обмен информацией о краже? А об утрате? Если он это сделает с помощью незащищённых каналов связи, то и злоумышленник может заявить (якобы от лица пользователя): 'ключ украли, компьютер сломали, не слушайте больше писем с этим ключом'. Т.е. вся защита держится на личном доверии, каких-то других каналах связи? Или вообще ни на чём не держится?
Главная проблема, которую можно выделить из этих примеров: пользователь не имеет возможности проверить, что ключ "A" принадлежит пользователю A. Любой другой пользователь (злоумышленник) может сделать то же самое, что пользователь A, и назвать себя пользователем A.
Как решить эту задачу?
Главная 'правда' PKI состоит в том, что подобная задача не может быть решена только средствами криптографии. Необходима некая договорённость между использующими ключи людьми о том, как именно доказывать связь ключа и пользователя. Решение этого вопроса - и есть суть PKI. Дополнительно же, помимо 'главной задачи' решается ещё несколько очень важных задач, позволяющих обеспечить множество видов дополнительного криптографического сервиса.
= Концепции PKI =
Помимо криптографии, PKI использует два очень важных понятия (эти понятия не относятся к криптографии, это понятия из 'реального мира'): идентичность и доверие.
"Идентичность" — набор данных о субъекте (не обзяательно человеке), позволяющий отличить субъекта от всех остальных возможных субъектов. Это может быть набор паспортных данных (вполне себе идентичность человека) или реквизиты юрлица (аналогично, но для организаций). А ещё это может быть емейл. Глупо? Зато удобно. В суде такое не примут, а вот в большинстве других случаев (например, при шифровке переписки) - емейла вполне достаточно. Ведь он позволяет однозначно отличить один емейл от другого.
Собственно, те, кто выступает в качестве субъектов криптографии (т.е. тех, кто что-то подписывает, шифрует, прячет и т.д.), так и называют 'субъект криптографии'.
"Доверие" - это фундаментальная идея всей инфрастрктуры открытых ключей. Все связи внутри инфраструктуры - это указание на то, кто кому что и как доверяет . Точно определить термин 'доверие' сложно, и для практических нужд PKI используется следующая: 'А доверяет Б, если поведение Б соответствует ожидаемому А'. Другими словами, если мы кому-то доверяем (деньги), то мы уверены, что этот человек будет себя вести так, как мы ожидаем (в хорошем смысле).
Заметим, что доверие редко бывает всеобщим. Обычно мы доверяем в каком-то конкретном вопросе (или наборе вопросов).
Эти два понятия 'идентичность' и 'доверие' являются основой для построения PKI.
= Сертификат =
Определение сертификата очень простое:
"сертификат" - подписанная доверенной стороной связь между идентичностью и её открытым ключом (-ами).
На самом деле в этом определении очень много того, о чём мы пока не говорили. Оставим в стороне 'подписанная доверенной стороной' (об этом позже). Сфокусируемся на 'связь между идентичностью и открытым ключом'.
Фактически, сертификат - это ключ, к которому дописали, чей это ключ. Мы открываем сертификат и видим, что он принадлежит Васе Пупкину. Значит, подписи сообщения от Васи Пупкина следует проверять указанным открытым ключом, и шифровать письма Васе Пупкину надо так же надо этим открытым ключом.
Однако, просто указание на имя (емейл) и открытый ключ не достаточно - такая конструкция ничем не отличается от предыдущей (электронное письмо 'мой открытый ключ XXX-XXX-XXX-XXX, С уважением, Вася Пупкин'). Нужны какие-то объективные доказательства того, что ключ Васи Пупкина - это таки ключ Васи Пупкина. И Вася Пупкин - это именно ТОТ Вася, о котором мы думаем.
В принципе, если подумать, то если связь 'вася пупкин + открытый ключ' подпишет кто-то из тех, чей ключ мы знаем (уже), то это добавит нам уверенности. Но только в том случае, если этот 'кто-то' нам знаком и мы ему доверяем. А если нет?
Было бы неплохо иметь аналог нотариальной конторы, которая бы могла заверять связь идентичности и ключа. Нотариусу мы доверяем, значит, мы можем быть уверены, что ключ принадлежит именно тому, чья идентичность указана в сертификате.
= Центры доверия =
Обобщённая концепция нотариуса нас приводит к следующему понятию:
"Удостоверяющий центр" (УЦ) (lang-en
Certificate authority) — точка доверия, которая подписывает сертификаты. (то самое '...подписанная доверенной стороной...' из определения сертификата). В чём доверяют УЦ? Это вопрос очень сложный и о нём мы поговорим много позже, пока, для удобства изложения, будем считать, что как минимум, доверяют правильности заполнения полей, описывающих идентичность в сертификате. Т.е. УЦ действительно подтверждает, что сертификат, выданный на имя Васи Пупкина выдан именно Васе Пупкину.
Кстати, нетривиальный момент: что означает 'выдан?' (ведь сертификат, как и открытый ключ, вероятнее всего, будет публично доступен) Есть ли разница, кому именно отдадут файл сертификата?
"Выдача сертификата" — это заверение цифровой подписью открытого ключа и идентичности. Другими словами, 'выдача сертификата', это не передача каких-то данных, а проверка, что у Васи Пупкина есть закрытый ключ, соответствующий открытому ключу в сертификате. В первом (грубом) приближении, УЦ делает две вещи: проверяет (например) паспортные данные Васи Пупкина и проверяет, что Вася Пупкин имеет закрытый ключ, соответствующий открытому ключу, добавляемому в сертификат.
Об УЦ мы будем ещё много говорить (там есть много сложностей и нюансов), а пока примем как грубую модель, что УЦ связывает идентичность и открытый ключ.
"Сертификат УЦ". Есть ещё один важный момент. УЦ подписывает сертификат своим закрытым ключом. Мы хотим проверить сертификат. Это значит, что мы должны иметь открытый ключ УЦ (ну, или, точнее, его сертификат). Откуда он у нас? Есть два варианта:
# Сертификат УЦ подписан другим УЦ (да, так может быть). А сертификат того УЦ подписан третьим УЦ. И так до бесконечности? Нет.
# Сертификат УЦ может быть подписан самим УЦ. (конец цепочки).
Самоподписанный (иногда говорят 'самовыданный') сертификат — это очень сложная штука. Можем ли мы ему доверять? НЕТ! Любой проходимец может подписать себе сертификат представившись именем крупного банка - и, разумеется, мы не будем ему доверять на этом основании.
... Только если мы не знаем точно, что это сертификат крупного банка. Тогда, разумеется, мы можем ему доверять. Как различить проходимца от настоящего УЦ (которому мы можем доверять)?. "PKI не даёт ответа о том, каким корневым УЦ следует доверять, а каким нет". Этот вопрос следует решить человеку самостоятельно. (Иногда за него думают производители операционных систем, включающих некоторые УЦ в список 'доверенных корневых удостоверяющих центров').
Таким образом, самоподписанный сертификат является лишь формальностью (начальной точкой для дерева доверия), но ничего не доказывает с точки зрения PKI. Единственное, что доказывает этот сертификат, что выпускающий самоподписанный сертификат УЦ обладает соответствующим закрытым ключом (т.к. подпись можно сделать только с помощью закрытого ключа). Всё. Все остальные вопросы - правда написана в идентичности сертификата или нет, можно ему доверять или нет - эти все вопросы следует решить ДО начала использования сертификата.
Фактически, наличие самоподписанных сертификатов УЦ, является одним из допущений PKI (наравне с существованием хорошей ассиметричной криптографии и криптохешей), в рамках которой модель PKI действует. Если бы мы были занудными математиками, то мы бы сказали что-то вроде: 'Допустим, что у нас есть хорошие криптохеши и работающая ассиметричная криптография. Если пользователь доверяет хотя бы одному доверенному УЦ, то...'.
Количество доверенных УЦ у каждого пользователя своё. Кто-то доверяет УЦ компании 'Рога и Копыта', а кто-то сомневается. Возможно, есть параноик, который вообще никому не верит. (Кстати, вполне себе PKI, в которой нет ни одного доверенного удостоверяющего центра, одни враги кругом).
Соответственно, понятие 'доверенный УЦ' (с упором на слово 'доверенный') - это субъективное понятие каждого из субъектов криптографии. Кто-то верит, кто-то нет. Что произойдёт, если мы столкнёмся с подписью, сертификат которой заверен недоверенным УЦ? Поведение может отличаться от программы к программе: кто-то скажет 'нет доверия, продолжить?', кто-то молча проигнорирует (как бы если бы подписи не было), кто-то запишет в журнал безопасности кляузу 'пользователь А проверил подпись пользователя Б, заверенную УЦ, которому нет доверия'.
Каким УЦ следует доверять пользователю? Точнее, кто это решает? На первый взгляд - сам пользователь и решает. Иногда. Но не всегда. Например, работодатель может решить, что пользователь должен доверять некоему УЦ (причём, обязательно). Так тоже бывает.
А бывает так, что пользователь сам себе УЦ (кого подписал, тому доверяешь, кому не подписал - не доверяешь).
В этой главе лишь объяснена необходимость УЦ, подробнее о типах УЦ, типах доверия УЦ и т.д. - потом. Так же в этой главе не описано ещё одно важное свойство УЦ - 'отзыв сертификата'.
= Путь сертификации =
Выше мы упомянули, что УЦ может быть несколько, таким образом, что сертификат одного УЦ подписан другим УЦ. Развивая эту мысль на множество УЦ, мы можем получить огромную цепь из кучи удостоверяющих центров. Каким образом, проверяя сертификат, мы можем понять, 'можно доверять или нет'? Для проверки сертификатов нам надо построить 'путь сертифицирования' от сертификата до любого из 'доверенных корневых центров'. (или наоборот, это не важно). Мы должны полностью воссоздать цепочку доверия 'мы доверяем А (как доверенному УЦ), УЦ подписал сертификат УЦ 'Б', 'Б' подписал 'В', 'В' подписал 'Д', 'Д' выпустил сертификат для пользователя 'Е'. Т.к. в каждом моменте кто-то кому-то в некотором смысле доверяет, то именно в этом, некотором, смысле мы можем доверять этому 'Е'. Если же такого пути не удастся найти (например, УЦ по имени 'Г' и пользователь 'Ж', чьи сертификаты не подписаны никем из тех, кому ты доверяем, даже опосредованно), то и оснований верить написанному в сертификате 'Ж' нет.
Заметим, мы пока не обсуждали, каким бывает доверие (мы можем доверять фирме 1000р на счету, но мы не готовы ей доверять вопросы оформления квартиры в собственность), о том, каким образом доверие ограничивается мы поговорим в разделе про политики удостоверяющих центров и ограничения.
= Инфраструктура (итог главы) =
Соберём фрагменты информации в единую систему. PKI описывает правила взаимодействия между следующими объектами:
* Удостоверяющими центрами, которые выпускают (подписывают) сертификаты
* Субъектов криптографии, которые выполняют одно из следующих действий:
** Расшифровывают, подписывают данные или выполняют другие операции с использованием закрытого ключа
** Шифруют, проверяют подпись или выполняют другие операции с использованием открытого ключа
** Проверяют действительность сертификата, проверяя подпись на каждом из сертификатов в пути сертификации до центра доверия.
Сама концепция PKI не предписывает какой-либо структуры связи между субъектами, и более того, 'в жизни' применяется несколько несовместимых моделей взаимодействия. Несмотря на их несовместимость (или частичную совместимость - об этом позже), все они действуют по одним и тем же принципам, которые и есть суть PKI.
= Политики УЦ =
Перед тем, как доверять УЦ подписывать чьи-либо сертификаты, было бы неплохо понять, кому и что пописывает этот УЦ. Одному достаточно доказательств владения электронной почтой, другой же хочет нотариально-заверенную копию документов, третий же требует ещё и личного присутствия. Понятно, что третий УЦ будет наиболее желательным для того, кто ему доверяет (но наиболее проблемным для того, чей сертификат заверяют). Для понимания, что заверяет УЦ существует 'политика УЦ'. Фактически, это документ, описывающий что именно удостоверяет удостоверяющий центр. Вне зависимости от строгости (расслабленности) политики, УЦ, который не выполняет свою собственную политику 'не заслуживает доверия'.
= Варианты инфраструктур =
Исходя из вышенаписанного, мы можем попробовать указать на несколько базовых типов инфраструктур (правильнее было бы их называть 'принципиальными схемами инфраструктур'):
* Инфраструктура индивидуального УЦ
* Инфраструктура единичного УЦ
* Иерархическая инфраструктура подчинённых УЦ
* Множество независимых УЦ
Помимо вышеназванных, существует несколько других, о котороых пойдёт речь позже, и которые, фактически, являются специфичными случами вышеназванных.
Каждая из инфраструктур должна давать ответ на следующие вопросы:
# Кто выписывает сертификаты субъектам
# Как проверяется доверие сертификату
# Кто решает, каким УЦ доверять, а каким нет
# Как осуществляется взаимодействие между УЦ
= Инфраструктура индивидуального УЦ =
Это самая простая инфраструктура для аморфного сообщества независимых пользователей. Не существует каких-либо единых стандартов взаимодействия, подчинения и доверия. Доверие формулируется каждым пользователем в отношении каждого пользователя самостоятельно (верю/не верю). Доверие может быть не двусторонним (Вася Пупкин верит Президенту, но Президент не верит Васе Пупкину).
(Побочным эффектом личного решения 'верю/не верю' является требование глубокого понимания каждым участником принципов работы системы, очевидно, что 90-летний колхозник не сможет внятно ответить на вопрос, доверяет ли он Бабе Мане (85 лет, доярка) право удостоверять личности третьих лиц своей цифровой подписью).
В такой схеме каждый человек имеет свою пару ключей и самоподписанный сертификат. Получив сертификаты других лиц пользователь решает в отношении каждого из них 'верю/не верю' (и если верю, то до какой степени). В принципе, если доверенный друг подписал сертификат постороннего лица, то мы можем поверить, что это таки сертификат постороннего лица. Денег ему мы не дадим, но хотя бы будем уверены, что идентичность лица совпадает с заявленной в подписи. Более того, уровень доверия чужим подписям (чьей подписи на сертификате третьего лица мы верим, а чьей нет) определяет сам пользователь (или ПО исходя из заданных пользователем же весовых коэфицентов: три подписи с уровнем доверия пять, то же самое, что одна подпись с уровнем 10).
Множество пользователей строит множество отдельных 'звёзд' доверия. Каждая звезда сходится к пользователю, который, собственно, её и формирует. (У одного будет 3 лучика, у другого сотня с гаком).
Подобная схема используется, например, в системе Gnu PG, где пользователи самостоятельно создают свои сертификаты.
* 'Кто выписывает сертификаты субъектам': сами пользователи (себе и другим лицам)
* 'Как проверяется доверие сертификату': исходя из подписи доверенных лиц или личного мнения проверяющего
* 'Кто решает, каким УЦ доверять, а каким нет': пользователь
* 'Как осуществляется взаимодействие между УЦ': на основании личной политики каждого пользователя.
= Инфраструктура единичного УЦ =
Первая инфраструктура, в которой можно вообще задуматься о необходимости УЦ. Схема простая: есть УЦ, есть пользователи (сервера и т.д.). УЦ выписывает сертификаты для всех, кого нужно. Все доверяют 'своему' УЦ и таким образом могут проверить, что предъявителю сертификат выдан тем же самым УЦ.
Подобная инфраструктура обладает минимальной сложностью в управлении, за что её, собственно, и используют. Главным минусом подобной инфраструктуры является однозначная централизация управления (что в большинстве случаев является благом, а в меньшинстве - критической проблемой). У такого УЦ есть единая точка компрометации (по аналогии с единой точкой отказа) - если закрытый ключ УЦ по халатности или в результате злого умысла похищен, то это СТРОГО эквивалентно похищению всех закрытых ключей всех пользователей сети. В рамках PKI утрата (разглашение) ключа УЦ - это катастрофа, означающая полное прекращение существования инфраструктуры (нужно строить новую, с нуля, выписывать всем новые сертификаты). А для разглашения не так-то и много нужно - например, 'утёкший' бэкап сервера, на котором стоит CA.
В большинстве конфигураций, где применяется такая инфраструктура, УЦ администрируется одним лицом (или несколькими, без чёткого разделения полномочий), без сформулированных политик и регламента УЦ (о них чуть позже - но в кратце, это правила, согласно которым действует УЦ).
Ответы на стандартные вопросы:
* 'Кто выписывает сертификаты субъектам': администратор УЦ
* 'Как проверяется доверие сертификату': исходя из подписи УЦ на сертификате
* 'Кто решает, каким УЦ доверять, а каким нет': администратор УЦ, внедряющий инфраструктуру в те или иные приложения, как только инфраструктура внедрена, доверие всем сертификатам от этого УЦ происходит автоматически
* 'Как осуществляется взаимодействие между УЦ': никак. В отдельных случаях пользователи (приложения) могут доверять нескольким раздельным УЦ, но это решение не является инфраструктурой.
= Иерархическая инфраструктура подчинённых УЦ =
В этой инфраструктуре УЦ находятся в древовидной зависимости: есть единый корневой УЦ, есть подчинённые (промежуточные) УЦ, есть конечные пользователи. Корневой сервер выпускает сертификаты для подчинённых серверов, которые в свою очередь выпускают сертификаты для нижестоящих серверов и/или пользователей.
Технически, корневой сервер может выпускать сертификаты для пользователей (схема, наподобие единственного УЦ), но, обычно, так не делают: корневой УЦ выписывает сертификаты ТОЛЬКО для подчинённых УЦ. Так как подчинённых УЦ обычно в разы (порядки, etc) меньше, чем пользователей, то использование корневого УЦ (а, значит, вероятность обшибки/компрометации) существенно меньше. Компрометация же ключа подчинённого УЦ обычно решается отзывом ключа 'пострадавшего' (об отзыве ключей в следующих главах) - при этом почти никто не страдает (центр доверия - корневой УЦ как был так и остаётся). Единственными пострадавшими оказываются люди, чьи сертификаты оказались скомпрометированы (им нужно получить новые от нового УЦ).
Кажется, разницы в этом никакой? Ну был корневой, стал 'второго уровня' - всё равно компрометация режет большую дыру в инфраструктуре (в случае одного УЦ - размером в инфраструктуру).
Тут есть большая разница: если компрометируется ключ промежуточного (подчинённого) УЦ, то при этом инфраструктура сохраняется: во-первых, не нужно менять доверенные сертификаты всюду, где им доверяли (по закону подлости их оказывается на 1-2 больше, чем число мест, где сертификат заменили). Во-вторых, нет никакого механизма оповещения о проблеме (только лично, по телефону или ножками...). В случае же компрометации промежуточного УЦ все во-первых оповещаются о том, что данные сертификаты перестали действовать, во-вторых нет необходимости что-то менять у проверяющих узлов. У тех же, у кого сертификаты перестанут приниматься, будет возможность запросить новые (т.е. пользователи явно получат уведомление о проблеме).
При этом компрометация ключа корневого УЦ означает ровно то же, что и в случае одиночного УЦ (даже больше, т.к. инфраструктура с несколькими УЦ обычно больше инфраструктуры с единственным УЦ) - полное уничтожение инфраструктуры с необходимостью вручную устранять все её следы (чтобы сервер, например, перестал принимать соединения от пользователей, чьи сертификаты подписаны скомпрометированным ключом, нужно вручную поменять конфигурацию сервера - и так с каждым сервером, маршрутизатором и т.д., не говоря уже про, например, финансовый отдел, который надо лично известить о том, что платёжные поручения, подписанные сертификатом из уничтоженного PKI больше принимать нельзя).
Помимо большей защиты корневого УЦ, промежуточные УЦ дают очень важную возможность: делегировать права на выписывание сертификата администраторам промежуточных УЦ. Они могут быть менее квалифицированы, чем администратор корневого УЦ (им нужно меньше думать об инфраструктуре, их ошибка менее фатальна), и их может быть практически неограниченное количество. Например, свой УЦ у каждого филиала организации.
Ответы на стандартные вопросы:
* 'Кто выписывает сертификаты субъектам': администратор корневого УЦ для подчинённых УЦ, администраторы подчинённых УЦ другим подчинённым УЦ меньшего уровня, конечным пользователям.
* 'Как проверяется доверие сертификату': проверяется цепочка сертификатов от головного УЦ до УЦ, выдавшего сертификат конечного субъекта. Каждый сертификат (кроме корневого) должен быть подписан доверенным УЦ.
* 'Кто решает, каким УЦ доверять, а каким нет': доверие всем сертификатам инфраструктуры УЦ происходит автоматически, чужим сертификатам не доверяют.
* 'Как осуществляется взаимодействие между УЦ': строгое иерархическое подчинение. У каждого УЦ (кроме корневого) есть один вышестоящий УЦ. Количество подичнённых УЦ - произвольное.
= Множество независимых УЦ =
В ситуации, когда есть несколько независимых УЦ, между которыми должно быть взаимодействие (или, между обладателями сертификатов которых должно быть взаимодействие), следует различать две ситуации: административное разделение с целью построения сложной сети и ситуацию, когда взаимодействуют инфраструктуры, разделённые в силу объективных обстоятельств (например, PKI двух различных организаций).
Первое нужно для реализации надёжной и сложной иерархии, второе - попытка обеспечить хоть какую-то работу двух (возможно, не очень совместимых между друг другом) инфраструктур.
Важной особенностью инфраструктуры независимых УЦ является то, что она не является иерархией - это уже не древовидная структура, а граф произвольного вида (в котором могут быть петли, а в результате каких-то катаклизмов - и обособленные участки). В этой ситуации, для взаимодействия УЦ из разных иерархий приходится выписывать сертификаты специального вида, которые называются 'кросс-сертификаты'.
= Зачем всё это нужно? =
Основной вопрос: а зачем это нужно в реальной жизни? Если не рассматривать огромные, поросшие бюрократическим мхом, транснациональные корпорации и министерства?
Ответов два: во-первых, полное понимание инфраструктуры (точнее, вариантов построения инфраструктуры) - это лучше, чем неполное понимание или полное непонимание. В определенённые моменты времени может оказаться так, что таки придётся делать кросс-сертификацию для нескольких инфрактурктур. В этом случае лучше понимать, что происходит, иначе последствия окажутся сильно хуже, чем кажется (например, неосторожно выписанный сертификат для чужого УЦ можем привести к автоматическому доверию сертификатам тысяч других УЦ, что, например, не есть цель сертификации).
Второй ответ (более прагматичный). Существующее ПО по работе с сертификатами исходит из общей модели, и для понимания, что эти программы делают, для чего, и что именно нужно сделать, чтобы 'оно работало'. Возможно, от УЦ требуется всего-то навсего выписать сертификаты. Но ...шаблоны сертификатов, политики, критические дополнения, САС - всё это есть и всё это нужно знать. (Примером такого, кстати, является CA-сервис в windows server).
= Литература =
* Полянская О.Ю. , Горбатов В.С. Инфраструктуры открытых ключей, Бином, 2007, ISBN: 978-5-9556-0081-9
=Under construction =
на заглавную О сайте10 самыхСловариОбратная связь к началу страницы
© 2008-2014

online
magazines pdf download
download magazine pdf
download ebooks pdf
XHTML | CSS
1.8.11