Инфраструктуры открытых ключей - Ольга Полянская

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-пакетов, а также частичную защиту от анализа трафика путем применения туннельного режима [216]. Документы RFC, относящиеся к IPsec, содержат описания протокола аутентифицирующего заголовка, протокола инкапсулирующей защиты содержимого IP-пакетов и протокола управления ключами и контекстами безопасности. Стандарты IPsec обеспечивают конфиденциальность, целостность и достоверность данных, передаваемых через открытые IP-сети.

Стандарты DNS определяют механизмы, обеспечивающие безопасность данных инфраструктуры системы доменных имен DNS. Документы описывают операционные требования безопасности системы, методы хранения сертификатов и ключей Диффи-Хэллмана, динамическое обновление защищенной системы DNS, механизм защиты передаваемых данных с помощью алгоритма MD5, DSA и RSA-ключей и цифровых подписей. Для обеспечения достоверной передачи DNS-данных в масштабе Интернета в систему DNS вводятся расширения DNSSEC, задаваемые соответствующим стандартом.

Спецификация SET предлагает инфраструктуру для защиты от подделок платежных карт, используемых для транзакций электронной коммерции в Интернете, описывает систему аутентификации участников расчетов, которая базируется на PKI [2]. Принципы SET излагаются в трех книгах, содержащих сведения о правилах ведения бизнеса на базе защищенных электронных транзакций, руководство программиста и формальное описание протокола SET. Рис. 15.1 иллюстрирует взаимосвязь стандартов в области PKI [10].

Итак, базой для разработки стандартов в области PKI стали стандарты серии X.500 (хотя не все их наименования начинаются с X.5xx) Международного союза электросвязи (ITU), предложившие стандартную структуру баз данных, записи в которых содержали информацию о пользователях [3]. Стандарт 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, а также их аналоги на русском языке приведены в табл. 15.5.

Системы, использующие сертификаты, и PKI

Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.

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