IoT Hub Device Provisioning Service - łańcuch certyfikatów

Pisałam już o Device Provisioning Service i o automatycznym dodawaniu urządzeń do naszego systemu
Jednak w tym przykładzie opieram się o certyfikat generowany dla pojedynczego urządzenia i rejestruję również indywidualne urządzenie.
A to trochę nie o to chodzi.

Żeby faktycznie dostać automatyzację procesu rejestracji dużej ilości urządzeń, brakuje nam grupowej rejestracji, czyli Enrollment Group.
Aby mieć bezpieczne połączenie i grupową rejestrację urządzeń najlepiej, gdy skorzystamy z certyfikatów. Ale generowanie certyfikatów i cała konfiguracja wcale łatwe nie jest, albo raczej nie jest oczywista.
Ale jest to najłatwiejsza droga, ze względu na relacje jeden certyfikat główny wgrywany do DPS oraz wiele certyfikatów urządzeń. Urządzenia zabezpieczone są prywatnym kluczem unikatowym dla każdego urządzenia. Klucz ten powiązany jest z głównym certyfikatem:

Root CA

Co to jest root ca certyfikat?

To certyfikat, którym możemy podpisywać/poświadczać inne certyfikaty. Czyli jest to nasz korzeń, z którego będą wyrastały gałęzie, aż do liści.
W zależności od naszych potrzeb i wymagań biznesowych można taki certyfikat kupić, wtedy mamy potwierdzone źródło certyfikatu i każdy kto będzie go używał może mu zaufać. W szczególności mowa tutaj o przypadkach, kiedy zamierzamy integrować nasze urządzenia z zewnętrznymi produktami I serwisami.

W przypadku gdy nie przewidujemy integracji z żadnymi serwisami i produktami poza naszym IoTHubem, możemy się zdecydować na self-signed certyfikat. Jest to świetny pomysł dla testowego środowiska. Może być również świadomie wdrożony na produkcji. Należy w takim wypadku pamiętać, aby odpowiednio zabezpieczyć taki certyfikat i cały łańcuch powstających z niego certyfikatów. (Don’t compromise the private key and the whole chain.)

Self-signed Root CA

Pracując z aplikacjami webowymi często tworzymy sobie self-signed SSL certyfikat, taki do testowania, tak aby nie wydawać dodatkowych pieniędzy a pisać już rozwiązanie najbardziej zbliżone do produkcyjnego środowiska.
Dla rozwiązania IoT również możemy sobie wygenerować cały łańcuch self-signed certyfikatów.

HowTo: jak wygenerować certyfikaty?

Microsoft udostępnia nam skrypty do generowania takich certyfikatów, obarczając je ogromnymi komentarzami, „nie używać dla produkcji”. Jednak po małych modyfikacjach skrypty nadają się do użycia nawet na produkcji. A chodzi o ustawienie danych naszej organizacji oraz daty wygaśnięcia certyfikatu, ponieważ domyślnie w skryptach jest to miesiąc. Orginalne skrypty znajdują się w SDK dla C++ tutaj łącznie z wytłumaczeniem tego procesu: Managing test CA certificates for samples and tutorials.

Tutaj znajdziecie moje zmodyfikowane skrypty do generowania root certyfikatu.
A tutaj skrypty dla różnych certyfikatów pośrednich oraz certyfikatów dla urządzeń na podstawie tych pośrednich certów. Repozytorium zawiera również potrzebne konfiguracje.

Używanie skryptów nie jest skomplikowane w końcu to tylko zestaw poleceń. Więcej zabawy jest z odpowiednią kolejnością poleceń.

Jak nie wiadomo co można zrobić to wystarczy wywołać skrypt bez parametrów a dostaniemy możliwe opcje

sh ./certGen.sh

Do stworzenia root certyfikatu wywołujemy

sh ./certGen.sh create_root

W wyniku dostaniemy parę plików które docelowo powinniśmy bardzo chronić, głównie klucz prywatny do tego certyfikatu. Na jego podstawie będą powstawać kolejne.

Tutaj pokazuję cały proces. Z jednym zastrzeżeniem - root certyfikat wgrywamy na Azure tylko w przypadku gdy nie generujemy certyfikatów pośrednich.




HowTo : Generowanie certyfikatów pośrednich

Ponieważ chcę posiadać dwie grupy urządzeń, dlatego generuje dwa certyfikaty pośrednie. Dwa osobne pośrednie certyfikaty są generowane przez dwa osobne pliki, ponieważ każdy certyfikat będzie miał swoje ustawienia takie jak nazwa oraz konfigurację.
Uruchamiamy najpierw JL (potem powtarzamy cały proces dla drugiego certyfikatu PiK)

