Dlaczego bezpieczne provisioning powinno odbywać się na produkcji
Urządzenie sieciowe wysyłane bez tożsamości trzeba sprovisionować w terenie. Provisioning polowy oznacza ręczny krok (albo podatne na atak auto-enrollment) podczas instalacji. Oba warianty rodzą problemy operacyjne i ekspozycję bezpieczeństwa.
Provisioning po stronie produkcji nadaje urządzeniu unikalną tożsamość kryptograficzną zanim opuści zakład. Urządzenie startuje, uwierzytelnia się i rejestruje bez ręcznej ingerencji.
Bezpieczne elementy
Microchip ATECC608 oraz NXP EdgeLock to typowe secure elements dla IoT. Oba wspierają:
- generowanie klucza prywatnego ECC wewnątrz układu (klucz nigdy go nie opuszcza),
- podpisywanie i weryfikację certyfikatów,
- ochronę przed replay opartą na liczniku,
- zachowanie ujawniające próby manipulacji.
Linia produkcyjna generuje klucz wewnątrz secure element, podpisuje certyfikat przy użyciu root CA, zapisuje certyfikat w urządzeniu i wiąże klucz publiczny z numerem seryjnym.
Wdrożenie certyfikatów X.509
X.509 jest standardowym formatem certyfikatu. Rejestracja po stronie produkcji zwykle przebiega tak:
- Secure element generuje parę kluczy ECC (klucz prywatny zamknięty w układzie).
- System produkcyjny odczytuje klucz publiczny.
- System produkcyjny podpisuje certyfikat za pomocą root CA opartego na HSM.
- Certyfikat zostaje zapisany w urządzeniu.
- Klucz publiczny i odcisk certyfikatu są zapisywane przy numerze seryjnym.
Klucz prywatny root CA nigdy nie trafia na linię produkcyjną. Pozostaje w HSM w kontrolowanym środowisku.
AWS IoT i Azure DPS
AWS IoT wspiera Just-in-Time Provisioning (JITP) oraz Multi-Account Registration. Azure Device Provisioning Service (DPS) wspiera atestację X.509, atestację Trusted Platform Module (TPM) oraz atestację kluczem symetrycznym.
Oba rozwiązania pozwalają linii produkcyjnej rejestrować urządzenia z wyprzedzeniem, dzięki czemu rejestrują się one automatycznie przy pierwszym połączeniu z chmurą. Przebieg po stronie produkcji:
- Urządzenie otrzymuje certyfikat X.509.
- Odcisk certyfikatu urządzenia jest rejestrowany w chmurowym DPS.
- Urządzenie startuje w terenie, prezentuje certyfikat i rejestruje się automatycznie.
- Chmura przypisuje urządzenie do właściwej grupy i pobiera konfigurację.
Własna infrastruktura PKI realizuje ten sam schemat z użyciem zaplecza wewnętrznego zamiast AWS lub Azure.
Sprawdzony przebieg po stronie produkcji
- root CA oparte na HSM w kontrolowanym środowisku, dostępne przez API podpisujące,
- generowanie klucza dla każdej jednostki wewnątrz secure element na linii,
- podpisywanie certyfikatu przez wywołanie API (bez ekspozycji materiału klucza),
- wstępna rejestracja w chmurowym DPS jako element kroku provisioningu,
- rekord rejestracji dla każdej jednostki w bazie produkcyjnej,
- opcjonalne zarządzanie listą unieważnień dla urządzeń wycofanych lub utraconych.
Typowe pułapki
- Klucz prywatny root CA przechowywany na linii produkcyjnej (poza HSM).
- Ten sam klucz wypalony do wielu urządzeń („tryb testowy, który trafił do produkcji”).
- Odcisk certyfikatu zapisany, ale niezarejestrowany wcześniej w chmurowym DPS.
- Provisioning wykonywany ręcznie dla kilku sztuk i nigdy nieprzeskalowany.
Źródła
- dokumentacja AWS IoT Just-in-Time Provisioning,
- dokumentacja Microsoft Azure Device Provisioning Service,
- dokumentacja Microchip ATECC608 secure element,
- dokumentacja NXP EdgeLock secure element.