Het faciliteren van IoT-provisioning op schaal

Of u nu een nieuw apparaat wilt ontwerpen of een bestaand apparaat wilt aanpassen voor het IoT, u moet rekening houden met IoT-provisioning waarmee IoT-apparaten online naar cloudservices worden gebracht. Voor het ontwerp van IoT-inrichtingen moeten beslissingen worden genomen die van invloed zijn op de gebruikerservaring en beveiliging voor zowel de inbedrijfstelling van het netwerk als de voorzieningsmechanismen voor referenties die digitale identiteiten, cloud-eindpunten en netwerkreferenties configureren, zodat apparaten veilig verbinding kunnen maken met de cloud.

Om IoT-provisioning op grote schaal uit te voeren, bouwen en onderhouden klanten vaak op maat gemaakte tools en softwaretoepassingen die vereiste referenties kunnen pushen via protocollen die door hun apparaten worden ondersteund en die meerdere probleemdomeinen bestrijken. De IoT-inrichtingsdomeinen omvatten:

• Netwerk inbedrijfstelling, dat mechanismen biedt voor klanten om contextspecifieke parameters te definiëren;
• Inschrijvingsregistratie, die inloggegevens en configuratie toewijst aan fysieke apparaten; en
• Cloud-provisioning, waarmee de configuratiegegevens aan de cloudzijde worden ingesteld die authenticatie, autorisatie en apparaatbeheer mogelijk maken.

Alle drie deze inrichtingsdomeinen moeten harmonieus samenwerken voor een spectaculaire gebruikerservaring voor de klant.

Een mobiele provider voorziet bijvoorbeeld configuratiegegevens en beleidsinstellingen wanneer een gebruiker van een mobiele telefoon voor het eerst verbinding maakt. Dit is een eenvoudig en goed begrepen proces dat niet veel tijd kost voor de gebruiker van een mobiel apparaat, waarbij de simkaart de identiteit van het apparaat vertegenwoordigt. De situatie wordt heel anders en uitdagend voor klanten, vooral OEM's (Original Equipment Manufacturers), die miljoenen IoT-apparaten proberen te leveren.

In dit artikel leert u hoe u de risico's die samenhangen met uw eigen IoT-implementatie kunt vermijden of beperken, en door middel van korte voorbeelden kunt u begrijpen hoe een IoT-service die wordt aangeboden via cloudplatforms zoals Amazon Web Services (AWS) u helpt om uw IoT-provisioningdoelen.

Benaderingen voor netwerkinbedrijfstelling wanneer dat nodig is

Uiteindelijk maakt uw IoT-apparaat verbinding met en communiceert met een centrale service die de hub is van uw IoT-oplossing. Om die hub te bereiken, moet uw IoT-apparaat lid zijn van een netwerkmedium. Het medium kan een harde draad zijn, zoals Ethernet, of radiotransmissie, zoals Wi-Fi. Afhankelijk van het medium heb je een mens nodig om het apparaat te vertellen bij welk medium het moet aansluiten om de hub te bereiken. Met mobiel hoeft u het apparaat bijvoorbeeld niet te vertellen met welk netwerk u verbinding moet maken, omdat dit is gedefinieerd door de simkaart. Aan de andere kant, om lid te worden van een Wi-Fi-netwerk, moet u de naam en het wachtwoord van het Wi-Fi-toegangspunt kennen en het apparaat deze details kunnen vertellen. We zullen ons concentreren op de apparaten die moeten worden geconfigureerd om lid te worden van een netwerk.

Er zijn verschillende mechanismen die klanten hebben gebruikt om lid te worden van IoT-netwerken. Bijna iedereen heeft tegenwoordig een smartphone en bijna elke smartphone heeft Bluetooth, dus configuratie via Bluetooth is alomtegenwoordig geworden. Dat is echter niet de enige manier om verbinding te maken. Sommige wifi-modules op IoT-apparaten zijn slim genoeg om op zichzelf staande toegangspunten te worden, waar u een eenvoudige webpagina kunt ontwikkelen waarmee gebruikers de configuratie van het grotere netwerk kunnen invoeren. Voor niet-consumentenapparaten is het nog steeds gebruikelijk om via serieel of microSD te configureren. Bluetooth-configuratie met behulp van een smartphone-applicatie is de norm geworden. Deze smartphone-apps kunnen ook helpen bij het inrichten van de cloud op het apparaat, wat u verderop in dit artikel zult ontdekken.

