Проблема аутентификации. Инфраструктура открытых ключей

Презентацию к лекции Вы можете скачать здесь.

Цель лекции

• Изучить предпосылки проблемы аутентификации
• Рассмотреть основные компоненты инфраструктуры открытых ключей PKI
• Изучить структуры и принципы работы удостоверяющего центра
• Рассмотреть технологии работы с отозванными сертификатами

Текст лекции

В одноключевых системах существуют две принципиальные проблемы:

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

Такие задачи позволяют решить алгоритмы, основанные на ряде математических проблем. Наиболее известный и широко распространенный протокол открытого распределения ключей [13.1] был разработан У. Диффи и М. Хеллманом в 1976 г. Протокол позволяет двум пользователям обмениваться частным ключом по уязвимым каналам, не имея никаких предварительных договоренностей. Безопасность протокола Диффи-Хеллмана основана на трудности вычисления дискретного логарифма в конечном поле. Существует ряд модификаций этого алгоритма, предусматривающих аутентификацию участников.

Протокол Диффи-Хеллмана часто обозначается аббревиатурой DH. Вариант протокола, основанный на использовании криптографических преобразований в группе точек эллиптической кривой, обозначается как ECDH [13.2].

В 1995 году на базе протокола Диффи-Хеллмана был предложен новый протокол, получивший название MQV по первым буквам фамилий его авторов Menezes - Qu - Vanstone. Протокол был модифицирован в 1998 году [13.3].

Для случая эллиптических кривых используется обозначение ECMQV [13.4]. Протокол MQV является более защищенным к возможным махинациям с подменой ключей, по сравнению с оригинальным протоколом Диффи-Хеллмана. Данные протоколы входят в стандарты IEEE P1363 [13.5], ANSI X9.42 [13.8] и ANSI X9.63 [13.6].

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

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

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

Рис. 13.1. Процедура входа пользователя в АС

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

Сертификаты

В Microsoft .NET Framework широко используются сертификаты. Сертификат [13.8] - это закодированный файл формата ASN.1 ( Abstract Syntax Notation One ), содержащий открытый ключ и дополнительную информацию о ключе и его владельце. Сертифика т имеет ограниченный срок действия и подписывается с помощью другого ключа (так называемого издателя), который используется для обеспечения гарантии подлинности как атрибутов, так и самого открытого ключа. ASN.1 можно рассматривать как двоичный аналог XML [13.8]: у него также имеются правила кодировки, строгий контроль типов и теги, однако все эти компоненты имеют двоичные значения, которым, как правило, не соответствуют никакие печатные символы.

Чтобы такой файл могли использовать разные системы, он должен иметь стандартный формат. Это формат X.509 (текущая версия 3), описанный в документе RFC 3280 [13.14]. Стандарт X.509 не определяет обязательного типа ключа, встроенного в сертификат, но в настоящее время алгоритм RSA [13.15] является наиболее известным из применяемых криптографических алгоритмов с асимметричными шифрами. Сертификаты X509 играют очень важную роль в мире Web. Они устанавливают коммуникации SSL и выполняют аутентификацию. Стандарт X.509 ITU-T [13.16] является фундаментальным стандартом, лежащим в основе всех остальных, используемых в инфраструктуре открытых ключей. Основное его назначение - определение формата электронного сертификата и списков отозванных сертификатов [13.17]. Сертификаты используются также при цифровом подпиcывании кода по технологии Authenticode. При подписывании двоичного кода ( EXE и DLL ) добавляется информация об авторе: это гарантирует, что файл является достоверным и обеспечивает целостность программного обеспечения.

В стандарте PKCS #7 [13.18, 13.19] определяется двоичный формат для подписанных и шифрованных данных Cryptographic Message Syntax ( CMS ) (Синтаксис криптографического сообщения). CMS используют многие протоколы безопасности, в том числе SSL и S / MIME. Кроме того, CMS применяется, когда приложения должны осуществлять обмен подписанными и шифрованными данными между несколькими сторонами.

Получение сертификатов

Существует несколько способов получения сертификата [13.8]. При обмене файлами сертификаты обычно размещаются в файле формата CER или PFX. Файлы с расширением CER являются подписанными файлами ASN.1 в формате X.509v3. Они содержат открытый ключ и дополнительную информацию. Могут также встретиться файлы с расширением PFX ( Personal Information Exchange ). В соответствии со стандартом PKCS #12 [13.20], файл с расширением PFX ( Personal Information Exchange ) содержит сертификат и соответствующий закрытый ключ. Файлы в формате PFX обычно применяются для импорта пар ключей на сервер или с целью резервного копирования.

Существует возможность создавать собственные сертификаты. Метод их создания обычно зависит от способа их применения. Для обычных ситуаций в Интернете, когда пользователь не знает, с кем он связывается, запрашивается, как правило, сертификат от коммерческого центра сертификации ( CA ). Преимуществом такого подхода является то, что эти известные центры сертификации уже признаны доверенными операционной системой Windows и всеми другими операционными системами (и обозревателями), поддерживающими сертификаты и протокол SSL [13.21]. Это позволяет обходиться без обмена ключами центра сертификации.

Для ситуаций B2B (сокр. от business-to-business, "бизнес для бизнеса" - схема организации взаимодействия между предприятиями, в т.ч. с привлечением интернет-ресурсов ) и интрасетей можно использовать внутренний центр сертификации. Службы сертификатов входят в Windows 2000 и Windows Server 2003 и в сочетании со средством Active Directory позволяют распространять сертификаты в рамках организации.

Для простых SSL -соединений не требуется доступ к хранилищу сертификатов, но если в коде идет обращение к Web -сервисам или Web -приложениям, расположенным на другом сервере, который требует аутентификации сертификатом X509, то приложение должно поддерживать возможность чтения сертификата из хранилища сертификатов Windows и добавления его к Web -запросу (или к прокси Web -сервиса) перед тем, как отправить запрос.

Сертификаты используются в разных компонентах .NET Framework, и на некотором уровне все эти функциональные возможности основаны на классе X509Certificate из пространства имен System.Security.X509Certificates. У пакета .NET Framework 1.x имелось представление сертификатов X.509, названное X509Certificate. Этот класс обладал ограниченным набором функциональных возможностей и не поддерживал криптографические операции. В версии 2.0 введена модернизированная поддержка сертификатов и добавлен новый класс, названный X509Certificate2. Он является производным от класса X509Certificate и имеет более широкие возможности. При необходимости можно выполнять преобразования между этими классами, но рекомендуется по возможности использовать последнюю версию.