Hierarchia certyfikatów X.509: offline'owy root CA — fabryczny pośredni CA — unikatowy certyfikat urządzenia na każdą jednostkę
Klucze symetryczne współdzielone przez flotę urządzeń oznaczają, że jedno skompromitowane urządzenie naraża wszystkie. Certyfikaty X.509 dają każdemu urządzeniu unikatową tożsamość kryptograficzną — kompromitacja jednego dotyka jednego.
Projekt hierarchii certyfikatów
Root CA (samopodpisany, offline, sprzęt odizolowany od sieci)
└── Manufacturing CA (online HSM, podpisuje certyfikaty urządzeń)
└── Certyfikat urządzenia (unikatowy na numer seryjny)
Klucz: ECC P-256 (mniejszy i szybszy niż RSA-2048)
Integracja z Azure IoT Hub DPS
az iot dps enrollment-group create --dps-name fss-dps --enrollment-id fss-devices --certificate-path manufacturing-ca.crt --iot-hubs fss-production-hub.azure-devices.net
Proces provisioningu fabrycznego
Bezpieczeństwo całej Twojej floty urządzeń zależy od integralności procesu provisioningu fabrycznego. Klucz prywatny Manufacturing CA nigdy nie może opuścić HSM. Stacja programująca, która wgrywa certyfikaty urządzeń, musi znajdować się w odizolowanym segmencie sieci bez dostępu do internetu. Każde wystawienie certyfikatu musi być zapisane wraz z numerem seryjnym urządzenia, odciskiem certyfikatu (thumbprint) i znacznikiem czasu — ten dziennik jest Twoją ścieżką audytu dla stanu bezpieczeństwa całej floty urządzeń.
Dla produkcji wielkoseryjnej (1000+ jednostek dziennie) praktycznym podejściem jest automatyczny provisioning zintegrowany ze stanowiskiem testów funkcjonalnych: przyrząd testowy komunikuje się z usługą podpisującą HSM przez bezpieczne wewnętrzne API, generuje CSR z bezpiecznego elementu ATECC608B, otrzymuje podpisany certyfikat i zapisuje go do NVS urządzenia — wszystko w mniej niż 5 sekund na urządzenie. Urządzenie w żadnym momencie procesu nie przechowuje niezabezpieczonego klucza prywatnego.
Unieważnianie certyfikatów
Certyfikaty X.509 można unieważnić, jeśli urządzenie zostało skompromitowane, zgłoszone jako skradzione lub wycofane z użytku. Azure IoT Hub utrzymuje rejestr urządzeń, w którym poszczególne urządzenia można wyłączyć — uniemożliwiając połączenie nawet z ważnym certyfikatem. Dla unieważniania na poziomie floty (jeśli podejrzewa się kompromitację partii urządzeń z określonej serii fabrycznej) konfiguracja IoT Hub może wskazywać urządzenia po tagu i masowo je wyłączać.
Listy unieważnionych certyfikatów (CRL) to standardowy mechanizm PKI do dystrybucji informacji o unieważnieniu, ale są niepraktyczne dla urządzeń IoT, które mogą pozostawać offline przez dłuższy czas. Podejście oparte na rejestrze IoT Hub — sprawdzanie przy połączeniu zamiast dystrybucji CRL — jest bardziej odporne dla urządzeń z przerywaną łącznością.
Reakcja na kompromitację pośredniego CA
Jeśli Twój Manufacturing CA zostanie skompromitowany — zdarzenie mało prawdopodobne, lecz katastrofalne — potrzebujesz planu odzyskiwania. Twój Root CA (odizolowany od sieci, offline) może wystawić nowy certyfikat pośredniego CA i unieważnić skompromitowany. Urządzenia już w terenie zachowują swoje ważne certyfikaty urządzeń, które zostały podpisane przez (obecnie unieważniony) pośredni CA. Wymaga to, aby IoT Hub ufał nowemu pośredniemu CA i utrzymywał zapis unieważnienia dla starego.
Ten scenariusz podkreśla znaczenie hierarchii trójpoziomowej zamiast dwupoziomowej (Root CA podpisujący bezpośrednio certyfikaty urządzeń): izolacja Root CA sprawia, że kompromitacja Manufacturing CA nie wymusza wycofywania urządzeń. Projektuj hierarchię PKI z tym modelem zagrożeń na uwadze od samego początku.
Budujesz produkt IoT?
FSS to pełnostackowy zespół inżynierii IoT — sprzęt, firmware, chmura i aplikacje mobilne w jednym miejscu.