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

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

В одноключевых системах существуют две принципиальные проблемы: Распределение секретных ключей по информационному каналу; Аутентификация секретного ключа (процедура, позволяющая получателю удостовериться, что секретный ключ принадлежит законному отправителю). Такие задачи позволяют решить алгоритмы, основанные на ряде математических проблем. Наиболее известный и широко распространенный протокол открытого распределения ключей [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.  Процедура входа пользователя в АС Средства разграничения доступа, согласно классификационной схеме, отнесены к активным средствам защиты, поскольку позволяют блокировать доступ пользователя к информации АС в случае непрохождения им процедур идентификации, аутентификации или авторизации. Средства защиты этого уровня могут выполнять свои функции на уровне узлов АС или на уровне сетевого взаимодействия. Сертификаты В 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-приложениях используется либо хранилище локальной машины, либо хранилище учетной записи службы (пользовательское хранилище служебной учетной записи, под которой выполняется системная служба 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 несколькими способами, например, с помощью механизма ответного вызова проверки.

Протоколы аутентификации в Windows

Рассмотрим наиболее распространенные протоколы безопасности, используемые в процессе аутентификации в Windows. SPNEGO SPNEGO (сокр. от Simple and Protected GSS-API Negotiation Mechanism - простой и защищенный механизм переговоров по GSS-API) - механизм, который используется для аутентификации клиентского приложения на удаленном сервере в том случае, когда ни одна из сторон не знает, какой протокол аутентификации поддерживает другая сторона. GSS-API (Generic Security Service Application Program Interface - Обобщенный прикладной программный интерфейс службы безопасности) [14.1] предназначен для защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент/сервер. Он предоставляет услуги по взаимной аутентификации осуществляющих контакт партнеров и по контролю целостности и обеспечению конфиденциальности пересылаемых сообщений. Пользователями интерфейса безопасности GSS-API являются коммуникационные протоколы (обычно прикладного уровня) или другие программные системы, самостоятельно выполняющие пересылку данных. Обобщенный интерфейс безопасности GSS-API не зависит от конкретной языковой среды и от механизмов безопасности, обеспечивающих реальную защиту. Последнее обстоятельство позволяет создавать приложения, которые на уровне исходного текста мобильны по отношению к смене механизмов безопасности. Тем самым реализуется открытость прикладных систем и соответствующих средств защиты. На каждом компьютере, где предполагается применять интерфейс безопасности GSS-API, должно быть установлено клиентское программное обеспечение соответствующего механизма защиты. Приложение, использующее GSS-API, локальным образом вызывает необходимые функции, получая в ответ так называемые "токены безопасности". Токен может содержать зашифрованное удостоверение пользователя, электронную подпись или целое зашифрованное сообщение. Приложения обмениваются токенами безопасности, достигая тем самым аутентификации, целостности и конфиденциальности общения. Поскольку коммуникационные аспекты вынесены за пределы GSS-API, он автоматически оказывается независимым от сетевых протоколов. Сетевая мобильность приложений должна обеспечиваться иными средствами. SPNEGO - стандартный псевдо-механизм GSS-API. Псевдо-механизм определяет, какие механизмы GSS-API являются доступными, выбирает один из них и передает ему "право" осуществлять в дальнейшем необходимые операции по обеспечению безопасного взаимодействия приложений. Наиболее известным применением SPNEGO является расширение Microsoft "HTTP Negotiate". Впервые SPNEGO был реализован в Internet Explorer 5.01 и IIS 5.0 с целью реализации возможности SSO (Single Sign-On, "единый вход", "принцип однократной регистрации"), позже переименованной в Integrated Windows Authentication. SPNEGO мог выбирать между протоколами Kerberos и NTLM. Позднее Firefox и Konqueror также стали поддерживать SPNEGO. NTLM Когда Microsoft начала работу над созданием централизованных сетей масштабов предприятия при работе над операционной системой Windows NT, перед разработчиками была поставлена весьма сложная и новая по тем временам задача - реализовать технологии SSO и "One user - one password". "One user - one password" - "один пользователь - один пароль" означает, что у пользователя должен быть единый пароль, используемый для доступа ко всем ресурсам и протоколам сети. Действенные меры защиты не должны затруднять работу пользователей. Например, их следует освободить от необходимости отдельно регистрироваться на каждом ресурсе, используя при этом разные пароли. Кроме того, процесс регистрации не должен сопровождаться длительными задержками при получении доступа. Single sign-on, как отмечалось выше, подразумевает, что этот пароль указывается всего один раз - при входе пользователя в сеть). Необходимо было разработать такую схему аутентификации, которая позволила бы любому сетевому приложению передавать данные аутентификации независимо от сетевого протокола. Это привело к появлению NTLM и NTLMSSP (NTLM Security Service Provider - подсистемы, позволяющей любому клиент-серверному приложению использовать NTLM, ничего не зная о его внутренней структуре). Протокол NTLM относится к семейству challenge-response (запрос-ответ) протоколов. Это означает, что ни пароль, ни его хеш никогда не передаются "как есть": они используются для генерации ответа (response) на случайный запрос (challenge). Аутентифицирующая сторона сравнивает полученный ответ с вычисленным локально. Генерация и проверка запроса и ответа осуществляется не приложениями, а провайдером NTLMSSP. Протокол NTLM имеет много брешей в безопасности. Часть проблем вызвана тем, что Microsoft необходимо было сохранить совместимость с существующими сетями LanManager для MS-DOS и Windows for Workgroups. Другие являются ошибками проектирования, третьи - исключительно криптографические. В настоящее время Microsoft рекомендует в качестве протокола аутентификации использовать Kerberos (см. следующую главу). Тем не менее, в новых версиях Windows он поддерживается и все еще используется, к примеру, на уровне рабочих групп (при отсутствии домена Active Directory). Kerberos Kerberos - протокол аутентификации, разработанный в 1980-х гг. в Массачусетском технологическом институте (MIT - Massachusetts Institute of Technology). Первой операционной системой семейства Windows, реализующей протокол Kerberos [14.2], стала Windows 2000. Сетевая служба Kerberos действует как доверенный посредник, обеспечивая безопасную сетевую проверку подлинности, которая дает пользователю возможность работать на нескольких машинах сети. Kerberos использует криптографию с секретным ключом: как правило, применяются шифры DES или Triple-DES (3DES), хотя в последней версии, Kerberos v5, описанной в документе RFC 1510 [14.4], поддерживаются и другие алгоритмы: так, Windows Vista была выпущена с улучшенной версией протокола Kerberos, позволяющей использовать криптоалгоритм AES. Kerberos версии 5 использует режим СВС (Cipher Block Chaining). CBC [14.3] - это режим шифрования с обратной связью, при котором перед вычислением очередного шифрованного блока открытый текст складывается побитно по модулю 2 с предыдущим шифртекстом. В режиме СВС над открытым текстом и предыдущим шифртекстом выполняется операция XOR и тем самым каждый предыдущий шифрблок используется для модифицирования очередного блока открытого текста. Для аутентификации в службе Kerberos используются удостоверения. Различают два вида удостоверений (credentials): мандаты (tickets) и аутентификаторы (authenticators). Подробно структура различных сообщений Kerberos описана в документе RFC 1510 [14.2], мы ограничимся основной информацией. Мандат используется для безопасной передачи серверу данных о клиенте. Сервер также может проверить, действительно ли мандат был выдан клиенту, который его предъявляет. Мандат Kerberos имеет следующую форму: где - сервер, - клиент, - сетевой адрес клиента, - начало и окончание времени действия мандата, - секретный ключ сервера, - сеансовый ключ для клиента и сервера, - мандат клиента на пользование сервера. Запись здесь и далее обозначает некоторые данные , зашифрованные ключом . Клиент не может расшифровать мандат, т. к. не знает секретного ключа сервера, но он может предъявлять его серверу неограниченное количество раз в течение промежутка от начала до окончания действия мандата. Аутентификатор - некий блок информации, зашифрованный с помощью секретного ключа. Аутентификатор предъявляется вместе с мандатом. Клиент создает аутентификатор каждый раз, когда ему нужно воспользоваться службами сервера. Аутентификатор Kerberos имеет следующую форму: где - сервер, - клиент, - начало и окончание действия мандата, - сеансовый ключ для клиента и сервера, - аутентификатор клиента для сервера. В отличие от мандата, аутентификатор используется только один раз: содержание этого блока данных должно меняться при каждом новом сеансе, иначе злоумышленник может проникнуть в систему, воспользовавшись перехваченным сообщением. Схема работы протокола Kerberos представлена на рис. 14.1 [14.3]. Выделяется 3 основные стадии: Клиент запрашивает у сервера аутентификации мандат на обращение к Серверу выдачи мандатов (Ticket-Granting Server, TGS). В роли сервера аутентификации выступает центр распределения ключей (KDC, Key Distribution Center). KDC направляет клиенту мандат, содержащий уникального сеансового ключа (session key) для предстоящего сеанса. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера (шаги 1-2); Для подключения к конкретному серверу клиент запрашивает у TGS мандат на обращение к серверу. В роли TGS также выступает KDC. Если все в порядке, KDC отсылает мандат клиенту (шаги 3-4); Клиент предъявляет серверу полученный мандат вместе с аутентификатором. Если удостоверение клиента правильно, сервер предоставляет клиенту доступ к службе (шаги 5-6*). Рис. 14.1.  Схема работы протокола Kerberos Запрос мандата на выделение мандата сервера Мандат на выделение мандата сервера Запрос мандата сервера Мандат сервера Запрос услуги Метка времени, зашифрованная сеансовым ключом* *Шаг 6 выполняется, если требуется взаимная аутентификация. Посылая клиенту метку времени, зашифрованную сеансовым ключом, сервер доказывает, что ему известен правильный секретный ключ, и он может расшифровать мандат и аутентификатор.

Безопасная вычислительная база нового поколения

Сложность, разнородность и скорость изменения современных открытых систем противоречит принципам проектирования защищенных систем. Инициатива Microsoft по созданию "Безопасной вычислительной базы нового поколения" (Next-Generation Secure Computing Base - NGSCB) [16.1] нацелена на разработку платформы, обеспечивающей надежное управление доступом и при этом сохраняющей открытость персональных компьютеров. Microsoft объявила о разработке NGSCB в 2002 году. Этот набор технологий, известный ранее под кодовым названием Palladium, подразумевает использование сочетания программных и аппаратных средств, которое должно существенно повысить уровень защищенности ПК. По замыслу авторов проекта, на открытой платформе NGSCB может работать любое программное обеспечение, но необходимы механизмы, которые позволили бы защитить друг от друга операционные системы и приложения, выполняемые на одной и той же машине. Достичь этого можно путем изоляции операционной системы от других процессов и реализации аппаратной и программной поддержки секретности и аутентификации по отношению к локальным и удаленным объектам. Проект NGSCB еще не был реализован в полной мере, не встретив поддержки со стороны корпоративных пользователей и производителей программного обеспечения: необходимым условием применения новых средств защиты было изменение кода существующих систем. Тем не менее, ряд идей, лежащих в основе NGSCB, были реализованы в Windows Vista и Windows Server 2008 и заложили основу для дальнейшего развития проекта доверенной открытой платформы. Windows Vista TPM Платформа NGSCB разрабатывалась в соответствии с новыми требованиями в области безопасности, установленными группой Trusted Computing Group (TCG) [16.4]. TCG была сформирована в 2003 г. с целью разработки и продвижения открытых стандартов на "доверенные вычисления" (trusted computing). В число компаний-основателей входят Advanced Micro Devices, Hewlett-Packard, IBM, Infineon, Intel, Lenovo, Microsoft и Sun Microsystems; в настоящий момент группа насчитывает 135 участников. Основным результатом работы группы на данный момент является спецификация Trusted Platform Module (TPM) [16.3] и связанный с ним документ Trusted Computing Group Software Specification (TSS) [16.2]. Под TPM мы будем понимать не только абстрактную концепцию, но и аппаратный компонент "доверенной вычислительной платформы". TSS - спецификация программного интефейса (API), который должны использовать разработчики для взаимодействия с TPM. "Доверенная вычислительная платформа" - это платформа, которая должна обеспечивать пользователя более высоким уровнем защиты по сравнению с традиционным персональным компьютером. Текущая версия спецификации TPM на момент написания данного курса лекций - 1.2. Эта версия спецификации TPM была опубликована в октябре 2003 г. и с тех пор претерпела ряд изменений. Windows Vista поддерживает только TPM-устройства, совместимые с версией 1.2. Trusted Platform Module (TPM) - микроконтроллер, который предлагает средства для безопасного создания и хранения ключей шифрования. Важно отметить, что микросхема ТРМ имеет встроенную защиту от подделки. TCG рассматривает TPM как основу для построения доверенной вычислительной платформы. Специализированная микросхема TPM, предназначенная для создания мастер-ключа шифрования, который может быть в дальнейшем использован для шифрования других ключей, сгенерированных на уровне пользователя, позволяет обеспечить дополнительную защиту ключей, не полагаясь только на программное обеспечение, которое подвержено уязвимостям (например, ошибкам типа "переполнение буфера" - buffer overflow). TPM позволяет создавать криптографические ключи и зашифровывать их таким образом, что они могут быть расшифрованы только тем же самым модулем TPM. Данный процесс, называемый "сокрытием" (wrapping) ключа или "привязкой" ("binding") ключа, помогает защитить ключ от раскрытия. В каждом модуле TPM хранится секретный ключ, называемый ключом корневого хранилища (Storage Root Key, SRK), который создается при инициализации модуля и никогда не станет доступен любому другому компоненту системы, программному обеспечению, процессу или пользователю. Ключ SRK используется для защиты ключей, которыми шифруются данные в на диске. При очистке модуля SRK стирается, что приводит к отмене права владения модулем TPM и отключению модуля TPM. "Запечатывание" (sealing) ключа в модуле TPM позволяет создавать ключи, которые будут не только зашифрованы, но и привязаны к определенной системной конфигурации. Такой тип ключа может быть расшифрован только в том случае, если характеристика платформы, на которой его пытаются расшифровать, совпадает с той, на которой этот ключ создавался. При использовании "запечатанного" ключа и BitLocker (см. секцию "Средство шифрования диска Windows BitLocker") можно обеспечить блокировку данных до тех пор, пока они не будут перенесены на компьютер с подходящей аппаратной или программной конфигурацией. Согласно концепции TCG, доверенная вычислительная платформа должна обладать следующими возможностями: Защищенные функции (Protected capabilities); Мониторинг целостности (Integrity monitoring); Хранение показателей целостности (Integrity storage); Оповещение о целостности (Integrity reporting). Защищенные функции - набор команд, которые могут применяться для доступа к секретным данным, размещенным в защищенных хранилищах. Мониторинг целостности - это набор данных о состоянии системы и метрик, позволяющих отражающих состояние защищенности системы: например, должна быть возможность определить, подвергались ли данные несанкционированному доступу. Метрики могут храниться в логах, но хеш-значения состояния целостности системы, полученные при помощи алгоритма с помощью алгоритма SHA1, записываются в регистры конфигурации платформы (platform configuration registers, PCR), которые представляют собой перезаписываемые или неперезаписываемые ячейки памяти самого TPM. Назначение функции оповещения о целостности очевидно из названия. Аттестация ("attestation") позволяет с использованием специальных 2048-битных ключевых пар (Attestation Identity Key, AIK), хранимых в TPM, подписывать при помощи алгоритма RSA сведения о параметрах и конфигурации платформы и на основании этих данных проверять надежность системы. Существует 4 типа аутентификации [16.5]: TPM использует ключ AIK, чтобы подписать некие данные, хранимые внутри самого модуля, подтверждая, что он активен и может проверить сам себя; TPM использует ключ AIK, чтобы подписать данные в регистрах PCR, что позволяет оповещать 3-ю сторону о целостности системы ("удаленная аттестация"); Платформа подтверждает свою идентичность, предоставляя данные, которые использовались при создании ключа AIK; Платформа использует непереносимые ключи, хранимые в TPM, для аутентификации устройства (например, с целью проверить, что система, осуществляющая доступ к данным, обладает соответствующими правами). "Корни доверия" (roots of trust) - это заслуживающие доверия компоненты системы, которые позволяли бы верифицировать состояние других частей системы. Обычно различают 3 корня доверия: Корень доверия для измерения (Root of trust for measurement, RTM); Корень доверия для хранения (Root of trust for storage, RTS); Корень доверия для оповещения (Root of trust for reporting, RTR). RTM, как правило, представляет собой процессор, работающий под контролем центрального корня доверия для измерения (Core root of trust for measurement, CRTM), где CRTM - это набор инструкций, выполняемых вычислительной машиной при осуществлении измерений. Важнейшее понятие доверенной платформы - "доверенный строительный блок" (Trusted Building Block, TBB), который включает 2 компонента - CRTM и TPM. Оба эти компонента физически расположены на материнской плате и не должны заменяться. На рис.16.1 показана связь TBB и BIOS с архитектурой Windows Vista. Во-первых, важно отметить, что TSS располагается на более высоком уровне, чем драйвер TPM и базовые службы TPM (TPM Base Services, TBS). Драйвер TPM предоставляется производителем TPM, TBS является компонентом Windows Vista, а TSS представляет собой реализацию одноименной спецификации, разработанной группой TCG. Таким образом, TCG определила спецификации для трех компонентов доверенной платформы, расположенных на разных уровнях. Необходимо отметить несколько аспектов, специфичных для архитектуры Windows Vista TPM. В отличие от обычных драйверов, драйвер TPM необходим еще до загрузки операционной системы, использующей механизм безопасной загрузки: поэтому он интегрирован в код BIOS. Кроме того, Microsoft в качестве посредника между высокоуровневыми приложениями и драйвером TPM (по сути - аппаратным обеспечением TPM) предлагает использовать TBS. TSS предоставляет приложениям третьих фирм стандартный API-интерфейс для взаимодействия с TPM. Интересные данные по тестированию TPM и служб TPM в Windows Vista приводятся в [16.6]. Рис. 16.1.  Архитектура Windows Vista TPM Secure Startup (Безопасная загрузка) Каждый раз при загрузке системы контроль в первую очередь получает CRTM: пока не выполнятся инструкции из этого набора, управление не может быть передано другому коду. Цель такого подхода - дать CRTM возможность определить надежность каждого компонента системы, прежде чем передать ему управление. Последовательность загрузки (с момента запуска CRTM) проиллюстрирована на рис. 16.2 (подробное описание см. в [16.5]): CRTM производит измерения целостности оставшейся части кода BIOS. Если CRTM устанавливает, что измерения подтверждают идентичность системы, контроль передается BIOS. BIOS производит измерения целостности конфигурационных установок платформы и других необходимых параметров. Если BIOS устанавливает, что измерения подтверждают идентичность системы, контроль передается менеджеру загрузки Windows Vista, который производит свои измерения целостности как часть процесса безопасной загрузки. Когда контроль получает механизм загрузки BitLocker, он производит измерения целостности загрузочного сектора NTFS и менеджера загрузки. Как только BitLocker убедится в том, что уже выполненный код и код, которому нужно передать управление, заслуживает доверия, он распечатывает ключ и расшифровывает содержимое диска, а затем передает управление ядру операционной системы. Задача проверки целостности кода переходит к Windows Vista. Подобно предшествующим компонентам, Vista производит измерения целостности кода; при обнаружении несоответствия с ранее сохраненными значениями загрузка блокируется. Убедившись в том, что целостность кода не нарушена, операционная система загружается. Рис. 16.2.  Процесс загрузки доверенной платформы: (A) - согласно спецификации TCG; (B) - в интерпретации Microsoft Средство шифрования диска Windows BitLocker Средство шифрования диска BitLocker (прежнее название - Full Volume Encryption/FVE - "полное шифрование тома") обеспечивает защиту данных на аппаратном уровне. Шифрование всего системного тома Windows позволяет предотвратить утечку или раскрытие данных с утерянного, украденного или неправильно утилизированного компьютера. Технология BitLocker помогает организациям исполнять государственные постановления и законы, в которых требуется использование высоких стандартов обеспечения безопасности и защиты данных (например, закон Сарбэйнса-Оксли [16.7] и HIPAA [16.8]). Шифрование диска BitLocker является новой возможностью, которая доступна в Windows Vista и Server 2008. Оптимальным хранилищем для ключа шифрования с точки зрения функции BitLocker является микросхема доверенного платформенного модуля TPM версии 1.2. Если технология развертывается в системе, не имеющей такой микросхемы, то ключ шифрования записывается на запоминающее устройство USB [16.9]. BitLocker использует алгоритм AES с ключом 128 бит [16.10]. Взлом такого шифра методом полного перебора с использованием самого мощного персонального компьютера уйдет более 100 триллионов лет [16.5]. При современном уровне развитии вычислительной техники можно гарантировать, что на ближайшие 2 тыс. лет данные, зашифрованные алгоритмом AES-128 в безопасности. Однако нельзя с уверенностью утверждать, что за это время не появится более эффективных методов взлома таких шифров или что в AES не обнаружатся лазейки, которые позволят осуществлять поиск ключа более эффективно, чем методом полного перебора. Для повышения надежности длину ключа можно увеличить до 256 бит с помощью групповых политик или через интерфейс, предоставляемый провайдером инструментария управления Windows (Windows Management Instrumentation, WMI) для BitLocker. Более подробная информация по криптоалгоритмам, используемым BitLocker, изложена в [16.11]. Защита данных с помощью шифрования BitLocker усиливается за счет шифрования системного раздела и проверки целостности компонентов, используемых на раннем этапе загрузки. Каждый сектор тома шифруется отдельно, при этом часть ключа шифрования определяется номером этого сектора. В результате два сектора, содержащие одинаковые незашифрованные данные, будут в зашифрованном виде выглядеть по-разному, что сильно затрудняет определение ключей шифрования путем записи и шифровки заранее известных данных. Не шифруются три элемента [16.9]: загрузочный сектор, поврежденные сектора, уже отмеченные как нечитаемые, метаданные тома. Метаданные тома состоят из трех избыточных копий данных, используемых BitLocker, включая статистическую информацию о томе и защищенные копии некоторых ключей расшифровки. Эти элементы не требуют шифрования, поскольку не являются уникальными, ценными или позволяющими определить личность. Перед применением шифрования BitLocker использует алгоритм, называемый диффузором (diffuser) [16.10]. В результате его применения даже мельчайшее изменение исходного текста приводит к абсолютному изменению всего сектора зашифрованных данных. Это серьезно затрудняет определение ключей или дешифровку. Использование технологии BitLocker - это один из возможных подходов к проблеме гарантированного уничтожения информации на жестком диске. Как известно (см., например, [16.12]), эта задача является очень важной: даже использование специализированных средств не всегда предохраняет от риска восстановления данных злоумышленником по остаточной информации. Чтобы избавиться от данных, достаточно избавиться от ключа, которым они были зашифрованы: несмотря на то, что данные при этом физически останутся на жестком диске, для злоумышленника они уже не будут представлять интереса. На первый взгляд, совместное использование EFS и BitLocker противоречит золотому правилу криптографии: "Если вы шифруете что-то дважды - вы, очевидно, не понимаете смысл своих действий" [16.5]. Действительно, в стандартном сценарии шифрования данные шифруются симметричным криптоалгоритмом с использованием ключа, который затем зашифровываются на открытом ключе пользователя, имеющего право доступа к этим данным. В этом случае мы имеем 2 ключа и 2 шага шифрования - тем не менее, к каждому объекту шифрования (данным и симметричному ключу) криптоалгоритм применяется только один раз. Какой смысл дополнительно шифровать данные, которые уже защищены при помощи BitLocker? Однако заметим, что пользователь, обладающий ключом шифрования BitLocker, автоматически получает доступ ко всему содержимому диска. EFS предоставляет более гибкий подход и позволяет управлять доступом на уровне пользователей. Очевидным минусом комбинирования технологий является снижение производительности системы.

Системы управления идентичностью

Управление идентичностью Технологии на базе Web-сервисов и языка XML являются на сегодняшний день самым распространенным механизмом построения распределенных систем. В связи с этим необходимы стандарты безопасного обмена данными вне границ защищаемого периметра. В рамках этого подхода в центре внимания находятся не обороняемые машины или сети, а передаваемые документы либо другие сведения о действиях, людях или предприятиях [13.9]. Одной из ключевых задач обеспечения безопасности взаимодействия сервисов является идентификация участников информационного обмена. Все цифровые удостоверения обладают одним общим важным свойством: при передаче по сети любое цифровое удостоверение представляется некоторым маркером доступа (security token). Маркер доступа [13.10] - это набор байтов, содержащих информацию о цифровом удостоверении (одно или более утверждений (claims), каждое из которых содержит некоторую часть данных удостоверения). Помимо утверждений с именем, фамилией, домашним адресом и т. д., в маркеры доступа могут входить утверждения с уязвимой информацией - например, номерами банковских карт. Большинство маркеров доступа сопровождается некоторой информацией, позволяющей аутентифицировать предъявителя удостоверения. Самым простым, но не самым надежным подходом является сопровождение утверждений паролем. Более правильный подход предполагает использование ЭЦП. Для представления маркеров используется множество разных форматов. Например, сертификаты X.509 и удостоверения Kerberos разрабатывались не как средство передачи произвольного набора утверждений, но могут переносить некоторую информацию, полезную для некоторых цифровых удостоверений. Маркеры, созданные с помощью SAML [13.11] - стандарта промышленной группы OASIS - могут содержать любой необходимый набор утверждений. В работе [13.9] приводится список самых популярных стандартов, используемых при управлении идентичностью: WS-Security [17.1, 17.2, 17.3, 17.4] поддерживает безопасность протокола SOAP, конфиденциальность и целостность сервисов; согласован с другими средствами, такими как сертификаты X.509, Kerberos и SAML. Security Assertion Markup Language (Язык разметки для систем обеспечения безопасности, SAML) [13.11]: служит для обмена подтверждениями об аутентификации и авторизации между доменами. В русском языке не установился общепринятый перевод термина SAML; поэтому его трактуют и как "язык разметки утверждений безопасности", и как "язык разметки допуска к информации", и как "язык разметки для инфраструктуры безопасности". Каждый из переводов по-своему корректен, и в совокупности они верно передают смысл. Спецификация Liberty Alliance 1.0 уточняет SAML. XML Access Control Markup Language (XACML) [17.5], язык разметки управления доступом: является расширением XML для создания конструкций, служащих для автоматизации авторизации и управления доступом к информации. Средства XACML определяют те директивы, которые формируются и передаются для управления доступом. Extensible Rules Markup Language (XrML) [17.6]: язык управления правами собственности в мультимедиа, порожден движением Digital Rights Management и в какой-то мере составляет конкуренцию языку XACML. XML Encryption и XML Digital Signature [17.9].: спецификации цифровой подписи и криптографии в XML-документах. Service Provisioning Markup Language (SPML) [17.7]: задуман как средство описания вспомогательных данных, необходимых для установления отношений между сервисами. Разрабатывается ассоциацией OASIS для обмена данными между кооперирующимися организациями (см. также www. openspml. org). XML Key Management Specification (XKMS) [17.8] служит стандартом для инфраструктуры открытых ключей XKISS (XML Key Information Service Specification) и регистрационной спецификации XKRSS (XML Key Registration Service Specification). Спецификация призвана упростить обмен ключами по схеме, предложенной Диффи и Хеллманом. Средства безопасной аутентификации через Passport .NET Passport - это система управления идентичностью, разработанная Microsoft, позволяющая аутентифицироваться на различных веб-сайтах с использованием одного и того же удостоверения. Онлайновая служба .NET Passport позволяет осуществлять навигацию по сайтам, поддерживающим Passport, без необходимости отдельной регистрации на каждом из них. Эта технология единого унифицированного входа (Single Sign-On, SSO) экономит время и усилия пользователей при ведении электронной бизнес-деятельности и доступе к разнообразным ресурсам через Интернет. Для идентификации пользователя .NET Passport использует уникальное 64-битное число, которое для повышения безопасности зашифровывается. Система позволяет пользователю хранить персональную информацию в профиле .NET Passport и предоставлять эту информацию сайтам-участникам. Сайт-участник системы Passport (participating site) - любой Web-сайт, на котором реализован единый вход. NET Passport. Для работы с большинством функций .NET Passport и для доступа к базовым профилям пользователей сайт-участник должен быть зарегистрирован. Чтобы избежать автоматической повторной аутентификации (silent reauthentication), сайты-участники могут требовать от пользователя заново вводить свое регистрационное имя и пароль независимо от текущего состояния аутентификации этого пользователя. Заставляя его повторно вводить свои учетные данные, сайт запрещает доступ любому, кто не знает соответствующего имени и пароля. Для защищенной передачи учетных данных и профилей пользователей на сайты-участники применяется специальный cookie, в терминологии .NET Passport называемый билетом (ticket, ticket cookie). Профиль пользователя в системе .NET Passport может включать следующую информацию: Адрес электронной почты; Имя и фамилию; Место жительства; Предпочтения относительно языка; Часовой пояс; Пол; Дату рождения; Профессию. Кроме того, в профиле есть "кошелек" - средства для безопасного управления телефонными номерами, данными кредитных карточек и счетами, избавляющие пользователей от необходимости заново вводить эти данные каждый раз при посещении сайтов-участников. У стандартного входа через Passport и других механизмов проверки есть ряд общих проблем с безопасностью. Во-первых, уязвимость перед лобовыми атаками, при которых подбираются подходящие учетные данные. Чтобы уменьшить уязвимость перед атаками такого рода, на серверах входа для .NET Passport реализован механизм замедления (slow-down), минимизирующий риск осуществления атаки с подбором паролей. После пяти подряд неудачных попыток входа пользователя просят подождать пять минут. Это не блокирует пользователя, но ставит серьезную преграду на пути у злоумышленников, пытающихся получить доступ к какой-нибудь учетной записи. Повторение пакетов - другой тип атаки, при которой перехватывается транзакция входа по открытому HTTP-соединению. Несмотря на шифрование билета и профиля, служба Passport со стандартным входом уязвима перед атаками с повторением пакетов, т. к. обмен ими осуществляется через открытое HTTP-соединение. Перехватив соответствующие пакеты и повторив их, хакер может подменить пользователя на тот период, пока не истечет срок действия его билета регистрации (login ticket). Защищенный вход (secure sign-in) - функциональность .NET Passport версии 2.0 (и выше), которая обеспечивает более высокую безопасность по сравнению со стандартным входом, расширяя его возможности за счет дополнительных средств и заметно уменьшая вероятность входа хакеров по учетной записи, взломанной атакой с повторением пакетов или по словарю. Функции защищенного входа устраняют уязвимость, присущую стандартному входу. Фактически реализация защищенного входа требует применения SSL, специальных параметров для функций входа через Passport и браузера с поддержкой HTTPS (этот протокол поддерживается почти всеми современными браузерами). Защищенный вход может быть основан на СОМ-объекте Passport. Manager или на объекте Passport Identity, предоставляемом Framework. Windows Cardspace В работе приводится основная причина, по которой система Passport не получила широкого распространения: ни владельцы сайтов, ни пользователи в общем случае не были заинтересованы в Microsoft как посреднике в их взаимодействии. Цифровые удостоверения предоставляются и будут предоставляться разными источниками. Таким образом, нужен способ согласованного использования нескольких систем цифровых удостоверений. Необходима метасистема, специализирующаяся на идентификации. Если система защиты сумеет использовать и генерировать подтверждения об авторизации или аутентификации в стандартном формате, появится возможность создать федеративную модель управления идентичностью (Identity Management), объединяющую всю распределенную систему. В Windows вводятся новые возможности, призванные сделать метасистему реальностью. Windows CardSpace, изначально известная как "InfoCard", позволяет любому приложению Windows, включая и Internet Explorer, и продукты сторонних производителей, обеспечить своим пользователям единый способ работы с цифровыми удостоверениями. CardSpace как часть .NET Framework 3.x/4.x доступна в Windows начиная с XP / Server 2003. Наиболее важными можно назвать четыре аспекта технологии Windows CardSpace : Поддержка любой системы цифровых удостоверений; Единообразный пользовательский контроль над цифровым удостоверением; Замена основанной на паролях веб-регистрации; Повышение доверия пользователей удостоверениям удаленных приложений. Цель новой модели удостоверений Framework 3.0 на основе заявок заключается в том, чтобы уменьшить зависимость от конкретных типов учетных данных, не понижая при этом уровень безопасности приложения. Программирование при помощи модели удостоверений .NET Framework 3.0 позволяет обрабатывать не только билеты Kerberos и сертификаты, но также и маркеры языка SAML, что прокладывает путь к некоторым интересным архитектурам удостоверений, включая объединенное управление удостоверениями. Информационная карта (information card, InfoCard) представляет цифровое удостоверение, которое пользователь потенциально может предоставить участвующей стороне. С точки зрения пользователя, информационная карта - это визуальное отображение цифрового удостоверения на экране компьютера. Однако для CardSpace информационная карта - это, фактически, XML-документ, хранящийся на компьютере пользователя, работающем под управлением Windows. В информацию на карте входят данные о том, у какого издателя удостоверений необходимо запросить маркер доступа для этого удостоверения, какие типы маркеров может выпустить этот издатель удостоверений, и какие именно утверждения могут содержаться в этих маркерах. Выбирая определенную карту, пользователь, фактически, принимает решение запросить определенный маркер доступа с определенным набором утверждений, созданный определенным издателем удостоверений. Информационная карта создается некоторым издателем удостоверений, обязательно снабжается цифровой подписью и поставляется вместе с сертификатом издателя удостоверений. Эта подпись используется для проверки достоверности удостоверения самого издателя удостоверений. Содержимое информационной карты помогает пользователям разумно выбрать цифровое удостоверение, а CardSpace - сопоставить карту с требованиями участвующей стороны и получить соответствующий маркер доступа от издателя удостоверений, выпустившего эту карту. В политике издателя удостоверений должен быть оговорен порядок проведения аутентификации запросов маркеров доступа. Издатель удостоверений может по выбору поддерживать любой вариант аутентификации пользователей (или все варианты) из четырех, поддерживаемых в первой версии CardSpace: Имя пользователя/пароль (что может потребовать от пользователя введения пароля при каждом использовании карты); Удостоверение Kerberos; Сертификаты X.509 v3 (или на базе программного обеспечения, или со смарт-карт); Маркеры доступа SAML, созданные издателем самостоятельно формируемых удостоверений. При передаче в маркере доступа уязвимая информация обычно кодируется, что делает ее недоступной как для мошенников, так и для CardSpace. Уязвимая информация никогда не включается в информационную карту и, следовательно, не хранится на компьютере пользователя. Windows CardSpace - часть .NET Framework 3.0, и приложения, использующие его, являются приложениями Windows, однако совместимые с CardSpace средства выбора удостоверений также реализуются и на других платформах и устройствах.