Delen via

Beveiligingsprocedures voor Fabrikanten van Azure IoT-apparaten

  • Artikel

Naarmate meer fabrikanten IoT-apparaten vrijgeven, is het handig om richtlijnen te identificeren met betrekking tot algemene procedures. In dit artikel vindt u een overzicht van aanbevolen beveiligingsprocedures waarmee u rekening moet houden wanneer u apparaten maakt voor gebruik met Azure IoT Device Provisioning Service (DPS).

  • Opties voor apparaatverificatie selecteren
  • Certificaten installeren op IoT-apparaten
  • Een TPM (Trusted Platform Module) integreren in het productieproces

Opties voor apparaatverificatie selecteren

Het ultieme doel van een ioT-apparaatbeveiligingsmaatregel is het maken van een veilige IoT-oplossing. Maar problemen zoals hardwarebeperkingen, kosten en beveiligingsexpertise hebben allemaal invloed op welke opties u kiest. Verder heeft uw benadering van beveiliging invloed op de manier waarop uw IoT-apparaten verbinding maken met de cloud. Hoewel er verschillende elementen van IoT-beveiliging zijn om rekening mee te houden, is een belangrijk element dat elke klant tegenkomt welk verificatietype moet worden gebruikt.

Drie veelgebruikte verificatietypen zijn X.509-certificaten, TRUSTED Platform Modules (TPM) en symmetrische sleutels. Hoewel er andere verificatietypen bestaan, gebruiken de meeste klanten die oplossingen bouwen in Azure IoT een van deze drie typen. De rest van dit artikel onderzoekt voor- en nadelen van het gebruik van elk verificatietype.

X.509-certificaat

X.509-certificaten zijn een type digitale identiteit dat u voor verificatie kunt gebruiken. De X.509-certificaatstandaard wordt beschreven in IETF RFC 5280. In Azure IoT zijn er twee manieren om certificaten te verifiëren:

  • Vingerafdruk. Een vingerafdrukalgoritme wordt uitgevoerd op een certificaat om een hexadecimale tekenreeks te genereren. De gegenereerde tekenreeks is een unieke id voor het certificaat.
  • CA-verificatie op basis van een volledige keten. Een certificaatketen is een hiërarchische lijst met alle certificaten die nodig zijn om een EE-certificaat (end-entity) te verifiëren. Als u een EE-certificaat wilt verifiëren, moet u elk certificaat in de keten verifiëren, inclusief een vertrouwde basis-CA.

Voordelen voor X.509:

  • X.509 is het veiligste verificatietype dat wordt ondersteund in Azure IoT.
  • X.509 staat een hoog niveau van controle toe voor certificaatbeheer.
  • Veel leveranciers zijn beschikbaar om verificatieoplossingen op basis van X.509 te bieden.

Nadelen voor X.509:

  • Veel klanten moeten mogelijk afhankelijk zijn van externe leveranciers voor hun certificaten.
  • Certificaatbeheer kan kostbaar zijn en kan worden toegevoegd aan de totale kosten van de oplossing.
  • Levenscyclusbeheer van certificaten kan lastig zijn als logistiek niet goed is doordacht.

Trusted Platform Module (TPM)

TPM, ook wel ISO /IEC 11889 genoemd, is een standaard voor het veilig genereren en opslaan van cryptografische sleutels. TPM verwijst ook naar een virtueel of fysiek I/O-apparaat dat communiceert met modules die de standaard implementeren. Een TPM-apparaat kan bestaan als discrete hardware, geïntegreerde hardware, een module op basis van firmware of een softwaremodule.

Er zijn twee belangrijke verschillen tussen TPM's en symmetrische sleutels:

  • TPM-chips kunnen ook X.509-certificaten opslaan.
  • TPM-attestation in DPS maakt gebruik van de TPM-goedkeuringssleutel (EK), een vorm van asymmetrische verificatie. Bij asymmetrische verificatie wordt een openbare sleutel gebruikt voor versleuteling en wordt een afzonderlijke persoonlijke sleutel gebruikt voor ontsleuteling. Symmetrische sleutels gebruiken daarentegen symmetrische verificatie, waarbij de persoonlijke sleutel wordt gebruikt voor zowel versleuteling als ontsleuteling.

Voordelen voor TPM:

  • TPM's zijn opgenomen als standaardhardware op veel Windows-apparaten, met ingebouwde ondersteuning voor het besturingssysteem.
  • TPM-attestation is eenvoudiger te beveiligen dan sas-token (Shared Access Signature) op basis van symmetrische sleutelattestation.
  • U kunt eenvoudig verlopen en vernieuwen, of apparaatreferenties rollen. DPS rolt automatisch de IoT Hub-referenties wanneer een TPM-apparaat moet worden herprovisioning.

Nadelen voor TPM:

  • TPM's zijn complex en kunnen moeilijk te gebruiken zijn.
  • Het ontwikkelen van toepassingen met TPM's is moeilijk, tenzij u een fysieke TPM of een kwaliteitsemulator hebt.
  • Mogelijk moet u het bord van uw apparaat opnieuw ontwerpen om een TPM op te nemen in de hardware.
  • Als u de EK op een TPM rolt, wordt de identiteit van de TPM vernietigd en wordt er een nieuwe gemaakt. Hoewel de fysieke chip hetzelfde blijft, heeft deze een nieuwe identiteit in uw IoT-oplossing.

Symmetrische sleutel

Met symmetrische sleutels wordt dezelfde sleutel gebruikt voor het versleutelen en ontsleutelen van berichten. Als gevolg hiervan is dezelfde sleutel bekend bij zowel het apparaat als de service waarmee het wordt geverifieerd. Azure IoT biedt ondersteuning voor symmetrische sleutelverbindingen op basis van SAS-tokens. Verificatie met symmetrische sleutels vereist aanzienlijke verantwoordelijkheid van de eigenaar om de sleutels te beveiligen en een gelijk beveiligingsniveau met X.509-verificatie te bereiken. Als u symmetrische sleutels gebruikt, is het raadzaam om de sleutels te beveiligen met behulp van een HSM (Hardware Security Module).

Voordelen voor symmetrische sleutel:

  • Het gebruik van symmetrische sleutels is de eenvoudigste, laagste kostenmethode om aan de slag te gaan met verificatie.
  • Het gebruik van symmetrische sleutels stroomlijnt uw proces omdat er niets extra's zijn om te genereren.

Nadelen voor symmetrische sleutel:

  • Symmetrische sleutels nemen een aanzienlijke inspanning om de sleutels te beveiligen. Dezelfde sleutel wordt gedeeld tussen het apparaat en de cloud, wat betekent dat de sleutel op twee plaatsen moet worden beveiligd. De uitdaging met TPM- en X.509-certificaten bewijst daarentegen het bezit van de openbare sleutel zonder de persoonlijke sleutel te onthullen.
  • Met symmetrische sleutels kunt u eenvoudig slechte beveiligingsprocedures volgen. Een veelvoorkomende tendens met symmetrische sleutels is het codeeren van de niet-versleutelde sleutels op apparaten. Hoewel deze praktijk handig is, blijven de sleutels kwetsbaar. U kunt een aantal risico's beperken door de symmetrische sleutel veilig op te slaan op het apparaat. Als uw prioriteit echter uiteindelijk beveiliging is in plaats van gemak, gebruikt u X.509-certificaten of TPM voor verificatie.

Gedeelde symmetrische sleutel

Er is een variatie van symmetrische sleutelverificatie, ook wel gedeelde symmetrische sleutel genoemd. Deze benadering omvat het gebruik van dezelfde symmetrische sleutel op alle apparaten. Het wordt aanbevolen om te voorkomen dat gedeelde symmetrische sleutels op uw apparaten worden gebruikt.

Pro voor gedeelde symmetrische sleutel:

  • Eenvoudig te implementeren en goedkoop te produceren op schaal.

Nadelen voor gedeelde symmetrische sleutel:

  • Zeer kwetsbaar voor aanvallen. Het voordeel van eenvoudige implementatie is veel opwegen tegen het risico.
  • Iedereen kan uw apparaten imiteren als ze de gedeelde sleutel verkrijgen.
  • Als u afhankelijk bent van een gedeelde symmetrische sleutel die wordt aangetast, verliest u waarschijnlijk de controle over de apparaten.

