08.03.2021 10:06
itsar 4 2900 Источник

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


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


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


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



а также изучить первоисточник на сайте Сколтеха.


Сегодня мы рассмотрим механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).


Чтобы обеспечить базу безопасности, у каждого устройства и сервера должно быть что-то общее, секретное, которое никто не знает. В OpenUNB это секретный ключ шифрования K0, имеющий длину k, равную 128 или 256 бит. Весь остальной протокол должен быть сделан так, чтобы этот базовый, основной ключ не стал бы известен никому никаким образом, а информация при этом была защищена. Поэтому базовый ключ претерпевает такое множество преобразований в своем стремлении встретиться с информацией.


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


В недрах устройства и сервера OpenUNB есть счетчик активаций Na и счетчик эпох Ne, которые остаются примерно одинаковыми в процессе работы системы. Сначала вырабатывается ключ активации:


$ Ka = CTR (K0, Na || 0^{n/2-16}, 0^k).$


Потом уже по ключу активации вырабатываются рабочие ключ шифрования Km и ключ имитозащиты Ke:


$ Km = CTR (Ka, 0x02 || Ne || 0^{n/2-32}, 0^k),$


$ Ke = CTR (Ka, 0x03 || Ne || 0^{n/2-32}, 0^k).$


Для криптографических преобразований разработчики OpenUNB рекомендуется использовать блочный шифр «Магма», который имеет длину блока n = 64 бита и длину ключа k = 256 бит, определенный в стандарте ГОСТ Р 34.12-2015.


Шифрование выглядит так:


$ EncryptedMACPayload = CTR (Ke, Nn || 0^{n/2-16}, MACPayload),$


где Nn — номер пакета, а выработка имитовставки так:


$MIC = CMAC24 (Km, P),$


где значение вектора P зависит от длины блока n и длины поля MACPayload. Пусть len –
однобайтная целочисленная беззнаковая переменная, равная длине полезных данных
MACPayload в битах (переменная len может принимать значения 16 или 48), тогда:


если len = 48 и n = 64, то


$P = DevAddr || MACPayload || Nn || 0^{2n-len-48} || len;$


в остальных случаях


$P = DevAddr || MACPayload || Nn || 0^{n-len-48} || len.$


Процедура CMAC24 здесь это криптопреобразование "режим выработки имитовставки" согласно ГОСТ.


Далее эти поля вставляются на свои места. Напомним схему формирования пакета:
image


Более подробно, со всеми деталями, вы можете прочитать о безопасности в OpenUNB в первоисточнике.


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


Как всегда, исходники крипто-преобразований от deef137 доступны на Github.