Autentisera identiteter med X.509-certifikat

Artikel
02/04/2025

IoT Hub använder X.509-certifikat för att autentisera enheter. X.509-autentisering tillåter autentisering av en IoT-enhet som en del av TLS-standardanslutningsetableringen (Transport Layer Security).

Ett certifikat för X.509-certifikatutfärdare (CA) är ett digitalt certifikat som kan signera andra certifikat. Ett digitalt certifikat betraktas som ett X.509-certifikat om det överensstämmer med den standard för certifikatformatering som föreskrivs i IETF:s RFC 5280-standard.

Funktionen X.509 CA möjliggör enhetsautentisering till IoT Hub med hjälp av en certifikatutfärdare (CA). Det förenklar den inledande processen för enhetsregistrering och logistik för leveranskedjan under enhetstillverkningen.

Autentisering och auktorisering

Autentisering är en process för att bevisa att du är den du säger att du är. Autentisering verifierar identiteten för en användare eller enhet till IoT Hub. Det förkortas ibland till AuthN.

Auktorisering är processen för att bekräfta behörigheter för en autentiserad användare eller enhet på IoT Hub. Den anger vilka resurser och kommandon du får åtkomst till och vad du kan göra med dessa resurser och kommandon. Auktorisering förkortas ibland till AuthZ.

X.509-certifikat används endast för autentisering i IoT Hub, inte auktorisering. Till skillnad från Microsoft Entra-ID och signaturer för delad åtkomst kan du inte anpassa behörigheter med X.509-certifikat.

Typer av certifikatautentisering

Du kan använda valfritt X.509-certifikat för att autentisera en enhet med IoT Hub genom att ladda upp antingen ett tumavtryck för certifikat eller en certifikatutfärdare (CA) till IoT Hub.

X.509 CA signerad - Det här alternativet rekommenderas för produktionsscenarier och är i fokus för den här artikeln.

Om enheten har ett CA-signerat X.509-certifikat laddar du upp ett rotcertifikat eller mellanliggande CA-certifikat i signeringskedjan till IoT Hub innan du registrerar enheten. Enheten har ett X.509-certifikat med den verifierade X.509 CA:n i certifikatkedjan. När enheten ansluter visar den sin fullständiga certifikatkedja och IoT-hubben kan verifiera den eftersom den känner till X.509 CA:n. Flera enheter kan autentisera mot samma verifierade X.509 CA.
X.509 självsignerad

Om enheten har ett självsignerat X.509-certifikat ger du IoT Hub en version av certifikatet för autentisering. När du registrerar en enhet laddar du upp ett tumavtryck för certifikatet, vilket är en hash för enhetens X.509-certifikat. När enheten ansluter visas certifikatet och IoT-hubben kan verifiera det mot den hash som den känner till.

Viktigt!

Följande funktioner för enheter som använder X.509-certifikatutfärdarautentisering (CA) är ännu inte allmänt tillgängliga och förhandsgranskningsläget måste vara aktiverat:

HTTPS, MQTT över WebSockets och AMQP via WebSockets-protokoll.
Filuppladdningar (alla protokoll).

Dessa funktioner är allmänt tillgängliga på enheter som använder X.509 tumavtrycksautentisering.

Framtvinga X.509-autentisering

För extra säkerhet kan en IoT-hubb konfigureras för att inte tillåta SAS-autentisering för enheter och moduler, vilket lämnar X.509 som det enda godkända autentiseringsalternativet. För närvarande är den här funktionen inte tillgänglig i Azure Portal. Konfigurera, ange disableDeviceSAS och disableModuleSAS till true för IoT Hub-resursegenskaperna:

az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true

Fördelar med X.509 CA-certifikatautentisering

IoT kräver en unik identitet för varje enhet som ansluter. För certifikatbaserad autentisering är dessa identiteter i form av certifikat.

Ett giltigt men ineffektivt sätt att tillhandahålla ett unikt certifikat på varje enhet är att förgenerera certifikat och ge alla leveranskedjepartner motsvarande privata nycklar. Den här metoden levereras med utmaningar som måste övervinnas för att säkerställa förtroende, enligt följande:

Att behöva dela privata enhetsnycklar med partner i leveranskedjan, förutom att ignorera PKI:s bästa praxis att aldrig dela privata nycklar, gör det dyrt att bygga förtroende för leveranskedjan. Det kräver system som säkra rum för att hysa privata enhetsnycklar och processer som periodiska säkerhetsgranskningar. Båda lägger till kostnader i leveranskedjan.
Att på ett säkert sätt redovisa enheter i leveranskedjan och senare hantera dem i distributionen via enhetens tillbakadragning blir en en-till-en-uppgift för varje nyckel-till-enhet-par. Den här relationen utesluter grupphantering av enheter om inte begreppet grupper uttryckligen är inbyggt i processen på något sätt. Säker hantering av redovisning och enhetens livscykel blir därför en tung driftsbörda.

X.509 CA-certifikatautentisering erbjuder eleganta lösningar på dessa utmaningar med hjälp av certifikatkedjor. En certifikatkedja är resultatet av att en certifikatutfärdare signerar en mellanliggande certifikatutfärdare som i sin tur signerar en annan mellanliggande certifikatutfärdare och så vidare tills en slutlig mellanliggande certifikatutfärdare signerar en enhet. Certifikatkedjor skapar en en-till-många-relation mellan ett CA-certifikat och dess underordnade enheter. Med den här relationen kan du registrera valfritt antal enheter i IoT Hub genom att registrera ett X.509 CA-certifikat en gång.

X.509 CA-autentisering förenklar även logistik för leveranskedjan. Ett typiskt enhetstillverkningsflöde omfattar flera steg och vårdnadshavare. Genom att använda certifikatutfärdare kan du signera varje förmyndare i en kryptografisk förtroendekedja i stället för att anförtro dem privata enhetsnycklar. Varje vårdnadshavare signerar enheter i respektive steg i tillverkningsflödet. Det övergripande resultatet är en optimal leveranskedja med inbyggt ansvar genom användning av den kryptografiska förtroendekedjan.

Den här processen ger mest säkerhet när enheter skyddar sina unika privata nycklar. Därför rekommenderar vi att du använder HSM (Hardware Secure Modules) som kan generera privata nycklar internt.

Azure IoT Hub Device Provisioning Service (DPS) gör det enkelt att etablera grupper av enheter till hubbar. Mer information finns i Självstudie: Etablera flera X.509-enheter med hjälp av registreringsgrupper.

X.509-certifikatflöde

I det här avsnittet beskrivs hur du använder X.509 CA-certifikat för att autentisera enheter som ansluter till IoT Hub, vilket innehåller följande steg:

Hämta ett X.509 CA-certifikat.
Signera enheter med X.509 CA-certifikat.
Registrera X.509 CA-certifikatet till IoT Hub.
Autentisera enheter som är signerade med X.509-certifikatutfärdare.
Återkalla ett enhetscertifikat om det har komprometterats.

Hämta ett X.509 CA-certifikat

X.509 CA-certifikatet är överst i kedjan med certifikat för var och en av dina enheter. Du kan köpa eller skapa en beroende på hur du tänker använda den.

För produktionsmiljöer rekommenderar vi att du köper ett X.509 CA-certifikat från en leverantör av professionella certifikattjänster.

Du kan också skapa ett självsignerat X.509 CA-certifikat i testsyfte. Mer information om hur du skapar certifikat för testning finns i Skapa och ladda upp certifikat för testning. Vi rekommenderar inte självsignerade certifikat för produktionsmiljöer.

Oavsett hur du skaffar ditt X.509 CA-certifikat ser du till att alltid hålla motsvarande privata nyckel hemlig och skyddad.

Köpa ett certifikat

Att köpa ett CA-certifikat har fördelen att en välkänd rotcertifikatutfärdare fungerar som en betrodd tredje part för att gå i god för IoT-enheters legitimitet när enheterna ansluter. Välj det här alternativet om dina enheter är en del av ett öppet IoT-nätverk där de interagerar med produkter eller tjänster från tredje part.

Om du vill köpa ett X.509 CA-certifikat väljer du en rotcertifikattjänstprovider. Rot-CA-providern vägleder dig om hur du skapar det offentliga/privata nyckelparet och hur du genererar en begäran om certifikatsignering (CSR) för deras tjänster. En CSR är den formella processen för att ansöka om ett certifikat från en certifikatutfärdare. Resultatet av det här köpet är ett certifikat som ska användas som certifikatutfärdare. Med tanke på allestädes närvarande X.509-certifikat kommer certifikatet sannolikt att ha formaterats korrekt till IETF:s RFC 5280-standard.

Skapa ett självsignerat certifikat

Processen för att skapa ett självsignerat X.509 CA-certifikat liknar att köpa ett, förutom att det inte involverar en tredjepartssignator som rotcertifikatutfärdaren.

Du kan välja det här alternativet för testning tills du är redo att köpa ett utfärdarcertifikat. Du kan också använda ett självsignerat X.509 CA-certifikat i produktion om dina enheter inte ansluter till några tjänster från tredje part utanför IoT Hub.

Logga in enheter i certifikatkedjan med förtroende

Ägaren till ett X.509 CA-certifikat kan kryptografiskt signera en mellanliggande certifikatutfärdare som i sin tur kan signera en annan mellanliggande certifikatutfärdare och så vidare tills den sista mellanliggande certifikatutfärdaren signerar ett enhetscertifikat. Resultatet är en överlappande kedja av certifikat som kallas för en förtroendekedja för certifikat. Den här förtroendedelegeringen är viktig eftersom den upprättar en kedja av vårdnad och undviker delning av signeringsnycklar.

Den här kaskad av certifikat i kedjan representerar den logiska överlämningen av utfärdaren. Många leveranskedjor följer den här logiska hand-offen där varje mellanliggande certifikatutfärdare loggas in i kedjan samtidigt som alla överordnade CA-certifikat tas emot. Den sista mellanliggande certifikatutfärdare signerar slutligen varje enhet och matar in alla utfärdarcertifikat från kedjan till enheten.

Diagram som visar certifikaten i en förtroendekedja.

Enhetscertifikatet (kallas även ett lövcertifikat) måste ha sitt gemensamma namn (CN) inställt på enhets-ID :t (CN=deviceId) som används när du registrerar IoT-enheten i Azure IoT Hub. Den här inställningen krävs för autentisering.

För moduler som använder X.509-autentisering måste modulens certifikat ha sitt gemensamma namn (CN) formaterat som CN=deviceId/moduleId.

Lär dig hur du skapar en certifikatkedja som du gör när du signerar enheter.

Registrera X.509 CA-certifikatet till IoT Hub

Registrera ditt X.509 CA-certifikat till IoT Hub, som använder det för att autentisera dina enheter. Ett X.509 CA-certifikat kan autentisera alla enheter som har certifikatutfärdare i certifikatkedjan. Registrering av X.509 CA-certifikatet är en tvåstegsprocess som omfattar uppladdning av certifikatfilen och sedan upprättande av bevis på innehav.

Uppladdningsprocessen innebär att du laddar upp en fil som innehåller certifikatet. Den här filen får aldrig innehålla några privata nycklar.

Steget bevis på innehav innebär en kryptografisk utmaning och svarsprocess mellan dig och IoT Hub för att verifiera att du verkligen äger CA-certifikatet. Du kan välja att antingen automatiskt eller manuellt verifiera ägarskapet. För manuell verifiering genererar IoT Hub en slumpmässig utmaning som du signerar med CA-certifikatets privata nyckel. Om du har bevarat den privata nyckeln hemligheten och skyddat enligt rekommendationerna är det bara du som har kunskapen för att slutföra det här steget. Sekretess för privata nycklar är källan till förtroende för den här metoden. När du har signerat utmaningen laddar du upp en fil som innehåller resultatet för att slutföra verifieringen.

Lär dig hur du registrerar certifikatutfärdarcertifikatet.

Autentisera enheter som är signerade med X.509 CA-certifikat

Med ditt X.509 CA-certifikat registrerat och enheter signerade med en förtroendekedja är det sista steget enhetsautentisering. När en X.509 CA-signerad enhet ansluter laddar den upp sin certifikatkedja för validering. Med den här informationen autentiserar IoT Hub enheten i en tvåstegsprocess.

Först validerar IoT Hub kryptografiskt certifikatkedjan för intern konsekvens. Sedan utfärdar IoT Hub en behörighetsbeprövning till enheten. IoT Hub deklarerar enhetens autentisering på ett lyckat bevis på innehav från enheten. Den här deklarationen förutsätter att enhetens privata nyckel är skyddad och att endast enheten kan svara på den här utmaningen. Vi rekommenderar att du använder säkra chips som HSM (Hardware Secure Modules) på enheter för att skydda privata nycklar.

En lyckad enhetsanslutning till IoT Hub slutför autentiseringsprocessen och tyder också på en korrekt konfiguration. Varje gång en enhet ansluter omförhandlar IoT Hub TLS-sessionen och verifierar enhetens X.509-certifikat.

Återkalla ett enhetscertifikat

IoT Hub kontrollerar inte listan över återkallade certifikat från certifikatutfärdare när enheter med certifikatbaserad autentisering autentiseras. Om du har en enhet som måste blockeras från att ansluta till IoT Hub på grund av ett potentiellt komprometterat certifikat inaktiverar du enheten i identitetsregistret. Mer information finns i Inaktivera eller ta bort en enhet.

Exempelscenario

Company-X gör Smart-X-Widgets som är utformade för professionell installation. Company-X outsourcar både tillverkning och installation. Factory-Y tillverkar Smart-X-Widgets och Technician-Z installerar dem. Company-X vill att Smart-X-Widget ska levereras direkt från Factory-Y till Technician-Z för installation och sedan ansluta direkt till Company-X:s instans av IoT Hub. För att göra detta måste Company-X slutföra några engångskonfigurationsåtgärder för att förbereda Smart-X-Widget för automatisk anslutning. Det här scenariot från slutpunkt till slutpunkt innehåller följande steg:

Hämta X.509 CA-certifikatet
Registrera X.509 CA-certifikatet till IoT Hub
Logga in enheter i en certifikatkedja med förtroende
Ansluta enheterna

De här stegen visas i Självstudie: Skapa och ladda upp certifikat för testning.

Hämta certifikatet

Company-X kan antingen köpa ett X.509 CA-certifikat från en offentlig rotcertifikatutfärdare eller skapa ett via en självsignerad process. Båda alternativen innebär två grundläggande steg: att generera ett offentligt/privat nyckelpar och signera den offentliga nyckeln till ett certifikat.

Information om hur du utför dessa steg skiljer sig från olika tjänsteleverantörer.

Registrera certifikatet till IoT Hub

Company-X måste registrera X.509 CA till IoT Hub där den fungerar för att autentisera Smart-X-Widgets när de ansluter. Med den här engångsprocessen kan du autentisera och hantera valfritt antal Smart-X-Widget-enheter. En-till-många-relationen mellan CA-certifikat och enhetscertifikat är en av de största fördelarna med att använda X.509 CA-autentiseringsmetoden. Alternativet skulle vara att ladda upp enskilda certifikattumavtryck för varje Smart-X-Widget-enhet, vilket ökar driftskostnaderna.

Att registrera X.509 CA-certifikatet är en tvåstegsprocess: ladda upp certifikatet och ange sedan bevis på innehav.

Ladda upp certifikatet

X.509 CA-certifikatuppladdningsprocessen är just det: ladda upp CA-certifikatet till IoT Hub. IoT Hub förväntar sig certifikatet i en fil.

Certifikatfilen får inte under några omständigheter innehålla några privata nycklar. Bästa praxis från standarder som styr PKI (Public Key Infrastructure) kräver att kunskap om Company-X:s privata nyckel uteslutande finns i Company-X.

Bevisa innehav

X.509 CA-certifikatet, precis som alla digitala certifikat, är offentlig information som är känslig för avlyssning. Därför kan en tjuvlyssnare fånga upp ett certifikat och försöka ladda upp det som sitt eget. I vårt exempel måste IoT Hub se till att ca-certifikatet Company-X som laddats upp verkligen tillhör Company-X. Det gör det genom att utmana Company-X att bevisa att de har certifikatet genom ett PoP-flöde (proof-of-possession).

För flödet proof-of-possession genererar IoT Hub ett slumpmässigt tal som Company-X kan signera med sin privata nyckel. Om Company-X följde PKI:s metodtips och skyddade sin privata nyckel skulle bara de kunna svara korrekt på utmaningen med bevis på innehav. IoT Hub fortsätter att registrera X.509 CA-certifikatet efter ett lyckat svar på utmaningen med bevis på innehav.

Ett lyckat svar på proof-of-possession-utmaningen från IoT Hub slutför X.509 CA-registreringen.

Logga in enheter i en certifikatkedja med förtroende

I vårt exempel innebär certifikatbaserad autentisering att varje Smart-X-Widget måste ha ett unikt enhetscertifikat. I stället för att skapa enskilda certifikat/nyckelpar för varje enhet bestämmer sig Company-X för att använda CA-certifikat och skapa en förtroendekedja för varje enhet.

I vårt exempel signerar Company-X Factory-Y, som i sin tur signerar Technician-Z som slutligen signerar Smart-X-Widget.

Följande diagram visar hur certifikatkedjan med förtroende samlas i vårt Smart-X-Widget-exempel.

Company-X interagerar aldrig fysiskt med någon av Smart-X-Widgets. Den initierar certifikatkedjan med förtroende genom att signera Factory-Y:s mellanliggande CA-certifikat.
Factory-Y har nu ett eget mellanliggande CA-certifikat med en signatur från Company-X. Den skickar kopior av dessa objekt till varje enhet. Den använder också sitt mellanliggande CA-certifikat för att signera Technician-Z:s mellanliggande CA-certifikat och Smart-X-Widget-enhetscertifikaten.
Tekniker-Z har nu ett eget mellanliggande CA-certifikat med en signatur från Factory-Y. Den skickar kopior av dessa objekt till varje enhet. Den använder också sitt mellanliggande CA-certifikat för att signera Smart-X-Widget-enhetscertifikaten.
Varje Smart X-Widget-enhet har nu ett eget unikt enhetscertifikat och kopior av offentliga nycklar och signaturer från varje mellanliggande CA-certifikat som den interagerade med i hela leveranskedjan. Dessa certifikat och signaturer kan spåras tillbaka till den ursprungliga Company-X-roten.

Ca-metoden för autentisering ingjuter säker ansvarsskyldighet i leveranskedjan för enhetstillverkning. På grund av processen för certifikatkedjan registreras och verifieras åtgärderna för varje medlem i kedjan kryptografiskt.

Den här processen bygger på antagandet att det unika offentliga/privata nyckelparet för enheten skapas oberoende av varandra och att den privata nyckeln alltid skyddas inom enheten. Lyckligtvis finns säkra kiselchips i form av maskinvarusäkerhetsmoduler (HSM) som kan generera nycklar internt och skydda privata nycklar. Company-X behöver bara lägga till ett sådant säkert chip i Smart-X-Widgets komponentfaktura.

Autentisera enheter

Enheter som tillverkas för X.509 CA-autentisering är utrustade med unika enhetscertifikat och en certifikatkedja från respektive leveranskedja för tillverkning. Enhetsanslutning sker även för första gången i en tvåstegsprocess: uppladdning av certifikatkedja och innehavsbevis.

I vårt exempel laddar varje Smart-X-Widget upp sitt unika enhetscertifikat tillsammans med Factory-Y- och Technician-Z X.509 CA-certifikat och svarar sedan på utmaningen proof-of-possession från IoT Hub.

Med det förregistrerade X.509 CA-certifikatet från Company-X verifierar IoT Hub att den uppladdade certifikatkedjan är internt konsekvent och att den giltiga ägaren av X.509 CA-certifikatet har sitt ursprung i kedjan. Precis som med registreringsprocessen för X.509 CA använder IoT Hub en test-of-possession challenge-response-process för att fastställa att kedjan och därmed enhetscertifikatet tillhör den enhet som laddar upp den. Ett lyckat svar utlöser IoT Hub för att acceptera enheten som autentiserad och bevilja den anslutning.

Grunden för förtroende ligger i att skydda privata nycklar, inklusive privata enhetsnycklar. Därför kan vi inte tillräckligt betona vikten av säkra kiselchips i form av maskinvarusäkerhetsmoduler (HSM) för att skydda privata enhetsnycklar, och det övergripande bästa sättet att aldrig dela privata nycklar från något certifikat i kedjan.

Nästa steg

Använd device provisioning-tjänsten för att etablera flera X.509-enheter med hjälp av registreringsgrupper.

Mer information om fälten som utgör ett X.509-certifikat finns i X.509-certifikat.

Om du har ett rotcertifikatutfärdarcertifikat eller ett underordnat CA-certifikat och vill ladda upp det till din IoT-hubb måste du kontrollera att du äger certifikatet. Mer information finns i Självstudie: Skapa och ladda upp certifikat för testning.

Dela via