Интернет вещей по-русски. Безопасность в OpenUNB

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


    Для иллюстрации актуальности я приведу в пример протокол 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.

    Комментарии 4

      +1

      А можете на примерах описать, в чем основные проблемы безопасности в IoT?

        0
        Мы здесь больше рассматриваем не проблемы безопасности IoT в целом, а проблемы безопасности при передаче по радио. В этом смысле проблемы не сильно отличаются от типовых: скрытие номера абонента, шифрование и обеспечение подлинности и целостности данных при передаче.

        Можно придумать массу сценариев.

        Создатели CRISP выделяют существенно большую важность целостности и аутентичности сообщений, по сравнению с их конфиденциальностью. Может быть это и есть основная проблема безопасности IoT?
        +1
        А 256 бит для ключа не слишком мало? Там нет угрозы его взлома перебором?
          +1
          Нет, длины 256 бит достаточно. Это стандартная длина ключа для «отечественных» шифров Магма и Кузнечик, которые определены в ГОСТ Р 34.12-2015. А если смотреть на «зарубежный» AES, то у него возможна длина ключа 128, 192 или 256 бит.

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

        Самое читаемое