РешенияПродуктыКонсалтингПоддержкаКонтакты
Перейти на предыдущую страницу  Перейти на главную страницу  Версия для печати  

Стандарты в схемах аутентификации на основе одноразовых паролей

Автор:
Ляпер Виталий Сергеевич
инженер-стажер
ООО "Компания "Демос"

    На сегодняшний день одноразовые пароли (OTP - One-Time Password), получили широкое распространение, как надежное и удобное средство для аутентификации. Характерным примером может служить решение SecurID от компании RSA Security - двухфакторная аутентификация на основе пользовательских данных (PIN или пароль) и токенкода.
    Одноразовый пароль обычно представляет собой сгенерированную последовательность символов, т.н. токен-код, (в целях удобства зачастую просто цифр), которая периодически меняется и имеет достаточно короткое время жизни, т.е. по прошествии некоторого временного отрезка, когда комбинация сменится, предыдущая будет уже непригодна для аутентификации. Алгоритм, по которому токен-код генерируется, синхронизован с сервером таким образом, что для проверки подлинности кода проверяющей стороне не нужна никакая дополнительная информация. Принцип работы такого токена основан на вычислении односторонней функции от времени и секретного значения, и в случае компрометации токен-кода его становится невозможно использовать через несколько минут после генерации. Технически генераторы одноразовых паролей могут быть выполнены в различном виде: брелок с экраном, на котором отображается токен-код , java card applet или midlet, тогда в качестве форм-фактора будут использованы смарт-карта и телефон соответственно1.
    Поскольку изначально предполагается, что одноразовые пароли главным образом используются для аутентификации пользователей и, по возможности, должны быть всегда "под рукой", то для их реализаций можно выдвинуть ряд требований, при соблюдении которых они становятся удобным и надежным средством аутентификации:
  • Лёгкость использования. OTP-токен должен иметь простой и понятный интерфейс, как для пользователя, который будет читать значение токен-кода и вводить его при аутентификации (либо использовать механизм типа PKCS #11), так и для сервера, который будет производить ресинхронизацию токена, когда это понадобится.
  • Безопасность алгоритмов и протоколов. Алгоритмы, используемые для генерации токен-кода должны удовлетворять требованиям невозможности получить по токен-коду защищенную информацию, например, инициализирующий вектор, кроме того все криптографические операции должны выполняться внутри защищенной среды, предоставляя наружу только уже готовый к использованию результат. Инициализация токена и его ресинхронизация в свою очередь должны использовать безопасные соединения для передачи инициализирующей информации, зная которую взломщик может имитировать работу токена.
  • Гибкость реализации. Требование мобильности токена подразумевает возможность его реализации на базе различных форм-факторов (брелки, телефоны, sim-карты).
  • Экономичность аппаратной реализации. Данный фактор является скорее само-собой разумеющимся, нежели жестоко требуемым.

    Компания RSA Security, силами своего подразделения RSA Laboratories в рамках работ по стандартизации существующих схем работы с одноразовыми паролями, организовала рабочую группу, занимающуюся созданием открытых стандартов механизмов одноразовых паролей - OTPS. В результате усилиями специалистов ряда лабораторий и компаний из различных стран проведена работа по унификации (стандартизации) схем одноразовых паролей, механизмов и протоколов, результаты которой по итогам нескольких рабочих совещаний приведены на http://www.rsasecurity.com/rsalabs/node.asp?id=2816 и http://www.rsasecurity.com/rsalabs/node.asp?id=2987.
    На текущий момент доступны восемь документов, специфицирующих OTP, четыре из них находятся в состоянии draft версий. Эти документы полностью покрывают основные аспекты использования одноразовых паролей такие, как:

  • инициализация OTP атрибутов в присоединенном токене;
  • получение OTP из токена;
  • пересылка и проверка OTP.
На рисунке показан полный цикл жизни одноразового пароля, а также протоколы, используемые на определенных этапах жизненного цикла. Рассмотрим их более подробно.



Инициализация токена. CT-KIP

    CT-KIP это протокол типа клиент-сервер для инициализации и конфигурации криптографического токена с разделяемыми ключами. Он предназначен для использования в коммуникационных и компьютерных системах на основе связанных криптографических токенов. Протокол достаточно удобен и гибок, поскольку не требует ни возможностей схем частных ключей, ни наличия инфраструктуры открытых ключей.
    Версия 1.0 этого протокола опубликована в декабре 2005 г. и описывает 4-х проходовый клиент(токен)-сервер протокол инициализации, в котором обе стороны вносят вклад в энтропию генерируемых ключей. Коротко её суть в следующем:

  • Клиент CT-KIP передает серверу информацию о том, какой токен будет инициализирован, поддерживаемую версию протокола, а также для каких алгоритмов шифрования будут сгенерированы ключи. Также передается информация об алгоритмах MAC(Message Authentication Code), поддерживаемых токеном.
  • В соответствии с полученной от клиента информацией сервер CT-KIP передает клиенту некоторое случайное значение RS. Вместе с этим случайным значением, сервер передает клиенту: информацию о том, ключи для какого алгоритма шифрования будут сгенерированы, информацию о том, каким шифром будут защищаться данные, передаваемые на следующих проходах протокола (при использовании асимметричной схемы шифрования, передается открытый ключ сервера). Длина RS может зависеть от того, для какого алгоритма шифрования генерируется ключевой материал.
  • Токен генерирует случайное значение RC и шифрует его, используя выбранный на предыдущем этапе алгоритм шифрования с ключом K, который является либо открытым ключом сервера, либо разделяемым секретом, присланным с его же стороны. Длина RC может зависеть от типа выбранного ключа. Токен отправляет зашифрованное RC серверу. Кроме того, токен вычисляет ключ KTOKEN заданного типа на основе значений RC и RS и ключа K.
  • Сервер расшифровывает значение RC и вычисляет ключ KTOKEN заданного типа на основе двух значений RC и RS, а также ключа K. После чего сервер ставит в соответствие токену значение KTOKEN и сохраняет его. В последствии эта пара может быть использована для проверки или расшифровки данных, полученных от токена.
  • После того как сервер запомнит информацию о ключе токена, он посылает подтверждение, которое содержит идентификатор сгенерированного ключа, а также иногда дополнительную настроечную информацию.
  • После того как получено подтверждение от сервера, токен ставит в соответствие идентификатор ключа с его значением и сохраняет полученную конфигурационную информацию, если таковая имеется.
    Модификация протокола CT-KIP не прекращается, в марте 2006г. вышла версия 1.1, в которой добавлены одно- и двух- проходовые варианты для упрощения схем распределения ключей, новая схема вычисления MAC, а также xml-схема самого протокола. В целом аналогов протоколу CT-KIP просто нет, в дальнейшем он сможет стать удобным средством для инициализации ключевого материала, не только в приложении к OTP.


Генерация. OTP-PKCS#11 и MS CryptoAPI

    Данные стандарты описывают объекты, процедуры и механизмы как для PKCS#11, так и для MS CryptoAPI, которые применяются для инициализации и проверки сгенерированных токенов. Основным моментом можно считать то, что эти механизмы предоставляют схему доступа к связному токену для приложений в режиме совместимости, что существенно облегчает задачу подключения приложения к токену без использования специального API (third-party).
    Механизмы PKCS#11 опубликованы в декабре 2005г. , MS CryptoAPI находится в стадии final draft.
    На рисунке показано как PKCS#11 интегрируется в приложение, которому требуется аутентификация с использованием OTP-токенов.

    В данном случае мы воспользуемся примером связанного аппаратного токена, однако программные реализации токенов имеют аналогичный механизм интеграции. Приложение вызывает процедуру C_Sign, чтобы получить значение одноразового пароля от токена. В нашем примере приложение затем передает полученное значение некоторому Client API, которое в свою очередь уже пересылает его по сети серверу аутентификации. В качестве Client API могут быть использованы стандартные протоколы аутентификации такие, как RADIUS (RFC 2865) или EAP (RFC 3748), возможно также использование других протоколов.
    В целом протокол OTP-PKCS#11 специфицирован довольно неплохо, и его использование не вызывает затруднений.


Транспорт. OTP-TLS и EAP-POTP

    EAP - набор протоколов, широко используемых для аутентификации сторон в сетевом доступе, в частности, на основе WiFi, удаленном доступе PPP и в IPSEC. Реализация обычно состоит из станции, точки доступа (NAS) и сервера аутентификации.
    Обычно работа протокола EAP сводится к посылке в NAS атрибутов, которые затем перенаправляются на сервер аутентификации. К особенностям исполнения протокола EAP в применении к одноразовым паролям, т.е. протокола EAP-POTP, можно отнести следующие: EAP-POTP определяет метод, который позволяет программно использовать OTP- токен, осуществляет взаимную аутентификацию сторон и генерирует ключевой материал. При этом не используется туннелинг. В целом EAP-POTP дополняет все семейство протоколов EAP.
    На рисунке показана для примера типовая схема аутентификации с использованием EAP, с указанием всех протоколов, применяемых в ней.

    Протокол TLS (Transport Layer Security) широко используется для обеспечения защиты сессий не только при работе в Интернете, но и в других видах сессионного доступа. Данный протокол использует значительное многообразие криптографических методов и шифрсюитов (ciphersuits). В OTP-TLS TLS используется в соединении с т.н. Pre-Shared Key (PSK) шифрсюитами (RFC 4279). Главными моментами в протоколе OTP-TLS является то, что он определяет вывод PSK из OTP, а также то, что в протоколе определены несколько новых расширений для TLS в зависимости от жесткости OTP. На данный момент часть материалов по OTP-TLS уже опубликована.


Проверка. OTP-WSS-Token, OTP Validation Service.

    Часть спецификации, касающаяся валидации OTP на сегодняшний день находится в наименее проработанном состоянии и будет, скорее всего, существенно дополняться и расширяться в самое ближайшее время.
    OTP-WSS-Token используется для OTP аутентификации в схемах по обработке запросов к доверенной стороне для веб-сервисов. В данном протоколе используются xml-кодированные OTP объекты, которые содержат аутентификационные атрибуты. Пример такого токена:

    Функционально это аналог OASIS Web Services Security2 - пользовательский профиль, но привязанный к OTP. Важным моментом в OTP-WSS-Token является то, что могут быть использованы различные типы токенов, в том числе time-based, challenge-based, counter-based, которые могут активироваться либо с сервера, либо с клиента.
    OTP Validation Service - веб-сервис между взаимодействующими сторонами и сервером проверки OTP для определения аутентичности запросов. Основная функциональность сервиса заключается в отправке OTPToken'ов к валидатору и получении ответа yes/no. OTP Validation Service поддерживает большое множество OTP методов, с помощью которых становиться возможным воспроизвести ряд функций, таких, как ресинхронизация требуемого OTP компонента с аутентифицирующим сервисом и управление валидирующим сервисом. Также в сервис включена поддержка защиты сообщений (подписание, шифрование).
    В заключение хотелось бы упомянуть о том, что нынешняя спецификация OTP - это довольно серьезный шаг в развитии технологии. Она полностью покрывает весь жизненный цикл одноразовых паролей, кроме того спецификация доступна для широкого круга пользователей и является бесплатной.
    Разработки в рамках существующей спецификации ведутся в виде взаимодействия и дискуссии через mailing list и рабочие группы.
    В результате на сегодняшний день появилась реальная альтернатива закрытым "патентованным" OTP-стандартам, что в итоге резко понижает стоимость решений на базе одноразовых паролей для конечного пользователя. Кроме того сложившаяся ситуация работы с открытыми стандартами приводит к минимизации ошибок реализации, более быстрым и адекватным нововведениям, а также более простой интеграции в существующие системы. И наконец, то обстоятельство, что удалось выработать формат представления механизмов OTP на основе хэш функций в виде свободном от конкретного варианта используемого алгоритма, означает, что при сохранении функциональности механизмов OTP и протоколов его использования конкретные реализации могут и должны быть выполнены в нашем случае на базе отечественного криптографического стандарта ГОСТ Р 34.11.


1    Мобильный телефон на сегодняшний день может выступать в качестве платформы для приложений, в таком же качестве может быть использована и смарт-карта, которая по сути своей является небольшим, но вполне полноценных компьютером, для которого можно писать приложения используя, например, подмножество языка Java - JavaCard Framework. Приложения на Java для смарт-карт носят название Java Card Applet. В случае использования как платформы мобильного телефона с поддержкой Java, а точнее версии J2ME (Java 2 Micro Edition), приложения носят название MIDlet. SIM-карта обычного мобильного телефона является смарт-картой, на которой можно запускать Java-приложения, таким образом она может быть использована для реализации на ней токена.
2    OASIS Web Services Security - стандарт разработанный для безопасной передачи данных между веб-сервисами. В WSS для передачи данных используются SOAP-сообщения, к которым добавлены security-токены, кроме того для обеспечения безопасности используются такие технологии, как XML Digital Signature, XML Encryption , X.509 Certificates. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
Перейти в начало страницы