Взлом метро (проездных, карточек) + АЛГОРИТМ КРИПТОГРАФИЧЕСКИХ ПРЕОБРАЗОВАНИЙ В СООТВЕТСТВИИ С ГОСТ 28147-89

Взлом метро (проездных, карточек)

Знакомо ли тебе желание разгадать все загадки да вскрыть все защиты Московского Метрополитена? Сделать, например, себе «вечный билет»? Но ведь специалисты метро постоянно находят все более изощренные способы защиты. Металлические жетоны сменились пластиковыми, те, в свою очередь, магнитными билетами, а на смену магнитным пришли бесконтактные карты. У многих исследователей опустились руки — кажется, будто Метрополитен стал неприступной крепостью. Но любую защиту можно обойти. И зачастую, вскрыть ее оказывается в разы проще, чем построить...

Как все начиналось

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

Года три назад у меня снова проснулся интерес к теме метро. Я активно изучал магнитные билеты (информации по этой теме в интернетах было предостаточно) и даже собрал маленький станочек для изготовления дубликатов из двух головок от катушечных магнитофонов и небольшого количества рассыпухи. Не забыл и про свою социальную карту (уже студенческую). Но после изучения документации мне стало понятно, что система практически неприступна — чип MF1S50 Mifare Classic 1K, на базе которых изготавливаются социальные карты, защищен двумя 48-битными ключами. На аппаратном уровне взломать его так просто не получится, а перебирать ключи можно до скончания солнечной системы. Да и картоводы, поддерживающие Classic, стоили по тем временам каких-то неподъемных денег (про Ebay я как-то не подумал, увы). Интерес к магнитным билетам быстро остыл, а социальную карту пришлось снова отложить до лучших времен.

Встречайте: «Ультралайт»

Билеты «Ультралайт» появились в нашем метро недавно, но сразу же вызвали у общественности бурный интерес. Их начали курочить, рвать, расклеивать утюгом и применять прочие методы терморектального криптоанализа. Надо признаться, жажда знаний заставила и меня раскурочить парочку. В результате их изучения и поисков в интернетах было установлено — это не что иное, как Mifare Ultralight, «облегченная» совместимая версия Mifare Classic. Беглый просмотр документации по чипам этого стандарта дал понять — встроенных систем защиты у этих карт нет. Ко всему прочему я напал на статью, детально описывающую успешный взлом похожей транспортной системы голландскими студентами. Все вместе подтолкнуло меня к новым исследованиям.

Поехали!

Для начала, разумеется, просто необходимо было где-то раздобыть беспроводной картовод, поддерживающий «Ультралайт». Было два варианта: или собрать самому (что заняло бы много времени), или купить уже готовое устройство. При мысли о втором варианте, памятуя о ценах трехгодичной давности, у меня пошли мурашки по коже. Но я все же решился посмотреть актуальные цены. И не зря! Я был приятно удивлен, узнав, что можно купить полностью функциональный девайс (OmniKey CardMan 5321), который поддерживает кучу проводных и беспроводных карт по привлекательной цене — 4000 рубликов.

Конечно, не мало, но с другой стороны, это и не 10000; тем более, покупка готового ридера давала возможность сразу сосредоточиться на исследованиях билетов, а не на конструировании и отладке железа, которая могла затянуться на неопределенный срок. Вместе с ридером у той же фирмы (ISBC) был приобретен очень удобный оригинальный SDK местного производства. Он, опять же, позволил не растрачивать силы и время на написание низкоуровневки и отладку работы ПО с ридером, а сосредоточиться непосредственно на билетах. Итак, за пару дней неспешного кодинга родилась маленькая программка, с помощью которой можно было в удобной форме наблюдать и править всю внутреннюю структуру «Ультралайтов». Тогда я начал изучать билеты.

Глухая стена

В процессе изучения через мой ридер прошло очень много билетов. Какие-то я, закатав рукава, доставал «из помойки», какие-то покупал — смотрел, что на них записано, затем проходил и смотрел еще раз. Это были билеты почти всех типов, за исключением, пожалуй, проездного «Ультралайта» на 70 поездок. Через пару недель у меня накопилась большая и отсортированная база дампов разных билетов и в разных состояниях. Были и дампы, снятые с одного и того же билета после каждой поездки, и несколько билетов с метрополитеновскими номерами, идущими подряд. В мою коллекцию попало даже несколько дампов двух разных временных единых социальных билетов (один был выдан сроком на 5 дней, другой на 30), снятых через некоторый временной интервал. Это оказались очень интересные экземпляры, и при этом очень редкие (мне они доставались из первых рук с немедленным возвратом, только на «прочитать»).

По сути, это почти единственный тип «Ультралайтов», который работает не только в метро, но и на наземном транспорте. К тому же, только у этого типа билетов вообще нет ограничения на количество поездок. Впоследствии, именно они сослужили мне большую службу… Весь этот зоопарк я собирал с одной целью — четко определить структуру и формат записи данных на билете. Конечно, какие-то поля были видны сразу, невооруженным глазом, но некоторые нет. Например, я не сразу понял, где записан номер билета метро (тот самый, который на нем напечатан). Осознание пришло совершенно случайно. Дело в том, что я (как и, думаю, большинство из нас), смотря в хекс, привык выравнивать для себя информацию по байтам и мыслить, минимум, байтами. Выяснилось, что здесь этот подход неверен. Глядя на дамп билета, нужно мыслить более мелкими единицами — тетрадами, а иногда и битами. Понял я это тогда, когда «узрел» наконец номер билета, — он оказался сдвинут на 4 бита относительно начала байта, а оставшиеся 4 бита с той и с другой стороны номера занимала прочая служебная информация. Через некоторое время формат записи данных на билеты стал почти полностью понятен.

Стало очевидно, где и как хранятся все даты, счетчики, идентификаторы. Оставалась лишь пара полей, назначение которых было неясно просто потому, что от дампа к дампу данные в них были одинаковы. Но на этом вся радость и закончилась — глупо было бы предполагать, что такие билеты могут оставить незащищенными. В каждом дампе было 32 бита различной информации, никак не коррелировавшей с остальным содержимым. Я предположил, что это своего рода контрольная сумма, «хэш» данных, записанных на билете. Все попытки прикинуть или рассчитать эти 32 бита обернулись полным провалом (в частности, было предположение, что это какой-то вид CRC32, с нестандартным полиномом и стартовым значением).

При попытке изменить хотя бы полтора бита информации внутри билета терминал проверки в метро высвечивал «ПЛОХОЙ БИЛЕТ », увесистым домкратом заколачивая последние гвозди в крышку гроба. Конечно, были попытки обойти систему и другими способами, например, попытаться скопировать билет на чистую карту один-в-один (тут, увы, помешал заводской серийник, который, как выяснилось, тоже участвовал в генерации «хэша») или выставить биты блокировок так, чтобы запретить турникету изменять содержимое билета. Проверочный терминал такой «вечный» билетик признавал, но турникет пускать отказывался... Таким образом, я уперся в стену. В ту большую, крепкую бетонную стену, об которую многие имеют привычку убиваться с разбега. Не найдя никакой информации на форумах и досках, я решил, что на этом мои исследования закончены — путей больше нет, и поставил жирную точку. Как выяснилось, зря...

Странное знакомство

Сентябрьский вечер ничем не отличался от других. Уже почти наступила ночь, на улице было прохладно и сыро. Я сидел перед экраном монитора, и, попивая теплый, чуть сладкий зеленый чай, мирно разводил плату для очередной своей поделки. DipTarce, немного башорга, аська... Кто-то позвонил по скайпу — отвлекают! Опять аська, опять DipTrace — в общем, все как обычно. В очередной раз на передний план вывалилось окно аськи — кто-то, доселе мне неизвестный, написал «Привет». Я, ничтоже сумняшеся, ответил тем же. Следующее сообщение явилось переломным во всей истории: «Ты вроде метро интересуешься, у меня тут кое-какое барахлишко есть. Если интересно, давай встретимся, я тебе передам». Сначала меня это немного смутило и насторожило (может быть, развод или подстава, а может, и «спецслужбы» заинтересовались — паранойя берет свое), но потом я подумал: почему бы и нет?

Спецслужбы мной интересоваться вряд ли бы стали, а почвы для развода, и уж тем более, для подставы тут вроде бы и нет. После недолгой беседы мы договорились о встрече днем, в центре зала одной из станций московского метро. Незнакомец оказался высоким молодым человеком, в очках, с большим черным полиэтиленовым пакетом в руках. Мы поздоровались, затем он передал мне пакет со словами: «На, держи. Мне это все равно не пригодилось, может тебе будет полезно». Заглянув внутрь, я увидел два метрошных терминала, переложенных газетами, несколько хаотично разбросанных белых пластиковых карточек и болванку в коробочке. На мой вопрос о том, сколько я за это должен (денег), парень помотал головой, улыбнулся и сказал: «Да ты что, никто ничего никому не должен, занимайся... Так, мне уже бежать надо, вон и поезд мой как раз! Давай, пока!».

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

Явление софта народу

Придя домой, я разобрал пакет. Второй из терминалов оказался автобусным валидатором (тяжеленный, блин!); карточки были Mifare Classic 1K (чистые), а на диске красовался один единственный архив. После беглого ознакомления с содержимым выяснилось — это софт, который используется на кассах метро. Отложив в сторону терминал и валидатор, я решил вплотную заняться изучением интересного софта. Примерно за час из бардака, который распаковался, мне удалось выстроить и запустить у себя на компьютере эту программу. Еще час потребовался, чтобы разобраться в ее структуре. Прочесав все ini-файлы (с комментариями, любезно оставленными разработчиком), я уже имел полное представление что это, как это работает и с чем это едят. Едят, как выяснилось, с ридером Parsec PR-P08, поэтому, за отсутствием оного, попробовать софт в действии не удалось.

Разработчиком значилась фирма «Смартек» — крупный государственный подрядчик, разрабатывающий системы такого рода (подробнее можно почитать на их сайте). Программа была написана на Delphi с использованием рантайм-bpl’ок. Причем, софт имел модульную структуру, и все подпрограммы, классы и компоненты располагались в отдельных DLL или bpl’ках с говорящими названиями (вот это был и самый главный фэйл разработчиков). После беглого анализа внутренностей софта я выяснил, что, во-первых, информация обо всех выданных билетах передается в централизованную базу данных (к слову, это Oracle) и, во-вторых, в программе используется некий механизм ключей. Программа могла общаться с БД не только в режиме реального времени. Делаем выводы: все операции в системе могут происходить с определенной задержкой. Теоретически, это дает нам фору.

Но прежде всего меня заинтересовал механизм ключей (я примерно уже начал догадываться, зачем он может быть нужен). Итак, я взялся за дизассемблер и приступил к работе. Механизм состоял из двух файлов — CryptKeyRef.dll и keys.d (единственный «хитрый» файл во всей программе, который, кроме как на файл с ключами, больше ни на что не похож). А пользовалась всем этим добром рантайм-bpl’ина SmLayout.bpl. Эта библиотека оказалась просто находкой для моих исследований — в ней содержались классы для работы с внутренним наполнением билетов. Так как это рантайм-bpl, то достаточно было просто взглянуть на ее таблицу экспорта, чтобы уже процентов на 60 понять, что к чему. Более детальный анализ расставил все на свои места. Помнишь, в начале статьи я говорил о том, что в структуре «Ультралайта» остались еще несколько полей, назначение которых было непонятным?

Одно из этих полей — так называемый «идентификатор раскладки». По сути, все билеты метро строятся из фиксированной заголовочной части и переменной части данных. Так вот, это поле «Layout» в заголовке как раз и определяло, каким образом и какие данные расположены в оставшейся части билета. Таких раскладок существует несколько (каждая под свой тип билета), и в SmLayout.bpl каждой из них соответствовал свой класс (плюс общий класс-родитель, в котором были методы для работы с заголовочной частью). Поэтому разобраться, какие поля в каждой раскладке за что отвечают, было просто (еще бы, с говорящими-то именами методов в экспорте!). Добив полностью весь Layout 8 (который используется в «Ультралайтах») и перепроверив, обо всех ли полях в структуре билета у меня было верное представление, я взялся за механизм ключей. Действительно, он отвечал за генерацию «хэша». Как работает механизм, стало полностью ясно после изучения работы метода, отвечавшего за вычисление «хэша». Сначала, из файла с ключами (keys.d) выбирается верный ключ.

Система устроена так, что у каждого типа билетов есть свой идентификатор (в комплекте присутствовала полная таблица с идентификаторами и названиями билетов, в виде текстового файла со значениями, разделенными запятой). Состоит он из идентификатора зоны (приложения) и идентификатора типа карты. Так вот, исходя из этих чисел, в файле ключей выбирается кейринг, внутри которого может быть уже несколько ключей (на случай, когда новый ключ ввели, а старые билеты еще используются). Запись нового билета происходит с использованием самого первого, а проверка на валидность — с использованием всех ключей в кейринге. Далее выбранный ключ расшифровывается с помощью CryptKeyRef.dll (зачем их хранят зашифрованными, ума не приложу). После чего расшифрованный ключ и почти все данные билета, а также его аппаратный серийный номер и число (метод генерации «хэша», который указывается для кейринга в keys.d) — передаются в функцию ckCalcHashCode, находящуюся в той же CryptKeyRef.dll. На выходе мы получаем значение, на котором я в свое время и «застрял» — тот самый «хэш». Разумеется, я написал маленькую программку, которая, используя эти функции из CryptKeyRef.dll и файл keys.d, могла проверять и, в случае чего, пересчитывать «хэш» внутри любого дампа. Я перепроверил все на нескольких дампах, и, получив положительный результат, ушел, довольный, спать.

