Як забезпечити зв'язок між додатком та пристроєм IoT?

Зараз я працюю над проектом, який включає зв'язок Bluetooth між мобільним додатком (зараз використовується платформа Ionic) та вбудованим пристроєм. Для порівняння, наш продукт схожий на розумний замок .

Безпека викликає надзвичайно важливе значення, і ми розглядаємо шляхи забезпечення того, щоб наше апаратне та програмне забезпечення не було зламано. Які кроки потрібно зробити, щоб забезпечити безпеку нашої системи?

Редагувати: Так, ми зараз шифруємо комунікації та використовуємо HTTPS, коли пристрій спілкується з нашим сервером.

Щоб забезпечити безпеку вашого пристрою, я маю кілька порад:

1. Додайте трохи шифрування до зв'язку Bluetooth. Я рекомендую тримати ключі шифрування в повітрі. Наприклад, ви можете попросити користувача сканувати QR-код, який знаходиться на пристрої, надрукований у вікні і т. Д. При первинному налаштуванні мобільного додатка, можливо, за допомогою клавіші AES? До вас. Це для того, щоб хтось не бачив звичайний текст, який передається в ефірі.
2. Якщо ви можете, тримайтеся подалі від режиму ECB (використовуйте CBC) вибраного алгоритму шифрування, оскільки це може дати деяку інформацію про передані дані. Більше інформації про це можна знайти тут .
3. Під час передачі даних Bluetooth обов’язково введіть унікальний ідентифікатор, щоб повідомлення не було повторене (наприклад, ви можете включити позначку часу). Ви також можете впровадити якусь систему, схожу на TOTP.
4. Покладіть на пристрій порт, який дозволяє легко прошивати, щоб у випадку, якщо ви зрозуміли, що програмне забезпечення має помилку (а чомусь ви не можете оновити його OTA), пристрій не є дорогим паперовим вагою, а лише пристроєм який потрібно підключити до ПК та перенести на нове програмне забезпечення.
5. Додатково. Щоб переконатися, що хтось із шахрайським корінним сертифікатом (можливо, самостійно виданий та встановлений на клієнтському пристрої) не може перехопити зв’язок вашого сервера, перевірте сертифікат HTTPS. Ось такий запит на Android, ви повинні мати можливість знайти подібні ресурси для iOS .

Крім того, якщо ви хочете дізнатися більше про криптологію та шифрування, якими ви користуєтесь для захисту свого пристрою, перевірте цю (безкоштовну) книгу . Це багато говорить про хороші та погані реалізації алгоритмів шифрування та має допомогти вам у забезпеченні продукту. (Примітка 1: Будь ласка, не створюйте власний алгоритм. Примітка 2: Я не пов'язаний з crypto101 або lvh.)

Якщо ви можете мати TCP від ​​кінця до кінця, тоді використовуйте TLS від кінця до кінця (наприклад, з HTTPS).

Не винаходити колесо, особливо якщо мова йде про криптографію - більшість людей помиляються. Якщо пристрій не має надто обмежених ресурсів для підтримки TLS, якщо ви опускаєтесь до рівня AES, ви робите це неправильно . Помилка №1 полягає в шифруванні та забутті автентифікації - якщо у вас зашифрований канал між вашим сервером та людиною посередині, замість зашифрованого каналу між вашим сервером та пристроєм, то шифрування не принесло жодної користі . Якщо ви не можете використовувати TLS, переконайтеся, що незалежно від протоколу, який ви використовуєте, все засвідчується і шифрується те, що має бути конфіденційним.

Щоб безпечно користуватися TLS, подумайте, які гарантії потрібно мати, з точки зору кожного учасника. Як правило, пристрій повинен знати, що він спілкується з законним сервером. Це означає, що він повинен перевірити сертифікат сервера. Пристрій повинен мати сертифікат X.509 органу сертифікації, записаний як довірений; для цього потрібне сховище, яке не може бути змінено зловмисником, але воно не вимагає конфіденційності сховища. Зауважте, що ви не повинні жорстко кодувати сертифікат сервера безпосередньо, оскільки це не дозволить вам легко замінити цей сертифікат, якщо він порушений. Натомість пристрій зберігає очікувану ідентичність(ім'я хоста) сервера та сертифікат органу сертифікації, який гарантує, що певний відкритий ключ належить до очікуваного імені хоста. Знову ж таки, не винаходити колесо, покладайся на перевірку сертифікатів, надану бібліотекою або програмою TLS.

Якщо сервер повинен знати, що він спілкується з законним клієнтом, то для кожного клієнта необхідно мати свій власний сертифікат клієнта. Для цього потрібне конфіденційне зберігання клієнта. Передайте сертифікат клієнта функції відкриття сеансу TLS з вашої бібліотеки TLS або встановіть його в конфігурації програми.

Це забезпечує забезпечення зв'язку між вашим сервером та пристроєм. Якщо мобільний додаток може спілкуватися з пристроєм безпосередньо (наприклад, щоб дозволити відключену роботу під час роботи в локальній мережі Wi-Fi), спочатку потрібно виконати пару між смарт-комутатором та мобільним телефоном. Підключення означає обмін ключами, переважно обмін відкритими ключами, якщо ресурси дозволяють, інакше узгодження секретних ключів. Мета цього пари - забезпечити, щоб кожен пристрій знав, з ким спілкується.

Вам також потрібно захистити канал управління, незалежно від того, переходить він безпосередньо від мобільного пристрою до смарт-комутатора або через сервер. Подумайте про авторизацію: чи існують різні рівні доступу до комутатора, наприклад, рівень управління, який дозволяє робити конфігурацію, і основний канал, який просто дозволяє вмикати / вимикати комутацію? Зазвичай це обробляється на етапі аутентифікації після встановлення захищеного каналу (TLS, якщо можливо).

Інший розгляд - оновлення прошивки. Це складний варіант: з одного боку, немає такої речі, як абсолютна безпека, тому у вас з’являться патчі безпеки, які слід застосовувати час від часу. З іншого боку, механізм оновлення вбудованого програмного забезпечення - це складна річ і сам по собі може мати помилки. Як мінімум, переконайтеся, що оновлення прошивки підписані. Покладатися лише на безпеку каналу зв’язку для оновлення є невиразним, оскільки довірений, що базується на захищеному каналі, більший, ніж для статичної перевірки безпеки, і іноді ви можете застосувати оновлення мікропрограмного забезпечення без підключення до мережі. Крім перевірки підпису, в ідеалі ви повинні мати певний захист від відкоту, щоб супротивник міг "