sh ./certGenJL.sh create_intermediate


Wygenerował się plik chain dla root certyfikatu oraz nasz intermediate JL cert.

Certyfikaty pośrednie powinny wylądować w Azure DPS w sekcji certyfikatów.

Rejestracja certyfikatów w DPS

W Azure rejestrujemy certyfikat, a raczej klucz publiczny wybranego certyfikatu.
Po załadowaniu widzimy szarą ikonkę niepotwierdzonego certyfikatu.
Musimy potwierdzić, że wgrany certyfikat jest nasz.





Proof of possession

Prywatny klucz powinien być strzeżony i nie wychodzić poza security posiadającej go organizacji. Tak więc tylko prawowity posiadacz certyfikatu ma klucz prywatny.
Dodając klucz publiczny do Azura, musimy udowodnić, że jesteśmy posiadaczem klucza prywatnego. Azure generuje wyzwanie, które jest losowym ciągiem znaków. Wyzwanie podpisujemy naszym kluczem prywatnym. Tak wygenerowane potwierdzenie zwracamy Azurowi. Jeśli wszystko się zgadza, mamy zweryfikowany certyfikat gotowy do użycia.

Enrollment group

Na podstawie dodanego i zweryfikowanego przed chwilą certyfikatu możemy dodać grupę w DPS.



I tutaj mały trick. Pomimo że nasz certyfikat jest dla nas certyfikatem pośrednim, to w Enrollment Group wybieramy konfigurację root, a certyfikat będzie dostępny do wyboru z listy.
Jest tak ponieważ jest to bezpośredni root dla liści, które będą wgrywane na urządzenie. I Azure nie musi wiedzieć nic więcej. Nadal chodzi o to, aby root był jak najbardziej bezpieczny. Natomiast przy weryfikacja certyfikatu urządzenia zostanie sprawdzony cały łańcuch certyfikatów.

Certificate chain

Ponieważ zabezpieczeń nigdy dość, a jeden klucz prywatny to zdecydowanie za mało możemy tworzyć łańcuch certyfikatów. Tak naprawdę, to nie chcemy, aby każdy kto ma jakaś odpowiedzialność w procesie wytwarzania miał dostęp do wszystkiego, to tak jak podawanie hasła do swojego keypassa/lastpassa.
Aby zwiększyć bezpieczeństwo oraz zmniejszyć prawdopodobieństwo skompromitowania certyfikatu, każdy poziom certyfikatów może być zarządzany przez inną np. jednostkę organizacyjną.

Właściciel certyfikatu CA = Certificate Authority = urząd certyfikacji, może kryptograficznie podpisać pośredni CA, który z kolei może podpisać inny pośredni CA i tak dalej. Ostatni pośredni CA kończy ten procesu przez podpisanie certyfikatu urządzenia. W rezultacie powstaje kaskadowy łańcuch certyfikatów zwany łańcuchem zaufania certyfikatów = Certificate Chain. W prawdziwym życiu działa to jako przekazanie zaufania w kierunku podpisywanych urządzeń. Ta delegacja jest ważna, ponieważ ustanawia kryptograficznie zmienny łańcuch opieki i odpowiedzialności oraz pozwala uniknąć udostępniania prywatnych kluczy podpisywania.




Na końcu mamy urządzenie, które ma swój własny certyfikat, oraz cały łańcuch certyfikatów pośrednich aż do korzenia reprezentowany przez klucze publiczne wszystkich tych certyfikatów. Warto jak najbardziej zabezpieczyć również certyfikaty przetrzymywane na urządzeniu, dlatego zaleca się tutaj podzespoły typu Hardware Secure Modules (HSM) do sprzętowego szyfrowania i zabezpieczenia wrażliwych na kradzież certyfikatów.

Podłączenie urządzenia

Gdy urządzenie podłącza się do Azure dostaje takie samo wyzwanie potwierdzenia certyfikaty, jak my dostaliśmy wgrywając certyfikat do DPS.
Urządzenie podpisuje wyzwanie swoimi kluczami i przedstawia certyfikat weryfikujący DPS, który sprawdza jego poprawność w stosunku do wgranych certyfikatów pośrednich znanych DPS.
Oprócz potwierdzenia tożsamości samego urządzenia, weryfikowany jest również cały łańcuch certyfikatów. Dzięki temu wiemy nie tylko że urządzenie ma poprawny certyfikat, ale także że cały proces podpisywania nie został nigdzie złamany.


Gdy urządzenie zostanie poprawnie zweryfikowane pokazuje się na liście zarejestrowanych urządzeń, wraz z informacją do którego IoT Huba zostało przypisane.




Moje nagranie całego procesu

Komentarze

Popularne posty