Så här används certifikat i Azure IoT Edge

Gäller för: IoT Edge 1.5

IoT Edge använder olika typer av certifikat för olika syften. Den här artikeln beskriver hur IoT Edge använder certifikat med Azure IoT Hub- och IoT Edge-gatewayscenarier.

Sammanfattning

IoT Edge använder certifikat i dessa kärnscenarier. Använd länkarna om du vill veta mer om varje scenario.

Förutsättningar

• Du behöver en grundläggande förståelse för kryptering av offentliga nycklar, nyckelpar och hur en offentlig nyckel och privat nyckel kan kryptera eller dekryptera data. Mer information om hur IoT Edge använder kryptering med offentliga nycklar finns i Förstå kryptering av offentliga nycklar och X.509 Offentlig nyckelinfrastruktur.
• Du behöver en grundläggande förståelse för hur IoT Edge relaterar till IoT Hub. Mer information finns i Förstå Azure IoT Edge-körningen och dess arkitektur.

Scenario med en enskild enhet

Tänk dig ett scenario där en IoT Edge-enhet med namnet EdgeGateway ansluter till en Azure IoT Hub med namnet ContosoIotHub för att lära dig mer om IoT Edge-certifikatbegrepp. I det här exemplet använder all autentisering X.509-certifikatautentisering i stället för symmetriska nycklar. För att skapa förtroende för det här scenariot måste vi garantera att IoT Hub- och IoT Edge-enheten är äkta: "Är den här enheten äkta och giltig?" och "Är identiteten för IoT Hub korrekt?". Här är en bild av scenariot:

Den här artikeln förklarar svaren på varje fråga och expanderar sedan exemplet i senare avsnitt.

Enheten verifierar IoT Hub-identitet

Hur kontrollerar EdgeGateway att det pratar med den riktiga ContosoIotHub? När EdgeGateway pratar med molnet ansluter den till slutpunkten ContosoIoTHub.Azure-devices.NET. För att se till att slutpunkten är giltig behöver IoT Edge ContosoIoTHub för att visa identifiering (ID). ID:t måste utfärdas av en utfärdare som EdgeGateway litar på. För att verifiera IoT Hub-identiteten använder IoT Edge och IoT Hub TLS-handskakningsprotokollet för att kontrollera IoT Hubs serveridentitet. Följande diagram visar en TLS-handskakning. Vissa detaljer utelämnas för att hålla det enkelt. Mer information om TLS-handskakningsprotokollet finns i TLS-handskakning på Wikipedia.

I det här sammanhanget behöver du inte känna till den exakta informationen om den kryptografiska algoritmen. Det viktigaste är att algoritmen kontrollerar att servern har den privata nyckel som är kopplad till dess offentliga nyckel. Den här kontrollen bevisar att certifikatpresentatören inte kopierade eller stal den. Tänk på ett foto-ID där ditt ansikte matchar fotot. Om någon stjäl ditt ID kan de inte använda det eftersom ditt ansikte är unikt. För kryptografiska nycklar är nyckelparet relaterat och unikt. I stället för att matcha ett ansikte med ett foto-ID använder den kryptografiska algoritmen nyckelparet för att verifiera identiteten.

I vårt scenario visar ContosoIotHub följande certifikatkedja:

Rotcertifikatutfärdare (CA) är Baltimore CyberTrust Root-certifikatet . DigiCert signerar det här rotcertifikatet, som är allmänt betrott och lagras i många operativsystem. Till exempel inkluderar både Ubuntu och Windows det i standardcertifikatarkivet.

Windows-certifikatarkiv:

Ubuntu-certifikatarkiv:

När en enhet söker efter Baltimore CyberTrust Root-certifikatet finns den redan i operativsystemet. Eftersom certifikatkedjan från ContosoIotHub signeras av en rotcertifikatutfärdare som operativsystemet litar på från EdgeGateway-perspektivet är certifikatet tillförlitligt. Det här certifikatet kallas för IoT Hub-servercertifikatet. Mer information om IoT Hub-servercertifikatet finns i TLS-stöd (Transport Layer Security) i IoT Hub.

