X.509-certifikatattestering

  • Artikel

Den här artikeln beskriver de begrepp som ingår när enheter etableras med X.509-certifikatattestering i Device Provisioning Service (DPS). Den här artikeln är relevant för alla personer som är involverade i att förbereda en enhet för distribution.

X.509-certifikat kan lagras i en maskinvarusäkerhetsmodul HSM.

Dricks

Vi rekommenderar starkt att du använder en HSM med enheter för att lagra hemligheter på ett säkert sätt, till exempel X.509-certifikatet, på dina enheter i produktion.

Etablera enheter med X.509-certifikat

Att använda X.509-certifikat som en attesteringsmekanism är ett utmärkt sätt att skala produktionen och förenkla enhetsetablering. X.509-certifikat ordnas vanligtvis i en certifikatkedja med förtroende där varje certifikat i kedjan signeras av den privata nyckeln för nästa högre certifikat och så vidare och avslutas i ett självsignerat rotcertifikat. Det här arrangemanget upprättar en delegerad förtroendekedja från rotcertifikatet som genereras av en betrodd certifikatutfärdare (CA) ned via varje mellanliggande certifikat till det slutliga certifikatet som är installerat på en enhet. Mer information finns i Enhetsautentisering med X.509 CA-certifikat.

Ofta representerar certifikatkedjan en logisk eller fysisk hierarki som är associerad med enheter. En tillverkare kan till exempel skapa följande certifikathierarki:

  • Ett självsignerat rotcertifikatutfärdarcertifikat startar certifikatkedjan.
  • Rotcertifikatet genererar ett unikt mellanliggande CA-certifikat för varje fabrik.
  • Varje fabriks certifikat genererar ett unikt mellanliggande CA-certifikat för varje produktionsrad i fabriken.
  • Produktionslinjecertifikatet genererar ett unikt enhetscertifikat (slutentitet) för varje enhet som tillverkas på raden.

Mer information finns i Konceptuell förståelse av X.509 CA-certifikat i IoT-branschen.

Rotcertifikat

Ett rotcertifikat är ett självsignerat X.509-certifikat som representerar en certifikatutfärdare (CA). Det är certifikatkedjans slutpunkter eller förtroendeankare. Rotcertifikat kan utfärdas själv av en organisation eller köpas från en rotcertifikatutfärdare. Rotcertifikatet kan också kallas för ett rotcertifikatutfärdarcertifikat.

Mellanliggande certifikat

Ett mellanliggande certifikat är ett X.509-certifikat som har signerats av rotcertifikatet (eller av ett annat mellanliggande certifikat med rotcertifikatet i kedjan) och som även kan signera nya certifikat. Det sista mellanliggande certifikatet i en kedja signerar lövcertifikatet. Ett mellanliggande certifikat kan också kallas för ett mellanliggande CA-certifikat.

Mellanliggande certifikat används på olika sätt. Mellanliggande certifikat kan till exempel användas för att gruppera enheter efter produktlinjer, kunder som köper enheter, företagsdivisioner eller fabriker.

Anta att Contoso är ett stort företag med en egen PKI (Public Key Infrastructure) med rotcertifikatet med namnet ContosoRootCert. Varje dotterbolag till Contoso har ett eget mellanliggande certifikat som är signerat av ContosoRootCert. Varje dotterbolag använder sitt mellanliggande certifikat för att signera sina lövcertifikat för varje enhet. I det här scenariot kan Contoso använda en enda DPS-instans där ContosoRootCert är ett verifierat certifikat. De kan ha en registreringsgrupp för varje dotterbolag. På så sätt behöver varje enskilt dotterbolag inte bekymra sig om att verifiera certifikat.

Slutentitetscertifikat för "löv"

Ett lövcertifikat, eller slutentitetscertifikat, identifierar en certifikatinnehavare. Den har rotcertifikatet i sin certifikatkedja och noll eller fler mellanliggande certifikat. Ett lövcertifikat används inte för att signera andra certifikat. Den identifierar en enhet unikt för etableringstjänsten och kallas ibland för ett enhetscertifikat. Under autentiseringen använder en enhet den privata nyckeln som är associerad med certifikatet för att svara på ett bevis på innehavsutmaning från tjänsten.

Lövcertifikat som används med enskilda registreringsposter måste ha ämnesnamnet (CN) inställt på registrerings-ID:t. Registrerings-ID:t identifierar enhetsregistreringen med DPS och måste vara unikt för DPS-instansen (ID-omfånget) där enheten registreras.

För registreringsgrupper anger ämnesnamnet (CN) det enhets-ID som är registrerat med IoT Hub. Enhets-ID visas i registreringsposterna för den autentiserade enheten i registreringsgruppen. För enskilda registreringar kan enhets-ID anges i registreringsposten. Om den inte anges i registreringsposten används ämnesnamnet (CN).

Mer information finns i Autentisera enheter som är signerade med X.509 CA-certifikat.

