Autentisera identiteter med X.509-certifikat

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

Ett X.509 CA-certifikat ä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. En certifikatutfärdare (CA) innebär att innehavaren kan signera andra certifikat.

Den här artikeln beskriver hur du använder X.509-certifikatutfärdare (CA) för att autentisera enheter som ansluter till IoT Hub, vilket omfattar följande steg:

• Hämta ett X.509 CA-certifikat
• Så här registrerar du X.509 CA-certifikatet till IoT Hub
• Så här signerar du enheter med X.509 CA-certifikat
• Så här autentiseras enheter som är signerade med X.509 CA

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. Mer information om X.509-autentisering med IoT Hub finns i X.509-certifikat som stöds.

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.

I den här artikeln beskrivs autentisering med X.509-certifikat. 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 Azure IoT Hub.

X.509-certifikat används 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.

Framtvinga X.509-autentisering

För ytterligare 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-portalen. 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

X.509-certifikatutfärdarautentisering (CA) är en metod för att autentisera enheter till IoT Hub med en metod som dramatiskt förenklar skapandet av enhetsidentiteter och livscykelhantering i leveranskedjan.

Ett särskiljande attribut för X.509 CA-autentisering är den en-till-många-relation som ett CA-certifikat har med sina underordnade enheter. Den här relationen möjliggör registrering av valfritt antal enheter i IoT Hub genom att registrera ett X.509 CA-certifikat en gång. Annars måste unika certifikat vara förregistrerade för varje enhet innan en enhet kan ansluta. Den här en-till-många-relationen förenklar även livscykelhanteringsåtgärder för enhetscertifikat.

Ett annat viktigt attribut för X.509 CA-autentisering är förenkling av logistik för leveranskedjan. Säker autentisering av enheter kräver att varje enhet har en unik hemlighet som en nyckel som grund för förtroende. I certifikatbaserad autentisering är den här hemligheten en privat nyckel. Ett typiskt enhetstillverkningsflöde omfattar flera steg och vårdnadshavare. Det är svårt och dyrt att hantera privata enhetsnycklar på ett säkert sätt över flera vårdnadshavare och upprätthålla förtroendet. Med hjälp av certifikatutfärdare löser du det här problemet genom att signera varje förmyndare i en kryptografisk förtroendekedja i stället för att ge 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.

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. Att köpa ett CA-certifikat har fördelen att rotcertifikatutfärdare fungerar som en betrodd tredje part för att gå i god för enheternas legitimitet. Överväg det här alternativet om dina enheter ingår i ett öppet IoT-nätverk där de interagerar med produkter eller tjänster från tredje part.

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.

Kommentar

Vi rekommenderar inte att du använder 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. Den här försiktighetsåtgärden är nödvändig för att skapa förtroende för X.509 CA-autentiseringen.

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 avslutar processen genom att signera ett enhetscertifikat. Resultatet är en överlappande kedja av certifikat som kallas för en förtroendekedja för certifikat. Den här delegeringen av förtroende är viktig eftersom den upprättar en kryptografiskt variabel kedja av vårdnad och undviker delning av signeringsnycklar.

Enhetscertifikatet (kallas även ett lövcertifikat) måste ha sitt gemensamma namn (CN) inställt på enhets-ID :t (CN=deviceId) som användes när IoT-enheten registrerades 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 under registreringen och anslutningen. 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.

Beviset på innehavssteget omfattar en kryptografisk utmaning och svarsprocess mellan dig och IoT Hub. Med tanke på att innehållet i det digitala certifikatet är offentligt och därför är känsligt för avlyssning måste IoT Hub verifiera att du verkligen äger CA-certifikatet. Du kan välja att antingen automatiskt eller manuellt verifiera ägarskapet. För manuell verifiering genererar Azure IoT Hub en slumpmässig utmaning som du signerar med CA-certifikatets motsvarande 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 slutför du det här steget och verifierar certifikatet manuellt genom att ladda upp en fil som innehåller resultatet.

Lär dig hur du registrerar certifikatutfärdarcertifikatet.

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

Varje IoT-hubb har ett identitetsregister som lagrar information om de enheter och moduler som tillåts ansluta till den. Innan en enhet eller modul kan ansluta måste det finnas en post för enheten eller modulen i IoT-hubbens identitetsregister. En enhet eller modul autentiserar med IoT-hubben baserat på autentiseringsuppgifter som lagras i identitetsregistret.