Протухшие ключи

Несмотря на теоретический успех, хотелось проверить все, так сказать, «в бою». На следующий день, возвращаясь с работы, я специально прикупил свежий «Ультралайт» на одну поездку, чтобы посмотреть, действуют ли мои ключи или уже нет (судя по всему, они были старенькие). Можно, конечно, сразу было попробовать записать «сфабрикованный» «Ультралайт» и пойти проверить, но на тот момент у меня закончились пустые карты, да и немного страшновато идти «наобум» — вдруг что? По приходу домой я первым делом, даже не помыв руки, с нетерпением бросился проверять свежий билет своими ключами. И тут меня поджидал большой облом — «хэш», записанный в билете не проходил ни по одному из ключей. Стало быть, ключи действительно уже протухли и на смену им пришли новые. Это полностью перечеркивало все мои труды. Мне немного взгрустнулось. Я заварил зеленого чая, поиграл немного на фортепиано (да-да) и сел дальше разводить свою неоконченную плату...

Еще не все потеряно

Идея пришла ко мне неожиданно, когда я в очередной раз зачем-то смотрел внутрь файла с ключами. Я заметил, что в «ходовом» кейринге (который используется для расчета 1-, 2-, 5-поездочных и прочих «Ультралайтов») было два ключа — новый (на тот момент, разумеется) и, по всей видимости, — старый. Но был также кейринг, в котором лежал всего один ключ. Раньше я не обращал на него внимания, а концентрировался на «ходовом». Для расчета каких билетов используется этот ключ, я не знал. Когда я посмотрел, что за тип билета привязан к кейрингу, то у меня вспыхнула маленькая искорка надежды. Дело в том, что этот тип билета был — ВЕСБ. Да, именно тот редкий тип билета, — временный проездной на все виды транспорта. Я прикинул, что если билет единый, то этот ключ должен использоваться не только в метро, но и на наземном транспорте, где его очень сложно и долго заменять на новый.

К тому же, ключ в кейринге всего один, что косвенно подтверждало мою догадку. Ко всему прочему, я вспомнил, что, когда вычищал метрошную программу от разного «мусора», там было нечто, похожее на архив старых файлов ключей. Откопав и открыв оригинальный архив, я увидел, что это действительно так. И самое главное, просмотрев все старые файлы ключей, я обнаружил, что именно этот ключ оставался неизменным! Уже без единой капли сомнения я склепал свой собственный ВЕСБ (благо, у меня были дампы такого типа, что в разы упростило задачу — я просто поменял в дампах даты и номер), а «хэш» рассчитал с использованием этого ключа. Итак, настало время проверки (тем более, я как раз купил еще немного чистого пластика). Зайдя в вестибюль, я сначала приложил свой «билет» к проверочному терминалу. На табло высветился срок действия билета, который я указал, и загорелся зеленый светодиод. Стало быть, работает. Сделав гримасу попроще и спрятав белоснежный пластик в рукав, я подошел к турникету, приложил руку к валидатору и... спокойно прошел на весело загоревшийся зеленый. Это ознаменовало окончательную победу.

А что же дальше?

А дальше начались эксперименты, в ходе которых было выяснено множество интересных вещей. Например, по такому «левому» ВЕСБу можно ходить всего два-три дня. Дело в том, что номер, который внутри билета я указываю «от балды», при каждом проходе сохраняется в памяти головы турникета, а через какое-то время отсылается вместе с остальными в центр обработки данных. Там система не находит реально выданного билета с таким номером и вносит его в стоплист, который затем рассылается по всем турникетам метро. И так должно происходить со всеми типами билетов, не только с ВЕСБ — в дополнение к «хэшу» и часто меняющимся ключам это очень хорошая защита. Обойти ее, по понятным причинам, не представляется возможным.

Также было замечено, что установка или не установка битов блокировки не играет никакой роли на то, сработает билет или нет. Исключение составляет только бит блокировки зоны OTP, который турникет, видимо, проверяет всегда, даже несмотря на то, что писать в OTP не собирается. В дальнейшем я взялся за метрошный и автобусный терминалы, привел их в порядок, изучил и запустил на стенде. Теперь, чтобы проверить очередную догадку, уже не надо было бежать со свежеиспеченным билетиком-мутантом в метро, а стало возможным проверять их «не отходя от кассы». Тем более, терминал метро оказался такой же старый (ко всему прочему и глючный), как и мои ключи. Так что я мог попробовать «в работе» и любые другие типы билетов «Ультралайт» — то, чего я никогда не смогу сделать «вживую» в метро. Параллельно с этими экспериментами я продолжал заниматься софтом.

Так как велось много споров о том, что же за алгоритм используется при вычислении «хэша», я решил полностью восстановить его, переписав алгоритм с нуля на «людском» языке программирования, а в процессе как раз надеялся понять, какой же это алгоритм — что-то широко известное или же какая-то своя, внутренняя разработка. Попутно меня посещало много разных мыслей (в том числе, что это может быть и AES), но при детальном изучении уже работающего кода без использования Смартековских библиотек выяснилось, что алгоритм этот — «всего-навсего» ГОСТ — отечественный стандарт шифрования (всю необходимую информацию о нем ты сможешь без труда найти в Сети). Конкретно, для вычисления «хэша» использовался цикл 16-З. «Хэш», по сути, это не что иное, как имитовставка ГОСТ.

Структура информации, записанной на билете «Ультралайт»

Что такое страница, где и как располагаются аппаратный серийный номер, биты блокировки и зона OTP, ты можешь прочитать в оригинальной документации (файл-спецификация в формате PDF с полным описанием чипа есть на диске). Рекомендую начать изучение именно с нее. Я же опишу структуру расположения данных, формируемую системами метро в пользовательской области, доступной для чтения и перезаписи (при отсутствии блокировок, естественно). Все содержимое билета можно условно разделить на заголовочную часть и две полностью дублирующие друг друга части данных (это сделано в целях резервирования и защиты от ошибок). Заголовочная часть в билетах «Ультралайт» начинается со страницы 4. Часть ее одинакова по структуре во всех билетах и идентификаторах системы Метрополитена и МосГорТранса. Первые 10 бит — идентификатор приложения; следующие 10 бит — идентификатор типа карты (о том, какие бывают идентификаторы, ты можешь прочитать в другой, специально выделенной для этого врезке). После идентификаторов располагается серийный номер билета (он выбит на обратной стороне билета, не путай его с аппаратным — это разные вещи!) размером 32 бита. Последние 4 бита — поле Layout, которое указывает системе, каким образом интерпретировать последующие данные (что-то вроде формата файла).