Benaderingen voor het verstrekken van apparaatreferenties op schaal

Processen voor het leveren van apparaatreferenties blijven zeer gefragmenteerd in de branche en er is geen zicht op convergentie op korte termijn. De meeste gecentraliseerde IoT-systemen suggereren, of vereisen, sterk een Transport Layer Security (TLS) 1.2-verbinding voor versleuteld transport, wat recenter, en misschien welsprekend, encryptie in transit wordt genoemd. Tegenwoordig gebruiken de meeste IoT-implementaties Public Key Infrastructure (PKI), dus de rest van dit artikel gaat uit van het gebruik van PKI. In ieder geval is het absoluut noodzakelijk dat elk apparaat zijn eigen unieke identificerende privésleutel en certificaat heeft.

Om een ​​sessie met een cloud (of service-eindpunt) te maken, heeft TLS 1.2 een privésleutel en een x.509-certificaat (of referentie) nodig. Opmerking:sommige technieken, zoals Java Web Tokens of JWT, hebben vergelijkbare uitdagingen, maar worden hier niet besproken. De privésleutel, die vergelijkbaar is met uw DNA, mag alleen bekend zijn bij een individueel apparaat, wat betekent dat deze niet met andere apparaten mag worden gedeeld. Het x.509-certificaat, dat vergelijkbaar is met een rijbewijs, wordt uitgegeven door een verifieerbare certificeringsinstantie (CA) door middel van een Certificate Signing Request (CSR). Het afleveren van een CSR verschilt niet veel van het overhandigen van de paspoortuitgevende instantie van uw land uw geboorteakte met een vingerafdruk en een bewijs van andere geslaagde tests als bewijs om een ​​paspoort te ontvangen. In dit artikel verwijzen we naar het x.509-certificaat als referentie, in de veronderstelling dat het apparaat een unieke privésleutel heeft.

De details van TLS 1.2 vallen buiten het bestek van dit artikel, maar we zullen u genoeg informatie geven om een ​​beetje geïnformeerd te zijn, zodat u begrijpt waarom het absoluut noodzakelijk is dat het apparaat de privésleutel beschermt. Tijdens het TLS 1.2-verbindingsproces vindt een reeks uitwisselingen plaats om te bewijzen dat het apparaat de eigenaar is van de privésleutel die zijn identiteit is. Uw apparaat moet bewijzen dat het de echte eigenaar is van het x.509-certificaat dat het probeert te gebruiken voor authenticatie. Om ervoor te zorgen dat de IoT-service een apparaatreferentie vertrouwt wanneer uw apparaat verbinding maakt, moet u die privésleutel bij de hand hebben. Nu kun je je realiseren dat als een slechte acteur die sleutel in handen krijgt, het beveiligingsmodel uit elkaar valt. Bescherm ten koste van alles de sleutels van uw IoT-kasteel!

Zoals de meesten die het IoT implementeren, moet u beslissingen nemen over hoe u deze referenties op grote schaal inricht. Om een ​​korte beoordeling te geven, moet elk apparaat het volgende hebben:

• Een unieke, onveranderlijke privésleutel die het apparaat vertegenwoordigt. In het ideale geval moet de privésleutel fysiek worden beschermd en niet in het hoofdprogrammageheugen kunnen worden geladen, ter bescherming tegen zij-aan-zij- en andere geavanceerde aanvallen.
• Een referentie met betrekking tot uw applicatie of IoT-service.

Logistiek verschilt tussen de keuzes voor de levering van privésleutels en referenties, sommige die los staan ​​van cloud-provisioning en andere die afhankelijk zijn van cloud-provisioning.

