CYBERSECURITY W AUTOMOTIVE
AUTOSAR SecOC – architektura i wyzwania bezpieczeństwa komunikacji w pojazdach
Niniejszy artykuł jest częścią cyklu poświęconego tematyce cyberbezpieczeństwa w branży automotive, przygotowanego przez Krzysztofa Labudę.
Czym jest protokół SecOC w kontekście AUTOSAR?
W tej części przybliżę czytelnikowi podejście architektoniczne AUTOSAR dla Secure Onboard Communication Protocol (SecOC).
SecOC, na który powoływałem się w czwartej odsłonie cyklu „Co kryje się pod hasłem cybersecurity w automotive?”, jest jednym z głównych protokołów umożliwiających uwierzytelnienie i sprawdzanie spójności komunikacji samochodowej.
Zależność od innych warstw protokołu i SecOC, z niższą warstwą stosu komunikacyjnego, będzie zależeć od architektury platformy (AP – Authentic PDU lub CP – Cryptographic PDU), a w przypadku implementacji CP będzie również zależeć od rodzaju transmisji (tutaj możemy wyróżnić transmisję bezpośrednią, transmisję wyzwalaną lub protokół transportowy). Te specyficzne dla projektu zależności nie są częścią specyfikacji protokołu i zależą od innych dedykowanych standardów lub norm, m.in. FIPS-180-4 (standaryzującego funkcje hashujące) czy opracowań NIST.
Protokół SecOC nie jest zależny od typowej warstwy aplikacji motoryzacyjnej. Opiera się jednak na istnieniu komponentu oprogramowania, który zapewnia informacje o freshness values. Ponadto mogą istnieć wyspecjalizowane aplikacje, które wyzwalają modyfikację w zachowaniu SecOC.
Na poniższym obrazku porównano realizacje SecOC w oparciu o szynę CAN oraz standardowy stos sieciowy ETH. Są w nim zawarte również moduły kryptograficzne opisywane w drugiej odsłonie cyklu (CSM, CRYIF, Cry dla CRYPTO).
Ogólny sposób formowania ramki opiera się o realizację o stos sieciowy, zrealizowany o protokół ETH (widać enkapsulację freshness oraz MAC z danymi).
Ilustracja przedstawiająca formowanie ramki:
Źródło: opracowanie własne na podstawie: https://www.linkedin.com/pulse/cyber-security-solution-autosar-classic-platform-quoc-bao-nguyen/
Ilustracja przedstawiająca strukturę zabezpieczonej przez SecOS ramki:
Źródło: opracowanie własne na podstawie: https://autosec.se/wp-content/uploads/2019/03/6.-Holisec_SecOC_2019-03-26_Kaushik_final.pdf
Ilustracja przedstawiająca odbiór oraz weryfikację ramki:
Źródło: opracowanie własne na podstawie https://www.linkedin.com/pulse/cyber-security-solution-autosar-classic-platform-quoc-bao-nguyen/
Architektura komunikacji: CAN vs Ethernet w SecOC
Jako ciekawostkę można rozpatrzyć realizację w oparciu o szynę CAN. O sposobach zabezpieczania tego protokołu i problematyce wspominałem w osobnym cyklu – Cybersecurity w automotive: rozwiązania sieciowe. Charakterystyczne jest to, że realizacja w oparciu o CAN nie może odbywać się w ramach jednej ramki. Konieczna jest realizacja poprzez Cryptographic Message i komplementarną do niej Authentic Message.
Ilustracja przedstawiająca realizację w oparciu o CAN:
Źródło: opracowanie własne na podstawie: https://www.linkedin.com/pulse/cyber-security-solution-autosar-classic-platform-quoc-bao-nguyen/
SecOC jako rozwiązanie wprowadza kluczową funkcjonalność niezbędną do weryfikacji autentyczności komunikacji opartej na PDU między ECU w ramach architektury / sieci pojazdu. Podejście to wymaga, aby zarówno wysyłający ECU, jak i ECU odbierający zaimplementowali moduł SecOC. Aby zapewnić autentyczność wiadomości, moduł SecOC po stronie wysyłającej i odbierającej uzyskuje tzw. freshness values z zewnętrznego menedżera tej wartości dla każdego jednoznacznie zabezpieczonego łącza komunikacyjnego.
Po stronie nadawcy moduł SecOC tworzy Secured I-PDU poprzez dodanie informacji uwierzytelniających do wychodzącego Authentic I-PDU. Informacje uwierzytelniające składają się z elementu pełniącego rolę uwierzytelniającą, np. kodu uwierzytelniania wiadomości (MAC) i opcjonalnie freshness values. Niezależnie od tego, czy wartość świeżości jest zawarta w payloadzie Secure I-PDU, freshness values są brane pod uwagę podczas generowania przez podmiot uwierzytelniający. W przypadku korzystania z freshness counter, zamiast znaczników czasu (timestamp), freshness counter powinien być zwiększany przez Freshness Manager przed dostarczeniem informacji uwierzytelniających do strony odbiorcy.
Po stronie odbiorcy moduł SecOC sprawdza autentyczność (oraz freshness) I-PDU poprzez weryfikację informacji uwierzytelniających, które zostały dołączone przez moduł SecOC strony wysyłającej. Aby zweryfikować autentyczność Authentic I-PDU, Secured I-PDU dostarczony do strony odbierającej SecOC powinien być tym samym Secured I-PDU.
Składowe Secured I-PDU:
źródło: Konsorcjum AUTOSAR, strona 11 https://www.autosar.org/fileadmin/standards/R20-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf
Diagram przedstawiający przykład zawartości zabezpieczonej jednostki danych (Secured I-PDU) z obciętymi freshness value i authenticatorem:
Źródło: Konsorcjum AUTOSAR, strona 12 https://www.autosar.org/fileadmin/standards/R20-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf
SOC i SIEM – analiza zagrożeń poza pojazdem
AUTOSAR rozróżnia 3 profile SecOC, w zależności od obranych parametrów – algorytmu MAC (Message Authentication Code), sposobu traktowania wartości freshness i wartości MAC:
SecOC Profile 1 (24Bit-CMAC-8Bit-FV)
- Algorytm: CMAC/AES-128
- Przycięcie wartości freshness: 8 bitów
- Przycięcie wartości MAC: 24 bity
SecOC Profile 2 (24Bit-CMAC-No-FV)
- Algorytm: CMAC/AES-128
- Przycięcie wartości freshness: 0 bitów (wartość świeżości nie jest używana)
- Przycięcie wartości MAC: 24 bity
SecOC Profile 3 (JASPAR)
- Algorytm: CMAC/AES-128
- Długość wartości freshness: 64 bity
- Przycięcie wartości freshness: 4 bity
- Przycięcie wartości MAC: 28 bitów
Wyzwania i ograniczenia implementacji SecOC w praktyce
Warto zwrócić uwagę, że w tak zaproponowanym protokole istnieje kilka istotnych wyzwań:
- Każdy OEM definiuje swój dedykowany sposób implementacji SecOC, co wymaga dostosowania. Pomocna może być biblioteka Pythona Scapy.
- Gdy używana jest wartość freshness, musi ona być dokładnie monitorowana i synchronizowana, co bywa problematyczne.
- Ramki zabezpieczone przez SecOC zazwyczaj występują razem z niezabezpieczonymi, co może komplikować obsługę.
- Niespójne generowanie MAC może prowadzić do nieprzewidywalnego zachowania systemu zabezpieczeń, szczególnie przy niejasnościach dotyczących uwierzytelnianych pól (np. PDU-ID czy długość ramki).
- Zarządzanie materiałem kryptograficznym (klucze, aktualizacje, mapowanie PDU-ID na klucze) wpływa na integralność komunikacji i wymaga bezpiecznej implementacji.
AUTOSAR oferuje wsparcie i mechanizmy bezpiecznego przechowywania danych oraz ochrony poufnych informacji w ECU pojazdów. Obejmuje to m.in. szyfrowanie danych, kontrolę dostępu oraz bezpieczne usuwanie danych, aby zapobiec nieautoryzowanemu dostępowi lub wyciekowi danych.
Autor: Krzysztof Labuda,
Konsultant ds. testów bezpieczeństwa
Uczestnik programu Certified Ethical Hacker CEH v11, który uczy najnowszych narzędzi, technik i metodologii hackerskich klasy komercyjnej, używanych przez hakerów i specjalistów ds. bezpieczeństwa informacji.
