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

Отличительная особенность службы SMS — гарантированная доставка сообщения адресату. Послание — рано или поздно — дойдет до адресата: система автоматически выявляет факт неудачной попытки соединения, запоминает сообщение и хранит его до тех пор, пока связь с получателем не восстановится.

Для организации службы SMS (рис. 1) создается центр обработки сообщений (Short Message Service Center, SMSC). Он получает сообщения от отправителя сообщений (Short Message Entity, SME), в качестве которого может выступать сервер или мобильное устройство, и выполняет все функции, связанные с промежуточным хранением сообщений и контролем их доставки мобильным пользователям. Помимо SMSС имеется еще шлюзовое устройство (Short Message Service Gateway, SMSG), обеспечивающее взаимодей?ствие сервера с элементами сетевой инфраструктуры (центр коммутации MSC, реестры собственных и обслуживаемых абонентов HLR и VLR), интерфейс со службами голосовой и электронной почты, а также связь с внешними для данной сети источниками сообщений, например, центрами обработки сообщений других операторов.

Рис. 1. Архитектура службы SMS

Для доставки сообщения выполняются запросы к реестрам абонентов и сообщение перенаправляется в домашнюю сеть абонента, а затем и непосредственно на мобильный телефон получателя; обратно возвращается сообщение о статусе доставки.

Суммарный размер сообщения может достигать 163 байт, а само сообщение содержит: тип сообщения (2 бита); флаги атрибутов: будут ли еще сообщения, есть ли обратный путь, наличие заголовка, сообщать ли статус (4 бита); адрес отправителя сообщения (2-12 байт); протокол (1 байт); схема кодирования (1 байт); метка времени от SMSC (7 байт); длина поля данных (1 байт); поле данных (до 140 байт).

В описанной процедуре доставки сообщение проходит как по внутренним сетям оператора связи, так и по открытым каналам (радиоканал, Internet). Тем не менее, передаваемые данные можно защитить.

Инфраструктура мобильной сети обеспечивает идентификацию абонента и обеспечение конфиденциальности передаваемых данных путем шифрования трафика при передаче по открытым сетям (рис. 2). Эти особенности службы коротких сообщений дают возможность использовать SMS как устойчивый и защищенный транспортный механизм для аутентификации. Рассмотрим схему строгой аутентификации, реализованную с помощью SMS, а также сравним области применения различных схем строгой аутентификации.

Рис. 2. Пример взаимодействия компонентов для доставки сообщения

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

  • слабая схема (одиночный фактор, например, типовой пароль или PIN-код);
  • строгая схема (два и более факторов, например, токен плюс PIN-код).

Обычно реализация строгой схемы подразумевает предъявление чего-то, принадлежащего пользователю (токен, смарт-карта, мобильный телефон, КПК и т.д.), или чего-то, известного пользователю (например, пароль или PIN-код).

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

Технология RSA SecurID построена на процедуре генерации одноразового пароля (One-Time Password, OTP). Генерируемый токен — это псевдослучайная величина, вычисляемая как функция от секретного начального вектора генерации и времени, отображаемая на дисплее (6-8 знаков) и изменяющаяся каждые 60 секунд. В настоящее время к собственному алгоритму компании RSA Security для генерации добавлена реализация на основе стандарта AES с 128-разрядным начальным вектором генерации токена.

При входе в систему пользователь дополняет текущее число на токене своим секретным PIN-кодом и вводит их как один код (так называемый, passcode). Система отсылает сформированный код серверу аутентификации, который проверяет его путем симметричной генерации части passcode. Результат аутентификации посылается обратно в систему, которая в соответствии с ним предоставляет доступ или отказывает в нем. Такой подход дает возможность строить многовариантные схемы аутентификации и авторизации доступа в различные информационные ресурсы в зависимости от требуемых параметров жесткости, целевого назначения, удобства и стоимостных характеристик.

