При явном делегировании субъекту ясно, что пользователь А изначально имел это полномочие и передал его на некоторое время пользователю В. Такое делегирование иногда называется контролируемым ( делегирование с контрольным журналом), потому что полная цепочка передачи полномочий от центра авторизации до конечного обладателя полномочия очевидна для проверяющего субъекта. Оба типа делегирования имеют свои достоинства, но явное делегирование более точно соответствует требованиям ведения бизнеса в корпоративной и финансовой сферах, потому что здесь имеется большая определенность в отношении ответственности за причинение финансового ущерба.
Как обсуждалось ранее, управление полномочиями требует предварительной аутентификации. Теоретически может использоваться любой механизм аутентификации, хотя очевидны преимущества сервиса аутентификации, базирующегося на 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. Эта проблема обостряется с ростом числа сайтов, которым известен секрет (для выполнения дальнейших шагов транзакции или для однократной регистрации).
Третий способ заключается в том, что субъект E имеет пару ключей и сертификат. S1 говорит S2: "Тот, кто может аутентифицировать себя при помощи сертификата, является субъектом, о котором я сообщаю". Механизм аутентификации для E состоит в доказывании знания секретного ключа, соответствующего открытому ключу в сертификате.
Механизмом сильной аутентификации субъекта при многошаговой транзакции является его однократная регистрация, когда субъект E предъявляет пароль (или PIN-код, или биометрическую характеристику и т.п.) локальной системе, чтобы открыть пару ключей, но не участвует в аутентификации S1 перед S2 (или каким-либо следующим участником транзакции).
Обеспечиваемый PKI сервис приватности делает возможной сильную аутентификацию и, следовательно, более высокую степень безопасности в многошаговых и многосторонних транзакциях, чем альтернативные механизмы. Это достигается путем использования анонимных сертификатов или сертификатов, выпущенных под псевдонимом, которые во время транзакции не раскрывают идентичность владельца сертификата никакой доверяющей стороне.
Механизмы, которые необходимы для сервисов, базирующихся на PKI
К механизмам, которые необходимы для сервисов на базе PKI, относятся:
* цифровые подписи, хэш-функции, коды аутентификации сообщений (MAC) и шифры;
* надежные источники времени;
* механизмы создания политики полномочий ;
* механизмы обработки политики полномочий ;
* механизмы инфраструктуры управления полномочиями ;
* архитектура приватности.
Цифровые подписи, хэш-функции, коды аутентификации сообщений и шифры