Efficiënte IoT-sensor provisioning: Veilige connectiviteit & credentialbeheer

Het internet of things (IoT) is voor de meeste van ons op dit punt geen vreemde meer. IoT-apparaten kunnen worden gezien als behorend tot de consumenten-, medische- of industriële markten. Of het apparaat nu een videobel is, een insulinepomp, of een industriële sensor, de gebruiker zal geconfronteerd worden met twee significante uitdagingen: 1) het apparaat fysiek/logisch verbinden met het netwerk en 2) ervoor zorgen dat het apparaat de juiste credentials heeft om het in staat te stellen te interopereren met andere apparaten op hetzelfde netwerk of met de server(s) die verwacht worden de data van het apparaat te verzamelen. Deze uitdagingen kunnen grotendeels gegroepeerd worden in een proces bekend als provisioning.

Basis Provisioning

De grootste uitdaging in het provisioning-proces is de capaciteit om te waarborgen dat een apparaat en de verbinding met het netwerk/server veilig zijn. Dit steunt zwaar op zowel asymmetrische als symmetrische encryptietechnieken en het bestaan van digitale certificaten.

In het geval van asymmetrische encryptie, is er een wiskundig gerelateerd publiek/privé sleutelpaar. Als iets versleuteld is met de publieke sleutel, dan kan alleen de privésleutel het ontsleutelen. Dit in tegenstelling tot symmetrische encryptie, waar dezelfde sleutel gebruikt wordt om zowel te versleutelen als te ontsleutelen. Symmetrische encryptie vereist minder resources (bijv. minder bits in de sleutel, wat resulteert in snellere encryptie) om betere beveiliging te bereiken dan met asymmetrische encryptie. Echter, symmetrische encryptie vereist dat de sleutels op een of andere manier uitgewisseld worden die niet door een tussenpersoon gezien kan worden. Wat typisch gedaan wordt is het gebruik van de bestemming's publieke sleutel om een pre-master-sleutel te versleutelen, deze naar de bestemming te sturen en dan de bestemming hun privésleutel gebruikt om de pre-master-sleutel te ontsleutelen en de gedeelde sessiesleutel te genereren. Dit is de manier waarop Diffie-Hellman-sleuteluitwisseling het gebruik van snellere en sterkere symmetrische encryptie mogelijk maakt met een handshake die asymmetrische encryptie benut.

De eerste vereiste voor provisioning is dat het IoT-apparaat een uniek identiteitsmechanisme heeft. Dit kan onderdeel zijn van het apparaatfabricatieproces waarbij een identiteitschip onderdeel is van de stuklijst, of wat veel microprocessorfabrikanten tegenwoordig doen – een unieke identiteit met publieke en privésleutels in de processor branden bij de fabricage. Dit wordt aangeduid als provisioning tijdens de leveringsketen.

We kunnen zien dat de basisschritten die gebruikt worden voor het provisioneren van IoT-apparaten ofwel binnen het bedrijf of met dienstverleners zoals Amazon Web Services, Google Cloud, of Microsoft Azure, allemaal een vergelijkbaar proces volgen:

1. Apparaatinschrijving

   • Maak een record aan op de server die metadata voor het IoT-apparaat bevat. Dat kan een serienummer of andere unieke apparaatidentifier, locatie van het apparaat, en andere data omvatten die het bedrijf dat het IoT-apparaat gebruikt helpt om zijn rol te begrijpen.

2. Sleutelgeneratie

   • Als het IoT-apparaat een uniek identiteitschip heeft zoals een Trusted Platform Module (TPM) of anderszins een set publieke en privésleutels geïnstalleerd op fabrikaatmoment, dan is deze sleutelgeneratie al gedaan. Echter, als een set sleutels niet al bestaat, kan de installateur een set genereren met tools zoals OpenSSL. Of als een van de cloud-providers gebruikt wordt, zal de dienstverlener typisch een sleutelgeneratiemechanisme hebben. De publieke en privésleutels moeten op het apparaat opgeslagen worden, met de privésleutel geplaatst in een soort beschermde opslag om te voorkomen dat het in het veld uitgelezen wordt. Om veiligheidsredenen wordt voorgesteld dat de sleutels tenminste 2048-bits lang zijn of langer als RSA-gebaseerde algoritmes gebruikt worden of 256 bits of langer voor elliptische-curve-gebaseerde algoritmes.

3. Een certificaat genereren

   • Bij activatie genereert het apparaat een certificate signing request (CSR) en stuurt die CSR naar een certificeringsinstantie (CA) voor ondertekening. De CA is typisch een vertrouwde derde partij zoals Digicert, GlobalSign, of zelfs de cloud-dienstverlener. Het apparaat stuurt zijn publieke sleutel en enige metadata in de CSR en de CA genereert een secure socket layer (SSL) certificaat (typisch een X.509 certificaat). Het tekent dat certificaat met de CA's privésleutel voordat het teruggestuurd wordt naar het apparaat. Zodra het apparaat een certificaat heeft, kan het deelnemen aan een transport layer security (TLS) handshake die een versleutelde link met de server kan tot stand brengen. Omdat het certificaat getekend is met de privésleutel van een vertrouwde derde partij, kunnen we beweren dat het apparaat dat de privésleutel beheert geassocieerd met de publieke sleutel in het certificaat bekend en vertrouwd is.

   • Het is ook mogelijk om een „self-signed” certificaat te genereren. Als het apparaat bijvoorbeeld in-house geproduceerd werd en alleen door de fabrikant gebruikt wordt, zou er geen behoefte zijn aan een externe CA om het te certificeren. Met tools zoals OpenSSL kan de fabrikant het publieke/privé sleutelpaar en het certificaat genereren, en ze kopiëren naar de beveiligde opslag op het apparaat zodra het van de productielijn komt.

4. Het apparaat provisioneren

   • Met de sleutels en certificaat kan het apparaat nu zijn identiteit beweren aan de dienstverlener door een beveiligde link via TLS of de datagram-versie van TLS bekend als DTLS te initiëren. De TLS/DTLS-handshake vestigt een symmetrische encryptiesleutel die gebruikt kan worden voor daaropvolgende beveiligde dataoverdracht tussen het apparaat en de dienstverlener zodat het apparaat ingeschreven kan worden, en de data opgeslagen in het record gegenereerd met de dienstverlener in stap 1.

De handshake wordt gebruikt om een beveiligde sleuteluitwisseling te implementeren om een symmetrische encryptielink tot stand te brengen. Eenmaal de link gevestigd, kan data van het apparaat naar de server overgedragen worden zonder vrees voor compromittering door cyberaanvallen. Bijvoorbeeld, man-in-the-middle (MITM) aanvallen, waar een tussenpersoon de communicatie in transit onderschept, zullen voorkomen worden aangezien de tussenpersoon de symmetrische sleutel die in de bulk-encryptie gebruikt wordt, mist. Nieuwere versies van de TLS-handshake (TLS 1.3) verkorten deze berichtenuitwisseling dramatisch om lagere latentie-overdrachten van apparaten naar dataverzamelingssystemen te ondersteunen.

Bulk Provisioning

Tot nu toe was de provisioning-discussie gericht op een mens in de lus voor singleton of kleine aantallen apparaten. De beveiliging richtte zich ook grotendeels op het gebruik van encryptie en de mens in staat te zijn om de authenticiteit van het apparaat te attesteren door het uit de oorspronkelijke verpakking te halen. Echter, bij industriële schalen is deze vereiste van een fysiek betrokken mens impractisch.

Bijvoorbeeld, veel van de nieuwere slimme gebouwen bevatten duizenden sensoren, waaronder omgevingslichtsensoren, luchtkwaliteitssensoren, microfoons om kamerbezetting te bepalen, en temperatuur- en vochtigheidssensoren, om er maar een paar te noemen. Als een mens elk van deze apparaten handmatig moest provisioneren, zou het snel een full-time baan worden. Echter, de identiteiten van deze apparaten en hun beveiligingsreferenties zullen gewaarborgd moeten worden. Hoe kunnen apparaten dan in bulk geprovisioneerd worden zonder menselijke interventie?

Eerst moeten we begrijpen dat industriële IoT-apparaten nog steeds de twee basisvereisten hebben die aan het begin besproken werden. De operator moet de apparaten associëren met een netwerk en de identiteit van de apparaten en hun beveiliging verifiëren voordat ze toegang verlenen tot de server of dienstverlener die de sensoroutputs verzamelt en analyseert. De fysieke verbinding met het netwerk zal variëren gebaseerd op de communicatiemedia en het kunnen beweren van een identiteit vereist het gebruik van digitale certificaten. Om bulk provisioning te ondersteunen, is het best om het publiek/privé sleutelpaar en het certificaat van het apparaat in de leveringsketen te incorporeren, zodat het apparaat uit de doos klaar is om de certificate signing request te genereren en de provisioning-handshake af te handelen.

Naturellijk zullen veel IoT-apparaten een draadloos protocol van een of andere soort gebruiken, vooral als het om greenfield-toepassingen gaat. Er zijn een veelheid van keuzes waaronder cellulair, Wi-Fi, Zigbee, LoRaWAN, SigFox, en meer. Echter, als we een legacy-toepassing upgraden, is het nog steeds mogelijk dat Ethernet, RS-485, ProfiBus, of veel andere oudere bedrade technologieën in gebruik zijn. In het geval van de bedrade interfaces, kan toegang tot het netwerk zo simpel zijn als de kabel in het apparaat steken. Echter, draadloze protocollen zijn iets complexer.

Als de connectiviteit via een cellulaire verbinding is, wordt het provisioning waarschijnlijk afgehandeld door de cellulaire aanbieder in de vorm van een subscriber identification module (SIM) kaart of een van de nieuwere embedded eSIM-modules. Wanneer de carrier het International Mobile Equipment Identity (IMEI) identifier van het apparaat pakt en het associeert met een specifieke SIM/eSIM in hun interne databases, heeft de carrier een unieke manier om het apparaat te identificeren. Deze unieke identiteit wordt gebruikt om het apparaat te valideren als een legitiem lid van het netwerk van de carrier en om provisioning aan het apparaat over de lucht te leveren. Daardoor, door een lijst te hebben van de IMEI-nummers en hun geassocieerde SIM/eSIM, kunnen alle apparaten geactiveerd/provisioneerd worden zonder verdere menselijke interventie. Dezelfde soort benadering kan toegepast worden op andere cellulaire-achtige draadloze technologieën zoals LoRaWAN.

Technologieën zoals Bluetooth mesh, die toenemend in slimme gebouwen gevonden worden, hebben ook een ingebouwde provisioning-strategie gebaseerd op dezelfde concepten van een publiek/privé sleutelpaar en een digitaal certificaat ingesloten in het apparaat. Door een goed gedefinieerd provisioning-protocol en geassocieerde beveiligingshandshakes, kan een nieuw apparaat veilig aan het netwerk toegevoegd worden in een paar milliseconden zonder menselijke interactie. Hetzelfde soort provisioning-scenario kan gevonden worden over een aantal IoT-verbindingopties.

IoT Provisioning Conclusies

Je apparaten verbinden en provisioneren op je netwerk vereist een aanzienlijke gedachte aan beveiliging en het provisioning-proces. Gelukkig, met leveringsketens beveiligingsreferenties en nieuwe provisioning-protocollen en -technieken, kan het proces met een minimum van menselijke interactie en significant minder tijd dan in het verleden voltooid worden. Geautomatiseerde certificaatgeneratie en goed gedefinieerde beveiligingsprotocollen kunnen ervoor zorgen dat onze apparaten een geldige identiteit hebben en altijd veilige sleutelgeneratie en versleutelde communicatie tussen zichzelf en de servers/dienstverleners gebruiken.

De grote cloud-dienstverleners hebben quite a bit gedachte gestoken in hun provisioning-mechanismen, met goed gedefinieerde provisioning-stappen en -protocollen. Helaas gebruikt elke dienstverlener een andere set API's en benaderingen. Echter, de algemene provisioning-flow is hetzelfde tussen de leveranciers en kan gemakkelijk geautomatiseerd worden voor gevallen van massa-implementaties. Er zijn ook een veelheid van bedrijven die zich richten op IoT-provisioning-apparaten en automatiseringsbenaderingen, als er legacy of interne infrastructuren nodig zijn voor het bedrijf. Dus, hoewel iedereen op een gegeven moment of een ander de kwesties van provisioning moet overwegen, of ze nu consument of onderneming zijn, ten minste zul je in staat zijn om te profiteren van bestaande benaderingen en niet nieuwe paden hoeven te blazen.

Dit artikel is geschreven door Mike Anderson, Embedded Systems Architect, en Industry Consultant. Voor meer informatie, contacteer Mr. Anderson op dit e-mailadres wordt beschermd tegen spambots. Je hebt JavaScript nodig om het te kunnen zien. of bezoek https://info.hotims.com/82319-160 .