Гибкость сервиса означает учет особенностей конкретного клиентского устройства и разнообразие методов управления полномочиями пользователей. Так, если необходимо универсальное средство контроля доступа удаленных пользователей, то стоит воспользоваться токенами SeсurID. Для штатных сотрудников офиса, которым нужен повседневный доступ на основе системы единого входа (single-sign-on, SSO), лучше подойдут смарт-карты или USB-токены. Для реализации однократного или редкого доступа удобнее использовать доставку однократного пароля OTP посредством отправки SMS на мобильный телефон. Если матрица прав пользователей меняется, то единая система управления сервисом аутентификации позволяет просто и быстро изменить схему полномочий доступа пользователя, что, собственно, и является залогом гибкости и скорости в обслуживании средств обеспечения безопасного доступа к контролируемым ресурсам (см. сравнительную таблицу использования таких средств).

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

Решение по доставке атрибутов одноразового пароля на мобильный телефон, предложенное компанией RSA Security, включает два основных программных компонента — сервер аутентификации и агент, устанавливаемый на защищаемый ресурс. Для подключения к сети GSM и передачи текстовых сообщений SMS по протоколу SMPP используется специальный модуль расширения (plug-in). Никакого дополнительного аппаратного и программного обеспечения на рабочем месте конечных пользователей не требуется.

Схема предоставления доступа зарегистрированному пользователю весьма проста (рис. 3). При входе на Web-портал, защищенный посредством RSA Mobile, вводится имя и пароль; после этого система ищет номер мобильного телефона, соответствующий имени абонента, и пересылает на этот телефон одноразовый код доступа в виде SMS-сообщения. Пользователь вводит код и получает доступ к требуемому ресурсу.

Рис. 3. Схема двухфакторной аутентификации RSA Mobile

Проведенные испытания показали, что код доступа доставляется по назначению менее чем за 6 секунд. Доставку кода также возможно осуществлять при помощи электронной почты (протокол SMTP) или каких-либо иных портативных телекоммуникационных устройств. Прототипы этой системы аутентификации успешно прошли испытания в Европе, Азии и Соединенных Штатах. Крупные организации (например, банки) уже сейчас заключают соглашения с операторами мобильных сетей для того, чтобы с помощью SMS-сообщений осуществлять рассылку клиентам уведомлений — например, о текущем состоянии их счетов.

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

Компанией «Демос» было проведено тестирование всех технологических аспектов функционирования компонентов системы RSA Mobile и отлажены конфигурации их взаимодействия со службой SMS-сообщений компании МТС. Полученные результаты хорошо согласуются с заявленными параметрами: задержка доставки SMS-токена в рамках одной сети составила 2-3 секунды. При использовании механизмов роуминга в другие сети («Би Лайн», Orange, Vodafone) задержка составляет 4-5 секунд. Эти величины позволяют сократить время жизни генерируемого токена до 10-15 секунд, что вполне соответствует самым жестким требованиям безопасности, предъявляемым к системам аутентификации в транзакционных банковских схемах. Также исследовался режим перехвата IP-пакетов с содержанием датаграмм протокола SMPP, несущего значение токена от RSA Mobile плагина до SMSC-сервера.

В целом, испытания показали высокую гибкость настройки программного обеспечения и простоту сопряжения с серверами SMSC с использованием протокола SMPP v3.4. Настройка работы передачи токена по другим протоколам (например, SMTP) не вызвала никаких трудностей. Реализация системы на базе J2EE обеспечивает простую модификацию программного обеспечения под различные нужды конкретных сервисов.

В целях подготовки реального использования были предложены демо-варианты защищенных с помощью RSA Mobile Web-ресурсов, эмулирующих реально существующие ресурсы, в том числе, доступ в систему Raiffeisen Bank, удаленный доступ к почтовому ящику MTC на почтовом сервере «Демос-Интернет», к системе МТС ИССА и др.

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

Автор выражает благодарность за содействие в тестировании сотрудникам компании МТС Андрею Бурцеву и Виктору Краснову.

Тимофей Горшков (timofey@dol.ru) — сотрудник компании «Демос» (Москва), RSA Certified Security Professional.