Читать онлайн «Инфраструктуры открытых ключей». Страница 26

Между PGP-ключами (или сертификатами) и сертификатами открытых ключей X.509, а также между соответствующими моделями доверия имеются существенные отличия, препятствующие взаимодействию сообщества пользователей PGP с другими сообществами, которые используют сертификаты формата X.509 (например, сообществом пользователей S/MIME). Это намного серьезнее, чем проблема несовместимости протоколов, потому что непохожа и несовместима основа базовых сервисов безопасности, обеспечиваемых открытыми ключами. Возможным решением может быть адаптация сертификатов X.509 v3 в дополнение к PGP-сертификату (или вместо него). Версия Open PGP 6.5. способна поддерживать сертификаты X.509, но, позволяя пользователям Open PGP подключаться к PKI на базе X.509, она не решает проблему несовместимости основных протоколов Open PGP и S/MIME. Другим возможным решением может быть разработка продуктов, поддерживающих сертификаты и PGP и X.509 v3, но это из-за существенных различий в моделях доверия усложнит администрирование и управление.

Протокол SET, который базируется на техническом стандарте, разработанном компаниями VISA и Master Card, обеспечивает безопасность электронных расчетов по пластиковым картам через Интернет: гарантирует конфиденциальность и целостность информации о платежах, аутентификацию счета владельца карты и дает возможность подтвердить право коммерсанта (продавца) проводить финансовые операции с финансовым учреждением [1]. В среде SET инфраструктура открытых ключей является фундаментом, на котором базируется вся система аутентификации участников расчетов.

Цифровые сертификаты, также известные как электронные мандаты или цифровые удостоверения личности, используются для связывания открытых ключей и субъектов и выпускаются доверенной третьей стороной или компанией - УЦ. Сертификаты владельцев карт выдаются только с разрешения финансового учреждения - эмитента этих карт, снабжаются его цифровой подписью и не могут быть изменены третьей стороной. Сертификаты содержат данные о номере счета и периоде действия, которые шифруются с использованием известного алгоритма шифрования с секретным ключом - Data Encryption Standard (DES). Запрашивая сертификат, владелец карты сообщает о своем намерении стать участником электронной торговли. Эти сертификаты передаются продавцам вместе с запросами о покупке и платежными инструкциями.

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

Конфиденциальность и целостность сообщений, которыми обмениваются участники системы защищенных электронных транзакций, обеспечивается механизмом двойных подписей. Содержание каждого сообщения шифруется при помощи случайно сгенерированного симметричного ключа шифрования. Этот ключ, в свою очередь, шифруется с использованием открытого ключа получателя сообщения. Созданный в результате последней операции так называемый цифровой конверт отправляется получателю вместе с зашифрованным сообщением. После получения цифрового конверта получатель расшифровывает его при помощи своего секретного ключа, чтобы получить случайно сгенерированный симметричный ключ для расшифровки исходного сообщения отправителя. Протокол SET предоставляет участникам сервис аутентификации на базе сертификатов формата X.509 и имеет средства аннулирования, реализованные с помощью списка аннулированных сертификатов. Спецификации SET [113], [114] и [115] задают стандарт поддержки платежей по кредитным картам в распределенных сетях. SET адаптирует формат сертификата открытого ключа X.509 и задает свои собственные специфические дополнения, которые поддерживаются только в SET-совместимых системах [44]. SET также предъявляет определенные требования профиля к стандартным дополнениям. Ниже иллюстрируется структуру сертификата SET.

|Версия |

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

|Идентификатор алгоритма подписи |

|Имя издателя |

|Период действия (не ранее/не позднее) |

|Имя субъекта |

|ИНформация об открытом ключе субъекта |

|Уникальный идентификатор издателя |

|Уникальный идентификатор субъекта |

|Дополнения |

Структура сертификата SET

|Стандартные дополнения | Специфические SET-дополнения |

|Идентификатор ключа УЦ | Тип сертификата |

|Назначение ключа | Данные продавца |

|.... | Сертификат карты |

|Туннелирование |

|Спецификатор SET |

Отметим, что на вышеуказанной схеме представлены не все возможные дополнения. Поскольку не-SET-приложения не понимают частные дополнения, задаваемые SET, нельзя ожидать, что не-SET-приложение (например, электронная почта на базе S/MIME) примет к использованию сертификат SET. Это действительно так, хотя формат сертификата SET согласуется с форматом сертификата X.509 v3. Дополнение Тип сертификата является критическим, следовательно, не-SET-приложение должно отвергать SET -сертификат. Пометка определенных дополнений как критических является общепринятой практикой для того, чтобы определенный тип сертификата мог использоваться только в контексте данного приложения. Этот пример характеризует ситуацию, когда конечному пользователю требуется несколько сертификатов.

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

Информация для авторизации часто имеет меньший срок действия, чем сертификат открытого ключа. Она могла бы указываться в дополнениях сертификата открытого ключа, но это не является выходом по двум причинам. Во-первых, подобный сертификат должен аннулироваться при любых изменениях информации для авторизации. Во-вторых, УЦ, выпускающий данный сертификат, не имеет полномочия подписывать эту информацию, а должен связываться с источником информации о правах доступа конкретного пользователя.

Атрибутный сертификат X.509 связывает атрибуты прав доступа с владельцем сертификата и предназначен для использования в Интернет приложениях [84]. Поскольку атрибутный сертификат не содержит открытого ключа, то его используют вместе с сертификатом открытого ключа. Аутентификация субъекта осуществляется при помощи сертификата открытого ключа, а связывание атрибутов с данным субъектом - посредством атрибутного сертификата.

Атрибутные сертификаты могут применяться в сервисах аутентификации источника данных и неотказуемости. В этом случае в сертификаты включают дополнительную информацию о субъекте, который ставит цифровую подпись. Эта информация позволяет удостовериться, что субъект имеет право подписывать данные. Род проверки зависит от содержания данных, которыми обмениваются стороны или которые должны быть заверены цифровой подписью.

Атрибутный сертификат X.509 напоминает сертификат открытого ключа этого же формата, но имеет другие функциональные возможности. Он представляет собой структурированную двоичную запись формата ASN.1 и подписывается издателем сертификата. Атрибутный сертификат содержит девять полей: версия, владелец, издатель, идентификатор алгоритма подписи, серийный номер, период действия, атрибуты, уникальный идентификатор издателя и дополнения (см. ниже). Владелец атрибутного сертификата характеризуется подобно субъекту сертификата открытого ключа подписи, но может быть задан по имени, издателю и серийному номеру сертификата открытого ключа, либо при помощи хэш-кода сертификата или открытого ключа.