• Geïntegreerde circuitbeveiligingsmodules (die meestal cryptografische mogelijkheden hebben), ofwel standalone ofwel deelnemend aan een System-In-Package (SiP), System-On-Module (SoM) of System-On-Chip (SoC) ontwerp, met een van de volgende gedragingen:

• • Een beveiligingsmodule met een handmatig ingerichte of zelfgenererende privésleutel, of vertrouwensbasis.
  • In aanvulling op het vorige item biedt de beveiligingsmodule referenties in de vorm van vooraf ingerichte x.509-certificaten.

• Subscriber Identity Module (SIM), embedded-SIM (eSIM) en geïntegreerde SIM (iSIM)-technologieën bieden hardware die ontwerpers gebruiken als een mobiele identiteit voor communicatie met mobiele netwerken. Het verstrekken van inloggegevens is meestal afhankelijk van de provider van de mobiele netwerkoperator (MNO), de mobiele virtuele netwerkprovider (MVNO) of een derde partij. Als u mobiele modules gebruikt voor communicatie, is dit uw keuze.
• Aangepaste, geautomatiseerde levering van apparaatreferenties aan een flash-segment van apparaten, dat tijdens de fabricage een speciale beveiligde flash kan hebben, in combinatie met een Hardware Security Module (HSM).
• Handmatige levering van privésleutels en inloggegevens voor speciale beveiligde beveiligde flash (of niet-beveiligde flash, meestal tijdens prototyping, maar niet aanbevolen voor fleet-provisioning).

De uitvoering van TLS 1.2 is een rekenintensieve activiteit vanwege de cryptografievereisten, die op hun beurt de keuze van rekencomponenten beïnvloeden, vooral als u een microcontroller gebruikt voor uw ontwerp. Gespecialiseerde IC's bevatten meestal cryptografieroutines, die de hostprocessor ontlasten van het toepassen van cycli op de TLS 1.2-bewerking, terwijl ervoor wordt gezorgd dat de privésleutel niet in het hoofdgeheugen wordt geladen.

De benadering die u voor hardware kiest, hangt af van uw hardware-ontwerp. Het kiezen van een elegante oplossing voor het hardware-ontwerp vereenvoudigt de provisioning op schaal, maar vereist een vroege selectie van componenten in de levenscyclus van het hardware-ontwerp, aangezien dit van invloed is op andere ontwerpkeuzes van componenten voor compute, cryptografiemodules, wiskundige co-processing en flash. Zeker, voor apparaten op grote schaal wil je niet handmatig leveren, en trends suggereren dat vooraf ingerichte apparaten de minste wrijving opleveren vanuit het oogpunt van productie, operaties en klantervaring.

IoT-apparaatvoorziening vereist cloud- en apparaatorkestratie

Succesvolle inrichting van IoT-apparaten vereist orkestratie van cloud- en apparaatprovisioning die van invloed is op het hardware- en softwareontwerp en op de manier waarop u apparaten gedurende de levenscyclus van het apparaat beheert.

Vanuit het oogpunt van IoT-service hebt u een proces nodig dat is afgestemd op uw keuze voor het inrichten van inloggegevens om gerelateerde configuratieobjecten te maken. Wanneer het apparaat verbinding maakt met een IoT-service, moet de IoT-service het apparaat kunnen herkennen (authenticatie), specifieke apparaatacties inschakelen (autorisatie) en het apparaat in een specifieke context bedienen en beheren (apparaatbeheer).

Voor authenticatie moet de IoT-service een vingerafdruk van de referentie hebben, zodat wanneer het apparaat verbinding maakt en de referentie naar de IoT-service verzendt, de IoT-service de fysieke verbinding kan relateren aan de configuratie-objecten. Voor AWS IoT registreert u uw referentie waarmee de IoT-service de inkomende verbinding kan herkennen. De TLS-handshake, die vereist dat het apparaat toegang heeft tot de Private Key (wat de IoT-service niet heeft) zorgt ervoor dat de referentie is verzonden vanaf het apparaat met de Private Key. Daarom is het zo essentieel om de privésleutel op het apparaat te beschermen.