Для билетов «Ультралайт» значение Layout равно 0x08. На этом одинаковая часть заголовка заканчивается. Далее в билете «Ультралайт» указана дата, по которую годен бланк (16 бит). Все даты в системе указываются в формате количества прошедших дней с 01.01.1992. Тут заголовочная часть билета «Ультралайт» заканчивается (в билетах с другим Layout еще может быть записана различная дополнительная информация). Первая область данных начинается со страницы 8. Сначала записаны 16 бит даты выдачи билета. После этого указан срок действия билета в днях (с момента выдачи) — 8 бит. Первые 16 бит страницы 9 — счетчик поездок. Он может быть либо уменьшающимся до нуля (во всех билетах с ограничением числа поездок), либо увеличивающимся от нуля (в билетах ВЕСБ, без ограничения числа поездок). После счетчика в оставшейся части страницы турникет при каждом проходе вписывает свой уникальный идентификатор. По всей видимости, это используется для предотвращения повторного прохода без ожидания по билету ВЕСБ (турникеты в вестибюле соединены в сеть и опрашивают друг друга), а также для возможности посмотреть, через какой турникет был совершен проход (например, в случае ошибки или для ведения статистики). Страница 10 полностью занята 32-битным «хэшем».

Страница 11 пуста. Эта область данных целиком реплицируется на оставшиеся 4 страницы (с 12 по 15). Получается, что при нормальном функционировании эти две области всегда содержат одинаковые данные. Отдельно стоит сказать об использовании системой зоны OTP. Она используется для постепенного «выжигания» билета с каждой поездкой (билетов ВЕСБ это не касается). Два самых младших бита выставляются при гашении или аннулировании билета (по стоп-листу). Аннулированный билет восстановлению не подлежит. Для выжигания остается всего 30 бит. Эта зона представляется системой как 100% поездок. С каждой новой поездкой выставляется определенное количество бит (от младших к старшему), соответствующее тому, сколько процентов занимает одна поездка. Например, для 5-поездочного билета с каждой новой поездкой будет «выжигаться» по 6 бит, а для 60-поездочного — по половинке бита (с округлением в большую сторону). Стоит упомянуть, что повторное использование билетов «Ультралайт» невозможно не только из-за «выжигания» OTP, но также из-за того, что на кассе, при выдаче билета (а возможно даже и при его изготовлении) почти все страницы блокируются для перезаписи. Таким образом, ни «перезарядить», ни изменить тип билета на другой уже не получится.

Примеры используемых идентификаторов билетов метро

Все числа указаны в десятичной системе счисления!

Идентификаторы приложения:

• 262 — Билет Московского Метро.
• 264 — Билет наземного транспорта Москвы.
• 266 — Единый социальный Москвы и МО.
• 270 — Билет «Легкого метро».

Идентификаторы типа билетов «Ультралайт»:

• 120 — Одна поездка.
• 121 — Две поездки.
• 126 — Пять поездок.
• 127 — Десять поездок.
• 128 — Двадцать поездок.
• 129 — Шестьдесят поездок.
• 130 — Багаж + проход.
• 131 — Только багаж.
• 149 — Единый «Ультралайт» (70 поездок).
• 150 — ВЕСБ.

Mifare Classic

Не обошел вниманием в своих исследованиях я и злополучный Mifare Classic 1K. Как ты понимаешь, самым главным препятствием на пути к «Классикам» стояли аппаратные ключи A и B. По счастливой случайности, эти ключи лежали в одном из модулей программы в открытом виде (превед разработчикам!) и мне не составило никакого труда написать небольшую программку для работы с содержимым этих карт, используя полученные ключи. В процессе экспериментов были выявлены некоторые интересные особенности, как то: метро для хранения билета использует первый сектор карты, а наземный транспорт — четвертый; никакой защиты, кроме аппаратных ключей (которые, будучи записанными в софт в таком виде, скорее всего, вообще ни разу не менялись с момента ввода системы в эксплуатацию) на этих билетах не существует.

Вместо этого, в конце каждого блока указана CRC-16, просто для защиты данных от повреждения. К тому же, на социальных картах, помимо билетов, записано еще много разнообразной и интересной информации. Например, в 13 и 14 секторах социальных карт указаны фамилия, имя и отчество владельца. Эти (и некоторые другие) данные можно прочитать с использованием публичного ключа 0xA0A1A2A3A4A5. В ходе экспериментов удалось полностью клонировать студенческую СКМ, а также несколько проездных билетов на чистые карты Classic.

Но от клонирования, как выяснилось, замечательно спасает система стоп-листов — таким билетом можно пользоваться не более двух дней, затем он аннулируется (правда, в отличие от «Ультралайт», карту «Классик» можно восстановить после аннулирования, но от стоп-листа это не спасет). Так как никакой защиты на картах Classic не использовалось, они достаточно быстро стали мне неинтересны, и я решил все-таки сосредоточиться на исследовании «Ультралайт».

The End, или Подведем итоги

Системы метро, а в частности, новые билеты «Ультралайт», вопреки мнениям и догадкам, оказались хорошо защищены. Очень радует, что разработчики использовали надежный и проверенный временем ГОСТ, а не стали изобретать велосипед. С такой защитой подделать билет «Ультралайт», не имея доступа к конфиденциальным данным (ключевой информации), просто невозможно. Замечательно продумана и система сменных ключей, и механизм стоп-листов. Конечно, не обошлось без недостатков и ошибок. Самая большая из них — программное обеспечение, которое никак не защищено.

Достаточно было отказаться от использования рантайм-bpl, и это затруднило бы анализ в десятки раз! Как вариант, — обработка особо важных частей программы AsProtect’ом или ExeCryptor’ом, с последующей запаковкой всех файлов MoleBox’ом свели бы возможность анализа почти к нулю. Инструментарий-то недорогой. А использование хорошей (желательно, малоизвестной или сделанной на заказ) защиты подобного рода, но с аппаратными ключами сделало бы разбор программы полностью невозможным. Разумеется, Метрополитен — это режимное предприятие, но не стоит при этом забывать про человеческий фактор. Ведь еще Кевин Митник говорил (и не только говорил, но и демонстрировал на собственном примере, за что и сел, гы), что иногда для достижения цели проще и эффективнее использовать «социальную инженерию», нежели пытаться сломать непробиваемую защиту. Что ж, на этой ноте я и закончу свое повествование. А тебе, читатель, желаю больше интересных и удачных исследований!

Описание алгоритма криптографических преобразований в соответствии с ГОСТ 28147-89

Данный стандарт устанавливает единый алгоритм криптографического преобразования для систем обработки информации в сетях электронных вычислительных машин (ЭВМ), отдельных вычислительных комплексах и ЭВМ, который определяет правила шифрования данных и выработки имитовставки.

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

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

Структурная схема алгоритма криптографического преобразования

Структурная схема алгоритма криптографического преобразования (криптосхема), приведенного на рисунке 1, содержит:

• - ключевое запоминающее устройство (КЗУ) на 256 бит, состоящее из восьми 32-разрядных накопителей (Х₀, Х₁, Х₂, Х₃, Х₄, Х₅, Х₆, Х₇);
• - четыре 32-разрядных накопителя (N₁, N₂, N₃, N₄);
• - два 32-разрядных накопителя (N₅, N₆) с записанными в них постоянными заполнения С₂, С₁;
• - два 32-разрядных сумматора по модулю 2³² (СМ₁, СМ₃);
• - 32- разрядный сумматор поразрядного суммирования по модулю 2 (СМ₂);
• - 32-разрядный сумматор по модулю (2³²-1) (СМ₄);
• - сумматор по модулю 2 (СМ₅), ограничение на разрядность сумматора СМ₅ не накладывается;
• - блок подстановки (К);
• - регистр циклического сдвига на одиннадцать шагов в сторону старшего разряда (R).

Рисунок 1.

Блок подстановки К состоит из восьми узлов замены К₁, К₂, К₃, К₄, К₅, К₆, К₇, К₈ с памятью на 64 бита каждый. Поступающий на блок подстановки 32-разрядный вектор разбивается на восемь последовательно идущих 4-разрядных векторов, каждый из которых преобразуется в 4-разрядный вектор соответствующим узлом замены, представляющим собой таблицу из шестнадцати строк, содержащих по четыре бита заполнения в строке. Входной вектор определяет адрес строки в таблице, заполнение данной строки является выходящим вектором. Затем 4-разрядные выходные векторы последовательно объединяются в 32-разрядный вектор.

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

При записи ключа (W₁, W₂, …, W₂₅₆), W_qЄ{0,1}, q=i÷256, â КЗУ значение W₁ вводится в 1-й разряд накопителя Х₀, значение W₂ вводится во 2-й разряд накопителя Х₀, …, значение W₃₂ вводится в 32-й разряд накопителя Х₀; значение W₃₃ вводится в 1-й разряд накопителя Х₁, значение W₃₄ вводится во 2-й разряд накопителя Х₁, …, значение W₆₄ вводится в 32-й разряд накопителя Х₁; значение W₆₅ вводится в 1-й разряд накопителя Х₂ и т.д., значение W₂₅₆ вводится в 32-й разряд накопителя Х₇.

При перезаписи информации содержимое p-го разряда одного накопителя (сумматора) переписывается в p-й разряд другого накопителя (сумматора).

Значение постоянной заполнения С₁ (константа) накопителя N₆ приведено в таблице 1.

Значение постоянной заполнения С₂ (константа) накопителя N₅ приведено в таблице 2.

Ключи, определяющие заполнения КЗУ и таблиц блока подстановки К, являются секретными элементами и поставляются в установленном порядке.

Заполнение таблиц блока подстановки К является долговременным ключевым элементом, общим для сети ЭВМ.

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

В криптосхеме предусмотрены четыре вида работы:

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

Шифрование в режиме простой замены

Зашифрование открытых данных в режиме простой замены

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

Рисунок 2

Открытые данные, подлежащие зашифрованию, разбиваются на блоки по 64 бита в каждом. Ввод любого блока Т₀=(a₁(0), a₂(0), …, a₃₂(0), b₁(0), b₂(0), …, b₃₂(0)) двоичной информации в накопители N₁ и N₂ производится так, что значение a₁(0) вводится в 1-й разряд N₁, значение a₂(0) вводится во 2-й разряд N₁, и т.д., значение a₃₂(0) вводится в 32-й разряд N₁; значение b₁(0) вводится в 1-й разряд N₂, значение b₂(0) вводится во 2-й разряд N₂ и т.д., значение b₃₂(0) вводится в 32-й разряд N₂. В результате получают состояние (a₃₂(0), a₃₁(0), …, a₂(0), a₁(0)) накопителя N₁ и состояние (b₃₂(0), b₃₁(0), …, b₂(0), b₁(0)) накопителя N₂.

В КЗУ вводятся 256 бит ключа. Содержимое восьми 32-разрядных накопителей Х₀, Х₁, …, Х₇ имеет вид:

• Х₀=(W₃₂, W₃₁, …, W₂, W₁)
• Х₁=(W₆₄, W₆₃, …, W₃₄, W₃₃)
• . . . . . . . . . . . . .
• Х₇=(W₂₅₆, W₂₅₅, …, W₂₂₆, W₂₂₅)

Алгоритм зашифрования 64-разрядного блока открытых данных в режиме простой замены состоит из 32 циклов.

В первом цикле начальное заполнение накопителя N₁ суммируется по модулю 2³² в сумматоре СМ₁ с заполнением накопителя Х₀, при этом заполнение накопителя N₁ сохраняется.

Результат суммирования преобразуется в блоке подстановки К и полученный вектор поступает на вход регистра R, где циклически сдвигается на одиннадцать шагов в сторону старших разрядов. Результат сдвига суммируется поразрядно по модулю 2 в сумматоре СМ₂ с 32-разрядным заполнением накопителя N₂. Полученный в СМ₂ результат записывается в N₁, при этом старое значение N₁ переписывается в N₂. Первый цикл заканчивается.

Последующие циклы осуществляются аналогично, при этом во 2-м цикле из КЗУ считывается заполнение Х₁, в 3-м цикле из КЗУ считывается заполнение Х₂ и т.д., в 8-м цикле из КЗУ считывается заполнение Х₇. В циклах с 9-го по 16-й, а также в циклах с 17-го по 24-й заполнения из КЗУ считываются в том же порядке: Х₀, Х₁, Х₂, Х₃, Х₄, Х₅, Х₆, Х₇.

В последних восьми циклах с 25-го по 32-й порядок считывания заполнений КЗУ обратный: Х₇, Х₆, Х₅, Х₄, Х₃, Х₂, Х₁, Х₀.

Таким образом, при зашифровании в 32 циклах осуществляется следующий порядок выбора заполнений накопителей:

• Х₀, Х₁, Х₂, Х₃, Х₄, Х₅, Х₆, Х₇, Х₀, Х₁, Х₂, Х₃, Х₄, Х₅, Х₆, Х₇,
• Х₀, Х₁, Х₂, Х₃, Х₄, Х₅, Х₆, Х₇, Х₇, Х₆, Х₅, Х₄, Х₃, Х₂, Х₁, Х₀.

В 32-м цикле результат из сумматора СМ₂ вводится в накопитель N₂, а в накопителе N₁ сохраняется старое заполнение.

Полученные после 32-го цикла зашифрования заполнения накопителей N₁ и N₂ являются блоком зашифрованных данных, соответствующих блоку открытых данных.

Расшифрование зашифрованных данных в режиме простой замены

Криптосхема, реализующая алгоритм расшифрования в режиме простой замены, имеет тот же вид (см. рисунок 2), что и при зашифровании. В КЗУ вводятся 256 бит того же ключа, на котором осуществлялось зашифрование. Зашифрованные данные, подлежащие расшифрованию, разбиты на блоки по 64 бита в каждом. Ввод любого блока Т_ш=(а₁(32), а₂(32), …, а₃₂(32), b₁(32), b₂(32), …, b₃₂(32)) в накопители N₁ и N₂ производится так, что значение а₁(32) вводится в 1-й разряд N₁, значение a₂(32) вводится во 2-й разряд N₁, и т.д., значение a₃₂(32) вводится в 32-й разряд N₁; значение b₁(32) вводится в 1-й разряд N₂, значение b₂(32) вводится во 2-й разряд N₂ и т.д., значение b₃₂(32) вводится в 32-й разряд N₂.

Расшифрование осуществляется по тому же алгоритму, что и зашифрование открытых данных, с тем изменением, что заполнения накопителей Х₀, Х₁, …, Х₇ считываются из КЗУ в циклах расшифрования в следующем порядке:

• Х₀, Х₁, Х₂, Х₃, Х₄, Х₅, Х₆, Х₇, Х₇, Х₆, Х₅, Х₄, Х₃, Х₂, Х₁, Х₀,
• Х₇, Х₆, Х₅, Х₄, Х₃, Х₂, Х₁, Х₀, Х₇, Х₆, Х₅, Х₄, Х₃, Х₂, Х₁, Х₀.

Полученные после 32 циклов работы заполнения накопителей N₁ и N₂ составляют блок открытых данных.

Т₀=(a₁(0), a₂(0), …, a₃₂(0), b₁(0), b₂(0), …, b₃₂(0)), соответствующий блоку зашифрованных данных, при этом значение а₁(0) блока Т₀ соответствует содержимому 1-го разряда N₁, значение а₂(0) соответствует содержимому 2-го разряда N₁ и т.д., значение а₃₂(0) соответствует содержимому 32-го разряда N₁; значение b₁(0) соответствует содержимому 1-го разряда N₂, значение b₂(0) соответствует содержимому 2-го разряда N₂, и т.д., значение b₃₂(0) соответствует содержимому 32-го разряда N₂.

Аналогично расшифровываются остальные блоки зашифрованных данных.

Режим гаммирования

Зашифрование открытых данных в режиме гаммирования

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

Рисунок 3

Открытые данные, разбитые на 64-разрядные блоки Т₀⁽¹⁾, Т₀⁽²⁾, …, Т₀^(М-1), Т₀^(М), зашифровываются в режиме гаммирования путем поразрядного суммирования по модулю 2 в сумматоре СМ₅ с гаммой шифра Г_ш, которая вырабатывается блоками по 64 бита, т.е.

Г_ш=(Г_ш⁽¹⁾, Г_ш⁽²⁾, …, Г_ш^(М-1), Г_ш^(М)),

где М – определяется объемом шифруемых данных.

Г_ш⁽ⁱ⁾ – i-й 64-разрядный блок, i=1÷Ì, число двоичных разрядов в блоке Т₀^(М) может быть меньше 64, при этом неиспользованная для зашифрования часть гаммы шифра из блока Г_ш^(М) отбрасывается.

В КЗУ вводятся 256 бит ключа. В накопители N₁, N₂ вводится 64-разрядная двоичная последовательность (синхропосылка) S=(S₁, S₂, …, S₆₄), являющаяся исходным заполнением этих накопителей для последующей выработки М блоков гаммы шифра. Синхропосылка вводится в N₁ и N₂ так, что значение S₁ вводится в 1-й разряд N₁, значение S₂ вводится во 2-й разряд N₁, и т.д., значение S₃₂ вводится в 32-й разряд N₁; значение S₃₃ вводится в 1-й разряд N₂, значение S₃₄ вводится во 2-й разряд N₂ и т.д., значение S₆₄ вводится в 32-й разряд N₂.

Исходное заполнение накопителей N₁ и N₂ (синхропосылка S) зашифровывается в режиме простой замены в соответствии с требованиями пункта 1.3.1. Результат зашифрования переписывается в 32-разрядые накопители N₃ и N₄ так, что заполнение N₁ переписывается в N₃, а заполнение N₂ переписывается в N₄.

Заполнение накопителя N₄ суммируется по модулю (2³²-1) в сумматоре СМ₄ с 32-разрядной константой С₁ из накопителя N₆, результат записывается в N₄.

Заполнение накопителя N₃ суммируется по модулю 2³² в сумматоре СМ₃ с 32-разрядной константой С₂ из накопителя N₅, результат записывается в N₃.

Заполнение N₃ переписывается в N₁, а заполнение N₄ переписывается в N₂, при этом заполнение N₃, N₄ сохраняется.

Заполнение N₁ и N₂ зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N₁, N₂ образует первый 64-разрядный блок гаммы шифра Г_ш⁽¹⁾, который суммируется поразрядно по модулю 2 в сумматоре СМ₅ с первым 64-разрядным блоком открытых данных Т₀⁽¹⁾=(t₁⁽¹⁾, t₂⁽¹⁾, …, t₆₃⁽¹⁾, t₆₄⁽¹⁾). В результате суммирования получается 64-разрядный блок зашифрованных данных Т_ш⁽¹⁾=(τ₁⁽¹⁾, τ₂⁽¹⁾, …, τ₆₃⁽¹⁾, τ₆₄⁽¹⁾).

