Connected Vehicle Security – cz. 1

 

Business Insider przewiduje, że w 2021 roku na drogach będzie ponad 380 milionów samochodów umownie nazywanych „connected cars”, czyli na stałe połączonych z siecią. Analitycy firmy Gartner twierdzą zaś, że za cztery lata co najmniej jeden na pięć samochodów będzie wyposażony w dostęp do funkcjonalności online. Dzięki tym rozwiązaniom będziemy mogli płacić nie wysiadając z samochodu dzięki systemowi płatności uruchamianemu z poziomu panelu radia samochodowego. Połączenie z miejską infrastrukturą pozwoli nam na łatwiejsze zlokalizowanie wolnego miejsca postojowego. Dzięki połączeniu z inteligentnym domem będziemy mogli odebrać wideodomofon w samochodzie, a zbliżając się do domu system poinformuje nas o brakach w lodówce, nastawi nam ulubioną muzykę, programy tv lub włączy saunę. Nasz mechanik będzie mógł wykonać diagnostykę samochodu zdalnie.

Te rozwiązania są stosowane już nie tylko w autach ekskluzywnych, ale również produkowanych masowo. Biorąc pod uwagę przypadki zdalnego przejęcia kontroli nad Jeepem Cheerokee oraz Teslą pojawia się pytanie o bezpieczeństwo tego typu rozwiązań.

Władze w USA dostrzegły to ryzyko i 17 marca 2017 r.  opublikowały oświadczenie o rosnącym zagrożeniu związanym ze zdalnym wykorzystaniem exploitów na istniejące podatności w connected vehicles (CV).  Stan Michigan opracowuje bardzo surowe kary za hakowanie samochodów.

Grupa robocza Internet of Things opracowała poradnik opisujący technologie powszechnie wykorzystywane w connected cars i związane z nimi podatności oraz dostarcza propozycje zabezpieczeń. I właśnie zawarte w nim porady posłużą m.in jako podstawa do tego artykułu.

W tej części postaram się przybliżyć model architektury proponowany przez  amerykański Departament Transportu. Podejście wykorzystane do rozwoju architektury zostało oparte na standardzie ISO/IEC/IEEE 42010:2011 “Systems and software engineering — Architecture description.”

Architektura Connected vehicle reference implementation architecture (“CVRIA”) jest oparta na zbiorze składającym się z warstwowo połączonych różnych punktów widzenia (“views”).

  • Organizacji – obejmujący relację pomiędzy organizacjami i zasobami i opisujący ich rolę.
  • Funkcjonalny – z punktu widzenia logicznych interakcji pomiędzy funkcjami i przepływami danych.
  • Fizyczny – uwzględniający połączenia pomiędzy fizycznymi obiektami i obiektami aplikacji
  • Komunikacyjny – definiujący warstwowe protokoły komunikacyjne pomiędzy obiektami.

Z punktu widzenia organizacji (Enterprise view) – CVRIA przedstawia zależności pomiędzy organizacjami występującymi w architekturze i opisuje zależności, role interakcje i wymiany informacji zachodzące pomiędzy nimi. Główny nacisk jest położony na relacje pomiędzy tzw. obiektami organizacji, ale obejmuje też powiązania pomiędzy nimi, a elementami odgrywającymi znaczącą rolę w dostarczaniu usług zwanych zasobami. Powiązania pomiędzy obiektami oraz obiektami i zasobami określone są jako Role (m.in.  odpowiedzialny, posiadający, instalujący, utrzymujący itd). Pomiędzy obiektami istnieje jeszcze Koordynacja definiowana jako forma kontraktu lub umowy w celu realizacji wdrożenia i utrzymania aplikacji dla CV.

Zdefiniowanych obiektów organizacji  jest kilkaset, ja posłużę się jednym dla zilustrowania stopnia złożoności tych relacji.

Diagram dla Obiektu Właściciel CV – jednostki posiadającej samochód połączony z siecią (Connected Vehicle).

Do powyżej przedstawionych interfejsów pomiędzy obiektami należy jeszcze uwzględnić opisy jaką rolę w modelu architektury pełni każdy z wymienionych obiektów.

Z punktu widzenia funkcjonalnego (Functional view) – model architektury opisuje to jako zbiór powiązanych ze sobą i hierarchicznie uporządkowanych Procesów tj. zarządzanie, monitorowanie, kontrola, utrzymanie, obsługa awarii, usługi dla kierowcy i podróżnych, obsługa płatności itd. Wraz z nimi opisany jest przepływ danych zachodzących pomiędzy procesami

Z punktu widzenia fizycznego (Physical view) – CVRIA prezentuje powiązania i przepływy danych pomiędzy fizycznymi elementami takimi jak systemy wsparcia (uwierzytelnienia, rejestracji, aktualizacji, monitorowania itp), urządzenia podróżne ( karty płatnicze, karty podróżne), pojazdy i wyposażenie, centra usługowe i informacji (płatnicze, graniczne, obsługi awarii, autoryzacji, informacji o ruchu, zarządzanie flotą itp) i stacje (np. ładowania, parkowania, graniczne).

Z punktu widzenia komunikacji (Communication view) – w tym widoku opisane są protokoły i standardy niezbędne do realizacji komunikacji pomiędzy fizycznymi elementami prezentowanymi w widoku modelu z punktu widzenia fizycznego.

Model komunikacji CVRIA NITSA (Communications Model for the Connected Vehicle Reference Implementation Architecture (CVRIA) and National ITS Architecture) oparty jest o model OSI (Open System Interconnection) uwzględniając dodatkową, specyficzną warstwę aplikacji – ITS Application Information Layer – definiującą strukturę, znaczenie i kontrolę wymiany informacji pomiędzy dwoma punktami końcowymi. 

Poniżej przykład wymiany informacji pomiędzy urządzeniem samochodowym umożliwiającymi realizację opłat drogowych lub parkingowych, a centrum obsługi płatności

Źródłem komunikacji jest urządzenie zwane Vehicle On-Board Equipment (OBE), które umożliwia przetwarzanie, przechowywanie i wymianę informacji. Kluczowym komponentem OBE jest radio obsługujące technologie V2V (vehicle to vehicle), V2I (vehicle to infrastructure) oraz V2X (vehicle to application).

W przypadku obsługi płatności przepływ informacji  (vehicle payment information) zawiera dane umożliwiające identyfikację konta lub źródła płatności i powiązanego z nim pojazdu oraz informacje określające rodzaj i cenę żądanej usługi.Odbiorcą informacji jest centrum obsługi płatności (Payment Administration Center) dostarczające usługę rozliczenia płatności dla operatorów usług (np. opłat drogowych lub parkingowych).

Model CVRIA ilustruje w/w komunikację za pomocą diagramów uwzględniając zastosowanie różnych formatów i standardów wymianu danych i wskazując główne kwestie związane z bezpieczeństwem.

Format JSON

Format XML

Standard ASN.1

Z zastosowaniem przydrożnych urządzeń służących jako bramka pośrednicząca pomiędzy pojazdem, a centrum obsługi płatności.

W kolejnych częściach artykułu przedstawię przykłady podatności i zagrożeń typowych dla pojazdów połączonych z siecią oraz sposoby ich zabezpieczenia.

Facebooktwittergoogle_pluslinkedin
Facebooklinkedin

Skomentuj