Если речь идет о безопасности Интернета вещей (IoT), то следует сразу оговорится о какой стороне безопасности пойдет речь. Дело в том, что не существует системы, которую нельзя взломать или которая является абсолютно надежной. Вопрос только во времени, деньгах или банальной случайности. Казалось бы, оптоволоконные сети связи достаточно надежны в силу их физической природы соединения, но все равно, если нет шифрования данных, к самому потоку информации злоумышленники могут вполне добраться. Что остается говорить о беспроводных сетях и, фактически основе Интернета вещей – технологии Wi-Fi или, более правильно ее называть – IEEE 802.11? При этом не стоит забывать, что любые системы могут ломаться и не выдерживать нагрузок. Роботы, электроника, различные механические устройства с подключением к Интернет, впрочем, как и без подключения, потенциально могут нанести вред. Кстати, сейчас совсем забыли направление, которым занимается мехатроника, которая идеально подходит в ключе описания стека IoT. В общем, безопасность – это многогранное понятие и в данной публикации хотелось бы затронуть только небольшую часть этой проблемы, на примере решения задач шифрования и передачи данных для устройств IoT.
The 10 Most Vulnerable IoT Security Targets – Internet of Things Institute
Безопасность передачи данных в открытом пространстве Интернет-коммуникаций – основная задача, которая должна обязательно учитываться при проектировании и эксплуатации любой технологии, связанной с Интернетом вещей. В отличие от традиционных концепций построения Интернет-коммуникаций, сети IoT в настоящее время переживают только начальную точку развития. В большинстве случаев может показаться что, обеспечив достаточную надежность и масштабирование серверных систем, устройств пользователей и зашифровав данные, можно вполне успешно обеспечить безопасность IoT. Это не совсем так, поскольку, например, можно реализовать систему, где данные из камеры домашнего ассистента будут достаточно хорошо зашифровываться и передаваться на сервер, где их потом распаковывают и архивируют в надежном хранилище и, почему-то, открывают доступ к этому архиву по банальному протоколу FTP. Тут злоумышленнику можно не утруждать себя взломом конечных устройств и серверов, а ограничиться достаточно известным протоколом сетевого доступа к файлам. Таким образом, безопасность – это многогранное понятие, где не стоит забывать даже о мелких нюансах и мелочах. Ведь защита IoT-устройств сводится на нет, если можно взломать операционную систему IoT-шлюза или любой другой точки в IoT-цепочке соединений, где, например, хранятся данные в открытом виде.
Разработчикам таких сложных, распределенных систем, как IoT, обязательно следует предусмотреть надежное решение обеспечения защиты инфраструктуры всей системы, т.е. исключить возможность не только взлома системы путем атаки на устройства, но и защитить персональные данные пользователей или подобные сведения о владельцах конечных устройств IoT и т.п. Поэтому, проектируя систему на основе концепции Интернета вещей, всегда нужно помнить, что есть два равнозначных домена:
— коммуникация устройств IoT;
— обеспечение надежного хранения, обработка и представление данных.
Как не трудно догадаться, используя готовое решение на базе современных средств AWS IoT, можно получить фактически «из коробки» решение проблемы безопасности на уровне взаимодействия устройств. При этом, защиту данных и программных решений вполне можно обеспечить за счет применения дополнительных сервисов, входящих в облако AWS. Но не следует забывать, что для Интернета вещей узким местом все-таки остается пропускная способность коммуникационных каналов. Ведь не везде сейчас есть уверенный доступ к Wi-Fi, 3G или LTE.
В промышленных и домашних сетях вполне можно получить гарантированную скорость доступа, но мобильным устройствам это будет сделать не всегда так просто. Поэтому, шифрование в таких системах может быть и, наоборот, относительно негативным фактором, которое только усложняет конечные устройства и увеличивает размер пакетов данных. Например, можно долго не думать, отвечая на вопрос, насколько могут быть сложными алгоритмы шифрования для реализации на 8-ми битном микроконтроллере Arduino Uno. Однако, не следует забывать о законе Мура и стремительном развитии электроники.
Advances in Semi Manufacturing Continue to Make Products Better and More Affordable – Intel Newsroom
Если нужно шифровать данные, то сейчас вполне можно найти подходящее по стоимости решение, способное реализовать необходимые алгоритмы на базе микроконтроллера или микропроцессора. Также защита данных может быть предусмотрена на аппаратном уровне в микросхемах интерфейса Ethernet, модулях Wi-Fi или 3G. При этом нужно понимать, что совсем не стоит заботиться о шифровании данных, которые и так будут доступны в открытом виде, например, для открытых систем мониторинга температуры и т.п. Но тут может проявить себя совсем другой вопрос безопасности – компрометация данных. Например, не заботясь об авторизации и аутентификации «своих» устройств IoT, можно пропустить момент, когда под такое устройство «замаскируется» оборудование злоумышленника, давая заведомо ложные данные в систему.
Очевидно, как было отмечено ранее, комплексный подход к решению проблемы безопасности уже сейчас можно увидеть на примере современных облачных вычислений. Давайте более детально рассмотрим в этом плане технологии Amazon IoT. Облако Amazon Web Services (AWS) доступно для тестирования в рамках «уровня бесплатного пользования». Например, для AWS IoT, в течении первого года после регистрации, будет доступно 250 000 сообщений (опубликованных или доставленных) в месяц. Для множества других сервисов доступна линейка подобных лимитов. К сожалению, Amazon не дает возможности «бездумно» экспериментировать в течение пробного использования. Пользователь этого облака всегда должен давать себе отчет, что запускает или как генерирует определенные действия. Все, что будет превышать порог бесплатного использования придется оплатить согласно действующим тарифам.
Регистрация в облаке AWS достаточно простая. Однако, сразу сервис запросит $1 USD с карточки клиента для подтверждения возможности оплаты счетов этой картой. Также для нового пользователя сервис проверит существование реального телефона, и тут его может ожидать небольшой сюрприз. Подтвердить телефон можно автоматически после звонка сервиса. Но для обладателей смартфонов, звонок может раздаться не в приложении телефона, а в Viber. Количество ввода кода подтверждения ограничено, если не догадаться где в Viber нужно ввести заветные цифры, можно просто исчерпать лимит и ожидать порядка суток до новой попытки. Вот, почему-то так и случилось. В любом случае, техподдержка Amazon всегда поможет, даже на бесплатном тарифе. Описав проблему в чате, буквально за считанные минуты, вполне можно решить подобный вопрос после живого звонка оператора. Можно предположить, что и все другие вопросы по работе с сервисом можно очень оперативно решать с техподдержкой. А в масштабах использования ресурсов облака, когда потребуется беспрецедентное качество, сервис предоставляет платные тарифы технической поддержки.
Итак, начиная работать с облаком, многие сразу приступают к экспериментам с виртуальными машинами, файловыми хранилищами и т.п. Но у нас задача рассмотреть сервис AWS IoT и понять насколько такое решение является защищенным. Поскольку AWS IoT – это лишь часть сервисов облака Amazon, то так или иначе этот сервис интегрируется со многими другими решениями облака (AWS Services). Для этого существует механизм Rules Engine, который позволяет построить набор правил взаимодействия подключенных устройств и других ресурсов облачных вычислений. Например, можно реализовать взаимодействие AWS IoT и сервиса запуска программного кода AWS Lambda, нереляционной базой данных Amazon DynamoDB или сервисом обработки и анализа потоковых данных Amazon Kinesis Streams.
AWS IoT – Amazon Web Services
Центральное место AWS IoT – это шлюз Device Gateway, который обеспечивает взаимодействие устройств с платформой облака. Фактически – это брокер MQTT, который, с одной стороны, обеспечивает безопасное подключение устройств с использованием механизма аутентификации и авторизации, а с другой – позволяет использовать весь потенциал AWS-решений и сервисов. Шлюз также поддерживает протоколы WebSockets, HTTP 1.1. AWS IoT автоматически масштабируется и может поддерживать более миллиарда устройств. Интересно, что в случае потери соединения с удаленным устройством от Amazon есть интересное решение – это «тени» устройств (Device Shadows). «Тени» представляют из себя некоторую абстракцию или виртуальное представление последнего состояния устройства, которое стало недоступным. Также для «тени» можно задать желаемое будущее состояние. Благодаря такому подходу можно гибко проектировать свои приложения для работы с удаленными устройствами в условиях неустойчивой связи.
И главное для тех, кто до сих пор думает, что облако и безопасность Интернета вещей – это миф, выдержка из документации AWS IoT: «Каждое подключенное устройство должно иметь учетные данные для доступа к брокеру сообщений или службе «теневых» устройств. Весь трафик на и из AWS IoT должен быть зашифрован через Transport Layer Security (TLS). Учетные данные устройства должны храниться в безопасности, чтобы безопасно отправлять данные брокеру сообщений. Механизмы безопасности облаков AWS защищают данные при перемещении между AWS IoT и другими устройствами или службами AWS».
Security and Identity for AWS IoT – AWS Documentation
Проблема только в одном – Интернет вещей предполагает наличие огромного количества подключенных устройств, впрочем, как и множества пользователей, которые могут и хотят взаимодействовать со своими гаджетами и более серьезными системами. Если облако решает проблемы масштабирования и организации базовой защиты элементов системы, то как говорилось ранее, не надо забывать, что безопасность – это комплексное понятие, где в большинстве случаев, основным звеном в цепочке мер защиты Интернета вещей являются организационные меры, банальное внимание и следование элементарным принципам организации защиты веб-ресурсов. Ведь основное – это не доверять данным пользователя, выполнять валидацию и верификацию информации, шифровать трафик, надежно хранить ключи шифрования и многое другое. Заметим, что особенно на этапе проектирования системы, следует уделить особое внимание обеспечению комплексной безопасности предстоящего решения.
Для разработки аппаратных устройств Интернета вещей Amazon предоставляет SDK AWS IoT. Поддерживаются языки и платформы: Embedded (встраиваемый) C, JavaScript, плата Arduino Yun, Java, Python, iOS и Android. Также Amazon поддерживает ряд устройств и плат прототипирования, среди которых хотелось бы выделить решение Mongoose OS ESP32-DevKitC. Это плата на основе бюджетного модуля ESP32 компании Espressif Systems. Недорогие модули компании Espressif уже давно стали синонимом любительского Интернета вещей. Интересна и сама прошивка Mongoose OS компании Cesanta. Эта прошивка поддерживают и более старые модули Espressif ESP8266, плюс устройства на базе микроконтроллеров CC3220, CC3200 и STM32F4. В отличие от традиционного решения на базе IDE Arduino, Lua или MicroPython для ESP8266, прошивка Mongoose OS имеет два типа лицензирования: свободная GPLv2 и коммерческая лицензия. Выбор лицензии зависит от требуемого поддерживаемого функционала системы и типов проектов, которые используют выбранную прошивку.
В качестве основы для прототипа устройства IoT выберем модуль Development Kit NodeMCU на базе ESP8266, как одно из наиболее популярных решений, впрочем, из самых недорогих плат. Средняя цена за модуль порядка $3 USD. Существует несколько вариантов и версий плат NodeMCU, главное – это чип ESP8266 и дополнительно 32Mbits(4MBytes) флэш памяти, а остальное – это небольшие различия в компоновке платы, например, использование USB-UART моста CH34x или CP210x и т.п.
Работать с выбранной прошивкой – Mongoose OS, очень удобно. Подключаем к USB-порту компьютера модуль NodeMCU. Если требуется драйвер USB-UART моста, который после установки на компьютер создаст виртуальный COM-порт, то на сайте Mongoose OS, в разделе Downloads, можно найти ссылку на скачивание необходимого программного обеспечения. Затем, с этого же сайта разработчиков Mongoose OS, следует скачать утилиту mos для поддерживаемых операционных систем: Windows, MacOS или Linux. Затем, после запуска mos, все действия по разработке выполняются в графической оболочке внутри браузера. Для разработки можно выбрать два языка: C/C++ или JavaScript. Первый – позиционируется для промышленных решений, а JavaScript – для целей прототипирования и отладки.
Разработка в среде mos на JavaScript для прошивки Mongoose OS.
Настройка подключения к маршрутизатору Wi-Fi и облаку AWS IoT выполняется внутри графической оболочки. Но уж раз мы перешли к облачным системам, то перед настройками нашей платы для работы с AWS IoT сначала нужно вспомнить о сервисе AWS Identity and Access Management (IAM). Этот сервис предназначен для управления доступом пользователей к сервисам и ресурсам облака. В панели управления AWS выбираем сервис IAM и создаем пользователя, группу и назначаем пользователю права доступа к сервису AWS IoT (Policy name), например, для тестового подключения дадим полный доступ «AWSIoTFullAccess», что, конечно, не лучшее решение для реальных задач.
После этого, в панели mos прописываем соответствующие секретные ключи авторизации для созданного пользователя AWS: «Access Key ID» и соответствующий ему «Secret Access Key». Далее разрабатываем приложение для устройства, например, на JavaScript или, просто, используем демонстрационный пример работы с брокером MQTT. Затем, выполнив локальную отладку приложения, сгенерируем на устройстве сертификаты подключения к облаку:
где REGION – выбираемый пользователем регион, в котором будут использованы ресурсы AWS IoT. Команду «mos aws-iot-setup» можно не запускать, а выполнить все действия подключения к облаку в среде утилиты mos. После этого можно проверить работу системы запустив в AWS IoT клиент MQTT.
Тестирование получения данных от подключенных устройств в среде AWS IoT.
В тестовом приложении Mongoose OS для модуля NodeMCU на базе ESP8266, по нажатию кнопки «Flash» – выполняется публикация сообщения, в котором содержится отчет о занятой памяти и времени непрерывной работы. Необходимо отметить, что в облачном сервисе AWS IoT, можно эффективно использовать панель мониторинга, с помощью которой представляются сводные статистические данные о работе подключенных устройств.
Мониторинг состояния устройств и анализ статистики сообщений в среде AWS IoT.
Таким образом, используя AWS IoT и Mongoose OS можно получить защищенное соединение для Интернета вещей. Однако, если базовой защиты будет недостаточно, есть еще одна интересная возможность. Mongoose OS поддерживает работу с криптографической микросхемой ATECC508A. Это фактически со-процессор, который позволяет генерировать стойкие ключи шифрования используя криптографические алгоритмы на эллиптических кривых. Длина ключа 256-bit, микросхема гарантирует уникальный 72-bit серийный номер, а для хранения ключей, сертификатов и данных – доступна встроенная память 10Kb EEPROM (во встроенной памяти можно хранить до 16-ти ключей). Микросхема работает в диапазоне напряжений 2.0В – 5.5В при температурном режиме от -40 до +85 0С и поддерживает коммуникацию по шине I2C или, в зависимости от подтипа выбранной микросхемы, использует высокоскоростной последовательный однопроводный интерфейс для связи с основным процессором. Цена устройства, порядка $0.8 USD. Позиционируется микросхема ATECC508A как система обеспечения безопасности IoT-узла и идентификатор (ID). О крипточипе можно написать отдельную статью, но все-равно лучше обратиться к первоисточнику – официальной документации на сайте производителя. Также компания Microchip Technology для поддержки своих крипточипов, включая ATECC508A, выпускает платы для ознакомления. Например, достаточно простую CryptoAuthentication Xplained Pro Extension Board (ATCRYPTOAUTH-XPRO).
В случае использования такого крипточипа, команда mos aws-iot-setup уже будет использовать аппаратные ресурсы микросхемы и сконфигурирует обмен данными устройства и облака по защищенному протоколу TLS. Собрать на беспаячной макетнице прототип системы на базе ATECC508A-SSHDA-B – вполне не трудная задача. Единственное, по аналогии с платой ATCRYPTOAUTH-XPRO на макетницу можно добавить подтягивающие резисторы 3.9 кОм по информационным цепям SDA, SCL и, конечно, блокировочный конденсатор 0.1 мкФ. Как всегда, чтобы не повторятся в конце публикации размещены ссылки на подробные публикации по подключению крипточипа к ESP8266. Единственное, это надо быть внимательными с программной частью, так как после генерации ключей микросхему ATECC508A можно заблокировать, в результате чего она перейдет в режим обеспечения секретности, противодействуя аппаратному взлому.
Интересно, а у читателей нашего блога есть положительный или отрицательный опыт применения ATECC508A?
Еще раз хочется отметить, что все действия с Mongoose OS можно выполнять прямо в окне утилиты mos интерфейса браузера. Например, перейдя во вкладку RPC Browser, можно проверить подключение по шине I2C, выполнив команду: I2C.Scan, которая, например, для ATECC508A должна вернуть код [96]. Хочется особенно отметить, что у проекта Mongoose OS отличная поддержка, и сама инфраструктура открытого проекта. Например, прямо в оболочку mos интегрирован чат на базе сервиса Gitter, где можно задать вопросы разработчикам и энтузиастам мира Интернета вещей.
В завершении можно сказать, что поскольку наше устройство уже подключено к облаку AWS IoT, то можно смело отключить разъем USB с ESP8266 и подключиться утилитой mos к устройству через сервис облака AWS. Для этого запустим команду:
Таким образом, рассмотрены потенциальные возможности работы с облаком и разработки устройств Интернета вещей с примерами современных методов защиты IoT. Бесспорно, многим покажется, что это слишком длинная статья или, что все это «вода» и т.д. В свою очередь, хочется отметить, что это только введение в проблему и обязательно в нашем блоге появится более детальная проработка концепций безопасности веб-технологий, включая решения для IoT и социальной составляющей мира Интернета вещей.
Мир меняется и меняется он вместе с нами. Если еще недавно многие разработчики могли лишь мечтать о платформах высокопроизводительных вычислений, о построении распределенных высоконагруженных систем, то сейчас – это уже реальность, которая доступна в качестве облачного сервиса. Если когда-то в прошлом нужно было использовать специальные математические библиотеки для расчетов на базе 8-ми битных микроконтроллеров, понятно, если этого требовала задача, то сейчас проще использовать в проекте соизмеримый по цене 32-х битный вычислитель. Наш мир стремительно поменялся, сейчас мы можем реализовывать свои идеи на значительно более высоком уровне. И тут, как нельзя кстати, немного вдохновляющей рекламы IoT от Amazon Web Services. Осталось пожелать читателям создавать инновации, которые будут помогать делать наш мир безопаснее, удобней и рациональней.
IoT – Day One – Amazon Web Services
Скрытное подсоединие к оптоволокну: методы и предосторожности — Хабрахабр
Немного о «законе Мура» — Хабрахабр
Beecham Research reveals extent of security challenges facing the Internet of Things — Comms Business
Уровень бесплатного пользования AWS — Amazon Web Services
Начало работы с AWS IoT — Amazon Web Services
AWS Identity and Access Management (IAM) — Amazon Web Services
Comparison of ESP8266 NodeMCU development boards — my2cents
Starting with JavaScript – Cesanta
AWS IoT on Mongoose OS, Part 1 — AWS Partner Network (APN) Blog
AWS IoT on Mongoose OS, Part 2 — AWS Partner Network (APN) Blog
ATECC508A — Microchip Technology
The two-dollar secure IoT solution: Mongoose OS + ESP8266 + ATECC508 + AWS IoT
Security — Mongoose OS Documentation
AWS IoT support for Mongoose OS — Cesanta
Secure remote device management with Mongoose OS and AWS IoT for ESP32, ESP8266, TI CC3200, STM32 — Cesanta
Understanding the AWS IoT Security Model — The Internet of Things on AWS
The 10 Most Vulnerable IoT Security Targets – Internet of Things Institute
Безопасность передачи данных в открытом пространстве Интернет-коммуникаций – основная задача, которая должна обязательно учитываться при проектировании и эксплуатации любой технологии, связанной с Интернетом вещей. В отличие от традиционных концепций построения Интернет-коммуникаций, сети IoT в настоящее время переживают только начальную точку развития. В большинстве случаев может показаться что, обеспечив достаточную надежность и масштабирование серверных систем, устройств пользователей и зашифровав данные, можно вполне успешно обеспечить безопасность IoT. Это не совсем так, поскольку, например, можно реализовать систему, где данные из камеры домашнего ассистента будут достаточно хорошо зашифровываться и передаваться на сервер, где их потом распаковывают и архивируют в надежном хранилище и, почему-то, открывают доступ к этому архиву по банальному протоколу FTP. Тут злоумышленнику можно не утруждать себя взломом конечных устройств и серверов, а ограничиться достаточно известным протоколом сетевого доступа к файлам. Таким образом, безопасность – это многогранное понятие, где не стоит забывать даже о мелких нюансах и мелочах. Ведь защита IoT-устройств сводится на нет, если можно взломать операционную систему IoT-шлюза или любой другой точки в IoT-цепочке соединений, где, например, хранятся данные в открытом виде.
Разработчикам таких сложных, распределенных систем, как IoT, обязательно следует предусмотреть надежное решение обеспечения защиты инфраструктуры всей системы, т.е. исключить возможность не только взлома системы путем атаки на устройства, но и защитить персональные данные пользователей или подобные сведения о владельцах конечных устройств IoT и т.п. Поэтому, проектируя систему на основе концепции Интернета вещей, всегда нужно помнить, что есть два равнозначных домена:
— коммуникация устройств IoT;
— обеспечение надежного хранения, обработка и представление данных.
Как не трудно догадаться, используя готовое решение на базе современных средств AWS IoT, можно получить фактически «из коробки» решение проблемы безопасности на уровне взаимодействия устройств. При этом, защиту данных и программных решений вполне можно обеспечить за счет применения дополнительных сервисов, входящих в облако AWS. Но не следует забывать, что для Интернета вещей узким местом все-таки остается пропускная способность коммуникационных каналов. Ведь не везде сейчас есть уверенный доступ к Wi-Fi, 3G или LTE.
В промышленных и домашних сетях вполне можно получить гарантированную скорость доступа, но мобильным устройствам это будет сделать не всегда так просто. Поэтому, шифрование в таких системах может быть и, наоборот, относительно негативным фактором, которое только усложняет конечные устройства и увеличивает размер пакетов данных. Например, можно долго не думать, отвечая на вопрос, насколько могут быть сложными алгоритмы шифрования для реализации на 8-ми битном микроконтроллере Arduino Uno. Однако, не следует забывать о законе Мура и стремительном развитии электроники.
Advances in Semi Manufacturing Continue to Make Products Better and More Affordable – Intel Newsroom
Если нужно шифровать данные, то сейчас вполне можно найти подходящее по стоимости решение, способное реализовать необходимые алгоритмы на базе микроконтроллера или микропроцессора. Также защита данных может быть предусмотрена на аппаратном уровне в микросхемах интерфейса Ethernet, модулях Wi-Fi или 3G. При этом нужно понимать, что совсем не стоит заботиться о шифровании данных, которые и так будут доступны в открытом виде, например, для открытых систем мониторинга температуры и т.п. Но тут может проявить себя совсем другой вопрос безопасности – компрометация данных. Например, не заботясь об авторизации и аутентификации «своих» устройств IoT, можно пропустить момент, когда под такое устройство «замаскируется» оборудование злоумышленника, давая заведомо ложные данные в систему.
Очевидно, как было отмечено ранее, комплексный подход к решению проблемы безопасности уже сейчас можно увидеть на примере современных облачных вычислений. Давайте более детально рассмотрим в этом плане технологии Amazon IoT. Облако Amazon Web Services (AWS) доступно для тестирования в рамках «уровня бесплатного пользования». Например, для AWS IoT, в течении первого года после регистрации, будет доступно 250 000 сообщений (опубликованных или доставленных) в месяц. Для множества других сервисов доступна линейка подобных лимитов. К сожалению, Amazon не дает возможности «бездумно» экспериментировать в течение пробного использования. Пользователь этого облака всегда должен давать себе отчет, что запускает или как генерирует определенные действия. Все, что будет превышать порог бесплатного использования придется оплатить согласно действующим тарифам.
Регистрация в облаке AWS достаточно простая. Однако, сразу сервис запросит $1 USD с карточки клиента для подтверждения возможности оплаты счетов этой картой. Также для нового пользователя сервис проверит существование реального телефона, и тут его может ожидать небольшой сюрприз. Подтвердить телефон можно автоматически после звонка сервиса. Но для обладателей смартфонов, звонок может раздаться не в приложении телефона, а в Viber. Количество ввода кода подтверждения ограничено, если не догадаться где в Viber нужно ввести заветные цифры, можно просто исчерпать лимит и ожидать порядка суток до новой попытки. Вот, почему-то так и случилось. В любом случае, техподдержка Amazon всегда поможет, даже на бесплатном тарифе. Описав проблему в чате, буквально за считанные минуты, вполне можно решить подобный вопрос после живого звонка оператора. Можно предположить, что и все другие вопросы по работе с сервисом можно очень оперативно решать с техподдержкой. А в масштабах использования ресурсов облака, когда потребуется беспрецедентное качество, сервис предоставляет платные тарифы технической поддержки.
Итак, начиная работать с облаком, многие сразу приступают к экспериментам с виртуальными машинами, файловыми хранилищами и т.п. Но у нас задача рассмотреть сервис AWS IoT и понять насколько такое решение является защищенным. Поскольку AWS IoT – это лишь часть сервисов облака Amazon, то так или иначе этот сервис интегрируется со многими другими решениями облака (AWS Services). Для этого существует механизм Rules Engine, который позволяет построить набор правил взаимодействия подключенных устройств и других ресурсов облачных вычислений. Например, можно реализовать взаимодействие AWS IoT и сервиса запуска программного кода AWS Lambda, нереляционной базой данных Amazon DynamoDB или сервисом обработки и анализа потоковых данных Amazon Kinesis Streams.
AWS IoT – Amazon Web Services
Центральное место AWS IoT – это шлюз Device Gateway, который обеспечивает взаимодействие устройств с платформой облака. Фактически – это брокер MQTT, который, с одной стороны, обеспечивает безопасное подключение устройств с использованием механизма аутентификации и авторизации, а с другой – позволяет использовать весь потенциал AWS-решений и сервисов. Шлюз также поддерживает протоколы WebSockets, HTTP 1.1. AWS IoT автоматически масштабируется и может поддерживать более миллиарда устройств. Интересно, что в случае потери соединения с удаленным устройством от Amazon есть интересное решение – это «тени» устройств (Device Shadows). «Тени» представляют из себя некоторую абстракцию или виртуальное представление последнего состояния устройства, которое стало недоступным. Также для «тени» можно задать желаемое будущее состояние. Благодаря такому подходу можно гибко проектировать свои приложения для работы с удаленными устройствами в условиях неустойчивой связи.
И главное для тех, кто до сих пор думает, что облако и безопасность Интернета вещей – это миф, выдержка из документации AWS IoT: «Каждое подключенное устройство должно иметь учетные данные для доступа к брокеру сообщений или службе «теневых» устройств. Весь трафик на и из AWS IoT должен быть зашифрован через Transport Layer Security (TLS). Учетные данные устройства должны храниться в безопасности, чтобы безопасно отправлять данные брокеру сообщений. Механизмы безопасности облаков AWS защищают данные при перемещении между AWS IoT и другими устройствами или службами AWS».
Security and Identity for AWS IoT – AWS Documentation
Проблема только в одном – Интернет вещей предполагает наличие огромного количества подключенных устройств, впрочем, как и множества пользователей, которые могут и хотят взаимодействовать со своими гаджетами и более серьезными системами. Если облако решает проблемы масштабирования и организации базовой защиты элементов системы, то как говорилось ранее, не надо забывать, что безопасность – это комплексное понятие, где в большинстве случаев, основным звеном в цепочке мер защиты Интернета вещей являются организационные меры, банальное внимание и следование элементарным принципам организации защиты веб-ресурсов. Ведь основное – это не доверять данным пользователя, выполнять валидацию и верификацию информации, шифровать трафик, надежно хранить ключи шифрования и многое другое. Заметим, что особенно на этапе проектирования системы, следует уделить особое внимание обеспечению комплексной безопасности предстоящего решения.
Для разработки аппаратных устройств Интернета вещей Amazon предоставляет SDK AWS IoT. Поддерживаются языки и платформы: Embedded (встраиваемый) C, JavaScript, плата Arduino Yun, Java, Python, iOS и Android. Также Amazon поддерживает ряд устройств и плат прототипирования, среди которых хотелось бы выделить решение Mongoose OS ESP32-DevKitC. Это плата на основе бюджетного модуля ESP32 компании Espressif Systems. Недорогие модули компании Espressif уже давно стали синонимом любительского Интернета вещей. Интересна и сама прошивка Mongoose OS компании Cesanta. Эта прошивка поддерживают и более старые модули Espressif ESP8266, плюс устройства на базе микроконтроллеров CC3220, CC3200 и STM32F4. В отличие от традиционного решения на базе IDE Arduino, Lua или MicroPython для ESP8266, прошивка Mongoose OS имеет два типа лицензирования: свободная GPLv2 и коммерческая лицензия. Выбор лицензии зависит от требуемого поддерживаемого функционала системы и типов проектов, которые используют выбранную прошивку.
В качестве основы для прототипа устройства IoT выберем модуль Development Kit NodeMCU на базе ESP8266, как одно из наиболее популярных решений, впрочем, из самых недорогих плат. Средняя цена за модуль порядка $3 USD. Существует несколько вариантов и версий плат NodeMCU, главное – это чип ESP8266 и дополнительно 32Mbits(4MBytes) флэш памяти, а остальное – это небольшие различия в компоновке платы, например, использование USB-UART моста CH34x или CP210x и т.п.
Работать с выбранной прошивкой – Mongoose OS, очень удобно. Подключаем к USB-порту компьютера модуль NodeMCU. Если требуется драйвер USB-UART моста, который после установки на компьютер создаст виртуальный COM-порт, то на сайте Mongoose OS, в разделе Downloads, можно найти ссылку на скачивание необходимого программного обеспечения. Затем, с этого же сайта разработчиков Mongoose OS, следует скачать утилиту mos для поддерживаемых операционных систем: Windows, MacOS или Linux. Затем, после запуска mos, все действия по разработке выполняются в графической оболочке внутри браузера. Для разработки можно выбрать два языка: C/C++ или JavaScript. Первый – позиционируется для промышленных решений, а JavaScript – для целей прототипирования и отладки.
Разработка в среде mos на JavaScript для прошивки Mongoose OS.
Настройка подключения к маршрутизатору Wi-Fi и облаку AWS IoT выполняется внутри графической оболочки. Но уж раз мы перешли к облачным системам, то перед настройками нашей платы для работы с AWS IoT сначала нужно вспомнить о сервисе AWS Identity and Access Management (IAM). Этот сервис предназначен для управления доступом пользователей к сервисам и ресурсам облака. В панели управления AWS выбираем сервис IAM и создаем пользователя, группу и назначаем пользователю права доступа к сервису AWS IoT (Policy name), например, для тестового подключения дадим полный доступ «AWSIoTFullAccess», что, конечно, не лучшее решение для реальных задач.
После этого, в панели mos прописываем соответствующие секретные ключи авторизации для созданного пользователя AWS: «Access Key ID» и соответствующий ему «Secret Access Key». Далее разрабатываем приложение для устройства, например, на JavaScript или, просто, используем демонстрационный пример работы с брокером MQTT. Затем, выполнив локальную отладку приложения, сгенерируем на устройстве сертификаты подключения к облаку:
> mos aws-iot-setup --aws-region REGION --aws-iot-policy mos-defaultгде REGION – выбираемый пользователем регион, в котором будут использованы ресурсы AWS IoT. Команду «mos aws-iot-setup» можно не запускать, а выполнить все действия подключения к облаку в среде утилиты mos. После этого можно проверить работу системы запустив в AWS IoT клиент MQTT.
Тестирование получения данных от подключенных устройств в среде AWS IoT.
В тестовом приложении Mongoose OS для модуля NodeMCU на базе ESP8266, по нажатию кнопки «Flash» – выполняется публикация сообщения, в котором содержится отчет о занятой памяти и времени непрерывной работы. Необходимо отметить, что в облачном сервисе AWS IoT, можно эффективно использовать панель мониторинга, с помощью которой представляются сводные статистические данные о работе подключенных устройств.
Мониторинг состояния устройств и анализ статистики сообщений в среде AWS IoT.
Таким образом, используя AWS IoT и Mongoose OS можно получить защищенное соединение для Интернета вещей. Однако, если базовой защиты будет недостаточно, есть еще одна интересная возможность. Mongoose OS поддерживает работу с криптографической микросхемой ATECC508A. Это фактически со-процессор, который позволяет генерировать стойкие ключи шифрования используя криптографические алгоритмы на эллиптических кривых. Длина ключа 256-bit, микросхема гарантирует уникальный 72-bit серийный номер, а для хранения ключей, сертификатов и данных – доступна встроенная память 10Kb EEPROM (во встроенной памяти можно хранить до 16-ти ключей). Микросхема работает в диапазоне напряжений 2.0В – 5.5В при температурном режиме от -40 до +85 0С и поддерживает коммуникацию по шине I2C или, в зависимости от подтипа выбранной микросхемы, использует высокоскоростной последовательный однопроводный интерфейс для связи с основным процессором. Цена устройства, порядка $0.8 USD. Позиционируется микросхема ATECC508A как система обеспечения безопасности IoT-узла и идентификатор (ID). О крипточипе можно написать отдельную статью, но все-равно лучше обратиться к первоисточнику – официальной документации на сайте производителя. Также компания Microchip Technology для поддержки своих крипточипов, включая ATECC508A, выпускает платы для ознакомления. Например, достаточно простую CryptoAuthentication Xplained Pro Extension Board (ATCRYPTOAUTH-XPRO).
В случае использования такого крипточипа, команда mos aws-iot-setup уже будет использовать аппаратные ресурсы микросхемы и сконфигурирует обмен данными устройства и облака по защищенному протоколу TLS. Собрать на беспаячной макетнице прототип системы на базе ATECC508A-SSHDA-B – вполне не трудная задача. Единственное, по аналогии с платой ATCRYPTOAUTH-XPRO на макетницу можно добавить подтягивающие резисторы 3.9 кОм по информационным цепям SDA, SCL и, конечно, блокировочный конденсатор 0.1 мкФ. Как всегда, чтобы не повторятся в конце публикации размещены ссылки на подробные публикации по подключению крипточипа к ESP8266. Единственное, это надо быть внимательными с программной частью, так как после генерации ключей микросхему ATECC508A можно заблокировать, в результате чего она перейдет в режим обеспечения секретности, противодействуя аппаратному взлому.
Интересно, а у читателей нашего блога есть положительный или отрицательный опыт применения ATECC508A?
Еще раз хочется отметить, что все действия с Mongoose OS можно выполнять прямо в окне утилиты mos интерфейса браузера. Например, перейдя во вкладку RPC Browser, можно проверить подключение по шине I2C, выполнив команду: I2C.Scan, которая, например, для ATECC508A должна вернуть код [96]. Хочется особенно отметить, что у проекта Mongoose OS отличная поддержка, и сама инфраструктура открытого проекта. Например, прямо в оболочку mos интегрирован чат на базе сервиса Gitter, где можно задать вопросы разработчикам и энтузиастам мира Интернета вещей.
В завершении можно сказать, что поскольку наше устройство уже подключено к облаку AWS IoT, то можно смело отключить разъем USB с ESP8266 и подключиться утилитой mos к устройству через сервис облака AWS. Для этого запустим команду:
mos --cert-file $(mos config-get mqtt.ssl_cert) --key-file $(mos config-get mqtt.ssl_key) --port mqtts://$(mos config-get mqtt.server)/$(mos config-get device.id). Теперь можно выполнять отладку без прямого подключения платы устройства к компьютеру. Главное, чтобы модуль ESP8266 мог свободно выходить в Интернет.Таким образом, рассмотрены потенциальные возможности работы с облаком и разработки устройств Интернета вещей с примерами современных методов защиты IoT. Бесспорно, многим покажется, что это слишком длинная статья или, что все это «вода» и т.д. В свою очередь, хочется отметить, что это только введение в проблему и обязательно в нашем блоге появится более детальная проработка концепций безопасности веб-технологий, включая решения для IoT и социальной составляющей мира Интернета вещей.
Мир меняется и меняется он вместе с нами. Если еще недавно многие разработчики могли лишь мечтать о платформах высокопроизводительных вычислений, о построении распределенных высоконагруженных систем, то сейчас – это уже реальность, которая доступна в качестве облачного сервиса. Если когда-то в прошлом нужно было использовать специальные математические библиотеки для расчетов на базе 8-ми битных микроконтроллеров, понятно, если этого требовала задача, то сейчас проще использовать в проекте соизмеримый по цене 32-х битный вычислитель. Наш мир стремительно поменялся, сейчас мы можем реализовывать свои идеи на значительно более высоком уровне. И тут, как нельзя кстати, немного вдохновляющей рекламы IoT от Amazon Web Services. Осталось пожелать читателям создавать инновации, которые будут помогать делать наш мир безопаснее, удобней и рациональней.
IoT – Day One – Amazon Web Services
Интересные ресурсы и ссылки:
Скрытное подсоединие к оптоволокну: методы и предосторожности — Хабрахабр
Немного о «законе Мура» — Хабрахабр
Beecham Research reveals extent of security challenges facing the Internet of Things — Comms Business
Уровень бесплатного пользования AWS — Amazon Web Services
Начало работы с AWS IoT — Amazon Web Services
AWS Identity and Access Management (IAM) — Amazon Web Services
Comparison of ESP8266 NodeMCU development boards — my2cents
Starting with JavaScript – Cesanta
AWS IoT on Mongoose OS, Part 1 — AWS Partner Network (APN) Blog
AWS IoT on Mongoose OS, Part 2 — AWS Partner Network (APN) Blog
ATECC508A — Microchip Technology
The two-dollar secure IoT solution: Mongoose OS + ESP8266 + ATECC508 + AWS IoT
Security — Mongoose OS Documentation
AWS IoT support for Mongoose OS — Cesanta
Secure remote device management with Mongoose OS and AWS IoT for ESP32, ESP8266, TI CC3200, STM32 — Cesanta
Understanding the AWS IoT Security Model — The Internet of Things on AWS
Комментарии (4)
constb
23.11.2017 09:15добавлю ещё что aws iot допускает «нецелевое» использование в веб-разработке. если в веб-приложении нужны пуши, а само приложение написано на лямбдах (или просто нет желания возиться с socket.io или настраивать centrifugo, или просто есть сомнения в части масштабирования) – нужен отдельный облачный websocket-сервер.
aws iot эту задачу решает полностью – вам в идеале понадобится авторизация через cognito, iam-роли для авторизованных и неавторизованных пользователей. для неавторизованных доступ к топикам iot определяется в iam-роли, для авторизованных права доступа должны быть как в iam-роли, так и в iot-политике, которая подключается к cognito identity с помощью iot.attachPrincipalPolicy. есть небольшая проблема в том что для приватных топиков в политике можно использовать идентификатор identity но нет переменной, которая бы содержала идентификатор пользователя из userpool, в то время как в jwt-токене есть только второй.
я выкрутился, добавив лямбду, которую фронтенд дёргает с id-токеном, она хранит в dynamodb мэппинг с userpool id на identity id, и если нужного мэппинга для нового юзера ещё нет, сразу делает и iot.attachPrincipalPolicy. имея такой мэппинг, можно всегда отправить приватный пуш когнито-юзеру с бэкенда по его userpool-идентификатору.
было бы конечно намного проще если бы в userpool был метод получения identity id, или чтобы можно было userpool id использовать как переменную в iam-политике. копаясь на амазоновском форуме я нашёл даже достаточно старые темы от людей, столкнувшихся с теми же трудностями. по видимому архитектура cognito делает решение этой задачи нетривиальным, раз они до сих пор не могут этого сделать…
Sleuthhound
23.11.2017 10:01Все это конечно классно — использование готовых облачных решений, но как мне кажется, ключевой момент в безопасности IoT — это использовать свои сервисы, контроль разработки и управления на предмет утечек секретных ключей от этих сервисов (случайные или преднамеренные), а так же наличие предусмотренной возможности смены всех данных для авторизации IoT устройств в случае компрометации ключей. Недавние раскрытые утечки ключей от AWS крупных клиентов тому доказательства.
Sly_tom_cat
23.11.2017 10:44«Недавние раскрытые утечки ключей от AWS крупных клиентов тому доказательства.»
Важно только уточнить, что утечка ключей была через github репозитории тех самых «крупных клиентов», а не непосредственно из AWS.
И сама эта утечка еще одно напоминание что в сфере обеспечения безопасности нет мелочей и нет людей, связанных с разработкой, которые не должны думать над ней постоянно…
Kot_dnz
Как все же использовать 508, что бы не заблокировать?
Документация расплывчата…