comments

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

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

На основе комментариев рецензентов (см. ниже) вот несколько советов по использованию этих радиостанций, чтобы вы знали уровень предлагаемой защиты:

Вероятно, безопасность AES256 реализована «правильно», и наблюдатель не сможет расшифровать ваши сообщения.
Предупреждение: Если злоумышленник получит в своё владение одну из радиостанций, он сможет либо a) извлечь ключ канала из этого устройства, либо b) использовать эту радиостанцию для прослушивания новых коммуникаций.
Предупреждение: Если злоумышленник получит «код/URL QR-канала[^1]», который вы делитесь с другими, этот злоумышленник сможет читать любые сообщения, отправленные по каналу (как завтра, так и в прошлом — если он сохранил сырые копии этих широковещательных пакетов).

[^1]:

Текущая реализация обеспечивает опциональную конфиденциальность для участников настроенной сети:

Шифрование реализовано в устройствах/узлах с ключами шифрования на уровне всей сети.
Шифрование опционально и отключается, когда устройства находятся в «режиме Ham».
Шифрование не поддерживается в клиентах (iOS, Android) для облегчения распространения как массового ПО.
Сопряжение клиента с устройством происходит через:
Прямой USB-кабель
BT-сопряжение
Устройства «неразборчивы» и сопрягаются с любым ближайшим клиентом. Конфиденциальность сети требует физической защиты всех узлов.

Всегда помните о заметке xkcd о шифровании.

Если вы эксперт в криптографии, пожалуйста, ознакомьтесь с этими заметками и нашими вопросами ниже. Не поможете ли вы нам, изучив наши заметки ниже и дав совет? Мы с радостью укажем столько или так мало кредитов, сколько вы пожелаете ;-).
Существующее решение считайте «альфа-версией» и, вероятно, достаточно защищённым от не особо агрессивного противника (но мы пока не можем сделать более уверенного заявления).

Заметки для рецензентов

Если вы изучаете нашу реализацию, вот краткое описание нашего метода.

Мы выполняем всю криптографию только на уровне SubPacket (полезной нагрузки), чтобы все узлы Meshtastic маршрутизировали для других — даже те каналы, которые зашифрованы ключом, которым узел не обладает.
В основном основано на чтении Wikipedia и использовании режимов, поддерживаемых ESP32 на аппаратном уровне.
Мы используем AES256-CTR как потоковый шифр (с нулевой обрезкой последнего БЛОКА), поскольку он хорошо поддерживается с аппаратным ускорением.
Наш ключ AES — 128 или 256 бит, передаётся как часть спецификации «Channel».
Номер узла, объединённый с номером пакета, используется как NONCE. Этот nonce хранится во флэше устройства и по сути никогда не повторяется. Если пользователь создаст новый «Channel» (т. е. выберет новый случайный 256-битный ключ), номер пакета начнётся с нуля.
Номер пакета отправляется в открытом виде с каждым пакетом. Номер узла можно вывести из поля «from» каждого пакета. (Открытый текст приемлем, поскольку он просто предоставляет IV для каждой операции шифрования.)
Каждый 16-байтовый БЛОК пакета имеет увеличивающийся СЧЕТЧИК. СЧЕТЧИК начинается с нуля для первого блока каждого пакета.
IV для каждого блока формируется путём объединения NONCE как старших 96 бит IV и СЧЕТЧИКА как младших 32 бит. Поскольку наши пакеты маленькие, часть счётчика на практике никогда не превысит 32 (пять бит).

Комментарии рецензента №1

Этот рецензент — профессионал в криптографии, но желает остаться анонимным. Благодарим его за комментарии ;-):

Я предполагаю, что meshtastic используется для походов в местах, где кто-то способный пытается его взломать — как если бы вы ходили с этим по DefCon. Я потратил около часа на изучение шифрования и имею следующие замечания:

Описание не такое ясное, как код.
Код правильно использует режим AES-CTR для обеспечения конфиденциальности.
Комментарий к initNonce содержит всю необходимую информацию.
Думаю, больший вопрос по шифрованию — «что шифрование должно делать»? На данный момент злоумышленник, который ещё не захватил ни одного устройства, не может разумно захватить текст или данные о местоположении. Злоумышленник, захвативший любое устройство в канале/сети, сможет читать всё, что идёт на это устройство, всё, что хранится на нём, и любые другие коммуникации в канале, которые он захватил в зашифрованном виде. Если эта возможность в целом соответствует вашим ожиданиям и подходит для тех приключений, для которых это предназначено, то, на основе общедоступной или широко известной информации, шифрование хорошее. Если эти свойства вызывают беспокойство (например, история устройства намеренно ограничена, и вы не хотите, чтобы устройство, захваченное сегодня, угрожало информации, отправленной по каналу вчера), мы могли бы обсудить способы достижения этого (скорее всего, синхронизация времени и замена ключа его собственным SHA256 каждые X часов, а также обеспечение отсутствия ненужного хранения старого ключа).
Ещё две вещи, которые стоит учитывать: AES-CTR сам по себе не обеспечивает аутентичности (например, злоумышленник может переворачивать биты при повторной отправке данных и искажать результирующий открытый текст), и текущая схема даёт некоторые подсказки о передаче по размеру. Так что, если вы беспокоитесь о противнике, который намеренно портит сообщения или знает длину текстового сообщения, это может быть возможно.

Предполагаю, что сеть ведёт себя как сеть хранения и пересылки — или, по крайней мере, цель — избежать установления двустороннего соединения для передачи данных. К сожалению, я мало работал с mesh-сетями, но помню, что изучал их кратко в школе лет десять назад.

Комментарии от @Jorropo

Инициализация IV использует только 31 случайный бит при каждой перезагрузке, затем последовательно увеличивает номера сообщений. Это не очень много, дубликаты маловероятны, но возможны в масштабе всей сети. К счастью, IV включает младшие 32 бита MAC-адреса, который должен быть уникальным для каждого узла, так что каждый узел — свой собственный парадокс дней рождения, мы не ищем парадокс на уровне всей сети, который было бы легко взломать. См. #4031. Можно исправить.
Отсутствие целостности не было должным образом учтено, модуль удалённого администрирования реализует привилегированные RPC-вызовы поверх AES-CTR без MAC или AEAD. Можно исправить.
Реализация AES-CTR выглядит так, будто защищает конфиденциальность, предполагая отсутствие дубликатов IV.
Отсутствие прямой секретности немного беспокоит для чат-мессенджера, когда новые пользователи лишены параноидальных и раздражающих практик управления ключами, необходимых для безопасной работы.
По моему мнению, клиенты должны показывать большой красный блок в первый раз при открытии Direct-Message, указывая, что это не приватно и не E2E. Это не было ясно мне без чтения кода.
Этот проект полностью подходит для чата с незнакомцами, используя ключ по умолчанию и понимая, что всё публично, я бы не доверял ему ничего приватного без дополнительного слоя или значительной переработки. Например, я бы считал SSH или Signal поверх Meshtastic безопасными. Однако Meshtastic не выбирает худшую криптографию по плохим причинам, они делают сеть значительно удобнее для использования над ненадёжным медленным LoRa-каналом.