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

Шифрование

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

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

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

Используемое в PKI асимметричное шифрование подразумевает два ключа: открытый ключ и закрытый ключ. Как показано на рисунке 1, процесс начинается, когда отправитель зашифровывает сообщение с использованием открытого ключа. Отправитель может запросить открытый ключ у предполагаемого получателя сообщения либо загрузить его из открытой папки или с сайта. Только предполагаемый получатель сообщения сможет расшифровать его с использованием надлежащего закрытого ключа. Несколько более медленное, чем симметричное шифрование, ассиметричное шифрование в свою очередь не требует обмена секретным ключом.

 

Рисунок 1. Процесс ассиметричного шифрования

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

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

Цифровые подписи

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

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

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

 

Рисунок 2. Алгоритм обеспечения целостности данных

Цифровые сертификаты

Цифровые сертификаты — это электронные документы, которые содержат:

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

Цифровые сертификаты, как правило, распространяются в формате, определяемом стандартом X.509.

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

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

Служба проверки достоверности, в свою очередь, обеспечивает проверку действительности сертификатов в реальном времени. Это можно сделать посредством проверки списков отзыва сертификатов (CRL) или с использованием протокола оперативного состояния сертификата Online Certificate Status Protocol (OCSP). Но сначала мне бы хотелось рассказать о самоподписанных сертификатах.

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

CRL и OCSP

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

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

OCSP — базирующийся на HTTP протокол, использующий минимальную пропускную способность сети для выполнения проверки состояния сертификата, в противоположность тем клиентам, которые загружают CRL. OCSP определяет состояние сертификата, запрашивая информацию об одном-единственном сертификате, и, следовательно, объем получаемых клиентом данных остается тем же самым, даже если количество отозванных сертификатов увеличивается. Начиная с Windows Server 2008 и Windows Vista, OCPS по умолчанию поддерживается в Microsoft Internet Explorer (IE). Выпускающий сертификаты сервер должен также поддерживать OCSP и соответствующим образом конфигурировать их.

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

У каждого CA может наступить такой момент, когда он уже не в состоянии самостоятельно справиться с обслуживанием всего потока запросов на проверку и выпуск сертификатов для всех заинтересованных в этом объектов. Поэтому корневой CA имеет возможность предоставить подчиненному CA полномочия на выпуск сертификатов. Такая система формирует иерархию «корневой/подчиненный».

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

Например, в случае с веб-браузером сертификаты корневого CA поставляются вместе с клиентской операционной системой и формируют цепочку доверия непосредственно до открытого CA, такого как VeriSign и Thawte. Если СА, выпустивший сертификат, не является доверенным, то цепочка сертификатов обязательно должна включать CA, который таковым является.

Процесс проверки достоверности сертификата происходит следующим образом: клиентская операционная система проверяет поле сертификата «Кем выдан», чтобы понять, какой именно CA выпустил этот сертификат. Далее операционная система расшифровывает цифровую подпись проверяемого сертификата, используя при этом открытый ключ сертификата подчиненного или корневого CA его издателя, для того чтобы прочитать хеш цифровой подписи. Затем клиентская операционная система генерирует второй хеш для проверяемого сертификата и сравнивает его с хешем, полученным из расшифрованной цифровой подписи. Если они совпадают, то сертификат признается действительным (достоверным).

Вся картина целиком

Давайте посмотрим, как из отдельных фрагментов складывается целостное решение PKI. Шифрование SSL обычно используется веб-сайтами и веб-браузерами для проверки подлинности веб-сервера и зашифровки данных для передачи по открытым каналам Интернета. Протокол Transport Layer Security (TLS) является расширенной версией SSL (а точнее говоря, SSL 3.0) и используется, как правило, для защищенных интернет-транзакций.

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

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

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

Планирование решения PKI

Теперь, когда вы знаете, как работает шифрование, цифровые подписи и цифровые сертификаты, можно начинать планировать, каким образом надлежит обеспечить защиту уязвимых данных. Для начала нужно решить, что вы, собственно, хотите получить: шифрование, авторизацию или и то и другое. Развертывание и запуск собственного решения PKI — весьма непростая задача (к тому же с весьма ощутимыми затратами на управление), поэтому стоит тщательно все взвесить и решить, действительно ли оно необходимо. Системам, в которых используется IPsec или доменная изоляция, часто вовсе не требуется PKI. Также важно подумать над тем, как планируется использовать PKI в будущем, и убедиться, что развертываемое решение в достаточной степени масштабируемое. И наконец, при развертывании решения PKI всегда опирайтесь на чей-либо успешный опыт.

Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF