Канальный уровень

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

Так как канальный уровень OpenUNB довольно сложен, я решил разбить его на подсистемы и описывать их в отдельных статьях. Кстати, приведу список всех наших статей об OpenUNB:

• Интернет вещей по-русски. Минимализм и открытость OpenUNB
• Интернет вещей по-русски. Многоканальная мощь физуровня базовой станции OpenUNB
• Интернет вещей по-русски. Помехоустойчивое кодирование в OpenUNB

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

Канальный уровень отвечает за механизм управления доступом устройств к радиоканалу (Media Access Control, MAC) и механизм управления логической связью (Logical Link Control, LLC) между устройствами и сервером сети.

Канальный уровень определяет:

1. механизм множественного доступа устройств к радиоканалу;
2. механизм повторных передач пакетов;
3. формат пакетов канального уровня и алгоритм их формирования;
4. схему адресации устройств;
5. процедуру активации (аутентификации и регистрации) устройств на сервере;
6. механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).

Сегодня мы рассмотрим первые четыре пункта списка.

Для обеспечения множественного доступа устройств к радиоканалу в сети используется неслотированная частотная ALOHA. Частота передачи каждого пакета должна выбираться устройством случайно из всей полосы рабочих частот приема шлюзов. В случае если передача пакета осуществляется с повторами, для каждой очередной передачи должна выбираться случайная частота отличная от частот, выбранных для предыдущих передач пакета.

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

Формат пакета OpenUNB по уровням:

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

В эти шесть байт входят адрес (DevAddr) и проверочное слово (MIC). Обе эти части имеют одинаковый размер (три байта) и простые, но тщательно отточенные разработчиками свойства.

Слово DevAddr это временный адрес устройства. В лирическом отступлении можно отметить, что мало можно найти протоколов IoT, в которые внедрена концепция временных адресов, хотя в сотовой связи она присутствует начиная со стандартов 2G. В OpenUNB временный адрес (меняется каждые 4 часа) формируется криптографически из базового ключа K0, привязанного к DevID, назначение которого имеет необыкновенную гибкость. Во-первых, DevID может не быть уникальным. Пользователь даже может назначить DevID случайным образом. Уникальность DevID придаст назначение соответствующего ему базового секретного ключа K0. Во-вторых, нет даже требований к длине DevID. Стандарт требует иметь его длину не менее 4 байт, но рекомендует длину 16 байт. В-третьих, такая гибкость приводит к возможности назначать DevID в разных сетях децентрализовано, не сверяясь друг с другом.

Если говорить точно, временный адрес DevAddr вырабатывается так:

где Ne номер эпохи (время), а Ka ключ активации, который получается так:

где Na номер активации, а K0 базовый секретный ключ.

Процедуры ECB и CTR здесь это криптопреобразования "режим простой замены" и "режим гаммирования", соответственно. Эти процедуры определены в стандартах шифрования ГОСТ.

Таким образом, если считать криптопреобразования стойкими, а ключ K0 секретным, связь между DevID и DevAddr экономически оправданным способом установить не получится. Поэтому третья сторона не может сопоставить пакеты в эфире с конкретным устройством IoT, не зная ключ K0. Какой еще протокол IoT может похвастаться таким удивительным свойством?!

Слово MIC, проверочное слово, уникально. Оно имеет по меньшей мере две ипостаси: это имитовставка и слово контроля целостности в одном лице. За счет этого двойного назначения получается немалая экономия в объеме данных, а значит и в энергии, потребляемой устройством. Есть еще третья функция MIC, скрытая от неискушенного читателя. Это конкретизация соответствия DevAddr и DevID. Очевидно, ввиду малости длины DevAddr, это поле не будет уникальным для всех DevID, по крайней мере это не гарантируется криптопреобразованиями. Но существует связь DevAddr и MIC, которая определяется секретным ключом K0 и другими параметрами. Если говорить точно, то чудо-слово MIC получается так:

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

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

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

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

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

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

Как обычно, теоретическая проработка у нас сразу вытекает в практику. Исходники криптопреобразований для оконечного устройства уже можно найти на Github.

Кстати, физический уровень нами уже сделан и сейчас проходит проверку на местности. Вы уже можете взять исходники передатчика оконечного устройства и приемника базовой станции и опробовать дальность работы самостоятельно. Для этого нужно минимальное железо. Заинтересованных прошу обращаться. Мы поможем консультацией первым энтузиастам. Наш бессменный программист deef137 всегда на связи.

Пока писалась эта статья, пришла отличная новость: стандарт опубликован на сайте Сколтеха. Теперь полная картина не ускользнет от вас.

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

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

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

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

В OpenUNB активация устройства производится пользователем. Также необходим доверенный канал между пользователем и сервером сети. Схема взаимодействия представлена ниже:

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

В стадии "запрос на активацию" пользователь должен по служебному каналу отправить на сервер запрос на активацию, в котором передается идентификатор DevID активируемого конечного устройства. Если активация возможна, то сервер сообщает об этом. Далее пользователь делает "запуск процедуры активации на устройстве". Это может быть пакет по радио-интерфейсу или другому, удобному. Это также может быть нажатие кнопки "активация" или просто включение питания устройства. После этого события устройство передает "служебный пакет активации", в котором содержится номер текущей активации.

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

Рассмотрим подробно процедуру со стороны устройства и со стороны сервера.

Со стороны устройства процедура выглядит так:

1. проверяется текущее значение счетчика активаций Na. Если счетчик активаций уже достиг максимально возможного значения, то данное устройство больше не может использоваться, и выключается;
2. увеличивается значение счетчика активаций: Na = Na + 1;
3. вырабатывается ключ активации Ka;
4. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
5. формируется служебный пакет активации, в поле MACPayload которого содержится текущее значение счетчика активаций Na, а в качестве адреса указывается DevAddr0 = CRC24(DevID). При этом поле MACPayload передается в открытом виде (не шифруется), а поле имитовставки MIC рассчитывается на ключе Km для номера Nn = 0. Сформированный служебный пакет активации должен быть отправлен MAX_PKT_TX_NUM раз подряд для повышения вероятности его доведения;
6. устройство считает активацию успешно завершенной и может передавать пакеты полезных данных.

Напомним формат пакета OpenUNB:

Сервер по приему пакета активации ищет адрес из пакета в списке адресов активированных устройств. Для каждого из найденных совпадений:

1. сохраняется полученное значение счетчика активаций устройства Na. Если для данного устройства ранее уже осуществлялась успешная активация, то сервер должен дополнительно проверить, что текущее значение Na больше чем значение Na, полученное при предыдущей успешной активации. Если эта проверка завершается неуспешно, то сервер переходит к следующему найденному устройству;
2. вырабатывается ключ активации Ka;
3. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
4. для пакета проверяется совпадение имитовставки MIC на ключе Km для номера Nn = 0.

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

Детали работы процедур активации OpenUNB смотрите в первоисточнике на сайте Сколтеха.

Реализованные процедуры активации и другие процедуры безопасности доступны в исходниках здесь.

Наш бессменный мастер Интернета вещей deef137 всегда на связи и готов помочь с вопросами по коду.

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

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

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

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

• Интернет вещей по-русски. Минимализм и открытость OpenUNB
• Интернет вещей по-русски. Многоканальная мощь физуровня базовой станции OpenUNB
• Интернет вещей по-русски. Помехоустойчивое кодирование в OpenUNB
• Интернет вещей по-русски. Канальный уровень OpenUNB. Общие положения и адресация устройств
• Интернет вещей по-русски. Процедура активации OpenUNB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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