Med ditt X.509 CA-certifikat registrerat och enheter som är inloggade i en certifikatkedja med förtroende är det sista steget enhetsautentisering när enheten ansluter. När en X.509 CA-signerad enhet ansluter laddar den upp sin certifikatkedja för validering. Kedjan innehåller alla mellanliggande certifikatutfärdare och enhetscertifikat. Med den här informationen autentiserar IoT Hub enheten i en tvåstegsprocess. IoT Hub validerar kryptografiskt certifikatkedjan för intern konsekvens och utfärdar sedan en proof-of-possession-utmaning 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 bör du inaktivera enheten i identitetsregistret. Mer information finns i Inaktivera eller ta bort en enhet i en IoT-hubb.

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 detta ska hända måste Company-X slutföra några engångskonfigurationsåtgärder för att skapa smart X-widget för automatisk anslutning. Det här scenariot från slutpunkt till slutpunkt innehåller följande steg:

1. Hämta certifikatet för X.509 CA

2. Registrera X.509 CA-certifikatet till IoT Hub

3. Logga in enheter i en certifikatkedja med förtroende

4. Anslut 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.

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 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 hjälper dig att skapa 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. I vårt exempel skulle Company-X signera sitt utfärdarcertifikat i stället för en rotcertifikatutfärdare.

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.

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 nummer som ska signeras av Company-X med dess 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

IoT kräver en unik identitet för varje enhet som ansluter. För certifikatbaserad autentisering är dessa identiteter i form av certifikat. I vårt exempel innebär certifikatbaserad autentisering att varje Smart-X-Widget måste ha ett unikt enhetscertifikat.

Ett giltigt men ineffektivt sätt att tillhandahålla unika certifikat på varje enhet är att förgenerera certifikat för Smart-X-Widgets och att lita på partner i leveranskedjan med motsvarande privata nycklar. För Company-X innebär det att du anförtror både Factory-Y och Technician-Z. 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 blir en en-till-en-uppgift för varje nyckel-till-enhet-par från platsen för enhetens unika certifikatgenerering (och privat nyckel) till enhetens tillbakadragning. Detta 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. I vårt exempel signerar Company-X Factory-Y, som i sin tur signerar Technician-Z som slutligen signerar Smart-X-Widget.

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, och den sista mellanliggande certifikatutfärdare signerar slutligen varje enhet och matar in alla utfärdarcertifikat från kedjan i enheten. Denna överlämning är vanlig när det kontrakterade tillverkningsföretaget med en hierarki av fabriker beställer en viss fabrik för att göra tillverkningen. Hierarkin kan vara flera nivåer djup (till exempel efter geografi/produkttyp/tillverkningslinje), men endast fabriken i slutet får interagera med enheten, men kedjan underhålls överst i hierarkin.

Alternativa kedjor kan ha olika mellanliggande certifikatutfärdare som interagerar med enheten, i vilket fall certifikatutfärdare interagerar med enheten som matar in certifikatkedjans innehåll vid den tidpunkten. Hybridmodeller är också möjliga där endast vissa av ca:erna har fysisk interaktion med enheten.

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

1. 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.
2. Factory-Y har nu ett eget mellanliggande CA-certifikat och en signatur från Company-X. Den skickar kopior av dessa objekt till enheten. Det använder också sitt mellanliggande CA-certifikat för att signera Technician-Z:s mellanliggande CA-certifikat och Smart-X-Widget-enhetscertifikatet.
3. Tekniker-Z har nu ett eget mellanliggande CA-certifikat och en signatur från Factory-Y. Den skickar kopior av dessa objekt till enheten. Den använder också sitt mellanliggande CA-certifikat för att signera Smart-X-Widget-enhetscertifikatet.
4. 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

Hur ansluter de när ca-certifikatet på den översta nivån har registrerats till IoT Hub och enheterna har sina unika certifikat? Hur kan potentiellt miljontals enheter ansluta och autentiseras från första gången genom att registrera ett X.509 CA-certifikat till IoT Hub? Genom samma certifikatuppladdning och proof-of-possession-flöde som vi tidigare stötte på när vi registrerade X.509 CA-certifikatet.

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.

Under uppladdningen av certifikatkedjan laddar enheten upp sitt unika certifikat och sin certifikatkedja till IoT Hub. Med det förregistrerade X.509 CA-certifikatet verifierar IoT Hub att den uppladdade certifikatkedjan är internt konsekvent och att kedjan har sitt ursprung i den giltiga ägaren av X.509 CA-certifikatet. 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.

I vårt exempel skulle varje Smart-X-Widget ladda upp sitt unika enhetscertifikat tillsammans med Ca-certifikaten Factory-Y och Technician-Z X.509 och sedan svara på utmaningen proof-of-possession från IoT Hub.

Grunden för förtroende ligger i att skydda privata nycklar, inklusive privata enhetsnycklar. Därför kan vi inte nog betona vikten av säkra kiselchips i form av maskinvarusäkerhetsmoduler (HSM) för att skydda privata nycklar för enheter, och det övergripande bästa sättet att aldrig dela några privata nycklar, som en fabrik som anförtror en annan med sin privata nyckel.

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.