Sammendrag

  • Sikker provisjonering gir hver enhet en unik identitet ved første oppstart.
  • Secure elements (ATECC608, NXP EdgeLock) holder private nøkler som aldri forlater brikken.
  • AWS IoT, Azure DPS og egendefinert PKI støtter alle innrullering på produksjonssiden.
  • Det er på produksjonslinjen dette enten fungerer riktig eller skaper feil ute i felten.

Hvorfor sikker provisjonering hører hjemme i produksjonen

En tilkoblet enhet som leveres uten identitet, må provisjoneres i felt. Feltprovisjonering betyr et manuelt trinn (eller en sårbar automatisk innrullering) ved installasjon. Begge skaper driftsmessig friksjon og sikkerhetsmessig eksponering.

Provisjonering på produksjonssiden gir enheten en unik kryptografisk identitet før den leveres. Enheten starter, autentiserer seg og rulles inn uten manuelt inngrep.

Secure elements

Microchip ATECC608 og NXP EdgeLock er vanlige secure elements for IoT. Begge støtter:

  • Generering av privat ECC-nøkkel inne i brikken (nøkkelen forlater den aldri)
  • Signering og verifisering av sertifikater
  • Tellerbasert replay-beskyttelse
  • Tamper-evident oppførsel

Produksjonslinjen genererer en nøkkel inne i secure element, signerer et sertifikat mot rot-CA, skriver sertifikatet til enheten og logger den offentlige nøkkelen mot serienummeret.

Innrullering av X.509-sertifikat

X.509 er standardformatet for sertifikater. Innrullering på produksjonssiden følger vanligvis dette mønsteret:

  1. Secure element genererer ECC-nøkkelpar (privat nøkkel låst i brikken)
  2. Produksjonssystemet leser offentlig nøkkel
  3. Produksjonssystemet signerer sertifikatet med HSM-basert rot-CA
  4. Sertifikatet skrives tilbake til enheten
  5. Offentlig nøkkel og sertifikatfingeravtrykk logges mot serienummeret

Rot-CA-ens private nøkkel berører aldri produksjonslinjen. Den ligger i en HSM i et kontrollert miljø.

AWS IoT og Azure DPS

AWS IoT støtter Just-in-Time Provisioning (JITP) og Multi-Account Registration. Azure Device Provisioning Service (DPS) støtter X.509-attestering, Trusted Platform Module (TPM)-attestering og attestering med symmetrisk nøkkel.

Begge gjør at produksjonslinjen kan forhåndsregistrere enheter slik at de rulles inn automatisk ved første skytilkobling. Arbeidsflyten på produksjonssiden:

  1. Enheten provisjoneres med X.509-sertifikat
  2. Enhetens sertifikatfingeravtrykk registreres i sky-DPS
  3. Enheten starter i felt, presenterer sertifikatet og rulles inn automatisk
  4. Skyen tilordner enheten til riktig gruppe og laster ned konfigurasjon

Egen PKI følger samme mønster med intern infrastruktur i stedet for AWS eller Azure.

En arbeidsflyt på produksjonssiden som fungerer

  • HSM-basert rot-CA i et kontrollert miljø, tilgjengelig via et signerings-API
  • Nøkkelgenerering per enhet inne i secure element på linjen
  • Sertifikatsignering via API-kall (ingen nøkkelmateriale eksponeres)
  • Forhåndsregistrering i sky-DPS som del av provisjoneringstrinnet
  • Innrulleringspost per enhet logget i produksjonsdatabasen
  • Eventuell forvaltning av tilbaketrekkingsliste for utgåtte eller tapte enheter

Vanlige fallgruver

  • Rot-CA-ens private nøkkel lagret på produksjonslinjen (ikke i HSM)
  • Samme nøkkel brent inn i flere enheter ("testmodus som ble levert")
  • Sertifikatfingeravtrykk logget, men ikke forhåndsregistrert i sky-DPS
  • Provisjoneringsflyten utført for hånd på noen få enheter, aldri skalert

Kilder

  • AWS IoT-dokumentasjon om Just-in-Time Provisioning
  • Microsoft Azure-dokumentasjon om Device Provisioning Service
  • Microchip-dokumentasjon for secure element ATECC608
  • NXP-dokumentasjon for secure element EdgeLock

Be om tilbud på programmerte og serialiserte enheter

Hvis denne forskningen passer din produktsituasjon, send filer så skoper vi produksjonen.