Sammanfattningsvis kan EdgeGateway verifiera och lita på ContosoIotHubs identitet eftersom:

• ContosoIotHub presenterar sitt IoT Hub-servercertifikat
• Servercertifikatet är betrott i OS-certifikatarkivet
• Data som krypteras med ContosoIotHubs offentliga nyckel kan dekrypteras av ContosoIotHub, vilket bevisar dess innehav av den privata nyckeln

IoT Hub verifierar IoT Edge-enhetsidentitet

Hur kontrollerar ContosoIotHub att det kommunicerar med EdgeGateway? Eftersom IoT Hub stöder ömsesidig TLS (mTLS) kontrollerar den EdgeGateways certifikat under en klientautentiserad TLS-handskakning. För enkelhetens skull hoppar vi över några steg i följande diagram.

I det här fallet tillhandahåller EdgeGateway sitt IoT Edge-enhetsidentitetscertifikat. Från ContosoIotHubs perspektiv, kontrollerar den att fingeravtrycket för det angivna certifikatet stämmer överens med dess register, och att EdgeGateway har den privata nyckeln kopplad till det certifikat som diskeras. När du etablerar en IoT Edge-enhet i IoT Hub anger du ett tumavtryck. IoT Hub använder tumavtrycket för att verifiera certifikatet.

Använd till exempel följande kommando för att hämta identitetscertifikatets tumavtryck på EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

Kommandot matar ut certifikatets SHA256-tumavtryck:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Om du visar SHA256-tumavtrycksvärdet för EdgeGateway-enheten som är registrerad i IoT Hub ser du att den matchar tumavtrycket på EdgeGateway:

Sammanfattningsvis litar ContosoIotHub på EdgeGateway eftersom EdgeGateway visar ett giltigt IoT Edge-enhetsidentitetscertifikat med ett tumavtryck som matchar det som registrerats i IoT Hub.

Mer information om processen för att skapa certifikat finns i Skapa och etablera en IoT Edge-enhet i Linux med X.509-certifikat.

Certifikatanvändning för modulidentitetsåtgärder

I diagrammen för certifikatverifiering kan det se ut som om IoT Edge bara använder certifikatet för att prata med IoT Hub. IoT Edge har flera moduler. IoT Edge använder certifikatet för att hantera modulidentiteter för moduler som skickar meddelanden. Modulerna använder inte certifikatet för att autentisera till IoT Hub, men använder SAS-nycklar som härletts från den privata nyckel som IoT Edge-modulens körning genererar. Dessa SAS-nycklar ändras inte även om enhetsidentitetscertifikatet upphör att gälla. Om certifikatet upphör att gälla körs edgeHub fortfarande, men endast modulidentitetsåtgärderna misslyckas.

Interaktionen mellan moduler och IoT Hub är säker eftersom SAS-nyckeln härleds från en hemlighet, och IoT Edge hanterar nyckeln utan risk för mänsklig inblandning.

Scenario med kapslad enhetshierarki med IoT Edge som gateway

Nu förstår du en enkel interaktion mellan IoT Edge och IoT Hub. Men IoT Edge kan också fungera som en gateway för underordnade enheter eller andra IoT Edge-enheter. Dessa kommunikationskanaler måste vara krypterade och betrodda. På grund av den extra komplexiteten ska vi expandera exempelscenariot till att omfatta en nedströmsenhet.

Vi lägger till en vanlig IoT-enhet med namnet TempSensor, som ansluter till den överordnade IoT Edge-enheten EdgeGateway som ansluter till IoT Hub ContosoIotHub. Som tidigare använder all autentisering X.509-certifikatautentisering. Det här scenariot väcker två frågor: "Är TempSensor-enheten legitim?" och "Är EdgeGateways identitet korrekt?". Scenariot illustreras här:

Enheten verifierar gatewayidentiteten

Hur verifierar TempSensor att det kommunicerar med den äkta EdgeGateway? När TempSensor vill prata med EdgeGateway behöver TempSensor EdgeGateway för att visa ett ID. ID:t måste utfärdas av en utfärdare som TempSensor litar på.

