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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

 

Нотаризация

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

Приватность

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

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

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

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

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

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

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

 

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

 

К механизмам, которые необходимы для сервисов на базе PKI, относятся:

* цифровые подписи, хэш-функции, коды аутентификации сообщений (MAC) и шифры;

* надежные источники времени;

* механизмы создания политики полномочий ;

* механизмы обработки политики полномочий ;

* механизмы инфраструктуры управления полномочиями ;

* архитектура приватности.

 

Цифровые подписи, хэш-функции, коды аутентификации сообщений и шифры

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

 

Надежные источники времени

Сервис защищенного датирования требует наличия одного или нескольких надежных источников времени, то есть способа получения надежного представления текущего времени (синхронного глобальному времени, с высоким уровнем точности) одного или нескольких устройств/субъектов в локальной среде .

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

 

Механизмы создания и обработки политики полномочий

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

Политика полномочий должна быть не только разработана и отредактирована, но и обработана и воспринята механизмом верификации некоторого вида (иногда называемым точкой принятия решений о политике ) в момент запроса субъектом доступа к некоторому ресурсу. То есть точка принятия решения о политике использует политику полномочий как закон, согласно которому принимается или отвергается запрос субъекта на доступ к ресурсу или сервису. Для восприятия политики полномочий компьютером необходим формальный язык спецификации политики (например, язык eXtensible Access Control Markup Language - XACML или Annex D стандарта X.509) . Важным требованием общих инфраструктур управления полномочиями являются механизмы, которые могут интерпретировать закодированные политики и действовать в соответствии с ними.

 

Механизмы инфраструктуры управления полномочиями

Существует ряд механизмов реализации инфраструктуры управления полномочиями (Privilege Management Infrastructure - PMI). Они делятся на три категории:

* механизмы на базе Kerberos , такие как SESAME (a Secure European System for Applications in a Multi-vendor Environment) и DCE (Distributed Computing Environment) ;

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

* механизмы, основанные на атрибутных сертификатах, которые подобны сертификатам, определенным в стандарте X.509 и языке Security Assertion Markup Language (SAML) . Атрибутный сертификат аналогичен сертификату с открытым ключом, но связывает идентификационные данные субъекта не с открытым ключом, а с информацией о полномочиях или правах субъекта.

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

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

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

 

Архитектура приватности

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

1 УЦ знает подлинные идентификационные данные субъекта, но выпускает сертификаты, которые скрывают идентичность субъекта от всех остальных;

2 УЦ не знает подлинных идентификационных данных субъекта (они известны только самому субъекту), но, тем или иным способом, выпускает значимые сертификаты.

 

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

 

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

 

Механизм доставки точного времени

Для защищенного сервиса датирования (и соответственно для сервисов нотаризации и неотказуемости, которые базируются на нем) должен существовать способ доставки точного времени одному или нескольким центрам датирования в сети. Специалистами была выполнена трансформация известного протокола Network Time Protocol (NTP) в защищенный протокол Secure Network Time Protocol для криптографической аутентификации отправителя и проверки целостности данных, включенных в NTP-сообщение. Значение этой работы возрастает с ростом числа проектов развертывания дополнительного PKI-сервиса - сервиса защищенного датирования.

 

Защищенные протоколы

Для многих обсуждаемых в этой главе сервисов, базирующихся на PKI, ключевым компонентом является сервер, обеспечивающий связь с другими субъектами PKI (например, сервер центра датирования, центра нотаризации или сертификации данных, центра авторизации). Такая связь невозможна без защищенных протоколов - ведь подделка сообщений может скомпрометировать этот сервис. Следовательно, для обеспечения надежности предоставляемых сервисов в PKI должны использоваться защищенные протоколы (для связи "клиент-сервер" и одноранговых коммуникаций), поддерживающие аутентификацию, целостность и конфиденциальность. Примерами онлайновых протоколов, которые могут служить таким целям, являются протокол безопасности транспортного уровня TLS и протокол Simple Public Key GSS-API Mechanism (SPKM) .

 

Резервные серверы

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

 

Физически защищенный архив

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

 

Сертификаты приватности и отображение идентичности

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

 

Обстоятельства реальной жизни

Обстоятельства реальной жизни можно рассматривать как самое главное условие функционирования сервисов PKI. И главные, и дополнительные сервисы PKI становятся субъектом непредсказуемого поведения, некорректной работы или ненадежных результатов, если инфраструктура неправильно реализована или если пользователи и администраторы не обладают минимальным уровнем подготовки в сфере безопасности. Например, если субъекты PKI не соблюдают осторожность при хранении секретных ключей, то могут быть полностью скомпрометированы главные сервисы PKI и сервис неотказуемости. Если плохо реализован базовый протокол S/MIME или IKE, то не может надежно поддерживаться защищенная связь.

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