De juiste keuze maken voor uw apparaten

Als u een verificatiemethode wilt kiezen, moet u rekening houden met de voordelen en kosten van elke benadering voor uw unieke productieproces. Voor apparaatverificatie is er meestal een omgekeerde relatie tussen hoe veilig een bepaalde benadering is en hoe handig het is.

Certificaten installeren op IoT-apparaten

Als u X.509-certificaten gebruikt om uw IoT-apparaten te verifiëren, biedt deze sectie richtlijnen voor het integreren van certificaten in uw productieproces. U moet verschillende beslissingen nemen. Dit zijn beslissingen over algemene certificaatvariabelen, wanneer certificaten moeten worden gegenereerd en wanneer ze moeten worden geïnstalleerd.

Als u gewend bent aan het gebruik van wachtwoorden, kunt u vragen waarom u niet hetzelfde certificaat op al uw apparaten kunt gebruiken, op dezelfde manier als u hetzelfde wachtwoord op al uw apparaten zou kunnen gebruiken. Ten eerste is het gebruik van hetzelfde wachtwoord overal gevaarlijk. De praktijk heeft bedrijven blootgesteld aan belangrijke DDoS-aanvallen, waaronder de aanval die DNS enkele jaren geleden op de US East Coast heeft neergenomen. Gebruik nooit overal hetzelfde wachtwoord, zelfs met persoonlijke accounts. Ten tweede is een certificaat geen wachtwoord, het is een unieke identiteit. Een wachtwoord is vergelijkbaar met een geheime code die iedereen kan gebruiken om een deur in een beveiligd gebouw te openen. Het is iets wat u weet en u kunt het wachtwoord aan iedereen geven om toegang te krijgen. Een certificaat is net als een rijbewijs met uw foto en andere details, die u aan een bewaker kunt laten zien om in een beveiligd gebouw te komen. Het is gebonden aan wie je bent. Mits de bewaker nauwkeurig overeenkomt met personen met rijbewijs, kunt u alleen uw licentie (identiteit) gebruiken om toegang te krijgen.

Variabelen die betrokken zijn bij certificaatbeslissingen

Houd rekening met de volgende variabelen en hoe elke variabele van invloed is op het algehele productieproces.

Waar de vertrouwensbasis van het certificaat vandaan komt

Het kan kostbaar en complex zijn om een PKI (Public Key Infrastructure) te beheren. Vooral als uw bedrijf geen ervaring heeft met het beheren van een PKI. U hebt de volgende opties:

  • Gebruik een PKI van derden. U kunt tussenliggende ondertekeningscertificaten kopen bij een externe certificaatleverancier. U kunt ook een persoonlijke certificeringsinstantie (CA) gebruiken.
  • Gebruik een zelfbeheerde PKI. U kunt uw eigen PKI-systeem onderhouden en uw eigen certificaten genereren.
  • Gebruik de Azure Sphere-beveiligingsservice . Deze optie is alleen van toepassing op Azure Sphere-apparaten.

Waar certificaten worden opgeslagen

Er zijn enkele factoren die van invloed zijn op de beslissing over waar certificaten worden opgeslagen. Deze factoren omvatten het type apparaat, verwachte winstmarges (of u zich veilige opslag kunt veroorloven), apparaatmogelijkheden en bestaande beveiligingstechnologie op het apparaat dat u mogelijk kunt gebruiken. Overweeg de volgende opties:

  • In een HSM (Hardware Security Module). Het gebruik van een HSM wordt ten zeerste aanbevolen. Controleer of op het besturingsbord van uw apparaat al een HSM is geïnstalleerd. Als u weet dat u geen HSM hebt, neem dan contact op met de hardwarefabrikant om een HSM te identificeren die aan uw behoeften voldoet.
  • Op een veilige plaats op schijf, zoals een vertrouwde uitvoeringsomgeving (TEE).
  • In het lokale bestandssysteem of een certificaatarchief. Bijvoorbeeld het Windows-certificaatarchief.

