Zephyrnet-logo

De beveiliging van IoT-apparaten

Datum:

De beveiliging van IoT-apparaten
Illustratie: © IoT For All

De beveiliging van IoT-apparaten is een breed expertisedomein dat zich uitstrekt over de omgeving waarin apparaten worden uitgevoerd en de hardwareplatforms en besturingssystemen die de basis vormen waarop de daadwerkelijke apparaatfunctionaliteit is gebouwd. Elk gebied vereist verschillende technologieën en vaardigheden, maar alle gebieden moeten samen een veilige eenheid vormen. De harde waarheid is dat het verwaarlozen van één enkel gebied fatale gevolgen kan hebben, zelfs als alle andere gebieden perfect zijn.

Het is echter nog maar een begin om één beveiligd apparaat zijn werk te laten doen. Het veilig inzetten en bedienen van niet slechts één apparaat, maar het hele apparaatpark brengt een nieuwe uitdaging met zich mee in de vorm van provisioning, authenticatie en identiteitsbeheer.

In dit artikel

We zullen verschillende essentiële gebieden in het domein van IoT-beveiliging onderzoeken. IoT-apparaten zijn er in vele soorten en maten, maar de volgende beveiligingsgerelateerde aspecten zijn voor allemaal hetzelfde:

  • Fysieke beveiligingsperimeter van IoT-apparaten
  • Hardware
  • Besturingssysteem
  • Software
  • Identiteit en provisioning van IoT-apparaten
  • Authenticatie van IoT-apparaten

Fysieke beveiligingsperimeter van IoT-apparaten

IoT-apparaten bevinden zich doorgaans in onvoorspelbare, onstabiele en onveilige omgevingen die heel anders zijn dan bijvoorbeeld computersystemen die in datacenters draaien.

Als er niet voldoende fysieke beveiliging kan worden gegarandeerd, is het van essentieel belang dat IoT-apparaten voorbereid zijn op bedreigingen van potentieel kwaadwillende actoren met fysieke toegang. Er zijn verschillende maatregelen die hardware- en softwareontwerpers kunnen nemen om dergelijke risico's te verminderen. Deze maatregelen kunnen algemene technieken omvatten, zoals het versleutelen van gegevens op opslagapparaten, en enkele meer IoT-specifieke technieken die we in de rest van het artikel zullen onderzoeken.

Hardware

Hardware vormt de basis voor de beveiliging van IoT-apparaten. Wanneer hardware wordt aangetast, kunnen de meeste beveiligingsmaatregelen op softwareniveau die IoT-apparaten bieden, door aanvallers worden omzeild.

Historisch gezien was het vanuit veiligheidsoogpunt feitelijk game-over als een aanvaller fysieke toegang kreeg tot een computersysteem. Gelukkig zijn er op dit gebied veel vorderingen gemaakt dankzij een groeiend aantal IoT-apparaten en andere soorten mobiele apparaten. Voorbeelden van dergelijke beveiligingen op hardwareniveau kunnen zijn:

  • Vertrouwde uitvoeringsomgevingen (TEE) zoals Intel SGX maken het mogelijk om specifieke delen (enclaves) van het geheugen te versleutelen die alleen door de CPU on-the-fly kunnen worden gedecodeerd, waardoor effectief wordt voorkomen dat code die niet afkomstig is van de enclave, deze leest en wijzigt (inclusief het besturingssysteem en de hypervisors). er zijn er).
  • Fysiek niet-kloneerbare functies (PUF) kunnen worden gebruikt als unieke, onvervalsbare en onveranderlijke apparaat-ID's.
  • A Trusted Platform Module (TPM) is een speciale cryptoprocessor en veilige opslag voor kritieke gegevens zoals coderingssleutels. Het kan cryptografisch beveiligde willekeurige getallen genereren en cryptografische bewerkingen uitvoeren met behulp van de opgeslagen sleutels zonder deze buiten de TPM bloot te leggen of de hardwareconfiguratie te valideren.

Hoewel deze technieken al vele jaren worden onderzocht en geïmplementeerd, zijn de PUF's nog niet wijd verspreid en beginnen TEE's pas onlangs terrein te winnen. Aan de andere kant worden TPM's al lange tijd als een standaard beschouwd, zijn ze op de meeste computers te vinden en kunnen ze zonder enige twijfel de beveiliging van IoT-apparaten aanzienlijk verbeteren.

We mogen ook niet vergeten dat het opzettelijk compromitteren van een IoT-apparaat door een kwaadwillende actor niet de enige bedreiging is. Veel apparaten worden buiten geplaatst, waardoor het weerbestendig maken van de hardware een must is.

Besturingssysteem

Hoewel beperkte IoT-apparaten zonder besturingssysteem (OS) gebruikelijk zijn, zijn veel apparaten complexer en is er een besturingssysteem nodig.

Het feit dat het besturingssysteem elk computerproces/programma dat erop draait kan verstoren (tenzij een geavanceerd mechanisme zoals hierboven vermeld TEE wordt gebruikt), maakt het een net zo belangrijk onderdeel van de beveiliging van IoT-apparaten als hardware.

Ten eerste moet er een manier zijn om te garanderen dat tijdens het opstarten een kwaadwillig ongewijzigde versie van een besturingssysteem wordt geladen. Een dergelijke garantie kan worden bereikt door het besturingssysteem digitaal te ondertekenen en de handtekening tijdens het downloaden te controleren booting. Daar zijn standaarden voor, zoals Beveiligd Opstarten.

Last but not least bevatten alle besturingssystemen beveiligingsproblemen. Losstaand van zero-day Bij aanvallen kunnen dergelijke kwetsbaarheden effectief worden opgelost door tijdige levering en toepassing van softwarepatches.

Software applicaties

Het compromitteren van een enkele applicatie lijkt misschien een veel kleinere impact te hebben dan een compromittering van het hele besturingssysteem of de hele hardware. Het kan echter het enige zijn dat de aanvaller nodig heeft om te slagen. Bovendien verwerken veel applicaties, in tegenstelling tot besturingssystemen, rechtstreeks gevoelige bedrijfsgegevens en communiceren ze met gebruikers.

Soortgelijke maatregelen voor besturingssystemen kunnen ook worden toegepast op verschillende softwarepakketten en applicaties die bovenop het besturingssysteem draaien. Het verifiëren van de integriteit van uitvoerbare bestanden en hun tijdige beveiligingsupdates moet worden overwogen.

Bij het schrijven van aangepaste applicaties moeten ontwikkelaars er rekening mee houden dat de omgeving waarin hun code wordt uitgevoerd, niet vertrouwd is. Voorbeelden:

  • Bij het laden van gevoelige gegevens in RAM, maak het toegewezen geheugen zo snel mogelijk vrij en maak het leeg om het risico te verkleinen dat gevoelige gegevens via een geforceerde geheugendump worden vrijgegeven.
  • Denk twee keer na voordat u gevoelige gegevens naar een schijf schrijft. Zelfs als schijfversleuteling is geïnstalleerd, worden de gegevens geëxfiltreerd. Als het nodig is gevoelige gegevens naar schijf te schrijven, kunt u overwegen deze te versleutelen met een sleutel die is opgeslagen in een Trusted Platform Module (TPM) die in de vorige sectie is genoemd.

Identiteit en provisioning van IoT-apparaten

Om een ​​vloot IoT-apparaten zinvol te kunnen beheren, moet elk apparaat zijn eigen identiteit hebben en moet er een manier zijn om veilig een identiteit aan nieuwe apparaten toe te wijzen en indien nodig de identiteit van bestaande apparaten te wijzigen. We zouden dit proces ‘device provisioning’ kunnen noemen. Voor IoT-oplossingen is identiteit essentieel, zodat bijvoorbeeld gegevens van individuele apparaten veilig kunnen worden onderscheiden of gecompromitteerde apparaten kunnen worden losgekoppeld.

