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

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

Цель лекции

·                             Изучить предпосылки проблемы аутентификации

·                             Рассмотреть основные компоненты инфраструктуры открытых ключей 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 и имеет более широкие возможности. При необходимости можно выполнять преобразования между этими классами, но рекомендуется по возможности использовать последнюю версию.

Хранилища сертификатов

Сертификаты и соответствующие им закрытые ключи можно хранить на различных устройствах, например жестких дисках, смарт-картах и в ключах для порта USB. В Windows предусмотрен уровень абстракции, называемый хранилищем сертификатов, который служит для обеспечения единого способа доступа к сертификатам независимо от места их хранения. Windows поддерживает несколько типов хранилищ сертификатов. Хранилище локальной машины, например, доступно всем приложениям, запущенным с определенными привилегиями на этой локальной машине. Можно создать отдельное хранилище для каждой службы Windows на машине, и каждый пользователь может иметь отдельное хранилище сертификатов. Сертификаты в этих хранилищах защищены. Если у аппаратного устройства имеется поддерживаемый Windows криптопровайдер, можно получать доступ к данным, хранящимся на этом устройстве, используя интерфейс API хранилища сертификатов.

Если хранилище локальной машины шифруется ключом, управляемым локальным центром безопасности данной машины, то пользовательское хранилище шифруется ключом, хранимым в профиле пользователя [13.17]. В пределах одного хранилища Windows различает контейнеры, используемые для разных целей. Наиболее важными являются персональный ( Personal ) контейнер и контейнер под названием "Доверительный корневой центр сертификации " ( Trusted Root Certification Authorities ). Персональный контейнер обычно содержит все сертификаты, используемые приложениями (и пользователями, если речь идет о пользовательском хранилище), в то время как Trusted Root Certification Authorities хранит сертификаты для центров, издающих сертификаты. В контейнере Other People (Другие) содержатся сертификаты пользователей, с которыми имеется безопасная связь. Примером центра сертификации является VeriSign [13.22]. Любой сертификат, изданный доверительным центром, сертификат которого присутствует в хранилище Trusted Root Certification Authorities, считается заверенным системой. В Web -приложениях ASP.NET используется либо хранилище локальной машины, либо хранилище учетной записи службы (пользовательское хранилище служебной учетной записи, под которой выполняется системная служба Windows ); для приложений рабочей среды сертификаты обычно устанавливаются в хранилище пользователя.

Новый диспетчер Server Manager и связанные с ним мастера появились в результате попыток Microsoft сделать Windows Server 2008 (изначальное название продукта - Longhorn) по-настоящему модульной операционной системой [13.23]. Роль Active Directory ( AD ) Certificate Server состоит из четырех подкомпонентов: Certification Authority, Certificate Authority Web Enrollment, Simple Certificate Enrollment Protocol ( SCEP ) и Online Certificate Status Protocol ( OCSP ). В терминологии Microsoft эти подкомпоненты именуются также ролевыми службами. Первые два компонента ( Certification Authority и Certificate Authority Web Enrollment ) присутствовали в прошлых версиях Windows Certificate Services. Certification Authority - механизм сертификации и генератор списка отзыва; Certificate Authority Web Enrollment - набор Web -старниц, с помощью которых пользователи могут подписаться на получение сертификатов через Web -интерфейс. В прошлом SCEP -компонент входил в состав комплектов ресурсов Windows 2000 Server и Windows Server 2003. Благодаря SCEP сетевые устройства, такие как маршрутизаторы и коммутаторы, могут легко получить сертификаты из удостоверяющего центра Windows Certification Authority ( CA ). Компонент OCSP предоставляет новую службу, которой не было в прошлых версиях Windows. Через компонент OCSP пользователи и приложения могут получить информацию о состоянии сертификата в реальном времени (например, действителен сертификат или отозван).

Для получения доступа к хранилищу сертификатов Windows используется класс X509Store [13.8]. В его конструкторе указывается местоположение хранилища (текущего пользователя или компьютера) и имя хранилища. Внутренние имена не всегда совпадают с именами, представленными в оснастке MMC ( Microsoft Management Console ). Контейнер Personal соответствует имени My, Other People - AddressBook.

Получив правильный экземпляр X509Store, можно выполнять поиск, извлечение, удаление и добавление сертификатов. Поиск сертификатов можно выполнять на основе разных критериев, включая имя объекта, серийный номер, хеш, кем выдан сертификат и период его действия. Если извлечение сертификатов из хранилища осуществляется программным способом в приложениях, необходимо использовать уникальное свойство - например, идентификатор ключа объекта. Свойство HasPrivateKey сообщает о наличии или отсутствии соответствующего закрытого ключа. Свойства PrivateKey и PublicKey возвращают соответствующий ключ в виде экземпляра RSACryptoServiceProvider. При проверке сертификата следует учитывать несколько критериев, в особенности - кем он выдан (как правило, пользователь доверяет сертификатам, выданным центром сертификации из списка доверенных центров сертификации ) и его текущую действительность ( сертификаты могут становиться недействительными, например, при истечении срока их действия или при отзыве выдавшим их центром сертификации ). Для проверки этих свойств можно использовать класс X509Chain. Используя этот класс, можно указать политику проверки действительности - например, запрашивать доверенный корневой центр сертификации или указывать, требуется ли проверять сетевые или локальные списки отзыва. Если требуется проверить сертификаты, использовавшиеся для подписывания данных, важно проверить, был ли сертификат действительным на момент вычисления подписи - для этого класс X509Chain предоставляет возможность изменить время проверки.

Поддержка протокола SSL

Протокол проверки подлинности SSL [13.12] основан на сертификатах. В .NET Framework поддержка протокола SSL состоит из двух частей [13.8]. Специальный (но наиболее широко используемый) случай SSL через HTTP реализуется посредством класса HttpWebRequest (в конечном счете, этот класс используется также для клиентских прокси веб-сервисов).

При подключении к конечной точке, защищенной протоколом SSL, сертификат сервера проверяется на клиенте. По умолчанию в случае сбоя проверки подключение незамедлительно закрывается. Можно переопределить этот вариант поведения, обеспечив ответный вызов к классу с именем ServicePointManager. При каждой проверке сертификата стеком HTTP клиента сначала проверяется, обеспечен ли ответный вызов. Если обеспечен - выполняется соответствующий код. Для подключения ответного вызова необходимо предоставить делегата типа RemoteCertificateValidationCallback. Протокол SSL поддерживает также проверку подлинности клиента с помощью сертификата. Если веб-узел или веб-сервис, к которой требуется получить доступ, требует сертификат клиента, то как прокси клиента веб-сервисы, так и HttpWebRequest предоставляют свойство ClientCertificates типа X509Certicate.

В пакете .NET Framework 2.0 введен новый класс SslStream, позволяющий поместить SSL поверх любого потока, а не только HTTP. SslStream осуществляет поддержку стандартных сертификатов . NET несколькими способами, например, с помощью механизма ответного вызова проверки.

Краткие итоги

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

Скачано с www.znanio.ru