Проблема аутентификации доступа к информационным ресурсам является на сегодня весьма актуальной. Защиты с помощью пароля нередко оказывается недостаточно, ее требуется усиливать. Операционная система Microsoft Win-dows 2000 позволяет усовершенствовать процесс аутентификации пользователей с помощью смарт-карт, но при этом требуется наличие устройства чтения - ридера. Есть и другие варианты, и один из них предполагает использование электронных USB-ключей eToken компании «Аладдин», которые являются полнофункциональным аналогом одновременнно смарт-карт и устройств чтения/записи для работы со смарт-картами.
Смарт-карта или eToken
Термин «смарт-карта» используется для обозначения устройств размером с кредитную карточку, обладающих различными возможностями: карты для хранения данных, бесконтактные карты и карты на основе интегральных микросхем (integrated circuit cards, ICC). Все они отличаются друг от друга, а также от традиционных карт с магнитной полосой, обычно используемых для обслуживания банковского счета.
На персональном компьютере и в среде Windows 2000 используются карты на основе интегральных микросхем, так как они могут выполнять сложные криптографические операции. Смарт-карта - это, по существу, миниатюрный компьютер с ограниченной памятью и возможностью обработки данных, заключенный в форму пластиковой кредитной карточки. Обмен данными между смарт-картой и приложением, работающим на компьютере, осуществляется через полудуплексный последовательный интерфейс, управляемый приемным устройством с помощью соответствующего драйвера. Устройства для чтения смарт-карт достаточно разнообразны и могут подсоединяться к компьютеру с помощью интерфейса RS-232, PCMCIA или USB.
eToken - это первый полнофункциональный аналог смарт-карты, выполненный в виде брелка. Он напрямую подключается к компьютеру через порт Universal Serial Bus (USB) и не требует наличия дорогостоящих устройств считывания или других дополнительных устройств. Более подробная информация о моделях eToken приведена во врезках «Познакомимся поближе» и «Преимущества eToken перед смарт-картами».
Смарт-карты являются важнейшим компонентом инфраструктуры открытых ключей (PKI), интегрированной Microsoft в Windows 2000. Смарт-карты расширяют возможности программной аутентификации. Аналогичными функциями обладает и eToken, который обеспечивает:
- физическое хранилище сертификатов, надежно защищенное от взлома;
- изоляцию криптографических операций с личными ключами от операционной системы;
- возможность использования одних и тех же сертификатов и ключей на работе, дома или в другом месте за счет мобильности физического хранилища.
eToken может использоваться для аутентификации пользователя в домене Windows 2000 в трех случаях:
- интерактивный вход в систему (interactive logon), при котором задействуются каталог Active Directory, протокол Kerberos версии 5 и сертификат открытого ключа;
- удаленный вход в систему (remote logon), использующий сертификат открытого ключа, протокол Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) для идентификации удаленного пользователя, учетная запись которого хранится в каталоге Active Directory;
- аутентификация клиента (client authentication) - процесс взаимной идентификации пользователя и домена с помощью сертификата открытого ключа, сопоставленного с хранящейся в каталоге Active Directory учетной записью.
Пользователям, которые не занимаются администрированием, проще носить с собой eToken, а не запоминать пароли. К этой категории пользователей обычно относится значительная часть служащих компании. Такими пользователями могут быть внештатные сотрудники, поставщики, подрядчики и все, кому не приходится управлять компьютером или сетью.
Поскольку eToken может применяться для идентификации по SSL в дополнение к интерактивной и удаленной регистрации, эффект от внедрения eToken будет еще больше, так как значительной части персонала не придется использовать пароли. Однако пользователям с расширенными полномочиями и администраторам приходится выполнять операции, которые предполагают вторичную аутентификацию с запросом имени пользователя, имени домена и пароля, и, следовательно, здесь eToken не подойдет. В частности, eToken не может применяться при операциях включения компьютера в домен, установке или удалении Active Directory, настройке службы удаленного доступа.
Интерактивный вход в систему
При подключении eToken к USB-порту Windows 2000 «понимает», что теперь, вместо имени пользователя, имени домена и пароля, необходимо запросить персональный идентификационный номер (Personal Identification Number, PIN), см. Экран 1. Это событие эквивалентно нажатию сочетания клавиш Ctrl-Alt-Del, инициирующему процедуру входа в систему с использованием пароля. Однако PIN, который указывается в диалоговом окне при входе в систему, обеспечивает аутентификацию только по отношению к eToken, но не к домену.
|
| Экран 1. Окно ввода PIN-кода к eToken. |
Сертификат открытого ключа, хранящийся в защищенной памяти eToken, используется для аутентификации в домене с применением протокола Kerberos версии 5 и его расширения PKINIT.
Запрос на вход в систему
После того как пользователь вводит в окне регистрации PIN, операционная система определяет, может ли пользователь быть идентифицирован и аутентифицирован на основе предъявленной им удостоверяющей информации (PIN и eToken). При запросе на вход в систему сначала происходит обращение к локальной системе безопасности (LSA), которая передает запрос пакету аутентификации Kerbe-ros, запущенному на клиентском компьютере. Пакет Kerberos посылает запрос службе аутентификации Key Distribution Center (KDC), функционирующей на контроллере домена, для аутентификации и получения билета TGT (билет начального уровня - Ticket Granting Ticket). В состав запроса к службе аутентификации (Authentication Service, AS), в те его поля, которые предшествуют идентификационным, помещается сертификат пользователя, обнаруженный в памяти eToken. Удостоверение, включенное в эти поля, заверяется цифровой подписью с использованием личного ключа пользователя так, чтобы KDC могла проверить запрос, отправленный владельцем сертификата.
Проверка сертификата
Перед тем как удовлетворить запрос, служба AS, прежде всего, должна проверить происхождение сертификата и убедиться в том, что он заслуживает доверия. KDC использует CryptoAPI, чтобы проследить путь от пользовательского сертификата к сертификату корневого центра сертификации (CA). Если KDC по тем или иным причинам (например, корневой сертификат недействителен, невозможно найти родительские сертификаты или определить, не аннулирован ли сертификат) окажется не в состоянии построить допустимую цепочку сертификатов, то она вернет сообщение об ошибке и откажет в удовлетворении запроса.
KDC также должна проверить, уполномочен ли центр сертификации, выдавший сертификат, выдавать сертификаты для аутентификации в домене. В Windows 2000 для аутентификации с помощью eToken источником сертификатов должен быть корпоративный центр сертификации, который опубликован в Active Directory. Это требуется для предотвращения выдачи сертификатов в пространстве имен другого домена ложными центрами сертификации, действительными только в одной из иерархий. Хотя предпринять подобного рода атаку исключительно сложно, так как это зависит от получения ложным центром сертификации прав на издание от законного родительского центра сертификации, решение запрашивать корпоративный CA, опубликованный в Active Directory, было принято во избежание самой возможности вторжения.
Проверка цифровой подписи
После успешной проверки сертификата пользователя служба KDC применяет CryptoAPI для проверки цифровой подписи удостоверения. Проверка подписи выполняется с помощью открытого ключа из пользовательского сертификата для подтверждения того, что запрос исходит от владельца открытого ключа. Поскольку сертификат был обнаружен в защищенной памяти eToken, а удостоверение подписано с использованием личного ключа, хранящегося опять же в eToken, цифровая подпись должна быть законна. После проверки подписи служба KDC должна проверить отметку времени в удостоверении, чтобы убедится в том, что запрос не является атакой, использующей перехваченные в сети данные.
Поиск учетной записи и билет TGT
Убедившись, что пользователь является тем, за кого себя выдает, и что сертификат может быть использован для аутентификации в домене, служба KDC запрашивает в каталоге домена учетную запись. KDC ищет учетную запись пользователя в Active Directory по основному имени пользователя (User Principal Name, UPN), которое указано в поле альтернативного имени (Subject Alternative Name) в пользовательском сертификате открытого ключа. Учетная запись, которую KDC получает от службы каталога, используется для формирования билета TGT. Билет TGT будет включать идентификатор безопасности пользователя (Security ID, SID), SID всех групп, членом которых пользователь является. Список SID внесен в поля данных авторизации TGT.
KDC генерирует специальный сеансовый ключ для защиты дальнейшего взаимодействия клиента с контроллером и помещает его в созданный билет TGT. Затем KDC шифрует TGT, используя специальный ключ, хранящийся в учетной записи krbtgt. Сеансовый ключ зашифровывается с помощью открытого ключа из сертификата пользователя и включается в соответствующее поле ответа KDC. Служба KDC подписывает ответ, используя свой личный ключ, чтобы клиент был уверен, что ответ получен от KDC, которой можно доверять.
Клиент сначала проверяет подпись KDC, формируя путь сертификации от сертификата KDC к доверенному корневому CA, а затем использует открытый ключ KDC, чтобы проверить подпись ответа. После получения ответа KDC клиент с помощью своего личного ключа расшифровывает сеансовый ключ. Полученный TGT в дальнейшем используется уже стандартным протоколом Kerberos для запросов сеансовых билетов для доступа к ресурсам домена.
Автономная регистрация в системе (Offline Logon)
Когда пользователь отсоединен от сети или контроллер домена недоступен, пользователь должен сохранить возможность зарегистрироваться на своем компьютере автономно. Такая возможность обеспечивается с помощью паролей путем сравнения хешированного пароля, сохраняемого локальной системой безопасности, с хешем удостоверения, которое пользователь предъявляет Graphical Identification and Authentication (GINA) в процессе автономной регистрации в системе. Если сравниваемые данные совпадают, пользователь получает доступ к локальной машине.
В случае применения eToken автономный вход в систему требует ввести личный ключ пользователя для расшифровки дополнительных удостоверений, зашифрованных с помощью открытого ключа пользователя. Если у пользователя есть несколько ключей eToken, дополнительные удостоверения должны быть расшифрованы и соотнесены с хешем удостоверения для того, чтобы гарантировать пользователю возможность доступа независимо от того, какой eToken используется.
Аутентификация клиента
Поскольку поддержка eToken интегрирована в CryptoAPI, протоколам Secure Sockets Layer (SSL) и Transport Layer Security (TLS) не нужно «знать» что-либо об eToken для того, чтобы работать с ним. Роль eToken в процессе аутентификации клиента состоит в том, чтобы подписать часть данных протокола на начальной стадии сеанса обмена данными по протоколу SSL. Поскольку закрытый ключ, соответствующий сертификату открытого ключа, хранится в памяти eToken, подобный метод аутентификации является более строгим, так как применение закрытого ключа требует от владельца eToken подтверждения прав доступа и к eToken, и к домену. Кроме того, операции с закрытым ключом, выполняемые на начальной стадии сеанса обмена данными, реализуются eToken таким образом, что закрытый ключ никогда не передается компьютеру или в локальную сеть.
Взаимная аутентификация
Оба протокола, SSL 3.0 и TLS 1.0, поддерживают взаимную аутентификацию, что для клиента означает возможность проверить подлинность сервера, а для сервера - подлинность клиента.
Аутентификация сервера происходит, когда клиент подтверждает подлинность сервера, проверяя криптографическую подпись в сертификате сервера, а также всех промежуточных сертификатов CA.
Аутентификация клиента сервером реализована так же, как и аутентификация сервера, но проверка сертификатов осуществляется в противоположном направлении. Сервер проверяет криптографическую подпись в сертификате клиента, а также все промежуточные сертификаты CA.
Как только аутентификация клиента выполнена, сервер должен установить контекст безопасности с соответствующей авторизацией, которая определяет, какие ресурсы сервера разрешено использовать клиенту.
Авторизация
При аутентификации клиента в Win-dows 2000 с применением открытых ключей используются данные из сертификата клиента для получения информации о его правах доступа в домене.
Когда установлен сеанс SSL или TLS, провайдер безопасного канала (secure channel provider) прежде всего пытается, исходя из UPN сертификата, найти учетную запись пользователя в каталоге домена. UPN включено в сертификат в поле альтернативного имени субъекта (Alternative Subject Name), оно определяет точное имя учетной записи пользователя (префикс) и имя домена, в котором расположена учетная запись (суффикс). Так же как при входе в систему с помощью eToken на основе Kerberos, источник сертификатов должен иметь полномочия на выпуск сертификатов для домена, чтобы им можно было доверять при идентификации и проверке полномочий.
Если нет соответствия UPN или СА не уполномочен издавать сертификаты для аутентификации в домене, провайдер пытается запросить в каталоге поиск учетной записи, у которой атрибут Alternate Security Iden-tities содержит явное указание на соответствие сертификату клиента. Явное указание сертификата в учетной записи пользователя требует дополнительных действий со стороны ад министратора. Соответствие сертификату клиента может быть основано либо на имени источника, либо на источнике и субъекте в сертификате. Учетная запись может иметь один или более связанных с ней сертификатов, что упрощает применение одной учетной записи несколькими пользователями. Сертификат не может соответствовать нескольким учетным записям, хранящимся в каталоге домена. Аутентификация не будет выполнена, если сертификат соответствует более чем одной учетной записи.
Удаленный доступ
Поддержка расширяемой аутентификации для удаленных пользователей в Windows 2000 обеспечивается службой удаленного доступа RAS. Сервер удаленного доступа поддерживает протокол аутентификации EAP и обеспечивает модулям различных производителей возможность поддержки разнообразных методов аутентификации (см. Экран 2).
|
| Экран 2. Выбор метода аутентификации. |
Windows 2000 содержит встроенный модуль для поддержки eToken, что позволяет обеспечить строгую аутентификацию удаленных пользователей. Замечу, что удаленный доступ к системе фактически означает две аутентификации: на сервере RAS и в сети.
Первая аутентификация завершается подтверждением аутентификации сер-вера RAS клиентом и установлением соединения между клиентом и сервером. В результате клиенту сопоставляются некоторые политики RAS и атрибуты учетной записи. Атрибуты учетной записи применяются индивидуально и включают такие свойства, как права доступа, режимы обратного вызова (callback options), статические маршруты (static routes) и т. д. Политики RAS определяют основные принципы взаимодействия сервера с клиентом. Это позволяет управлять пользователями, обеспечивая соответствие свойств подключения, группового членства, профиля и т. д.
Вторая аутентификация относится к домену и использует TLS в качестве протокола аутентификации вместо Kerberos. Аутентификация в домене с использованием EAP-TLS очень похожа на аутентификацию по протоколу SSL, за исключением того, что сертификат открытого ключа должен содержать UPN, соответствующее учетной записи, хранящейся в доменном каталоге Active Directory.
Политики безопасности
В домене Windows 2000 имеется несколько типов политик, определяющих процедуры работы с eToken.
Обязательное использование eToken. Windows 2000 поддерживает на уровне отдельного пользователя политику учетных записей, требующую обязательного использования eToken для интерактивной регистрации в системе (см. Экран 3).
|
| Экран 3. Установка обязательного использования eToken. |
Это означает, что, как только политика применена к учетной записи, воспользоваться паролем для интерактивной регистрации или регистрации из командной строки будет невозможно. Политика действует только для интерактивной регистрации в сети, но не для удаленного доступа, когда используется другая политика, установленная на сервере удаленного доступа.
Режим обязательного использования eToken, обусловленный политикой учетной записи при интерактивной регистрации, должен быть установлен для пользователей, являющихся членами группы Users и применяющих eToken для регистрации в домене Windows 2000.
Отсоединение eToken. Когда пользователь надолго отходит от компьютера во время активного сеанса, предполагается, что он либо выходит из системы, либо блокирует компьютер. В противном случае компьютер открыт для злоумышленника, имеющего физический доступ к нему.
Политика извлечения смарт-карты (или eToken) - это локальная политика, действие которой распространяется на компьютер, а не на учетную запись пользователя.
Решение об установке политики отсоединения eToken зависит от потребностей корпорации и от того, как пользователи работают с компьютерами. В тех ситуациях, когда работа ведется в помещениях, куда могут зайти посторонние, использование такой политики настоятельно рекомендуется (см. Экран 4). Если же у каждого пользователя есть отдельный компьютер, возможно, нет необходимости устанавливать вышеописанную политику, и можно ограничиться применением хранителей экрана и тому подобных мер.
|
| Экран 4. Выбор режима блокировки при отсоединении eToken. |
Как и в случае многих других политик безопасности, усиление защиты сопряжено с дополнительными неудобствами в работе.
А что делать, если пользователь забыл свой eToken дома? Возможность войти в здание по временному пропуску существенно отличается от того, что нужно для регистрации на компьютере для исполнения служебных обязанностей. Здесь может быть несколько вариантов.
Можно выдать временный eToken с сертификатом короткого срока действия, например на один день.
Или же можно не устанавливать политику обязательного использования eToken для интерактивной регистрации, а вместо нее установить политику, требующую использования длинного пароля, который выдается пользователям только в крайнем случае, а впоследствии отменяется.
Персональные идентификационные номера
В то время как пароли обладают очевидными недостатками, в частности создаются пользователями на основе легко запоминаемых ассоциаций, PIN-коды eToken не подчиняются тем же правилам, что и «надежные пароли» (strong passwords), поскольку eToken не подвержены классическим атакам путем подбора слов.
Проблемы запоминания PIN-кода не существует, поскольку eToken блокирует многократные попытки ввести ошибочный PIN-код, аппаратно реализуя задержку (примерно 1 с) между вводами PIN-кода.
Поскольку PIN-код никогда и ни в какой форме не передается непосредственно по сети, атаки с использованием перехваченной информации чрезвычайно затруднены необходимостью физически владеть самим ключом eToken (в отличие от имитации сетевого пакета при атаках, базирующихся на пароле).
Благодаря способности eToken противостоять вышеописанным типам атак, часто менять PIN-код не требуется.
Станция регистрации eToken
Станция регистрации смарт-карт (то же относится и к eToken) работает как часть корпоративной службы центра сертификации в Windows 2000 Server и Windows 2000 Advanced Server. Она поддерживает централизованную выдачу eToken. Станция регистрации смарт-карт использует шаблоны сертификатов для определения того, какую информацию включать в тот или иной сертификат.
Для eToken существует два шаблона:
- eToken для регистрации (не может использоваться для защиты электронной почты);
- eToken пользователя.
Чтобы выдавать сертификаты для eToken, на предприятии должна существовать станция регистрации смарт-карт (eToken). Это требование обязательно, поскольку по умолчанию пользователи домена не могут регистрировать сертификаты eToken, выданные корпоративным ЦС Windows 2000.
|
| Экран 5. Работа со станцией регистрации. |
Доступ к сертификатам eToken ограничен администратором домена, если только он не модифицировал права доступа к шаблонам, чтобы обеспечить остальным группам пользователей возможность регистрации. Это необходимо для предотвращения атак в том случае, когда пользователь покидает свое рабочее место, не завершив сеанса работы с системой или не заблокировав ее, и некто использует активный сеанс для регистрации сертификата eToken под видом пользователя (возможно, не подозревающего об этом).
Для использования станции регистрации eToken Windows 2000, кто-то из сотрудников должен выполнять функции регистратора. Для того чтобы поддержать эти функции, корпоративный центр сертификации может выдать такому сотруднику сертификат регистратора. Данный сертификат обеспечивает более широкие полномочия по сравнению с другими, поскольку служащий с сертификатом регистратора имеет возможность зарегистрировать сертификат eToken любого пользователя домена, включая администратора. Поэтому рекомендуется, чтобы по умолчанию права доступа к шаблону сертификата регистратора предоставляли возможность регистрации только избранным сотрудникам.
Кроме того, желательно отключить выдачу сертификата этого типа в центре сертификации, за исключением особых случаев или когда необходимо автономное (offline) применение CA. По умолчанию, разрешения на доступ к сертификатам регистраторов установлены только для администраторов доменов.
Внедрение eToken
Использование в организации eToken позволяет существенно повысить безопасность сети за счет совершенствования методов аутентификации. К тому же пользователям больше не придется запоминать множество учетных записей (login) и паролей к различным ресурсам сети и приложениям. Нужно запомнить одно-единственное число - PIN-код к своему ключу eToken.
Максим Подлесный - руководитель отдела разработок компании Aladdin Software Security R.D. C ним можно связаться по адресу: it@aladdin.ru.
Познакомимся поближе
eToken имеет до 64 Кбайт защищенной энергонезависимой памяти (EEPROM) и может использоваться как портативный контейнер для хранения секретных данных (ключей шифрования, кодов доступа, сертификатов). eToken имеет уникальный серийный номер (ID) и может использоваться как электронный идентификатор (ключ) для аутентификации пользователя. eToken поддерживает работу и интегрируется со всеми основными системами и приложениями, использующими технологию Public Key Infrastructure (PKI).
eToken R2
eToken R2 имеет аппаратно реализованный алгоритм шифрования DESX со 120-разрядным ключом.
eToken Pro
eToken Pro, в отличие от R2, имеет дополнительный чип смарт-карты, аппаратно реализующий алгоритм шифрования RSA/1024, 3DES (TripleDES), SHA-1 и генератор личных (Private) ключей, никогда не покидающих микросхему.
В eToken Pro используется микросхема SLE66C Infineon, обеспечивающая исключительно высокий уровень безопасности, сертифицированный по ITSEC LE4.
В eToken Pro используется файловая система Siemens CardOS/M4, поддерживающая неограниченную иерархию объектов и файлов.
eToken RIC
В eToken RIC аппаратно реализованы криптографические алгоритмы шифрования ГОСТ 28147-89 (имеет сертификат соответствия ФАПСИ), включая диверсификацию и формирование сессионного ключа, а также DES и Triple DES.
Преимущества eToken перед смарт-картами
Помимо функций смарт-карт eToken обладает дополнительными возможностями:
- не требует дорогостоящего устройства считывания и лишних проводов. Большинство устройств чтения смарт-карт подключается к компьютеру через последовательный порт RS-232, разъем PCMCIA Type II или шину USB. eToken напрямую подключается к компьютеру через USB-порт и не требует наличия дорогостоящих устройств считывания или других дополнительных устройств;
- имеет больше памяти (до 32 Кбайт) и может хранить несколько сертификатов (семь и более). Криптографические смарт-карты имеют ограниченный объем памяти, обычно от 2 до 16 Кбайт. Поскольку память пользуется большим спросом и довольно дорого стоит, производители карт ограничивают объем памяти, доступный одному приложению;
- различные приложения могут использовать один и тот же eToken. eToken поддерживает стандарт PC/SC и эмулирует смарт-карту и устройство считывания, что позволяет легко встраивать его как в существующие приложения, так и в новые. При работе с разными приложениями может использоваться уже имеющийся eToken. Необходимости в покупке дополнительных ключей нет. Потребуется лишь доплатить за лицензию на использование нужной программы;
- возможна одновременная работа с несколькими брелками eToken.