Как защитить связь между приложением и устройством IoT?

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

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

Изменить: Да, в настоящее время мы шифруем связь и используем HTTPS, когда устройство связывается с нашим сервером.

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

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

Кроме того, если вы хотите узнать больше о криптологии и шифровании, которые вы будете использовать для защиты своего устройства, проверьте эту (бесплатную) электронную книгу . Он много говорит о хороших и плохих реализациях алгоритмов шифрования и должен помочь вам в защите вашего продукта. (Примечание 1: пожалуйста, не создавайте свой собственный алгоритм. Примечание 2: я не связан с crypto101 или lvh.)

Если у вас может быть сквозной TCP, то используйте сквозной TLS (например, с HTTPS).

Не изобретайте колесо, особенно когда дело доходит до криптографии - большинство людей ошибаются. Если устройство не слишком ограничено в ресурсах для поддержки TLS, если вы опуститесь до уровня AES, вы делаете это неправильно . Ошибка № 1 заключается в шифровании и забывании аутентификации - если у вас есть зашифрованный канал между вашим сервером и посредником, а не зашифрованный канал между вашим сервером и вашим устройством, то шифрование не принесло никакой пользы , Если вы не можете использовать TLS, убедитесь, что используемый вами протокол аутентифицирует все и шифрует то, что должно быть конфиденциальным.

Чтобы безопасно использовать TLS, подумайте о том, какие гарантии вам нужны, с точки зрения каждого участника. Как правило, устройство должно знать, что оно общается с законным сервером. Это означает, что он должен проверить сертификат сервера. Устройство должно иметь сертификат X.509 центра сертификации, зарегистрированный как доверенный; это требует хранилища, которое не может быть изменено злоумышленником, но не требует никакой конфиденциальности хранилища. Обратите внимание, что вам не следует жестко кодировать сертификат сервера напрямую, потому что это не позволит вам легко заменить этот сертификат, если он скомпрометирован. Вместо этого устройство хранит ожидаемую идентичность(имя хоста) сервера и сертификат центра сертификации, который гарантирует, что определенный открытый ключ принадлежит ожидаемому имени хоста. Еще раз, не изобретайте колесо, положитесь на проверку сертификата, предоставленную вашей библиотекой TLS или приложением.

Если сервер должен знать, что он общается с законным клиентом, то у каждого клиента должен быть свой собственный сертификат клиента. Это требует конфиденциального хранения на клиенте. Передайте сертификат клиента функции открытия сеанса TLS из библиотеки TLS или установите его в конфигурации приложения.

Это обеспечивает безопасность связи между вашим сервером и вашим устройством. Если мобильное приложение может напрямую взаимодействовать с устройством (например, чтобы разрешить отключенную операцию, когда оно находится в локальной сети Wi-Fi), сначала необходимо выполнить сопряжение между интеллектуальным коммутатором и мобильным телефоном. Сопряжение означает обмен ключами, предпочтительно обмен открытыми ключами, если позволяют ресурсы, в противном случае соглашение о секретных ключах. Цель этого соединения - убедиться, что каждое устройство знает, с кем оно разговаривает.

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

Еще одним соображением является обновление прошивки. Это непросто: с одной стороны, абсолютной безопасности не существует, поэтому у вас будут патчи для безопасности, которые нужно применять время от времени. С другой стороны, механизм обновления прошивки является сложной вещью и может сам по себе иметь ошибки. По крайней мере, убедитесь, что ваши обновления прошивки подписаны. Полагаться только на безопасность канала связи для обновлений сложно, потому что основанное на надежном канале для безопасного канала больше, чем для статической проверки безопасности, и иногда вам может потребоваться применить обновления встроенного ПО без сетевого подключения. В дополнение к проверке подписи, в идеале вы должны иметь некоторую защиту от отката, чтобы противник мог