Введение в PKI

PKI (англ. 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-бит из любого набора данных, то всего есть 2^N различных значений хеша. Очевидно, что если мы на вход дадим 2^N+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, С уважением, Вася Пупкин»). Нужны какие-то объективные доказательства того, что ключ Васи Пупкина — это таки ключ Васи Пупкина. И Вася Пупкин — это именно ТОТ Вася, о котором мы думаем.

В принципе, если подумать, то если связь «вася пупкин + открытый ключ» подпишет кто-то из тех, чей ключ мы знаем (уже), то это добавит нам уверенности. Но только в том случае, если этот «кто-то» нам знаком и мы ему доверяем. А если нет?

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

Центры доверия

Обобщённая концепция нотариуса нас приводит к следующему понятию:

Удостоверяющий центр (УЦ) (англ. Certificate authority) — точка доверия, которая подписывает сертификаты. (то самое «…подписанная доверенной стороной…» из определения сертификата). В чём доверяют УЦ? Это вопрос очень сложный и о нём мы поговорим много позже, пока, для удобства изложения, будем считать, что как минимум, доверяют правильности заполнения полей, описывающих идентичность в сертификате. То есть УЦ действительно подтверждает, что сертификат, выданный на имя Васи Пупкина выдан именно Васе Пупкину.

Кстати, нетривиальный момент: что означает «выдан?» (ведь сертификат, как и открытый ключ, вероятнее всего, будет публично доступен) Есть ли разница, кому именно отдадут файл сертификата?

Выдача сертификата — это заверение цифровой подписью открытого ключа и идентичности. Другими словами, «выдача сертификата», это не передача каких-то данных, а проверка, что у Васи Пупкина есть закрытый ключ, соответствующий открытому ключу в сертификате. В первом (грубом) приближении, УЦ делает две вещи: проверяет (например) паспортные данные Васи Пупкина и проверяет, что Вася Пупкин имеет закрытый ключ, соответствующий открытому ключу, добавляемому в сертификат.

Об УЦ мы будем ещё много говорить (там есть много сложностей и нюансов), а пока примем как грубую модель, что УЦ связывает идентичность и открытый ключ.

Сертификат УЦ. Есть ещё один важный момент. УЦ подписывает сертификат своим закрытым ключом. Мы хотим проверить сертификат. Это значит, что мы должны иметь открытый ключ УЦ (ну, или, точнее, его сертификат). Откуда он у нас? Есть два варианта:

1. Сертификат УЦ подписан другим УЦ (да, так может быть). А сертификат того УЦ подписан третьим УЦ. И так до бесконечности? Нет.
2. Сертификат УЦ может быть подписан самим УЦ. (конец цепочки).

Самоподписанный (иногда говорят «самовыданный») сертификат — это очень сложная штука. Можем ли мы ему доверять? НЕТ! Любой проходимец может подписать себе сертификат представившись именем крупного банка — и, разумеется, мы не будем ему доверять на этом основании.

… Только если мы не знаем точно, что это сертификат крупного банка. Тогда, разумеется, мы можем ему доверять. Как различить проходимца от настоящего УЦ (которому мы можем доверять)?. PKI не даёт ответа о том, каким корневым УЦ следует доверять, а каким нет. Этот вопрос следует решить человеку самостоятельно. (Иногда за него думают производители операционных систем, включающих некоторые УЦ в список «доверенных корневых удостоверяющих центров»).

Таким образом, самоподписанный сертификат является лишь формальностью (начальной точкой для дерева доверия), но ничего не доказывает с точки зрения PKI. Единственное, что доказывает этот сертификат, что выпускающий самоподписанный сертификат УЦ обладает соответствующим закрытым ключом (так как подпись можно сделать только с помощью закрытого ключа). Всё. Все остальные вопросы — правда написана в идентичности сертификата или нет, можно ему доверять или нет — эти все вопросы следует решить ДО начала использования сертификата.

Фактически, наличие самоподписанных сертификатов УЦ, является одним из допущений PKI (наравне с существованием хорошей ассиметричной криптографии и криптохешей), в рамках которой модель PKI действует. Если бы мы были занудными математиками, то мы бы сказали что-то вроде: «Допустим, что у нас есть хорошие криптохеши и работающая ассиметричная криптография. Если пользователь доверяет хотя бы одному доверенному УЦ, то…».

Количество доверенных УЦ у каждого пользователя своё. Кто-то доверяет УЦ компании «Рога и Копыта», а кто-то сомневается. Возможно, есть параноик, который вообще никому не верит. (Кстати, вполне себе PKI, в которой нет ни одного доверенного удостоверяющего центра, одни враги кругом).

Соответственно, понятие «доверенный УЦ» (с упором на слово «доверенный») — это субъективное понятие каждого из субъектов криптографии. Кто-то верит, кто-то нет. Что произойдёт, если мы столкнёмся с подписью, сертификат которой заверен недоверенным УЦ? Поведение может отличаться от программы к программе: кто-то скажет «нет доверия, продолжить?», кто-то молча проигнорирует (как бы если бы подписи не было), кто-то запишет в журнал безопасности кляузу «пользователь А проверил подпись пользователя Б, заверенную УЦ, которому нет доверия».

Каким УЦ следует доверять пользователю? Точнее, кто это решает? На первый взгляд — сам пользователь и решает. Иногда. Но не всегда. Например, работодатель может решить, что пользователь должен доверять некоему УЦ (причём, обязательно). Так тоже бывает.

А бывает так, что пользователь сам себе УЦ (кого подписал, тому доверяешь, кому не подписал — не доверяешь).

В этой главе лишь объяснена необходимость УЦ, подробнее о типах УЦ, типах доверия УЦ и т. д. — потом. Так же в этой главе не описано ещё одно важное свойство УЦ — отзыв сертификата.

Путь сертификации

Выше мы упомянули, что УЦ может быть несколько, таким образом, что сертификат одного УЦ подписан другим УЦ. Развивая эту мысль на множество УЦ, мы можем получить огромную цепь из кучи удостоверяющих центров. Каким образом, проверяя сертификат, мы можем понять, «можно доверять или нет»? Для проверки сертификатов нам надо построить путь сертифицирования от сертификата до любого из доверенных корневых центров. (или наоборот, это не важно). Мы должны полностью воссоздать цепочку доверия "мы доверяем А (как доверенному УЦ), УЦ подписал сертификат УЦ «Б», «Б» подписал «В», «В» подписал «Д», «Д» выпустил сертификат для пользователя «Е». Поскольку в каждом моменте кто-то кому-то в некотором смысле доверяет, то именно в этом, некотором, смысле мы можем доверять этому «Е». Если же такого пути не удастся найти (например, УЦ по имени «Г» и пользователь «Ж», чьи сертификаты не подписаны никем из тех, кому ты доверяем, даже опосредованно), то и оснований верить написанному в сертификате «Ж» нет.

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

Инфраструктура (итог главы)

Соберём фрагменты информации в единую систему. PKI описывает правила взаимодействия между следующими объектами:

• Удостоверяющими центрами, которые выпускают (подписывают) сертификаты
• Субъектов криптографии, которые выполняют одно из следующих действий:
  • Расшифровывают, подписывают данные или выполняют другие операции с использованием закрытого ключа
  • Шифруют, проверяют подпись или выполняют другие операции с использованием открытого ключа
  • Проверяют действительность сертификата, проверяя подпись на каждом из сертификатов в пути сертификации до центра доверия.

Сама концепция PKI не предписывает какой-либо структуры связи между субъектами, и более того, «в жизни» применяется несколько несовместимых моделей взаимодействия. Несмотря на их несовместимость (или частичную совместимость — об этом позже), все они действуют по одним и тем же принципам, которые и есть суть PKI.

Политики УЦ

Перед тем, как доверять УЦ подписывать чьи-либо сертификаты, было бы неплохо понять, кому и что подписывает этот УЦ. Одному достаточно доказательств владения электронной почтой, другой же хочет нотариально-заверенную копию документов, третий же требует ещё и личного присутствия. Понятно, что третий УЦ будет наиболее желательным для того, кто ему доверяет (но наиболее проблемным для того, чей сертификат заверяют). Для понимания, что заверяет УЦ существует политика УЦ. Фактически, это документ, описывающий что именно удостоверяет удостоверяющий центр. Вне зависимости от строгости (расслабленности) политики, УЦ, который не выполняет свою собственную политику не заслуживает доверия.

Варианты инфраструктур

Исходя из вышенаписанного, мы можем попробовать указать на несколько базовых типов инфраструктур (правильнее было бы их называть «принципиальными схемами инфраструктур»):

• Инфраструктура индивидуального УЦ
• Инфраструктура единичного УЦ
• Иерархическая инфраструктура подчинённых УЦ
• Множество независимых УЦ

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

Каждая из инфраструктур должна давать ответ на следующие вопросы:

1. Кто выписывает сертификаты субъектам
2. Как проверяется доверие сертификату
3. Кто решает, каким УЦ доверять, а каким нет
4. Как осуществляется взаимодействие между УЦ

Инфраструктура индивидуального УЦ

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

(Побочным эффектом личного решения «верю/не верю» является требование глубокого понимания каждым участником принципов работы системы, очевидно, что 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

О необходимости PKI

Из криптографии будут взяты (без проверки правильности утверждения, как данное), следующие важные допущения:

• существует такая хитрая математическая операция, которая позволяет шифровать одной половинкой ключа, а расшифровывать другой. При этом, зная «шифрующую» половинку и результат шифрования, расшифровать её никак нельзя
• Существует такая функция, которая из любой последовательности байтов сделает набор байт известного размера, но подобрать под набор байт какую-то последовательность получится только перебором.

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

Второе — это криптографические хеш-функции. Разница с обычными хеш-функциями (вроде CRC) в том, что очень трудно подобрать по хешу подходящую последовательность.

Приняв за данность эти утверждения, посмотрим, какие сервисы мы можем построить на этих допущениях:

• Раздадим открытый ключ всем желающим. Любой желающий может зашифровать файл и передать его нам, но расшифровать его можем только мы, с нашим закрытым ключом. Это даёт нам сервис конфиденциальности (никто не подслушает переданное сообщение, точнее, подслушав, ничего из него не поймёт).
• Раздадим всем открытый ключ, спрячем от чужих глаз ключ закрытый. Теперь, сделаем наоборот, будем с помощью закрытого ключа ШИФРОВАТЬ (расшифровать можно будет только с помощью открытого). Если мы сделаем хеш-слепок какого-то текста, зашифруем его и допишем результат шифрования в конце текста, то любой желающий (имеющий ключ для расшифровки) сможет сделать то же самое и убедиться, что шифрованный хеш совпадает с написанным снизу текста. Однако, никто (кроме нас) не сможет зашифровать этот хеш. То есть любой желающий может проверить, что ТОЛЬКО МЫ зашифровали текст. То есть это, фактически, цифровая подпись. Это предоставляет нам сервис неизменности переданной информации.

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

Однако, этого недостаточно. Например, если это платёжное поручение в банк, то злоумышленник, получив один раз легальное платёжное поручение, может носить его в банк сколько угодно раз (и вместо 100р забрать 100 раз по 100 рублей).

Более того, если это будет не платёжное поручение, а, например, долговая рассписка, то мы не сможем доказать, что её подписал именно должник. Почему? Потому что должник подло поменяет свой закрытый ключ, и заявит, что это мы сами сделали свои открытый/закрытый ключ, сами подписали и теперь требуем деньги с него. Нам нужен какой-то метод доказать, что текст был подписан именно ключом должника.

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

Для расширения криптографии на реальный мир нужны «точки привязки» математики к реальному миру. Именно для этого и служит инфракструктура открытых ключей. Используя криптографию, добавляя к ней «правила игры» (законы и стандарты), мы получаем возможность использовать возможности криптографии для «бытовых» (деловых и т. д.) нужд.

Базовые понятия

Какие же понятия мы должны добавить в криптографию, чтобы она стала «съедобна»?

Первое: мы должны сформулировать понятие «идентичности». Идентичность — набор данных о субъекте (не обзяательно человеке), позволяющий отличить субъекта от всех остальных возможных субъектов. Это может быть набор паспортных данных (вполне себе идентичность человека) или реквизиты юрлица (аналогично, но для организаций). А ещё это может быть емейл. Глупо? Зато удобно. В суде такое не примут, а вот в большинстве других случаев (например, при шифровке переписки) — емейла вполне достаточно. Ведь он позволяет однозначно отличить один емейл от другого.

Собственно, те, кто выступает в качестве субъектов криптографии (то есть тех, кто что-то подписывает, шифрует, прячет и т. д.), так и называют субъект криптографии.

Второе: даже если мы можем проверить криптографическую целостность информации, можем ли мы ей доверять? Нет, потому что доверие не строится на математике. Это внематематическая сущность. Точно определить термин «доверие» сложно, и для практических нужд PKI используется следующая: «А доверяет Б, если поведение Б соответствует ожидаемому А». Другими словами, если мы кому-то доверяем (деньги), то мы уверены, что этот человек будет себя вести так, как мы ожидаем (в хорошем смысле).

Заметим, что доверие редко бывает всеобщим. Обычно мы доверяем в каком-то конкретном вопросе (или наборе вопросов).

Эти два понятия «идентичность» и «доверие» являются основой для построения PKI.

Удостоверяющие центры и сертификаты

Как было сказано раньше, у нас не существует методов доказать, что подпись «а» была его подписью на момент получения нами подписанного неким ключём документа. Хотя… В жизни, мы можем распечатать хэш открытого ключа, и у нотариуса, с пописью (а то и личным участием) обладателя закрытого ключа заверить её.

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

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

Заметим, чтобы мы могли проверить, что ключ «а» действительно принадлежит человеку «А», мы должны увидеть не только подпись нотариуса на проверяемых ключах, но и явное доказательство, что эти ключи приналежат «А». То есть нотариус должен подписать не только открытый ключ (закрытый подписывать не нужно, так как закрытый ключ НИКОМУ не показывается, даже нотариусу), но и какую-то информацию об А. Например, его паспортные данные. Или другую идентичность.

Важно: мы должны ДОВЕРЯТЬ (в том смысле, как было описано ранее) нотариусу, то есть нотариус ведёт себя так, как мы от него ожидаем: он заверяет идентичность и подпись только проверив их (если нотариус заверит идентичность и подпись не проверив их, то он не оправдает нашего доверия). В принципе, документ подписывается обеими сторонами, то есть подписывающий тоже должен доверять тому нотариусу, который заверил наши ключи. Проще всего, если это один и тот же нотариус.

Так вот, важно: связь идентичности и открытых ключей называется СЕРТИФИКАТОМ. А тот, кто подписывает эту связь (и проверяет, что идентичность — это идентичность) называется УДОСТОВЕРЯЮЩИМ ЦЕНТРОМ. Понятно, что мы должны доверять удостоверяющему центру, если хотим проверять сертификаты, которые он подписал.

Но нотариусов же много! Один заверился в юр.конторе возле дома, второй возле дома. А живут — на разных концах города. Нам надо иметь открытые ключи всех нотариусов, чтобы проверять все возможные подписи? Глупо.

А что, если мы будем иметь единственный сертификат адвокатской коллегии, ключом которого подписываются сертификаты нотариусов, которые, в свою очередь, подписывают сертификаты людей (организаций)? Это будет удобнее.

Это — и есть иерархия удостоверяющих центров. Удостоверяющий центр заверяет подпись и идентичность нотариуса (и, это важно, указывает, что это нотариус, то есть лицо, имеющее право заверять чужие подписи). Нотариус заверяет ключи и идентичность персоны, однако, указывает, что этими ключами можно только подписывать договора (а вот заверять чужие сертификаты уже нельзя). Почему он это делает? Потому что он НЕ ДОВЕРЯЕТ лицам (у них нет нужной квалификации). Зато мы ему (нотариусу) доверяем. Почему? Потому что он не делает глупостей, а все его заверения — истины и могут быть приняты в суде.

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

Вот эти отношения доверия — и есть суть PKI. PKI — это не процесс подписи, это процесс проверки того, что подпись принадлежит именно тому лицу, которое должно было подписать документ. Для этого используются удостоверяющие центры, которым мы доверяем.

Остаётся один маленький вопрос: а кто подписывает сертификат адвокатской коллегии? Если у адвокатской коллегии нет вышестоящего удостоверяющего центра, то она просто берёт и сама подписывает свой сертификат. Такой сертификат называется самоподписанным (или самовыданным).

А что мешает Васе Пупкину подписать свой собственный сертификат самому? Ничего! Берёшь и подписываешь. Только вот Васе Пупкину никто не верит. И его подписи (на самом себе) — грош цена. А вот адвокатской коллегии — верят. И потому, её сертификат берут и доверяют всему, что было подписано с помощью ключей этого сертификата.

Но если Вася Пупкин подло напишет в сертификате, что он на самом деле коллегия адвокатов и самоподпишет его? Как мы отличим «настоящую» адвокатскую коллегию от фальшивой?

…

Никак! В этом и есть важное «но»: начальные отношения доверия НЕ МОГУТ быть установлены в электронном виде. Мы должны приехать в коллегию и взять сертификат у них, пометив его для себя (обычно, с помощью ПО), как доверенный. Ленивые могут его скачать с сайта коллегии (но где гарантии, что сайт коллегии, а не подделка?).

Таким образом, и это очень важно: начальные отношения доверия устанавливаются вне PKI. PKI начинает работать в тот момент, когда мы уже имеем доверенный сертификат. Хотя бы один.

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

См. также

• Защита конфиденциальных данных и анонимность в интернете