TPM-attestering
IoT Hub Device Provisioning Service är en hjälptjänst för IoT Hub som du använder för att konfigurera zero-touch-enhetsetablering till en angiven IoT-hubb. Med Device Provisioning Service kan du etablera miljontals enheter på ett säkert sätt.
Den här artikeln beskriver identitetsattesteringsprocessen när du använder en TPM (Trusted Platform Module). En TPM är en typ av maskinvarusäkerhetsmodul (HSM). Den här artikeln förutsätter att du använder en diskret, inbyggd programvara eller integrerad TPM. Programvaruemulerade TPM:er är väl lämpade för prototyper eller testning, men de ger inte samma säkerhetsnivå som diskreta, inbyggda programvara eller integrerade TPM:er. Vi rekommenderar inte att du använder programvaru-TPM:er i produktion. Mer information om typer av TPM finns i En kort introduktion till TPM.
Den här artikeln är endast relevant för enheter som använder TPM 2.0 med HMAC-nyckelstöd och deras bekräftelsenycklar. Det är inte för enheter som använder X.509-certifikat för autentisering. TPM är en branschomfattande ISO-standard från gruppen betrodd databehandling och du kan läsa mer om TPM i den fullständiga TPM 2.0-specifikationen eller ISO/IEC 11889-specifikationen. Den här artikeln förutsätter också att du är bekant med offentliga och privata nyckelpar och hur de används för kryptering.
Enhets-SDK:er för Device Provisioning Service hanterar allt som beskrivs i den här artikeln åt dig. Du behöver inte implementera något ytterligare om du använder SDK:erna på dina enheter. Den här artikeln hjälper dig att förstå konceptuellt vad som händer med ditt TPM-säkerhetschip när enheten etablerar och varför den är så säker.
Översikt
TPM:er använder något som kallas bekräftelsenyckeln (EK) som säker rot för förtroende. EK är unikt för TPM och om du ändrar den ändras enheten till en ny.
Det finns en annan typ av nyckel som TPM:er har, kallad lagringsrotnyckeln (SRK). En SRK kan genereras av TPM:s ägare när den har ägarskapet för TPM. Ägarskapet för TPM är det TPM-specifika sättet att säga "någon anger ett lösenord på HSM". Om en TPM-enhet säljs till en ny ägare kan den nya ägaren ta över ägarskapet för TPM för att generera en ny SRK. Den nya SRK-generationen säkerställer att den tidigare ägaren inte kan använda TPM. Eftersom SRK är unikt för TPM:ns ägare kan SRK användas för att försegla data i själva TPM:n för ägaren. SRK tillhandahåller en sandbox-miljö där ägaren kan lagra sina nycklar och ger åtkomstreaktivering om enheten eller TPM säljs. Det är som att flytta in i ett nytt hus: att ta ägarskap är att byta lås på dörrarna och förstöra alla möbler som lämnats av de tidigare ägarna (SRK), men du kan inte ändra adressen till huset (EK).
När en enhet har konfigurerats och är redo att användas har den både en EK och en SRK tillgänglig för användning.
En anteckning om ägarskap för TPM: Ägarskap för en TPM beror på många saker, inklusive TPM-tillverkare, den uppsättning TPM-verktyg som används och enhetens operativsystem. Följ anvisningarna som är relevanta för systemet för att ta över ägarskapet.
Device Provisioning Service använder den offentliga delen av EK (EK_pub) för att identifiera och registrera enheter. Enhetsleverantören kan läsa EK_pub under tillverkningen eller den slutliga testningen och ladda upp EK_pub till etableringstjänsten så att enheten identifieras när den ansluter till etableringen. Device Provisioning Service kontrollerar inte SRK eller ägare, så "rensa" TPM raderar kunddata, men EK (och andra leverantörsdata) bevaras och enheten kommer fortfarande att identifieras av Device Provisioning Service när den ansluter till etableringen.
Detaljerad attesteringsprocess
När en enhet med en TPM först ansluter till enhetsetableringstjänsten kontrollerar tjänsten först den angivna EK_pub mot EK_pub som lagras i registreringslistan. Om EK_pubs inte matchar tillåts inte enheten att etableras. Om EK_pubs matchar kräver tjänsten att enheten bevisar ägarskapet för den privata delen av EK via en nonce-utmaning, vilket är en säker utmaning som används för att bevisa identitet. Device Provisioning Service genererar en nonce och krypterar den sedan med SRK och sedan EK_pub, som båda tillhandahålls av enheten under det första registreringsanropet. TPM håller alltid den privata delen av EK säker. Detta förhindrar förfalskning och säkerställer att SAS-token etableras på ett säkert sätt till auktoriserade enheter.
Vi går igenom attesteringsprocessen i detalj.
Enheten begär en IoT Hub-tilldelning
Först ansluter enheten till enhetsetableringstjänsten och begär att etableras. På så sätt ger enheten tjänsten sitt registrerings-ID, ett ID-omfång och EK_pub och SRK_pub från TPM. Tjänsten skickar tillbaka den krypterade noncen till enheten och ber enheten att dekryptera nonce och använda den för att signera en SAS-token för att ansluta igen och slutföra etableringen.
Nonce-utmaning
Enheten tar nonce och använder de privata delarna av EK och SRK för att dekryptera nonce till TPM; ordningen för nonce-kryptering delegerar förtroende från EK, som är oföränderlig, till SRK, som kan ändras om en ny ägare tar ägarskapet för TPM.
Verifiera nonce och ta emot autentiseringsuppgifter
Enheten kan sedan signera en SAS-token med den dekrypterade nonce och återupprätta en anslutning till Device Provisioning Service med hjälp av den signerade SAS-token. När Nonce-utmaningen har slutförts tillåter tjänsten att enheten etableras.
Nästa steg
Nu ansluter enheten till IoT Hub och du är säker på att enheternas nycklar lagras på ett säkert sätt. Nu när du vet hur Device Provisioning Service på ett säkert sätt verifierar en enhets identitet med hjälp av TPM kan du läsa följande artiklar om du vill veta mer: