Введение в криптографию и сертификаты

Основы криптографии

Криптография - область математики, связанная с защитой информации. Решает задачи засекречивания информации (шифрования), проверки ее подлинности (аутентичности) и целостности.

Секретность данных

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

Способность симметричных систем шифрования противостоять атакам зависит от стойкости алгоритма и длины ключа. "Стойкость" означает, что система хорошо спроектирована, защищена и выдержала все предыдущие атаки, а кроме того известны все слабости алгоритма. Если алгоритм стойкий, самая эффективная атака на него - атака прямым перебором всех возможных значений ключа. Длина ключа измеряется в битах, например 40-разрядный, 56-разрядный или 128-разрядный ключ. Чем больше длина ключа, тем большего времени потребует атака прямым перебором.

В настоящее время 40-разрядные симметричные ключи считаются весьма ненадежными, для них время полного перебора на высокопроизводительном компьютере оценивается минутами. Рекомендуется использовать 128-разрядные ключи.

Наиболее известные симметричные алгоритмы шифрования:

Из всех криптографических систем симметричные системы обладают самой высокой скоростью шифрования и расшифровки. Однако в симметричных системах есть большая проблема: две стороны должны как-то договориться о ключе шифрования. Передавать ключ по незащищенному каналу нельзя, а если предположить, что стороны имеют в своем распоряжении защищенный канал для передачи ключа, то шифрование им вовсе не нужно: все данные следует передавать по защищенному каналу. В общем виде эта проблема известна как задача распределения ключей и ставится так: как одна сторона может безопасно передать ключ другой стороне по незащищенному каналу связи? На этот вопрос мы ответим позже в ходе рассмотрения асимметричных криптографических систем.

Проверка целостности данных

Проверка того, что информация не была искажена - важный аспект защиты информации. Для этого криптографические системы используют хэш-функции. Хэш-функция преобразует большой объем данных в маленький хэш (другое название - дайджест), длина которого обычно составляет 128 или 160 бит.

Основные характеристики дайджестов:

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

Перед отправкой сообщение можно хэшировать и добавить к нему полученный дайджест. Получатель может заново вычислить дайджест и сравнить с полученным. Если хэши совпадают, значит и данные не были изменены. Правильно? Не совсем. Ничто не мешает злоумышленнику изменить сообщение, вычислить хэш и добавить его к модифицированному сообщению. Значит перед отправкой хэш сообщения необходимо как-то защитить. Эту проблему мы решим позднее при рассмотрении цифровой подписи.

Обычно применяются следующие хэш-функции:

Хэширование выполняется очень быстро даже для больших объемов данных.

Проверка подлинности

Помимо симметричных систем шифрования существуют также асимметричные, в которых вместо одного ключа, используемого обеими сторонами, применяются пары ключей. Каждая сторона владеет двумя математически связанными ключами, один из которых называется открытым, а другой - закрытым. Обычно оба ключа - очень большие числа (512, 1024 или 2048 бит).

Т.о., если A получил сообщение якобы от B и это сообщение можно расшифровать открытым ключом B, значит сообщение было зашифровано закрытым ключом B, а значит оно от B и пришло, поскольку только B имеет доступ к своему закрытому ключу. Т.о. можно доказать подлинность сообщения. Правда есть проблема: у A нет гарантии, что открытый ключ, использованный для расшифровки, принадлежит именно B. Этот открытый ключ A получил по незащищенному каналу, а значит злоумышленник мог его подменить. Эту проблему мы решим позднее при обсуждении сертификатов.

С другой стороны, если A хочет послать секретное сообщение, которое должен прочитать только B, A должен зашифровать сообщение открытым ключом B, доступным любому желающему. Такое сообщение можно расшифровать только закрытым ключом B, доступ к которому имеет только B. И снова та же проблема: где гарантия, что открытый ключ, использованный для шифрования, принадлежит именно B?

Выводы.

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

Самая известная система шифрования с открытым ключом - RSA - названа по именам ее создателей: Ривеста, Шамира и Адельмана, основателей компании RSA Data Security.

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

Соединяем хэширование и проверку подлинности: цифровая подпись

