Dela via

Säkerhetsmetoder för Azure IoT-enhetstillverkare

  • Artikel

När fler tillverkare släpper IoT-enheter är det bra att identifiera vägledning kring vanliga metoder. Den här artikeln sammanfattar rekommenderade säkerhetsmetoder att tänka på när du tillverkar enheter för användning med Azure IoT Device Provisioning Service (DPS).

  • Välja alternativ för enhetsautentisering
  • Installera certifikat på IoT-enheter
  • Integrera en TPM (Trusted Platform Module) i tillverkningsprocessen

Välja alternativ för enhetsautentisering

Det ultimata syftet med alla IoT-enhetssäkerhetsmått är att skapa en säker IoT-lösning. Men problem som maskinvarubegränsningar, kostnader och säkerhetsexpertis påverkar alla vilka alternativ du väljer. Dessutom påverkar din säkerhetsstrategi hur dina IoT-enheter ansluter till molnet. Det finns flera element i IoT-säkerhet att tänka på, men ett nyckelelement som varje kund stöter på är vilken autentiseringstyp som ska användas.

Tre allmänt använda autentiseringstyper är X.509-certifikat, TPM (Trusted Platform Modules) och symmetriska nycklar. Även om det finns andra autentiseringstyper använder de flesta kunder som skapar lösningar på Azure IoT någon av dessa tre typer. Resten av den här artikeln granskar fördelarna och nackdelarna med att använda varje autentiseringstyp.

X.509-certifikat

X.509-certifikat är en typ av digital identitet som du kan använda för autentisering. X.509-certifikatstandarden dokumenteras i IETF RFC 5280. I Azure IoT finns det två sätt att autentisera certifikat:

  • Tumavtryck. En tumavtrycksalgoritm körs på ett certifikat för att generera en hexadecimal sträng. Den genererade strängen är en unik identifierare för certifikatet.
  • CA-autentisering baserat på en fullständig kedja. En certifikatkedja är en hierarkisk lista över alla certifikat som behövs för att autentisera ett EE-certifikat (end-entity). För att autentisera ett EE-certifikat är det nödvändigt att autentisera varje certifikat i kedjan, inklusive en betrodd rotcertifikatutfärdare.

Proffs för X.509:

  • X.509 är den säkraste autentiseringstypen som stöds i Azure IoT.
  • X.509 tillåter en hög kontrollnivå för certifikathantering.
  • Många leverantörer är tillgängliga för att tillhandahålla X.509-baserade autentiseringslösningar.

Nackdelar för X.509:

  • Många kunder kan behöva förlita sig på externa leverantörer för sina certifikat.
  • Certifikathantering kan vara kostsamt och bidrar till den totala lösningskostnaden.
  • Det kan vara svårt att hantera certifikatets livscykel om logistiken inte är väl genomtänkt.

Trusted Platform Module (TPM)

TPM, även kallat ISO/IEC 11889, är en standard för säker generering och lagring av kryptografiska nycklar. TPM refererar också till en virtuell eller fysisk I/O-enhet som interagerar med moduler som implementerar standarden. En TPM-enhet kan finnas som diskret maskinvara, integrerad maskinvara, en modul baserad på inbyggd programvara eller en programvarubaserad modul.

Det finns två viktiga skillnader mellan TPM:er och symmetriska nycklar:

  • TPM-chips kan också lagra X.509-certifikat.
  • TPM-attestering i DPS använder TPM-bekräftelsenyckeln (EK), en form av asymmetrisk autentisering. Med asymmetrisk autentisering används en offentlig nyckel för kryptering och en separat privat nyckel används för dekryptering. Symmetriska nycklar använder däremot symmetrisk autentisering, där den privata nyckeln används för både kryptering och dekryptering.

Fördelar för TPM:

  • TPM:er ingår som standardmaskinvara på många Windows-enheter, med inbyggt stöd för operativsystemet.
  • TPM-attestering är enklare att skydda än tokenbaserad symmetrisk nyckelattestering med signatur för delad åtkomst (SAS).
  • Du kan enkelt förfalla och förnya eller rulla autentiseringsuppgifter för enheten. DPS återställer automatiskt IoT Hub-autentiseringsuppgifterna när en TPM-enhet ska återskapas.

Nackdelar för TPM:

  • TPM:er är komplexa och kan vara svåra att använda.
  • Programutveckling med TPM är svårt om du inte har en fysisk TPM eller en kvalitetsemulator.
  • Du kan behöva göra om kortet på enheten för att inkludera en TPM i maskinvaran.
  • Om du rullar EK på en TPM förstör den identiteten för TPM och skapar en ny. Även om det fysiska chipet förblir detsamma har det en ny identitet i din IoT-lösning.

Symmetrisk nyckel

Med symmetriska nycklar används samma nyckel för att kryptera och dekryptera meddelanden. Därför är samma nyckel känd för både enheten och tjänsten som autentiserar den. Azure IoT stöder SAS-tokenbaserade symmetriska nyckelanslutningar. Symmetrisk nyckelautentisering kräver ett betydande ägaransvar för att skydda nycklarna och uppnå en lika hög säkerhetsnivå med X.509-autentisering. Om du använder symmetriska nycklar rekommenderar vi att du skyddar nycklarna med hjälp av en maskinvarusäkerhetsmodul (HSM).

Proffs för symmetrisk nyckel:

  • Att använda symmetriska nycklar är det enklaste och billigaste sättet att komma igång med autentisering.
  • Genom att använda symmetriska nycklar effektiviseras processen eftersom det inte finns något extra att generera.

Nackdelar med symmetrisk nyckel:

  • Symmetriska nycklar tar en betydande grad av arbete för att säkra nycklarna. Samma nyckel delas mellan enhet och moln, vilket innebär att nyckeln måste skyddas på två platser. Däremot bevisar utmaningen med TPM- och X.509-certifikat att den offentliga nyckeln innehas utan att den privata nyckeln avslöjas.
  • Symmetriska nycklar gör det enkelt att följa dåliga säkerhetsmetoder. En vanlig tendens med symmetriska nycklar är att hårdkoda de okrypterade nycklarna på enheter. Även om den här metoden är praktisk lämnar den nycklarna sårbara. Du kan minska vissa risker genom att lagra den symmetriska nyckeln på enheten på ett säkert sätt. Men om din prioritet i slutändan är säkerhet snarare än bekvämlighet använder du X.509-certifikat eller TPM för autentisering.

Delad symmetrisk nyckel

Det finns en variant av symmetrisk nyckelautentisering som kallas delad symmetrisk nyckel. Den här metoden innebär att du använder samma symmetriska nyckel på alla enheter. Rekommendationen är att undvika att använda delade symmetriska nycklar på dina enheter.

Pro för delad symmetrisk nyckel:

  • Enkelt att implementera och billigt att producera i stor skala.

Nackdelar med delad symmetrisk nyckel:

  • Mycket sårbar för angrepp. Risken för angrepp uppväger fördelen med enkel implementering.
  • Vem som helst kan personifiera dina enheter om de hämtar den delade nyckeln.
  • Om du förlitar dig på en delad symmetrisk nyckel som komprometteras förlorar du förmodligen kontrollen över enheterna.

Göra rätt val för dina enheter

Om du vill välja en autentiseringsmetod bör du ta hänsyn till fördelarna och kostnaderna för varje metod för din unika tillverkningsprocess. För enhetsautentisering finns det vanligtvis en inverteringsrelation mellan hur säker en viss metod är och hur bekväm den är.

Installera certifikat på IoT-enheter

Om du använder X.509-certifikat för att autentisera dina IoT-enheter ger det här avsnittet vägledning om hur du integrerar certifikat i din tillverkningsprocess. Du måste fatta flera beslut, inklusive beslut om vanliga certifikatvariabler, när certifikat ska genereras och när de ska installeras.

