За последние десять лет масса технологий, имеющих хоть какое-либо отношение к информационным, претерпела множество изменений. Более того, многие сферы жизни, изначально не имеющие к IT никакого отношения, также преобразились до неузнаваемости и приобрели некий IT-шный бэкграунд. Немаловажную роль в этих процессах информатизации сыграла концепция Интернета вещей (IoT). С самого появления этой концепции было понятно, что она серьёзно повлияет на все сферы деятельности человека, экономические и социальные процессы, а спустя несколько лет после её появления технология оказалась на карандаше Национального разведывательного совета США и была занесена в список «подрывных инноваций».

По мере развития технологии IoT, ставшей устойчивой тенденцией на протяжении последних десяти лет, она наполнялась технологическим содержанием и практическими стандартами. При этом до некоторого времени комплексная информационная безопасность этой технологии вообще никого не волновала. Если внедрялись какие-то меры безопасности, то по остаточному принципу. Учитывая, что изначально никто никаких специальных стандартов для устройств IoT не разрабатывал, в основном использовали то, что было. Понятно, что «взрослые» варианты стандартов подходят для IoT не в полной мере. Требуются технологии, обладающие высокой производительностью в ограниченных средах. Устройства IoT связаны достаточно жёсткими ограничениями по питанию, памяти и вычислительным ресурсам. Если добавить к этому ненадёжные каналы связи, каналы с потерями, сильно ограниченные полосы пропускания и крайне динамичную сетевую топологию, то становится совсем кисло.

Спустя некоторое время IETF признал эту проблему, стандартизовав ряд облегчённых протоколов и технологий, разработанных специально для IoT, включая протокол ограниченных приложений (Constrained Application Protocol, CoAP), краткое представление двоичных объектов (Concise Binary Object Representation, CBOR) и сжатие заголовков статического контекста (Static Context Header Compression, SCHC).

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

Как я уже отметил, некоторые подходящие решения существуют. Например, подписание и шифрование объектов CBOR (CBOR Object Signing and Encryption, COSE), определяющее базовые службы безопасности на уровне приложений. Безопасность объектов для ограниченных сред RESTful (Object Security for Constrained RESTful Environments, OSCORE), представляющая собой упрощённое расширение безопасности для CoAP с использованием CBOR и COSE.

В этой статье речь пойдёт об адаптированной версии протокола обмена ключами Диффи-Хеллмана. 

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

Уже принятые протоколы безопасности типа COSE и OSCORE требуют безопасного обмена криптографическими ключами. Такой протокол обмена ключами должен быть «лёгким» и учитывать особенности IoT. Разработка и совершенствование Ephemeral Diffie-Hellman Over COSE (EDHOC) ведётся силами рабочей группы LAKE (Lightweight Authenticated Key Exchange Working Group), которая была сформирована в 2019 году, а первый проект протокола был опубликован только в июле 2020 года. На сегодняшний день актуален 20 драфт EDHOC.

Это очень компактный и лёгкий протокол с проверкой подлинности, предназначенный для использования в сценариях с ограничениями. Он позволяет использовать различные методы аутентификации, основанные либо на подписях, либо на статических долгосрочных ключах DH (Diffie-Hellman). Также протокол предусматривает возможности обеспечения постквантовой безопасности, заменяя получение ключа механизмом инкапсуляции ключей (Key Encapsulation Mechanism, KEM). Примитивы CBOR и COSE встроены в сообщения протокола, но EDHOC не привязан к конкретному транспорту.

Краткое представление двоичных объектов CBOR — формат данных, разработанный для небольшого размера кода и небольшого размера сообщения. Он основывается на модели данных JSON, но расширяет её, например за счёт прямого кодирования двоичных данных без преобразования base64. Подписание и шифрование COSE описывает, как создавать и обрабатывать подписи, коды аутентификации сообщений и шифрование с использованием CBOR. Оно основано на JOSE, но адаптировано для обеспечения более эффективной обработки на ресурсо-ограниченных устройствах.

Я нашёл несколько исследований безопасности различных версий протокола. Часть обнаруженных уязвимостей была исправлена в последующих версиях. Некоторые исследования проводились с помощью платформы Sapic+ и программных средств автоматизированного анализа свойств безопасности криптографических протоколов ProVerif, Tamarin Prover и DeepSec. Современные инструменты автоматизированного анализа символьных протоколов действительно способны решать поставленные задачи, в частности они успешно использовались для поиска слабых мест в ранних версиях стандарта 5G и активно применялись в процессе стандартизации TLS 1.3.

Краткое описание протокола EDHOC

EDHOC направлен на предоставление общего сеансового ключа двум сторонам, потенциально работающим на устройствах с ограниченными возможностями, и может работать с несколькими методами аутентификации: каждая сторона (инициатор и ответчик) может использовать метод аутентификации либо со схемой подписи (SIG), либо со статическим ключом Диффи-Хеллмана (STAT).

EDHOC на базе подписи построен на варианте протокола SIGMA. Так же как и протокол туннелирования IKEv2, EDHOC реализует вариант MAC-then-Sign протокола SIGMA-I. Поток сообщений (за исключением необязательного четвёртого сообщения) показан на рисунке ниже.

G_X и G_Y — эфемерные открытые ключи ECDH I и R соответственно.

CRED_I и CRED_R — учётные данные аутентификации, содержащие открытые ключи аутентификации.

ID_CRED_I и ID_CRED_R используются для идентификации и, при необходимости, передачи учётных данных инициатора и ответчика.

Sig(I; ...) и Sig(R; ...) обозначают подписи, сделанные с использованием закрытого ключа аутентификации.

Enc(),  AEAD() и MAC() обозначают шифрование и код аутентификации сообщения.

Для полноценной работы EDHOC добавляет некоторые дополнительные элементы протокола:

• Хэши расшифровки (хэши данных сообщения) TH_2, TH_3, TH_4, используемые для получения ключа и в качестве дополнительных аутентифицируемых данных.

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

• Необязательное четвёртое сообщение, предоставляющее подтверждение ключа для I в развёртываниях, где данные защищённого приложения не отправляются из R в I.

• Экспортёр ключевых материалов и функцию обновления ключей.

• Безопасное согласование комплекта шифров.

• Выбор идентификаторов соединения C_I и C_R, которые могут использоваться в EDHOC для идентификации состояния протокола.

• Транспорт внешних авторизационных данных.

Протокол состоит из трёх обязательных сообщений (сообщение_1, сообщение_2, сообщение_3), необязательного четвёртого сообщения (сообщение_4) и сообщения об ошибке между инициатором I и ответчиком R. Нечётные сообщения отправляются I, чётные — R. Как I, так и R могут отправлять сообщения об ошибках. Роли имеют немного разные свойства безопасности, которые учитываются при их назначении для защиты наиболее конфиденциального идентификатора, обычно такого, который невозможно вывести из маршрутной информации на нижних уровнях.

Все сообщения EDHOC представляют собой последовательности CBOR и закодированы. На рисунке ниже показан поток сообщений EDHOC с необязательным четвёртым сообщением, а также содержимым каждого сообщения.

Элемент данных METHOD в сообщении_1 представляет собой целое число, определяющее один из четырёх методов аутентификации, которые я указал в таблице выше. При использовании статического ключа Диффи-Хеллмана аутентификация обеспечивается кодом аутентификации сообщений MAC, вычисляемым на основе эфемерно-статического общего секрета ECDH, что позволяет значительно уменьшить размер сообщений. При этом инициатор и ответчик должны согласовать метод, который будет использоваться для реализации EDHOC. Для сокращения размера сообщений протокол не имеет специального поля для указания версии протокола.

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

Криптографически протокол не предъявляет никаких требований к нижним уровням. Как я уже упоминал, он не привязан к конкретному транспортному уровню и может использоваться даже в средах без IP. В дополнение к передаче сообщений, включая ошибки, при необходимости транспорт отвечает за обработку потерь, переупорядочивание, дублирование, управление потоком сообщений, фрагментацию и сборку, демультиплексирование сообщений EDHOC из других типов и защиту от DoS.

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

Набор шифров EDHOC состоит из упорядоченного набора алгоритмов из реестров «Алгоритмы COSE» и «Эллиптические кривые COSE», а также длины MAC-адреса EDHOC. Длина MAC-адреса EDHOC должна быть не менее 8 байтов.

Он поддерживает все алгоритмы подписи, определенные COSE. Как и в (D)TLS 1.3 и IKEv2, подпись в COSE определяется совместно алгоритмом подписи и алгоритмом ключа аутентификации. Точные детали алгоритма проверки подлинности ключа зависят от типа учётных данных проверки.

Каждый набор шифров идентифицируется предопределенной целочисленной меткой. EDHOC можно использовать со всеми алгоритмами и кривыми, определенными для COSE. Реализации могут использовать либо любую комбинацию алгоритмов и параметров для определения собственного частного набора шифров, либо один из предварительно определённых наборов. Частные наборы шифров могут быть идентифицированы любым из четырёх значений -24, -23, -22, -21. Предварительно определённые наборы шифров перечислены в реестре стандарта.

Наборы шифров 0-3, основанные на AES-CCM, предназначены для IoT с ограничениями, где накладные расходы на сообщения являются очень важным фактором.

Наборы шифров 1 и 3 используют длину в 128 бит, а в алгоритме Application AEAD – 64 бита.

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

Набор шифров 6, основанный на AES-GCM, предназначен для обычных приложений без ограничений. Он состоит из высокопроизводительных алгоритмов, которые широко используются в приложениях без ограничений.

Наборы шифров 24 и 25 предназначены для приложений с высоким уровнем безопасности, таких как государственные и финансовые приложения. Набор шифров 24 состоит из алгоритмов набора CNSA.

Итак, рассмотрим небольшой пример формирования ключа. 

Для этого выберем метод аутентификации 3 (оба респондента используют статический метод аутентификации на основе Диффи-Хеллмана, STAT/STAT) и набор шифров 0 и 2. Разница между Cipher Suite 0 и Cipher Suite 2 заключается в выборе эллиптической кривой. Поскольку обе кривые обеспечивают одинаковые гарантии безопасности и различаются только реализацией, мы не включаем идентификатор набора шифров Suites_I в первое сообщение протокола.

В реестре ключей EDHOC псевдослучайные ключи (PRK) получаются с использованием функции извлечения. В контексте наборов шифров 0 и 2 используется алгоритм хэширования SHA-256. Следовательно, согласно стандарту Extract(соль, IKM) = HKDF-Extract(соль, IKM) определяется с помощью SHA-256, где IKM (input keying material) входной ключевой материал (в текущем примере это ключи Диффи-Хеллмана) и Expand(PRK, info , length) = HKDF-Expand(PRK, info, length), где info содержит хэш расшифровки (TH₂, TH₃или TH₄), имя производного ключа и некоторый контекст, а length – выходная длина в битах.

Во время обмена ключами происходит несколько криптографических вычислений. Ключевой материал, включая ключи MAC (поскольку взят метод STAT/STAT), ключи шифрования и векторы инициализации основаны на реестре ключей, адаптированном из формального анализа, представленного на Международной конференции по безопасности и криптографии (SECRYPT ’21). На рисунке фиолетовые прямоугольники обозначают общие секреты Диффи-Хеллмана (g^x_e^y_e, g^y_s^x_e, g^x_s^y_e), где x_e и y_e — эфемерные ключи DH, а x_s и y_s — долговременные статические ключи DH. Из этих общих секретов Диффи-Хеллмана извлекаем псевдослучайные ключи PRK_2e, PRK_3e2m и PRK_4e3m, выделенные синим цветом (индекс PRK указывает на его использование или на то, в какой операции защиты сообщений он задействован. Например, PRK_3e2m участвует в шифровании сообщения_3 и в вычислении MAC-адреса сообщения_2).

Затем эти ключи расширяются для вычисления материала шифрования (выделено красным цветом) и тегов аутентификации t₂ и t₃ (жёлтый цвет). Ключи PRK_2e и PRK_3e2m также используются для вычисления солей  salt_3e2m и salt_4e3m соответственно, выделенных зелёным цветом, которые используются в функции HKDF-Extract. Окончательный ключ сеанса PRKout выделен тёмно-зелёным цветом, вычисляется при вызове HKDF-Expand на PRK_4e3m. Хэши расшифровки, обозначаемые как TH_i, используются в качестве входных данных для функции HKDF-Expand.

Точнее, с SHA-256 (H):

где m₁ — первое сообщение, отправленное инициатором, m₂ и m₃ — открытые тексты, зашифрованные в сообщении_2 и сообщении_3.

Как описано выше, наборы шифров, которые мы выбрали, используют AES-CCM-16-64-128. В итоге детализированная схема аутентифицированного шифрования будет выглядеть следующим образом:

В AES-CCM-16-64-128 алгоритм AES-128 выбран в качестве алгоритма блочного шифрования, используя ключ, nonce, сообщение и заголовок в качестве входных данных. AES-CCM режим AES, обеспечивающий как шифрование, так и аутентификацию. Этот режим сочетает в себе режим шифрования CBC-MAC и CTR (счётчик). Первый шаг состоит в вычислении тега T, затем шифровании сообщения и тега с использованием режима счётчика. Nonce — длиной 13 байт, что позволяет использовать 2^13×8 возможных значений nonce без повторения.

В конце сеанса протокола инициатор и ответчик вычисляют TH₄. Это значение можно использовать, если приложению необходимо экспортировать сеансовый ключ EDHOC. Кроме того, в случае необходимости обновления ключа респонденты повторно запускают HKDF-Extract с PRK_4e3m в качестве входных данных вместе с согласованным nonce. Окончательный сеансовый ключ SK = PRK_out.

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

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

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

В общем, время покажет.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS