dxdt.ru: занимательный интернет-журнал

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

(Речь здесь идёт только о шифровании, обеспечение целостности и аутентификацию – оставим за рамками заметки. И там же, за рамками, очевидный момент: тезис “внутренней сети” – весьма и весьма спорный.)

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

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

При этом, с точки зрения защиты передаваемой информации, решение с шифрованием окажется заведомо не хуже, чем полностью открытый протокол. А внедрить именно мониторинг – особенной проблемы не составляет, если только сразу проектировать протокол с учётом этого требования. Другое дело, что в случае с шифрованным протоколом, у чисто внешнего решения, предназначенного для “защиты”, возникнут проблемы: это решение должно уметь работать с ключами, как-то получать их, и так далее. Это существенно увеличивает затраты на разработку, по сравнению с “мониторингом” открытого протокола, где можно быстро и просто приспособить имеющиеся в “офисной линейке” решения (с сомнительной степенью полезности).

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

Стеганография – это различные методы сокрытия дополнительной информации в некотором открытом носителе. В современной ситуации, особенно, если рассматривать её в контексте Интернета, отличительная особенность стеганографии в том, что она позволяет скрывать метаинформацию об обмене данными: то есть, скрывать сам факт установления соединения. Так, защитить передаваемую по открытому каналу информацию от прослушивания поможет шифрование, но сам факт соединения (передачи зашифрованной информации) будет виден прослушивающей стороне, и она, например, может помешать этому соединению, прервав его в самом начале.

Создание хорошо сокрытого канала связи представляет проблему. В случае с Интернетом, дополнительный канал может быть спрятан внутри того или иного “обычного трафика”, но подобрать правильный трафик – непросто. Например, не годится метод, когда для маскирования используется специально создаваемая сессия с особым удалённым узлом, даже если эта сессия является “обычной” парой “HTTP-запрос/HTTP-ответ”: во-первых, будет зафиксирован факт отправки запроса; во-вторых, активная атакующая сторона может перехватить соединение, прервать его, а потом повторить запрос самостоятельно, тем самым выяснив какие-то детали обмена информацией.

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

На практике эта схема сталкивается с трудностями распределения ключей. На первый взгляд, можно предположить, что узлы просто используют тот или иной типовой вариант протокола Диффи-Хеллмана (DH). Но этот протокол обычно виден в трафике: так, в случае подходящего варианта на эллиптических кривых, открытый ключ представляет собой координаты точки на кривой – соответственно, если прослушивающая сторона знает кривую, то она может элементарно обнаружить факт обмена DH, проверив, что подозрительные байты действительно кодируют точки на кривой. Сам секрет таким образом вычислить, конечно, нельзя, поэтому узлы смогут использовать полученный ключ в других сессиях. Более того, далеко не всегда можно с большой вероятностью сказать, что стороны действительно обменялись ключами, а не просто передали случайные значения (точки). Однако, речь идёт именно о сокрытии факта соединения, а сеанс DH этот факт документирует довольно неплохо.

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

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

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

Сейчас вновь поднялся шум, касающийся внедрения биометрической идентификации, применительно к банкам. Например, клиент идентифицируется по изображению лица и записи голоса. Подобные системы пытаются внедрять уже много лет. Естественно, банки привлекает потенциальное удобство для клиента: можно говорить, что ему больше не нужны никакие дополнительные “идентификаторы”, потому что банкомат уже не потребует банковской карты.

При этом с самой биометрией, естественно, ничего не изменилось: данные, которые предлагается использовать для идентификации, общедоступны. Лицо человека несложно сфотографировать (если, конечно, он не носит постоянно маску). Голос – нетрудно записать. При этом удалённые системы сразу создают новые направления для атак методами социальной инженерии (с повторным проигрыванием голосовой записи, или с трансляцией ответов атакуемого клиента банка).

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

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

Биометрическая идентификация должна использоваться только в качестве дополнения к другим методам, и проводить её должен тоже человек (пусть и с применением “технических средств”).

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

Квантовые протоколы предполагают, что стороны смогут определить факт прослушивания канала при помощи статистического анализа принятых квантовых значений, сравнивая переданные и принятые данные при помощи открытого канала. Действительно, если прослушивающая сторона принимала передаваемые фотоны (или другие носители “квантовой информации”), то она обязательно внесла изменения в статистику и будет обнаружена. Проблема в том, что кванты генерирует и излучает вполне классическая установка. Рассмотрим простой воображаемый аппарат, где поляризация испускаемого фотона задаётся при помощи вращающегося диска с набором фильтров: лазерный импульс генерируется в случайный момент времени – фотон проходит через тот или иной фильтр, оказавшийся на его пути, и соответственно поляризуется. В этой схеме определить поляризацию фотона можно не измеряя его – достаточно знать, в каком положении находился диск в момент излучения импульса. Предположим, что двигатель, который вращает диск, излучает систематическую помеху. Тогда положение диска можно вычислить по этой помехе (да, может потребоваться дополнительная информация о стартовой конфигурации и т.п., но это детали). Момент, в который лазер генерирует импульс-источник фотона, также можно определить по той или иной помехе, например, разряд наводит некоторое “эхо” в цепи питания (вариант не столь теоретический, как может показаться). В случае использования более продвинутой системы, построенной на квантовой запутанности, соответствующие утечки информации могут происходить в момент измерения передающей стороной своей части накопленных квантовых пар. Логика прослушивания при этом не меняется.

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

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

На сайте ESA опубликован отчёт по результатам анализа причин потери аппарата “Скиапарелли” на Марсе. Аппарат, напомню, разбился, так как не выполнил программу торможения и посадки. Отчёт довольно подробный, но некоторых технических деталей всё же не хватает (нет подробного описания архитектуры программного обеспечения и средств разработки, например; нет описания моделей движения и пр.). Авария произошла из-за того, что аппарат преждевременно перешёл в конфигурацию завершающего спуска, отстрелив парашют и проведя минимальное (3 секунды) “окончательное торможение” реактивными двигателями на высоте около 3,7 км. Последовавшее свободное падение завершилось ударом о поверхность Марса с предполагаемой скоростью около 150 м/сек.

Основной результат расследования такой. Причин у нештатного падения аппарата несколько: во-первых, использовавшиеся при разработке модели динамики парашютной системы не обладали достаточной точностью; во-вторых, логика системы управления, – по большей части, это логика в программном коде, – не учитывала возможных “экстремальных” или ошибочных данных, которые могли поступать с различных датчиков (прежде всего, инерциальная навигационная система); в-третьих – при проектировании даже не попытались заложить в систему какую-то устойчивость, а просто рассчитывали на то, что работа всех частей не выйдет за пределы некоторой упрощённой модели, которую сочли эквивалентной штатному снижению (и даже тут ошиблись).

Почему-то в СМИ пишут, что причиной падения “Скиапарелли” стала “тригонометрическая ошибка”, типа, неверно учли “знак значения синуса”. Из отчёта такой вывод не следует. Ошибка с расчётом угла положения (по одной из осей аппарата), приведшая в итоге к “отрицательной высоте” (расчётной) и преждевременному включению последовательности приземления, действительно упоминается, но причина её в том, что сигнальный флаг модуля инерциальной системы навигации, сообщавший о запредельных измеряемых параметрах, действовал слишком долгое время – это не было учтено в логике работы, так как разработчики почему-то рассчитывали на максимальную продолжительность такого режима в 15 мс. А главное, что ключевой дефект совершенно не в этом: так, если бы система управления была спроектирована должным образом, то она могла бы легко компенсировать и ошибку в определении угла, и даже вычисленную “отрицательную высоту”; последняя, впрочем, тогда и не возникла бы. Для компенсации не требовалось даже резервировать системы, достаточно было грамотно сверять имеющиеся данные от нескольких сенсоров (инерциальная система, таймер, радиовысотомер) между собой и с моделью движения. Более того, точное моделирование могло ещё на Земле показать, что возможны ситуации с запредельными угловыми скоростями, соответственно, их необходимо учитывать в логике системы управления. Именно об этом и сказано в отчёте.

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

В криптографической библиотеке для Arduino используется российский шифр “Магма” (ГОСТ 34.12-2015). Я сравнил свою реализацию “Магмы” из библиотеки с другим “малым” шифром – Speck, который был предложен в 2013 году специалистами АНБ. Чтобы сравнение было точнее, я также реализовал Speck, использовав inline-ассемблер (ссылка на исходный код – в конце записки).

Прежде всего – краткое описание шифра Speck. Это новый блочный шифр, специально разработанный для программной реализации в микроконтроллерах, то есть, вычислителях с сильно ограниченными ресурсами. Как и многие другие современные шифры (а также и “Магма”), Speck построен на базе простой “раундовой” функции, которая последовательно вызывается с разными ключами, проводя преобразование блока данных. В Speck эта же функция используется для разворачивания основного ключа в последовательность ключей раундов. Это первое существенное отличие от “Магмы”, в котором разворачивание ключа сводится к копированию (см. описание “Магмы”). Спецификация Speck вводит несколько вариантов шифра, имеющих разную разрядность блока и ключа. Я использовал наиболее близкий к “Магме” вариант: 64-битный блок и 128-битный ключ (256-битного, по ключу, варианта Speck для 64-битного блока – нет, поэтому сравнить шифры на одной длине ключа нельзя). От варианта к варианту в Speck различаются количество раундов и часть параметров раундовой функции (разрядность логических сдвигов).

На картинке ниже – подробная схема раунда Speck (шифрование).

Входной блок разбивается на две части. Это, опять же, одно из распространённых и хорошо проверенных решений в схемах шифров. Левая часть (A₁ на схеме) циклически сдвигается вправо на 8 разрядов, суммируется с правой частью (A₀) по модулю 2³² (то есть, как два 32-разрядных числа “естественным образом”, без переноса и знака; операция обозначена символом ⊞). На следующем шаге выполняется сложение по модулю 2 (XOR, ⊕) с раундовым ключом. После чего результат обработки полублока суммируется (опять же, XOR) со вторым полублоком, который перед этим циклически сдвигается на три разряда влево.

В шифре “Магма” используется схема Фейстеля, в которой полублоки, после применения раундовых преобразований, переставляются. Раунд шифра Speck также можно привести к схеме Фейстеля, разделив на два этапа. Первый этап включает преобразования левой части, за которыми следует перестановка полублоков. Схема:

Второй этап – состоит в применении сдвига и XOR к результату первого этапа. Схема:

То есть, с некоторой долей условности можно сказать, что Speck построен из двух, применяемых последовательно, конструкций Фейстеля.

Раунды выполняются циклически. Для используемого варианта шифра число повторений равняется 27. Таким образом, требуется 27 раундовых ключей, каждый разрядностью 32 бита. Схема их получения из исходного, 128-битного, ключа состоит в последовательном применении той же раундовой функции к ключу, предварительно разбитому на слова, разрядность которых совпадает с разрядностью полублока. То есть, 128-битный ключ (16 байтов) даёт нам четыре слова по 32 бита. Эти слова служат левым и правым полублоком в раундовой функции. Ключом (K_i на схеме) при этом является номер раунда. Другими словами: первый раундовый ключ – это младшие 32 бита исходного, основного ключа (используются прямо). Второй раундовый ключ – младшие 32-бита результата применения раундовой функции к младшим 64 битам основного ключа (очевидно, что сюда, в качестве правого полублока, входит первый раундовый ключ); и так далее, подробнее можно посмотреть в исходном коде.

Переходим к сравнению шифров. Ассемблерная реализация позволяет посчитать примерное число тактов, необходимых для выполнения преобразований шифра. Для Speck подсчёт дал 1951 такт – столько занимает полная реализация, с обращением к памяти, где хранятся раундовые ключи и блок открытого текста, с выгрузкой результата. Сюда не входит код получения последовательности раундовых ключей (развёртывания ключа). 1951 такт, в пересчёте на байт данных (блок состоит из 8 байтов), даёт: 1951/8 = 244 такта на байт (приблизительно). В исходной работе, со спецификацией Speck, авторы приводят результат от 118 до 160 тактов для аналогичного 8-разрядного микроконтроллера, но здесь не учитываются операции по загрузке/выгрузке блоков, так что результаты довольно близки (кроме того, мой вариант можно оптимизировать).

Реализация “Магмы” из библиотеки для Arduino показывает следующие результаты: 9092 такта полный код, соответственно, 1136 (приблизительно) тактов на байт (отмечу, что показатели близки к реализациям AES). Существенный вклад в это число вносит реализация подстановок, где много обращений к памяти с достаточно сложными преобразованиями указателей. Этот код можно оптимизировать, вплоть до того, что сами подстановки разместить в регистрах (для 16 полубайтовых подстановок, закрывающих одну позицию во входном полублоке, достаточно восьми байтовых регистров; однако вся таблица подстановок в регистрах типичного микроконтроллера вряд ли поместится – для неё нужно 64 регистра). Правда, вычисление номера регистра и обращение к нему потребует дополнительных усилий, объём кода заметно возрастёт, а для “Магмы” он и так не маленький. Тем не менее, вряд ли выигрыш по тактам составит более двух раз. Из-за подстановок – “Магма” медленнее, чем Speck, тут ничего нельзя поделать.

Другим параметром, по которому можно сравнить шифры, является объём требуемой памяти данных. Для Speck нужно 108 байтов для раундовых ключей. Реализация “Магмы” требует 128 байтов (здесь больше раундов – 32). При этом, если требуется экономия памяти, “Магма” позволяет прямо использовать в качестве раундовых ключей слова из состава основного ключа. Со Speck такой фокус не пройдёт, потому что здесь сложная функция разворачивания ключа. Однако оптимизация всё равно возможна: раундовые ключи можно вычислять в процессе выполнения раундов шифра. Впрочем, такой вариант приведёт к тому, что минимум в два раза возрастёт число тактов, поэтому Speck приблизится к “Магме”. Для хранения таблицы подстановок “Магма” требует ещё 8*8=64 байта.

Реализация “Магмы” существенно превышает показатели Speck по объёму кода. И тот, и другой шифр вполне укладываются в разумные рамки, но код шифра Speck – очень компактный. Побайтового сравнения объёмов я не привожу.

Итак, “Магма” уступает Speck по показателям, относящимся к программной реализации. Неудивительно: “Магма” очень старый шифр, разработанный ещё в 70-х годах прошлого века. Как ни странно, в этом состоит его преимущество, если говорить об оценках стойкости. Этот шифр до сих пор входит в рекомендации ГОСТ и для него пока не опубликовано криптоанализа, существенно снижающего стойкость, хотя сломать шифр пытались многократно. Speck – новый шифр, выполненный в современных традициях, задуманный специально для микроконтроллеров, этим обусловлены его преимущества. Для данного шифра также пока не опубликовано криптоанализа, существенно снижающего стойкость (известные работы – предлагают академические атаки, не пригодные для практических сценариев), но нужно учитывать малое распространение и новизну шифра. Отмечу также, что Speck далеко не единственный новый шифр, ориентированный на “Интернет вещей”, однако является одним из самых простых, быстрых и компактных. Тем не менее, преимущество в скорости и возможность экономии нескольких десятков байтов – не всегда являются решающими факторами, в том числе, для устройств с малой вычислительной мощностью. Например, в случае передачи раз в час команд от устройства к устройству, разница в несколько миллисекунд, требующихся для получения криптограммы, не играет роли. (С другой стороны, каждый такт – это расход энергии элемента питания, что может оказаться существенным для устройств с экстремально низким энергопотреблением.)

В ГОСТ на средства криптографической защиты информации уже есть весьма современный шифр “Кузнечик”, сходный с AES. Однако и “Кузнечик”, и AES – не очень хорошо подходят для микроконтроллеров, так как быстрая реализация этих шифров требует довольно большого объёма памяти, который доступен далеко не для всех платформ, кроме того, часто требуются короткие криптограммы (64 бита). Вполне возможно, что в обозримом будущем в стандартах появится новый российский шифр, ориентированный именно на маломощные вычислители.

Приложение: исходный код реализации Speck для Arduino (только зашифрование), также содержит дополнительные функции для шифрования тестового вектора и проверки правильности работы.

В корпоративных сетях нередко применяются системы DLP (Data Loss Prevention), которые должны предотвращать утечки конфиденциальной информации. (Иногда почему-то считается, что основная задача DLP не предотвращение утечек, а их обнаружение; однако, если утечка произошла, это означает лишь, что система DLP не сработала.) Предотвращение утечек подразумевает перекрытие каналов, по которым эти утечки могут происходить. В самом банальном варианте – блокируется передача данных через сетевые подключения (но не приём). Или рабочее место, где возможен доступ к защищаемым данным, физически не подключено к сетям передачи данных. Ну и так далее, вариантов много, а продвинутая система ещё должна следить за доступом к данным, а не только “трафик просматривать”.

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

Предположим, что данные передаются со скоростью один килобит, это, примерно, 100 полезных байтов в секунду (потребуется израсходовать часть полосы на коррекцию ошибок и служебную информацию) – тогда за час можно скопировать около 350 килобайт информации. Не очень много, но, если взять объём за рабочий день, достаточно для многих типов конструкторской документации или дампов баз данных клиентов. Да, очевидно, что в качестве аппаратного носителя схемы годится смартфон, но смартфоны могут быть запрещены, а компактный считыватель, выполненный в виде шариковой ручки, пронести возможно.

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

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

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

Превратил реализацию шифра “Магма” для Arduino в библиотеку, добавив схему аутентификации CMAC (на том же шифре) и удобные интерфейсы для шифрования/расшифрования. На специальной странице есть короткое описание и ссылки на саму библиотеку: шифрование для Arduino.

В продолжение предыдущей заметки – посмотрим, как устроены симметричные блочные шифры. Примером послужит шифр “Магма”, в версии ГОСТ Р 34.12-2015, с картинками. Симметричными называют шифры, для которых ключ расшифрования можно легко получить из ключа зашифрования. В современных симметричных шифрах – эти ключи просто совпадают. Блочный шифр, в отличие от потокового, работает с блоками данных фиксированной длины (разрядности), измеряемой в битах. Например, шифр AES работает с блоками разрядности 128 бит. А “Магма” – 64 бита.

Получив на вход блок открытого текста и ключ, преобразование, называемое шифром, выводит блок шифротекста, той же разрядности. Соответствие между блоками открытого текста и блоками шифротекста задаёт значение ключа. “Магма” использует ключ длиной 256 бит. Современные шифры строятся из некоторых элементарных операций над блоками. Наборы таких операций обычно объединяют в раунды. Раунды повторяются несколько раз.

В “Магме” 64-битный блок разделяется на две равные части, над которыми производятся операции раунда. Эти операции включают в себя (в порядке выполнения): сложение с ключом раунда; подстановки; циклический сдвиг; сложение с половиной блока. Заканчивается раунд перестановкой полублоков местами. Раунд показан на схеме ниже:

A₁ и A₀ – две части входного блока: соответственно, они содержат по 32 разряда каждая. На вход цепочки раундовых операций поступает значение полублока A₀. Для каждого раунда используется свой ключ. На схеме ключ обозначен K_i. Раундовый ключ также имеет длину 32 бита (разряда), то есть, совпадает с разрядностью половины блока. Сложение блока со значением ключа (операция обозначена символом ⊞) выполняется по модулю 2³² – это эквивалентно “естественному”, для вычислительной техники, сложению двух 32-битных чисел (без знака). Над результатом сложения выполняются подстановки по таблице подстановок. Таблицы часто называют S-boxes. “Магма” использует 4-битные подстановки, отдельные для каждого полубайта из 32-битного блока. Логика тут следующая: 32-битный блок разбивается на 8 4-битных частей, каждое из получившихся значений (0..15, так как битов – четыре) заменяется на соответствующее ему значение из таблицы подстановок; таблиц восемь – по одной для каждой позиции 4-битного значения внутри 32-битного блока.

В версиях шифра, предшествовавших ГОСТ Р 34.12-2015, таблицы подстановок предлагалось выбирать отдельно для каждой сети обмена сообщениями и держать в секрете. То есть, таблицы позволяли повысить стойкость шифра. При этом, впрочем, неверно выбранные подстановки стойкость могут заметно снизить, а раскрыть секретные подстановки реально, если атакующий может зашифровывать произвольные тексты с известным ключом. В ГОСТ Р 34.12-2015 – значения подстановок зафиксированы.

Значение 32-битного блока после подстановок циклически сдвигается влево на 11 разрядов (то есть, биты сдвигаются влево, а выбывшие разряды вдвигаются справа в том же порядке). После операции сдвига, значение поразрядно суммируется с блоком A₁ по модулю 2, это логическая операция XOR (обозначена символом ⊕ на схеме).

В заключении раунда – A₁ и A₀ меняются местами. То есть, A₀ переходит в следующий раунд без изменений, но становится на место A₁. Всего раундов 32. Последний раунд отличается тем, что 32-битные блоки не меняются местами, а просто объединяются: A₀ присоединяется к A₁ справа. Это замыкает всю конструкцию, позволяя использовать её без изменений для расшифрования: операция расшифрования отличается только обратным порядком раундовых ключей.

Раундовых ключей – 32. Каждый имеет разрядность 32 бита. Эти ключи получаются из основного ключа шифрования при помощи алгоритма развёртывания ключа. В “Магме” этот алгоритм очень простой. Исходный ключ содержит 32 байта (256/8=32). 32 байта – это 8 раундовых ключей, каждый по четыре байта; на 32 раунда – ключи копируются, с той лишь разницей, что последние восемь используются в обратном порядке. Схема:

Работа шифра выражается в “перемешивании” битов открытого текста, схему перемешивания определяет ключ (и таблицы подстановок, но мы считаем, что они неизменны). Преобразования можно визуализировать. На картинке ниже – разным значениям битов соответствуют синий и жёлтый цвета, раунды выполняются сверху вниз (самая верхняя строка – открытый текст).

Посмотрим, насколько важны параметры и базовые преобразования, выбранные для построения шифра. Важным инструментом криптоанализа является изучение работы шифра при малых отличиях открытых текстов. На картинке ниже – распространение изменений между раундами “Магмы”: два открытых текста отличаются значением одного бита, ключ используется одинаковый; синим цветом отображены разряды, значения которых совпали между собой; зелёным – отличающиеся разряды.

Хорошо видно, что уже на седьмом раунде различия между значениями блоков сравнимы (визуально) с типичным расстоянием между двумя случайными 64-битными значениями. При этом решающий вклад в “разделение” блоков вносят подстановки (собственно, в этом их основное назначение). Попробуем выключить подстановки (кроме последнего раунда; без подстановок, естественно, данный шифр использовать нельзя).

Результат – плачевный. Несмотря на то, что это лишь схема для двух открытых текстов, понятно, что ни о каком “лавинном эффекте” от замены одного бита говорить уже не приходится. Сходного результата можно добиться и использованием “плохих” таблиц подстановок (но нестойкие таблицы, в общем случае, не обязательно приводят к такому эффекту).

Попробуем изменить другой параметр – число разрядов, на которые циклически сдвигается блок в каждом раунде. Используем сдвиг на 12 разрядов, вместо 11 (подстановки и другие преобразования – без изменений).

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