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

Сервисы, базирующиеся на PKI

В предыдущей главе обсуждались главные сервисы безопасности, предлагаемые PKI: аутентификация, целостность и конфиденциальность. Настоящая глава посвящена сервисам, которые не являются фундаментальными сервисами любой PKI, но могут быть построены на базе PKI. К дополнительным, базирующимся на PKI сервисам относятся:

* защищенная связь;

* защищенное датирование;

* нотаризация ;

* неотказуемость;

* защищенный архив данных;

* управление полномочиями;

* приватность [44].

Защищенная связь

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

* защищенную электронную почту, использующую протоколы S/MIME v2 [169] и S/MIME v3 [158], [159];

* защищенный доступ к web-серверу на базе протокола TLS [142];

* защищенную виртуальную частную сеть, использующую протоколы IPSec [143] и IKE [147].

Для шифрования и подписания почтовых сообщений, наряду с главными сервисами PKI, может быть реализована защищенная электронная почта в качестве сервиса, базирующегося на PKI. Это позволяет передавать сообщения по открытым сетям без риска компрометации их аутентичности, целостности и конфиденциальности. Более подробно защищенная электронная почта и другие приложения защищенной связи рассматриваются в (лекции 17), которая посвящена приложениям, базирующимся на PKI.

Защищенное проставление меток времени

Защищенное датирование, или проставление меток времени , заключается в связывании доверенным центром датирования метки времени с определенной "порцией" данных при сохранении их аутентичности и целостности. Причем, важным является не столько само значение времени, сколько защищенность связывания данных с определенным временем (датой). В частности, в некоторых приложениях бывает важно зафиксировать не время совершения события, а последовательность событий, например, поступление в доверенный центр данного документа Y перед документом Z, но после документа X.

Доверенный центр датирования не является строго необходимым компонентом этого сервиса. Любой субъект может поддерживать надежное время в своей локальной среде и в случае необходимости связывать метки времени со своими собственными данными. На практике, однако, трудно поддерживать надежное время для локальных сред (например, настольных систем) многих пользователей, поэтому прибегают к помощи доверенных центров датирования, которые обрабатывают запросы субъектов на проставление меток времени.

Защищенный сервис датирования базируется на главных сервисах PKI: аутентификации и целостности. Метка времени на документе образуется в результате подписания цифровым образом комбинации хэш-кода самого документа и значения времени в некотором формате. Подпись доверенного центра датирования обеспечивает аутентичность и целостность данных. Для того чтобы эта схема работала, все субъекты PKI должны знать и доверять открытому ключу подписи центра датирования, при помощи которого можно проверить подпись на метке времени. Если такой ключ становится ненадежным (например, в результате компрометации секретного ключа подписи центра датирования), необходимо, чтобы все субъекты PKI были проинформированы об этом, и для центра датирования был выпущен новый надежный ключ. Все метки времени, заверенные ненадежным ключом, не следует считать валидными.

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

Нотаризация

Существуют разные трактовки термина нотаризация, но в данном контексте считается, что базирующийся на PKI сервис нотаризации предназначен для сертификации данных, то есть подтверждения их валидности или корректности. Вывод о корректности данных зависит от их типа, например, если данные, подлежащие сертификации, являются цифровой подписью, то нотаризация подтверждает валидность подписи при выполнении следующих условий:

* математической корректности результата верификации подписи при помощи соответствующего открытого ключа;

* правильного связывания открытого ключа подписи с субъектом, который подписывает данное значение;

* доступности и надежности всех других данных, необходимых для процесса валидации (например, дополнительных сертификатов для формирования полного пути).

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

Неотказуемость

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

Наиболее распространенными и часто обсуждаемыми вариантами неотказуемости являются неотказуемость источника (когда пользователь не может ложно отказаться от отправки сообщения или документа) и неотказуемость получения (когда пользователь не может ложно отказаться от получения сообщения или документа). Однако должны быть определены и другие варианты, включая неотказуемость создания, неотказуемость доставки и неотказуемость подтверждения.

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

1 он намеренно передал свой секретный ключ подписи третьей стороне, чтобы иметь возможность отказаться от получения сообщения от А ;

2 секретный ключ подписи пользователя В был скомпрометирован без его ведома, следовательно, при защите ключа им была допущена небрежность.

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

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

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

Для поддержки сервиса неотказуемости необходим архив данных, где должны защищенно храниться доказательства, которые могут потребоваться для разрешения споров: просроченные сертификаты, старые списки САС, токены меток времени, структуры сертификации данных и другая относящаяся к делу информация. Важно отметить, что во многих PKI недостаточно простого архива данных и может возникнуть необходимость в криптографической защите доказательств. Более того, как только срок действия ключа подписи определенного доказательства истекает и старый ключ заменяется новым, это доказательство повторно подписывается новым ключом. В результате образуется непрерывный "след" ключей, ведущий обратно во времени к дате первоначального создания доказательства. След ключей связан с соответствующим следом сертификатов и датами подписей.

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

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

Управление полномочиями

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

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

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

Понятие полномочия или права часто приводит к понятию делегирования [57]. Если пользователь А обладает определенным полномочием, то может передать это право другому субъекту - пользователю В (возможно, с некоторыми ограничениями). Пусть, например, пользователь А имеет неограниченный доступ к некоторому web-сайту для выполнения определенной рабочей функции. В ряде случаев ему бывает необходимо, чтобы его коллега, пользователь В, получил доступ к этому сайту для выполнения работы вместо него (например, в отсутствие пользователя А ). Делегирование бывает скрытое и явное. Скрытое делегирование происходит тогда, когда пользователь А делегировал некоторое полномочие пользователю В, а субъект, проверяющий авторизацию В, не может определить, что делегирование имело место. С точки зрения проверяющего, пользователь В получил полномочия от надежного центра авторизации и пользователь А никак не участвовал в этом процессе.

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

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

Приватность

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

Пример 16.1. Рассмотрим следующий сценарий. Субъект E под псевдонимом проходит аутентификацию на web-сайте S₁. S₁ неизвестны подлинные идентификационные данные субъекта E, поскольку тот использует псевдоним. Однако S₁ определяет, что это тот же самый субъект, который не раз посещал сайт, и может присвоить ему специальный статус (например, "Е интересуется информацией определенного рода" или "Е получает приоритет" ). В том случае, если для удовлетворения запроса субъекта E его необходимо перенаправить на второй web-сайт S₂, то S₁ может сослаться на E как на субъекта со специальным статусом. Это иногда называют проблемой индексной ссылки [44].

Существуют три способа решения этой проблемы: токены носителя, схемы на базе секрета, схемы на базе открытых ключей. При помощи токенов носителя S₁ информирует S₂: "Тот, кто Вам предъявит этот токен (или указатель на этот токен), является тем субъектом, о котором я сообщаю". Механизм аутентификации для субъекта E заключается только во владении токеном (или указателем) и возможности предъявить его S₂. Ясно, что если этот токен/указатель похищен, то любой субъект может с успехом выдать себя за E.

Второй способ характеризуется тем, что E и S₁ разделяют некоторый секрет, такой как пароль или симметричный ключ. S₁ говорит S₂: "Тот, кто знает следующий секрет - xyz^abc - является тем субъектом, о котором я сообщаю". В этом случае механизм аутентификации для субъекта E - это доказывание знания секрета перед S₂. Данное решение подразумевает, что общий секрет E и S₁ обязательно должен быть раскрыт S₂, который получает возможность маскироваться под субъекта E перед S₁. Эта проблема обостряется с ростом числа сайтов, которым известен секрет (для выполнения дальнейших шагов транзакции или для однократной регистрации).

Третий способ заключается в том, что субъект E имеет пару ключей и сертификат. S₁ говорит S₂: "Тот, кто может аутентифицировать себя при помощи сертификата, является субъектом, о котором я сообщаю". Механизм аутентификации для E состоит в доказывании знания секретного ключа, соответствующего открытому ключу в сертификате.

Механизмом сильной аутентификации субъекта при многошаговой транзакции является его однократная регистрация, когда субъект E предъявляет пароль (или PIN-код, или биометрическую характеристику и т.п.) локальной системе, чтобы открыть пару ключей, но не участвует в аутентификации S₁ перед S₂ (или каким-либо следующим участником транзакции).

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

Механизмы, которые необходимы для сервисов, базирующихся на PKI

Условия функционирования сервисов, базирующихся на PKI