ЭЦП, ЭП
Электронная подпись (ЭЦП, ЭП) это реквизит конкретного электронного документа, который создан в результате криптографического преобразования с помощью закрытого ключа пользователя.
На практике сложилось так, что чаще всего пользователи говорят «ЭЦП» (электронная цифровая подпись) имея в виду ключи (открытый и закрытый) и сертификат ключа проверки электронной подписи. Аббревиатура «ЭЦП» пришла из 1-ФЗ «электронной цифровой подписи» от 10.01.2002. Этот закон утратил силу, но термин «ЭЦП» прочно прижился! В новом законе уже фигурирует термин «ЭП» (электронная подпись). Слово «цифровая» опустили, т.к. это является синонимом слова «электронная».
Даже на нашем сайте вы чаще всего увидите именно это обозначение. Так как именно это самое распространённое обозначение сертификата, хоть эта формулировка и не совсем точная.
По данным сервиса Яндекс.Wordstat пользователи поисковика Яндекс используют фразу «получить ЭЦП» в 10 раз чаще чем «получить КЭП».
Мы стараемся быть ближе к нашим клиентам, поэтому тоже используем «неправильный» термин.
Политики УЦПравить
Перед тем, как доверять УЦ подписывать чьи-либо сертификаты, было бы неплохо понять, кому и что подписывает этот УЦ. Одному достаточно доказательств владения электронной почтой, другой же хочет нотариально-заверенную копию документов, третий же требует ещё и личного присутствия. Понятно, что третий УЦ будет наиболее желательным для того, кто ему доверяет (но наиболее проблемным для того, чей сертификат заверяют). Для понимания, что заверяет УЦ существует политика УЦ. Фактически, это документ, описывающий что именно удостоверяет удостоверяющий центр. Вне зависимости от строгости (расслабленности) политики, УЦ, который не выполняет свою собственную политику не заслуживает доверия.
КЭП, УКЭП
КЭП (УКЭП) — усиленная квалифицированная электронная подпись. То же самое что и ЭЦП (ЭП), только с уточнением, что подпись создана с помощью именно квалифицированного сертификата.
Разберём подробнее что значит усиленная и квалифицированная.Усиленная — используется средство криптозащиты информации (например КриптоПро CSP).Квалифицированная — сертификат электронной подписи выдаётся аккредитованным удостоверяющим центром.
Таким образом, практически все электронные подписи, созданные с помощью сертификатов полученных в удостоверяющих центрах, усиленные квалифицированные, за исключением случаем когда клиент заказывает именно неквалифицированный сертификат для внутреннего ЭДО.
Наглядное объяснение принципа работы сертификатов открытого ключа на примере установки ПО от стороннего разработчика пользователем в Интернете
Сертификаты, как правило, используются для обмена зашифрованными данными в больших сетях. Криптосистема с открытым ключом решает проблему обмена секретными ключами между участниками безопасного обмена, однако не решает проблему доверия к открытым ключам. Предположим, что Алиса, желая получать зашифрованные сообщения, генерирует пару ключей, один из которых (открытый) она публикует каким-либо образом. Любой, кто желает отправить ей конфиденциальное сообщение, имеет возможность зашифровать его этим ключом, и быть уверенным, что только она (так как только она обладает соответствующим секретным ключом) сможет это сообщение прочесть. Однако описанная схема ничем не может помешать злоумышленнику Давиду создать пару ключей, и опубликовать свой открытый ключ, выдав его за ключ Алисы. В таком случае Давид сможет расшифровывать и читать, по крайней мере, ту часть сообщений, предназначенных Алисе, которые были по ошибке зашифрованы его открытым ключом.
Идея сертификата — это наличие третьей стороны, которой доверяют две другие стороны информационного обмена. Предполагается, что таких третьих сторон немного, и их открытые ключи всем известны каким-либо способом, например, хранятся в операционной системе или публикуются в журналах. Таким образом, подлог открытого ключа третьей стороны легко выявляется.
Сертификат открытого ключа выдаётся центром сертификации и состоит из таких полей как:
Цифровая подпись гарантирует невозможность подделки сертификата. Она является результатом криптографической хеш-функции от данных сертификата, зашифрованным закрытым ключом центра сертификации. Открытый ключ центра сертификации является общеизвестным, поэтому любой может расшифровать им цифровую подпись сертификата, затем вычислить хеш самостоятельно и сравнить, совпадают ли хеши. Если хеши совпадают — значит сертификат действительный и можно не сомневаться, что открытый ключ принадлежит именно тому, с кем мы собираемся устанавливать соединение.
Если Алиса сформирует сертификат со своим публичным ключом и этот сертификат будет подписан третьей стороной (например, Трентом), любой, доверяющий Тренту, сможет удостовериться в подлинности открытого ключа Алисы. В централизованной инфраструктуре в роли Трента выступает удостоверяющий центр. В сетях доверия Трент может быть любым пользователем, и следует ли доверять этому пользователю, удостоверившему ключ Алисы, решает сам отправитель сообщения.
Зачем всё это нужно?Править
Основной вопрос: а зачем это нужно в реальной жизни? Если не рассматривать огромные, поросшие бюрократическим мхом, транснациональные корпорации и министерства?
Ответов два: во-первых, полное понимание инфраструктуры (точнее, вариантов построения инфраструктуры) — это лучше, чем неполное понимание или полное непонимание. В определённые моменты времени может оказаться так, что таки придётся делать кросс-сертификацию для нескольких инфраструктур. В этом случае лучше понимать, что происходит, иначе последствия окажутся сильно хуже, чем кажется (например, неосторожно выписанный сертификат для чужого УЦ можем привести к автоматическому доверию сертификатам тысяч других УЦ, что, например, не есть цель сертификации).
Второй ответ (более прагматичный). Существующее ПО по работе с сертификатами исходит из общей модели, и для понимания, что эти программы делают, для чего, и что именно нужно сделать, чтобы «оно работало». Возможно, от УЦ требуется всего-то навсего выписать сертификаты. Но шаблоны сертификатов, политики, критические дополнения, САС — всё это есть и всё это нужно знать. (Примером такого, кстати, является CA-сервис в windows server).
Пусть имеются две стороны информационного обмена — , , желающие обмениваться сообщениями конфиденциально, и третья сторона (играющая роль удостоверяющего центра), которой доверяют и .
регистрируется у (посылает запрос на подпись), указывая данные о себе и свой . Сторона посредством определенных механизмов «удостоверяет личность» стороны и выдает стороне сертификат , устанавливающий соответствие между субъектом и ключом . Сертификат содержит:
посылает стороне свой сертификат . проверяет цифровую подпись . Для этого
Если полученные хеши равны — ЭЦП корректна, а это подтверждает, что действительно принадлежит .
Теперь , зная открытый ключ и зная, что он принадлежит именно , может шифровать этим открытым ключом все последующие сообщения для . И только сможет их расшифровать, так как известен только .
Перспективы использования SSL-сертификатов
В ближайшее время вряд ли появится альтернатива PKI на базе стандарта X.509: размах необходимых действий по глобальному переходу на новые стандарты был бы весьма велик. По той же причине не следует ожидать существенного преодоления уже известных проблем стандарта, таких как невозможность оперативного исключения корневого сертификата, или трудоёмкая процедура получения сертификата в целом.
Практически все протоколы и сети Интернета переходят на защищённый канал передачи данных. Как следствие, спрос на SSL-сертификаты будет только возрастать. Насколько жизнеспособными окажутся модели OpenCA и Lets Encrypt, можно только гадать.
А пока тщательная проверка репутации CA перед приобретением у него сертификата является самым надёжным средством убедиться, что вас не ждут неприятности в этой области, как минимум до появления ближайшего обновления любого из установленных у вас на компьютере продуктов, использующих SSL/TSL. И, разумеется, имеет смысл следить за всеми обновлениям ОС и компонентов, не забывать интересоваться их состоянием с точки зрения безопасности.
Электронная форма сертификата определяется стандартом X.509. Перечень обязательных и необязательных полей, которые могут присутствовать в сертификате, определяется данным стандартом, а также законодательством. Согласно законодательству России и Украины (закон «Об электронной цифровой подписи») сертификат должен содержать следующие поля:
Кроме этого в сертификат могут вноситься дополнительные поля.
Бумажный сертификат должен выдаваться на основании подтверждающих документов и в присутствии лица с последующим заверением подписями работника УЦ и носителя закрытого ключа.
ЭЦП, ЭП, КЭП, УКЭП, СКПЭП, сертификат электронной подписи. В чём отличия?
Проверено на актуальность: 16.11.2022 г.
Обычно всеми этими терминами называют одно и то же — это «квалифицированный сертификат ключа проверки электронной подписи» — «КСКПЭП» или просто «сертификат»! Это хоть и не привычно, но именно так правильно, согласно 63-ФЗ, называется то, что выдаёт удостоверяющий центр пользователям!
Пожалуй, трудно найти сферу с более запутанной терминологией, чем электронная подпись! Разберём подробнее каждый термин.
Программные ошибки при использовании сертификатов
Одной из наиболее неприятных проблем является полное игнорирование ошибок сертификатов при использовании защищённого соединения. В статье «The Most Dangerous Code in the World» рассматриваются типичные приёмы, непригодные с точки зрения практической информационной безопасности, когда ошибки сертификатов просто игнорируются.
Другим инцидентом была ситуация, когда продукты Mozilla стали считать недействительными все самоподписанные сертификаты, для которых не было возможности проверить достоверность на внешних службах (таких как OCSP-серверы). Следствием стала практическая невозможность использования таких продуктов для локальных сетей компаний, где обычно использовался их собственный CA и его корневой сертификат.
Криптография с открытым ключом
До 1970 года использовалась практически только криптография с симметричным ключом. Очевидное слабое звено таких криптографических схем — необходимость передачи ключа всем участвующим в защищённом обмене сторонам.
Изобретателем методики шифрования с открытым ключом считается Ральф Меркл. Если в случае симметричного шифрования один и тот же ключ (фиксированный набор данных произвольной длины) используется как для зашифровки, так и для расшифровки, то в подходе с открытым ключом есть два ключа: секретный, который надлежит знать только владельцу, и открытый — доступный всем желающим. Только владелец секретного ключа может дешифровать предназначенный для него шифротекст или подписать своим ключом любой набор данных (файл). В то же время любой владелец открытого ключа может отправить (зашифровать) текст владельцу секретного ключа, или проверить подпись того или иного файла.
Теоретически система шифрования с открытым ключом опирается на то, что разложение на простые множители достаточно больших чисел потребует много времени и/или значительных вычислительных мощностей. Это лежит в основе подбора секретного ключа по известному открытому. Всё упирается в вычислительные ресурсы и время. Сегодня принято считать, что использование ключей длиной 2048 бит не позволяет в общем случае подобрать секретный ключ за разумный срок в пределах вычислительной мощности, доступной в настоящее время. Рекомендуем ознакомиться с подробностями того, как длина ключа влияет на вероятность вскрытия шифра в случае симметричного шифрования и шифрования с открытым ключом. Упрощая: открытый ключ длиной 1024 бит по уровню требуемой вычислительной мощности примерно так же стоек, как и 80-битный симметричный ключ.
В случае использования RSA (сокращение по фамилиям изобретателей этой криптосистемы, Rivest-Shamir-Adleman) скорость шифрования примерно пропорциональна квадрату длины ключа, а расшифровки — кубу. Современные программы криптографии оперируют в общем случае с ключами вплоть до 4096 бит. Даже 2048 бит во многих случаях достаточно, чтобы исключить возможность взлома за разумное время. Использование более длинных ключей может серьёзно повысить затраты времени и вычислительной мощности, а также размер полученного шифротекста, при этом не добавляя существенных различий во времени, необходимом для дешифровки. Что сто лет, что миллион — на практике в большинстве случаев разницы нет.
Важный момент: если удалось сохранить и шифротекст, и актуальный для того момента открытый ключ, то рано или поздно (теоретически) текст удастся прочесть. Это следует иметь в виду, если информация предназначена для длительного хранения без доступа к ней третьих лиц. Шифрование в таком виде не предполагает наличия т. н. Perfect forward secrecy, когда получение ключа для шифрования в будущем не повлияло бы на возможность расшифровки прошлых сообщений.
В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в RFC4491: Using GOST with PKIX.
О потребности в инфраструктуреПравить
Как мы уже сказали раньше, использование несимметричных алгоритмов шифрования и криптохешей позволяет защитить (казалось бы) передаваемую информацию от подслушивания и изменения.
Однако, условием этого является обмен открытыми ключами между сторонами (участвующими в обмене информацией). А как пользователь С сможет проверить, что полученный ключ — это ключ D, а не злобного E (который перехватил оригинальное письмо D, а вместо него отправил письмо со своим открытым ключом, и получая все сообщения от D, он их расшифровавает/меняет, шифрует/подписывает своим ключом и отправляет дальше к C)? Каким образом мы можем узнать, что данный ключ принадлежит данному пользователю? Опять шифроблокнотики, личные встречи и бумаги с печатями? (Кстати, это не самый сложный метод: люди обмениваются нотариально заверенными бумагами с распечатанными открытыми ключами — и никакой «злобный Е» не сможет притвориться одним из них. Главная проблема подобного метода — плохое масштабирование. Если 300 человек решат так сделать со всеми остальными 299 человеками, то потребуется 300*299=89700 нотариально заверенных распечаток открытых ключей).
Проблема получения правильного открытого ключа — это первая проблема. Вторая проблема: предположим, что закрытый ключ пользователя украли. Как ему оповестить всех людей, с кем у него защищённый обмен информацией о краже? А об утрате? Если он это сделает с помощью незащищённых каналов связи, то и злоумышленник может заявить (якобы от лица пользователя): «ключ украли, компьютер сломали, не слушайте больше писем с этим ключом». То есть вся защита держится на личном доверии, каких-то других каналах связи? Или вообще ни на чём не держится?
Главная проблема, которую можно выделить из этих примеров: пользователь не имеет возможности проверить, что ключ A принадлежит пользователю A. Любой другой пользователь (злоумышленник) может сделать то же самое, что пользователь A, и назвать себя пользователем A.
Как решить эту задачу?
Главная «правда» PKI состоит в том, что подобная задача не может быть решена только средствами криптографии. Необходима некая договорённость между использующими ключи людьми о том, как именно доказывать связь ключа и пользователя. Решение этого вопроса — и есть суть PKI. Дополнительно же, помимо «главной задачи» решается ещё несколько очень важных задач, позволяющих обеспечить множество видов дополнительного криптографического сервиса.
Концепции PKIПравить
Помимо криптографии, PKI использует два очень важных понятия (эти понятия не относятся к криптографии, это понятия из «реального мира»): идентичность и доверие.
Идентичность — набор данных о субъекте (не обязательно человеке), позволяющий отличить субъекта от всех остальных возможных субъектов. Это может быть набор паспортных данных (вполне себе идентичность человека) или реквизиты юрлица (аналогично, но для организаций). А ещё это может быть емейл. Глупо? Зато удобно. В суде такое не примут, а вот в большинстве других случаев (например, при шифровке переписки) — емейла вполне достаточно. Ведь он позволяет однозначно отличить один емейл от другого.
Собственно, те, кто выступает в качестве субъектов криптографии (то есть тех, кто что-то подписывает, шифрует, прячет и т. д.), так и называют субъект криптографии.
Доверие — это фундаментальная идея всей инфрастрктуры открытых ключей. Все связи внутри инфраструктуры — это указание на то, кто кому что и как доверяет . Точно определить термин «доверие» сложно, и для практических нужд PKI используется следующая: «А доверяет Б, если поведение Б соответствует ожидаемому А». Другими словами, если мы кому-то доверяем (деньги), то мы уверены, что этот человек будет себя вести так, как мы ожидаем (в хорошем смысле).
Заметим, что доверие редко бывает всеобщим. Обычно мы доверяем в каком-то конкретном вопросе (или наборе вопросов).
Эти два понятия «идентичность» и «доверие» являются основой для построения PKI.
СертификатПравить
Определение сертификата очень простое:
сертификат — подписанная доверенной стороной связь между идентичностью и её открытым ключом (-ами).
На самом деле в этом определении очень много того, о чём мы пока не говорили. Оставим в стороне «подписанная доверенной стороной» (об этом позже). Сфокусируемся на «связь между идентичностью и открытым ключом».
Фактически, сертификат — это ключ, к которому дописали, чей это ключ. Мы открываем сертификат и видим, что он принадлежит Васе Пупкину. Значит, подписи сообщения от Васи Пупкина следует проверять указанным открытым ключом, и шифровать письма Васе Пупкину надо так же этим открытым ключом.
В принципе, если подумать, то если связь «вася пупкин + открытый ключ» подпишет кто-то из тех, чей ключ мы знаем (уже), то это добавит нам уверенности. Но только в том случае, если этот «кто-то» нам знаком и мы ему доверяем. А если нет?
Было бы неплохо иметь аналог нотариальной конторы, которая бы могла заверять связь идентичности и ключа. Нотариусу мы доверяем, значит, мы можем быть уверены, что ключ принадлежит именно тому, чья идентичность указана в сертификате.
Центры доверияПравить
Обобщённая концепция нотариуса нас приводит к следующему понятию:
Кстати, нетривиальный момент: что означает «выдан?» (ведь сертификат, как и открытый ключ, вероятнее всего, будет публично доступен) Есть ли разница, кому именно отдадут файл сертификата?
Выдача сертификата — это заверение цифровой подписью открытого ключа и идентичности. Другими словами, «выдача сертификата», это не передача каких-то данных, а проверка, что у Васи Пупкина есть закрытый ключ, соответствующий открытому ключу в сертификате. В первом (грубом) приближении, УЦ делает две вещи: проверяет (например) паспортные данные Васи Пупкина и проверяет, что Вася Пупкин имеет закрытый ключ, соответствующий открытому ключу, добавляемому в сертификат.
Об УЦ мы будем ещё много говорить (там есть много сложностей и нюансов), а пока примем как грубую модель, что УЦ связывает идентичность и открытый ключ.
Сертификат УЦ. Есть ещё один важный момент. УЦ подписывает сертификат своим закрытым ключом. Мы хотим проверить сертификат. Это значит, что мы должны иметь открытый ключ УЦ (ну, или, точнее, его сертификат). Откуда он у нас? Есть два варианта:
Самоподписанный (иногда говорят «самовыданный») сертификат — это очень сложная штука. Можем ли мы ему доверять? НЕТ! Любой проходимец может подписать себе сертификат представившись именем крупного банка — и, разумеется, мы не будем ему доверять на этом основании.
Таким образом, самоподписанный сертификат является лишь формальностью (начальной точкой для дерева доверия), но ничего не доказывает с точки зрения PKI. Единственное, что доказывает этот сертификат, что выпускающий самоподписанный сертификат УЦ обладает соответствующим закрытым ключом (так как подпись можно сделать только с помощью закрытого ключа). Всё. Все остальные вопросы — правда написана в идентичности сертификата или нет, можно ему доверять или нет — эти все вопросы следует решить ДО начала использования сертификата.
Количество доверенных УЦ у каждого пользователя своё. Кто-то доверяет УЦ компании «Рога и Копыта», а кто-то сомневается. Возможно, есть параноик, который вообще никому не верит. (Кстати, вполне себе PKI, в которой нет ни одного доверенного удостоверяющего центра, одни враги кругом).
Соответственно, понятие «доверенный УЦ» (с упором на слово «доверенный») — это субъективное понятие каждого из субъектов криптографии. Кто-то верит, кто-то нет. Что произойдёт, если мы столкнёмся с подписью, сертификат которой заверен недоверенным УЦ? Поведение может отличаться от программы к программе: кто-то скажет «нет доверия, продолжить?», кто-то молча проигнорирует (как бы если бы подписи не было), кто-то запишет в журнал безопасности кляузу «пользователь А проверил подпись пользователя Б, заверенную УЦ, которому нет доверия».
Каким УЦ следует доверять пользователю? Точнее, кто это решает? На первый взгляд — сам пользователь и решает. Иногда. Но не всегда. Например, работодатель может решить, что пользователь должен доверять некоему УЦ (причём, обязательно). Так тоже бывает.
А бывает так, что пользователь сам себе УЦ (кого подписал, тому доверяешь, кому не подписал — не доверяешь).
В этой главе лишь объяснена необходимость УЦ, подробнее о типах УЦ, типах доверия УЦ и т. д. — потом. Так же в этой главе не описано ещё одно важное свойство УЦ — отзыв сертификата.
Путь сертификацииПравить
Выше мы упомянули, что УЦ может быть несколько, таким образом, что сертификат одного УЦ подписан другим УЦ. Развивая эту мысль на множество УЦ, мы можем получить огромную цепь из кучи удостоверяющих центров. Каким образом, проверяя сертификат, мы можем понять, «можно доверять или нет»? Для проверки сертификатов нам надо построить путь сертифицирования от сертификата до любого из доверенных корневых центров. (или наоборот, это не важно). Мы должны полностью воссоздать цепочку доверия «мы доверяем А (как доверенному УЦ), УЦ подписал сертификат УЦ «Б», «Б» подписал «В», «В» подписал «Д», «Д» выпустил сертификат для пользователя «Е». Поскольку в каждом моменте кто-то кому-то в некотором смысле доверяет, то именно в этом, некотором, смысле мы можем доверять этому «Е». Если же такого пути не удастся найти (например, УЦ по имени «Г» и пользователь «Ж», чьи сертификаты не подписаны никем из тех, кому ты доверяем, даже опосредованно), то и оснований верить написанному в сертификате «Ж» нет.
Заметим, мы пока не обсуждали, каким бывает доверие (мы можем доверять фирме 1000р на счету, но мы не готовы ей доверять вопросы оформления квартиры в собственность), о том, каким образом доверие ограничивается мы поговорим в разделе про политики удостоверяющих центров и ограничения.
Инфраструктура (итог главы)Править
Соберём фрагменты информации в единую систему. PKI описывает правила взаимодействия между следующими объектами:
Сама концепция PKI не предписывает какой-либо структуры связи между субъектами, и более того, «в жизни» применяется несколько несовместимых моделей взаимодействия. Несмотря на их несовместимость (или частичную совместимость — об этом позже), все они действуют по одним и тем же принципам, которые и есть суть PKI.
Сертификаты и PKI в целом
Не очень сложно сформулировать основные принципы PKI. Поскольку всё вращается вокруг пар ключей и цифровых подписей, основные положения легко вывести, опираясь на эти термины.
Сертификат позволяет определить степень доверия — поскольку создать сертификат может кто угодно, вопрос именно в доверии. Цифровая подпись открытого ключа (одна из частей сертификата) и является способом обозначить доверие.
Наличие цифровой подписи означает, что где-то в этой цепочке имеется начало. Так называемые корневые сертификаты, принадлежащие обычно центрам сертификации (Certificate Authority, CA), должны приниматься на веру. На практике ряд корневых сертификатов уже вносится или в соответствующие хранилища конкретной операционной системы, или в хранилище программы, использующей SSL/TLS (такие как браузеры, почтовые клиенты и т. д.).
На практике, разумеется, это не так. Хотя широко используются иконки и значки, демонстрирующие степень доверия к сайту (например, зелёный замок в адресной строке), само по себе существование дорогого сертификата не может быть гарантией того, что посетителям сайта действительно гарантируется безопасность, высокое качество обслуживания и отсутствие последующих неприятностей.
Необходимо помнить, что взаимодействие ведётся с людьми. Надёжность, безопасность и прочие достоинства использования сертификатов X.509 определяются самым слабым звеном во всех системах безопасности: конкретными людьми.
Суммируя: SSL-сертификаты используются для реализации следующих основных возможностей:
конфиденциальности общения;
подтверждения целостности сообщения (что оно не было изменено в процессе доставки);
подтверждения аутентичности источника сообщения.
Базовые понятияПравить
Какие же понятия мы должны добавить в криптографию, чтобы она стала «съедобна»?
Первое: мы должны сформулировать понятие «идентичности». Идентичность — набор данных о субъекте (не обзяательно человеке), позволяющий отличить субъекта от всех остальных возможных субъектов. Это может быть набор паспортных данных (вполне себе идентичность человека) или реквизиты юрлица (аналогично, но для организаций). А ещё это может быть емейл. Глупо? Зато удобно. В суде такое не примут, а вот в большинстве других случаев (например, при шифровке переписки) — емейла вполне достаточно. Ведь он позволяет однозначно отличить один емейл от другого.
Второе: даже если мы можем проверить криптографическую целостность информации, можем ли мы ей доверять? Нет, потому что доверие не строится на математике. Это внематематическая сущность. Точно определить термин «доверие» сложно, и для практических нужд PKI используется следующая: «А доверяет Б, если поведение Б соответствует ожидаемому А». Другими словами, если мы кому-то доверяем (деньги), то мы уверены, что этот человек будет себя вести так, как мы ожидаем (в хорошем смысле).
Варианты инфраструктурПравить
Исходя из вышенаписанного, мы можем попробовать указать на несколько базовых типов инфраструктур (правильнее было бы их называть «принципиальными схемами инфраструктур»):
Помимо вышеназванных, существует несколько других, о которых пойдёт речь позже, и которые, фактически, являются специфичными случаями вышеназванных.
Каждая из инфраструктур должна давать ответ на следующие вопросы:
Инфраструктура индивидуального УЦПравить
Это самая простая инфраструктура для аморфного сообщества независимых пользователей. Не существует каких-либо единых стандартов взаимодействия, подчинения и доверия. Доверие формулируется каждым пользователем в отношении каждого пользователя самостоятельно (верю/не верю). Доверие может быть не двусторонним (Вася Пупкин верит Президенту, но Президент не верит Васе Пупкину).
(Побочным эффектом личного решения «верю/не верю» является требование глубокого понимания каждым участником принципов работы системы, очевидно, что 90-летний колхозник не сможет внятно ответить на вопрос, доверяет ли он Бабе Мане (85 лет, доярка) право удостоверять личности третьих лиц своей цифровой подписью).
В такой схеме каждый человек имеет свою пару ключей и самоподписанный сертификат. Получив сертификаты других лиц пользователь решает в отношении каждого из них «верю/не верю» (и если верю, то до какой степени). В принципе, если доверенный друг подписал сертификат постороннего лица, то мы можем поверить, что это таки сертификат постороннего лица. Денег ему мы не дадим, но хотя бы будем уверены, что идентичность лица совпадает с заявленной в подписи. Более того, уровень доверия чужим подписям (чьей подписи на сертификате третьего лица мы верим, а чьей нет) определяет сам пользователь (или ПО исходя из заданных пользователем же весовых коэффициентов: три подписи с уровнем доверия пять, то же самое, что одна подпись с уровнем 10).
Множество пользователей строит множество отдельных «звёзд» доверия. Каждая звезда сходится к пользователю, который, собственно, её и формирует. (У одного будет 3 лучика, у другого сотня с гаком).
Подобная схема используется, например, в системе Gnu PG, где пользователи самостоятельно создают свои сертификаты.
Инфраструктура единичного УЦПравить
Первая инфраструктура, в которой можно вообще задуматься о необходимости УЦ. Схема простая: есть УЦ, есть пользователи (серверы и т. д.). УЦ выписывает сертификаты для всех, кого нужно. Все доверяют «своему» УЦ и таким образом могут проверить, что предъявителю сертификат выдан тем же самым УЦ.
Подобная инфраструктура обладает минимальной сложностью в управлении, за что её, собственно, и используют. Главным минусом подобной инфраструктуры является однозначная централизация управления (что в большинстве случаев является благом, а в меньшинстве — критической проблемой). У такого УЦ есть единая точка компрометации (по аналогии с единой точкой отказа) — если закрытый ключ УЦ по халатности или в результате злого умысла похищен, то это СТРОГО эквивалентно похищению всех закрытых ключей всех пользователей сети. В рамках PKI утрата (разглашение) ключа УЦ — это катастрофа, означающая полное прекращение существования инфраструктуры (нужно строить новую, с нуля, выписывать всем новые сертификаты). А для разглашения не так-то и много нужно — например, «утёкший» бэкап сервера, на котором стоит CA.
В большинстве конфигураций, где применяется такая инфраструктура, УЦ администрируется одним лицом (или несколькими, без чёткого разделения полномочий), без сформулированных политик и регламента УЦ (о них чуть позже — но в кратце, это правила, согласно которым действует УЦ).
Ответы на стандартные вопросы:
Иерархическая инфраструктура подчинённых УЦПравить
В этой инфраструктуре УЦ находятся в древовидной зависимости: есть единый корневой УЦ, есть подчинённые (промежуточные) УЦ, есть конечные пользователи. Корневой сервер выпускает сертификаты для подчинённых серверов, которые в свою очередь выпускают сертификаты для нижестоящих серверов и/или пользователей.
Технически, корневой сервер может выпускать сертификаты для пользователей (схема, наподобие единственного УЦ), но, обычно, так не делают: корневой УЦ выписывает сертификаты ТОЛЬКО для подчинённых УЦ. Поскольку подчинённых УЦ обычно в разы (порядки, etc) меньше, чем пользователей, то использование корневого УЦ (а, значит, вероятность обшибки/компрометации) существенно меньше. Компрометация же ключа подчинённого УЦ обычно решается отзывом ключа «пострадавшего» (об отзыве ключей в следующих главах) — при этом почти никто не страдает (центр доверия — корневой УЦ как был так и остаётся). Единственными пострадавшими оказываются люди, чьи сертификаты оказались скомпрометированы (им нужно получить новые от нового УЦ).
Кажется, разницы в этом никакой? Ну был корневой, стал «второго уровня» — всё равно компрометация режет большую дыру в инфраструктуре (в случае одного УЦ — размером в инфраструктуру).
При этом компрометация ключа корневого УЦ означает ровно то же, что и в случае одиночного УЦ (даже больше, так как инфраструктура с несколькими УЦ обычно больше инфраструктуры с единственным УЦ) — полное уничтожение инфраструктуры с необходимостью вручную устранять все её следы (чтобы сервер, например, перестал принимать соединения от пользователей, чьи сертификаты подписаны скомпрометированным ключом, нужно вручную поменять конфигурацию сервера — и так с каждым сервером, маршрутизатором и т. д., не говоря уже про, например, финансовый отдел, который надо лично известить о том, что платёжные поручения, подписанные сертификатом из уничтоженного PKI больше принимать нельзя).
Помимо большей защиты корневого УЦ, промежуточные УЦ дают очень важную возможность: делегировать права на выписывание сертификата администраторам промежуточных УЦ. Они могут быть менее квалифицированы, чем администратор корневого УЦ (им нужно меньше думать об инфраструктуре, их ошибка менее фатальна), и их может быть практически неограниченное количество. Например, свой УЦ у каждого филиала организации.
Множество независимых УЦПравить
В ситуации, когда есть несколько независимых УЦ, между которыми должно быть взаимодействие (или, между обладателями сертификатов которых должно быть взаимодействие), следует различать две ситуации: административное разделение с целью построения сложной сети и ситуацию, когда взаимодействуют инфраструктуры, разделённые в силу объективных обстоятельств (например, PKI двух различных организаций).
Первое нужно для реализации надёжной и сложной иерархии, второе — попытка обеспечить хоть какую-то работу двух (возможно, не очень совместимых между друг другом) инфраструктур.
Важной особенностью инфраструктуры независимых УЦ является то, что она не является иерархией — это уже не древовидная структура, а граф произвольного вида (в котором могут быть петли, а в результате каких-то катаклизмов — и обособленные участки). В этой ситуации, для взаимодействия УЦ из разных иерархий приходится выписывать сертификаты специального вида, которые называются кросс-сертификаты.
Удостоверяющие центры и сертификатыПравить
Передовое решение эпохи электронного документооборота, да. (Примерно так же бывает, когда выборку данных сначала распечатывают, потом заверяют печатью, отправляют, получатель эту распечатку сканирует, распознаёт, вбивает в свою базу данных. Глупо и неэффективно).
Куда интереснее будет, если нотариус заверит ключи отправителя в электронном виде. Своим, электронным ключом. Который мы знаем. На момент подписания (в электронном виде) документа, мы проверим, что ключ, которым подписан, заверен нотариусом. Если человек, подписывавший документ, будет отрицать, что подпись его, то нотариус, заверявший её, сможет подтвердить, что это таки попись обвиняемого.
Заметим, чтобы мы могли проверить, что ключ «а» действительно принадлежит человеку «А», мы должны увидеть не только подпись нотариуса на проверяемых ключах, но и явное доказательство, что эти ключи приналежат «А». То есть нотариус должен подписать не только открытый ключ (закрытый подписывать не нужно, так как закрытый ключ НИКОМУ не показывается, даже нотариусу), но и какую-то информацию об А. Например, его паспортные данные. Или другую идентичность.
Важно: мы должны ДОВЕРЯТЬ (в том смысле, как было описано ранее) нотариусу, то есть нотариус ведёт себя так, как мы от него ожидаем: он заверяет идентичность и подпись только проверив их (если нотариус заверит идентичность и подпись не проверив их, то он не оправдает нашего доверия). В принципе, документ подписывается обеими сторонами, то есть подписывающий тоже должен доверять тому нотариусу, который заверил наши ключи. Проще всего, если это один и тот же нотариус.
Так вот, важно: связь идентичности и открытых ключей называется СЕРТИФИКАТОМ. А тот, кто подписывает эту связь (и проверяет, что идентичность — это идентичность) называется УДОСТОВЕРЯЮЩИМ ЦЕНТРОМ. Понятно, что мы должны доверять удостоверяющему центру, если хотим проверять сертификаты, которые он подписал.
Но нотариусов же много! Один заверился в юр.конторе возле дома, второй возле дома. А живут — на разных концах города. Нам надо иметь открытые ключи всех нотариусов, чтобы проверять все возможные подписи? Глупо.
А что, если мы будем иметь единственный сертификат адвокатской коллегии, ключом которого подписываются сертификаты нотариусов, которые, в свою очередь, подписывают сертификаты людей (организаций)? Это будет удобнее.
Это — и есть иерархия удостоверяющих центров. Удостоверяющий центр заверяет подпись и идентичность нотариуса (и, это важно, указывает, что это нотариус, то есть лицо, имеющее право заверять чужие подписи). Нотариус заверяет ключи и идентичность персоны, однако, указывает, что этими ключами можно только подписывать договора (а вот заверять чужие сертификаты уже нельзя). Почему он это делает? Потому что он НЕ ДОВЕРЯЕТ лицам (у них нет нужной квалификации). Зато мы ему (нотариусу) доверяем. Почему? Потому что он не делает глупостей, а все его заверения — истины и могут быть приняты в суде.
Таким образом, всем жителям города достаточно иметь один сертификат для проверки подписей. Проверка выглядит так: получить сертификат, которым подписывали документ (сертификаты могут свободно распространяться, потому что не содержат в себе закрытых ключей). Проверить, что сертификат подписан кем-то (нотариусом?). Проверить, что сертификат нотариуса заверен адвокатской палатой. Если всё правильно, то есть сертификат признан годным, то мы проверяем, что подпись на документе подлинная и точно знаем, что это именно та подпись именно того лица, о котором написано в сертификате.
Вот эти отношения доверия — и есть суть PKI. PKI — это не процесс подписи, это процесс проверки того, что подпись принадлежит именно тому лицу, которое должно было подписать документ. Для этого используются удостоверяющие центры, которым мы доверяем.
Остаётся один маленький вопрос: а кто подписывает сертификат адвокатской коллегии? Если у адвокатской коллегии нет вышестоящего удостоверяющего центра, то она просто берёт и сама подписывает свой сертификат. Такой сертификат называется самоподписанным (или самовыданным).
А что мешает Васе Пупкину подписать свой собственный сертификат самому? Ничего! Берёшь и подписываешь. Только вот Васе Пупкину никто не верит. И его подписи (на самом себе) — грош цена. А вот адвокатской коллегии — верят. И потому, её сертификат берут и доверяют всему, что было подписано с помощью ключей этого сертификата.
Но если Вася Пупкин подло напишет в сертификате, что он на самом деле коллегия адвокатов и самоподпишет его? Как мы отличим «настоящую» адвокатскую коллегию от фальшивой?
Таким образом, и это очень важно: начальные отношения доверия устанавливаются вне PKI. PKI начинает работать в тот момент, когда мы уже имеем доверенный сертификат. Хотя бы один.
В принципе, существует множество схем доверия (об этом чуть позже), но в любом случае, должен быть хотя бы один центр сертификации, которому мы доверяем. Чуть-чуть забегая вперёд: в некоторых случаях единственным таким центром может быть сертификат пользователя (то есть пользователь сам себе удостоверяющий центр, которому он пока что (до визита к психиатру) доверяет).
Различные модели доверия
CA может проводить как упрощённую верификацию, только по домену (DV — когда проверяется, что заказывающий сертификат управляет настройками домена), так и расширенную (OV — верификация организации; EV — расширенная верификация организации). В зависимости от ситуации и типа запрошенного сертификата, верификация может включать проверку существования организации-заказчика, наличие действующих контактных данных и т. д.
Вследствие всего этого цены на сертификаты OV/EV-типа, для которых требуется проверка, а главное — гарантия (например, в виде страхования), могут оказаться весьма высокими. В этой связи стоит упомянуть модель «сеть доверия» (Web of trust), когда доверие распространяется не только от корневого сертификата, надёжность которого не подлежит сомнению, а от человека или организации, за которых поручились другие участники сети доверия.
Проще говоря, если подтверждено доверие к одному из участников сети, то оно применяется и ко всем остальным участникам той же сети. Сама процедура верификации обычно требует физического присутствия человека, поэтому распространение таких сетей может оказаться не слишком простым процессом.
В число недостатков подхода «сеть доверия» можно включить не очень понятную процедуру отзыва доверия (как усилиями самого участника сети, так и усилиями других лиц или организаций).
Примером CA, работающего по схеме сети доверия, является OpenCA. При минимальном уровне доверия их сертификаты по сути подтверждают только факт управления доменным именем. Кроме того, корневой сертификат OpenCA не входит по умолчанию в хранилища доверенных сертификатов ОС и отдельных программных продуктов — так что ещё предстоит убедить пользователя внести его вручную. Использование сертификатов для ресурсов коммерческой направленности, для ресурсов, обрабатывающих или хранящих частные данные, и т. п. становится проблематичным.
Организация EFF (Electronic Frontier Foundation) объявила о запуска в сентябре 2015 года сервиса Lets Encrypt, где бесплатный сертификат сможет получить каждый ресурс.
Открытые ключиПравить
Перед пониманием того, что есть инфраструктура открытых ключей, нужно чётко представлять себе что есть открытые ключи. В этом учебнике не будет ничего про криптографию, результаты криптографии принимаются «как есть». Хотя, часть криптоалгоритмов может страдать уязвимостями, быть быстро взламываемыми и т. д., но они воспринимаются как данное (то есть без анализа устойчивости). Все случаи взлома, раскрытия, подделки и т. д. мы отнесём к одной категории — компрометации ключей. Это не совсем верно, так как компрометация алгоритма делает невозможным некоторые функции PKI, но в первом приближении об этой проблеме можно не думать.
Итак, что нам нужно из криптографии?
Во-первых, концепция криптофункции.
Криптофункция — функция, позволяющая из текста и ключа сделать шифр, такого типа, что даже имея несколько пар «текст-шифр» невозможно угадать ключ, и такой, что воссоздать текст из шифра можно только с помощью ключа. (Ключ, вообще, очень хорошее название, оно более ёмкое, чем «пароль» — ключ похож на обычный железный ключ — мы можем иметь много открытых и закрытых замков, но открыть данный конкретный замок мы можем только имея данный конкретный (подходящий к этому замку) ключ).
Криптография (использование криптофункций) бывает двух видов: симметричная и асимметричная (то есть с открытыми и закрытыми ключами). В симметричной криптографии ключ для расшифровки такой же, как для шифровки. Этот тип криптографии нас не интересует.
Криптография асимметричная же (являющаяся основой PKI) использует разные половинки ключа для шифровки и расшифровки. Половинки равноценны: если мы ключ разделили на две половинки A и B, то зашифровав с помощью A, мы можем расшифровать с помощью B. Зашифровав с помощью B мы можем расшифровать с помощью A (и только!). Мы не можем расшифровать шифр, созданный с помощью A, используя A. И наоборот, зашифрованное B не может быть расшифровано с помощью B. Более того (и это есть основа криптографии), ничем, кроме соответствующей половинки ключа, шифр не может быть расшифрован. Если B — шифровало, то ТОЛЬКО A может расшифровать. Если А шифровало, то ТОЛЬКО B может расшифровать.
Более того, процесс создания половинок A и B таков, что они могут быть созданы только вместе, одновременно. Нельзя сначала сделать A, а потом B. И наоборот — точно так же. (Соответственно, мысль: если мы посеяли одну половинку ключа, то вторую не удастся восстановить).
Мы своим произволом (административным решением, не имеющим под собой технического обоснования) объявляем одну половинку ключа открытым ключом, а вторую, ей соответствующую, закрытым ключом. Комбинацию открытого и закрытого ключа мы назовём ключевой парой. С точки зрения математики не имеет разницы кто есть кто. С административной же важно не то «кто есть кто», а чтобы использование (хранение и т. д.) открытых/закрытых ключей было разным. На самом деле, именно это — идея, что открытый и закрытый ключ используются с разными целями, и есть истинная цель асимметричной криптографии. Термины «закрытый» и «открытый» ключи немного неудачны. Им соответствуют более точные английские термины: private key (закрытый ключ) и public key (открытый ключ). Эти термины точнее, их дословный перевод: частный (личный) ключ и общественный ключ, соответственно.
Как понятно из английских названий, публичный (открытый) ключ мы предоставляем публике, а приватный (закрытый) храним у себя в чулане в секрете от всех остальных. Любой желающий может зашифровать некий текст (публично известным) открытым ключом и послать его нам. НИКТО, повторю, НИКТО (даже ФСБ, ФНС, ОБЭБ, ООН, ОБСЭ, МАГАТЕ, МАРДУК, ФБР и т. д.) не сможет расшифровать его (не применив силовые методы к отправителю/получателю, но это уже другой вопрос). НИКТО, у кого нет закрытого ключа НЕ МОЖЕТ расшифровать это сообщение. А владелец закрытого ключа (получатель) — может. Заметим, что пара открытый-закрытый ключ должны быть именно ПАРОЙ, какой попало закрытый ключ шифр от какого попало открытого ключа не сможет расшифровать. Таким образом, дав другу открытый ключ (его можно не прятать, так как обладание им никому ничем не поможет, и «дать другу» можно, например, по электронной почте или выложив на веб-сайте), вы дадите ему возможность отправить вам сообщение в зашифрованном виде, которое расшифровать можете только вы. Кстати, если друг пришлёт вам свой открытый ключ (из своей пары ключей, сохранив в уютной нычке секрете свой закрытый ключ), то вы так же сможете ему отправить сообщение в зашифрованном виде.
Оппа. Лёгкое движение руками мозгом — и у нас защищённый канал связи, который можно прослушивать сколько влезет, но из которого не получится ничего понять (кроме факта шифрованной переписки). Заметим, для установления защищённого канала связи мы даже не предпринимали каких-то серьёзных усилий (вроде передачи шифроблокнотиков резиденту, паролей и явок).
Это и есть суть асимметричной криптографии.
ПодписьПравить
Криптохеш — это такой хэш, который трудно подобрать. На самом деле требований к хешу много. Процитируем Википедию:
Требования к криптохешу:
, имеющее такой же хеш. Это свойство также называется необратимостью хеш-функции.
Для криптографических хеш-функций также важно, чтобы при малейшем изменении аргумента значение функции сильно изменялось. В частности, значение хеша не должно давать утечки информации даже об отдельных битах аргумента. Это требование является залогом криптостойкости алгоритмов шифрования, хеширующих пользовательский пароль для получения ключа.
Чтобы не ломать голову, сформулируем требования к криптохешу в простом виде: хеш сообщения не подделать. И под заданный хеш не получится подобрать другое сообщение.
Теперь, предположим, что мы для заданного сообщения сделаем криптохеш, зашифруем только хеш своим ЗАКРЫТЫМ ключом и положим результат в подпись письма. И отдадим другу. У которого есть наш открытый ключ. Как мы сказали раньше, открытый ключ и закрытый строго обратны друг для друга (открытым ключом можно расшифровать то, что зашифровано закрытым). Друг, приняв сообщение, сделает ту же самую хеш-функцию. После чего он расшифрует хеш из подписи. Если они совпали, то сообщение именно то, которое было подписано.
Можно ли подделать подпись? Для этого нужно каким-то образом зашифровать хеш сообщения тем самым ЗАКРЫТЫМ ключом, второй половинкой которого (соответствующим открытым ключом) будут пытаться расшифровать. А где ж его взять-то, если он в чулане спрятан секретный? Значит, подделать подпись не получится.
Второй вопрос: можно ли поменять уже подписанное сообщение, так, чтобы вместо $10 там было $100? (дописать нолик, или даже, чуть меньше, заменить единичку на двойку). Что при этом мы должны сделать? Подпись мы подделать не можем. Значит, мы должны так поменять сообщение (например, добавив пробелов, лишних запятых и т. д.), чтобы хеш изменённого сообщения был такой же, как у исходного. А подпись тогда будет та же самая. Но мы же чуть раньше сказали, что подобрать сообщение под заданный хеш очень сложно (потому-то он «криптохеш» и называется). А «очень сложно» у математиков означает «невозможно» в реальной жизни.
То есть подписанное сообщение невозможно подделать.
Подпись и шифрованиеПравить
Основная функция, которую берёт PKI из криптографии, это функция подписи. Для выполнения этой функции создаётся пара ключей: открытый и закрытый, при этом открытый публикуется, а закрытый прячется. Заметим, что с точки зрения инфраструктуры шифрование второстепенная функция. Отношения доверия выстраиваются, в первую очередь, основываясь на подписях. В то же самое время, область применения PKI очень тесно связана с шифрованием (так как в распоряжении пользователей уже есть ключи, пригодные для шифрования, то грех ими не воспользоваться).