TPM-attestering
Den här artikeln beskriver de begrepp som ingår när enheter etableras med hjälp av TPM-attestering (Trusted Platform Module) 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.
En TPM (Trusted Platform Module) ä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.
Den här artikeln är endast relevant för enheter som använder TPM 2.0 med HMAC-nyckelstöd och deras bekräftelsenycklar. 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 TPM-stöd 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.
TPM:er har en annan typ av nyckel som kallas 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 har den både en EK och en SRK tillgänglig för användning.
De specifika steg som ingår i ägarskapet för en TPM varierar beroende på tillverkare, vilken uppsättning TPM-verktyg som används och enhetens operativsystem.
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.
Attesteringsprocess
När en enhet med en TPM 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.