Подписание данных - процедура, объединяющая две криптографические технологии: асимметричное шифрование и хэширование. Процедура проста: ПО пользователя A хэширует сообщение, после чего шифрует полученный дайджест закрытым ключом A. Полученная в результате цифровая подпись добавляется к сообщению. Сообщение в открытом виде передается пользователю B, его ПО с помощью открытого ключа A расшифровывает подпись, получая исходный дайджест. Затем ПО пользователя B хэширует полученное сообщение и сравнивает вычисленный дайджест с исходным. Если два дайджеста совпадают, значит

Т.о. вопрос защиты дайджеста от модификации мы решили.

Добавим шифрование

А как же пользователю A послать секретное сообщение для B? Если бы асимметричная криптография не была такой медленной, пользователь A мог бы просто зашифровать все сообщение открытым ключом B. Однако асимметричное шифрование даже небольшого сообщения займет массу времени. Вместо этого, ПО пользователя A генерирует случайное число, которое будет выступать в роли сеансового ключа для симметричного шифрования. Сеансовый ключ (обычно 128 бит) шифруется открытым ключом B, результат отсылается B. Затем сообщение шифруется сеансовым ключом и также отправляется B. ПО пользователя B узнает сеансовый ключ, расшифровав его закрытым ключом B. Далее симметричным сеансовым ключом расшифровывается все остальное. Описанная здесь процедура передачи зашифрованного сеансового ключа называется обменом ключами.

Разумеется, шифрование сеансовым ключом можно использовать совместно с подписанием сообщения. В такой схеме симметричная криптография обеспечивает секретность данных, хэширование - их целостность, а асимметричная криптография гарантирует подлинность данных и служит для обмена ключами. Цель достигнута? Не совсем. Вспомним отложенную проблему.

  1. Как гарантировать, что открытый ключ пользователя B, используемый ПО пользователя A для шифрования сеансового ключа принадлежит именно пользователю B?
  2. Как гарантировать, что открытый ключ пользователя A, используемый ПО пользователя B для расшифровки цифровой подписи с целью получения исходного дайджеста сообщения, принадлежит именно пользователю A?

Эту проблему позволяют решить цифровые сертификаты.

Сертификаты

Сертификат - это двоичная структура, содержащая информацию о владельце открытого ключа. Самая распространенная форма сертификатов - сертификаты X.509 версий 1, 2 и 3. X.509 - это промышленный стандарт сертификатов, определенный в RFC-2459; его поддерживают все версии Windows от 95 до XP.

Сертификат X.509 содержит по крайней мере следующие поля:

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

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

Формат имен X.500

Формат имен X.500 - это стандартный метод однозначного именования объектов. Его применение уходит корнями к иерархическим службам каталогов X.500, в которых для идентификации сущностей в составе дерева каталогов использовались отличительные имена (DN - distinguished name). Отличительное имя представляет собой путь к подчиненному узлу дерева и выглядит, например, так: "C=RU, S=Moscow, L=Zelenograd, O=Polak IT, OU=Software, CN=Alexander Shastin, E=shur@polak.ru".

Основные компоненты имени X.500.

Компонент Описание
С Страна двумя буквами, соответствует имени национального корневого домена
S или SP Штат, область, провинция
L Населенный пункт
STREET Адрес в населенном пункте
O Организация
OU Отдел в организации
CN Общее имя
E или Email Адрес электронной почты

Имена эмитента и субъекта в первой и второй версиях X.509 задаются только в формате X.500, а сертификаты третьей версии могут использовать альтернативные форматы имен.

Сертификаты и доверие

Итак, сертификат связывает открытый ключ с субъектом, например компьютером или пользователем. Но как убедиться, что сертификат и открытый ключ в нем принадлежат субъекту? Это вопрос доверия к эмитенту сертификата.

Сертификаты  издаются и подписываются эмитентами; другое название - центры сертификации (ЦС) или certificate authority (CA). Издавая сертификат, центр сертификации выполняет следующие действия:

  1. Проверяет, является ли субъект тем, за кого себя выдает.
  2. Создает сертификат и подписывает его с помощью своего закрытого ключа.
  3. Выдает сертификат субъекту.

Теперь понятно, как пользователю A узнать, что сертификат с именем субъекта B и открытый ключ, содержащийся в сертификате, на самом деле принадлежат пользователю B. Если A верит выдавшему сертификат для B эмитенту CA1, что подлинность субъекта B проверена, значит сертификат с именем субъекта B может принадлежать только B.

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

  Этапы проверки сертификата Этапы проверки удостоверения личности
1 Эмитенту сертификата можно доверять Указанной в документе организации, выдавшей удостоверение, можно доверять
2 Сертификат подписан закрытым ключом эмитента, цифровая подпись действительна На удостоверении имеется печать выдавшей его организации; нет следов правки, подчистки и т.п.
3 Период действия сертификата начался и не истек Период действия документа начался и не истек
4 Сертификат не был отозван эмитентом Нет информации об аннулировании удостоверения
5 Имя субъекта в сертификате соответствует ожидаемому Фотография субъекта соответствует оригиналу

Чтобы все доверяющие стороны могли проверить цифровые подписи сертификатов, центр сертификации должен предоставить им свой собственный открытый ключ. Подобно конечным пользователям, центр сертификации предоставляет свой открытый ключ в виде сертификата с цифровой подписью. Однако поля "субъект" и "эмитент" в таком сертификате содержат одну и ту же информацию, а цифровая подпись выполняется собственным закрытым ключом. Т.е. сертификат центра сертификации является самоподписываемым (self-signed).

Центры сертификации можно разделить на две категории: открытые и частные. Открытые ЦС действуют через Internet, предоставляя услуги сертификации всем желающим. К таковым относятся например известные компании VeriSign и Thawte Consulting. Частные ЦС обычно принадлежат корпорациям или закрытым сетям. Такие ЦС, как правило, выдают сертификаты только пользователям внутри их собственной сферы деятельности.

Цепочки сертификатов

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

Если сертификат конечного пользователя выдан не корневым, а промежуточным ЦС, проверка такого сертификата превращается в проверку цепочки сертификатов (другое название - путь сертификации). Каждый сертификат в цепочке д.б. подписан с помощью закрытого ключа следующего сертификата в цепочке. Для каждого сертификата следует проверить, что срок его действия не истек, сертификат не был отозван и удовлетворяет требованиям расширений, определяемых сертификатами, расположенными выше в цепочке. Далее, если имеется доверие к корневому сертификату, оно автоматически распространяется на все сертификаты цепочки и, как следствие, на открытый ключ конечного пользователя.

Использование ключа

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

Расширениями X.509 v3 "использование ключа" ("key usage") и "улучшенное использование ключа" ("enhanced key usage") задается набор допустимых вариантов использования ключа, например SSL-аутентификация сервера и защита электронной почты. Очень важно использовать сертификаты строго по назначению. Если хоть один сертификат в цепочке используется не по назначению, цепочка не пройдет проверку. Естественно, при движении по цепочке сертификатов от корня к листу область разрешенного использования ключа может только сужаться.

Системные хранилища сертификатов

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

Ниже перечислены основные (не все) хранилища компьютера.

Хранилища Физические составные части хранилища
ID Название ID Название Расположение
My "Личные" (содержит сертификаты компьютера) .Default ".Реестр" HKLM\Software\Microsoft\
SystemCertificates\My
Root "Доверенные корневые центры сертификации" .Default ".Реестр" HKLM\Software\Microsoft\
SystemCertificates\Root
CA "Промежуточные центры сертификации" .Default ".Реестр" HKLM\Software\Microsoft\
SystemCertificates\CA

Как можно видеть из таблицы, хранилище компьютера My.Default, оно же "Личные.Реестр" физически располагается в ветви реестра "HKLM\Software\Microsoft\SystemCertificates\My".

В следующей таблице приведены основные хранилища пользователя. В случае использования профилей (для Windows NT 4.0, Windows 2000 и Windows XP - всегда) эти хранилища индивидуальны для каждого пользователя компьютера. Обратите внимание: хранилища Root и CA состоят из двух частей: собственно хранилища пользователя и ссылки на хранилище локального компьютера, т.о. для всех пользователей хранилища Root и CA содержат общую часть - соответствующее хранилище компьютера.

Хранилища Физические составные части хранилища
ID Название ID Название Расположение
My "Личные" (содержит сертификаты пользователя) .Default ".Реестр" HKCU\Software\Microsoft\
SystemCertificates\My
Root "Доверенные корневые центры сертификации" .Default ".Реестр" HKCU\Software\Microsoft\
SystemCertificates\Root
.LocalMachine ".Локальный компьютер" Представляет собой ссылку на хранилище компьютера "Root"
CA "Промежуточные центры сертификации" .Default ".Реестр" HKCU\Software\Microsoft\
SystemCertificates\CA
.LocalMachine ".Локальный компьютер" Представляет собой ссылку на хранилище компьютера "CA"

Хранилища служб существуют только под Windows NT 4.0, Windows 2000 и Windows XP. Ниже приведены основные хранилища службы.

Хранилища Физические составные части хранилища
ID Название ID Название Расположение
My "Личные" (содержит сертификаты службы) .Default ".Реестр" HKLM\Software\Microsoft\Crytography\
Services\ServiceName\SystemCertificates\My
Root "Доверенные корневые центры сертификации" .Default ".Реестр" HKLM\Software\Microsoft\Crytography\
Services\ServiceName\SystemCertificates\Root
.LocalMachine ".Локальный компьютер" Представляет собой ссылку на хранилище компьютера "Root"
CA "Промежуточные центры сертификации" .Default ".Реестр" HKLM\Software\Microsoft\Crytography\
Services\ServiceName\SystemCertificates\CA
.LocalMachine ".Локальный компьютер" Представляет собой ссылку на хранилище компьютера "CA"

Во всех трех случаях в названии хранилища Root ("доверенные корневые центры сертификации") употребляется слово "доверенные" и неслучайно. Помещая сертификат корневого ЦС в хранилище Root, мы автоматически обеспечиваем доверие к этому ЦС.

Доступ к хранилищам сертификатов пользователя имеет только этот пользователь. Доступ по записи к хранилищам компьютера и служб этого компьютера имеет только администратор компьютера.

Закрытые ключи чаще всего также хранятся в системном реестре, но отдельно от сертификатов. Если на компьютере имеется закрытый ключ, соответствующий сертификату, в изменяемых свойствах сертификата присутствует ссылка на контейнер закрытого ключа. Очень важно, чтобы закрытый ключ хранился в той же ветви реестра, что и сертификат, т.е. либо оба в ветви HKLM, либо оба в HKCU. В противном случае могут быть проблемы доступа к закрытому ключу сертификата.

Средства просмотра сертификатов и хранилищ

Наиболее удобным интерактивным средством для просмотра системных хранилищ и сертификатов является оснастка "сертификаты" консоли mmc. Оснастка "сертификаты" позволяет просматривать хранилища текущего пользователя, локального компьютера и его служб, а также сертификаты удаленного компьютера и его служб, импортировать сертификаты в системное хранилище или экспортировать их в файл, перемещать сертификаты из хранилища в хранилище и пр. На работу с хранилищами удаленного компьютера наложено ограничение: отсутствует доступ к закрытым ключам сертификатов. У этого средства всего один существенный недостаток: оно реализовано только под Windows 2000 и Windows XP. Под остальными платформами достойной замены оснастке "сертификаты" нет.

В Internet Explorer также имеется диалог "Диспетчер сертификатов" (см. меню "Сервис\Свойства обозревателя", закладку "содержание", кнопка "Сертификаты"). Однако этот диалог позволяет просматривать только хранилища текущего пользователя, т.е. сертификаты из хранилища локального компьютера My увидеть нельзя.

Кроме того, имеется работающая под любой платформой утилита командной строки certmgr.exe, позволяющая в консольном режиме посмотреть свойства сертификата, добавить сертификат в системное хранилище или удалить его. У утилиты две проблемы: не устанавливает код возврата в случае ошибки и задает много вопросов.

Импорт и экспорт сертификатов

