Faciliter le provisionnement IoT à grande échelle

Que vous cherchiez à concevoir un nouvel appareil ou à moderniser un appareil existant pour l'IoT, vous devrez envisager le provisionnement IoT qui met les appareils IoT en ligne sur les services cloud. La conception de l'approvisionnement IoT nécessite la prise de décisions qui ont un impact sur l'expérience utilisateur et la sécurité à la fois pour la mise en service du réseau et les mécanismes d'approvisionnement des informations d'identification qui configurent les identités numériques, les points de terminaison du cloud et les informations d'identification du réseau afin que les appareils puissent se connecter en toute sécurité au cloud.

Pour effectuer le provisionnement IoT à grande échelle, les clients créent et gèrent souvent des outils et des applications logicielles personnalisés qui peuvent pousser les informations d'identification requises sur des protocoles pris en charge par leurs appareils et couvrant plusieurs domaines problématiques. Les domaines d'approvisionnement IoT incluent :

• La mise en service du réseau, qui fournit aux clients des mécanismes pour définir des paramètres spécifiques au contexte ;
• Fourniture des informations d'identification, qui attribue les informations d'identification et la configuration aux appareils physiques ; et
• Le provisionnement cloud, qui définit les données de configuration côté cloud qui permettent l'authentification, l'autorisation et la gestion des appareils.

Ces trois domaines d'approvisionnement doivent fonctionner en harmonie pour une expérience utilisateur spectaculaire.

Par exemple, un opérateur mobile fournit des données de configuration et des paramètres de stratégie lorsqu'un utilisateur de téléphone mobile se connecte pour la première fois. Il s'agit d'un processus simple et bien compris qui ne prend pas beaucoup de temps pour l'utilisateur de l'appareil mobile où la carte SIM représente l'identité de l'appareil. La situation devient très différente et difficile pour les clients, en particulier les fabricants d'équipement d'origine (OEM), qui essaient de fournir des millions d'appareils IoT.

Tout au long de cet article, vous pourrez apprendre comment éviter ou atténuer les risques associés à votre propre déploiement IoT et comprendre, à travers de brefs exemples, comment un service IoT fourni via des plateformes cloud comme Amazon Web Services (AWS) vous aide à atteindre vos objectifs de provisionnement IoT.

Approches de mise en service du réseau lorsque le besoin s'en fait sentir

Finalement, votre appareil IoT se connecte et communique avec un service central qui est le hub de votre solution IoT. Pour atteindre ce hub, votre appareil IoT doit rejoindre un support en réseau. Le support peut être un fil dur, comme Ethernet, ou une transmission radio, comme le Wi-Fi. Selon le support, vous avez besoin d'un humain pour dire à l'appareil quel support il doit rejoindre pour réussir à atteindre le hub. Par exemple, avec le cellulaire, vous n'aurez pas besoin de dire à l'appareil le réseau à rejoindre car cela a été défini par la carte SIM. D'autre part, pour rejoindre un réseau Wi-Fi, vous devez connaître le nom et le mot de passe du point d'accès Wi-Fi et être en mesure de communiquer ces informations à l'appareil. Nous nous concentrerons sur les appareils nécessitant une configuration pour rejoindre un réseau.

Il existe plusieurs mécanismes différents que les clients utilisent pour rejoindre les réseaux IoT. Presque tout le monde a un smartphone aujourd'hui et presque tous les smartphones ont Bluetooth, donc la configuration via Bluetooth est devenue omniprésente. Cependant, ce n'est pas le seul moyen de se connecter. Certains modules Wi-Fi sur les appareils IoT sont suffisamment intelligents pour devenir des points d'accès à part entière, où vous pouvez développer une simple page Web qui permet aux utilisateurs de saisir la configuration du réseau plus large. Pour les appareils non grand public, il est toujours courant de configurer via série ou microSD. La configuration Bluetooth à l'aide d'une application smartphone est devenue la norme. Ces applications pour smartphones peuvent également aider au provisionnement du cloud des appareils, que vous découvrirez plus loin dans cet article.

Approches du provisionnement des identifiants des appareils à grande échelle

Les processus d'approvisionnement des informations d'identification des appareils continuent d'être très fragmentés dans l'ensemble du secteur, sans aucune ligne de mire pour une convergence de sitôt. La plupart des systèmes centralisés IoT suggèrent fortement, ou nécessitent, une connexion Transport Layer Security (TLS) 1.2 pour le transport crypté, qui est plus récemment, et peut-être éloquent, connu sous le nom de cryptage en transit. Aujourd'hui, la plupart des déploiements IoT utilisent l'infrastructure à clé publique (PKI), donc le reste de cet article suppose l'utilisation de la PKI. Dans tous les cas, il est impératif que chaque appareil possède sa propre clé privée et son propre certificat d'identification.

