Стандарты в области PKI
Стандарты играют существенную роль в развертывании и использовании PKI. Стандартизация в этой сфере позволяет разным приложениям взаимодействовать между собой с использованием единой PKI . Стандарты в области PKI можно разбить на четыре группы, каждая из которых относится к определенному технологическому сегменту, необходимому для создания PKI.
К первой группе () можно отнести стандарты серии X, подготовленные Международным Союзом по телекоммуникациям - ITU (International Telecommunications Union), и стандарты Международной организации стандартизации - ISO (International Organization for Standardization), относящиеся к PKI . Они признаны в международном масштабе, содержат описания концепций, моделей и сервиса каталога (X.500) и формализуют процедуру аутентификации (X.509). Стандарт X.509 первоначально предназначался для спецификации аутентификации при использовании в составе сервисов каталога X.500. С течением времени X.509 претерпел ряд изменений, и его последняя (третья) версия была стандартизована группой инженерной поддержки Интернета - Internet Engineering Task Force (IETF). Документ X.509 регулирует хранение информации в каталоге и получение данных аутентификации. Он характеризует криптосистему с открытым ключом как метод сильной аутентификации, который базируется на создании, управлении и свободном доступе к сертификату, связывающему субъекта (пользователя) с его открытым ключом. Синтаксис сертификатов формата Х.509 выражается с помощью особой нотации, так называемой абстрактной синтаксической нотации версии 1 (Abstract Syntax Notation One - ASN.1), которая была предложена комитетом разработчиков стандартов взаимодействия открытых систем OSI (Open System Interconnection) для использования с протоколами X.500. ASN.1 описывает синтаксис различных структур данных, вводя примитивные объекты и средства описания их комбинаций . Форматы электронного сертификата и САС, предложенные X.509, фактически признаны стандартом и получили всеобщее распространение независимо от X.500. Как показало время, наиболее ценной в стандарте X.509 оказалась не сама процедура, а ее служебный элемент - структура сертификата, содержащая имя пользователя, криптографические ключи и сопутствующую информацию .
|Номер и название стандарта | Содержание стандарта |
|X.500 | Каталог: обзор концепций, моделей и услуг |
|X.509 | Каталог: структура аутентификации |
|X.509a | Проект изменений и дополнений для продления срока действия сертификатов (расширение версии 3) |
|X.208 (ISO/IEC 8825)
Abstract Syntax Notation (ASN.1)
| Абстрактная синтаксическая нотация |
|X.209 | Основные правила кодирования для ASN.1 |
|ISO/IEC 8824
Object Identifiers (OIDs)
| Идентификаторы объектов |
|ISO/IEC 9594/8
Directory Services (X.509)
| Сервисы каталога (X.509) |
Таблица 15.1.I группа стандартов
Стандарты второй группы () разработаны основным центром по выпуску согласованных стандартов в области PKI - рабочей группой организации IETF, известной как группа PKIX (от сокращения PKI for X.509 certificates) . Документы PKIX определяют политику применения сертификатов и структуру регламента УЦ, форматы, алгоритмы и идентификаторы сертификата и САС X.509, схему поддержки PKIX в среде LDAP v2, форматы атрибутных сертификатов и сертификатов ограниченного пользования, описывают протоколы статуса сертификатов, запроса на сертификацию, проставления метки времени, эксплуатационные протоколы PKI.
Третью группу образуют стандарты криптографии с открытыми ключами PKCS (Public Key Cryptography Standards), разработанные компанией RSA Security Inc. совместно с неофициальным консорциумом, в состав которого входили компании Apple, Microsoft, DEC, Lotus, Sun и MIT. Документы PKCS признаны симпозиумом разработчиков стандартов взаимодействия открытых систем методом реализации стандартов OSI (Open System Interconnection). Стандарты PKCS () обеспечивают поддержку криптографических процессов при выполнении защищенного шифрованием информационного обмена между субъектами. Стандарты PKCS ориентированы на двоичные и ASCII-данные и совместимы со стандартом ITU-T X.509. В PKCS входят алгоритмически зависимые и независимые реализации стандартов . Многие из них опираются на систему шифрования с открытыми ключами RSA, названную по инициалам авторов Ривеста, Шамира и Адльмана, метод эллиптических кривых и метод согласования ключей Диффи-Хэллмана, подробно описанные в трех соответствующих криптографических стандартах.
|Номер и название стандарта | Содержание стандарта |
|
RFC 2510
Certificate Management Protocols (CMP)
| Инфраструктура открытых ключей Интернет X.509: протоколы управления сертификатами |
|
RFC 2511
Certificate Request Protocol
| Протокол запроса на сертификат |
|
RFC 2527
Certificate Policy and Certification
Practices Framework
| Политика применения сертификатов и структура регламента |
|
RFC 2559
LDAP V2 Operational Protocols
| Эксплуатационные протоколы инфраструктуры открытых ключей |
|
RFC 2560
Online Certificate Status Protocol (OCSP)
| Онлайновый протокол статуса сертификата |
|
RFC 2585
HTTP/FTP Operations
| Применение протоколов HTTP/FTP для получения сертификатов и САС и репозитория PKI |
|
RFC 2587
LDAP V2 Schema
| Схема поддержки PKIX в среде LDAP v2 |
|
RFC 2797
Certificate Management Messages over
CMS (CMC)
| Протокол управления сертификатами на базе сообщений управления сертификатами |
|
RFC 2875
Diffie-Hellman Proof-of-Possession
(POP) Algorithms
| Алгоритмы Диффи-Хэлмана доказывания владения |
|
RFC 3029
Data Validation and Certification
Server Protocols
| Протоколы сервера сертификации и проверки достоверности данных |
|
RFC 3039
Qualified Certificates Profile
| Формат сертификата ограниченного пользования |
|
RFC 3161
Time-Stamp Protocol (TSP)
| Протокол меток времени |
|
RFC 3279 (бывший RFC 2528)
Algorithms and Identifiers for the
Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List (CRL) Profile
| Алгоритмы и идентификаторы для профилей сертификатов и САС PKIX |
|
RFC 3280 (бывший RFC 2459)
Certificate & CRL Profile
| Форматы сертификата и списка аннулированных сертификатов X.509 |
|
RFC 3281
An Internet Attribute Certificate
Profile for Authorization
| Формат атрибутного сертификата для авторизации |
Таблица 15.2.II группа стандартов
|Номер и название стандарта | Содержание стандарта |
|
PKCS#1
RSA Cryptography
| Механизмы шифрования и подписания данных методом RSA.
Примечание:Стандарты PKCS #2 and PKCS #4 были объединены в PKCS #1
|
|
PKCS #3
Diffie-Hellman Key Agreement
| Согласование ключей методом Диффи-Хеллмана |
|
PKCS #5
Password-Based Cryptography
| Шифрование секретным ключом, созданным на основе пароля |
|
PKCS #6
Extended-Certificate Syntax
| Синтаксис расширенного сертификата |
|
PKCS#7
Cryptographic Message Syntax
| Синтаксис криптографических сообщений |
|
PKCS #8
Private-Key Information Syntax
| Синтаксис данных секретного ключа |
|
PKCS #9
Selected Attribute Types
| Особые типы атрибутов для использования в других PKCS-стандартах |
|
PKCS#10 (RFC2314)
Certification Request Syntax
| Стандарт синтаксиса запроса на сертификацию |
|
PKCS#11
Cryptographic Token Interface (Cryptoki)
| Прикладной программный интерфейс Cryptoki для криптографических устройств типа смарт-карт и карт PCMCIA |
|
PKCS #12
Personal Information Exchange Syntax
| Синтаксис обмена персональными данными пользователя (секретными ключами, различными тайнами и т.п.) |
|
PKCS #13
Elliptic Curve Cryptography
| Механизмы шифрования и подписания данных методом эллиптических кривых |
|
PKCS #15
Cryptographic Token Information Format
| Формат данных, хранящихся на криптографических токенах (является дополнением к PKCS #11) |
Таблица 15.3.III группа стандартов
Кроме того, стандарты PKCS определяют алгоритмически независимый синтаксис криптографических сообщений, данных секретного ключа, запросов на сертификацию, расширенных сертификатов, обмена персональными данными пользователя, что позволяет реализовать любой криптографический алгоритм в соответствии со стандартным синтаксисом и обеспечить взаимодействие самых разных приложений. Большинство стандартов, использующих криптографию, разработано с учетом применения PKI.
В четвертую группу объединены дополнительные связанные с PKI стандарты LDAP, S/MIME, S/HTTP, TLS, IPsec, DNS и SET (). Стандарты LDAP описывают упрощенный протокол доступа, позволяющий вводить, удалять, изменять и извлекать информацию, которая содержится в каталогах X.500. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет важную роль во множестве продуктов, таких как системы аутентификации, PKI, приложения электронной почты и электронной коммерции.
Стандарты S/MIME (Secure/Multipurpose Internet Mail Extensions) предназначены для обеспечения защищенного обмена сообщениями в Интернете. Протокол защищенной электронной почты S/MIME базируется на технологии шифрования и цифровой подписи, разработанной компанией RSA Security Inc., и используется для предупреждения возможного перехвата или подделки почтовых сообщений . Семейство стандартов S/MIME описывает синтаксис криптографических сообщений, управление сертификатами в среде S/MIME, процедуры и атрибуты дополнительных сервисов безопасности для почтовых приложений, к которым относятся заверенные цифровой подписью уведомления о приеме сообщений, метки безопасности и защищенные списки рассылки электронной почты.
К стандартам S/HTTP и TLS относятся документы, определяющие защищенный протокол передачи гипертекста HTTP и его расширения, протокол безопасности транспортного уровня TLS, его модификацию и использование в среде HTTP. TLS - открытый стандарт, разработанный на базе протокола защищенного обмена информацией между клиентом и сервером SSL (Secure Sockets Layer) в качестве его замены для защиты коммуникаций в Интернете. Протокол TLS обеспечивает конфиденциальность и целостность данных при коммуникации двух приложений и позволяет приложениям "клиент-сервер" взаимодействовать защищенным способом, предотвращающим перехват информации и подделку сообщений. Для взаимной аутентификации перед началом информационного взаимодействия приложениями используется технология PKI.
|Номер и название стандарта | Содержание стандарта |
|LDAP |
RFC 1777: Lightweight Directory Access
Protocol
| Упрощенный протокол доступа к каталогу |
|
RFC 1823: The LDAP Application Program
Interface
| Интерфейс прикладного программирования протокола LDAP |
|
RFC 2251: Lightweight Directory Access
Protocol (v3)
| Упрощенный протокол доступа к каталогу (версия 3) |
|
RFC 2252: Lightweight Directory Access
Protocol (v3): Attribute definition
| Описание атрибутов протокола LDAP (версия 3) |
|
RFC 2253: Lightweight Directory Access
LDAP
Protocol (v3): UTF-8 String
Representation of Distinguished Names
| Представление отличительных имен в протоколе LDAP (версия 3) |
|
RFC 2254: Lightweight Directory Access
Protocol (v3) The String
Representation of LDAP Search Filters
| Строковое представление фильтров поиска в протоколе LDAP (версия 3) |
|
RFC 2255: Lightweight Directory Access
Protocol (v3) The LDAP URL Format
| URL-формат протокола LDAP (версия 3) |
|S/MIME |
RFC 2311
S/MIME Version 2 Message Specification
| Спецификация сообщений S/MIME версии 2 |
|
RFC 2312
S/MIMEv2 Certificate Handling
| Управление сертификатами S/MIME версии 2 |
|
RFC 2630
Cryptographic Message Syntax (CMS)
| Синтаксис криптографических сообщений |
|
RFC 2632
S/MIME V3 Certificate Handling
| Управление сертификатами S/MIME версии 3 |
|
RFC 2633
S/MIME V3 Message Specification
| Спецификация сообщений S/MIME версии 3 |
|
S/MIMERFC 2634
Enhanced Security Services for S/MIME
| Сервисы безопасности для S/MIME |
|
RFC 2785
Methods for Avoiding the "Small-
Subgroup" Attacks on the Diffie-Hellman
Key Agreement Method for S/MIME
| Методы отражения атак на основе метода согласования ключей Диффи-Хэллмана для S/MIME |
|
RFC 3369 S/MIME Cryptographic Message
Syntax
| Синтаксис криптографических сообщений в S/MIME |
|S/HTTP TLS |
RFC 2246
TLS Protocol Version 1.0
| Протокол безопасности транспортного уровня TLS версии 1 |
|
RFC 2659
Security Extensions For HTML
| Расширения безопасности для протокола передачи гипертекста HTTP |
|
RFC 2660
S/HTTP TLS
The Secure HyperText Transfer Protocol
| Защищенный протокол HTTP |
|
RFC 2817
Upgrading to TLS Within HTTP
| Модификация протокола TLS в среде HTTP |
|
RFC 2818
HTTP Over TLS
| Использование протокола TLS для защищенных HTTP-соединений через Интернет |
|IPsec |
RFC 2401
Security Architecture for the Internet
Protocol
| Архитектура безопасности Интернет-протокола |
|
RFC 2402
IP Authentication Header
| Протокол аутентифицирующего заголовка |
|
IPsecRFC 2406
IP Encapsulating Security Payload (ESP)
| Протокол инкапсулирующей защиты содержимого IP-пакетов |
|
RFC 2408
Internet Security Association and Key
Management Protocol (ISAKMP)
| Интернет-протокол управления ключами и контекстами безопасности |
|DNS |
RFC 2137
Secure Domain Name System Dynamic Update
| Динамическое обновление защищенной системы доменных имен |
|
RFC 2535
Domain Name System Security Extensions
| Расширения системы доменных имен |
|
RFC 2536
DSA KEYs and SIGs in the Domain Name
System
| DSA-ключи и подписи в системе доменных имен |
|
RFC 2537
RSA/MD5 KEYs and SIGs in the Domain
Name System
| RSA/MD5-ключи и подписи в системе доменных имен |
|
DNSRFC 2538
Storing Certificates in the Domain
Name System
| Хранение сертификатов в системе доменных имен |
|
RFC 2539
Storage of Diffie-Hellman Keys in the
Domain Name System
| Хранение ключей Диффи-Хэллмана в системе доменных имен |
|
RFC 2540
Detached Domain Name System Information
| Отделенная информация системы доменных имен |
|
RFC 2541
DNS Security Operational Considerations
| Операционные требования безопасности службы доменных имен |
|SET |
Secure Electronic Transaction
Specification The Business Description
| Защищенные электронные транзакции. Спецификация: Описание бизнеса |
|
Secure Electronic Transaction
The Specification Programmer's Guide
SET
| Защищенные электронные транзакции. Спецификация: Руководство программиста |
|
Secure Electronic Transaction
Specification Formal Protocol Definition
| Защищенные электронные транзакции. Спецификация: Описание формального протокола |
Таблица 15.4.IV группа стандартов
Рис. 15.1. Взаимосвязь стандартов в области PKI
Стандарты семейства IPsec описывают архитектуру безопасности Интернет-протоколов (IP), регламентируют контроль целостности на уровне IP-пакетов, аутентификацию источника данных и защиту от воспроизведения ранее посланных IP-пакетов, обеспечение конфиденциальности при помощи шифрования содержимого IP-пакетов, а также частичную защиту от анализа трафика путем применения туннельного режима . Документы RFC, относящиеся к IPsec, содержат описания протокола аутентифицирующего заголовка, протокола инкапсулирующей защиты содержимого IP-пакетов и протокола управления ключами и контекстами безопасности. Стандарты IPsec обеспечивают конфиденциальность, целостность и достоверность данных, передаваемых через открытые IP-сети.
Стандарты DNS определяют механизмы, обеспечивающие безопасность данных инфраструктуры системы доменных имен DNS. Документы описывают операционные требования безопасности системы, методы хранения сертификатов и ключей Диффи-Хэллмана, динамическое обновление защищенной системы DNS, механизм защиты передаваемых данных с помощью алгоритма MD5, DSA и RSA-ключей и цифровых подписей. Для обеспечения достоверной передачи DNS-данных в масштабе Интернета в систему DNS вводятся расширения DNSSEC, задаваемые соответствующим стандартом.
Спецификация SET предлагает инфраструктуру для защиты от подделок платежных карт, используемых для транзакций электронной коммерции в Интернете, описывает систему аутентификации участников расчетов, которая базируется на PKI . Принципы SET излагаются в трех книгах, содержащих сведения о правилах ведения бизнеса на базе защищенных электронных транзакций, руководство программиста и формальное описание протокола SET. иллюстрирует взаимосвязь стандартов в области PKI .
Итак, базой для разработки стандартов в области PKI стали стандарты серии X.500 (хотя не все их наименования начинаются с X.5xx) Международного союза электросвязи (ITU), предложившие стандартную структуру баз данных, записи в которых содержали информацию о пользователях . Стандарт X.509 ITU-T является фундаментальным стандартом, который лежит в основе всех остальных, используемых в PKI. Однако X.509 ITU-T не описывает полностью технологию PKI. В целях применения стандартов X.509 в повседневной практике комитеты по стандартизации, пользователи, поставщики программных продуктов и сервисов PKI обращаются к семейству стандартов PKIX.
Стандарты Internet X.509 PKI (PKIX)
Терминология и концепции PKIX
Стандарты PKIX для описания инфраструктур используют сходные понятия " инфраструктура открытых ключей PKI " и " инфраструктура управления привилегиями PMI " (Privilege Management Infrastructure). Главное отличие между ними заключается в том, что PKI управляет сертификатами открытых ключей, а PMI - атрибутными сертификатами. Сертификат открытого ключа можно сравнить с паспортом субъекта, а атрибутный сертификат - с визой, первый обеспечивает идентификацию личности, а второй дает определенное разрешение. Основные термины и аббревиатуры, используемые в стандартах PKIX, а также их аналоги на русском языке приведены в .
Системы, использующие сертификаты, и PKI
Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.
Цель PKI состоит в обеспечении надежного и эффективного управления ключами и сертификатами открытых ключей. Пользователи систем, основанных на PKI, должны быть уверены, что в любой момент времени при коммуникации с определенным субъектом они полагаются на открытый ключ, связанный с секретным ключом, владельцем которого является именно этот субъект. Эта уверенность возникает в результате использования сертификатов открытых ключей, связывающих значения открытых ключей с их владельцами. Связывание происходит в результате проверки доверенным УЦ идентичности субъекта и заверения цифровой подписью каждого сертификата открытого ключа.
|Термин на английском языке | Аббревиатура | Термин на русском языке |
|Attribute Authority | AA | Атрибутный центр |
|Attribute Certificate | AC | Атрибутный сертификат |
|Certificate | | Сертификат |
|Certification Authority | CA | Удостоверяющий центр (УЦ) |
|Certificate Policy | CP | Политика применения сертификатов (ППС) |
|Certification Practice Statement | CPS | Регламент УЦ |
|End-Entity | EE | Конечный субъект |
|Public Key Certificate | PKC | Сертификат открытого ключа |
|Public Key Infrastructure | PKI | Инфраструктура открытых ключей |
|Privilege Management Infrastructure | PMI | Инфраструктура управления привилегиями |
|Registration Authority | RA | Регистрационный центр (РЦ) |
|Relying Party | | Доверяющая сторона |
|Root CA | | Корневой УЦ |
|Subordinate CA | | Подчиненный УЦ |
|Subject | | Субъект |
|Top CA | | УЦ верхнего уровня |
Таблица 15.5.Термины PKIX
Согласно стандартам PKIX, PKI представляет собой комплекс программного и аппаратного обеспечения, персонала, а также политик и процедур, необходимых для создания, управления, хранения, распространения и аннулирования сертификатов открытых ключей. Компоненты PKI представлены в . Сертификат открытого ключа имеет ограниченный период действия, который зафиксирован в содержании сертификата. Поскольку клиент должен иметь возможность самостоятельно проверить подпись сертификата открытого ключа и его срок действия, сертификаты должны открыто публиковаться и распространяться посредством даже ненадежных коммуникаций и систем серверов.
|Компонент | Описание |
|Удостоверяющие центры (УЦ) | Выпускают и аннулируют сертификаты |
|Регистрационные центры (РЦ) | Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов |
|Владельцы сертификатов | Подписывают и шифруют электронные документы |
|Клиенты | Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ |
|Репозитории | Хранят и предоставляют информацию о сертификатах и списках САС |
Таблица 15.6.Компоненты PKI
Сертификаты открытых ключей используются в процессе валидации (подтверждения) заверенных цифровой подписью данных, когда получатель проверяет, чтобы:
1 информация, идентифицирующая отправителя, соответствовала данным, содержащимся в сертификате;
2 ни один сертификат из цепочки сертификатов не был аннулирован, и в момент подписания сообщения все сертификаты были действительными;
3 сертификат использовался отправителем по назначению;
4 данные не были изменены с момента создания ЭЦП.
После валидации получатель может принять данные, подписанные отправителем.
Общая схема функционирования PKI представлена на . Конечный субъект отправляет запрос на сертификат в РЦ (транзакция управления). Если запрос фактически одобрен, то направляется непосредственно в УЦ для заверения цифровой подписью. УЦ проверяет запрос на сертификат, и если тот проходит верификацию, то подписывается и выпускается сертификат. Сертификат публикуется в репозитории; в зависимости от конкретной конфигурации PKI, эта функция может быть возложена на регистрационный или удостоверяющий центр.
На показаны все возможные коммуникации между конечным субъектом и УЦ. Процесс аннулирования сертификата аналогичен процессу его генерации. Конечный субъект запрашивает УЦ об аннулировании своего сертификата, РЦ принимает решение и направляет запрос об аннулировании в УЦ. УЦ вносит изменения в список аннулированных сертификатов и публикует его в репозитории. Конечные субъекты могут проверить статус конкретного сертификата через операционный протокол.
Рис. 15.2. Схема функционирования PKI
Операционные протоколы - это протоколы для доставки сертификатов (или информации об их статусе) и списков аннулированных сертификатов к клиентским системам, использующим сертификаты. Существуют разнообразные механизмы распространения сертификатов и САС с использованием протоколов LDAP, HTTP и FTP. Например, поиск САС для проверки статуса сертификата осуществляет операционный протокол.
Протоколы управления необходимы для поддержки взаимодействий в онлайновом режиме между пользователем PKI и субъектами управления.
Протоколы управления поддерживают:
1 регистрацию субъекта для получения сертификата;
2 инициализацию (например, генерации пары ключей);
3 выпуск сертификата;
4 восстановление пары ключей;
5 обновление пары ключей по истечении срока действия сертификата;
6 обращение с запросом об аннулировании сертификата;
7 кросс-сертификацию, когда два удостоверяющих центра обмениваются информацией для генерации кросс-сертификата.
Политика применения сертификатов и регламент УЦ содержатся в документах, описывающих обязательства сторон и правила использования сертификатов.
Системы, использующие сертификаты, и PMI
Многие системы используют сертификаты открытых ключей для принятия решений по управлению доступом, основанному на идентификации. Такие решения принимаются только после того, как пользователь докажет, что имеет доступ к секретному ключу, который соответствует открытому ключу, содержащемуся в сертификате.
Для некоторых систем этого бывает достаточно, тем не менее часто появляется потребность управлять доступом на основе определенных принципов, ролей или должностей. Тогда для принятия решений по управлению доступом требуется дополнительная информация, которая обычно не включается в сертификат, так как период жизни подобной информации бывает намного меньше срока действия пары ключей. Атрибутный сертификат (АС) используется для связывания такой информации с сертификатом.
Формат атрибутного сертификата позволяет связать любую дополнительную информацию о владельце с сертификатом открытого ключа, включая в структуру данных, заверенных цифровой подписью, ссылку на один или несколько сертификатов открытых ключей одного и того же субъекта. Атрибутный сертификат может иметь несколько назначений (например, предназначаться для доступа к web-серверу и хосту электронной почты).
Согласно стандартам PKIX, PMI представляет собой комплекс программного и аппаратного обеспечения, кадров, а также политик и процедур, необходимых для создания, управления, хранения и аннулирования атрибутных сертификатов. Компоненты PMI представлены в .
|Компонент | Описание |
|Атрибутные центры (АЦ) | Издатели атрибутных сертификатов. Выпускают и аннулируют атрибутные сертификаты |
|Пользователи атрибутных сертификатов | Анализируют или обрабатывают атрибутные сертификаты (АС) |
|Верификаторы атрибутных сертификатов | Подписывают и шифруют электронные документы |
|Клиенты | Запрашивают действие, для которого должна быть сделана проверка авторизации |
|Репозиторий | Хранит и предоставляет информацию о сертификатах и САС |
Таблица 15.7.Компоненты PKI
Направления стандартизации
Группа PKIX IETF разрабатывает документы для следующих направлений стандартизации:
1 профили сертификатов и списков аннулированных сертификатов;
2 протоколы управления ;
3 операционные протоколы ;
4 политики применения сертификатов и регламенты;
5 сервисы проставления меток времени и сертификации/валидации данных.
К первому направлению относятся стандарты RFC 3280 , RFC 3281 , RFC 3039 и RFC 3279 . Стандарт RFC 3280 (бывший RFC 2459) Certificate & CRL Profile предлагает форматы сертификатов версии X.509 v3 и списка аннулированных сертификатов версии X.509 v2 для использования в Интернете, детализирует информацию, относящуюся к формам имен и стандартным дополнениям. Документ описывает алгоритм проверки цепочек сертификатов и форматы открытых ключей и электронной цифровой подписи для алгоритмов шифрования ключей RSA, DSA и Диффи-Хэллмана.
Стандарт RFC 3281An Internet Attribute Certificate Profile for Authorization определяет профиль атрибутного сертификата для использования в Интернет-протоколах. Атрибутный сертификат подобен сертификату открытого ключа, но в отличие от него содержит не открытый ключ, а атрибуты, характеризующие его владельца: принадлежность к какой-либо группе, роль, полномочия, уровень прозрачности информации о владельце и т.п. Стандарт обеспечивает поддержку атрибутных сертификатов для электронной почты в Интернете, протокола IPsec, приложений безопасности World Wide Web.
Стандарт RFC 3039 Qualified Certificates Profile описывает формат сертификата ограниченного использования. Владельцем этого сертификата может быть только физическое лицо. Термин "ограниченное использование" трактуется в общепринятом для государственного права смысле. Пока стандарт определяет основной синтаксис сертификата ограниченного использования без учета особенностей законодательства разных стран.
Стандарт RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile определяет идентификаторы алгоритмов и форматы шифрования используемых в PKIX открытых ключей и цифровых подписей, односторонние хэш-функции для генерации ЭЦП сертификатов и САС. Стандарт описывает шифрование цифровых подписей, сгенерированных при помощи криптографических алгоритмов RSA, DSA и алгоритма эллиптических кривых (ECDSA), задает форматы шифрования открытых ключей, используемых в криптографических алгоритмах RSA, DSA, Диффи-Хеллмана и алгоритма шифрования ключей (KEA).
Второе направление представлено документами RFC 2510 , RFC 2511 , RFC 2560 и RFC 2797 . Стандарты RFC 2510 Certificate Management Protocols (CMP) и RFC2511 Certificate Request Protocol определяют соответственно сообщения протоколов для процессов создания и управления сертификатами и синтаксис запроса на выпуск сертификата формата X.509.
Стандарт RFC 2560 Online Certificate Status Protocol (OCSP) предлагает онлайновый протокол для определения статуса сертификата без использования САС. По замыслу разработчиков, этот протокол должен удовлетворять операционным требованиям более своевременного поступления информации об аннулировании, чем это возможно при помощи САС. Протокол управляет обменом данными между OCSP-клиентами, проверяющими статус сертификата, и OCSP-исполнителем, информирующим об этом статусе.
Стандарт RFC 2797 Certificate Management Messages over CMS определяет протокол управления сертификатами на основе сообщений управления сертификатами. Документ разрабатывался для решения двух важных проблем сообщества PKI в Интернете:
1 реализации интерфейса с продуктами и сервисами PKI, базирующимися на сообщениях управления сертификатами и стандарте синтаксиса запроса на сертификат - PKCS#10;
2 использования стандарта SMIME v3 в протоколе регистрации сертификатов открытых ключей (Диффи-Хеллмана), подписанных при помощи алгоритма DSA.
К третьему направлению можно отнести документы RFC 2559 , RFC 2587 и RFC 2585 .
Стандарт RFC 2559 LDAP V2 Operational Protocols закрепляет использование протокола LDAP v2 для обеспечения доступа к репозиторию с целью поиска сертификатов и другой релевантной PKI информации и управления ими.
Стандарт RFC 2587 LDAP V2 Schema описывает минимально необходимую схему поддержки PKIX в среде LDAP v2 (как этого требует документ RFC 2559) и определяет только специфические PKIX-компоненты. В соответствии с этим документом серверы LDAP, действующие как хранилища (репозитории) PKIX, должны поддерживать вспомогательные классы объектов, определенные данным стандартом, и интегрировать эту схему с общими и специфическими для приложений схемами в зависимости от сервисов, предоставляемых сервером.
Документ RFC 2585 HTTP/FTP Operations описывает применение протоколов HTTP/FTP для получения сертификатов и списков аннулированных сертификатов из репозитория УЦ.
Четвертое направление представлено одним базовым стандартом RFC 2527 Certificate Policy and Certification Practices Framework , определяющим политику применения сертификатов и структуру регламента УЦ и подробно описанным в .
К пятому направлению стандартизации относятся документы RFC 3029 , RFC 2875 , RFC 3161 . Стандарт RFC 3029 Data Validation and Certification Server Protocols вводит понятие сервера сертификации и проверки достоверности данных для обеспечения надежности сервисов неотказуемости и предлагает протоколы для взаимодействия с этим сервером. На сервер возлагаются функции доверенной третьей стороны, проверяющей подлинность сертификатов открытых ключей и документов с цифровой подписью.
Стандарт RFC 2875 Diffie-Hellman Proof-of-Possession (POP) Algorithms описывает два метода получения значения проверки целостности на основе пары ключей Диффи-Хэллмана. В документе предлагаются два алгоритма доказывания владения, использующие процесс согласования ключей Диффи-Хеллмана для получения разделенного секрета на основе значения проверки целостности. В первом алгоритме значение формируется для конкретного получателя/верификатора при помощи открытого ключа этого верификатора. Во втором алгоритме значение формируется для произвольного верификатора. Документ RFC 3161 Time-Stamp Protocol (TSP) описывает протокол проставления метки времени.
Роль стандартов, профилей и тестирования функциональной совместимости
Несмотря на то, что стандарты являются средством обеспечения функциональной совместимости PKI-продуктов разных поставщиков, следование стандартам является необходимым, но не достаточным условием гарантий полной совместимости. Поставщики программных продуктов занимаются самым сложным видом деятельности в PKI-бизнесе. Они вынуждены разрабатывать и продвигать на рынок программные продукты в условиях быстрого и непрерывного изменения стандартов. Комплексные PKI-продукты должны реализовывать все релевантные стандарты, не жертвуя гибкостью при избирательной реализации некоторого подмножества стандартов. Это делает PKI-продукт одним из самых сложных программных продуктов. Варианты конфигурирования PKI-систем могут также привести к несовместимости отдельных реализаций.
В мире существует большое количество организаций, занимающихся разработкой стандартов в сфере информационных технологий, появляются все новые и новые стандарты. Цель любого стандарта - обеспечить общее описание (спецификацию) его синтаксиса и семантики, которые могут быть использованы как основа для реализации стандарта. Однако иногда некоторые семантические правила отсутствуют или не полностью определены, что приводит к неоднозначному толкованию стандартов и проблемам функциональной совместимости продуктов, разработанных на базе таких стандартов. На качество стандартов влияют не только детальность их проработки и отсутствие ошибок, но и ряд других обстоятельств:
1 поскольку работа в органах стандартизации обычно ведется на добровольной основе, не существует профессионалов, специализирующихся исключительно на разработке стандартов;
2 часто в стандартах делается попытка объединить несколько точек зрения разных специалистов, и компромисс достигается либо за счет спецификации опций, либо за счет рассмотрения ряда вопросов на обобщенном уровне;
3 иногда существует очень небольшой или противоречивый опыт реализации в сфере приложения стандарта, поэтому он не может быть должным образом учтен в стандарте;
4 не все подразделения органов стандартизации способны разрабатывать документы равного качества, важную роль играет состав и правила участия специалистов, утвержденные главным государственным органом стандартизации;
5 очень редко предлагаемое решение является оптимальным для разных сред, поэтому сохраняется тенденция продвижения спецификации множества решений, удовлетворяющих потребностям множества целевых доменов;
6 иногда некоторые положения стандартов неправильно интерпретируются и/или даже стандарт неправильно реализуется;
7 наиболее сложные проблемы совместимости порождает общепринятая практика включения в стандарты механизмов расширения их возможностей, с тем чтобы стандарты сохраняли адекватность при изменении обстоятельств и возникновении новых потребностей реальной жизни.
Перечисленные проблемы свидетельствуют о том, что, помимо разработки стандартов, требуются дополнительные меры для обеспечения функциональной совместимости продуктов разных поставщиков. К этим мерам можно отнести создание профилей стандартов, учитывающих специфику разных сред, а также утверждение сценариев тестирования функциональной совместимости.
Профиль стандарта описывает, какие из свойств, перечисленных в общей спецификации стандарта, являются обязательными, опциональными или разрешенными в данной среде. Кроме того, профиль стандарта обычно содержит специфические правила использования и принципы реализации стандарта. В контексте PKI необходимо создавать профили используемых протоколов инфраструктуры, схем и протоколов, связанных со вспомогательными компонентами репозитория, а также самих сертификатов и списков САС. В частности, профили сертификатов и списков САС должны задавать специфическое для данной среды назначение каждого используемого в них дополнения.
Для утверждения сценариев и проведения тестирования функциональной совместимости необходима организация независимых от поставщиков центров тестирования, которые могли бы оказывать помощь в оценке соответствия данного PKI-продукта на основе утвержденных профилей определенному набору критериев. На практике в индустрии PKI в международных и национальных инициативах по обеспечению функциональной совместимости участвуют именно поставщики PKI-продуктов.
Инициативы по обеспечению функциональной совместимости PKI-продуктов
Национальные инициативы
К числу наиболее известных национальных инициатив по обеспечению функциональной совместимости можно отнести инициативы США: Automotive Network eXchange, Bridge CA Demonstration, проект федеральной PKI, инициативу разработки спецификации минимальной функциональной совместимости MISPC, а также проект национальной ассоциации автоматизированных клиринговых палат США .
Automotive Network eXchange
В рамках инициативы Automotive Network eXchange (ANX) на основе технологии виртуальных частных сетей была спроектирована общая сеть компаний-производителей автомобилей для обеспечения защищенных коммуникаций между ними. В ходе реализации проекта был разработаны профили сертификатов и списков САС, которые включены как приложение в документ, названный политикой применения сертификатов ANX .
Bridge CA Demonstration
По инициативе правительства США в 1999-2001 гг. был реализован проект демонстрации мостового УЦ - Bridge CA Demonstration с целью показать возможности функциональной совместимости двух (или более) доменов PKI, основанных на разных моделях доверия. В ходе выполнения проекта была сделана попытка доказать, что один УЦ способен действовать как мост между несколькими доменами PKI. Деятельность по разработке профилей включала создание минимального профиля сертификата и САС, схемы каталога и профиля функциональной совместимости, были также утверждены процессы построения и валидации путей сертификации .
Федеральная PKI
В октябре 1994 г. федеральное правительство США создало техническую рабочую группу по PKI (PKI-TWG) для решения проблем реализации федеральной инфраструктуры открытых ключей (FPKI). Рабочая группа действовала под руководством национального института по стандартам и технологии США - National Institute of Standards and Technology (NIST) и состояла из представителей федеральных агентств. Она разработала профиль дополнений сертификата и САС федеральной инфраструктуры, названный Federal Public Key Infrastructure Certificate and CRL Extensions Profile .
Спецификация минимальной функциональной совместимости
В 1996 г. институт NIST совместно с рядом поставщиков продуктов, лидирующих на рынке PKI - AT&T, IREBBN, Motorola Certicom, Nortel (Entrust), Cylink, Spyrus, DynCorp и VeriSign, - выступил с инициативой разработки спецификации минимальной функциональной совместимости. Первая версия спецификации "Minimum Interoperability Specification for PKI components, Version 1" была опубликована в июне 1997 г. и содержала ссылку на реализацию, пригодную для тестирования соответствия компонентов PKI профилю минимальной функциональной совместимости. Этот документ позволил сообществу поставщиков демонстрировать соответствие их PKI-продуктов требованиям профиля.
Работа над спецификацией продолжалась, и в августе 2001 г. была опубликована вторая версия документа, названная "Minimum Interoperability Specification for PKI components, Version 2 - Second Draft" . Она объединяет некоторые работы группы IETF PKIX, опубликованные в 1998-2001 гг. (в частности, RFC 2459, RFC 2510 и RFC 2511), и дополняет первую версию положениями о поддержке сервисов конфиденциальности.
Проект национальной ассоциации автоматизированных клиринговых палат
Национальная ассоциация автоматизированных клиринговых палат США (National Automated Clearing House Association - NACHA) финансировала успешный проект функциональной совместимости удостоверяющих центров CA Interoperability Pilot, завершенный в октябре 1998 г. Участниками проекта были такие известные компании, как CertCo, Digital Signature Trust (DST), Entrust, GTE CyberTrust, IBM и VeriSign. В качестве базовой модели PKI в пилотном проекте была выбрана четырехсторонняя модель (см. ), имитирующая приобретение товаров и услуг через Интернет. Посредниками сделок между покупателем и продавцом выступали банки каждой из сторон, которые действовали как самостоятельные удостоверяющие центры. Все решения относительно финансовых транзакций должны были инициироваться банками.
С технологической точки зрения, главной целью проекта была демонстрация пригодности PKI-продуктов многих поставщиков для реализации предложенной модели, поэтому банки-участники проекта использовали разные программные продукты для поддержки УЦ, предоставленные поставщиками технологии. В дальнейшем поставщики - участники проекта совместно работали над созданием профилей сертификата и САС, и тестирование функциональной совместимости выполнялось для этих профилей. Результаты этой работы были опубликованы в документе "Функциональная совместимость удостоверяющих центров: от концепции к реальности" .
Апробация концепции SIRCA
Апробация концепции головного УЦ отрасли средств безопасности Securities Industry Root CA (SIRCA) выполнялась Ассоциацией отрасли средств безопасности США Securities Industry Association вместе с компаниями Digital Signature Trust (DST) и ABAecom. УЦ отрасли действовал как головной центр в двухуровневой иерархии и служил источником доверия для доверяющих сторон - фирм, занимающихся бизнесом в сфере средств безопасности. Каждая из двадцати фирм - участников проекта организовала свой УЦ, связанный с головным УЦ отрасли, а затем выпускала и подписывала цифровые сертификаты для своих служащих, для того чтобы они могли защищенно обмениваться сообщениями электронной почты с партнерами по бизнесу из других фирм.
Концепция SIRCA, аналогичная концепции мостового УЦ, по-своему реализовала установление отношений доверия между многими доменами PKI, которое, в противном случае, потребовало бы заключения двусторонних соглашений о кросс-сертификации каждого домена с каждым. В ходе апробации использовался относительно простой профиль сертификатов: приложение защищенной электронной почты S/MIME v2 профилировалось в том смысле, что выполнялось требование, чтобы в каждое заверенное цифровой подписью сообщение включался полный список сертификатов, необходимых для проверки пути сертификации.
Проект продемонстрировал возможность установления защищенных коммуникаций посредством Интернета между фирмами, занимающимися бизнесом в сфере средств безопасности, на базе головного УЦ отрасли и функциональную совместимость их удостоверяющих центров.
Международные инициативы
PKI X.509
Как уже отмечалось выше, ведущим центром по выпуску согласованных стандартов в области PKI является рабочая группа PKIX организации IETF. Профиль сертификата и САС, который был описан в документе RFC 2459, известном как первая часть PKIX, стал предложенным стандартом в январе 1999 года, а затем дополнен и заменен в апреле 2002 года документом RFC 3280. RFC 3280 ввел в формат сертификата и САС дополнения, которые содержат информацию, позволяющую клиентскому программному обеспечению определять местонахождение УЦ и репозитория. Многие специалисты в области PKI признают разработку стандарта RFC 2459 поворотным моментом в развитии инфраструктур открытых ключей, способствовавшим созданию функционально совместимых PKI-продуктов (более подробная информация о документах группы PKIX приведена в разделе "Стандарты Internet X.509 PKI").
Проект EEMA PKI Challenge
Европейский Форум по электронному бизнесу (European Forum for Electronic Business - EEMA) с начала января 2001 года выполнял двухлетний проект PKI Challenge (pkiC), который финансировали Европейский Союз и правительство Швеции . К участию в проекте помимо 13 организаций, входящих в состав Форума, были привлечены поставщики PKI-продуктов, пользователи, консультанты, академические институты, поставщики услуг по выпуску и поддержке цифровых сертификатов для выработки решений по обеспечению функциональной совместимости PKI-продуктов. Рекомендации, выработанные в результате реализации проекта, приведены в .
|Компонент PKI | Рекомендация |
|УЦ | УЦ должен публиковать списки аннулированных сертификатов (САС) в соответствии со стандартом X.509 v2.
В сертификатах должно присутствовать дополнение CRL Distribution Points, где перечислены пункты распространения САС.
Все действия, выполняемые УЦ, должны регистрироваться в контрольных журналах.
Для автоматической регистрации конечных пользователей должен поддерживаться, по крайней мере, протокол Simple CMP
|
|Репозиторий | Предпочтительно использование репозитория типа X.500, доступ к которому осуществляется по протоколу LDAP.
Поставщикам следует ориентироваться на поддержку LDAP v3.
Необходимо поддерживать следующий минимальный набор компонентов отличительного имени Distinguished Name (DN):
* C (страна);
* L (местонахождение);
* O (организация);
* OU (подразделение организации);
* CN (общее имя);
* DC (компонент домена).
Поставщикам следует реализовать и протестировать дополнения, введенные стандартом RFC 3280, которые содержат информацию о местонахождении удостоверяющих центров Authority Information Access и репозиториев Subject Information Access
|
|OCSP-респондер | Ответ OCSP-респондера может быть подписан одним из следующих ключей:
1 ключом, которым подписан проверяемый сертификат, то есть ключом того УЦ, который выпустил сертификат, подлежащий валидации;
2 ключом, выпущенным для OCSP-респондера вместе с соответствующим сертификатом открытого ключа, который имеет в поле дополнения Extended Key Usage параметр OCSP-Signing. Этот сертификат должен быть выпущен тем же УЦ, который издал сертификат, подлежащий валидации;
3 ключом, который является действующим внутри локальной конфигурации центра подписания OCSP-ответа для сертификата, подлежащего валидации.
Те поставщики, которые пока не реализовали поддержку OCSP-ответа, должны ориентироваться на второй вариант
|
|Клиентское ПО | Клиентское ПО конечного субъекта должно иметь возможность:
* генерировать пару ключей для регистрации;
* управлять содержимым локального репозитория, предназначенного для хранения копий сертификатов корневого УЦ, списков САС и сертификатов корреспондентов;
* локально управлять идентификационными данными субъекта, а также предлагать средства дистанционного управления ими через УЦ
|
|PKI-совместимые приложения | Приложения, использующие PKI, должны:
* работать с файловыми форматами PKCS#10, PKCS#7 и PKCS#11, а также поддерживать либо протокол PKIX-CMP, либо CMC;
* иметь возможность выполнять поиск в каталоге LDAP или любом LDAP-совместимом каталоге;
* понимать дополнения сертификатов, связывающих сертификат с той PKI, которая его поддерживает (т.е. crl Distribution Point, authority Information Access, Subject Information Access)
|
Таблица 15.8.Рекомендации проекта pkiC Европейского Форума по электронному бизнесу
Поскольку для PKI используется большой и сложный комплекс программных продуктов, которые должны работать в условиях открытого рынка, поставщики сталкиваются с необходимостью поддерживать большое количество различных стандартов. Более того, учитывая некоторое запаздывание в разработке технологии, которое демонстрирует рынок PKI, поставщики также должны обеспечивать совместимость еще и с некоторыми стандартами, которые были заменены или признаны лишними. В связи с этим в рамках проекта был предложен минимальный список стандартов, поддержку которых в целях функциональной совместимости должны обеспечить поставщики PKI-продуктов ().
|Стандарты PKIX |
RFC 2459/RFC 3280: Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile
RFC 2510: Internet X.509 Public Key Infrastructure
Certificate Management Protocols
RFC 2511: Internet X.509 Certificate Request Message
Format
RFC 2511 bis Internet X.509 Certificate Request
Message Format
RFC 2797: Certificate Management Messages over
CMS
RFC 2559: Internet X.509 Public Key Infrastructure
Operational Protocols - LDAP v2
RFC 2587: Internet X.509 Public Key Infrastructure
LDAP v2 Schema
RFC 3279: Algorithms and Identifiers for the Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile
|
|Стандарты PKCS |
PKCS#1: RSA Cryptography Standard
PKCS#7: Cryptographic Message Syntax Standard
PKCS#10: Certification Request Syntax Standard
PKCS#11: Cryptographic Token Interface Standard
PKCS#12: Personal Information Exchange Syntax
Standard
PKCS#15: Cryptographic Token Information Format
Standard
|
|Дополнительные стандарты |
RFC 1777: Lightweight Directory Access Protocol
RFC 1823: The LDAP Application Program Interface
RFC 2251: Lightweight Directory Access Protocol (v3)
RFC 2252: Lightweight Directory Access Protocol
(v3): Attribute definition
RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names
RFC 2254: Lightweight Directory Access Protocol (v3)
The String Representation of LDAP Search Filters
RFC 2255: Lightweight Directory Access Protocol (v3)
The LDAP URL Format
RFC 3369: S/MIME Cryptographic Message Syntax
|
|Проекты стандартов |
Draft RFC2510 bis: Internet X.509 Public Key
Infrastructure Certificate Management Protocols
Draft: Internet X.509 Public Key Infrastructure LDAP
v2 Schema for X.509 CRLs
Draft: Internet X.509 Public Key Infrastructure LDAP
v2 Schema for X.509 Attribute Certificates
Draft: LDAP v3 DN strings for use with PKIs
|
Таблица 15.9.Рекомендуемый список поддерживаемых стандартов
Следует отметить, что этот проект, как и все перечисленные выше, был в значительной степени ориентирован на техническое тестирование и проверку совместимости программного обеспечения. Однако развертывание PKI связано не только с техническими, но и с правовыми и человеческими аспектами, от которых также может зависеть совместимость инфраструктур открытых ключей.