Помимо системных хранилищ, сертификаты могут храниться в файлах. Файлы с расширением .CER, .CRT, .DER содержат единственный сертификат без закрытого ключа в кодировке DER или base64. Если для сертификата из такого файла имеется парный закрытый ключ, он обычно хранится в виде защищенного паролем файла с расширением .PVK. Для хранения цепочки сертификатов без закрытых ключей используется файл с расширением .P7B (стандарт PKCS #7). Для хранения цепочки сертификатов и закрытых ключей предназначаются файлы с расширением .P12 и .PFX (стандарт PKCS #12). Закрытый ключ в PFX-файле, как и в PVK-файле, защищается паролем.

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

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

  1. Нужна ли усиленная защита закрытого ключа? Если Вы включите усиленную защиту, операционная система будет запрашивать подтверждение при любой попытке использования закрытого ключа. Понятно, что для неинтерактивных приложений (например для служб) подобное поведение совершенно не подходит. Впрочем, даже для некоторых интерактивных приложений, например Outlook или Outlook Express, частое появление этого запроса быстро надоест, поэтому прежде чем устанавливать соответствующий флажок следует хорошо подумать.
  2. Разрешать ли в будущем экспорт закрытого ключа из системного хранилища? Не разрешать экспорт закрытого ключа - весьма разумная политика, если Вы храните копию ключа в PFX или PVK-файле. К сожалению, иногда не разрешать экспорт закрытого ключа невозможно. Имеется, например, такое системное требование: для использования закрытого ключа в протоколе SSL под Windows 95, Windows 98, Windows ME и Windows NT 4.0 закрытый ключ должен быть помечен как "экспортируемый". Windows 2000 и Windows XP лишены этого недостатка.

Следует быть очень внимательным при экспорте и импорте сертификатов вместе с закрытым ключом. Следует помнить обо всех копиях закрытого ключа и убедиться, что все они защищены.

Использование сертификатов в протоколах передачи данных

  1. Протокол Secure Socket Layer (SSL) - Internet-протокол для шифрования и аутентификации на уровне сеанса, предоставляющий защищенный канал между двумя сторонами  (сервером и клиентом). SSL обеспечивает аутентификацию сервера и необязательную аутентификацию клиента, чтобы противодействовать прослушиванию, постороннему вмешательству и подмене сообщений в приложениях типа клиент-сервер.

    SSL работает на транспортном уровне модели OSI и не зависит от протокола, используемого на прикладном уровне. Протоколы прикладного уровня (HTTP, FTP, ...) могут прозрачным образом располагаться поверх SSL.

    SSL был разработан Netscape в 1994 году. С тех пор получил широкое признание и в настоящее время поддерживается практически всеми Web-браузерами и Web-серверами, а также прочими программными и аппаратными средствами. К настоящему времени реализованы три версии: SSLv2, SSLv3 и TLSv1 (также известный как SSLv3.1). Доминирующими являются версии SSLv3 и TLSv1. Кроме того с целью исправления ошибок в SSLv2 Microsoft разработала свой собственный SSL-протокол PCTv1, который не был стандартизован, и в настоящее время практически не используется.

    Согласно протоколу SSL перед началом обмена прикладного уровня клиент и сервер выполняют handshake (рукопожатие), устанавливая т.о. защищенный канал связи.

    1. Клиент отправляет приветствие серверу. В приветствии перечисляются версии SSL, алгоритмы шифрования и сжатия, поддерживаемые клиентом.
    2. Сервер отправляет клиенту приветствие. В приветствии указывает выбранную версию SSL, выбранный алгоритм шифрования, выбранный алгоритм сжатия. Сервер отправляет клиенту цепочку сертификатов для аутентификации и (необязательно, обычно не используется!) запрос сертификата клиента.
    3. Клиент проверяет сертификат сервера, отправляет серверу свой сертификат (если просили), а также значение сеансового ключа, зашифрованное открытым ключом серверного сертификата. Клиент переходит в режим шифрования сообщений.
    4. Сервер проверяет клиентский сертификат (если был нужен) и переходит в режим шифрования сообщений.
    5. Защищенное соединение установлено, далее клиент и сервер обмениваются сообщениями протокола прикладного уровня, зашифрованными при помощи сеансового ключа.

     

  2. Secure/Multipurpose Internet Mail Extensions (S/MIME) - это спецификация для защищенной работы с электронной почтой. Если у пользователя есть закрытый ключ и связанный с ним сертификат, он может подписать свое сообщение электронной почты, что позволит получателям аутентифицировать сообщение. Имея доступ к сертификату получателя, пользователь может послать ему зашифрованное сообщение. Для обмена подписанными и зашифрованными сообщениями у обеих сторон должен быть сертификат и закрытый ключ. S/MIME поддерживают, в частности, почтовые клиенты Outlook и Outlook Express.

Список литературы

  1. Э. Джонс, Д.Оланд. "Программирование в сетях Microsoft Windows". ISBN 5-318-00725-2
  2. С. Бернет, С. Пэйн. "Криптография. Официальное руководство RSA securuty". ISBN 5-9518-003-X
  3. RFC-2459