Ольга Полянская - Инфраструктуры открытых ключей
1 УЦ знает подлинные идентификационные данные субъекта, но выпускает сертификаты, которые скрывают идентичность субъекта от всех остальных;
2 УЦ не знает подлинных идентификационных данных субъекта (они известны только самому субъекту), но, тем или иным способом, выпускает значимые сертификаты.
Условия функционирования сервисов, базирующихся на PKI
При принятии решения о развертывании некоторых дополнительных сервисов, базирующихся на PKI, следует учитывать условия их функционирования.
Механизм доставки точного времени
Для защищенного сервиса датирования (и соответственно для сервисов нотаризации и неотказуемости, которые базируются на нем) должен существовать способ доставки точного времени одному или нескольким центрам датирования в сети. Специалистами была выполнена трансформация известного протокола Network Time Protocol (NTP) [134] в защищенный протокол Secure Network Time Protocol [108] для криптографической аутентификации отправителя и проверки целостности данных, включенных в NTP-сообщение. Значение этой работы возрастает с ростом числа проектов развертывания дополнительного PKI-сервиса - сервиса защищенного датирования.
Защищенные протоколы
Для многих обсуждаемых в этой главе сервисов, базирующихся на PKI, ключевым компонентом является сервер, обеспечивающий связь с другими субъектами PKI (например, сервер центра датирования, центра нотаризации или сертификации данных, центра авторизации). Такая связь невозможна без защищенных протоколов - ведь подделка сообщений может скомпрометировать этот сервис. Следовательно, для обеспечения надежности предоставляемых сервисов в PKI должны использоваться защищенные протоколы (для связи "клиент-сервер" и одноранговых коммуникаций), поддерживающие аутентификацию, целостность и конфиденциальность. Примерами онлайновых протоколов, которые могут служить таким целям, являются протокол безопасности транспортного уровня TLS [142] и протокол Simple Public Key GSS-API Mechanism (SPKM) [139].
Резервные серверы
Серверы являются ключевым архитектурным элементом во многих сервисах, базирующихся на PKI. Следовательно, отказ сервера в обслуживании (из-за выхода из строя сегмента сети или поломки сервера) может существенно повлиять на взаимодействие и работу субъектов PKI. По этой причине в сети необходимы резервные серверы, доступные в режиме "теплого" или "горячего" резервирования.
Физически защищенный архив
Для базирующегося на PKI сервиса неотказуемости необходим архив (для того чтобы хранить, по крайней мере, старые копии списков САС, и, возможно, нотариально заверенные документы и другую информацию). Архив должен быть физически защищен от повреждения в случае пожара, землетрясений, ураганов и других стихийных бедствий, а также от хищения, взрывов и других действий людей. В целях безопасности должно быть предусмотрено хранение данных в резервном архиве.
Сертификаты приватности и отображение идентичности
При выполнении транзакции для сохранения приватности субъекта могут использоваться псевдонимы. Они позволяют скрывать информацию об идентичности субъектов либо от наблюдателей транзакции (например, пользователей Интернета), либо от других участников этой транзакции. При сокрытии информации от наблюдателей транзакции требуется поддерживать на сервере некоторое соответствие псевдонимов и настоящих имен или другой идентифицирующей субъектов информации, то есть отображение идентичности субъектов. При сокрытии информации от других участников транзакции это отображение выполняется третьей доверенной стороной ("УЦ приватности"), а иногда не выполняется никем. Таким образом, для поддержки базирующегося на PKI сервиса приватности необходимо выполнять отображение идентичности субъектов на серверном компоненте в режиме реального времени или использовать услуги независимого УЦ, который выпускает анонимные сертификаты или сертификаты под псевдонимом.
Обстоятельства реальной жизни
Обстоятельства реальной жизни можно рассматривать как самое главное условие функционирования сервисов PKI. И главные, и дополнительные сервисы PKI становятся субъектом непредсказуемого поведения, некорректной работы или ненадежных результатов, если инфраструктура неправильно реализована или если пользователи и администраторы не обладают минимальным уровнем подготовки в сфере безопасности. Например, если субъекты PKI не соблюдают осторожность при хранении секретных ключей, то могут быть полностью скомпрометированы главные сервисы PKI и сервис неотказуемости. Если плохо реализован базовый протокол S/MIME или IKE, то не может надежно поддерживаться защищенная связь.
В реальной жизни людям свойственно ошибаться. Ошибки в реализации и использовании PKI делают инфраструктуру уязвимой. Решению проблем, которые возникают на практике, способствуют выбор надежных поставщиков программного и аппаратного обеспечения, тщательное тестирование, непрерывный мониторинг функционирования PKI и обучение пользователей.
Лекция 17. Приложения, базирующиеся на PKI
Рассматриваются защищенная электронная почта, средства безопасности транспортного уровня и IP-уровня, дается краткая характеристика протоколов SSL и TLS, описываются протоколы установления соединений, передачи записей, протоколы IPsec, обсуждаются типовые сценарии использования PKI.
Защищенная электронная почта S/MIME
Спецификация Secure Multipurpose Internet Mail Extension (S/MIME) предназначена для защиты наиболее популярного Интернет-сервиса - электронной почты. В силу важности этого сетевого сервиса предпринималось много попыток стандартизовать решения защищенной электронной почты. Одна из первых схем защиты - Privacy Enhanced Mail (PEM) - была предложена в 1985 году. Следующая схема защиты появилась в 1995 году и получила название MIME Object Security Services (MOSS). Несмотря на то, что в них содержалось множество хороших идей, негибкость и отсутствие совместимости отодвинули PEM и MOSS на вторые роли в сфере создания защищенного обмена сообщениями и были вытеснены системами Secure/MIME (S/MIME) и Pretty Good Privacy (PGP).
Протоколы S/MIME и PGP поддерживаются большинством программных продуктов, предназначенных для коллективной работы и защиты электронной почты. Наиболее распространенным и широко признанным стандартом обмена сообщениями стал разработанный в 1996 году стандарт S/MIME. Первоначально компанией RSA Data Security была предложена вторая версия спецификации S/MIME v2 [169], [170], позднее она была доработана рабочей группой организации IETF и в результате появилась новая, третья версия - S/MIME v3 [158], [159].
S/MIME обеспечивает защиту от трех типов нарушений безопасности: "подслушивания", или перлюстрации, искажения сообщений и фальсификации [22]. Защита от перлюстрации достигается путем шифрования сообщений. Для защиты от искажения почтового сообщения или фальсификации в S/MIME применяют цифровые подписи. Цифровая подпись гарантирует, что сообщение не было изменено в процессе передачи. Кроме того, ее наличие не позволяет отправителю сообщения отказаться от своего авторства.
Однако цифровая подпись не гарантирует конфиденциальность сообщения. В S/MIME эту функцию выполняет цифровой конверт. Шифрование осуществляется с помощью симметричного криптографического алгоритма типа DES, Triple-DES или RS2. Симметричный ключ шифруется с помощью открытого ключа получателя, а зашифрованное сообщение и ключ передаются вместе.
Спецификация S/MIME определяет два типа MIME-конверта: один для цифровых подписей, другой - для шифрованных сообщений. Оба типа базируются на синтаксисе криптографических сообщений стандарта PKCS#7 [198]. Если сообщение должно быть зашифровано, а шифртексту должны быть присвоены некоторые атрибуты, используются вложенные конверты. Внешний и внутренний конверт предназначаются для защиты цифровых подписей, а промежуточный конверт - для защиты шифртекста.
Помимо обеспечения целостности сообщения во время передачи, S/MIME идентифицирует обладателя конкретного открытого ключа с помощью сертификата X.509. Цифровой сертификат удостоверяет, что открытый ключ действительно принадлежит тому, кто является субъектом сертификата.
S/MIME v3 поддерживает следующие важные свойства, которые отсутствуют в S/MIME v2:
* заверенные цифровой подписью квитанции;
* метки безопасности;
* списки рассылки;
* гибкое управление ключами.
Заверенные цифровой подписью квитанции позволяют отправителю сообщения удостовериться в том, что оно было получено адресатами без изменений. Получатель сообщения не может сгенерировать валидную квитанцию до тех пор, пока не проверит подпись отправителя на полученном сообщении.
