TPM 2.0 w motoryzacji

W artykule opiszę technologię Trusted Platform Module (TPM) oraz jej zastosowanie w systemach motoryzacyjnych. Omówię TPM jako sprzętowe źródło zaufania (Root of Trust), wykorzystywane do bezpiecznego generowania, przechowywania i zarządzania kluczami kryptograficznymi. Wyjaśnię także różnice między TPM a sprzętowymi modułami bezpieczeństwa (HSM), wskazując na ich odmienne role w architekturze pojazdu.

W dalszej części opiszę, dlaczego standard TPM został rozwinięty z wersji 1.2 do 2.0 oraz przedstawię jego kluczowe funkcje:

elastyczność w wykorzystaniu algorytmów,
bardziej rozbudowane mechanizmy autoryzacji,
wsparcie dla bezpiecznego rozruchu (Secure Boot) i atestacji.

W tekście znajdziecie również przykłady praktycznego zastosowania TPM w motoryzacji, w tym bezpieczną aktualizację firmware’u ECU oraz ochronę kluczy kryptograficznych przez cały cykl życia pojazdu.

Zacznę od wyjaśnienia, czym właściwie jest TPM.

Czym jest TPM (Trusted Platform Module)?

Trusted Platform Module to dedykowany sprzętowy komponent bezpieczeństwa, którego zadaniem jest zapewnienie systemowi sprzętowego źródła zaufania (Root of Trust). TPM bezpiecznie generuje, przechowuje i zarządza kluczami kryptograficznymi. W izolowanym, odpornym na manipulacje środowisku wykonuje również operacje istotne z perspektywy bezpieczeństwa, takie jak szyfrowanie, deszyfrowanie, podpisywanie cyfrowe oraz pomiary integralności.

Warto podkreślić, że TPM nie jest akceleratorem kryptograficznym. Nie został zaprojektowany do obsługi operacji kryptograficznych wymagających wysokiej przepustowości lub bardzo dużej wydajności. W systemach motoryzacyjnych moduły TPM są stosowane przede wszystkim do ochrony elektronicznych jednostek sterujących (ECU), zabezpieczania komunikacji wewnątrz pojazdu i komunikacji zewnętrznej, wspierania bezpiecznego rozruchu (Secure Boot), ochrony danych wrażliwych w cyklu życia pojazdu oraz zabezpieczania aktualizacji Over-the-Air (OTA).

TPM a HSM

W systemach motoryzacyjnych do realizacji funkcji cyberbezpieczeństwa oraz operacji kryptograficznych najczęściej wykorzystuje się dwa typy modułów sprzętowych: TPM oraz HSM. Zarówno Trusted Platform Module, jak i Hardware Security Module zapewniają bezpieczeństwo oparte na sprzęcie oraz chronione przechowywanie kluczy, jednak są projektowane z myślą o różnych zadaniach.

TPM pełni rolę Root of Trust dla pojedynczej platformy końcowej. Koncentruje się na pomiarze integralności, bezpiecznym rozruchu, jednoznacznej identyfikacji urządzenia i atestacji. W praktyce moduły TPM są zwykle stosowane w komponentach wyższego poziomu, takich jak:

bramy komunikacyjne (gateways),
jednostki centralne (Head Unit),
systemy infotainment pracujące z rozbudowanymi systemami operacyjnymi, takimi jak Linux lub QNX.

HSM, mimo że również może wspierać bezpieczny rozruch i weryfikację autentyczności, jest optymalizowany pod kątem wysokowydajnych operacji kryptograficznych oraz zarządzania kluczami w systemach wbudowanych czasu rzeczywistego. Dzięki temu HSM może obsługiwać szerszy zakres algorytmów, większą przepustowość oraz równoległe operacje dla wielu aplikacji czasu rzeczywistego.

W architekturach automotive HSM jest często bezpośrednio integrowany z mikrokontrolerem i zabezpiecza funkcje czasu rzeczywistego, takie jak uwierzytelnianie komunikatów oraz szyfrowanie w sieciach pojazdu. TPM jest natomiast zazwyczaj używany przy głównym procesorze, aby ustanowić zaufanie do systemu lub wspierać bezpieczne operacje cyklu życia, takie jak:

inicjalizacja poświadczeń,
Provisioning,
aktualizacje OTA.

Funkcje TPM 2.0

Poprzedni standard TPM 1.2 w dużym stopniu opierał się na algorytmie SHA-1 i wiązał go z architekturą rozwiązania. Podatności kryptograficzne opisane w pracy Xiaoyun Wang z 2005 roku dotyczącej kolizji SHA-1 skłoniły Trusted Computing Group do przeprojektowania standardu w kierunku elastyczności algorytmicznej. TPM 2.0 nie ogranicza się już do stałego zestawu operacji kryptograficznych. Obsługuje wiele konfigurowalnych algorytmów, w tym SHA-2, SHA-3 oraz algorytmy z rodziny ECC, takie jak ECDH i ECDSA. Dzięki temu systemy mogą lepiej dostosowywać się do zmieniających się wymagań bezpieczeństwa.

TPM 2.0 wprowadza także bardziej elastyczne mechanizmy autoryzacji dostępu do zasobów chronionych. Dostęp może zależeć nie tylko od hasła zdefiniowanego przez użytkownika lub dowodu kryptograficznego, ale również od tego, czy system znajduje się w znanym i zaufanym stanie. Służą do tego rejestry PCR (Platform Configuration Registers), które rozszerzają i przechowują skróty (hashe) kryptograficzne kolejnych etapów sekwencji rozruchowej, tworząc łańcuch zaufania. Jeżeli którykolwiek komponent zostanie zmieniony, zmieni się również odpowiedni skrót, a wartości PCR mogą zostać wykorzystane jako warunek dostępu do chronionych kluczy.

TPM 2.0 zawiera również mechanizm ochrony przed próbami siłowego odgadnięcia wartości autoryzacyjnych, takich jak kody PIN lub hasła. Układ śledzi nieudane próby autoryzacji i po przekroczeniu zdefiniowanego progu czasowo blokuje dostęp do wybranych funkcji lub danych. Mechanizm blokady może wymagać zachowania określonych opóźnień, w tym wykładniczego wydłużania czasu oczekiwania albo użycia specjalnych poświadczeń administracyjnych do resetu.

Sprzętowy model zaufania i zastosowanie TPM 2.0

Źródłem zaufania jest przede wszystkim konstrukcja samego układu TPM. Chip jest odporny na manipulacje i odizolowany od głównego procesora CPU. Klucze prywatne wygenerowane wewnątrz TPM z założenia nigdy nie opuszczają urządzenia. Ochrona kluczy jest więc wymuszana sprzętowo, a nie wyłącznie przez mechanizmy programowe. Dodatkowo dostawcy TPM mogą nadać każdemu układowi unikalny klucz poświadczenia (Endorsement Key, EK) oraz powiązane certyfikaty jeszcze przed dostarczeniem komponentu użytkownikowi końcowemu. Podczas produkcji ECU certyfikat może zostać zweryfikowany pod kątem podpisu zaufanego urzędu certyfikacji (CA) dostawcy TPM.

Należy jednak pamiętać, że TPM nie jest akceleratorem kryptograficznym i w niektórych scenariuszach może być wolniejszy niż implementacje programowe. Zazwyczaj nie stanowi to problemu na wczesnych etapach rozruchu ani w przypadkach, w których wymagane są certyfikowane implementacje kryptograficzne.

Dzięki tym funkcjom TPM 2.0 zapewnia większą skalowalność, elastyczność oraz gotowość na przyszłe wymagania bezpieczeństwa. Dobrze wpisuje się w potrzeby systemów motoryzacyjnych, między innymi w zakresie bezpiecznego provisioningu, zarządzania cyklem życia oraz aktualizacji OTA.

Stosy oprogramowania współpracujące z TPM 2.0

Dostępnych jest kilka bibliotek i stosów oprogramowania umożliwiających komunikację ze sprzętem TPM 2.0 oraz realizację operacji kryptograficznych, atestacji i zarządzania kluczami:

TPM2-TSS (Trusted Software Stack): otwartoźródłowa implementacja opracowana przez Trusted Computing Group i napisana w języku C. Udostępnia silnik OpenSSL (tpm2-tss-engine) oraz obsługę API PKCS#11 (tpm2-pkcs11), co ułatwia integrację ze standardowymi aplikacjami kryptograficznymi. Stos obejmuje również tpm2-abrmd (Access Broker and Resource Manager Daemon), potrzebny wtedy, gdy wiele aplikacji wymaga skoordynowanego dostępu do jednego urządzenia TPM. Do podstawowych zależności tpm2-abrmd należą D-Bus, systemd oraz GLib/GObject.
wolfTPM: lekka i przenośna biblioteka TPM 2.0 rozwijana przez wolfSSL. Została zaprojektowana z myślą o systemach wbudowanych i platformach motoryzacyjnych. Ma niewielki narzut oraz jest zgodna ze specyfikacjami TCG. Jej podstawowa funkcjonalność nie wymaga zewnętrznych zależności, dzięki czemu może być kompilowana i uruchamiana w środowiskach embedded oraz bare-metal. Biblioteka zapewnia obsługę API PKCS#11 i jest dostępna w modelu podwójnego licencjonowania: GPLv3 dla zastosowań open-source oraz licencji komercyjnej dla aplikacji własnościowych lub zamkniętoźródłowych.

Praktyczne przypadki użycia

Aktualizacja firmware’u ECU

Rycina 2 przedstawia przykładową architekturę, w której TPM umieszczony w jednostce centralnej (Head Unit), pełniącej rolę bramy komunikacyjnej, komunikuje się z Vehicle Manufacturing Center (VMC). Jednostka centralna weryfikuje podpisy oraz raporty integralności generowane przez poszczególne sterowniki ECU, z których każdy jest wyposażony we własny TPM.

W tym modelu każde ECU otrzymuje unikalny klucz poświadczenia. Klucz może zostać wprowadzony podczas produkcji lub nadany za pośrednictwem infrastruktury PKI producenta OEM. Publiczna część EK jest rejestrowana zarówno w jednostce centralnej, jak i w VMC. Na podstawie tej identyfikacji VMC wydaje poświadczenia podpisujące przypisane do konkretnego ECU.

Podczas bezpiecznej produkcji lub inicjalizacji każde ECU wykonuje pomiar obrazu firmware’u, czyli oblicza jego skrót kryptograficzny, a następnie podpisuje ten skrót przy użyciu klucza podpisującego chronionego przez TPM. Brama komunikacyjna weryfikuje podpisy i agreguje raporty integralności z wielu ECU. Zbiorczy raport jest następnie podpisywany kluczem chronionym przez TPM bramy i przesyłany do VMC w celu zdalnej weryfikacji.

Jeżeli wymagana jest aktualizacja firmware’u, VMC podpisuje pakiet aktualizacyjny swoim kluczem prywatnym. Jednostka centralna weryfikuje podpis z wykorzystaniem TPM, a następnie dystrybuuje aktualizację do docelowego ECU. Przed instalacją ECU waliduje pakiet aktualizacyjny przy użyciu własnych kluczy TPM. Po zakończeniu instalacji pomiary firmware’u są powtarzane, aby potwierdzić integralność aktualizacji oraz poprawność wdrożenia.

Taka architektura zapewnia:

jednoznaczną kryptograficzną identyfikację urządzeń,
sprzętowo chronione przechowywanie kluczy,
uwierzytelnioną dystrybucję firmware’u,
atestację realizowaną od końca do końca między ECU, bramą komunikacyjną w pojeździe i infrastrukturą backendową.

Bezpieczne przechowywanie kluczy

W architekturach automotive TPM pełni funkcję sprzętowego magazynu kluczy dla wrażliwych sekretów, takich jak klucze immobilizera, poświadczenia bezpiecznego rozruchu oraz klucze wykorzystywane w komunikacji pojazd-chmura (vehicle-to-cloud).

Klucze generowane w TPM są zorganizowane hierarchicznie.

Standard TPM 2.0 definiuje trzy trwałe hierarchie:

Platform,
Endorsement,
Owner.

Każda z nich może mieć wiele kluczy podstawowych (Primary Keys), które pełnią rolę kluczy nadrzędnych dla pozostałych kluczy. Gdy tworzony jest klucz podrzędny, TPM nie przechowuje go w postaci jawnej. Zamiast tego generuje prywatną i publiczną reprezentację obiektu klucza.

Aby zoptymalizować ponowne ładowanie kluczy z pamięci podręcznej, część prywatna jest chroniona przy użyciu symetrycznego klucza opakowującego. Klucz ten jest wyprowadzany z materiału klucza nadrzędnego z użyciem funkcji wyprowadzania klucza (KDF), co zapewnia ochronę niezależnie od tego, czy klucz nadrzędny jest symetryczny, czy asymetryczny. Takie podejście pozwala bezpiecznie eksportować obiekt klucza poza TPM, ponieważ może on zostać użyty, czyli odszyfrowany, wyłącznie przez ten TPM, który go utworzył.

Rycina 3 przedstawia uproszczony przykład struktury kluczy generowanych i przechowywanych w TPM.

Podsumowanie

TPM 2.0 odgrywa istotną rolę we wzmacnianiu bezpieczeństwa systemów motoryzacyjnych, ponieważ zapewnia sprzętowe źródło zaufania. W przeciwieństwie do HSM, który koncentruje się na wysokowydajnym przetwarzaniu kryptograficznym w systemach wbudowanych czasu rzeczywistego, TPM odpowiada przede wszystkim za integralność platformy, bezpieczną identyfikację urządzenia oraz zaufany stan systemu w komponentach wyższego poziomu, takich jak centralne bramy komunikacyjne i węzły telematyczne.

Tego typu sprzętowo wymuszana ochrona może wspierać producentów OEM w wykazywaniu zgodności z UNECE WP.29 R155 oraz w adresowaniu ryzyka identyfikowanego zgodnie z ISO/SAE 21434.

Dzięki obsłudze wielu algorytmów kryptograficznych, rozbudowanym politykom autoryzacji i większej skalowalności TPM 2.0 usuwa część ograniczeń wcześniejszych wersji standardu i lepiej odpowiada na zmieniające się wymagania bezpieczeństwa. Jego wdrożenie wymaga jednak świadomych decyzji architektonicznych. TPM skutecznie ogranicza ryzyko zdalnego pozyskania kluczy oraz manipulacji oprogramowaniem podczas rozruchu, ale nie eliminuje wszystkich zagrożeń, w szczególności exploitów działających już po uruchomieniu systemu.

Dodatkowo, dyskretne układy TPM komunikują się z systemem przez zewnętrzne magistrale fizyczne, takie jak SPI, co może narażać je na lokalne ataki sprzętowe, na przykład podsłuchiwanie magistrali z użyciem analizatora logicznego. Ochrona tych interfejsów wymaga stosowania szyfrowania parametrów sesji TPM 2.0 albo rozważenia rozwiązań typu Firmware TPM (fTPM), izolowanych programowo.

Przy właściwym zabezpieczeniu przed takimi atakami TPM 2.0 może wspierać bezpieczny provisioning, niezawodne aktualizacje OTA, chronioną komunikację oraz bezpieczne przechowywanie wrażliwych kluczy przez cały cykl życia pojazdu.