Значение τ₁⁽¹⁾ блока Т_ш⁽¹⁾ является результатом суммирования по модулю 2 в СМ₅ значения t₁⁽¹⁾ из блока Т₀⁽¹⁾ со значением 1-го разряда N₁, значение τ₂⁽¹⁾ блока Т_ш⁽¹⁾ является результатом суммирования по модулю 2 в СМ₅ значения t₂⁽¹⁾ из блока Т₀⁽¹⁾ со значением 2-го разряда N₁ и т.д., значение τ₆₄⁽¹⁾ блока Т_ш⁽¹⁾ является результатом суммирования по модулю 2 в СМ₅ значения t₆₄⁽¹⁾ из блока Т₀⁽¹⁾ со значением 32-го разряда N₂.

Для получения следующего 64-разрядного блока гаммы шифра Г_ш⁽²⁾ заполнение N₄ суммируется по модулю (2³²-1) в сумматоре СМ₄ с константой С₁ из N₆, заполнение N₃ суммируется по модулю 2³² в сумматоре СМ₃ с константой С₂ из N₅. Новое заполнение N₃ переписывается в N₁, а новое заполнение N₄ переписывается в N₂, при этом заполнение N₃ и N₄ сохраняется.

Заполнение N₁ и N₂ зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N₁, N₂ образует второй 64-разрядный блок гаммы шифра Г_ш⁽²⁾, который суммируется поразрядно по модулю 2 в сумматоре СМ₅ со вторым блоком открытых данных Т₀⁽²⁾. Аналогично вырабатываются блоки гаммы шифра Г_ш⁽³⁾, Г_ш⁽⁴⁾ …, Г_ш^(М) и зашифровываются блоки открытых данных Т₀⁽³⁾, Т₀⁽⁴⁾ …, Т₀^(М). Если длина последнего М-го блока открытых данных Т₀^(М) меньше 64 бит, то из последнего М-го блока гаммы шифра Г_ш^(М) для зашифрования используется только соответствующее число разрядов гаммы шифра, остальные разряды отбрасываются.

В канал связи или память ЭВМ передаются синхропосылка S и блоки зашифрованных данных Т_ш⁽¹⁾, Т_ш⁽²⁾ …, Т_ш^(М).

Расшифрование зашифрованных данных в режиме гаммирования

При расшифровании криптосхема имеет тот же вид, что и при зашифровании (см. рисунок 3). В КЗУ вводятся 256 бит ключа, с помощью которого осуществлялось зашифрование данных Т₀⁽¹⁾, Т₀⁽²⁾ …, Т₀^(М) при этом Т₀^(М) может содержать меньше 64 разрядов.

Режим гаммирования с обратной связью

Зашифрование открытых данных в режиме гаммирования с обратной связью

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

Рисунок 4

Открытые данные, разбитые на 64-разрядные блоки Т₀⁽¹⁾, …, Т₀^(М), зашифровываются в режиме гаммирования с обратной связью путем поразрядного суммирования по модулю 2 в сумматоре СМ₅ с гаммой шифра Г_ш, которая вырабатывается блоками по 64 бита, т.е. Г_ш=(Г_ш⁽¹⁾, Г_ш⁽²⁾, …, Г_ш^(М)), где М – определяется объемом шифруемых данных, Г_ш⁽ⁱ⁾ – i-й 64-разрядный блок, i=1÷Ì. Число двоичных разрядов в блоке Т₀^(М) может быть меньше 64.

В КЗУ вводятся 256 бит ключа. В накопители N₁, N₂ вводится 64-разрядная двоичная последовательность (синхропосылка) S=(S₁, S₂, …, S₆₄). Синхропосылка вводится в N₁ и N₂ так, что значение S₁ вводится в 1-й разряд N₁, значение S₂ вводится во 2-й разряд N₁, и т.д., значение S₃₂ вводится в 32-й разряд N₁; значение S₃₃ вводится в 1-й разряд N₂, значение S₃₄ вводится во 2-й разряд N₂ и т.д., значение S₆₄ вводится в 32-й разряд N₂.

Исходное заполнение накопителей N₁ и N₂ зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N₁ и N₂ образует первый 64-разрядный блок гаммы шифра Г_ш⁽¹⁾, который суммируется поразрядно по модулю 2 в сумматоре СМ₅ с первым 64-разрядным блоком открытых данных Т₀⁽¹⁾=(t₁⁽¹⁾, t₂⁽¹⁾, …, t₆₃⁽¹⁾, t₆₄⁽¹⁾).

В результате суммирования получается 64-разрядный блок зашифрованных данных Т_ш⁽¹⁾=(τ₁⁽¹⁾, τ₂⁽¹⁾, …, τ₆₃⁽¹⁾, τ₆₄⁽¹⁾).

Блок зашифрованных данных Т_ш⁽¹⁾ одновременно является также исходным состоянием N₁, N₂ для выработки второго блока гаммы шифра Г_ш⁽²⁾ и по обратной связи записывается в указанные накопители. При этом значение τ₁⁽¹⁾ вводится в 1-й разряд N₁, значение τ₂⁽¹⁾ вводится во 2-й разряд N₁ и т.д., значение τ₃₂⁽¹⁾ вводится в 32-й разряд N₁; значение τ₃₃⁽¹⁾ вводится в 1-й разряд N₂, значение τ₃₄⁽¹⁾ вводится во 2-й разряд N₂ и т.д., значение τ₆₄⁽¹⁾ вводится в 32-й разряд N₂.

Заполнение N₁, N₂ зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N₁, N₂ образует второй 64-разрядный блок гаммы шифра Г_ш⁽²⁾, который суммируется поразрядно по модулю 2 в сумматоре СМ₅ со вторым блоком открытых данных Т₀⁽²⁾.

Выработка последующих блоков гаммы шифра Г_ш⁽ⁱ⁾ и зашифрование соответствующих блоков открытых данных Т₀⁽ⁱ⁾ (i=3÷Ì) производится аналогично. Если длина последнего М-го блока открытых данных Т₀^(М) меньше 64 разрядов, то из Г_ш^(М) используется только соответствующее число разрядов гаммы шифра, остальные разряды отбрасываются.

В канал связи или память ЭВМ передаются синхропосылка S и блоки зашифрованных данных Т_ш⁽¹⁾, Т_ш⁽²⁾ …, Т_ш^(М).

Расшифрование зашифрованных данных в режиме гаммирования с обратной связью

При расшифровании криптосхема имеет тот же вид, что и при зашифровании (см. рисунок 4). В КЗУ вводятся 256 бит того же ключа, на котором осуществлялось зашифрование Т₀⁽¹⁾, Т₀⁽²⁾ …, Т₀^(М). Синхропосылка вводится в N₁, N₂ так, что значение S₁ вводится в 1-й разряд N₁, значение S₂ вводится во 2-й разряд N₁, и т.д., значение S₃₂ вводится в 32-й разряд N₁; значение S₃₃ вводится в 1-й разряд N₂, значение S₃₄ вводится во 2-й разряд N₂ и т.д., значение S₆₄ вводится в 32-й разряд N₂.

Исходное заполнение накопителей N₁ и N₂ (синхропосылка S) зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N₁, N₂ образует первый 64-разрядный блок гаммы шифра Г_ш⁽¹⁾, который суммируется поразрядно по модулю 2 в сумматоре СМ₅ с блоком зашифрованных данных Т_ш⁽¹⁾. В результате получается первый блок открытых данных Т₀⁽¹⁾.

Блок зашифрованных данных Т_ш⁽¹⁾ является исходным заполнением N₁, N₂ для выработки второго блока гаммы шифра Г_ш⁽²⁾. Блок Т_ш⁽¹⁾ записывается в N₁, N₂. При этом значение τ₁⁽¹⁾ вводится в 1-й разряд N₁, значение τ₂⁽¹⁾ вводится во 2-й разряд N₁ и т.д., значение τ₃₂⁽¹⁾ вводится в 32-й разряд N₁; значение τ₃₃⁽¹⁾ вводится в 1-й разряд N₂, значение τ₃₄⁽¹⁾ вводится во 2-й разряд N₂ и т.д., значение τ₆₄⁽¹⁾ вводится в 32-й разряд N₂. Полученное заполнение N₁, N₂ зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1, полученный в результате блок Г_ш⁽²⁾ суммируется поразрядно по модулю 2 в сумматоре СМ₅ со вторым блоком зашифрованных данных Т_ш⁽²⁾. В результате получается блок открытых данных Т₀⁽²⁾.

Аналогично в N₁, N₂ последовательно записываются блоки зашифрованных данных Т_ш⁽²⁾, Т_ш⁽³⁾ …, Т_ш^(М-1), из которых в режиме простой замены вырабатываются блоки гаммы шифра Г_ш⁽³⁾, Г_ш⁽⁴⁾, …, Г_ш^(М). Блоки гаммы шифра суммируются поразрядно по модулю 2 в сумматоре СМ₅ с блоками зашифрованных данных Т_ш⁽³⁾, Т_ш⁽⁴⁾ …, Т_ш^(М), в результате получаются блоки открытых данных Т₀⁽³⁾, Т₀⁽⁴⁾, …, Т₀^(М), при этом длина последнего блока открытых данных Т₀^(М) может содержать меньше 64-разрядов.

Режим выработки имитовставки

Для обеспечения имитозащиты открытых данных, состоящих из М 64-разрядных блоков Т₀⁽¹⁾, Т₀⁽²⁾, …, Т₀^(М), М≥2, вырабатывается дополнительный блок из l бит (имитовставки И_l). Процесс выработки имитовставки единообразен для всех режимов шифрования.

Первый блок открытых данных Т₀⁽¹⁾=(t₁⁽¹⁾, t₂⁽¹⁾, …, t₆₄⁽¹⁾)=(a₁⁽¹⁾(0), a₂⁽¹⁾(0), …, a₃₂⁽¹⁾(0), b₁⁽¹⁾(0), b₂⁽¹⁾(0), …, b₃₂⁽¹⁾(0)) записывается в накопители N₁ и N₂, при этом значение t₁⁽¹⁾=a₁⁽¹⁾(0) вводится в 1-й разряд N₁, значение t₂⁽¹⁾=a₂⁽¹⁾(0) вводится во 2-й разряд N₁, и т.д., значение t₃₂⁽¹⁾=a₃₂⁽¹⁾(0) вводится в 32-й разряд N₁; значение t₃₃⁽¹⁾=b₁⁽¹⁾(0) вводится в 1-й разряд N₂ и т.д., значение t₃₄⁽¹⁾=b₃₂⁽¹⁾(0) вводится в 32-й разряд N₂.

Заполнение N₁ и N₂ подвергается преобразованию, соответствующему первым 16 циклам алгоритма зашифрования в режиме простой замены, в соответствии с требованиями пункта 3.1. В КЗУ при этом находится тот же ключ, которым зашифровываются блоки открытых данных Т₀⁽¹⁾, Т₀⁽²⁾, …, Т₀^(М) в соответствующие блоки зашифрованных данных Т_ш⁽¹⁾, Т_ш⁽²⁾, …, Т_ш^(М).

Полученное после 16 циклов работы заполнение N₁ и N₂, имеющее вид (a₁⁽¹⁾(16), a₂⁽¹⁾(16), …, a₃₂⁽¹⁾(16), b₁⁽¹⁾(16), b₂⁽¹⁾(16), …, b₃₂⁽¹⁾(16)), суммируется в СМ₅ по модулю 2 со вторым блоком Т₀⁽²⁾=(t₁⁽²⁾, t₂⁽²⁾, …, t₆₄⁽²⁾). Результат суммирования заносится в N₁ и N₂ и подвергается преобразованию, соответствующему первым 16 циклам алгоритма зашифрования в режиме простой замены.

Полученное заполнение N₁ и N₂ суммируется в СМ₅ по модулю 2 с третьим блоком Т₀⁽³⁾ и т.д., последний блок Т₀^(М)=(t₁^(М), t₂^(М), …, t₆₄^(М)), при необходимости дополненный до полного 64-разрядного блока нулями, суммируется в СМ₅ по модулю 2 с заполнением N₁, a₁^(М-1)(16), a₂^(М-1)(16), …, a₃₂^(М-1)(16), b₁^(М-1)(16), b₂^(М-1)(16), …, b₃₂^(М-1)(16). Результат суммирования заносится в N₁, N₂ и зашифровывается в режиме простой замены по первым 16 циклам работы алгоритма. Из полученного заполнения накопителей N₁ и N₂ выбираем отрезок И_l=[a_32-l+1^(М)(16), a_32-l+1^(М)(16), …, a₃₂^(М)(16)].

Имитовставка И_l передается по каналу связи или в память ЭВМ в конце зашифрованных данных, т.е. Т_ш⁽¹⁾, Т_ш⁽²⁾, …, Т_ш^(М), И_l.

Поступившие зашифрованные данные Т_ш⁽¹⁾, Т_ш⁽²⁾, …, Т_ш^(М) расшифровываются, из полученных блоков открытых данных Т₀⁽¹⁾, Т₀⁽²⁾, …, Т₀^(М) вырабатывается имитовставка И^′_l, которая затем сравнивается с имитовставкой И_l, полученной вместе с зашифрованными данными из канала связи или памяти ЭВМ. В случае несовпадения имитовставок полученные блоки открытых данных Т₀⁽¹⁾, Т₀⁽²⁾, …, Т₀^(М) считают ложными.

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