Verbinding maken iviteit bij de fabriek

Verbinding maken iviteit in de fabriek bepaalt hoe en wanneer u de certificaten krijgt die op de apparaten moeten worden geïnstalleerd. Verbinding maken iviteitsopties zijn als volgt:

  • Connectiviteit. Connectiviteit is optimaal, het stroomlijnt het proces van het lokaal genereren van certificaten.
  • Geen verbinding. In dit geval gebruikt u een ondertekend certificaat van een CA om apparaatcertificaten lokaal en offline te genereren.
  • Geen verbinding. In dit geval kunt u certificaten verkrijgen die van tevoren zijn gegenereerd. U kunt ook een offline PKI gebruiken om certificaten lokaal te genereren.

Controlevereiste

Afhankelijk van het type apparaten dat u produceert, hebt u mogelijk een wettelijke vereiste om een audittrail te maken van de manier waarop apparaat-id's op uw apparaten worden geïnstalleerd. Controle voegt aanzienlijke productiekosten toe. In de meeste gevallen doet u dit dus alleen indien nodig. Als u niet zeker weet of een controle vereist is, neemt u contact op met de juridische afdeling van uw bedrijf. Controleopties zijn:

  • Geen gevoelige branche. Er is geen controle vereist.
  • Gevoelige industrie. Certificaten moeten worden geïnstalleerd in een beveiligde ruimte volgens de nalevingscertificeringsvereisten. Als u een beveiligde ruimte nodig hebt om certificaten te installeren, weet u waarschijnlijk al hoe certificaten op uw apparaten worden geïnstalleerd. En u hebt waarschijnlijk al een controlesysteem.

Geldigheidsduur van certificaat

Net als bij een rijbewijs hebben certificaten een vervaldatum die is ingesteld wanneer ze worden gemaakt. Hier volgen de opties voor de geldigheidsduur van het certificaat:

  • Verlenging is niet vereist. Deze methode maakt gebruik van een lange verlengingsperiode, dus u hoeft het certificaat nooit te verlengen tijdens de levensduur van het apparaat. Hoewel een dergelijke benadering handig is, is het ook riskant. U kunt het risico verminderen door beveiligde opslag te gebruiken, zoals een HSM op uw apparaten. De aanbevolen procedure is echter om te voorkomen dat langlevende certificaten worden gebruikt.
  • Verlenging is vereist. U moet het certificaat vernieuwen tijdens de levensduur van het apparaat. De geldigheidsduur van het certificaat is afhankelijk van de context en u hebt een strategie nodig voor verlenging. De strategie moet bevatten waar u certificaten krijgt en welk type over-the-air-functionaliteit uw apparaten moeten gebruiken in het verlengingsproces.

Wanneer certificaten worden gegenereerd

De mogelijkheden voor internetverbinding in uw fabriek zijn van invloed op uw proces voor het genereren van certificaten. U hebt verschillende opties voor het genereren van certificaten:

  • Vooraf geladen certificaten. Sommige HSM-leveranciers bieden een premium-service waarin de HSM-leverancier certificaten voor de klant installeert. Klanten geven eerst de HSM-leverancier toegang tot een handtekeningcertificaat. Vervolgens installeert de HSM-leverancier certificaten die zijn ondertekend door dat handtekeningcertificaat op elke HSM die de klant koopt. De klant hoeft alleen de HSM op het apparaat te installeren. Hoewel deze service kosten toevoegt, helpt het om uw productieproces te stroomlijnen. En het lost de vraag op wanneer certificaten moeten worden geïnstalleerd.
  • Door het apparaat gegenereerde certificaten. Als uw apparaten intern certificaten genereren, moet u het openbare X.509-certificaat van het apparaat extraheren om het in te schrijven bij DPS.
  • Verbinding maken fabriek. Als uw factory connectiviteit heeft, kunt u apparaatcertificaten genereren wanneer u ze nodig hebt.
  • Offline factory met uw eigen PKI. Als uw fabriek geen verbinding heeft en u uw eigen PKI gebruikt met offlineondersteuning, kunt u de certificaten genereren wanneer u ze nodig hebt.
  • Offline factory met externe PKI. Als uw factory geen verbinding heeft en u een PKI van derden gebruikt, moet u de certificaten van tevoren genereren. En het is nodig om de certificaten te genereren vanaf een locatie met connectiviteit.

Wanneer moet u certificaten installeren

Nadat u certificaten voor uw IoT-apparaten hebt gegenereerd, kunt u deze installeren op de apparaten.

Als u vooraf geladen certificaten met een HSM gebruikt, wordt het proces vereenvoudigd. Nadat de HSM op het apparaat is geïnstalleerd, heeft de apparaatcode toegang tot de HSM. Vervolgens roept u de HSM-API's aan voor toegang tot het certificaat dat is opgeslagen in de HSM. Deze benadering is het handigst voor uw productieproces.

Als u geen vooraf geladen certificaat gebruikt, moet u het certificaat installeren als onderdeel van uw productieproces. De eenvoudigste methode is het installeren van het certificaat in de HSM op hetzelfde moment dat u de eerste installatiekopieën van de firmware flasht. Uw proces moet een stap toevoegen om de installatiekopieën op elk apparaat te installeren. Na deze stap kunt u definitieve kwaliteitscontroles en eventuele andere stappen uitvoeren voordat u het apparaat inpakt en verzendt.

Er zijn softwarehulpprogramma's beschikbaar waarmee u het installatieproces en de uiteindelijke kwaliteitscontrole in één stap kunt uitvoeren. U kunt deze hulpprogramma's wijzigen om een certificaat te genereren of om een certificaat op te halen uit een vooraf gegenereerd certificaatarchief. Vervolgens kan de software het certificaat installeren waar u het moet installeren. Met softwarehulpprogramma's van dit type kunt u productiekwaliteit op schaal uitvoeren.

Nadat u certificaten op uw apparaten hebt geïnstalleerd, is de volgende stap het registreren van de apparaten met DPS.

Een TPM integreren in het productieproces

Als u een TPM gebruikt om uw IoT-apparaten te verifiëren, biedt deze sectie richtlijnen. De richtlijnen hebben betrekking op de veelgebruikte TPM 2.0-apparaten met HMAC-sleutelondersteuning (Hash-based Message Authentication Code). De TPM-specificatie voor TPM-chips is een ISO-standaard die wordt onderhouden door de Trusted Computing Group. Zie de specificaties voor TPM 2.0 en ISO/IEC 11889 voor meer informatie over TPM.

Eigenaar worden van de TPM

Een kritieke stap bij het produceren van een apparaat met een TPM-chip is het eigendom van de TPM. Deze stap is vereist, zodat u een sleutel kunt opgeven voor de eigenaar van het apparaat. De eerste stap is het extraheren van de goedkeuringssleutel (EK) van het apparaat. De volgende stap is het daadwerkelijk claimen van eigendom. Hoe u dit doet, is afhankelijk van het TPM- en besturingssysteem dat u gebruikt. Neem indien nodig contact op met de TPM-fabrikant of de ontwikkelaar van het besturingssysteem van het apparaat om te bepalen hoe het eigendom moet worden claimen.

In uw productieproces kunt u de EK extraheren en het eigendom claimen op verschillende momenten, waardoor flexibiliteit wordt toegevoegd. Veel fabrikanten profiteren van deze flexibiliteit door een HSM (Hardware Security Module) toe te voegen om de beveiliging van hun apparaten te verbeteren. In deze sectie vindt u richtlijnen voor het extraheren van de EK, wanneer u het eigendom van de TPM wilt claimen en overwegingen voor het integreren van deze stappen in een productietijdlijn.

Belangrijk

In de volgende richtlijnen wordt ervan uitgegaan dat u een discrete, firmware of geïntegreerde TPM gebruikt. Op plaatsen waar deze van toepassing is, worden in de richtlijnen notities toegevoegd over het gebruik van een niet-discrete TPM of software-TPM. Als u een software-TPM gebruikt, zijn er mogelijk extra stappen die deze richtlijnen niet bevatten. Software-TPM's hebben verschillende implementaties die buiten het bereik van dit artikel vallen. Over het algemeen is het mogelijk om een software-TPM te integreren in de volgende algemene productietijdlijn. Hoewel een met software geëmuleerde TPM echter geschikt is voor prototypen en testen, kan het niet hetzelfde beveiligingsniveau bieden als een discrete, firmware of geïntegreerde TPM. Als algemene praktijk vermijdt u het gebruik van een software-TPM in productie.

Algemene tijdlijn voor productie

In de volgende tijdlijn ziet u hoe een TPM een productieproces doorloopt en uiteindelijk in een apparaat terechtkomt. Elk productieproces is uniek en deze tijdlijn toont de meest voorkomende patronen. De tijdlijn biedt richtlijnen voor het uitvoeren van bepaalde acties met de sleutels.

Stap 1: TPM wordt vervaardigd

  • Als u TPM's van een fabrikant koopt voor gebruik op uw apparaten, controleert u of ze openbare goedkeuringssleutels (EK_pubs) voor u extraheren. Het is handig als de fabrikant de lijst met EK_pubs met de verzonden apparaten verstrekt.

    Notitie

    U kunt de TPM-fabrikant schrijftoegang geven tot uw inschrijvingslijst met behulp van beleid voor gedeelde toegang in uw inrichtingsservice. Met deze methode kunnen ze de TPM's voor u toevoegen aan uw inschrijvingslijst. Maar dat is vroeg in het productieproces en vereist vertrouwen in de TPM-fabrikant. Doe dit op eigen risico.

  • Als u TPM's produceert om te verkopen aan apparaatfabrikanten, kunt u overwegen om uw klanten een lijst met EK_pubs samen met hun fysieke TPM's te geven. Klanten EK_pubs een stap in hun proces opslaan.

  • Als u TPM's maakt voor gebruik met uw eigen apparaten, identificeert u welk punt in uw proces het handigst is om de EK_pub te extraheren. U kunt de EK_pub extraheren op een van de resterende punten in de tijdlijn.

Stap 2: TPM is geïnstalleerd op een apparaat

Op dit moment in het productieproces moet u weten met welk DPS-exemplaar het apparaat wordt gebruikt. Als gevolg hiervan kunt u apparaten toevoegen aan de inschrijvingslijst voor geautomatiseerde inrichting. Zie de DPS-documentatie voor meer informatie over het automatisch inrichten van apparaten.

  • Als u de EK_pub nog niet hebt geëxtraheerd, is het nu een goed moment om dit te doen.
  • Afhankelijk van het installatieproces van de TPM is deze stap ook een goed moment om eigenaar te worden van de TPM.

Stap 3: Op het apparaat zijn firmware en software geïnstalleerd

Op dit punt in het proces installeert u de DPS-client, samen met het id-bereik en de globale URL voor inrichting.

  • Nu is de laatste kans om de EK_pub te extraheren. Als een derde partij de software op uw apparaat installeert, is het een goed idee om eerst de EK_pub te extraheren.
  • Dit punt in het productieproces is ideaal om eigenaar te worden van de TPM.

    Notitie

    Als u een software-TPM gebruikt, kunt u deze nu installeren. Pak de EK_pub tegelijkertijd uit.

Stap 4: Het apparaat is verpakt en verzonden naar het magazijn

Een apparaat kan soms maximaal een jaar in een magazijn zitten voordat het wordt geïmplementeerd en ingericht met DPS. Als een apparaat zich lang vóór de implementatie in een magazijn bevindt, moeten klanten die het apparaat implementeren mogelijk de firmware, software of verlopen referenties bijwerken.

Stap 5: Het apparaat wordt geïnstalleerd op de locatie

Nadat het apparaat op de laatste locatie aankomt, gaat het via geautomatiseerde inrichting met DPS.

Zie inrichten en TPM-attestation voor meer informatie.

Resources

Naast de aanbevolen beveiligingsprocedures in dit artikel biedt Azure IoT resources om te helpen bij het selecteren van beveiligde hardware en het maken van beveiligde IoT-implementaties: