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

Двухфакторная аутентификация RSA SecurID

Алексей Аминов (lexam@dol.ru), Алексей Гавриленко (gavrilenko@dol.ru)

Введение

Средства и методы реализации технологий «жесткой» двухфакторной аутентификации постоянно изменяются в зависимости от спектра приложений и условий применения. Наиболее динамично эти изменения проявляются в сфере мобильных устройств (PDA, телефоны и т.д.). В работе рассмотрены особенности функционирования одной из наиболее популярной на сегодня схемы ACE/SecurID и описана реализация нового варианта аутентификатора для мобильного телефона.

Протокол аутентификации ACE (клиент/сервер)

Протокол ACE разработан с целью согласования и централизованного хранения пользовательских атрибутов и ключевой информации (UID и стартовые векторы генерации токен-кода) и активирования механизма SecurID. Протокол также согласовывает работу ACE-сервера и ACE-агентов и работает поверх протокола UDP. ACE-сервер включает в себя программу-демон, базу данных и программное обеспечение для администрирования.

Осуществление процедуры доступа пользователя к системе, защищённой SecurID, весьма просто - вводится имя своей учётной записи (login или UID) и пасскод, который состоит из PIN – числа, которое знает только пользователь, и токен-кода – числа, которое генерируется раз в минуту на токене (брелке или другом устройстве)1. При генерации используется хэш-функция, речь о которой пойдёт ниже. Далее, эти данные проверяются на сервере аутентификации, на котором есть возможность восстановить истинные значения, соответствующие именно этому пользователю, и по результатам проверки либо предоставляется доступ к ресурсу, либо нет. Схематически работу протокола можно изобразить на диаграмме2:

Работа протокола начинается при попытке пользователя получить доступ к защищённому ресурсу (sshd, httpd и др.) и функционально описывается следующим образом:

  • ACE-клиент сообщает ACE-серверу об этом с помощью «hello-сообщения»
  • ACE-сервер отвечает, добавляя в ответе временную метку, T
  • ACE-клиент предлагает пользователю ввести пасскод – пин + токен-код
  • Пользователь отсылает соответствующий пасскод, P
  • ACE-клиент считает хэш от своего IP-адреса, временной метки и пасскода : F2(IP,T,P) и разделяет его на 4 части : wp[1-4]
  • ACE-клиент посылает UDP-пакет, включающий имя пользователя и зашифрованную первую часть значения хэш-функции (wp[1]) ACE-серверу. Шифрование осуществляется по алгоритму DES, а ключ заранее генерируется ACE-клиентом и отсылается ACE-серверу при регистрации.
  • ACE-сервер расшифровывает пакет и считает F2(IP, T, L), где L - ожидаемый пасскод. Далее ACE-сервер также как и клиент разделяет хэш на 4 части и сверяет первую часть с пришедшей. Если проверка проходит успешно, то считается, что пользователь успешно прошёл аутентификацию. В случае, когда wp[1] сервера отличается от wp[1] клиента, то ACE-сервер считает F2, соответствующий значениям предыдущего и последущего токен-кода, т.е. F2(IP,T,L+1) и F2(IP,T,L-1).
  • Если аутентификация прошла успешно, то ACE-сервер отсылает соответствующее сообщение ACE-клиенту, шифруя его на ключе wp[2]. Если получаемые сервером значения wp[1] не совпадают с полученным от ACE-клиента, то сервер пытается найти соответствие ещё для величин в пределах временного строба L-10 – L+10. Он может отослать сообщение с просьбой ввести следущий токен-код. Так же сервер может отослать сообщение с ошибкой, зашифрованное на ключе wp[1].

    Так как протокол не привязывается к конкретной платформе, то для различных платформ могут быть необходимы собственные реализации ACE-клиента(агента), поэтому наряду с серверной частью, в пакет RSA SecurID входит SDK(Software Development Kit), при помощи которого можно самому написать агента под нужную платформу. Но этого в большинстве случаев делать не нужно, так как для многих систем они уже существуют, в частности, под все популярные операционные системы: Windows NT,2k,2k3,XP, Solaris 8,9, HP-UX 10,11, AIX 4.x, 5, как для локального так и удалённого доступа; а так же под распространённые сервисы: Apache, IIS, SSH и др.

    На основе технологии RSA SecurID реализован механизм SSO (single-sign-on), позволяющий пользователю производить идентификацию только один раз в течение сессии, а не при каждом обращении к новому сервису.

    Хэш-функция в алгоритме SecurID

    Идея достаточно простая: для генерации токен-кода используются две компоненты: составляющая, зависящая от времени и часть, которая неизвестна посторонним (секрет). Таким образом, общая схема генерации кода может быть выражена формулой y = H (k, t), где y – токен-код, k – секрет, t – время, H – некоторая функция, к которой должен быть предъявлен ряд требований. Одно из основных требований – необратимость, т.е., H должна быть такова, чтобы по значениям y и t нельзя было бы определить секрет k. Таким образом, H – это хэш-функция, значение которой зависит от ключа k.

    В алгоритме SecurID используется 64-битный3 секрет (seed) и 64-битное значение времени, которое получается с помощью расширения 24-х битного значения (в аппаратной реализации), или 32-х битного значения (в програмной реализации). Сначала значения времени и секрета «перемешиваются» и только после этого данные используются в четырёх циклах функции, зависящих от ключа. После прохождения каждого цикла, на основе предыдущего ключа и выходных данных цикла формируется новый ключ. После прохождения всех циклов, данные снова перемешиваются с текущим значением ключа и преобразуются в десятичное значение токен-кода (пары токен-кодов). Блок-схема этого алгоритма изображена на Рис 2:

    В настоящее время наряду с описанным выше алгоритмом, используется так называемая AES-схема, то есть алгоритм, ядром которого является хэш-функция, построенная на базе стандарта симметричного шифрования AES.

    Несколько слов о криптостойкости алгоритма SecurID4. Не так давно были опубликованы несколько статей5, в которых обсуждается проблема слабости хэш-функции и ее примитивов в алгоритме SecurID. В результате исследований, проведённых авторами этих статей, выявился ряд недостатков алгоритма. В частности, предложена атака, которая позволяет восстановить секрет токена намного быстрее, чем с помощью полного перебора. Однако, для того, чтобы осуществить атаку, необходимо располагать достаточно большой статистической базой выдаваемых токеном значений. Например, для того, чтобы достичь вероятности успеха атаки в 10%, необходимо непрерывно собирать значения токен-кода в течении двух месяцев, а чтобы увеличить вероятность до 35%, необходим целый год. Для накопления статистических данных, можно, например, установить перед токеном камеру, а по истечении года обработать информацию, записанную на камеру. Такой способ осуществим лишь в теории, так как на практике, злоумышленник не будет иметь физического доступа к токену на столь большой срок. Кроме того, трудности возникнут и с обработкой такого объёма информации. Другим вариантом накопления статистики является перехват аутентификационных пакетов в сети. В этом случае, время накопления необходимой информации увеличится в сотни раз. Например, если пользователь аутентифицируется по токену 1000 раз в год, то для достижения вероятности успеха атаки 35% необходимо собирать информацию в течение 525 лет. А если при аутентификации закрывать трафик, например, с помощью SSL/TLS, то этот способ вообще не применим.

    Таким образом, атака осуществима лишь теоретически и в реальности не возможна. Кроме того, при соответствующих организационных мерах, вероятность успеха атаки сводится к нулю:

  • Увольняемый из компании сотрудник лишается токена, а вопрос о повторном использовании токена тщательно изучается.
  • Утерянный токен выводится из употребления вообще и выдаётся новый токен.

    Следует повторить, что все вышеперечисленные рассуждения касаются только «классических» аппаратных токенов и никак не распрастраняются на AES-токены, которые абсолютно неуязвимы к указанным типам атак.

    Реализация алгоритма SecurID на мобильных устройствах

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

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

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

    Простейшим вариантом такого эмулятора может быть мидлет (java-приложение для сотового телефона), в который ключ «зашит» на этапе компиляции при инициализации пользователя в системе. При этом должна гарантироваться уникальность и непредсказуемость ключа. В этом случае для каждого пользователя нужно компилировать отдельный эмулятор, и распространять его какими-либо внешними средствами. Компиляцией эмулятора может заниматься программа-скрипт, которая собирает мидлет по запросу пользователя. Основное преимущество такого подхода – минимизация байт-кода программы, а недостаток – использование внешних средств доставки и необходимость защиты от перехвата. Другой вариант – свободно распространяемое приложение-оболочка, одинаковая для всех пользователей. Эта оболочка своими средствами (например, через SMS, GPRS или WAP) забирает ключ с какого-либо центрального сервера, инициализируется им и далее работает так же как и предыдущий вариант. Нужно отметить, что в этом варианте необходимо использовать протокол, гарантирующий защиту передачи ключа с сервера на телефон. Также необходимым условием является защита мидлета от считывания с телефона.

    Перспективной является также идея поместить эмулятор токена на SIM-карту. В этом случае генератор будет работать и на устройствах, не поддерживающих технологию Java. Дело в том, что смарт-карты содержат как собственное хранилище информации, так и собственный процессор, и поэтому могут быть использованы для генерации токен-кода. Этот способ является интересным ещё и потому, что апплет-эмулятор токена на SIM-карте дополняет набор средств (сертификаты) для доступа в сети Wi-Fi.

    Заключение

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

    Появляется всё больше приложений для телефонов, в том числе, и приложений, требующих жесткой аутентификации (например, какие-либо банковские и/или платежные приложения). Таким образом, технология SecurID может быть интегрирована в эти приложения.

    Вариант эмулятора токена на SIM-карте дополняет ряд других сервисов, обеспечивающих доступ в Wi-Fi при использовании спектра механизмов, определяемой из совокупности IEEE 802.1Х, в частности PEAP-OTP и др.


    1Существуют также и другие варианты, например, токены, в которые пользователь должен ввести пин, и только после этого генерируется паскод.
    2Ek(x) означает зашифрованый на ключе k текст x; F2() – хэш-функция от аргументов.
    3В последних модификациях токенов SecurID применяется 128-битный seed
    4Речь идёт о «классическом» алгоритме SecurID
    5A. Biryukov, J. Lano, B. Preneel “Cryptanalysis of the Alleged SecurID Hash Function”; Scott Contini, Yiqun Lisa Yin “Improved Cryptanalysis of SecurID”

  • Перейти в начало страницы