Программно-аппаратный комплекс защиты телеметрии и телеуправления cпециализированного беспилотного летательного аппарата

• –    выбор аппаратной платформы для реализации протокола;

• –    проведение криптоанализа шифратора протокола;

• –    разработка структуры протокола на сеансовом уровне.

Выбор аппаратной платформы для реализации протокола

Одним из главных критериев выбора платформы является скорость ее работы, она должна быть сопоставима скорости работы UART интерфейса. При этом платформа должна быть мобильной, обеспечивать возможность программирования пинов, ШИМ-сигнала и поддерживать аппаратные протоколы передачи данных, таких как: I2C, UART, SPI и т.п. Ранее установлено [1], что скорость алгоритма «Шифратор 125» на ноутбуке составляет 120 килобайт/с. Но ноут-бук– неподходящее устройство для встраивания его в электрические БПЛА, он недостаточно мобилен для этого и обладает избыточными техническими характеристиками. Для возможности встраивания алгоритма шифрования и «Протокола 125» [2] в технические устройства определена другая мобильная аппаратная платформа на базе процессора с архитектурой ARMhf – BeagleBone Black (BeaglePocket).

Результат расчета скорости на BeagleBone Black (BeaglePocket) с 1GHz 512 MB составляет свыше 5 килобайт/с (свыше 43 килобит/с). Случайная генерация ключа в среднем выдает скорость 12 килобайт/с (около 97 килобит/с – это стандартная скорость для большинства оборудования с поддержкой UART, попадающая в диапазон от 9.6 до 115.2 килобит/с). Увеличить скорость еще больше можно при помощи использования неприводимых многочленов меньшей степени, но это может повлиять на безопасность шифртекста. На рис. 1 показана скорость «Шифратора 125» в сравнении для процессоров разной мощности (на ноутбуке, рис. 1 a , и на микрокомпьютере, рис. 1 b ). Данные рис. 1 показывают, что скорости работы алгоритма шифрования на микрокомпьютере достаточно для передачи данных телеметрии и команд управления БПЛА по протоколу UART.

В ходе исследования установлена зависимость скорости шифрования от конфигурационного ключа (КК). Использование КК с 1 раундом шифрования и неприводимым многочленом из 240 бит дадут на ноутбуке скорость шифрования 120 килобайт/с, а на BeagleBoneBlack (PocketBeagle) 5 килобайт/с, тогда как средняя скорость при случайно сгенерированном КК будет примерно в два раза больше. Злоумышленник может определить факт использо-

Рис. 1. Скорость шифрования на ноутбуке (a); скорость шифрования на BeagleBone Black (BeaglePocket) (b); вариант аппаратного модуля передачи данных БПЛА (c)

Fig. 1. Encryption speed on a laptop (a); Encryption speed on BeagleBone Black (BeaglePocket) (b); a variant of the UAV hardware data transfer module (c)

вания подблоков небольшого размера при скорости шифрования, большей 120 килобайт/с или 5 килобайт/с для ноутбука и платы соответственно. Для того чтобы не допустить таких случаев, рекомендуется создать дополнительный раунд, чтобы скорость шифрования не превышала значительно приведенные выше показатели. Целевая скорость подбирается при помощи фрагментации блоков от небольших к большим. На рис. 1 c показан возможный вариант реализации аппаратного модуля телеметрии и телеуправления на данном шифре для малого сельскохозяйственного электрического беспилотного летательного аппарата (мБЭП-ЛА). В беспилотнике для решения задачи агрегирования информации с различных блоков устройств, находящихся в одном корпусе, можно использовать схему, где на вход PocketBeagle поступает информация для шифрования. Затем идет BeagleBoneBlack Industrial. Он собирает информацию с нескольких устройств PocketBeagle, выполняет окончательное агрегирование информации и передачу данных по Сети на большие расстояния (при использовании переходника информацию можно передавать по оптоволокну или в радиоэфире). Для проверки работоспособности шифратора проведено нагрузочное тестирование, осуществлен расчет энергопотребления в процессе шифрования. Учитывая, что мБЭПЛА в большинстве случаев работают непрерывно не более 2 ч, для проверки беспрерывного шифрования был выбран срок в 3 дня.

В табл. 1 представлены результаты тестирования энергопотребления и трехдневный тест непрерывного шифрования. Конфигурация алгоритма шифрования: три раунда, один раунд с заменой по неприводимому многочлену 240 бит, остальные – случайно сгенерированы. Размер файла шифрования 13,6 гигабайт. Аккумулятор A-Data 20000 mAh, Li-ion. Во время шифрования процессор был загружен вычислениями на 100 %. Температура окружающей среды 25 °C. Корректность шифрования проверялась по объему зашифрованных данных и по количеству прошедшего времени с учетом известной скорости шифрования алгоритма, и только в случае совпадения результатов проверка непрерывного шифрования признавалась успешной.

Таблица 1. Тестирование работы алгоритма шифрования на аппаратной платформе

Table 1. Testing the operation of the encryption algorithm on the hardware platform

Вид теста	Время	Результаты
Разряд аккумулятора и непрерывное шифрование	19.05.2018 [16:29]	Успешный запуск устройства и шифратора
Разряд аккумулятора и непрерывное шифрование	19.05.2018 [20:17]	Проверка. Непрерывное шифрование 4 ч. Потребление 2000 mAh (500 mAh/ч)
Разряд аккумулятора и непрерывное шифрование	20.05.2018 [12:07]	Проверка. Непрерывное шифрование 20 ч. Потребление 11660 mAh (728 mAh/ч)
Непрерывное шифрование	20.05.2018 [22:00]	Проверка. Непрерывное шифрование 1 день 6 ч
Непрерывное шифрование	21.05.2018 [20:23]	Проверка. Непрерывное шифрование 2 дня 2 ч
Непрерывное шифрование	22.05.2018 [02:00]	Проверка. Непрерывное шифрование 2 дня 8 ч
Непрерывное шифрование	22.05.2018 [16:30]	Проверка. Непрерывное шифрование 3 дня

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

Все тесты «Шифратора 125» проведены на оборудовании BeagleBoneBlack (есть его компактный аналог BeaglePocket) с 1GHz-процессором и 512MB ОЗУ.

Криптоанализ шифратора протокола

В литературе рассмотрен статистический криптоанализ и описание двух критерий проверки (К1 и К2) [1]. Для оценки возможности проведения линейного криптоанализа был рассчитан строгий лавинный критерий (СЛК) [4] для «Шифратора 125», так как он является показателем хорошей конфузии и диффузии [5]. Исходное сообщение одинаково для всех ключей («Текст для тестирования СЛК шт» в таблице UNICODE). Проводили 240 замеров для каждого ключа. В каждом замере изменяли один бит блока, а полученный шифртекст сравнивали с обычным шифртекстом сообщения. Для исследования использовали второй блок с данными, первый нормировочный блок не задействовали. Получены результаты, которые показывают, что «Шифратор 125» успешно выполнил СЛК для диффузии и конфузии (табл. 2), потому что эти значения практически полностью совпадают с поведением

Таблица 2. Результаты криптоанализа диффузии и конфузии шифра

Table 2. The results of cryptanalysis of diffusion and confusion of the cipher

	Максимальное отклонение от ½ среди всех битов блока	Кол-во бит, выполняющих строгий лавинный критерий с точностью 0.1	Кол-во бит, выполняющих строгий лавинный критерий с точностью 0.01	Лавинный эффект	Частотный анализ
Эталон, для расчета использованы ПСП	0.10	239	53	0.50
Диффузия, 1 раунд, небольшие блоки	0.50	0	0	0.02	нт К1:- K2: 26 %
Диффузия, 1 раунд, большой блок	0.09	240	33	0.50	■ К1:+ K2: 63 %
Диффузия, 3 раунда	0.09	240	51	0.50	К1:+ K2: 64 %
Конфузия, 1 раунд	0.50	0	0	0.49	-
Конфузия, 2 раунда	0.09	240	44	0.50	-

Таблица 3. Сравнительная таблица характеристик различных алгоритмов шифрования

Table 3. Comparative table of the characteristics of various encryption algorithms

Шифр Блок, бит Ключ, бит Возможность изменения таблиц замен Количество раундов Переменная фрагментация блоков замен и сложения с ключом IDEA 64 128 нет 8.5 нет SEED 128 128 нет 16 нет DES, 3DES, DESX 64 64, 112, 168, 184 нет 16, 48 нет Сamellia 128 128, 192, 256 нет 18, 24 нет ГОСТ Р 34.12-2015 128 256 нет 10 нет Twofish 128 128, 192, 256 нет 16 нет AES 128 128, 192, 256 нет 10, 12, 14 нет RC2, 4 (arcfour), 5, 6 32, 64, 128 0-2040 нет 1-255 нет ГОСТ 28147-89 64 256 да, 4 бит 16, 32 нет Blowfish 64 32-448 да, 8 бит 16 нет CAST5, 6 128 128, 160, 192, 224 да, 8 бит 48 нет Шифратор 125 240 0-5040< да, 0-240 бит 0-21< да псевдослучайной последовательности (ПСП). ПСП использовали вместо текста. При каждом новом замере брали новую ПСП и вычитали из первой ПСП, затем все характеристики рассчитывали как и при расчете СЛК шифра. Конфузия может определяться только для ключа раунда. С учетом наличия конфигурационного ключа ключ раунда может использоваться как временный ключ [1] или для имитозащиты (в протоколе на временных ключах). Необходимо добавлять второй раунд, если требуются хорошие показатели конфузии ключа раунда, или сцепку блоков.

Проанализированы данные по возможности применения известных атак на шифраторы [6-8]. Определен перечень возможных атак на шифр с оценкой устойчивости алгоритма шифрования к ним, в частности атака полным перебором: наибольшее количество свободных входных параметров «Шифратора 125» среди других широкораспространенных решений (табл. 3) делает его защищенным от данной атаки лучше, чем другие решения; статистический криптоанализ: наличие режима сцепки блоков с вектором инициализации из ПСП, успешное выполнение статистических тестов (например, частотного анализа) [1]; атака на основе связанных ключей: ключи всегда являются случайными последовательностями (принимаются по результатам выполнения статистических тестов, например частотного анализа); дифференциальный и интегральный криптоанализ: не имеет смысла, потому что S-блоки переменной длины со случайно сгенерированными неприводимыми многочленами [9], они могут быть большими и равными размеру блока с исходным текстом. Шифр не в режиме простой замены (кодовой электронной книги), так как использована сцепка блоков. Все это сводит на нет возможность взлома шифра по каждому раунду в отдельности, зная структуру небольших блоков замен.

Структура протокола на сеансовом уровне

Основным требованием к разработке структуры протокола сельскохозяйственного БПЛА [10, 11] является наличие параметров конфигурации протокола в зависимости от типа передаваемых данных: передача команд изменения конфигурации, критичных обновлений; передача управляющих команд и телеметрии; передача большого потока данных в реальном времени, например видео и звука, обновлений системы.

Для определения структуры защищенного протокола передачи данных сформулированы ключевые параметры, повышающие безопасность передачи данных для «Протокола 125»: длина блока или ключа шифрования, количество раундов шифрования, количество временных ключей на количество переданных зашифрованных данных. Эти параметры необходимо задать таким образом, чтобы для передаваемых данных получались шифртексты с высокими показателями криптозащиты. Параметр длины блока – один из немногих фиксированных значений. Учитывая наличие режима сцепки шифра, посылку временных ключей на определенный объем информации, аутентификацию и взятие хэша, в том числе учитывая наличие конфигурационного ключа в протоколе, менять его нет необходимости. Блок из 240 бит для таблицы UNICODE позволяет зашифровать 15 символов, иначе говоря, он работает «на уровне» слов и небольших словосочетаний. Повторения в словах достаточно редки, тем более в словосочетаниях, учитывая непредсказуемость смещения их начала, в отличие от символов. А благодаря сцепке по предыдущему шифртексту проблему повторений можно исключить практически полностью. Сцепка обеспечивает защиту от повторений в рамках одного временного ключа, смена временного ключа меняет все последовательности сцепок на новые, аутентификация и хэш каждого сообщения не дают возможности использовать какие-то его части, конфигурационный ключ делает неизвестным все свободные параметры «Шифратора 125». На рис. 2-6 можно ознакомиться с созданной схемой инициализации сессии протокола.

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

Сообщение замены параметров режима без уведомлений

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

Сообщение уведомления о корректности доставки замены временного общего ключа

*угеи1ифиеж*о» пог*>оеетжже

Теп «обще**

ПИЖ*»

Инициализация сессии "Протокола 125" для режимов передачи с уведомлением и t

TCtwwUDe с»г*ен1ы

Сообщение замены временного общего ключа иНфрСегарж количество сггувеОчыж сооОщеиан 10.

VI Тфшшио* / fKHNKTW

Ayiwn^euiep

TCP ши JDP общин ■№*• аге

Количество сл^ее^иеы» сообщении: К

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

Рис. 2. Схема работы протокола (часть 1)

Сообщение уведомления о корректности доставки замены параметров режима без уведомлений

Проверка передачи сессионного общего ключа приема для режима без уведомления. Защита от коллизии

Уведомление проверки передачи сессионного общего ключа приема для режима без уведомления. Защита от коллизии

Проверка передачи сессионного общего ключа передачи для режима без уведомления. Защита от коллизии

Рис. 3. Схема работы протокола (часть 2)

Уведомление проверки передачи сессионного общего ключа передачи для режима без уведомления. Защита от коллизии

TCP или UDP

Старая имитовставка (удаляемся после ус 1амошкмяя следукике* за текуией сессяя)

Идентификатор пользователя (начальная сцепка)

Аутентификатор пользователя

Тип сообщения

Новый временный общий ключ

Количество нормированных данных Случайное число

2 резервных поля из случайных чисел

Хэш данных (поби1оеая сумма

Служебный хэш

сех блокоя ?40 бит)

Нормированные

Количество служебных сообщении: 9.

(Защита от коллизии поля типа сообщения)

Идентификатор пользователя (начальная сцол«а| Шифр Солярис

тесты, то рекомендуется использовать предварительное сжатие данных

Сообщение уведомления о корректности доставки сообщения с данными №1

Старая имитовставка (удаляется после за текущей сессии) защита от коллизии

Рис. 4. Схема работы протокола (часть 3)

Предсохраненная имитовставка

Временный общий

Сообщение с данными №2

Рис. 5. Схема работы протокола (часть 4)

Сообщение уведомления о корректности доставки сообщения с данными №2

Сообщение без уведомления может приниматься и передаваться одновременно

Сообщение временного общего ключа приема для сообщения с данными №3 в режиме без уведомления

Сообщение временного общего ключа передачи для сообщения с данными №4 в оежиме без уведомления

Рис. 6. Схема работы протокола (часть 5)

Fig. 6. Protocol operation diagram (part 5)

конфиденциальности. Для дополнительной защиты от коллизий необходимо слать минимум 3-5 сообщений с одинаковой командой подряд. Шифртекст конфигурируется с лучшими показателями криптозащиты. Раунды можно увеличивать, так как не требуется большая скорость обмена информацией. В случае передачи команд управления или данных телеметрии скорость играет большую роль, но все равно можно при необходимости увеличить количество раундов. Так как данные команд управления не влияют на конфигурацию и постоянно обновляются, рекомендуется не защищать данные сообщения от возможности возникновения коллизий. Защита нужна, если параметр долго не обновляется и за это время оператор или программа может принять неправильное решение без возможности последующей корректировки. Тогда можно слать несколько сообщений, чтобы максимально снизить вероятность появления коллизий. Параметры телеметрии и управляющие команды можно отправлять в одном сообщении в соответствии с установленным параметром максимальной нагрузки данных на один временный ключ. В случае посылки потоковых данных большого объема, например видео или аудио, рекомендуется использовать только один раунд шифрования и режим без уведомлений.

Заключение

В результате проведенных исследований:

• •    произведен выбор программно-аппаратной платформы BeagleBone Black (BeaglePocket). Эта платформа позволяет внедрить разрабатываемый протокол в конструкцию БПЛА и использовать его для обеспечения защищенной передачи данных. Результаты тестирования непрерывности работы в процессе шифрования, энергопотребления платы подтвердили эффективность ее использования в БПЛА для обеспечения защищенного канала связи;

• •    результаты криптоанализа алгоритма шифрования протокола показали, что он лучше других широко распространенных алгоритмов устойчив к криптоатакам, так как имеет: наибольшее количество свободных входных параметров алгоритма; возможность изменения таблиц замен размером от 0 до размера блока шифра; переменную фрагментацию блоков на подблоки любого количества и любой длины;

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