Книга: Инфраструктуры открытых ключей

Альтернативные форматы сертификатов

Помимо сертификатов открытых ключей формата X.509 v3 существуют сертификаты и других форматов. Остановимся на сертификатах SPKI, PGP, SET и атрибутных сертификатах.

Сертификаты SPKI

Задачей простой инфраструктуры открытых ключей SPKI (Simple Public Key Infrastructure) является распространение сертификатов для авторизации, а не для аутентификации владельцев открытых ключей. Теоретические основы и требования к SPKI разработаны рабочей группой организации IETF. Базой для SPKI стали основные идеи простой распределенной структуры безопасности - Simple Distributed Security Infrastructure (SDSI), поэтому можно говорить о единой концепции, кратко обозначаемой SPKI/SDSI. Центральными объектами SDSI являются сами ключи, а не имена. Именно ключи могут идентифицировать объекты. Сертификаты SDSI имеют удобную для восприятия форму, как правило, содержат некоторый текст свободного формата, фотографию или другую информацию.

Рабочая группа IETF SPKI разработала ряд технических и информационных документов, в том числе:

* формат сертификата;

* теорию сертификатов;

* требования;

* примеры.

Основная цель сертификата SPKI - это авторизация некоторых действий, выдача разрешений, предоставление возможностей и т.п. владельцу ключа >[175]. Сертификаты SPKI часто называют сертификатами авторизации. Сертификаты авторизации, по замыслу авторов идеи SPKI, должны генерироваться любым владельцем ключа, которому разрешено предоставлять или делегировать полномочия. Владелец ключа непосредственно идентифицируется своим открытым ключом, хотя для ряда целей допускается применение некоторых других идентификаторов. Это может быть значение хэш-кода открытого ключа или некоторое имя, которое тем не менее всегда связано с ключом. В связи с тем, что сертификаты SPKI могут содержать информацию, которую владелец ключа не желает публиковать, допускается распространение сертификатов самим владельцем. Владелец ключа может использовать глобальное хранилище, например LDAP, сервер ключей PGP или систему доменных имен DNS.

Поскольку сертификаты SPKI содержат информацию, ознакомление с которой может представлять угрозу безопасности и приватности, объем информации, подтверждающей полномочия владельца, должен быть сведен к необходимому минимуму в зависимости от назначения сертификата. В тех случаях, когда требуется анонимность некоторых сертификатов (например, в секретном голосовании и аналогичных приложениях), сертификаты SPKI должны уметь присваивать атрибут ключу обезличенной подписи. Одним из атрибутов владельца ключа является его имя. У одного владельца ключа может быть несколько имен: те, которыми владелец предпочитает называться, и те, под которыми он известен другим владельцам ключей. Сертификат SPKI должен обеспечивать связывание ключей с такими именами.

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

Хотя SPKI-сертификаты имеют много общего с сертификатами открытых ключей X.509 (например, поля Issuer и Validity ), синтаксис и семантика этих полей неодинаковы. Кроме того, количество полей в сертификатах этих двух типов не позволяет их эквивалентно отображать друг на друга, а соглашения об именах отличаются полностью.

Работа группы IETF SPKI над документами простой инфраструктуры открытых ключей завершена, однако на практике эта работа в полном объеме не реализована. В настоящее время спрос на SPKI-сертификаты очень невелик, поэтому поставщики программных продуктов для УЦ и PKI не спешат реализовывать совершенно другой синтаксис сертификата в дополнение к сертификатам открытых ключей X.509 v3.

Сертификаты PGP

Система PGP (Pretty Good Privacy)>[40] разработана американским программистом Филиппом Циммерманном для защиты секретности файлов и сообщений электронной почты в глобальных вычислительных и коммуникационных средах. Ф. Циммерманн предложил первую версию PGP в начале 1990-х годов >[98]. Версия 2.x PGP была опубликована несколькими годами позже в спецификации набора стандартов IETF, названной PGP Message Exchange Formats >[137]. Последняя версия PGP, получившая название Open PGP, была издана в спецификации набора стандартов IETF - Open PGP Message Format >[149]. Документ, относящийся к Интернет-стандартам, объединяет PGP и MIME и называется PGP MIME Security with Pretty Good Privacy >[138].

PGP представляет собой гибридную систему, комплексно использующую преимущества асимметричных и симметричных криптографических алгоритмов. С точки зрения пользователя, PGP ведет себя как система с открытым ключом. Она обеспечивает безопасный обмен сообщениями и файлами по каналам открытой связи без наличия защищенного канала для обмена ключами >[218]. PGP позволяет шифровать, заверять электронной цифровой подписью, расшифровывать и проверять сообщения во время отправки и чтения электронной почты. В PGP применяются стойкие криптографические алгоритмы CAST, тройной DES и IDEA. Для выработки сеансового ключа используются алгоритмы RSA и Диффи-Хеллмана, для подписи - RSA и DSA. PGP задает форматы пакетов, позволяющие пересылать от одного субъекта к другому сообщения и файлы, а также PGP-ключи (иногда называемые PGP-сертификатами).

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

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

PGP поддерживает, в качестве частного случая своей обобщенной модели распределенного доверия, централизованный сценарий, когда сертификаты открытых ключей пользователей заверяет своей подписью лицо, пользующееся общим доверием - УЦ >[218]. Любому открытому ключу, заверенному подписью УЦ, можно доверять в том смысле, что он принадлежит тому, чье имя он несет. Все пользователи должны обладать копией открытого ключа УЦ для проверки его цифровой подписи. PGP обеспечивает интегрированную поддержку распространения и поиска открытых ключей на серверах ключей. Единый УЦ особенно подходит для больших централизованно управляемых организаций, правительственных или корпоративных. Некоторые организационные среды используют иерархию удостоверяющих центров, которая лежит в основе стандартной схемы, основанной на централизованном контроле и принудительно централизованном доверии. Иерархия удостоверяющих центров обычно диктует пользователю, кому он должен доверять. Децентрализованный вероятностный метод определения валидности ключей, реализованный PGP, позволяет пользователю самостоятельно принимать решение о доверии, строя свою собственную пирамиду сертификации.

Между 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

Протокол 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 и подписывается издателем сертификата. Атрибутный сертификат содержит девять полей: версия, владелец, издатель, идентификатор алгоритма подписи, серийный номер, период действия, атрибуты, уникальный идентификатор издателя и дополнения (см. ниже). Владелец атрибутного сертификата характеризуется подобно субъекту сертификата открытого ключа подписи, но может быть задан по имени, издателю и серийному номеру сертификата открытого ключа, либо при помощи хэш-кода сертификата или открытого ключа.

|Версия (v.1 или v.2) |

|Владелец сертификата |

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

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

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

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

|Атрибуты |

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

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

Структура атрибутного сертификата

Атрибуты описывают информацию о полномочиях владельца атрибутного сертификата. Как и сертификат открытого ключа подписи, атрибутный сертификат может содержать дополнения. Наряду с имеющимися в системе сервисами аутентификации, атрибутные сертификаты обеспечивают защищенную передачу информации о полномочиях их владельцев >[2]. Эту технологию могут применять, например, приложения удаленного доступа к сетевым ресурсам (таким, как web-серверы и базы данных), а также приложения, которые управляют физическим доступом в помещения и к аппаратному обеспечению.

Оглавление книги