Упрощение масштабной подготовки IoT

Независимо от того, хотите ли вы спроектировать новое устройство или модернизировать существующее для IoT, вам необходимо подумать о предоставлении IoT, которое позволяет подключать устройства IoT к облачным службам. Дизайн предоставления услуг Интернета вещей требует принятия решений, влияющих на взаимодействие с пользователем и безопасность как для механизмов ввода в эксплуатацию сети, так и для механизмов предоставления учетных данных, которые настраивают цифровые удостоверения, конечные точки облака и сетевые учетные данные, чтобы устройства могли безопасно подключаться к облаку.

Для масштабной подготовки IoT клиенты часто создают и поддерживают настраиваемые инструменты и программные приложения, которые могут передавать необходимые учетные данные по протоколам, поддерживаемым их устройствами, которые охватывают несколько проблемных областей. К доменам подготовки IoT относятся:

• ввод в эксплуатацию сети, который предоставляет клиентам механизмы для определения параметров, зависящих от контекста;
• Предоставление учетных данных, при котором учетные данные и конфигурация назначаются физическим устройствам; и
• Облачная подготовка, которая устанавливает данные конфигурации на стороне облака, которые обеспечивают аутентификацию, авторизацию и управление устройствами.

Все три домена обеспечения должны работать в гармонии для впечатляющего взаимодействия с пользователем.

Например, оператор мобильной связи предоставляет данные конфигурации и параметры политики при первом подключении пользователя мобильного телефона. Это простой и понятный процесс, который не займет много времени у пользователя мобильного устройства, где SIM-карта представляет собой идентификацию устройства. Ситуация становится совершенно иной и сложной для клиентов, особенно производителей оригинального оборудования (OEM), которые пытаются предоставить миллионы устройств IoT.

В этой статье вы сможете узнать, как избежать или снизить риски, связанные с вашим собственным развертыванием IoT, а также на кратких примерах понять, как услуга IoT, предоставляемая через облачные платформы, такие как Amazon Web Services (AWS), помогает вам достичь ваши цели по обеспечению IoT.

Подходы к вводу сети в эксплуатацию при необходимости

В конце концов, ваше IoT-устройство подключается и обменивается данными с центральной службой, которая является центром вашего IoT-решения. Чтобы подключиться к этому концентратору, ваше IoT-устройство должно подключиться к сетевому носителю. Средой может быть жесткий провод, например Ethernet, или радиопередача, например Wi-Fi. В зависимости от среды, вам нужен человек, чтобы сообщить устройству, к какому средству оно должно подключиться, чтобы достичь хаба. Например, при использовании сотовой связи вам не нужно сообщать устройству о присоединении к сети, потому что это было определено SIM-картой. С другой стороны, чтобы присоединиться к сети Wi-Fi, вам необходимо знать имя и пароль точки доступа Wi-Fi и иметь возможность сообщить устройству эти данные. Мы сосредоточимся на устройствах, требующих настройки для подключения к сети.

Есть несколько различных механизмов, которые клиенты использовали для присоединения к сетям IoT. Сегодня смартфон есть практически у всех, и почти каждый смартфон имеет Bluetooth, поэтому конфигурация через Bluetooth стала повсеместной. Однако это не единственный способ наладить общение. Некоторые модули Wi-Fi на устройствах IoT достаточно умны, чтобы сами по себе стать точками доступа, где вы можете разработать простую веб-страницу, которая позволяет пользователям вводить конфигурацию более крупной сети. Для непотребительских устройств все еще распространена настройка через последовательный порт или microSD. Настройка Bluetooth с помощью приложения для смартфона стала нормой. Эти приложения для смартфонов также могут помочь в облачной настройке устройства, о чем вы узнаете позже в этой статье.

Подходы к масштабной синхронизации учетных данных устройства

Процессы предоставления учетных данных для устройств по-прежнему сильно фрагментированы в отрасли, и в ближайшее время не будет видимости для конвергенции. Большинство централизованных систем IoT настоятельно рекомендуют или требуют подключения TLS 1.2 для зашифрованного транспорта, который в последнее время и, возможно, красноречиво известен как шифрование при передаче. Сегодня в большинстве развертываний Интернета вещей используется инфраструктура открытых ключей (PKI), поэтому остальная часть этой статьи предполагает использование PKI. В любом случае обязательно, чтобы каждое устройство имело собственный уникальный идентификационный закрытый ключ и сертификат.

