Комментарии 20
Осталось неясным почему логин надо менять на CN и зачем сертификаты хранить отдельно от прошивки.
По поводу сертификатов и софта (прошивки). Это весьма разнородные артефакты, отличающиеся своим жизненным циклом и назначением. Если сказать проще, то при разделении решается ряд задач:
1) возможность подключения к разным хостам;
2) очевидное исключение пересборки ПО для каждого экземпляра;
3) разделение труда )) - разработчики выдают софт, далее производство - генерация ключей с привязкой к конкретной инфраструктуре и прошивка в один или два такта;
4) получаем однотипный процесс производства для разных проектов.
Теперь про CN. Спасибо за вопрос!
Если отбросить философию, то это своего рода аутсорсинг администрирования клиентов инфраструктуры, переданный на уровень CA. Плюшки тут такие:
1) исключен доступ из кода к модификации identity устройства;
2) администрирование клиентов средствами CA, а не брокера (например, в Mosquitto не нужно пилить файл с паролями);
3) схема работает не только с Mosquitto, но и с NATS (без доработок ПО на устройствах);
4) исключает влияние программных ошибки при использовании "именных" топиков (за счет паттернов ACL).
Как-то много файлов и действий получается.
А не думали просто по одному уникальному топику каждому устройству делать, и в нем посылать сжатые данные? И трафик бы экономился и не надо было бы заниматься управлением доступом к топикам и аутентификацией клиентов.
Я понимаю и разделяю вашу мысль. Разработчики зачастую не проникаются темой девопса и CI/CD, тем более в iot, где и без этого переизбыток области знаний. Поэтому и отсылка к "много" файлов. Но гляньте на тьму файлов при сборке приложения... Это не более чем задача автоматизации на этапе производства партии устройств.
Далее, насчет уникального топика - в моей статье нет противоречий этому, а даже наоборот. Однако, чтобы дать целостную уникальность топику мы подставляем в имя топика CN, а на брокере строго контролируем топики по паттерну с помощью ACL. Думаю, это понимание и его пользу надо просто пережить на практике, либо проникнуться изучением бест практик. Разработчики брокеров не зря это запилили в базовых продуктах.
И, вот более крутая тема - это "сжатие".
Для этого нужно ощутить трафик сети, реальный поток данных в самом узком месте - как правило центральной очереди обработки сообщений. Если есть "мясо", которое нужно жать, то нужно применить Apache Avro или Google protobuf. В зависимости от ядра экосистемы.
Мне вот доводилось строить систему на базе сериализации Avro и Kafka в центре ядра. И этот вариант был именно осознанным, вымученным жизнью вариантом.
Теперь, что касается управления аутентификацией. Совершенно соглашусь, что очень хочется пустить на самотек и думать, что все узлы можно строго в своем софте и БД назначить, прописать и т.п. Но, вот опыт эксплуатации разных продуктов-проектов показал на практике, что смена команд, масштаб в несколько сотен тысяч (да даже десятков тысяч), какие-то периодические сбои в репликациях БД, постоянные переделки скриптов на производстве .человеческий фактор - все это приводило к появлению массовых информационных клонов на уровне узлов сети и прочего гемора с "полуручной" аутентификацией устройств.
И все это привело к более строгому следованию идеологии выделения задачи аутентификации узлов сети на уровень центральной инфраструктуры, где это является типовой задачей вне зависимости от типов клиентских платформ.
Мой метод описан в этой статье в параграфе где речь идет о MQTT.
Проблема Apache Avro или Google protobuf в том что это глубоко чуждые embedded протоколы не считающиеся с ограничением ресурсов и не снабженные никакими визуальными тулсами быстрой разработки.
Отлаживать такое на ESP у которого из отладки только рудиментарный JTAG это еще тот челендж.
Ваш способ аутентификации сильно привязан к серверу брокера. Чтобы устройства могли переключиться на другого брокера им нужно еще выслать сертификатов. А как эти сертификаты доставить? Без сертификатов, это можно было бы сделать просто задав новые логины через того же брокера.
Mosquitto конечно хороший брокер, но задосить его если используется аутентификация клиентов по сертификатам станет еще проще.
Защита самой прошивки устройств тоже никак не улучшается. Но сильно усложняется менеджмент. Кроме версиии прошивки теперь надо следить за версией сертификата, за версиями там разных ключей и проч.
А там еще какое-то скопище топиков у вас присутствует раз им нужен целый ACL. По моему вот этот ACL и будет камнем преткновения. Печальный опыт столкновения с такими вещами на десктопах свидетельствует.
Использование ACL намного проще. В минималке нужна всего 1 строка, содержащая паттерн подстановки в топик clientId или username. Например, паттерн
pattern write my_sensor/%c/state
будет гарантировать, что в имени топика (%c)присутствует наш CN. И если устройство по причине ошибки в коде вдруг пишет мимо указанного топика, то сообщения просто дропаются. Также, это гарантирует, что автор сообщения в этот топик именно то устройство, которому выдан соответствующий сертификат.
Что касается привязки к брокеру, то да, она выполняется без модификации (пересборки) артефакта с прикладным софтом, а уже после - на этапе производства партии устройств с условием взаимодействия данной партии с конкретной постоянной инфраструктурой. Без необходимости замены сертификатов в процессе эксплуатации.
Если пришло осознание, что нам нужно переключить хост/инфраструктуру/заменить сертификаты именно на этапе продакшена, то все в руках разработчика - через ОТА можно сделать исключение (костыль) в этой концепции и перейти на любой другой вариант.
Что касается дилеммы "напилить новых логинов в файл mosquitto с логинами" или "нагенерить партию сертификатов", то вопрос очень многофакторный. Нельзя однозначно сказать, что есть правильно, а что нет без оценки факторов. Наиважнейший из которых - это инженерный бэкграунд изготовителя, а также различные требования безопасности, включающие вопрос единой точки управления аутентификацией.
Насчет ддоса вопрос очень интересный. Думается так, раз у нас проект разросся до проблем с ддосом от собственной сети, то скорее всего у нас есть возможность применить не только жирнючий сервак для Mosquitto, но и балансировщики, среди которых есть выдающиеся экземпляры, работающие на 7 уровне, способные не только переключать бекенды по нагрузке, но и парсить сертификаты используя их для роутинга сообщений по бекендам. Я бы так сказал, что в данном случае узкое место не в сетевой инфраструктуре и не в нагрузке на сервера аутентификации, ведь это хорошо изученные истории, имеющие массу решений на уровне инфраструктуры.
И вот еще важный момент. Т.к. в нашей схеме мы никогда не копаемся в файлах Mosquitto с логинами/паролями, то вся инфраструктура брокера плавно и на 100% переходит в зону ответственности девопсов и админов.
Ваше замечание про AVRO вполне справедливо. Я немного погорячился, выйдя за контекст статьи и ESP32. Вспомнился удачный кейс сети на Embedded-Linux, в котором применение AVRO и проброс бинарного потока сообщений в экосистему Kafka (с нативным AVRO) были просто идеальной находкой для оптимизации. Однако, на ESP32 или на младшие кортексы это в лоб натягивать не стоит, хотя некоторые идеи на эту тему есть.
Согласен что обоюдная аутентификация выглядит надежней чем односторонняя только сервера. Но тогда как отключить клиентов от обслуживания брокером если это требуется? Но и пароли на стороне брокера тоже вызывают дополнительные административные действия.
Поэтому в своем решении я отказался и от того и от другого. Пароль один на всех.
Соединения то все равно шифрованные. Аутентификация и распределение данных по узлам выполняется в самом приложении клиенте брокера.
Прошивка содержит весь криптоматериал уже в себе. Пересобирать прошивку для смены криптоматериала не надо. Из map файла известно где он размещается в прошивке, и вся процедура замены выполняется как патч бинарника. Бинарник прошивки сжимается, шифруется и подписывается. Если дивайс взломали, то меняется вся прошивка с криптоматералом одновременно. У нас такой нюанс, что производство мелкосерийное, и прошивки меняются очень часто, чаще чем пароли.
Кстати паролей и всяких ключей в развитых IoT дивайсах гораздо больше чем упомянуто в вашей статье. Нужно ведь еще всех обеспечить уникальными паролями WiFi, дать пароль встроенному FTP серверу, сертификатами обеспечить встроенный WEB сервер, нужен пароль доступа по Telnet, пароль для Bluetooth, пароли на носители данных, клиентские пароли к внешним FTP, к облачным сервисам и т.д. и т.п. Это ж все желательно интегрировать в единую централизованную систему учета и генерации паролей и ключей.
Для отключения клиентов в данном случае нужно добавить механизм отзыва сертификатов.
В конфиге Mosquitto добавить путь (ссылку) на CRL файл со списком отозванных сертификатов.
crlfile file path
Далее, этот список администрируется уже со стороны CA, например утилитой openssl.
В моей статье приведен несколько упрощенный вариант работы с CA. Для полноты Однако, показана основная идея разделить задачи администрирование клиентов и прикладной разработки, сосредоточение вопроса аутентификации в рамках PKI и возможность переиспользования существующей PKI для серии embedded-проектов.
По поводу того, что "дивайс взломали" в моей статье как раз собраны все возможности и рекомендации Espressif по снижению рисков. Если их резюмировать, то вот:
1) включить Secure Boot 2;
2) включить Flash Encryption;
3) использовать только уникальные ключи для Flash Encryption, после прошивки их в eFuse желательно сразу удалить;
4) включить Release mode;
5) отключить UART-загрузчик;
0) держать в секрете ключ подписи бутлоадера и ПО.
Т.е. приходим все к тому же - возле брокера Mosquitto нужно держать некую базу данных связанную с информацией о всех IoT устройствах в сети. Чем это сильно отличается просто от базы данных паролей? База паролей хоть короче будет.
Надо учесть что Mosquitto это однопоточное приложение и стараться не нагружать его слишком сильно. Я вообще Mosquitto рассматриваю как удобный прокси и не более. Чем меньше на стороне брокера информации об инфраструктуре, чем меньше топиков тем лучше. Само создание и управление топиками изначально содержит в себе сложность администрирования. Оправданную только для очень примитивных дивайсов, типа ранних PIC-ов программировавшихся на ассемблере, которых и в сети уже давно нет.
А то что у вас само-подписанные сертификаты взломщики узнают прямо сразу, проанализировав трафик какого-нибудь одного IoT устройства. Поймут, что взломав брокера они сразу завладеют всей вашей сетью и что это отличный способ шантажа.
Способ защиты прошивки, который вы описали вполне понятен. Это стандартный путь, он такой у всех известных производителей микроконтроллеров. Только у вас он ещё усложнён архаичным API от Espressif c отсутствием сериализаторов (вместо этого NVS) и файловой системы и необходимостью сохранять прошивку на внешней Flash. Из-за этого возникают дополнительные задачи по планированию размещения и размеров разделов (партиций) на Flash и размножение артефактов.
Кстати про взлом. На хабре уже много статей об этом. Взламывают сам кристалл и читают eFuse. Процедура отработанная и достаточно недорогая. Т.е. сразу надо предполагать что "партнёрам" будет через некоторое время известна вся прошивка и ключи. Тут надо ориентироваться либо на чипы с неклонируемыми ключами, либо с очень сильной аппаратной защитой ключей и очень мобильную инфраструктуру, которую можно на лету заменить или переместить.
Да, вокруг брокера нужна инфраструктура CA. Которая фактически является типовым промышленным способом защиты сети, все практики хорошо известны и не отличаются от типа узла - будь то Windows клиенты или embedded. И с точки зрения сети, это скорее брокер встраивается в PKI.
Сертификаты брокера и клиентов не являются самоподписанными, если внимательно посмотреть на мой пример, то там приведен минимальный вариант развертывания CA. Который, в свою очередь, подписывает все далее возникающие сертификаты и crl-списки. Все это является уже классикой для сферы защиты сети. В таких конструкциях самым главным секретом является ключ CA. Это аксиомы PKI.
Что касается взлома, то скорее всего речь про кейс CVE-2023-35818, EMFI (Electro Magnetic Fault Injection) атака на чип. Если внимательно изучить отчет инженерной группы, проводившей взлом, то становится очевидным несколько моментов:
1) нужен физический доступ к конкретному дивайсу;
2) последовательность манипуляций, наличие спец оборудования и крутых инженеров - все это напоминает небольшой инженерный подвиг ради взлома одного экземпляра;
3) распространить оптом на всю сеть результаты взлома не получится, при условии, что ключи Flash Encryption создаются уникальными для каждого экземпляра (я об этом упомянул в статье);
4) прошивку в результате такого взлома подделать нельзя, т.к. ключ подписи Secure Boot 2 в дивайсе отсутствует (там только открытый дайджест);
5) экономический смысл такого взлома отсутствует;
6) думается, что гораздо проще все сломать средствами социальной инженерии.
Однако, понимание рисков мы держим как фактор. Появляются различные Security Advisory с описанием тех или иных уязвимостей в разных версиях чипов, т.е. нет гарантии, что в скором будущем ваше изделие не будет взломано.
Поэтому, в "денежных" и критических дивайсах строго-настрого требуется использование простых крипто-чипов для хранения ключей, либо более серьезных крипто-сопроцессоров. Без их использования будет невозможно, например, пройти какую-нибудь специализированную сертификацию устройства.
И, да, при использовании крипточипов задача использования CA играет похожими красками, что и описано в статье. Только с одним отличием - сертификат запихивается в крипточип. Кстати, для ESP32 в ESP-IDF включен один из простых кейсов "дополнительной аппаратной защиты" - возможность работать с ATECC608.
Известность практик не означает их практичность. Дивайсы не обращаются к авторизированным центрам, и этого хватает чтобы сильно облегчить захват управления.
Не вижу препятствий к физическому доступу к дивайсам. Даже банкоматы целиком утаскивают для реверса.
Команда сильно профессиональная не нужна. Вы наверно в курсе что контрафактные картриджы для принтеров сделаны даже не на копиях чипов защиты, а на других чипах повторяющих архитектуру оригинальных. А я мог бы сказать адрес подвала где все это делали.
Простые крипто чипы все равно вынудят придерживаться практики обращения к авторизированным центрам. Более того они требуют собственной аутентификации со стороны микроконтроллера. Я видел как аутентификацию крипточипов легко обходят дампя первые мегабайты обмена. А более сложно разработчики софта в микроконтроллерах поленились сделать.
С другой стороны вы начали с эфемерности сертификатов третьих сторон. А сейчас предлагаете ATECC608 у которого:
The device comes pre-provisioned secure element with a generic static certificate to reduce third party certificate authority costs.
Вот, кстати, да, на мой взгляд иногда проще подделать внешнее поведение дивайса, если оно заключается в дрыгании одними пинами по функции от состояния других пинов.
Но вот насчет того самого кейса взлома, то рекомендую внимательнее изучить их документ и доклад (есть на ютубе), где они по шагам показывают процесс.
Насчет авторизированных центров не совсем понял.
Мы вроде говорили о своей иерархии CA, которую можно украсть только если украсть ключ корневого CA. Но и для такого риска у ИБ все продумано давно )). Просто делают изолированный корневой CA и промежуточный, который уже пилит серты для брокеров и для клиентов. При этом, компрометация любого из нижестоящих уровней не ведет к компрометации соседей и верхнего уровня. Ну эти вопросы и риски с точки зрения профессионалов ИБ - просто уровень песочницы.
Взять, к примеру, Windows Server. Так там давно есть готовое решение AD CS (Active Directory Certificate Services), которое позволяет мышкой за час накликать целую готовую иерархическую и правильную во всех отношениях инфраструктуру PKI сразу в промышленном виде. И сразу из коробки с веб-сервисом (вместо голого openssl), удобно помогающим выдавать клиентские сертификаты по запросу.
Далее, вышеупомянутый чип ATECC608 поставляется не только в варианте с предустановленным сертификатом, но и в варианте Custom без сертификата.
Предустановка сертификатов - это не более чем аутсорсинг процесса их серийного выпуска и заливки в чип, что действительно может снизить стоимость производства при тех же результатах.
Значит я неправильно понимал термин CA. Думал что речь идёт просто о корневом сертификате, а не об отдельном сервере. Тогда да, всё становится на свои места.
Словом ваш метод аутентификации в брокере MQTT интересен.
Решил тоже его включить в конфиге TLS стека на Azure RTOS.
Все правильно вы понимали, скорее всего с точки зрения опыта использования. Ведь в кейсе, например, натягивания https сервера на железку там тоже есть CA, но он вырожден в одном артефакте - самоподписанном сертификате (этот тот вариант, когда один и тот же серт имеет смысл хардкодить на всех железках) - я это называю перевернутая вверх дном PKI. И это, конечно, совсем другое, нежели более полное понятие CA.
Например, википедия дает нам какое-то свое частное понимание этого термина.
https://ru.wikipedia.org/wiki/Центр_сертификации
И еще, по поводу брутфорсинга дампов трафика.
Приведу цитату из статьи с хабра, показывающую цену желания "провернуть фарш назад":Представим, что нам волшебным образом удалось перенаправить вычислительную мощь всей сети майнинга Bitcoin на взлом одного 2048-битного ключа RSA. Для этого нам нужно будет соотнести то, чем сейчас занимается сеть, с алгоритмом NFS. Я буду сравнивать сопоставимое соотношение, разработанное в RFC376612). Оно основывается на ситуации, актуальной на 2004 год, но лучшего нам, похоже, не найти.
Выполняемые сетью Bitcoin операции требуют приблизительно того же количества вычислений, что и используемые в качестве справочных в RFC376613). По RFC3766 для взлома 2048-битного RSA потребовалось бы 9,01×1030 криптографических операций. Сеть майнинга Bitcoin недавно достигла частоты 1,24×1028 операций/год14).
То есть воспользовавшись мощью самой большой сети, занимающейся взломом криптографических операций, нам бы понадобилось 9,01×1030/1,24×1028 лет для взлома одного ключа RSA. Это даёт 727 лет. Если бы волшебным образом смогли создать достаточно оборудования для взлома ключа RSA за год, то нам бы понадобилось 727/200, или в 3,6 раз больше электричества, чем генерируется на планете.
Оригинал здесь: https://habr.com/ru/companies/mvideo/articles/751506/
Я имел виду не расшифровку трафика, а по виду и адресам пакетов определить обращается или нет дивайс к центру авторизации. Если не обращается, значит система замкнута только на один сервер и её легче взломать через этот единственный сервер.
Что проверяется в сертификатах, а что нет в библиотеках ESP32 вопрос открытый. Бывает что TLS в микроконтроллере есть, но только доля того чтобы подключиться. Настоящая жёсткая аутентификация по всем полям сертификата не производится. Открыты ли все исходники TLS у ESP32 я не знаю. Может подскажете? С ESP32 не работаю.
Далее, поскольку у ESP32 нет технологии подобной TrustZone в ARM-ах, то на них можно атаковать по способу Interrupt-oriented Bugdoor Programming через сетевое подключение.
Тут немного проще. Если протокол реализован, то значит все работает в соответствии с ним. А сила TLS как раз и состоит в том, что нарушить его в коде нельзя. Думаю, основные риски все же кроются в проблемах утечки ключа, а не в реализациях. И суть не важно, какие там поля в сертификате использованы именно приложением, т.к. реализация протокола просто просто вынуждена следовать ему. Тут или все, или ничего.
А вот насчет мидлварных прокладок и риска утечки ключа, тут вы верно отметили насчет "посмотреть внутрь". К счастью, я еще не достиг такого уровня паранойи, чтобы рыть middleware и реализации MbedTLS и FreeRTOS. В большей степени полагаюсь на сообщество, ведь это популярные и активно используемые сущности.
Ну и если сравнивать АРМ и неАРМ, то вероятно, нужно брать во внимание не саму архитектуру, а конкретного чипмейкера, стремящегося создать решения с повышенной безопасностью.
В тему: Вероятность брутфорса ключа конкретного кошелька (например, Satoshi Nakamoto) примерно 54 миллиарда лет https://habr.com/ru/companies/first/articles/647913/comments/#comment_24014023
А нельзя ли что-нибудь попроще, типа туториала как сделать защищённый сервер на ESP32.
Камрад, уважение! Рад видеть, что ещё кто-то в теме!
P.S. Раскрыл часть моих разработок своей статьёй ;)
PKI для IOT, архитектура защищенной сети ESP32 + Mosquitto SSL и Flash Encryption для хранения сертификатов