Нефть и песок О стали Компрессор - подбор и ошибки Из истории стандартизации резьб Соперник ксерокса - гектограф Новые технологии производства стали Экспорт проволоки из России Прогрессивная технологическая оснастка Цитадель сварки с полувековой историей Упрочнение пружин Способы обогрева Назначение, структура, характеристики анализаторов Промышленные пылесосы Штампованные гайки из пружинной стали Консервация САУ Стандарты и качество Технология производства Водород Выбор материала для крепежных деталей Токарный резец в миниатюре Производство проволоки Адгезия резины к металлокорду Электролитическое фосфатирование проволоки Восстановление корпусных деталей двигателей Новая бескислотная технология производства проката Синие кристаллы Автоклав Нормирование шумов связи Газосварочный аппарат для тугоплавких припоев
Главная страница / Архитектура отрасли

Аутентификация через мобильный телефон



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

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

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

Процедура доступа пользователя к системе, защищенной SecurID, весьма проста: вводятся имя своей учетной

записи (login или UID) и пасскод, который состоит из PIN-числа, которое знает только пользователь, и токен-кода – числа, которое генерируется раз в минуту на токене (брелоке или другом устройстве)1. При генерации используется хэш-функция, речь о которой пойдет ниже. Затем эти данные проверяются на сервере аутентификации, на котором есть возможность восстановить истинные значения, соответствующие именно этому пользователю, и по результатам проверки либо предоставляется доступ к ресурсу, либо нет (рис. 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-сервер, как и клиент, разделяет хэш на четыре части и сверяет первую часть с пришедшей. Если проверка проходит успешно, то считается, что пользователь успешно прошел аутентификацию. Если wp [1] сервера отличается от wp [1] клиента, то ACE-сервер считает F2, соответствующий значениям предыдущего и последущего токен-кода, т. е. F2 (IP,T,L+1) и F2 (IP,T,L-1);

• если аутентификация прошла успешно, то ACE-сервер отсылает соответствующее сообщение ом значения 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 и др.

Главная страница / Архитектура отрасли