Чтобы создать сеанс с облаком (или конечной точкой службы), TLS 1.2 требует закрытого ключа и сертификата x.509 (или учетных данных). Примечание. Некоторые методы, такие как Java Web Tokens или JWT, имеют аналогичные проблемы, но не будут здесь обсуждаться. Закрытый ключ, который похож на вашу ДНК, должен быть известен только отдельному устройству, а это означает, что он не может быть передан другим устройствам. Сертификат x.509, который похож на водительские права, выдается проверяемым центром сертификации (CA) путем предоставления запроса на подпись сертификата (CSR). Подача CSR не слишком отличается от передачи паспорту организации вашей страны свидетельства о рождении с отпечатком пальца и подтверждением прохождения других тестов в качестве доказательства для получения паспорта. В этой статье мы называем сертификат x.509 учетными данными, предполагая, что устройство имеет уникальный закрытый ключ.

Подробности TLS 1.2 выходят за рамки этой статьи, но мы просто дадим вам достаточно информации, чтобы вы были немного проинформированы, чтобы вы могли понять, почему крайне важно, чтобы устройство защищало закрытый ключ. Во время процесса подключения TLS 1.2 происходит серия обменов, чтобы доказать, что устройство является владельцем закрытого ключа, который является его идентификатором. Ваше устройство должно доказать, что оно является настоящим владельцем сертификата x.509, который оно пытается использовать для аутентификации. Чтобы служба Интернета вещей могла доверять учетным данным устройства при подключении вашего устройства, вам необходимо иметь этот закрытый ключ под рукой. Теперь вы можете понять, что если злоумышленник завладел этим ключом, модель безопасности развалится. Любой ценой защитите ключи от своего замка IoT!

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

• Уникальный неизменяемый закрытый ключ, представляющий устройство. В идеале для защиты от параллельных и других сложных атак закрытый ключ должен быть физически защищен и не загружаться в основную память программы.
• Учетные данные, относящиеся к вашему приложению или службе Интернета вещей.

Логистика зависит от выбора закрытого ключа и предоставления учетных данных, некоторые из которых не связаны с облачной подготовкой, а другие полагаются на облачную подготовку.

• Модули безопасности на интегральных схемах (которые обычно обладают криптографическими возможностями), автономные или участвующие в разработке System-In-Package (SiP), System-On-Module (SoM) или System-On-Chip (SoC), один из следующих вариантов поведения:

• • Модуль безопасности, имеющий вручную подготовленный или самогенерируемый закрытый ключ или корень доверия.
  • В дополнение к предыдущему элементу модуль безопасности предоставляет учетные данные в виде предварительно подготовленных сертификатов x.509.

• Технологии модуля идентификации абонента (SIM), встроенной SIM-карты (eSIM) и интегрированной SIM-карты (iSIM) предоставляют оборудование, которое разработчики используют в качестве идентификатора сотовой связи для связи с сотовыми сетями. Предоставление учетных данных обычно зависит от поставщика оператора мобильной сети (MNO), поставщика виртуальной сети мобильной связи (MVNO) или третьей стороны. Если вы используете сотовые модули для связи, это ваш выбор.
• Настраиваемая автоматическая подготовка учетных данных устройства к сегменту флэш-памяти устройства, который может иметь специальную защищенную флэш-память, в сочетании с аппаратным модулем безопасности (HSM) во время производства.
• Ручная подготовка закрытых ключей и учетных данных для специальной защищенной флэш-памяти (или незащищенной флэш-памяти, обычно во время создания прототипа, но не рекомендуется для подготовки парка).

Выполнение TLS 1.2 - это ресурсоемкая деятельность из-за требований криптографии, что, в свою очередь, влияет на выбор вычислительных компонентов, особенно если вы используете микроконтроллер для своей разработки. Специализированные ИС обычно включают в себя криптографические процедуры, которые освобождают хост-процессор от применения циклов к операции TLS 1.2, гарантируя, что закрытый ключ не будет загружен в основную память.

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

Для подготовки устройств Интернета вещей требуется облако и согласование устройств

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

