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, было бы неплохо установить и сконфигурировать, по крайней мере, элементарную структуру сертификатов практически для любой компании.

Центр сертификации выпускает четыре типа сертификатов.

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

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

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

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

6. ИЕРАРХИЯ СЕРТИФИКАТОВ. Иерархия сертификатов — это структура, основанная на доверительных отношениях безопасности. Простая иерархия представляет собой корневой сервер ЦС с подчинен­ными серверами ЦС, которые выдают сертификаты клиентам. Поскольку иерархия основана на доверительных отношениях, то выданному сертификату доверяют на всех уровнях иерархического дерева. Можно создать множество типов отношений между серверами ЦС, начиная с многочисленных уровней подчиненных серверов ЦС и заканчивая одноранговыми серверами ЦС. Общий поток, установленный между ними, всегда будет иметь форму доверительных отношений.

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

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

Как правило, отношения ЦС основываются на полных иерархиях и/или простых отношениях типа "родитель-потомок". Существует два типа иерархии: корневые ие­рархии и перекрестные иерархии сертификатов.

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

Корневая иерархия устанавливается обычно на трех уровнях.

• Корень. Точка доверия иерархии с автоподписью. После определения структуры корневой сервер обычно переходит в автономный режим работы.

• Сервер ЦС второго уровня. Этот сервер ЦС определяет организационные политики. Благодаря политикам ЦС, можно отделять корневой сервер, поскольку он может переходить в автономный режим. Также существует возможность выделения применимости сертификатов по признакам географии, политик или какому-либо другому признаку, устанавливаемому корпорацией для определенных политик. Например, можно установить серверы политик ЦС для Северной и Южной Америки, а затем отделить цепи, находящиеся под ними. Можно также установить иерархию с помощью приложения, что, в основном, относится к финансовым приложениям. В некоторых случаях серверы ЦС политик можно сделать автономными или интерактивными в зависимости от их применения; но опять же, это зависит от требований безопасности, выдвигаемых конкретной организацией.

• Серверы ЦС, выдающие сертификаты. Этот сервер ЦС отвечает за выдачу сертифика­тов конечным компонентам. Данный сервер должен функционировать в интерак­тивном режиме, поскольку ему необходимо обслуживать запросы сертификатов.

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

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

Благодаря использованию перекрестной сертификации, один сервер СА сертифи­цирует другой, и наоборот: сервер ЦС1 перекрестно сертифицирует сервер ЦС2, а сервер ЦС2 перекрестно сертифицирует сервер ЦС1. Это означает, что ЦС1 является одновременно и корневым в своей собственной иерархии, и подчиненным — в иерар­хии ЦС2. Проблему в структуре перекрестной сертификации представляет масштабируемость, поскольку структура должна управлять большим количеством отношений и доверительными транзитивными отношениями. Поэтому очень важно проконтроли­ровать фактическое количество отношений (применяя перекрестную сертификацию). Перекрестная сертификация иногда используется в тех случаях, когда компания имеет множество структур сертификатов, которые непросто свести к одной структуре. При­чина этого явления заключается в том, что серверы ЦС производятся различными по­ставщиками программного обеспечения. Также может играть роль метод развертыва­ния сертификатов наравне с зависимостями приложений.

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