Чи можна витягти програми, завантажені на плату NodeMCU?

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

Одним з ключів, який мені потрібно "завантажити" на плату, є рядок підключення пристрою Azure і, звичайно, WiFi SSID та пароль.

Я боюся, що хтось може просто взяти дошку та "завантажити" файли, щоб отримати доступ до облікових даних безпеки.

Чи є мій страх необґрунтованим чи втрата облікових даних є реальною загрозою, яку мені потрібно пом'якшити?

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

Ви натрапили на проблему зберігання облікових даних таким чином, що без догляду процес може отримати доступ до них, але зловмисник не може. Це добре відома і дуже складна для вирішення проблема.

Якщо ваш пристрій IoT має вбудований на материнську плату апаратний сховище ключів, як-от деякі TPM, або еквівалентно Keystore, підтримуваному апаратним забезпеченням Android або Apple Secure Enclave, ви можете використовувати це.

З традиційними серверами ви можете використовувати HSM або Smart Cards, але єдине повне програмне рішення, про яке я знаю, - це отримати ключ AES з якогось "апаратного відбитка пальця", побудованого за допомогою комбінування серійних номерів усіх апаратних пристроїв. Потім використовуйте цей ключ AES для шифрування облікових даних. Процес, що працює на тому ж сервері, може реконструювати ключ AES та розшифрувати облікові дані, але як тільки ви витягнете файл із сервера, він, по суті, не розшифрується.

IoT кидає ключ у це з двох причин:

1. Припущення, що серійні номери обладнання унікальні, ймовірно, не відповідає, і

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

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

Таким чином, стандартний трюк виглядає так, що він тут не працює. Перше питання, яке вам потрібно буде задати собі:

• Яка моя модель загроз / де цей проект сидить на Secure <--> Convenientшкалі?

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

Це складна проблема, що ускладнюється характером пристроїв IoT.

Для повноти, повномасштабним промисловим рішенням цієї проблеми є:

• Надайте кожному пристрою IoT унікальний відкритий ключ RSA під час виготовлення. Запишіть цей відкритий ключ у db проти серійного номера пристрою.
• Зберігайте чутливі облікові дані на належному сервері, назвемо це "шлюзом".
• Коли пристрій IoT аутентифікується на шлюз (використовуючи його ключ RSA), шлюз відкриває для нього сеанс за допомогою збережених облікових даних і передає маркер сеансу назад на пристрій.
• Для кращої безпеки шлюз - це фізичний (або VPN) шлюз, так що весь трафік від пристрою IoT проходить через шлюз, і ви маєте більше контролю над правилами брандмауера та іншим способом - в ідеалі не дозволяйте пристрою мати пряму (тунель без VPN) доступ до Інтернету.

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

Загроза реальна, але, на щастя, ви не перший чи єдиний, хто має подібні проблеми безпеки.

Що вам потрібно - це ESP WiFi Manager - це те, що вам тут потрібно.

З цією бібліотекою ESP, який не має збереженого сеансу, перейде в режим AP і розмістить веб-портал. Якщо ви підключитесь до цієї AP за допомогою ПК або смартфона, тоді ви зможете налаштувати облікові дані Wi-Fi через веб-сторінку.

Вам не доведеться жорстко кодувати критичну інформацію, і ви можете використовувати свій пристрій у будь-якій мережі WiFi, яку ви хочете, не потребуючи переоформлення.

Як це працює

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

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

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

• через Портал захоплених та DNS-сервер ви отримаєте спливаюче вікно типу "Приєднатися до мережі" або отримаєте будь-який домен, до якого ви намагаєтесь отримати доступ, переспрямований на портал налаштування

• виберіть одну зі сканованих точок доступу, введіть пароль та натисніть кнопку «Зберегти»

• ESP спробує підключитися. У разі успіху він відмовляється від керування вашим додатком. Якщо ні, знову підключіться до AP та переконфігуруйте.

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

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

Хорошим моментом є те, що багато інтерфейсів підключення до wifi приймають хешовані паролі. Незважаючи на те, що я використав прийняті хеди md5 і md5 не надто безпечний, це все ще дуже складний виклик для середнього Джо. Залежно від вашого конфігураційного файлу, ви або вказуєте ім'я свого алгоритму хешування, а потім пишете свій пароль або використовуєте типовий інтерфейс, який використовує ваш wifi.

Проста відповідь - ТАК. Це можна зробити. Вам потрібно, принаймні, виконати якусь обтурацію, щоб забезпечити мінімальний захист.