1.Сертификаты. Общие сведения.
1.1.ИСТОРИЯ. Одной из целей разработки Windows 2000 явилось радикальное решение проблемы виртуальных частных сетей (VPN), причем самым важным моментом в обеспечении безопасности сети является гарантия безопасных сетевых подключений. Как уже отмечалось ранее, компания Microsoft допустила просчеты при выпуске первых версий протокола туннелирования "точка-точка" (РРТР) и версии 1 протокола аутентификации по методу "вызов-квитирование установления связи" фирмы Microsoft (MS-CHAP vl), и поэтому не решается повторить свой первый "печальный опыт". Одним из результатов подобного положения вещей является шаг к поддержанию стандартных задач со стороны Инженерной группы решения конкретной задачи Internet (IETF — Internet Engineering Task Force). Данные стандарты были проверены и подтверждены многими представителями данной отрасли, вследствие чего считаются более надежными в применении.
Непосредственным результатом данных исследований является внедрение стандартных технологий сертификатов. Благодаря встроенному стандартному клиенту и серверу сертификатов Windows 2000, обеспечивается средство взаимодействия с другими технологиями сертификатов, что свидетельствует о надежности примененной при разработке этой операционной системы технологии.
1.2.ПОНЯТИЕ О СЕРВЕРЕ СЕРТИФИКАТОВ. Операционная система Windows 2000 включает систему служб, протоколов и стандартов, позволяющих в сети устанавливать и управлять инфраструктурой обеспечения безопасности информации, основываясь на технологии общедоступных ключей. Инфраструктура открытого ключа системы Windows 2000 (PKI — Public Key Infrastructure) зависит от служб сертификатов, используемых для выпуска и управления цифровыми сертификатами. Сервер сертификатов полностью интегрируется с Active Directory и многими другими службами, благодаря чему системы могут использовать данную технологию при распределении и управлении сертификатами.
Назначение сертификатов заключается в предоставлении большего объема сведений, чем обычные имя пользователя и пароль, требуемые при выполнении аутентификации. При их использовании можно назначать права и характеристики, варьирующиеся в зависимости от типов сертификата. Также сертификаты могут применяться для выполнения следующих действий:
-
обеспечение защищенного доступа к Web-узлу, основываясь на сертификате пользователя;
-
ссылки на защищенные Web-подключения с установленным протоколом уровня защищенных сокетов (SSL — Secure Sockets Layer);
-
защищенная почтовая программа, гарантирующая подлинность, сохранность и конфиденциальность почтового сообщения;
-
присвоение кодового значения программе, гарантирующего подлинность авторства этой программы;
-
регистрация смарт-карт в домене Windows 2000;
-
зашифрованная файловая система (EFS — Encrypted File System);
-
протокол безопасности Internet (IPSec — Internet Protocol Security);
-
приложения и системы с настраиваемой системой безопасности.
В главе рассматривается инфраструктура PKI, которая является ключевой технологией для распределенных и неоднородных компьютерных сред, требующих наличия защищенной системы для обеспечения аутентификации и конфиденциальности данных.
Фирма Microsoft приводит неплохой пример, проводя аналогию между принципом действия данных отношений и системой водительских прав. В деловых кругах обычно доверяют удостоверению личности по водительским правам, поскольку всем хорошо известно, как протекает процесс выдачи прав и связанное с ним проведение удостоверения личности. То же самое происходит и с сертификатом, поскольку центр серти-фикации(СА — Certificate Authority) выполняет ту же самую процедуру, что и фирма BMV: он является поручителем удостоверения личности в мире цифровых технологий.
Шифрование методом симметричного ключа — процесс преобразования простого текста в зашифрованный с помощью одного и того же ключа и алгоритма. Примерами технологий, использующих шифрование методом симметричного ключа, могут служить протокол SSL с ключом сеанса (только защищенный канал SSL, а не аутентификация SSL), применяемый для шифрования сетевых данных, а также протокол Kerberos, использующий долговременные общие ключи между клиентами и центром распределения ключей. Алгоритмы симметричных ключей можно классифицировать на две категории: потоковые шифры, выполняющие поразрядное кодирование данных (RC4 — пример группового шифра), и блочные шифры, кодирующие данные по группам разрядов (RC2 -пример блочного шифра, размер блока которого равен 64 разряда).
Шифрование методом открытого ключа представляет технику асимметричного шифрования, при реализации которой два различных ключа выполняют взаимно дополняющие операции на основе одних и тех же алгоритмов. Алгоритмы с открытым ключом являются слишком медлительными при шифровании большого объема данных, поэтому в этих целях используются алгоритмы с асимметричным ключом. Последние алгоритмы относятся к алгоритмам специального назначения, например, алгоритмам RSA, использующимся при обмене ключами и цифровыми подписями. Алгоритм цифровой подписи (DSA — Digital Signature Algorithm), разработанный Федеральным правительством США, используется исключительно для выполнения цифровых подписей. Алгоритм Диффи-Хеллмана (Diffie-Hellman) используется для согласования или передачи ключей между двумя сторонами.
Хеширование представляет процесс ввода переменных (например, сообщение), в результате выполнения которого осуществляется вывод данных с фиксированной длиной строк (значение хеш-функции). Существует два уровня шифрования, выполняемого с помощью алгоритмов хеширования. Алгоритмы хеширования MD5, MD2 и MD4 производят 128-разрядные значения. Эти алгоритмы были разработаны лабораторией RSA Laboratories. Защищенный алгоритм хеширования (SHA— Secure Hash Algorithm), разработанный Федеральным правительством США, генерирует 160-разрядные значения. При этом данный алгоритм считается более безопасным, поскольку генерирует более длинные разряды хеширования.
Коды аутентификации сообщений (MAC — Message Authentication Code) имеют сходство с хеш-кодами, за исключением того, что помимо данных для MAC требуется ключ сеанса в качестве вводимой информации, применяемой для вычисления значения хеш-функции. Для повторного вычисления одного и того кода MAC потребуется ключ сеанса, а также данные, позволяющие установить связь между двумя сторонами. Поэтому обе стороны должны располагать ключом сеанса для создания одного и того же кода MAC.
1.3. ЦИФРОВЫЕ ПОДПИСИ. Благодаря цифровым подписям, обеспечивается механизм удостоверения подлинности переданных данных, а также идентифицируется личность, подписавшая сообщение или данные. Отправитель использует частный ключ в операции цифровой подписи, а получатель использует общедоступный ключ отправителя для удостоверения его подписи.
В силу того, что сами по себе цифровые подписи являются простыми данными, они могут передаваться вместе с защищаемыми ими данными. Они могут вкладываться в документ или присоединяться, например, к почтовому сообщению. Подпись, требующая более медленный алгоритм криптографии с общедоступным ключом, обычно использует значение хеш-функции данных, а затем подписывает данное значение. Это более практично, чем подписывание большого количества документов.
Использование сертификатов является весьма важным при выполнении цифровых подписей, шифровании и связывании ключей, используемых в учетных записях. Сертификаты связывают идентичность ключей субъекта (в основном, значение открытого ключа) с общей идентичностью. В качестве стандарта сертификатов была выбрана спецификация Х.509. Существуют два типа сертификатов Х.509: версия 1, не поддерживающая расширения, и версия 3, поддерживающая расширения.
1.4.Краткая история версий х.509
Сертификат Х.509 версии 1, появившийся в 1988 году, стал широко распространенным, однако по причине низкой степени интеграции приложений наблюдалось некоторое ограниченное использование сертификатов.
Сертификат Х.509 версии 2 включал поддержку уникальных идентификаторов субъекта и эмитента, в результате чего обеспечивалось повторное использование имен субъекта и/или эмитента в течение всего времени применения сертификата. Немного позже оказалось, что повторное использование имен небезопасно, вследствие чего для сертификатов не следует использовать уникальные идентификаторы. По этой причине сертификат версии 2 не нашел широкого применения.
Сертификат Х.509 версии 3, представленный в 1996 году, поддерживал расширения, причем любой пользователь мог задать расширение и включить его затем в сертификат. Одним из таких расширений является Key Usage, ограничивающее использование ключей при выполнении определенных задач. Можно установить приоритеты расширений для усиления действия, направленного на использование сертификата. Версия 3 обычно принимается как стандарт, поэтому все текущие приложения, основанные на сертификатах, должны поддерживать данную версию.
Сертификаты Х.509 версии 3
В промежутке между версиями 1 и 3 спецификации Х.509 произошло довольно много изменений. В следующем перечне описываются некоторые характерные признаки версии 3.
-
Поле Subject (Субъект), в котором указывается конечный объект, содержит имя пользователя, которому был выдан сертификат.
В поле Issuer (Эмитент) идентифицируется центр ЦС по имени.
-
Серийный номер сертификата — это уникальный номер, выданный ЦС, благодаря которому происходит идентификация сертификата среди всех сертификатов, выпущенных ЦС.
-
Открытый ключ субъекта фактически является значением общедоступного ключа сертификата данного пользователя, для которого существует соответствующий частный ключ.
-
Период достоверности определяет время, в течение которого будет действителен сертификат. Значение времени может измеряться в месяцах или годах; обычно сертификаты выдаются на один или два года для объекта или на больший срок для ЦС, в зависимости от используемой длины ключа. Обычно для периода достоверности устанавливаются даты Not-Before (He перед этим) и Not-After (He после этого). Это означает, что какое бы ни было текущее время, оно должно соответствовать датам, указанным в рассматриваемом окне проверки подлинности.
Расширения сертификатов предлагают дополнительную информацию, которая может включать такие сведения, как почтовое имя, частота использования сертификата (например, аутентификация клиента или защищенная почта), политики ЦС или используемые ими действия. И конечно же ЦС подписывает сертификат, в результате чего обеспечивается проверка его подлинности.
1.5.ЦЕНТР СЕРТИФИКАЦИИ. Центр сертификации (СА — Certificate Authority) — это служба, ответственная за выдачу сертификатов для инфраструктуры с открытым ключом. В роли ЦС может выступать общедоступный коммерческий сервер в Internet, либо какой-либо корпоративный сервер. Сертификаты могут использоваться различными способами, начиная с разрешения выполнять регистрацию с помощью смарт-карт, и завершая шифрованием электронной почты.
В силу того, что центр сертификации является частью структуры Windows 2000, было бы неплохо установить и сконфигурировать, по крайней мере, элементарную структуру сертификатов практически для любой компании.
Центр сертификации выпускает четыре типа сертификатов.
-
Сертификаты с автоподписью. Центр сертификации может выпускать сертификаты сам для себя. В данном случае мы имеем дело с сертификатами с автоподписью. Корневой ЦС имеет сертификат с автоподписью, благодаря чему устанавливаются полномочия иерархии.
-
Подчиненные сертификаты ЦС. Сервер ЦС может выпускать сертификаты для других серверов ЦС, назначая затем их официальными серверами сертификатов в данной иерархии. Это очень важный момент, поскольку во многих проектах эти ЦС будут выдавать сертификаты клиентам.
-
Сертификаты регистрации авторизации. Центр ЦС может также выдавать сертификаты администраторам. В данном случае речь идет об учетных записях, которые могут выступать в роли другой учетной записи с целью выполнения регистрации или других операций.
-
Сертификаты для конечных компонентов,например, компьютеров или пользователей. При выдаче сертификатов приложения или операционные системы могут быть сконфигурированы таким образом, что будут использовать модель безопасности, основанную на сертификатах. Это предотвратит попытки пользователей или системы в получении доступа к ресурсам без сертификата, относящегося к доверенной иерархии сертификатов.
-
ИЕРАРХИЯ СЕРТИФИКАТОВ. Иерархия сертификатов — это структура, основанная на доверительных отношениях безопасности. Простая иерархия представляет собой корневой сервер ЦС с подчиненными серверами ЦС, которые выдают сертификаты клиентам. Поскольку иерархия основана на доверительных отношениях, то выданному сертификату доверяют на всех уровнях иерархического дерева. Можно создать множество типов отношений между серверами ЦС, начиная с многочисленных уровней подчиненных серверов ЦС и заканчивая одноранговыми серверами ЦС. Общий поток, установленный между ними, всегда будет иметь форму доверительных отношений.
1.6.1.Доверительные отношения и иерархия ЦС. Чтобы сервер ЦС заслуживал доверие, он должен предлагать некоторые службы или информацию пользователям сертификатов для подтверждения своей идентичности. При этом также потребуется доказать, что пользователь или служба, удостоверяющие себя с помощью данного сертификата, являются именно теми, за кого себя выдают. Если подобное подтверждение отсутствует, клиент не может гарантировать подлинность происхождения сертификата, вследствие чего безопасность не гарантируется.
Сервер ЦС также обеспечивает статус аннулирования сертификата. Если полномочия сертификата отменяются, то ЦС должен проинформировать об этом пользователей данного сертификата. Благодаря этому, в результате отмены полномочий сертификата становится невозможным осуществление доступа с его помощью. Кроме того, ЦС должен указывать политики и практики, руководствуясь терминами, определяющими выпуск сертификатов, а также методику защиты ключей, поддержку аудита и выполнение подобных операций.
Как правило, отношения ЦС основываются на полных иерархиях и/или простых отношениях типа "родитель-потомок". Существует два типа иерархии: корневые иерархии и перекрестные иерархии сертификатов.
1.6.2.Корневые иерархии.Сервер ЦС может быть либо подчиненным, либо корневым, но никогда не выступает в обеих ипостасях одновременно. Корневая иерархия обладает одним очень важным свойством: корневой сервер ЦС может быть автономным. При проектировании среды сертификата важно учитывать систему безопасности с частным ключом ЦС, поскольку при атаке или дискредитации вся иерархия и цепь сертификатов становятся недействительны.
Корневая иерархия устанавливается обычно на трех уровнях.
-
Корень. Точка доверия иерархии с автоподписью. После определения структуры корневой сервер обычно переходит в автономный режим работы.
-
Сервер ЦС второго уровня. Этот сервер ЦС определяет организационные политики. Благодаря политикам ЦС, можно отделять корневой сервер, поскольку он может переходить в автономный режим. Также существует возможность выделения применимости сертификатов по признакам географии, политик или какому-либо другому признаку, устанавливаемому корпорацией для определенных политик. Например, можно установить серверы политик ЦС для Северной и Южной Америки, а затем отделить цепи, находящиеся под ними. Можно также установить иерархию с помощью приложения, что, в основном, относится к финансовым приложениям. В некоторых случаях серверы ЦС политик можно сделать автономными или интерактивными в зависимости от их применения; но опять же, это зависит от требований безопасности, выдвигаемых конкретной организацией.
• Серверы ЦС, выдающие сертификаты. Этот сервер ЦС отвечает за выдачу сертификатов конечным компонентам. Данный сервер должен функционировать в интерактивном режиме, поскольку ему необходимо обслуживать запросы сертификатов.
Другим преимуществом корневых иерархий является их способность к масштабированию, а также возможность изоляции одного определенного сервера ЦС. Другими словами, изменения, вносимые в определенный сервер ЦС или используемые им политики, не влияют на всех остальных пользователей.
1.6.3. Перекрестная иерархия сертификатов. В перекрестной иерархии сертификатов серверы ЦС могут быть как корневыми, так и подчиненными. Данная конфигурация не поддерживает автономные корневые каталоги, поскольку ЦС предполагается использовать в роли как корневого каталога, так и подчиненного элемента. Это зависит от инфраструктуры PKI, с помощью которой удостоверяется цепь. Перекрестная иерархия обычно используется для соединения отдельных PKI путем создания перекрестных сертификатов, не прибегая к отношениям явного доверия.
Благодаря использованию перекрестной сертификации, один сервер СА сертифицирует другой, и наоборот: сервер ЦС1 перекрестно сертифицирует сервер ЦС2, а сервер ЦС2 перекрестно сертифицирует сервер ЦС1. Это означает, что ЦС1 является одновременно и корневым в своей собственной иерархии, и подчиненным — в иерархии ЦС2. Проблему в структуре перекрестной сертификации представляет масштабируемость, поскольку структура должна управлять большим количеством отношений и доверительными транзитивными отношениями. Поэтому очень важно проконтролировать фактическое количество отношений (применяя перекрестную сертификацию). Перекрестная сертификация иногда используется в тех случаях, когда компания имеет множество структур сертификатов, которые непросто свести к одной структуре. Причина этого явления заключается в том, что серверы ЦС производятся различными поставщиками программного обеспечения. Также может играть роль метод развертывания сертификатов наравне с зависимостями приложений.
Еще одна проблема заключается в доступности перекрестных сертификатов, поскольку они не являются частью естественной цепи. Как правило, сертификаты не содержат информацию, указывающую на применение перекрестных сертификатов. Иерархии перекрестных сертификатов обычно зависят от каталога, не обязательно существующего на глобальном уровне в Internet или в корпоративной сети (если компании физически отделены друг от друга).