Om du är van vid att använda lösenord kanske du undrar varför du inte kan använda samma certifikat på alla dina enheter, ungefär som du kanske använder samma lösenord. För det första är det riskabelt att använda samma lösenord överallt och har lett till betydande DDoS-attacker, till exempel det som störde DNS på usa:s östkust för flera år sedan. Återanvänd aldrig lösenord, inte ens för personliga konton. För det andra är ett certifikat inte ett lösenord. Det är en unik identitet. Ett lösenord är som en hemlig kod som vem som helst kan använda för att låsa upp en dörr i en säker byggnad – det är något du känner till och kan dela. Däremot är ett certifikat som ett körkort med ditt foto och din information, som du visar för en vakt för att få åtkomst. Det är kopplat till din identitet. Så länge vakten matchar personer korrekt med sina licenser kan du bara använda din licens (identitet) för att komma in.

Variabler som ingår i certifikatbeslut

Tänk på följande variabler och hur var och en påverkar den övergripande tillverkningsprocessen.

Där certifikatroten för förtroende kommer från

Det kan vara kostsamt och komplext att hantera en offentlig nyckelinfrastruktur (PKI). Särskilt om ditt företag inte har någon erfarenhet av att hantera en PKI. Dina alternativ är:

  • Använd en PKI från tredje part. Du kan köpa mellanliggande signeringscertifikat från en tredjepartscertifikatleverantör. Eller så kan du använda en privat certifikatutfärdare (CA).
  • Använd en självhanterad PKI. Du kan underhålla ditt eget PKI-system och generera egna certifikat.

Var certifikat lagras

Det finns några faktorer som påverkar beslutet om var certifikat lagras. Dessa faktorer omfattar typen av enhet, förväntade vinstmarginaler (om du har råd med säker lagring), enhetsfunktioner och befintlig säkerhetsteknik på den enhet som du kanske kan använda. Överväg följande alternativ:

  • I en maskinvarusäkerhetsmodul (HSM). Användning av en HSM rekommenderas starkt. Kontrollera om enhetens kontrollkort redan har en HSM installerad. Om du vet att du inte har någon HSM kan du samarbeta med maskinvarutillverkaren för att identifiera en HSM som uppfyller dina behov.
  • På en säker plats på disken, till exempel en betrodd körningsmiljö (TEE).
  • I det lokala filsystemet eller i ett certifikatarkiv. Till exempel Windows-certifikatarkivet.

Anslutning på fabriken

Anslutningen på fabriken avgör hur och när du får certifikaten att installera på enheterna. Anslutningsalternativen är följande:

  • Anslutning. Anslutningen är optimal och effektiviserar processen för att generera certifikat lokalt.
  • Ingen anslutning. I det här fallet använder du ett signerat certifikat från en certifikatutfärdare för att generera enhetscertifikat lokalt och offline.
  • Ingen anslutning. I det här fallet kan du hämta certifikat som genererades i förväg. Eller så kan du använda en offline-PKI för att generera certifikat lokalt.

Granskningskrav

Beroende på vilken typ av enheter du producerar kan du ha ett regelkrav för att skapa en spårningslogg för hur enhetsidentiteter installeras på dina enheter. Granskning lägger till betydande produktionskostnader. Så i de flesta fall gör du det bara om det behövs. Om du är osäker på om en granskning krävs kan du kontakta företagets juridiska avdelning. Granskningsalternativ är:

  • Inte en känslig bransch. Ingen granskning krävs.
  • Känslig industri. Certifikat ska installeras i ett säkert rum enligt kraven för efterlevnadscertifiering. Om du behöver ett säkert utrymme för att installera certifikat är du förmodligen redan medveten om hur certifikat installeras på dina enheter. Och du har förmodligen redan ett granskningssystem på plats.

Längden på certifikatets giltighet

Liksom ett körkort har certifikat ett förfallodatum som anges när de skapas. Du måste förnya certifikatet under enhetens livslängd. Längden på certifikatets giltighet beror på kontexten och du behöver en strategi för förnyelse. Strategin bör omfatta var du får certifikat och vilken typ av funktioner som enheterna måste använda i förnyelseprocessen.

När du ska generera certifikat

Internetanslutningsfunktionerna i din fabrik påverkar processen för att generera certifikat. Du har flera alternativ för när du ska generera certifikat:

  • Förinstallerade certifikat. Vissa HSM-leverantörer erbjuder en premiumtjänst där HSM-leverantören installerar certifikat för kunden. Först ger kunderna HSM-leverantören åtkomst till ett signeringscertifikat. Sedan installerar HSM-leverantören certifikat som signerats av signeringscertifikatet på varje HSM som kunden köper. Allt kunden behöver göra är att installera HSM på enheten. Även om den här tjänsten tillför kostnader hjälper den till att effektivisera tillverkningsprocessen. Och det löser frågan om när certifikat ska installeras.
  • Enhetsgenererade certifikat. Om dina enheter genererar certifikat internt måste du extrahera det offentliga X.509-certifikatet från enheten för att registrera det i DPS.
  • Ansluten fabrik. Om din fabrik har anslutning kan du generera enhetscertifikat när du behöver dem.
  • Offlinefabrik med din egen PKI. Om din fabrik inte har någon anslutning och du använder din egen PKI med offlinestöd kan du generera certifikaten när du behöver dem.
  • Offlinefabrik med PKI från tredje part. Om din fabrik inte har någon anslutning och du använder en PKI från tredje part måste du generera certifikaten i förväg. Och det är nödvändigt att generera certifikaten från en plats som har anslutning.

När du ska installera certifikat

När du har genererat certifikat för dina IoT-enheter kan du installera dem på enheterna.

Om du använder förinstallerade certifikat med en HSM förenklas processen. När HSM har installerats på enheten kan enhetskoden komma åt den. Sedan anropar du HSM-API:erna för att komma åt certifikatet som lagras i HSM. Den här metoden är den mest praktiska för din tillverkningsprocess.

Om du inte använder ett förinstallerat certifikat måste du installera certifikatet som en del av produktionsprocessen. Den enklaste metoden är att installera certifikatet i HSM samtidigt som du blinkar den första avbildningen av inbyggd programvara. Processen måste lägga till ett steg för att installera avbildningen på varje enhet. Efter det här steget kan du köra slutgiltiga kvalitetskontroller och andra steg innan du paketera och skicka enheten.

Det finns programvaruverktyg som gör att du kan köra installationsprocessen och den slutliga kvalitetskontrollen i ett enda steg. Du kan ändra dessa verktyg för att generera ett certifikat eller för att hämta ett certifikat från ett förgenererat certifikatarkiv. Sedan kan programvaran installera certifikatet där du behöver installera det. Med programvaruverktyg av den här typen kan du köra produktionskvalitetstillverkning i stor skala.

När du har installerat certifikat på dina enheter är nästa steg att lära dig hur du registrerar enheterna med DPS.

Integrera en TPM i tillverkningsprocessen

Om du använder en TPM för att autentisera dina IoT-enheter ger det här avsnittet vägledning. Vägledningen omfattar de allmänt använda TPM 2.0-enheter som har stöd för hashbaserad kod för meddelandeautentisering (HMAC). TPM-specifikationen för TPM-chips är en ISO-standard som underhålls av den betrodda databehandlingsgruppen. Mer information om TPM finns i specifikationerna för TPM 2.0 och ISO/IEC 11889.

Ta över ägarskapet för TPM

Ett viktigt steg i tillverkningen av en enhet med ett TPM-chip är att ta ägarskapet för TPM. Det här steget krävs så att du kan ange en nyckel till enhetens ägare. Det första steget är att extrahera bekräftelsenyckeln (EK) från enheten. Nästa steg är att faktiskt göra anspråk på ägarskap. Hur du extraherar bekräftelsenyckeln beror på vilket TPM och operativsystem du använder. Om det behövs kontaktar du TPM-tillverkaren eller utvecklaren av enhetens operativsystem för att ta reda på hur du gör anspråk på ägarskap.

I din tillverkningsprocess kan du extrahera EK och göra anspråk på ägarskap vid olika tidpunkter, vilket ger flexibilitet. Många tillverkare drar nytta av den här flexibiliteten genom att lägga till en maskinvarusäkerhetsmodul (HSM) för att förbättra säkerheten på sina enheter. Det här avsnittet innehåller vägledning om när du ska extrahera EK, när du ska göra anspråk på ägarskap för TPM och överväganden för att integrera dessa steg i en tillverkningstidslinje.

Viktigt!

Följande vägledning förutsätter att du använder en diskret, inbyggd programvara eller integrerad TPM. På platser där det är tillämpligt lägger vägledningen till anteckningar om hur du använder en TPM som inte är diskret eller programvara. Om du använder en TPM-programvara kan det finnas ytterligare steg som inte ingår i den här vägledningen. Programvaru-TPM:er har en mängd olika implementeringar som ligger utanför den här artikelns omfång. I allmänhet är det möjligt att integrera en programvaru-TPM i följande allmänna tillverkningstidslinje. Även om en programvaruemulerad TPM är lämplig för prototyper och testning, kan den dock inte ge samma säkerhetsnivå som en diskret, inbyggd programvara eller integrerad TPM. Som allmän praxis bör du undvika att använda en TPM-programvara i produktion.

Tidslinje för allmän tillverkning

Följande tidslinje visar hur en TPM går igenom en produktionsprocess och hamnar i en enhet. Varje tillverkningsprocess är unik och den här tidslinjen visar de vanligaste mönstren. Tidslinjen ger vägledning om när du ska vidta vissa åtgärder med nycklarna.

Steg 1: TPM tillverkas

  • Om du köper TPM:er från en tillverkare för användning på dina enheter kan du se om de extraherar offentliga bekräftelsenycklar (EK_pubs) åt dig. Det är användbart om tillverkaren tillhandahåller listan över EK_pubs med de levererade enheterna.

    Kommentar

    Du kan ge TPM-tillverkaren skrivåtkomst till din registreringslista med hjälp av principer för delad åtkomst i etableringstjänsten. Med den här metoden kan de lägga till TPM:erna i registreringslistan åt dig. Men det är tidigt i tillverkningsprocessen, och det kräver förtroende för TPM-tillverkaren. Gör det på egen risk.

  • Om du tillverkar TPM:er för att sälja till enhetstillverkare bör du överväga att ge dina kunder en lista över EK_pubs tillsammans med deras fysiska TPM:er. Att ge kunderna EK_pubs sparar ett steg i processen.

  • Om du tillverkar TPM:er att använda med dina egna enheter kan du identifiera vilken punkt i processen som är mest praktisk att extrahera EK_pub. Du kan extrahera EK_pub på någon av de återstående punkterna i tidslinjen.

Steg 2: TPM installeras i en enhet

Nu i produktionsprocessen bör du veta vilken DPS-instans enheten används med. Därför kan du lägga till enheter i registreringslistan för automatisk etablering. Mer information om automatisk enhetsetablering finns i DPS-dokumentationen.

  • Om du inte har extraherat EK_pub är det dags att göra det nu.
  • Beroende på installationsprocessen för TPM är det här steget också ett bra tillfälle att ta över ägarskapet för TPM.

Steg 3: Enheten har inbyggd programvara installerad

Nu i processen installerar du DPS-klienten tillsammans med ID-omfånget och den globala URL:en för etablering.

  • Nu är sista chansen att extrahera EK_pub. Om en tredje part installerar programvaran på enheten är det en bra idé att extrahera EK_pub först.
  • Den här punkten i tillverkningsprocessen är idealisk för att ta över ägarskapet för TPM.

    Kommentar

    Om du använder en TPM-programvara kan du installera den nu. Extrahera EK_pub samtidigt.

Steg 4: Enheten paketeras och skickas till lagret

En enhet kan ibland sitta i ett lager i upp till ett år innan den distribueras och etableras med DPS. Om en enhet finns i ett lager under en lång tid före distributionen kan kunder som distribuerar enheten behöva uppdatera den inbyggda programvaran, programvaran eller utgångna autentiseringsuppgifter.

Steg 5: Enheten installeras på platsen

När enheten har anlänt till sin sista plats går den igenom automatisk etablering med DPS.

Mer information finns i etablering och TPM-attestering.

Resurser

Utöver de rekommenderade säkerhetsmetoderna i den här artikeln tillhandahåller Azure IoT resurser som hjälper dig att välja säker maskinvara och skapa säkra IoT-distributioner: