Можно ли извлекать программы, загруженные на плату NodeMCU?

13

Я использую плату NodeMCU с возможностями WiFi для создания простого трекера активов. Мне удалось найти несколько набросков Arduino, которые обеспечивают подключение к концентратору IoT Azure и публиковать сообщения.

Одним из ключей, которые мне нужно «загрузить» на плату, является строка подключения устройства Azure и, конечно, идентификатор SSID WiFi и пароль.

Я боюсь, что кто-то может просто взять доску и «скачать» файлы, чтобы получить доступ к учетным данным безопасности.

Является ли мой страх необоснованным, или потеря полномочий является реальной угрозой, которую мне нужно смягчить?

бараны
источник
3
Я думаю, что ответы @Mike Ounsworth и Bence Kaulics, взятые вместе, дают мне достойный выбор. К сожалению, я не могу отметить оба как принятые ответы.
баран

Ответы:

12

[Отказ от ответственности: я профессионал в области безопасности / криптозащиты и каждый день занимаюсь вопросами архитектуры безопасности.]

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

Если ваше устройство IoT имеет встроенное в материнскую плату аппаратное хранилище ключей, такое как некоторые TPM, или эквивалент аппаратного хранилища ключей Android или Apple Secure Enclave, то вы можете использовать его.

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

IoT вбивает в это ключ по двум причинам:

  1. Предположение, что аппаратные серийные номера являются уникальными, вероятно, не имеет места, и

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

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


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

  • Какова моя модель угроз / где находится этот проект в Secure <--> Convenientмасштабе?

В конечном счете, я думаю, что вам нужно либо решить это, security > convenienceи заставить человека вводить учетные данные после каждой загрузки (используя что-то вроде ответа @ BenceKaulics ), либо вы решаете это security < convenienceи просто помещаете учетные данные на устройство, возможно, используя некоторое запутывание, если вы чувствую, что имеет значение.


Это сложная проблема, которая усугубляется природой устройств IoT.

Для полноты полного промышленного решения этой проблемы:

  • Предоставьте каждому устройству IoT уникальный открытый ключ RSA во время изготовления. Запишите этот открытый ключ в БД относительно серийного номера устройства.
  • Храните конфиденциальные учетные данные на соответствующем сервере, назовем его «шлюзом».
  • Когда устройство IoT аутентифицируется на шлюзе (используя свой ключ RSA), шлюз открывает для него сеанс с использованием сохраненных учетных данных и передает маркер сеанса обратно на устройство.
  • Для обеспечения максимальной безопасности, шлюз является физическим (или VPN) шлюзом, так что весь трафик с устройства IoT проходит через шлюз, и вы имеете больший контроль над правилами межсетевого экрана и другими вещами - в идеале, предотвращая прямое подключение устройства (без VPN-туннелирования) Доступ к сети Интернет.

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

Майк Оунсворт
источник
2
Да. Большая часть проблемы заключается в том, что здесь пытаются защитить общий секретный пароль, который представляет собой пароль Wi-Fi. Общие секреты - плохая идея, когда устройство может быть физически вскрыто. Более совершенный дизайн будет разделять каждый экземпляр устройства (или другого компьютера) в его собственную среду безопасности с уникально защищенным каналом между каждым отдельным гаджетом и системами, с которыми они должны взаимодействовать. В любом случае, Wi-Fi может не очень хорошо подходить для приложения в любом случае по сравнению с какой-то двухточечной схемой 2,4 ГГц или даже с протоколом «Esp Now».
Крис Страттон
1
Хорошая точка зрения. Вы можете исправить проблему общего секрета , используя корпоративные клиентские сертификаты WPA2, а не пароль SSID (если устройство IoT достаточно велико, чтобы иметь стек TLS, многие этого не делают). Я ничего не знаю о Azure IoT Hub, но я предполагаю, что строки подключения устройств Azure уже уникальны для каждого устройства. К сожалению, это кажется довольно чистым черно-белым между «сделай сам без безопасности» и «промышленная безопасность» с небольшим перерывом между ними.
Майк Оунсворт
2
Мне интересно, если я могу открыть сеанс по желанию, зачем мне нужны учетные данные?
Андрей Савиных
1
@AndrewSavinykh Зависит от того, каковы полномочия. Может быть, все, что они делают, это открывают сессию, в этом случае да, не так много причин. Но, возможно, они являются учетными данными AD домена Windows или предоставляют доступ к дополнительным API, которые обычно не используются / недоступны с устройства IoT. Может быть, вы в порядке с сеансами, поступающими с скомпрометированных устройств, но не в порядке с сеансами, поступающими с ноутбуков атакующих. Да, это довольно быстро зависит от конкретного случая использования.
Майк Оунсворт
3
Серийные номера??? Поиск уникального серийного номера не должно быть проблемой, но серийные номера не являются секретными. Они бесполезны, чтобы сформировать ключ. Где на самом деле использование серийных номеров, чтобы сформировать ключ «стандартный трюк»?
Жиль "ТАК - перестань быть злым"
6

Угроза реальна, но, к счастью, вы не первый или единственный, кто сталкивается с подобными проблемами безопасности.

То, что вам нужно, это ESP WiFi Manager , то, что вам нужно здесь.

С этой библиотекой ESP, у которого нет сохраненного сеанса, переключится в режим AP и будет размещать веб-портал. Если вы подключитесь к этой точке доступа с помощью ПК или смартфона, вы сможете настроить учетные данные WiFi через веб-страницу.

Вам не нужно жестко кодировать важную информацию, и вы можете использовать свое устройство в любой сети Wi-Fi, которую вы хотите, без необходимости ее перепрошивки.

Как это устроено

  • когда ваш ESP запускается, он устанавливает его в режиме станции и пытается подключиться к ранее сохраненной точке доступа

  • если это не удается (или предыдущая сеть не сохранена), он переводит ESP в режим точки доступа и запускает DNS и WebServer (ip по умолчанию 192.168.4.1)

  • с помощью любого устройства с поддержкой Wi-Fi с подключением браузера (компьютера, телефона, планшета) к вновь созданной точке доступа

  • из-за Captive Portal и DNS-сервера вы либо получите всплывающее окно типа «Присоединиться к сети», либо любой домен, к которому вы пытаетесь получить доступ, перенаправленный на портал конфигурации

  • выберите одну из проверенных точек доступа, введите пароль, нажмите Сохранить

  • ESP попытается подключиться. В случае успеха, он возвращает управление вашему приложению. Если нет, переподключитесь к AP и перенастройте.

(Документация ESP WiFi Manager)

Бенс Кауликс
источник
1
Или просто загрузите записи или что-то еще, пока он находится в режиме AP. Надеюсь, что автор не пытается использовать Wi-Fi сам для отслеживания активов.
Крис Страттон,
1
@ChrisStratton :-) на самом деле, я пытаюсь использовать WiFi для отслеживания активов. К счастью, сеть WiFI, которую я использую, является общедоступной и открытой, но я беспокоюсь о последствиях, когда мне нужно использовать другую, для которой нужен пароль. Также тот факт, что на устройстве есть строка подключения AzureIoT Hub.
баран
2
@rams Конечно, чтение EEPROM устройства не будет большой задачей.
Бенс Кауликс
3
@rams На вашем оборудовании, да, EPROM можно прочитать. Более новые устройства могут иметь некоторые защищенные области флэш-памяти, которые лучше защищены. Конечно, это известная проблема, которая нуждается в поддержке на кристалле, чтобы попытаться сделать это правильно.
Шон
2
@SeanHoulihane - ESP8266 не имеет EEPROM. Вспышка SPI, которую она использует для всего (включая эмуляцию функциональности Arduino), является внешней по отношению к ESP8266. Даже в многочиповом модуле это отличная матрица, которую можно исследовать в приличной лаборатории.
Крис Страттон
3

Да, они могут получить доступ к вашему паролю, если вы оставите его в виде обычного текста.

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

atakanyenel
источник
3
Если они могут извлечь хешированный пароль, который работает во время хэширования, что может помешать им использовать его, не обращаясь к нему?
Крис Страттон
1
@ ChrisStratton вы правы. Способы, как это предотвратить для информационной безопасности SE, этот вопрос задает для предотвращения потери учетных данных. Тем не менее, хэшированные пароли по-прежнему не могут использоваться мобильными телефонами для подключения к сети без дополнительного программного обеспечения.
Атаканьенел
1
Да, в действительности это обеспечит некоторую защиту в случае повторного использования пароля Wi-Fi в какой-либо другой системе, но не слишком сильно от несанкционированного подключения к этой точке доступа Wi-Fi.
Крис Страттон,
1
@ChrisStratton да, например, белый список MAC-адресов гораздо более безопасен, чем просто иметь пароль и хэшировать его, но эти шаги в целом предназначены для безопасности Wi-Fi, а не для конфиденциальности учетных данных на общедоступных устройствах.
Атаканьенел
2
Нет, белый список MAC-адресов - это шутка, там нет никакого секрета . И, конечно, MAC легко извлекается из украденного ESP8266 или его флэш-памяти SPI. Единственное место, которое может помочь белый список MAC-адресов, - это против людей, которые используют графический интерфейс для подключения к сетям Wi-Fi, или если бы точка доступа находилась там, ожидая соединения от клиента, который может появиться когда-нибудь, но никогда не подключался к нему - т.е. Меч в камне типа хлам.
Крис Страттон,
1

Простой ответ - ДА. Это может быть сделано. Вы должны, по крайней мере, выполнить какое-то запутывание, чтобы обеспечить минимальную защиту.

Амит Вуйич
источник
1
Запутывание затрудняет выяснение того , как работает устройство, но бесполезно защищать устройство от клонирования . Бесполезно защищать от извлечения учетных данных: все, что вам нужно сделать, это запустить прошивку в эмуляторе.
Жиль "ТАК - перестань быть злым"
Полностью согласен. Моя мотивация дать такой ответ состояла в том, чтобы отметить, что <необходимо учитывать безопасность сети IoT>. @Mike Ounsworth дал подробный ответ, предлагая решения с использованием инфраструктуры AES и / или RSA. Я подумываю дать еще один ответ, но я не уверен, каким образом окунуться в криптографию (я также много лет занимаюсь платежными и банковскими решениями). Я думаю, что мы должны предоставлять практические / сбалансированные советы, потому что обычно люди избегают углубляться в криптографию для защиты устройств IoT на его заднем дворе.
Амит Вуйич
1
Если люди хотят создавать небезопасные устройства, потому что они не могут понять, как создавать безопасные устройства, я не вижу причин для их включения.
Жиль "ТАК - перестань быть злым"
Мой опыт показывает, что люди хотят учиться, но опять же, должен быть баланс между уровнем безопасности и сложностью. В индустрии платежей существует известная история о SET ( en.wikipedia.org/wiki/Secure_Electronic_Transaction ), которая была / была очень безопасной, но сложной для реализации, и из-за этого на практике не сработала.
Амит Вуйич
2
Запутывание добавляет сложности без улучшения безопасности. Это не баланс.
Жиль "ТАК - перестань быть злым"