Данный вариант является переработанной версией статьи, опубликованной в журнале «Зв’язок» № 7, 2005.

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

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

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

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

Функцией перемешивания могут быть хэш - алгоритмы: MD2 (128 бит), MD4 (128 бит), MD5 (128 бит), SHA (160 бит) и т.д. В основном используются MD4 и MD5, обладающие высоким быстродействием и хорошими размешивающими характеристиками (MD4 в 3 раза быстрее MD5).

Далее будем полагать, что используется хэш-функция с 128 битным выходом m=128.

Нулевая итерация (начальное заполнение) примет вид:

Г₀ = Hash(NomSeria, GodenDo, Nominal, SecretKey). (1)

На выходе (1) получим фиксированную m - битную строку хэш - суммы.

В итоге возможно ≈ 2^m начальных состояний генератора, вне зависимости от того, какой длины секретный ключ вводится и какой массив данных туда вводится.

Для получения остальных бит используется рекуррентное выражение:

Г_i+1 = Hash(Г_i) , (2)

где N – количество карточек в выпускаемой серии, L – длина кода пополнения счета в битах, [ ] – округление до большего целого.

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

Свойством (2) является возможность однозначного определения через любой выход хэш-суммы Г_k всех последующих хэш-сумм Г_k+1.

Данный механизм идеален для получения секретных ключей криптоалгоритмов или вычисления (1), но совершенно непригоден для получения кодов пополнения счета, так как они «публикуются» на карточках.

Приведем один из возможных механизмов подделки кодов пополнения счета.

Количество карточек в выпускаемой серии N несложно определить по серийным номерам карточек.

По номеру карточки можно вычислить номер m - битного блока бит и смещение кода пополнения счета в этом блоке.

Длина кода пополнения счета L подбирается из анализа кодов пополнения счета.

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

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

При этом не спасает модификация формулы (2) к виду:

Г_i+1 = Hash(Г_i, SecretKey) , (3)

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

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

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

Для минимизации возможности взлома кодов карточек пополнения счета, службам безопасности (далее СБ) операторов мобильной связи необходимо отказаться от пагубной стратегии, именуемой на Западе SbO, что в зависимости от чувства юмора расшифровывают либо как Security by Obscurity ("безопасность упрятыванием"), либо как Security by Ostrich ("безопасность по-страусиному"). Согласно этой стратегии, степень защиты любой системы в значительной степени увязывается с сохранением в тайне как особенностей ее конструкции, так и случаев ее компрометации. Автор еще в 2002 году лично столкнулся с проявлением этой стратегии в разговоре с представителем СБ одного оператора мобильной связи. СБ выразила заинтересованность в анализе защищенности кодов пополнения счета и даже хотела подкрепить свой интерес финансово. При этом они отказались предоставить для анализа уже использованную серию кодов пополнения счета, сославшись на ее … секретность! Секретным они называли то, что уже находилось в распоряжении автора и при этом было собрано из открытых источников без нарушения законодательства Украины. Налицо полная некомпетентность представителя СБ и непонимание того, что в действительности необходимо защищать. Не думаю, что сейчас что-либо изменилось в стратегии работы СБ.

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

При этом будут выявлены все недостатки и ошибки в реализации, что позволит избежать материальных потерь операторам и пользователям.