Voor autorisatie moet de IoT-service regels toepassen op de verbinding die de minimale IoT-servicetoegang verleent. Minimale toegang tot IoT-service betekent dat het apparaat wordt beperkt tot het gebruik van alleen de bronnen die het nodig heeft om aan zijn operationele verplichting te voldoen. AWS-klanten maken bijvoorbeeld IoT-beleid dat betrekking heeft op het configuratieobject van de referentie.

Voor apparaatbeheer wilt u metagegevens toepassen op uw configuratieobjecten om groepen of aggregaties van apparaten of vloten netjes te specificeren. Met IoT zullen we duizenden, tienduizenden en miljoenen apparaten moeten beheren. Het zal onpraktisch zijn om elk apparaat afzonderlijk te beheren. Plan vooruit om metadata toe te passen op uw apparaatconfiguratie, want achteraf aanpassen of refactoring kan pijnlijk zijn. Voor AWS IoT maakt u Thing Type- en Thing Group-configuratieobjecten die IoT Device Management-praktijken aansturen.

Benaderingen voor cloud-inrichting van apparaten op schaal

Het kan niet gezegd worden dat elke IoT-implementatie is anders als het gaat om apparaatvoorziening, maar er is voldoende differentiatie tussen hardwareleveranciers, IoT-applicaties en operationele contexten om een ​​robuuste set mechanismen aan te sturen die uw beslissing over het juiste mechanisme voor u zullen beïnvloeden. Over het algemeen zijn er drie benaderingen:bulkregistratie, on-demand registratie en luie registratie. Bij alle volgende methoden wordt verwacht dat elk IoT-apparaat zijn eigen unieke privésleutel- en certificaatpaar heeft of zal hebben.

Bulkregistratie

Met bulkregistratie is de set referenties die u wilt registreren bij een IoT-service bekend voordat het apparaat in het veld wordt ingezet. Zodra de lijst met inloggegevens is verkregen, kanaliseert u de inloggegevens naar een bulkregistratieproces. Het bulkregistratieproces registreert de referentie en coördineert de referentie vervolgens ook met gerelateerde beheerobjecten in de IoT-service waarmee u uw IoT-vloot beheert. Bulkregistratie kan maatwerk vereisen, maar IoT-serviceproviders bieden klanten meestal een bulkregistratieproces aan. AWS biedt bijvoorbeeld het AWS IoT Bulk-registratieproces als onderdeel van de AWS IoT Core-service en aangepaste verwerking met behulp van de AWS SDK. Een open source-project met de naam ThingPress behandelt specifieke gevallen van importgebruik.

Registratie op aanvraag

Met apparaatregistratie op aanvraag is de set fysieke apparaten met gekoppelde referenties niet bekend bij u voordat het apparaat in het veld wordt geïmplementeerd. Nadat het apparaat in het veld is ingezet, schakelt u het apparaat in. Bij on-demand bepaalt een connectiviteitssubroutine of een verwijzing naar de uitgever van de referentie is geregistreerd bij de IoT-service. Zolang de IoT-service een robuust mechanisme heeft om te verifiëren dat u in feite de eigenaar van de uitgever bent, wat betekent dat u de identiteit van de uitgever bij de hand hebt (in PKI, de privésleutel van de uitgever), kunt u er zeker van zijn dat de uitgever de legitimatie. Vervolgens registreert de subroutine automatisch de referentie en maakt gerelateerde beheerobjecten. AWS heeft bijvoorbeeld twee on-demand apparaatregistratiemechanismen genaamd Just-In-Time-Provisioning (JITP) die gebruikmaakt van een inrichtingssjabloon en Just-In-Time-Registration (JITR) die mechanismen biedt die volledig kunnen worden aangepast.

Luie registratie