Wat is precies de ‘identiteit’ van een IoT-apparaat? Het hangt af van de context. Het apparaat heeft echter een manier nodig om te bewijzen dat zijn identiteit legitiem is (authenticeren). We kunnen onderscheid maken tussen fysieke en logische apparaatidentiteit.

Fysieke identiteit

Fysieke identiteit is een identiteit op hardwareniveau die onvervalsbaar, uniek, onveranderlijk en niet-overdraagbaar moet zijn gedurende de gehele levenscyclus van het apparaat en die doorgaans niet gerelateerd is aan het bedrijfsdomein. In een ideale wereld zou de fysieke identiteit precies één keer worden toegewezen nadat de productie van apparaten is voltooid. Dit kan bijvoorbeeld worden bereikt door serienummers van alle hardwarecomponenten te combineren. In werkelijkheid is deze aanpak echter veel gecompliceerder:

  • Hardwarecomponenten kunnen kapot zijn en worden vervangen door nieuwe. Om het nog ingewikkelder te maken, kan het onderdeel vervangen worden door een gerepareerd onderdeel van een ander apparaat.
  • Niet alle hardwarecomponenten hebben een serienummer, of het serienummer kan niet gemakkelijk worden gelezen.
  • Serienummers zijn doorgaans geen cryptografisch veilige identificatiegegevens.

Dat is de reden dat de fysieke identiteit meestal 'bij benadering' wordt gemaakt door identificatiegegevens te genereren tijdens de productie of door een serienummer te gebruiken van een onderdeel dat als primair wordt beschouwd.

Logische identiteit

Logische identiteit daarentegen is doorgaans nauw gekoppeld aan het zakelijke domein of andere niet-technische aspecten, zoals de locatie van het apparaat. Net als bij de fysieke identiteit moet de logische identiteit onvervalsbaar en uniek zijn, maar kan deze ook veranderlijk en overdraagbaar zijn.

Om het verschil tussen fysieke en logische identiteit aan te tonen, kunt u het volgende voorbeeld gebruiken: Een robotarm op de assemblagelijn van een auto vervult een specifieke functie. Het is een stationair IoT-apparaat.

De fysieke identiteit van deze robot wordt rechtstreeks in de fabriek toegewezen door een cryptografisch beveiligde code te genereren UUID (e.g., c2c38155-b0d2-48b6-82fd-22fe3b316224).

Dit apparaat verzendt gegevens naar een cloudgebaseerde IoT-oplossingsbackend en ontvangt feedback van dezelfde backend. Er zijn twee soorten gegevens die deze robot verzendt:

  • Diagnostische gegevens over de uitgevoerde functionaliteit (bijvoorbeeld hoeveel auto-onderdelen op de assemblagelijn er per uur door deze robot zijn verwerkt).
  • Interne telemetriegegevens (bijvoorbeeld de hoeveelheid koppel die door elk gewricht wordt uitgeoefend).

Als de robot defect raakt en vervangen moet worden, verandert zijn fysieke identiteit.

Laten we aannemen dat de robot geen logische identiteit heeft. In dat geval is het niet eenvoudig om bestaande data in de cloud te correleren met de identiteit van de nieuwe robot. Het is misschien geen probleem voor de interne telemetriegegevens, omdat deze alleen relevant zijn voor de originele robot. De diagnostische gegevens over de uitgevoerde functionaliteit kunnen echter relevant zijn voor de nieuwe robot. Ook moeten andere systemen die met de oorspronkelijke robot communiceerden voordat ze defect raakten, er nu van op de hoogte worden gesteld dat de robot is vervangen.

Laten we dit vergelijken met een situatie waarin de oorspronkelijke robot ook een logische identiteit had die verband hield met de organisatie van de assemblagelijn van de auto (bijvoorbeeld lijn-03-links-lassen-12). Als deze logische identiteit wordt gebruikt voor het opslaan van de diagnosegegevens en voor de communicatie met andere systemen, kan het vervangen van de robot veel eenvoudiger zijn.

