Файл: Основыинформационнойбезопасности.pdf

87
Таким образом, центры сертификации и пользователи форми- руют древовидную иерархическую структуру (рис. 2.21). В вершине этого дерева находится корневой центр сертификации, на рис. 2.21 —
CA_1. Его особенность заключается в том, что он использует само- подписанный сертификат, т. е. сам заверяет свой ключ.
В приведенном примере CA_1 заверяет электронной подписью сертификаты подчиненных центров сертификации CA_2 и CA_3, а те, в свою очередь, подписывают сертификаты пользователей и центров более низкого уровня.
Перейдем к рассмотрению самих сертификатов. Наибольшее распространение получили цифровые сертификаты, формат которых определен стандартом X.509. На данный момент принята третья вер- сия стандарта. Формат сертификата изображен на рис. 2.22 [11].
Номер версии содержит числовое значение, соответствующее номеру версии (для сертификата версии 1 равен 0 и т. д.). В первой версии X.509 не было уникальных номеров («ID Изготовителя», «ID
Субъекта») и полей расширения. Во второй версии добавились ука- занные идентификаторы, в третьей — расширения.
Серийный номер — уникальный номер, присваиваемый каждому сертификату.
Алгоритм подписи — идентификатор алгоритма, используемого при подписании сертификата. Должен совпадать с полем Алгоритм
ЭЦП.
Изготовитель — имя центра сертификации, выдавшего серти- фикат. Записывается в формате Relative Distinguished Name — RDN
(варианты перевода названия — «относительное отдельное имя», «от- носительное характерное имя»). Данный формат используется в службах каталога, в частности, в протоколе LDAP. При записи Rela- tive Distinguished Name используются специальные ключевые слова:
CN (англ. «Common Name») — общее имя; OU (англ. «Organization
Unit») — организационная единица; DC (англ. «Domain Component»)
— составная часть доменного имени.

88
Рис. 2.22. Сертификат формата X.509 v.3
Например, в сертификате Microsoft Windows Hardware Compati- bility, который находится в хранилище сертификатов Windows’XP значение данного поля следующее:
CN = Microsoft Root Authority,
OU = Microsoft Corporation,
Тело сертификата
Алгоритм ЭЦП

ЭЦП

Номер версии

Серийный номер

Алгоритм подписи

Изготовитель
Name>
Субъект
Name>
Период действия
Действителен с

Действителен по

Открытый ключ
Алгоритм
< Algorithm ID>
Ключ

ID Изготовителя

ID Субъекта

Расширение
Критичность

Значение

Идентификатор

89
OU = Copyright (c) 1997 Microsoft Corp.
Как видно, указывается имя центра сертификации, компания, которой он принадлежит и т. д.
Субъект — имя владельца сертификата, представленное в том же формате RDN. Для указанного в предыдущем примере сертифика- та значения данного поля:
CN = Microsoft Windows Hardware Compatibility,
OU = Microsoft Corporation,
OU = Microsoft Windows Hardware Compatibility Intermediate CA,
OU = Copyright (c) 1997 Microsoft Corp.
Период действия описывает временной интервал, в течение ко- торого центр сертификации гарантирует отслеживание статуса серти- фиката (сообщит абонентам сети о факте досрочного отзыва сертифи- ката и т. д.). Период задается датами начала и окончания действия.
Открытый ключ — составное поле, содержащее идентификатор алгоритма, для которого предназначается данный открытый ключ, и собственно сам открытый ключ в виде набора битов.
ID Изготовителя и ID Субъекта содержат уникальные иденти- фикаторы центра сертификации и пользователя (на случай совпаде- ния имен различных CA или пользователей).
Расширения — дополнительный атрибут, связанный с субъек- том, изготовителем или открытым ключом и предназначенный для управления процессами сертификации. Более подробно он описан ниже.
Алгоритм электронной цифровой подписи (ЭЦП) — идентифи- катор алгоритма, используемый для подписи сертификата. Должен совпадать со значением поля Алгоритм подписи.
ЭЦП — само значение электронно-цифровой подписи для дан- ного сертификата.
Расширения могут определять следующие дополнительные па- раметры:

90
- идентификатор пары открытый/секретный ключ центра серти- фикации (изготовителя), если центр имеет несколько различных клю- чей для подписи сертификатов;
- идентификатор конкретного ключа пользователя (субъекта), если пользователь имеет несколько сертификатов;
- назначение ключа, например, ключ для шифрования данных, проверки ЭЦП данных, для проверки ЭЦП сертификатов и т. д.;
- уточнение периода использования — можно сократить время действия сертификата, указанное в поле Период действия (период, в течение которого статус сертификата отслеживается, станет больше, чем разрешенное время использования сертификата);
- политики использования сертификата;
- выбор соответствия политик использования сертификата для центра сертификации и пользователя, если имеются различные вари- анты;
- альтернативное имя пользователя и центра сертификации;
- указания, является ли пользователь сам центром сертифика- ции, и насколько глубоко разрешается разворачивать сертификацион- ный путь.
Предположим, что ключевые пары сгенерированы, открытые ключи заверены сертификатами и размещены в каталоге, реализован- ном с помощью web-сервера, ftp-сервера, службы каталога или другой технологии. Теперь, если абонент A желает проверить подпись або- нента B под полученным сообщением (или зашифровать для B сооб- щение с помощью его открытого ключа), он выполняет следующие действия [8]:
1) запрашивает в сетевом справочнике сертификат C
B
открытого ключа подписи (шифрования) абонента B;
2) проверяет достоверность сертификата C
B
(см. ниже);
3) в случае успеха проверяет подпись под сообщением (зашиф- ровывает сообщение) с помощью открытого ключа, извлеченного из
C
B

91
Процедура проверки достоверности сертификата C
B
состоит в следующем:
1) проверяется срок действия сертификата C
B
, если он закончил- ся, сертификат считается недостоверным;
2) из C
B
извлекается имя ЦС, подписавшего этот сертификат, обозначим его D;
3) если D = B, то сертификат самоподписанный, он считается достоверным только, если D = ROOT (хотя, возможно, в некоторых сетях право выдавать самоподписанные сертификаты имеет не один
ROOT, это — политика сети);
4) если же D

B, то из справочника запрашивается сертификат
C
D
открытого ключа подписи абонента D, проверяется на достовер- ность сертификат C
D
;
5) в случае отрицательного ответа принимается решение о недо- стоверности сертификата C
B
, иначе из C
D
извлекается открытый ключ
K
D
;
6) с помощью K
D
проверяется подпись под сертификатом C
B
, по результатам проверки этой подписи судят о достоверности C
B
Если ключи шифрования досрочно вышли из обращения (при- чины могут быть различны — пользователь увольняется из компании, секретный ключ скомпрометирован и т. д.), центр сертификации из- вещает об этом остальных пользователей сети путем выпуска списка отозванных сертификатов (англ. «Certificate Revocation List», сокр.
CRL). Структура CRL представлена на рис. 2.23. Поля списка содер- жат следующую информацию.
Номер версии определяет номер версии формата CRL. Текущая используемая версия — вторая.
Алгоритм подписи — идентификатор алгоритма, с помощью ко- торого подписан CRL. Должен совпадать по значению с полем Алго-
ритм ЭЦП.
Изготовитель — имя центра сертификации в формате RDN.
Выпущен — дата выпуска CRL.

92
Следующий — дата, до которой будет выпущен следующий
CRL.
Расширения описывают центр сертификации, точку для поиска
CRL данного центра, номер данного списка и т. д.
Рис. 2.23. Структура списка отозванных сертификатов
Отозванный сертификат — таких полей будет столько, сколь- ко сертификатов отзывается — содержит номер отзываемого серти- фиката, дату, с которой сертификат отозван, описание причины отзы- ва.
Алгоритм ЭЦП — идентификатор алгоритма ЭЦП, используе- мого для подписи списка.
ЭЦП — сама электронная цифровая подпись.
Проблемы с CRL заключаются в том, что может возникнуть си- туация, когда ключ уже отозван, но CRL еще не выпущен, т. е. поль- зователи не могут получить информацию о компрометации ключа.
Отозванный сертификат
Сер. номер

Дата отзыва

Расширения
Тело списка
Версия

Подпись

Изготовитель

Выпущен

Следующий

Расширения
Алгоритм ЭЦП

ЭЦП

93
Кроме того, распространение CRL идет по запросу клиента, и нару- шитель может препятствовать их получению.
Другая проблема PKI — самоподписанные сертификаты. Сер- тификат корневого ЦС должен раздаваться всем абонентам сети в начале работы и сохраняться в защищенном от подделки хранилище.
Иначе нарушитель может попробовать навязать свой сертификат в качестве сертификата корневого центра.
Мы рассмотрели случай реализации иерархической модели PKI, при которой центры сертификации организованы в древовидную структуру с корневым центром сертификации на верху иерархии. На практике также встречаются другие варианты организации:
- одиночный центр сертификации, который выдает себе само- подписанный сертификат — данная модель часто реализуется в не- больших организациях, но она имеет отмеченный выше недостаток, связанный с самоподписанными сертификатами;
- одноранговая модель, при которой независимые центры серти- фикации взаимно сертифицируют друг друга.
Надо отметить, что сфера применения цифровых сертификатов сейчас достаточно широка. В частности, они используются для рас- пределения открытых ключей в протоколах защиты электронной по- чты S/MIME или PGP, с помощью цифровых сертификатов проверя- ется подлинность участников соединения по протоколу SSL и т. д.
1>

94 шую роль межсетевых экранов в решении задач обеспечения сетевой безопасности, будет рассмотрен этот класс средств защиты.
3.1. ПРОТОКОЛ ЗАЩИТЫ ЭЛЕКТРОННОЙ ПОЧТЫ S/MIME
Протокол Secure Multipurpose Internet Mail Extensions (S/MIME) предназначен для защиты данных, передаваемых в формате MIME, в основном — электронной почты. Он был предложен в 1995 году ком- панией RSA Data Security Inc. Дальнейшие работы над протоколом велись рабочей группой организации Internet Engineering Task Force
(IETF), разрабатывающей стандарты сети Интернет. На данный мо- мент последней является версия 3.1 этого протокола, описываемая в документах RFC 3850, 3851, 3852. Протокол S/MIME предоставляет следующие криптографические услуги безопасности (криптографиче- ские сервисы):
- проверка целостности сообщения;
- установление подлинности отправителя (аутентификация);
- обеспечение секретности передаваемых данных (шифрование).
Нужно отметить, что сам по себе формат MIME описывает по- рядок форматирования писем, содержащих различные типы данных
(обычный текст, текст в формате html, видео и графические файлы различный типов и т. д.). При использовании S/MIME добавляются новые типы (например, application/pkcs7-mime и application/pkcs7- signature). Это позволяет указать на то, что данные в этом разделе яв- ляются зашифрованными, подписанными и т. д. Протокол позволяет обычным почтовым клиентам защищать исходящую почту и интер- претировать криптографические сервисы, добавленные во входящую почту (расшифровывать сообщения, проверять их целостность и т. д.).
Стандарт определяет использование симметричных криптоалго- ритмов для шифрования содержимого почтовых сообщений и алго- ритма с открытым ключом для защиты передаваемого вместе с пись- мом ключа симметричного шифрования.
Протокол S/MIME позволяет использовать различные криптоал- горитмы, причем их список может расширяться. Изначально из сим-

95 метричных шифров могли использоваться RC2, DES или TripleDES.
Для формирования дайджестов — алгоритмы MD5 и SHA1, причем версия 3 стандарта рекомендует использовать именно последний ал- горитм (из-за того, что он формирует более длинный дайджест и счи- тается более надежным). Защита симметричного ключа шифрования и
ЭЦП в версии 2 осуществляется с помощью алгоритма RSA с ключом от 512 до 1024 бит. Версия 3 добавляет возможность использовать другие алгоритмы, например алгоритм Диффи–Хеллмана с ключом длиной до 2048 бит. Распределение и аутентификация открытых клю- чей производится с помощью цифровых сертификатов формата X.509.
Таким образом, чтобы защищать переписку с помощью этого прото- кола, оба абонента должны сгенерировать ключевые пары и удосто- верить открытые ключи с помощью сертификатов. На рис. 3.1 приве- ден фрагмент письма, содержащий открытый текст «This is a clear- signed message.» и подпись к нему.
S/MIME поддерживается многими почтовыми клиентами: Mi- crosoft Outlook, Mozilla, The Bat! и т. д. Более широкое применение протокола сдерживается необходимостью наличия сертификатов у абонентов и плохой совместимостью с системами Web-почты.
Рис. 3.1. Фрагмент электронного письма с подписью