Met luie registratie zijn noch de set fysieke apparaten, noch de gekoppelde inloggegevens bekend voordat ze in het veld worden ingezet. In dit geval hebben apparaten een bekende, onveranderlijke identiteit (meestal een beschermde privésleutel) die de IoT-service kan bevestigen zonder de privé-identiteit buiten het apparaat over te dragen.

Tegenwoordig zijn er drie mechanismen voor luie registratie:per claim, per geautoriseerd mobiel apparaat en per geautoriseerde lijst met identiteiten. In het eerste geval verzendt het apparaat de claim naar de uitgever van de referentie, reageert de uitgever met een token en gebruikt het apparaat het token om een ​​directe webservice-API-aanroep te doen om het certificaat uit te geven. In het tweede geval werkt het apparaat samen met een mobiele telefoon, waarbij de mobiele telefoon mobiele inloggegevens gebruikt, zoals een gebruikersnaam en wachtwoord, de uitgever reageert met een token, de mobiele telefoon het token naar het apparaat verzendt en het apparaat het token om een ​​directe API-aanroep te doen. In het derde geval, een geautoriseerde lijst, die een lijst met openbare sleutels kan zijn, en het apparaat maakt een directe API-aanroep naar de IoT-service met een CSR. De openbare sleutel die is afgeleid van de CSR wordt vervolgens vergeleken met de geautoriseerde lijst en levert vervolgens het certificaat aan het apparaat wanneer er een overeenkomst bestaat. AWS Fleet-provisioning biedt bijvoorbeeld op claims en smartphones gebaseerde provisioning-mechanismen, het open source-project IoT Provisioning Secret-Free biedt luie registratiemechanismen met behulp van claims, en AWS-partner 1nce biedt een gestroomlijnde mobiele provisioning-ervaring via de AWS Marketplace.

De apparaatconfiguratie kiezen die bij u past

Als u de apparaatinrichting kiest die voor u geschikt is, moet u de apparaatreferentie en de inrichtingspraktijk voor apparaatcloud vinden die is afgestemd op uw hardwareontwerp, softwareontwerp, productie en levenscyclusactiviteiten van het apparaat. Het hardwareontwerp definieert hoe u individuele apparaatidentiteit en referentiebestanden definieert en opslaat. Het softwareontwerp is van invloed op de autorisatie van het apparaat. Productie beïnvloedt de omstandigheden waaronder geheimen worden gecreëerd en opgeslagen, of geïdentificeerd, en beïnvloeden hoe autorisatievingerafdrukken worden weerspiegeld in IoT-services.

Hoe u besluit om inloggegevens te verstrekken aan de fysieke hardware, wat overeenkomt met het hardwareontwerp dat meestal ver van tevoren wordt bepaald bij het doen van productontwerp, vormt een fundamentele spil voor specifieke soorten cloud-inrichtingsprocessen. Verder, als u niet uw eigen productie doet, gebruikt u contractfabrikanten voor het construeren van uw producten. Contractproductie heeft veel voordelen, maar over veel aspecten van het productieproces heeft u geen controle, waaronder het creëren van apparaatgeheimen zoals privésleutels en certificaten op de productielijn. De risico's zoals overproductie, klonen en andere aanvalsvectoren kunnen rechtstreeks verband houden met de contractfabrikant die wordt ingehuurd, wat betekent dat u veel vertrouwen moet hebben om 's nachts rustig te slapen.

Als u geen privé-CA voor uw IoT-vloot beheert, zijn vooraf ingerichte inloggegevens wellicht geschikt voor u. Vooraf ingerichte inloggegevens kosten misschien wat extra vooraf, maar we hebben gezien dat ze de operationele kosten aanzienlijk verlagen. Als u uw eigen privé-CA moet beheren, bieden sommige hardwarebedrijven vooraf ingerichte referenties wanneer de configuratie wordt uitgevoerd bij tape-out, wat betekent dat de contractfabrikant geen kennis heeft van de geheimen op het apparaat. Anders wilt u misschien leunen op inrichting in luie stijl waarbij het apparaat de onveranderlijke privésleutel of reproduceerbare zelfgenererende privésleutel op het apparaat heeft en kan deelnemen met een IoT-service om inloggegevens te laten implementeren na een bepaald niveau van attestatie. Als u zich in de ongelukkige situatie bevindt dat u geen onveranderlijke privésleutel op het apparaat heeft, kunt u nog steeds een privésleutel en referenties rechtstreeks in flash voorzien, maar dit wordt ten zeerste afgeraden.

In tegenstelling tot hardwareontwerp is softwareontwerp flexibeler en kan het veranderen gedurende de ontwikkeling van het apparaat en zelfs tijdens de levenscyclus (denk aan over-the-air firmware-updates). Telkens wanneer u een nieuwe batch apparaten naar klanten verzendt, moet u steunen op het inrichtingsproces van de cloud voor apparaten. Net als bij het ontwerpen van software, vereist het inrichtingsontwerp mogelijk flexibiliteit op basis van uw veranderende softwarevereisten. De vereiste configuratie- en aanpassingsbreedte is de drijvende kracht achter het apparaatcloud-provisioningproces dat u gaat gebruiken bij het implementeren van nieuwe of extra apparaatvloten.

De vereisten voor apparaatlevenscyclusactiviteiten zullen het niveau van flexibiliteit verhogen dat nodig is voor de inrichting van de cloud van apparaten. Meer specifiek, hoewel de meeste processen voor AWS IoT-apparaatcloud-provisioning het automatisch aanmaken van beheerobjecten zoals Thing Types en Thing Groups mogelijk maken, als uw proces ook enige aangepaste interoperabiliteit vereist tijdens de registratietijd, kunt u Just-In-Time- overwegen. Voorziening die diepere aanpassingen mogelijk maakt.

Tot slot, als je kijkt naar de levenscyclus van het apparaat, overweeg dan de mogelijkheid voor het apparaat om van menselijke eigenaar te veranderen tijdens zijn bruikbaarheid. Hoewel de identiteit van het apparaat in termen van de privésleutel mogelijk niet verandert, is er een mogelijkheid om het certificaat van de vorige eigenaar te beëindigen om het apparaat naar een "fabrieksstatus" te verplaatsen. Wanneer de nieuwe menselijke eigenaar het apparaat in gebruik neemt bij een nieuw netwerk en voorzieningen gebruikt met behulp van misschien een mobiele applicatie, moet op dat moment mogelijk een nieuw certificaat worden geleverd. De levenscyclusmechanica zou dan die vereisten moeten begeleiden.

Conclusie

In dit artikel hebben we IoT-inrichtingssituaties besproken die u vandaag waarschijnlijk zult tegenkomen. Evenzo hebt u gezien dat er veel keuzes zijn, afhankelijk van wat u probeert te bereiken en de resultaten waarvan u wilt dat uw klanten ervan genieten. Zoals alles ligt beveiliging ten grondslag aan de inrichting, die begint met elk apparaat met zijn eigen unieke en identificeerbare privésleutel en certificaatpaar. De benadering voor het inrichten van inloggegevens die u kiest, creëert dat draaipunt voor de inrichtingskeuzes van uw apparaatcloud. Als u een nieuw ontwerp maakt, moet u eens goed kijken naar geharde hardwarebeveiligingsoplossingen zoals beveiligde elementen en beveiligde enclaves, wat op zijn beurt de inrichting van de cloud voor apparaten vereenvoudigt. Als je een bestaand ontwerp evolueert of herwerkt, lijken je keuzes misschien veel beperkter, maar er zijn nog steeds opties om je apparaat in een IoT-capaciteit te laten aansluiten. Ten slotte kon je door de voorbeelden en anekdotes heen zien dat AWS IoT cloud-provisioningoplossingen voor apparaten heeft geleverd die goed passen bij onze siliciumpartneroplossingen. Nu is het tijd om veilig in gebruik genomen en ingerichte IoT-apparaten te gaan bouwen!