Authenticatie van IoT-apparaten

Ongeacht welke identificatiemiddelen IoT-apparaten gebruiken en hoe deze worden gegenereerd, de apparaten moeten bewijzen dat de identificatiegegevens die zij gebruiken legitiem zijn. Het proces om ervoor te zorgen dat een identificatie legitiem is en door een correct apparaat wordt gebruikt, wordt authenticatie genoemd.

Authenticatie van IoT-apparaten is altijd gebaseerd op symmetrisch or asymmetrische (openbare) sleutel cryptografie-algoritmen en hash-algoritmen. Deze algoritmen hebben altijd een geheime sleutel nodig die ergens in het apparaat is opgeslagen.

Hoe authenticatie precies werkt, hangt af van het specifieke algoritme. Er zijn echter altijd de volgende twee aannames:

  • De identiteit van het apparaat is gebonden aan de geheime sleutel.
  • De geheime sleutel is echt geheim.
  • Voor asymmetrische algoritmen is dit alleen bekend bij het apparaat.
  • Voor symmetrische algoritmen is dit alleen bekend bij het apparaat en de authenticerende partij (bijvoorbeeld ondersteund door een IoT-oplossing).

Omgaan met geheime sleutels

Waar en hoe precies geheime sleutels worden opgeslagen, hangt af van de mogelijkheden van het apparaat en het specifieke authenticatiealgoritme. De state-of-the-art aanpak is om sleutels in Trusted Platform Modules (TPM’s) te bewaren. De TPM's kunnen cryptografische bewerkingen rechtstreeks uitvoeren zonder de geheime sleutels bloot te leggen, waardoor bescherming wordt geboden tegen sleutelexfiltratie.

Een goede praktijk is om sleutels met een korte levensduur/sessie af te leiden uit de primaire sleutel om de blootstelling van de primaire sleutel te minimaliseren en voorwaartse geheimhouding.

Voorbeelden

De meest gebruikte algoritmen, standaarden en protocollen zijn:

  • RSA, Elliptic Curves, SHA2: Fundamentele asymmetrische (openbare) sleutelcodering en hashing-algoritmen.
  • X.509-certificaten: standaard die definieert hoe asymmetrische sleutels aan identiteit moeten worden gekoppeld via objecten die certificaten worden genoemd.
  • mTLS: Protocol voor het beveiligen van TCP-verbindingen. In tegenstelling tot gewone TLS worden beide zijden van de verbinding geverifieerd. Het is gebouwd bovenop de fundamentele encryptie- en hash-algoritmen en X.509-certificaten die hierboven zijn genoemd.
  • HMAC: Op symmetrische sleutels gebaseerd algoritme dat een ondertekende apparaat-ID kan genereren, die apparaten kunnen gebruiken om hun identiteit te bewijzen.

Key Takeaways

De aard van IoT-beveiliging is veelzijdig. Hoewel er veel soorten IoT-apparaten bestaan, zijn er enkele gemeenschappelijke beveiligingsaspecten waarmee elke ontwerper van IoT-oplossingen rekening moet houden:

  • De omgeving waarin het apparaat wordt uitgevoerd (fysieke beveiligingsperimeter).
  • De fundamenten waarop het apparaat is gebouwd (hardware, besturingssysteem).
  • De daadwerkelijke code die het apparaat nuttig maakt (software).
  • Processen die nodig zijn om de software op een veilige, beheersbare en schaalbare manier te laten werken (identiteit, provisioning en authenticatie).

Aan de andere kant is het geen goed idee om blindelings alle suggesties in dit artikel te volgen en te implementeren. Sommige maatregelen zijn belangrijker dan andere voor verschillende IoT-oplossingen, en sommige zijn in bepaalde contexten misschien niet eens relevant of haalbaar. Het versoepelen van veiligheidsmaatregelen moet echter altijd bewust en na goede overweging gebeuren.

spot_img

VC Café

LifeSciVC

Laatste intelligentie

VC Café

LifeSciVC

spot_img