Pour créer une session avec un cloud (ou un point de terminaison de service), TLS 1.2 nécessite une clé privée et un certificat x.509 (ou informations d'identification). Remarque :Certaines techniques telles que les jetons Web Java, ou JWT, présentent des défis similaires mais ne seront pas abordées ici. La clé privée, qui est comme votre ADN, ne doit être connue que d'un appareil individuel, ce qui signifie qu'elle ne doit pas être partagée avec d'autres appareils. Le certificat x.509, qui s'apparente à un permis de conduire, est délivré par une autorité de certification (CA) vérifiable en fournissant une demande de signature de certificat (CSR). La remise d'un CSR n'est pas très différente de la remise à l'entité émettrice du passeport de votre pays de votre certificat de naissance avec une empreinte digitale et une preuve d'autres tests réussis comme preuve pour recevoir un passeport. Tout au long de cet article, nous nous référons au certificat x.509 en tant qu'identifiant, en supposant que l'appareil dispose d'une clé privée unique.

Les détails de TLS 1.2 dépassent le cadre de cet article, mais nous allons juste vous donner suffisamment d'informations pour être un peu informé afin que vous puissiez comprendre pourquoi il est impératif que l'appareil protège la clé privée. Au cours du processus de connexion TLS 1.2, une série d'échanges se produisent pour prouver que l'appareil est le propriétaire de la Clé Privée qui est son identité. Votre appareil doit prouver qu'il est le véritable propriétaire du certificat x.509 qu'il essaie d'utiliser pour l'authentification. Pour que le service IoT fasse confiance aux informations d'identification de l'appareil lorsque votre appareil se connecte, vous devez avoir cette clé privée à portée de main. Vous pouvez maintenant vous rendre compte que si un mauvais acteur met la main sur cette clé, le modèle de sécurité s'effondre. À tout prix, protégez les clés de votre château IoT !

Comme la plupart de ceux qui déploient l'IoT, vous devez prendre des décisions sur la manière de provisionner ces informations d'identification à grande échelle. Pour passer brièvement en revue, chaque appareil doit avoir :

• Une clé privée unique et immuable représentant l'appareil. Idéalement, pour se protéger contre les attaques côte à côte et autres attaques avancées, la clé privée doit être physiquement protégée et ne pas pouvoir être chargée dans la mémoire principale du programme.
• Un identifiant, relatif à votre application ou service IoT.

La logistique diffère selon les choix pour le provisionnement de la clé privée et des informations d'identification, certains qui sont disjoints du provisionnement cloud et d'autres qui reposent sur le provisionnement cloud.

• Modules de sécurité de circuit intégrés (qui ont généralement des capacités cryptographiques), soit autonomes, soit participant à une conception System-In-Package (SiP), System-On-Module (SoM) ou System-On-Chip (SoC), avoir l'un des comportements suivants :

• • Un module de sécurité doté d'une clé privée provisionnée manuellement ou autogénérée, ou d'une racine de confiance.
  • En plus de l'élément précédent, le module de sécurité fournit des informations d'identification sous la forme de certificats x.509 pré-provisionnés.

• Les technologies de module d'identité d'abonné (SIM), de carte SIM intégrée (eSIM) et de carte SIM intégrée (iSIM) fournissent du matériel que les concepteurs utilisent comme identité cellulaire pour communiquer avec les réseaux cellulaires. La fourniture d'informations d'identification dépend généralement du fournisseur de l'opérateur de réseau mobile (MNO), du fournisseur de réseau virtuel mobile (MVNO) ou d'un tiers. Si vous utilisez des modules cellulaires pour la communication, c'est votre choix.
• Fourniture automatisée et personnalisée des identifiants de l'appareil à un segment flash de l'appareil, qui pourrait avoir une mémoire flash sécurisée spéciale, en conjonction avec un module de sécurité matérielle (HSM) pendant la fabrication.
• Approvisionnement manuel des clés privées et des informations d'identification sur une mémoire flash sécurisée spéciale (ou une mémoire flash non sécurisée, généralement pendant le prototypage, mais non recommandée pour l'approvisionnement de flotte).

L'exécution de TLS 1.2 est une activité de calcul intensif en raison des exigences de cryptographie, qui à leur tour influencent le choix des composants de calcul, en particulier si vous utilisez un microcontrôleur pour votre conception. Les circuits intégrés spécialisés incluent généralement des routines de cryptographie, qui soulagent le processeur hôte d'appliquer des cycles sur l'opération TLS 1.2 tout en garantissant que la clé privée n'est pas chargée dans la mémoire principale.