Kontrollera enhetsåtkomst med X.509-certifikat

Etableringstjänsten exponerar två registreringstyper som du kan använda för att styra enhetsåtkomst med X.509-attesteringsmekanismen:

  • Enskilda registreringsposter konfigureras med enhetscertifikatet som är associerat med en specifik enhet. Dessa poster styr registreringar för specifika enheter.
  • Registreringsgruppposter är associerade med ett specifikt mellanliggande certifikat eller rotcertifikatutfärdarcertifikat. Dessa poster styr registreringar för alla enheter som har det mellanliggande certifikatet eller rotcertifikatet i certifikatkedjan.

Ett certifikat kan bara anges i en registreringspost i DPS-instansen.

Ömsesidigt TLS-stöd

När DPS-registreringar konfigureras för X.509-attestering stöds ömsesidig TLS (mTLS) av DPS.

Krav för DPS-enhetskedjan

När en enhet försöker registrera sig via DPS med hjälp av en registreringsgrupp måste enheten skicka certifikatkedjan från lövcertifikatet till ett verifierat certifikat. Annars misslyckas autentiseringen.

Om till exempel bara rotcertifikatet verifieras och ett mellanliggande certifikat laddas upp till registreringsgruppen bör enheten visa certifikatkedjan från lövcertifikatet hela vägen till det verifierade rotcertifikatet. Den här certifikatkedjan skulle innehålla mellanliggande certifikat däremellan. Autentiseringen misslyckas om DPS inte kan passera certifikatkedjan till ett verifierat certifikat.

Tänk dig till exempel ett företag som använder följande enhetskedja för en enhet.

Diagram som visar en exempelkedja för enhetscertifikat.

I det här exemplet verifieras rotcertifikatet med DPS och intermediate2 certifikatet laddas upp i registreringsgruppen.

Diagram som visar rotcertifikaten och mellanliggande 2 certifikat som uppladdade till DPS.

Om enheten bara skickar följande enhetskedja under etableringen misslyckas autentiseringen. Eftersom DPS inte kan försöka autentisering förutsatt att certifikatet är intermediate1 giltigt.

Diagram som visar en certifikatkedja som misslyckas med autentisering eftersom den inte kedjas till roten.

Om enheten skickar hela enhetskedjan enligt följande under etableringen kan DPS försöka autentisering av enheten.

Diagram som visar en lyckad enhetscertifikatkedja.

DPS-ordning för åtgärder med certifikat

När en enhet ansluter till etableringstjänsten går tjänsten i sin certifikatkedja från och med enhetscertifikatet (lövcertifikatet) och letar efter en motsvarande registreringspost. Den använder den första posten som den hittar i kedjan för att avgöra om enheten ska etableras. Om det finns en enskild registrering för enhetscertifikatet gäller etableringstjänsten den posten. Om det inte finns någon enskild registrering för enheten letar tjänsten efter en registreringsgrupp som motsvarar det första mellanliggande certifikatet. Om den hittar en, tillämpas den posten. Annars letar den efter en registreringsgrupp för nästa mellanliggande certifikat, och så vidare, ned i kedjan till roten.

Tjänsten tillämpar den första posten som den hittar, så att:

  • Om den första registreringsposten som hittas är aktiverad etablerar tjänsten enheten.
  • Om den första registreringsposten som hittas är inaktiverad etablerar tjänsten inte enheten.
  • Om ingen registreringspost hittas för något av certifikaten i enhetens certifikatkedja etablerar tjänsten inte enheten.

Varje certifikat i en enhets certifikatkedja kan anges i en registreringspost, men det kan bara anges i en post i DPS-instansen.

Den här mekanismen och den hierarkiska strukturen för certifikatkedjor ger kraftfull flexibilitet i hur du kan styra åtkomsten för enskilda enheter och grupper av enheter. Tänk dig till exempel fem enheter med följande certifikatkedjor:

  • Enhet 1: rotcertifikat –> certifikat A –> enhets 1-certifikat
  • Enhet 2: rotcertifikat –> certifikat A –> enhets 2-certifikat
  • Enhet 3: rotcertifikat –> certifikat A –> enhets 3-certifikat
  • Enhet 4: rotcertifikat –> certifikat B –> enhets 4-certifikat
  • Enhet 5: rotcertifikat –> certifikat B –> enhets 5-certifikat

Inledningsvis kan du skapa en enda aktiverad gruppregistreringspost för rotcertifikatet för att aktivera åtkomst för alla fem enheterna. Om certifikat B senare komprometteras kan du skapa en inaktiverad registreringsgrupppost för certifikat B för att förhindra att enhet 4 och enhet 5 registreras. Om enheten 3 fortfarande blir komprometterad senare kan du skapa en inaktiverad enskild registreringspost för certifikatet. Detta återkallar åtkomsten för enhet 3, men tillåter fortfarande att enhet 1 och enhet 2 registreras.