Voorziening van slimme sensoren voor het IoT

Het internet der dingen (IoT) is op dit moment voor de meesten van ons geen onbekende. IoT-apparaten kunnen worden gezien als behorend tot de consumenten-, medische of industriële markt. Of het apparaat nu een videodeurbel, een insulinepomp of een industriële sensor is, de gebruiker zal voor twee belangrijke uitdagingen staan:1) het apparaat fysiek/logisch verbinden met het netwerk en 2) ervoor zorgen dat het apparaat de juiste inloggegevens heeft om het in staat stellen om samen te werken met andere apparaten op hetzelfde netwerk of met de server(s) die naar verwachting de gegevens van het apparaat zullen verzamelen. Deze uitdagingen kunnen grotendeels worden gegroepeerd in een proces dat bekend staat als provisioning.

Basisvoorzieningen

De grootste uitdaging in het inrichtingsproces is de mogelijkheid om ervoor te zorgen dat een apparaat en de verbinding met het netwerk/server veilig zijn. Dit is sterk afhankelijk van zowel asymmetrische als symmetrische versleutelingstechnieken en het bestaan ​​van digitale certificaten.

In het geval van asymmetrische encryptie is er een wiskundig gerelateerd publiek/privaat sleutelpaar. Als iets is versleuteld met de openbare sleutel, kan alleen de privésleutel het ontsleutelen. Dit in tegenstelling tot symmetrische codering, waarbij dezelfde sleutel wordt gebruikt om het bericht zowel te coderen als te decoderen. Symmetrische codering vereist minder bronnen (bijvoorbeeld minder bits in de sleutel, wat resulteert in snellere codering) om een ​​betere beveiliging te bereiken dan bij asymmetrische codering. Voor symmetrische versleuteling moeten de sleutels echter worden uitgewisseld op een manier die niet kan worden gezien door een indringer. Wat meestal wordt gedaan, is de openbare sleutel van de bestemming gebruiken om een ​​premastersleutel te coderen, deze naar de bestemming te sturen en vervolgens gebruikt de bestemming hun privésleutel om de premastersleutel te decoderen en de gedeelde sessiesleutel te genereren. Dit is de manier waarop Diffie-Hellman-sleuteluitwisseling het gebruik van snellere en sterkere symmetrische codering mogelijk maakt met behulp van een handdruk die gebruikmaakt van asymmetrische codering.

De eerste vereiste voor inrichting is dat het IoT-apparaat een uniek identiteitsmechanisme heeft. Dit kan een onderdeel zijn van het fabricageproces van het apparaat, waarbij een identiteitschip deel uitmaakt van de stuklijst, of wat veel microprocessorfabrikanten tegenwoordig doen - het branden van een unieke identiteit met openbare en privésleutels in de processor bij de fabricage. Dit wordt bevoorrading genoemd tijdens de toeleveringsketen.

We kunnen zien dat de basisstappen die worden gebruikt voor het inrichten van IoT-apparaten binnen de onderneming of bij serviceproviders zoals Amazon Web Services, Google Cloud of Microsoft Azure, allemaal een soortgelijk proces volgen:

1. Apparaatinschrijving

   • Maak een record op de server met metagegevens voor het IoT-apparaat. Dat kan een serienummer of een andere unieke apparaat-ID, locatie van het apparaat en andere gegevens zijn die de onderneming die het IoT-apparaat gebruikt, helpen de rol ervan te begrijpen.

2. Sleutelgeneratie

   • Als het IoT-apparaat een unieke identiteitschip heeft, zoals een Trusted Platform Module (TPM) of anderszins een set openbare en privésleutels heeft geïnstalleerd op het moment van fabricage, dan is deze sleutelgeneratie al voltooid. Als er echter nog geen set sleutels bestaat, kan het installatieprogramma een set genereren met tools zoals OpenSSL. Of als een van de cloudproviders wordt gebruikt, heeft de serviceprovider doorgaans een mechanisme voor het genereren van sleutels. De openbare en privésleutels moeten op het apparaat worden opgeslagen, waarbij de privésleutel in een soort beveiligde opslag wordt geplaatst om te voorkomen dat deze in het veld uit het apparaat wordt gelezen. Om veiligheidsredenen wordt aangeraden dat de sleutels ten minste 2048 bits lang of langer zijn als op RSA gebaseerde algoritmen worden gebruikt, of 256 bits of langer voor op elliptische curve gebaseerde algoritmen.

3. Een certificaat genereren

   • Op het moment van activering genereert het apparaat een certificaatondertekeningsverzoek (CSR) en stuurt dat CSR naar een certificeringsinstantie (CA) voor ondertekening. De CA is doorgaans een vertrouwde derde partij, zoals Digicert, GlobalSign of zelfs de cloudserviceprovider. Het apparaat verzendt zijn openbare sleutel en enkele metagegevens in de CSR en de CA genereert een SSL-certificaat (Secure Socket Layer) (meestal een X.509-certificaat). Het ondertekent dat certificaat met de privésleutel van de CA voordat het wordt teruggestuurd naar het apparaat. Zodra het apparaat een certificaat heeft, kan het deelnemen aan een TLS-handshake (Transport Layer Security) die een versleutelde verbinding met de server tot stand kan brengen. Omdat het certificaat is ondertekend door de privésleutel van een vertrouwde derde partij, kunnen we stellen dat het apparaat dat de privésleutel beheert die is gekoppeld aan de openbare sleutel in het certificaat, bekend en vertrouwd is.

   • Het is ook mogelijk om een ​​“self-signed” certificaat te genereren. Als het apparaat bijvoorbeeld intern is vervaardigd en alleen door de fabrikant wordt gebruikt, is er geen externe CA nodig om het te certificeren. Met behulp van tools zoals OpenSSL kan de fabrikant het openbare/private sleutelpaar en het certificaat genereren en deze kopiëren naar de beveiligde opslag op het apparaat wanneer het apparaat van de productielijn komt.

4. Het apparaat voorzien

   • Met de sleutels en het certificaat kan het apparaat nu zijn identiteit bevestigen aan de serviceprovider door een beveiligde koppeling te initiëren via TLS of de datagramversie van TLS die bekend staat als DTLS. De TLS/DTLS-handshake brengt een symmetrische coderingssleutel tot stand die kan worden gebruikt voor daaropvolgende veilige gegevensoverdracht tussen het apparaat en de serviceprovider, zodat het apparaat kan worden ingeschreven en de gegevens die in het record zijn opgeslagen, worden gegenereerd met de serviceprovider in stap 1.

De handshake wordt gebruikt om een ​​veilige sleuteluitwisseling te implementeren om een ​​symmetrische encryptielink tot stand te brengen. Zodra de koppeling tot stand is gebracht, kunnen gegevens van het apparaat naar de server worden overgedragen zonder angst voor compromissen door cyberaanvallen. Man-in-the-middle (MITM)-aanvallen, waarbij een tussenpersoon de communicatie in transit onderschept, worden bijvoorbeeld voorkomen omdat de indringer de symmetrische sleutel mist die wordt gebruikt in de bulkversleuteling. Nieuwere versies van de TLS-handshake (TLS 1.3) verkorten deze berichtenuitwisseling aanzienlijk om overdrachten met lagere latentie van apparaten naar de gegevensverzamelingssystemen te ondersteunen.

In bulk voorzien

Tot nu toe was de bevoorradingsdiscussie gericht op het hebben van een mens in de lus voor enkele of kleine aantallen apparaten. De beveiliging was ook grotendeels gericht op het gebruik van encryptie en de mens die de authenticiteit van het apparaat kan bevestigen door het uit de originele verpakking te halen. Bij het werken op industriële schaal is deze vereiste van een fysiek betrokken mens echter onpraktisch.

Veel van de nieuwere slimme gebouwen bevatten bijvoorbeeld duizenden sensoren, waaronder omgevingslichtsensoren, luchtkwaliteitssensoren, microfoons om de kamerbezetting te bepalen en temperatuur- en vochtigheidssensoren, om er maar een paar te noemen. Als een mens elk van deze apparaten handmatig zou moeten inrichten, zou het snel een fulltime baan worden. De identiteit van deze apparaten en hun beveiligingsreferenties moeten echter worden gegarandeerd. Dus, hoe kunnen apparaten in bulk worden geleverd zonder menselijke tussenkomst?

Ten eerste moeten we begrijpen dat industriële IoT-apparaten nog steeds de twee basisvereisten hebben die in het begin werden besproken. De operator moet de apparaten koppelen aan een netwerk en de identiteit van de apparaten en hun beveiliging verifiëren voordat ze toegang krijgen tot de server of serviceprovider die de sensoruitgangen verzamelt en analyseert. De fysieke verbinding met het netwerk is afhankelijk van de communicatiemedia en om een ​​identiteit te kunnen bevestigen, zijn digitale certificaten vereist. Om bulkprovisioning te ondersteunen, is het het beste om het openbare/private sleutelpaar en het certificaat van het apparaat in de toeleveringsketen op te nemen, zodat het apparaat uit de doos klaar is om het certificaatondertekeningsverzoek te genereren en de inrichtingshandshake af te handelen.

Natuurlijk zullen veel IoT-apparaten een of ander draadloos protocol gebruiken, vooral als het gaat om greenfield-toepassingen. Er is een veelvoud aan keuzes, waaronder mobiel, Wi-Fi, Zigbee, LoRaWAN, SigFox en meer. Als we echter een verouderde toepassing upgraden, is het nog steeds mogelijk dat Ethernet, RS-485, ProfiBus of vele andere oudere bedrade technologieën in gebruik zijn. In het geval van de bedrade interfaces kan toegang krijgen tot het netwerk net zo eenvoudig zijn als de kabel in het apparaat steken. Draadloze protocollen zijn echter iets gecompliceerder.

Als de connectiviteit via een mobiele verbinding is, wordt de voorziening waarschijnlijk afgehandeld door de mobiele provider in de vorm van een abonnee-identificatiemodule (simkaart) of een van de nieuwere ingebouwde eSIM-modules. Wanneer de vervoerder de IMEI-identificatiecode (International Mobile Equipment Identity) van het apparaat gebruikt en deze in hun interne databases aan een specifieke SIM/eSIM koppelt, heeft de vervoerder 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 koerier en om het apparaat via de ether te leveren. Door een lijst van de IMEI-nummers en de bijbehorende SIM/eSIM te hebben, kunnen daarom alle apparaten worden geactiveerd/voorzien zonder verdere menselijke tussenkomst. Deze zelfde soort benadering kan worden toegepast op andere cellulaire-achtige draadloze technologieën zoals LoRaWAN.

Technologieën zoals Bluetooth-mesh, dat steeds vaker wordt aangetroffen in slimme gebouwen, hebben ook een ingebouwde voorzieningsstrategie die is gebaseerd op dezelfde concepten van een openbaar/privé-sleutelpaar en een digitaal certificaat dat in het apparaat is ingebed. Via een goed gedefinieerd provisioningprotocol en bijbehorende beveiligingshandshakes kan een nieuw apparaat binnen enkele milliseconden veilig aan het netwerk worden toegevoegd zonder menselijke tussenkomst. Ditzelfde soort inrichtingsscenario is te vinden bij een aantal IoT-verbindingsopties.

IoT-voorziening laatste gedachten

Om uw apparaten op uw netwerk aan te sluiten en te leveren, moet u goed nadenken over de beveiliging en het inrichtingsproces. Gelukkig kan het proces met een minimum aan menselijke interactie en aanzienlijk minder tijd dan in het verleden nodig was, dankzij de beveiligingsreferenties voor de toeleveringsketen en nieuwe provisioningprotocollen en -technieken. Geautomatiseerde certificaatgeneratie en goed gedefinieerde beveiligingsprotocollen kunnen ervoor zorgen dat onze apparaten een geldige identiteit hebben en altijd gebruik zullen maken van veilige sleutelgeneratie en versleutelde communicatie tussen henzelf en de servers/serviceproviders.

De grote cloudserviceproviders hebben behoorlijk wat nagedacht over hun inrichtingsmechanismen, met goed gedefinieerde inrichtingsstappen en protocollen. Helaas gebruikt elke serviceprovider een andere set API's en benaderingen. De algemene leveringsstroom is echter hetzelfde tussen de leveranciers en kan eenvoudig worden geautomatiseerd voor massa-implementaties. Er zijn ook een groot aantal bedrijven die zich richten op IoT-provisioningapparaten en automatiseringsbenaderingen, als er legacy of interne infrastructuren nodig zijn voor de onderneming. Dus hoewel iedereen op een of ander moment moet nadenken over voorzieningen, of het nu consumenten of ondernemingen zijn, kun je in ieder geval profiteren van bestaande benaderingen en hoef je geen nieuwe wegen in te slaan.

Dit artikel is geschreven door Mike Anderson, Embedded Systems Architect en Industry Consultant. Neem voor meer informatie contact op met de heer Anderson via Dit e-mailadres wordt beveiligd tegen spambots. U heeft Javascript nodig om het te kunnen zien. of bezoek http://info.hotims.com/82319-160 .