L'approche que vous adoptez pour le matériel dépend de la conception de votre matériel. Le choix d'une solution élégante pour la conception matérielle simplifie certainement le provisionnement à grande échelle, mais nécessite une sélection de composants tôt dans le cycle de vie de la conception matérielle, car cela influence les autres choix de conception de composants pour le calcul, les modules de cryptographie, le co-traitement mathématique et la mémoire flash. Certes, pour les appareils à grande échelle, vous ne voudrez pas provisionner manuellement, et les tendances suggèrent que les appareils préconfigurés produisent le moins de frictions du point de vue de la fabrication, des opérations et de l'expérience client.

Le provisionnement des appareils IoT nécessite une orchestration du cloud et des appareils

La réussite du provisionnement des appareils IoT nécessite une orchestration du provisionnement du cloud et des appareils qui influence la conception matérielle et logicielle ainsi que la façon dont vous gérerez les appareils tout au long du cycle de vie des appareils.

Du point de vue du service IoT, vous aurez besoin d'un processus qui s'aligne sur votre choix d'approvisionnement des informations d'identification pour créer des objets de configuration associés. Lorsque l'appareil se connecte à un service IoT, le service IoT doit être capable de reconnaître l'appareil (authentification), d'activer des actions spécifiques de l'appareil (autorisation) et de faire fonctionner et gérer l'appareil dans un contexte spécifique (gestion des appareils).

Pour l'authentification, le service IoT doit avoir une empreinte digitale des informations d'identification. Ainsi, lorsque l'appareil se connecte et envoie les informations d'identification au service IoT, le service IoT peut associer la connexion physique aux objets de configuration. Pour AWS IoT, vous enregistrez vos informations d'identification qui permettent au service IoT de reconnaître la connexion entrante. La négociation TLS, qui nécessite que l'appareil ait accès à la clé privée (ce que le service IoT n'a pas) garantit que les informations d'identification ont été envoyées à partir de l'appareil avec la clé privée. C'est pourquoi il est si essentiel de protéger la clé privée sur l'appareil.

Pour l'autorisation, le service IoT doit appliquer des règles à la connexion qui accorde l'accès minimum au service IoT. L'accès minimum au service IoT signifie que la définition des limites de l'appareil pour qu'il n'utilise que les ressources dont il a besoin pour remplir son obligation opérationnelle. Par exemple, les clients AWS créent des stratégies IoT liées à l'objet de configuration des informations d'identification.

Pour la gestion des appareils, vous souhaiterez appliquer des métadonnées à vos objets de configuration pour spécifier proprement des groupes ou des agrégations d'appareils ou de flottes. Avec l'IoT, nous devrons gérer des milliers, des dizaines de milliers et des millions d'appareils. Il sera peu pratique de gérer chaque appareil individuellement. Planifiez à l'avance pour appliquer des métadonnées à la configuration de votre appareil, car la mise à niveau ou la refactorisation peut être pénible. Pour AWS IoT, vous créez des objets de configuration Type d'objet et Groupe d'objets qui pilotent les pratiques de gestion des appareils IoT.

Approches pour le provisionnement du cloud des appareils à grande échelle

On ne peut pas dire que chaque Le déploiement de l'IoT est différent en ce qui concerne l'approvisionnement des appareils, mais il existe suffisamment de différenciation entre les fournisseurs de matériel, les applications IoT et les contextes opérationnels pour conduire un ensemble robuste de mécanismes qui influenceront votre décision sur le mécanisme qui vous convient. De manière générale, il existe trois approches :l'enregistrement en masse, l'enregistrement à la demande et l'enregistrement paresseux. Toutes les méthodes suivantes s'attendent à ce que chaque appareil IoT ait, ou aura, sa propre paire de clé privée et de certificat.

Enregistrement en masse

Avec l'enregistrement en masse, l'ensemble d'informations d'identification que vous souhaitez enregistrer auprès d'un service IoT est connu avant le déploiement de l'appareil sur le terrain. Une fois la liste des informations d'identification obtenue, vous canalisez ensuite les informations d'identification vers un processus d'enregistrement en masse. Le processus d'enregistrement en bloc enregistre les informations d'identification, puis coordonne également les informations d'identification avec les objets de gestion associés dans le service IoT que vous utilisez pour gérer votre flotte IoT. L'enregistrement en masse peut nécessiter une personnalisation, mais les fournisseurs de services IoT proposent généralement un processus d'enregistrement en masse aux clients. Par exemple, AWS fournit un processus d'enregistrement AWS IoT Bulk dans le cadre du service AWS IoT Core et un traitement personnalisé à l'aide du kit SDK AWS. Un projet open source nommé ThingPress gère des cas d'utilisation d'importation spécifiques.

Inscription à la demande

Avec l'enregistrement d'appareils à la demande, vous ne connaissez pas l'ensemble d'appareils physiques avec des informations d'identification appariées avant le déploiement de l'appareil sur le terrain. Une fois l'appareil déployé sur le terrain, vous allumerez l'appareil. Avec à la demande, un sous-programme de connectivité détermine si une référence à l'émetteur des informations d'identification a été enregistrée auprès du service IoT. Tant que le service IoT dispose d'un mécanisme robuste pour vérifier que vous êtes bien le propriétaire de l'émetteur, ce qui signifie que vous disposez de l'identité de l'émetteur (en PKI, la clé privée de l'émetteur), vous pouvez être assuré que l'émetteur a fourni le justificatif. Ensuite, le sous-programme enregistre automatiquement les informations d'identification et crée les objets de gestion associés. Par exemple, AWS dispose de deux mécanismes d'enregistrement d'appareils à la demande nommés Just-In-Time-Provisioning (JITP) qui utilise un modèle de provisionnement et Just-In-Time-Registration (JITR) qui fournit des mécanismes pouvant être entièrement personnalisés.

Inscription paresseuse

Avec l'enregistrement différé, ni l'ensemble des périphériques physiques ni les informations d'identification couplées ne sont connus avant le déploiement sur le terrain. Dans ce cas, les appareils ont une identité connue et immuable (généralement, une clé privée protégée) que le service IoT peut confirmer sans transférer l'identité privée au-delà de l'appareil.

Aujourd'hui, il existe trois mécanismes d'enregistrement paresseux :par revendication, par appareil mobile autorisé et par liste d'identités autorisée. Dans le premier cas, l'appareil envoie la demande à l'émetteur des informations d'identification, l'émetteur répond avec un jeton et l'appareil utilise le jeton pour effectuer un appel API de service Web direct pour émettre le certificat. Dans le second cas, l'appareil fonctionne en tandem avec un téléphone mobile, où le téléphone mobile utilise des informations d'identification mobiles, comme un nom d'utilisateur et un mot de passe, l'émetteur répond avec un jeton, le téléphone mobile envoie le jeton à l'appareil et l'appareil utilise le jeton pour effectuer un appel API direct. Dans le troisième cas, une liste autorisée, qui peut être une liste de clés publiques, et l'appareil effectue un appel API direct au service IoT avec un CSR. La clé publique dérivée du CSR est ensuite comparée à la liste autorisée, puis fournit le certificat à l'appareil lorsqu'une correspondance existe. Par exemple, l'approvisionnement AWS Fleet fournit des mécanismes d'approvisionnement basés sur les revendications et les smartphones, le projet open source IoT Provisioning Secret-Free fournit des mécanismes d'enregistrement paresseux à l'aide de revendications, et le partenaire AWS 1nce fournit une expérience d'approvisionnement cellulaire rationalisée via AWS Marketplace.

Choisir l'approvisionnement de l'appareil qui vous convient

Choisir l'approvisionnement de l'appareil qui vous convient signifie trouver les informations d'identification de l'appareil et la pratique d'approvisionnement du cloud de l'appareil qui s'alignent sur vos opérations de conception matérielle, de conception logicielle, de fabrication et de cycle de vie de l'appareil. La conception du matériel définit la façon dont vous définissez et stockez les fichiers d'identité et d'identification des périphériques individuels. La conception du logiciel influence l'autorisation de l'appareil. La fabrication influence les conditions dans lesquelles les secrets seront créés et stockés, ou identifiés, influencent la façon dont les empreintes digitales d'autorisation se reflètent dans les services IoT.

La façon dont vous décidez d'effectuer l'approvisionnement des informations d'identification sur le matériel physique, qui reflète la conception du matériel qui est généralement décidée longtemps à l'avance lors de la conception du produit, crée un pivot fondamental vers des types spécifiques de processus d'approvisionnement cloud. De plus, si vous ne faites pas votre propre fabrication, vous utiliserez des fabricants sous contrat pour construire vos produits. La fabrication sous contrat présente de nombreux avantages, mais de nombreux aspects du processus de fabrication ne seront pas sous votre contrôle, notamment la création de secrets d'appareil tels que des clés privées et des certificats sur la ligne de fabrication. Les risques tels que la surproduction, le clonage et d'autres vecteurs d'attaque peuvent être directement liés au sous-traitant en location, ce qui signifie que vous devez avoir beaucoup de confiance pour dormir tranquille la nuit.

Si vous ne gérez pas d'autorité de certification privée pour votre flotte IoT, les informations d'identification pré-provisionnées peuvent vous convenir. Les informations d'identification pré-provisionnées peuvent coûter un peu plus cher au départ, mais nous avons vu qu'elles réduisent considérablement les coûts d'exploitation. Si vous devez gérer votre propre autorité de certification privée, certaines sociétés de matériel fournissent des informations d'identification préconfigurées où la configuration est effectuée lors de la sortie de la bande, ce qui signifie que le fabricant sous contrat n'aura aucune connaissance des secrets de l'appareil. Sinon, vous voudrez peut-être vous tourner vers un approvisionnement de style paresseux où l'appareil dispose de la clé privée immuable ou de la clé privée auto-générée reproductible sur l'appareil et peut participer à un service IoT pour que les informations d'identification soient déployées après un certain niveau d'attestation. Si vous vous retrouvez dans la malheureuse situation de ne pas avoir de clé privée immuable sur l'appareil, vous pouvez toujours fournir une clé privée et des informations d'identification directement pour flasher, mais cela n'est pas du tout recommandé.

Contrairement à la conception matérielle, la conception logicielle est plus flexible et peut changer tout au long du développement de l'appareil et même du cycle de vie (pensez aux mises à jour du micrologiciel en direct). Chaque fois que vous expédiez un nouveau lot d'appareils à des clients, vous devrez vous appuyer sur le processus de provisionnement du cloud des appareils. À l'instar de la conception logicielle, la conception de l'approvisionnement peut nécessiter une flexibilité en fonction de l'évolution de vos exigences logicielles. L'étendue de la configuration et de la personnalisation requise détermine le processus de provisionnement du cloud d'appareils que vous utiliserez lors du déploiement de flottes d'appareils nouvelles ou supplémentaires.

Les exigences opérationnelles du cycle de vie des appareils détermineront le niveau de flexibilité qui sera requis pour le provisionnement du cloud des appareils. Plus précisément, alors que la plupart des processus de provisionnement du cloud des appareils AWS IoT permettent la création automatique d'objets de gestion tels que les types d'objets et les groupes d'objets, si votre processus nécessite également une interopérabilité personnalisée pendant la période d'enregistrement, vous pouvez envisager le juste-à-temps. Provisioning qui permet une personnalisation plus poussée.

Enfin, lorsque vous examinez le cycle de vie de l'appareil, envisagez l'opportunité pour l'appareil de changer de propriétaire humain tout au long de son utilité. Bien que l'identité de l'appareil en termes de clé privée puisse ne pas changer, il est possible de déprécier le certificat du propriétaire précédent pour déplacer l'appareil vers un "état d'usine". Lorsque le nouveau propriétaire humain met l'appareil en service sur un nouveau réseau et le provisionne à l'aide peut-être d'une application mobile, un nouveau certificat peut devoir être provisionné à ce moment-là. La mécanique du cycle de vie devra alors accompagner ces exigences.

Conclusion

Tout au long de cet article, nous avons discuté des situations d'approvisionnement IoT auxquelles vous êtes probablement témoin aujourd'hui. De même, vous avez constaté qu'il existe de nombreux choix en fonction de ce que vous essayez d'atteindre et des résultats que vous souhaitez que vos clients apprécient. Comme tout, la sécurité sous-tend le provisionnement, qui commence avec chaque appareil ayant sa propre paire de clé privée et de certificat unique et identifiable. L'approche d'approvisionnement des informations d'identification que vous choisissez crée ce point de pivot pour vos choix d'approvisionnement en nuage de vos appareils. Si vous faites une nouvelle conception, vous voudrez examiner de près les solutions de sécurité matérielle renforcées telles que les éléments sécurisés et les enclaves sécurisées, ce qui à son tour simplifie le provisionnement du cloud des appareils. Si vous faites évoluer ou retravaillez une conception existante, vos choix peuvent sembler beaucoup plus limités, mais il existe toujours des options pour vous permettre de connecter votre appareil dans une capacité IoT. Enfin, tout au long des exemples et des anecdotes, vous avez pu constater qu'AWS IoT a fourni des solutions de provisionnement de cloud pour appareils qui se marient bien avec nos solutions partenaires sur silicium. Il est maintenant temps de construire des appareils IoT mis en service et provisionnés en toute sécurité !