Flödet är detsamma som när EdgeGateway pratar med ContosoIotHub. TempSensor och EdgeGateway använder TLS-handskakningsprotokollet för att verifiera EdgeGateways identitet. Det finns två viktiga detaljer:

• Värdnamnsspecifikitet: Certifikatet som visas av EdgeGateway måste utfärdas till samma värdnamn (domän eller IP-adress) som TempSensor använder för att ansluta till EdgeGateway.
• Självsignerad rotcertifikatutfärdarspecifikitet: Certifikatkedjan som presenteras av EdgeGateway finns troligen inte i operativsystemets betrodda standardrotarkiv.

För att förstå informationen ska vi först undersöka certifikatkedjan som presenteras av EdgeGateway.

Värdnamnsspecifikitet

Certifikatets gemensamma namn CN = edgegateway.local visas överst i kedjan. edgegateway.local är edgeHubs vanliga namn på servercertifikatet. edgegateway.local är också värdnamnet för EdgeGateway i det lokala nätverket (LAN eller VNet) där TempSensor och EdgeGateway är anslutna. Det kan vara en privat IP-adress som 192.168.1.23 eller ett fullständigt domännamn (FQDN) som diagrammet. EdgeHub-servercertifikatet genereras med hjälp av parametern värdnamn som definierats i filen IoT Edge config.toml. Blanda inte ihop edgeHub-servercertifikatet med Edge CA-certifikatet. Mer information om hur du hanterar Edge CA-certifikat finns i Hantera IoT Edge-certifikat.

När TempSensor ansluter till EdgeGateway använder TempSensor värdnamnet edgegateway.local för att ansluta till EdgeGateway. TempSensor kontrollerar certifikatet som visas av EdgeGateway och verifierar att certifikatets gemensamma namn är edgegateway.local. Om certifikatets gemensamma namn är annorlunda avvisar TempSensor anslutningen.

Varför behöver EdgeGateway få information om sitt eget värdnamn?

EdgeGateway har inget tillförlitligt sätt att veta hur andra klienter i nätverket kan ansluta till det. I ett privat nätverk kan det till exempel finnas DHCP-servrar eller mDNS-tjänster som listar EdgeGateway som 10.0.0.2 eller example-mdns-hostname.local. Men vissa nätverk kan ha DNS-servrar som mappar edgegateway.local till EdgeGateways IP-adress 10.0.0.2.

För att lösa problemet använder IoT Edge det konfigurerade värdnamnsvärdet i config.toml och skapar ett servercertifikat för det. När en begäran kommer till edgeHub-modulen visas certifikatet med rätt namn på certifikatet (CN).

Varför skapar IoT Edge certifikat?

Observera i exemplet att det finns en iotedged arbetsbelastning ca edgegateway i certifikatkedjan. Det är certifikatutfärdare (CA) som finns på IoT Edge-enheten som kallas Edge CA (tidigare känd som Enhetscertifikatutfärdare i version 1.1). Precis som Baltimore CyberTrust-rotcertifikatutfärdare i det tidigare exemplet kan Edge CA utfärda andra certifikat. Viktigast av allt, och även i det här exemplet, utfärdar det servercertifikatet till edgeHub-modulen . Men det kan också utfärda certifikat till andra moduler som körs på IoT Edge-enheten.

Är det inte farligt att ha ett utfärdarcertifikat på enheten?

Edge CA är utformat för att möjliggöra lösningar med begränsad, otillförlitlig, dyr eller frånvarande anslutning men har samtidigt strikta regler eller principer för certifikatförnyelser. Utan Edge CA kan IoT Edge – och i synnerhet edgeHub – inte fungera.

Så här skyddar du Edge CA i produktion:

• Placera den privata EdgeCA-nyckeln i en betrodd plattformsmodul (TPM), helst på ett sätt där den privata nyckeln genereras tillfälliga och aldrig lämnar TPM.
• Använd en PKI (Public Key Infrastructure) som Edge CA samlar in. Detta ger möjlighet att inaktivera eller neka förnyelse av komprometterade certifikat. PKI kan hanteras av kund-IT om de vet hur (lägre kostnad) eller via en kommersiell PKI-provider.

