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

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

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

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

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

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

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

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

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

Приватность

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

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

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

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