С точки зрения сервиса IoT вам понадобится процесс, который согласуется с вашим выбором предоставления учетных данных для создания связанных объектов конфигурации. Когда устройство подключается к службе IoT, служба IoT должна иметь возможность распознавать устройство (аутентификация), разрешать определенные действия с устройством (авторизация), а также работать и управлять устройством в определенном контексте (управление устройством).

Для аутентификации служба IoT должна иметь отпечаток учетных данных, поэтому, когда устройство подключается и отправляет учетные данные в службу IoT, служба IoT может связать физическое соединение с объектами конфигурации. Для AWS IoT вы регистрируете свои учетные данные, которые позволяют службе IoT распознавать входящее соединение. Рукопожатие TLS, которое требует, чтобы у устройства был доступ к закрытому ключу (чего нет у службы IoT), гарантирует, что учетные данные были отправлены с устройства с закрытым ключом. Вот почему так важно защитить закрытый ключ на устройстве.

Для авторизации служба IoT должна применять правила к соединению, которое предоставляет минимальный доступ к службе IoT. Минимальный доступ к услуге IoT означает, что установка ограничивает использование устройством только тех ресурсов, которые ему необходимы для выполнения своих операционных обязательств. Например, клиенты AWS создают политики Интернета вещей, которые связаны с объектом конфигурации учетных данных.

Для управления устройствами вы захотите применить метаданные к своим объектам конфигурации, чтобы четко указать группы или агрегаты устройств или флотов. С IoT нам нужно будет управлять тысячами, десятками тысяч и миллионами устройств. Управлять каждым устройством индивидуально будет нецелесообразно. Заранее планируйте применение метаданных к конфигурации вашего устройства, потому что дооснащение или рефакторинг может быть болезненным. Для AWS IoT вы создаете объекты конфигурации Thing Type и Thing Group, которые определяют методы управления устройствами IoT.

Подходы к масштабной облачной подготовке устройств

Нельзя сказать, что каждые Развертывание IoT отличается, когда дело доходит до подготовки устройств, но существует достаточная дифференциация между поставщиками оборудования, приложениями IoT и рабочими контекстами, чтобы управлять надежным набором механизмов, которые повлияют на ваше решение о подходящем для вас механизме. Вообще говоря, существует три подхода:массовая регистрация, регистрация по запросу и отложенная регистрация. Все следующие методы предполагают, что каждое устройство IoT имеет или будет иметь свою уникальную пару закрытого ключа и сертификата.

Массовая регистрация

При массовой регистрации набор учетных данных, которые вы хотите зарегистрировать в службе Интернета вещей, известен до развертывания устройства в полевых условиях. После получения списка учетных данных вы затем передаете учетные данные в процесс массовой регистрации. Процесс массовой регистрации регистрирует учетные данные, а затем также координирует учетные данные со связанными объектами управления в службе Интернета вещей, которую вы используете для управления своим парком Интернета вещей. Для массовой регистрации может потребоваться настройка, но поставщики услуг Интернета вещей обычно предоставляют клиентам процесс массовой регистрации. Например, AWS обеспечивает процесс регистрации AWS IoT Bulk как часть службы AWS IoT Core и настраиваемую обработку с помощью AWS SDK. Проект с открытым исходным кодом под названием ThingPress обрабатывает определенные варианты использования импорта.

Регистрация по запросу

При регистрации устройства по требованию набор физических устройств с парными учетными данными не известен вам до развертывания устройства в полевых условиях. После того, как устройство будет развернуто в поле, вы включите его. При использовании по запросу подпрограмма подключения определяет, была ли ссылка на эмитента учетных данных зарегистрирована в службе IoT. Пока служба IoT имеет надежный механизм для проверки того, что вы действительно являетесь владельцем эмитента, что означает, что у вас есть идентификация эмитента (в PKI, закрытый ключ эмитента), вы можете быть уверены, что эмитент предоставил учетные данные. Затем подпрограмма автоматически регистрирует учетные данные и создает связанные объекты управления. Например, в AWS есть два механизма регистрации устройств по запросу, которые называются Just-In-Time-Provisioning (JITP), которые используют шаблон обеспечения, и Just-In-Time-Registration (JITR), которые предоставляют механизмы, которые можно полностью настроить.

Ленивая регистрация

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

Сегодня существует три механизма отложенной регистрации:по заявке, по авторизованному мобильному устройству и по авторизованному списку идентификаторов. В первом случае устройство отправляет заявку издателю учетных данных, эмитент отвечает маркером, и устройство использует маркер для прямого вызова API веб-службы для выдачи сертификата. Во втором случае устройство работает в тандеме с мобильным телефоном, где мобильный телефон использует мобильные учетные данные, такие как имя пользователя и пароль, эмитент отвечает токеном, мобильный телефон отправляет токен на устройство, а устройство использует токен для прямого вызова API. В третьем случае авторизованный список, который может быть списком открытых ключей, и устройство выполняет прямой вызов API к службе IoT с CSR. Открытый ключ, полученный из CSR, затем сравнивается с авторизованным списком, а затем предоставляет сертификат устройству, когда существует совпадение. Например, AWS Fleet Provisioning обеспечивает механизмы предоставления на основе заявок и смартфонов, проект с открытым исходным кодом IoT Provisioning Secret-Free предоставляет ленивые механизмы регистрации с использованием заявок, а партнер AWS 1nce предоставляет оптимизированный опыт предоставления услуг сотовой связи через AWS Marketplace.

Выбор подходящей синхронизации устройства

Выбор подходящей для вас подготовки устройства означает поиск учетных данных устройства и практики предоставления ресурсов в облаке, которая согласуется с дизайном вашего оборудования, разработкой программного обеспечения, производством и операциями жизненного цикла устройства. Конструкция оборудования определяет, как вы определяете и храните файлы идентификаторов и учетных данных отдельных устройств. Дизайн программного обеспечения влияет на авторизацию устройства. Производство влияет на условия, при которых секреты будут создаваться и храниться или идентифицироваться, влияет на то, как отпечатки авторизации отражаются в службах Интернета вещей.

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

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

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

Требования к операциям жизненного цикла устройства будут определять уровень гибкости, который потребуется для предоставления устройств в облаке. В частности, хотя большинство процессов для облачной подготовки устройств AWS IoT позволяют автоматически создавать объекты управления, такие как типы вещей и группы вещей, если ваш процесс также требует какой-либо настраиваемой совместимости во время регистрации, вы, возможно, захотите рассмотреть вариант Just-In-Time- Инициализация, которая позволяет глубже настраивать.

Наконец, глядя на жизненный цикл устройства, рассмотрите возможность для устройства менять владельцев на протяжении всей его полезности. Хотя идентификация устройства с точки зрения закрытого ключа может не измениться, существует возможность отказаться от сертификата предыдущего владельца, чтобы перевести устройство в «заводское состояние». Когда новый владелец-человек вводит устройство в новую сеть и настраивает его, возможно, с помощью мобильного приложения, тогда может потребоваться подготовить новый Сертификат. Тогда механика жизненного цикла должна будет сопровождать эти требования.

Заключение

В этой статье мы обсуждали ситуации инициализации Интернета вещей, которые вы, вероятно, наблюдаете сегодня. Точно так же вы стали свидетелями того, что есть много вариантов в зависимости от того, чего вы пытаетесь достичь, и от результатов, которые, по вашему мнению, понравятся вашим клиентам. Как и все остальное, безопасность лежит в основе подготовки, которая начинается с того, что каждое устройство имеет свой собственный уникальный и идентифицируемый закрытый ключ и пару сертификатов. Выбранный вами подход к предоставлению учетных данных создает эту точку опоры для выбора облачной подготовки вашего устройства. Если вы разрабатываете новый дизайн, вам нужно внимательно изучить усиленные решения для обеспечения безопасности оборудования, такие как элементы безопасности и безопасные анклавы, что, в свою очередь, упрощает выделение ресурсов в облаке для устройств. Если вы дорабатываете или переделываете существующий дизайн, ваш выбор может показаться гораздо более ограниченным, но у вас все еще есть варианты подключить свое устройство в режиме IoT. Наконец, из примеров и анекдотов вы смогли убедиться, что AWS IoT предоставил решения для облачной подготовки устройств, которые хорошо сочетаются с решениями наших кремниевых партнеров. Пришло время создавать надежно настроенные и подготовленные устройства IoT!