Självsignerad rotcertifikatutfärdarspecifikitet

EdgeHub-modulen är en viktig komponent som utgör IoT Edge genom att hantera all inkommande trafik. I det här exemplet använder den ett certifikat utfärdat av Edge CA, som i sin tur utfärdas av en självsignerad rotcertifikatutfärdare. Eftersom rotcertifikatutfärdare inte är betrodd av operativsystemet är det enda sättet som TempSensor skulle lita på det att installera CA-certifikatet på enheten. Detta kallas även för scenariot med förtroendepaket , där du behöver distribuera roten till klienter som behöver lita på kedjan. Scenariot med säkerhetspaket kan vara besvärligt eftersom du behöver åtkomst till enheten och installera certifikatet. Att installera certifikatet kräver planering. Det kan göras med skript, läggs till under tillverkning eller förinstalleras i OS-avbildningen.

Genom att tillämpa alla dessa begrepp kan TempSensor kontrollera att det kommunicerar med den äkta EdgeGateway eftersom det visade ett certifikat som matchade adressen och certifikatet signeras av en betrodd rot.

För att verifiera certifikatkedjan kan du använda openssl på TempSensor-enheten. I det här exemplet ser du att värdnamnet för anslutningen matchar CN för djup 0-certifikatet och att rotcertifikatutfärdarcertifikatutfärdartypen matchar.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Mer information om openssl kommandot finns i OpenSSL-dokumentationen.

Du kan också kontrollera certifikaten där de lagras som standard i /var/lib/aziot/certd/certs. Du hittar Edge CA-certifikat , enhetsidentitetscertifikat och modulcertifikat i katalogen. Du kan använda openssl x509 kommandon för att inspektera certifikaten. Till exempel:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

Sammanfattningsvis kan TempSensor lita på EdgeGateway eftersom:

• EdgeHub-modulen visade ett giltigt IoT Edge-modulservercertifikat för edgegateway.local
• Certifikatet utfärdas av Edge CA som utfärdas av my_private_root_CA
• Den här privata rotcertifikatutfärdare lagras också i TempSensor som betrodd rotcertifikatutfärdare tidigare
• Kryptografiska algoritmer kontrollerar att ägarskaps- och utfärdandekedjan kan vara betrodd

Certifikat för andra moduler

Andra moduler kan hämta servercertifikat som utfärdats av Edge CA. Till exempel en Grafana-modul som har ett webbgränssnitt. Det kan också hämta ett certifikat från Edge CA. Moduler behandlas som underordnade enheter som finns i containern. Att kunna hämta ett certifikat från IoT Edge-modulens körning är dock ett särskilt privilegium. Moduler anropar arbetsbelastnings-API:et för att ta emot servercertifikatet som är kopplat till den konfigurerade Edge CA:n.

Gateway verifierar enhetsidentitet

Hur kontrollerar EdgeGateway att det kommunicerar med TempSensor? EdgeGateway använder TLS-klientautentisering för att autentisera TempSensor.

Sekvensen liknar ContosoIotHub som kontrollerar en enhet. Men i ett gatewayscenario förlitar sig EdgeGateway på ContosoIotHub som auktoritativ källa för certifikatpost. EdgeGateway behåller också en offlinekopia eller cache om det inte finns någon anslutning till molnet.

Sammanfattningsvis kan EdgeGateway lita på TempSensor eftersom:

• TempSensor visar ett giltigt IoT-enhetsidentitetscertifikat för dess namn
• Identitetscertifikatets tumavtryck matchar det som laddats upp till ContosoIotHub
• Kryptografiska algoritmer kontrollerar att ägarskaps- och utfärdandekedjan kan vara betrodd

Var du kan hämta certifikaten och hanteringen

I de flesta fall anger du egna certifikat eller använder automatiskt genererade certifikat. Till exempel genereras Edge CA och edgeHub-certifikatet automatiskt.

Det bästa sättet är dock att konfigurera dina enheter så att de använder en EST-server (Enrollment over Secure Transport) för att hantera x509-certifikat. Med en EST-server kan du undvika att hantera och installera certifikat manuellt på enheter. Mer information om hur du använder en EST-server finns i Konfigurera registrering via säker transportserver för Azure IoT Edge.

Du kan också använda certifikat för att autentisera till EST-servern. Dessa certifikat autentiseras med EST-servrar för att utfärda andra certifikat. Certifikattjänsten använder ett bootstrap-certifikat för att autentisera med en EST-server. Bootstrap-certifikatet är långlivat. När den först autentiseras begär certifikattjänsten ett identitetscertifikat från EST-servern. Identitetscertifikatet används i framtida EST-begäranden till samma server.

Om du inte kan använda en EST-server kan du begära certifikat från PKI-providern. Hantera certifikatfilerna manuellt i IoT Hub och dina IoT Edge-enheter. Mer information finns i Hantera certifikat på en IoT Edge-enhet.

Skapa testcertifikat för konceptbevisutveckling. Mer information finns i Skapa democertifikat för att testa IoT Edge-enhetsfunktioner.

Certifikat i IoT

Certifikatutfärdare

En certifikatutfärdare utfärdar digitala certifikat. Certifikatutfärdaren fungerar som en betrodd tredje part mellan certifikatägaren och certifikatmottagaren. Ett digitalt certifikat bevisar att mottagaren äger en offentlig nyckel. Förtroendekedjan för certifikat börjar med ett rotcertifikat, som är grunden för förtroende för alla certifikat som utfärdaren utfärdar. Rotcertifikatets ägare kan utfärda ytterligare mellanliggande certifikat (underordnade enhetscertifikat).

Rotcertifikatutfärdarcertifikat

Ett rotcertifikat är grunden för förtroendet i processen. I produktion köper du vanligtvis detta CA-certifikat från en betrodd certifikatutfärdare som Baltimore, Verisign eller DigiCert. Om du styr alla enheter som ansluter till dina IoT Edge-enheter kan du använda en företagscertifikatutfärdare. I båda fallen använder certifikatkedjan från IoT Edge till IoT Hub rot-CA-certifikatet. Underordnade IoT-enheter måste lita på rotcertifikatet. Lagra rot-CA-certifikatet i den betrodda rotcertifikatutfärdarens lagring eller ange dess information i programkoden.

Mellanliggande certifikat

I en typisk tillverkningsprocess för säkra enheter använder tillverkarna sällan rot-CA-certifikat direkt på grund av risken för läckage eller exponering av certifikaten. Rotcertifikatutfärdarcertifikatet skapar och signerar ett eller flera mellanliggande CA-certifikat digitalt. Det kan finnas en eller en kedja med mellanliggande certifikat. Scenarier som kräver en kedja med mellanliggande certifikat är:

• En hierarki med avdelningar inom en tillverkare
• Flera företag deltar seriellt i produktionen av en enhet
• En kund som köper en certifikatutfärdare för rotcertifikat och skapar ett signeringscertifikat för tillverkaren att använda för att signera enheter åt kunden.

Tillverkaren använder ett mellanliggande CA-certifikat i kedjan för att signera Edge CA-certifikatet som är placerat på slutenheten. Tillverkningsanläggningen skyddar noggrant dessa mellanliggande certifikat. Strikta fysiska och elektroniska processer styr deras användning.

Nästa steg

• Mer information om hur du installerar certifikat på en IoT Edge-enhet och refererar till dem från konfigurationsfilen finns i Hantera certifikat på en IoT Edge-enhet.
• Förstå Azure IoT Edge-moduler
• Konfigurera en IoT Edge-enhet till att fungera som en transparent gateway
• Den här artikeln beskriver hur certifikat används för att skydda anslutningar mellan de olika komponenterna på en IoT Edge-enhet eller mellan en IoT Edge-enhet och eventuella underordnade enheter. Du kan också använda certifikat för att autentisera din IoT Edge-enhet till IoT Hub. Dessa autentiseringscertifikat skiljer sig åt och beskrivs inte i den här artikeln. Mer information om hur du autentiserar enheten med certifikat finns i Skapa och etablera en IoT Edge-enhet med X.509-certifikat.