Mówi się, że bezpieczeństwo pod jednym, kluczowym względem jest jak jakość: nie można go dodać na końcu produkcji. Przenika całą strukturę projektu i musi był z nim gładko zintegrowane. Projektanci systemów wbudowanych mierzą się z coraz większymi wyzwaniami. Nowe produkty muszą pracować w jeszcze bardziej połączonym i potencjalnie bardziej wrogim otoczeniu.

Tradycyjnie zabezpieczenia uważa się za adekwatne, jeśli wymagają od napastnika podjęcia większego wysiłku do ich złamania niż wartość potencjalnych zysków. To podejście staje się problematyczne wraz z rosnącą złożonością połączeń pomiędzy urządzeniami. W kontekście samego dostępu do przyziemnych funkcji systemu wbudowanego, np. sterowania jakimś nieznaczącym elementem, wartość takiego włamania może być niewielka. Ale takie systemy mogą być bezcenne dla tych, którzy mają większe plany. Z poziomu takiego urządzenia można bowiem dostać się do podatnych na ataki bramek, a następnie do szerszej, cenniejszej infrastruktury.

Zagrożenia w systemach wbudowanych

Problem bezpieczeństwa stał się wielowymiarowy. Z jednej strony mamy kwestię bezpieczeństwa własności intelektualnej (IP – Intellectual Properties) – jak chronić same projekty systemów wbudowanych przed kradzieżą i kopiowaniem? Jak uniemożliwić kopiowanie kodu i klonowanie projektów? Z drugiej strony chronione muszą być też same zamierzone funkcje systemu. Projekt powinien być zabezpieczony przed wprowadzeniem niepowołanych zmian, które spowodowałyby, że będzie pracować w nieodpowiedni sposób. Oczywiście trzeba też upewnić się, że dane, jak i informacje o użytkownikach systemu, są zabezpieczone przed kopiowaniem. I tak jak wspomniano wcześniej, haker nie powinien móc wykorzystać systemu wbudowanego jako punku wejścia, za pomocą którego uzyska dostęp do szerszej infrastruktury IT.

Cryptojacking

Oprócz wszystkich tych powyższych kwestii, ostatnio pojawiło się nowe zagrożenie: możliwość kradzieży mocy obliczeniowej systemu (wbudowanego lub zwykłego). Fenomen ten nazywa się określeniem „cryptojacking”. Do normalnej pracy urządzenia dodaje się skrypt, który w trakcie działania sprzętu, uruchamia w tle algorytmy wydobywania kryptowalut. Wyniki działania są następnie po cichu przesyłane przez dowolny, otwarty port, wzbogacając tym samym twórców skryptu. Efekty mogą być dosyć zwodnicze. Z jednej strony żadne dane nie zostają skradzione, żadna prywatność nie zostaje naruszona. Jedynym efektem jest, że jakaś część cykli procesora zaginęła. Dla systemu wbudowanego, który powinien pracować w czasie rzeczywistym, problem ten może objawić się niedoborem wydajności w krytycznej sytuacji. Jak dotąd tego typu ataki obserwowano głównie w postaci kodu ukrytego na stronach internetowych. Jednakże nie stanowi trudności wyobrażenie sobie systemu wbudowanego, w którym pozostawiono niezabezpieczone połączenie internetowe, a które można zdalnie wykryć i wykorzystać. W podobny sposób, systemy podłączone do Internetu bywają podatne na przejęcie, co może skutkować przekształceniem ich w boty, stanowiące część machiny służącej do ataków internetowych na osoby trzecie.

Co na to projektanci?

Projektanci systemów wbudowanych są już dobrze zaznajomieni z licznymi głosami, zwracającymi uwagę, że „bezpieczeństwo jest problemem”. Mniej oczywiste jest, co powinni z tym zrobić. Na oprogramowanie systemu wbudowanego bardzo często składa się kod pochodzący z mnóstwa różnych źródeł. Wśród niego znajdzie się kod napisany specjalnie na potrzeby danego projektu, ale też bloki kodu ponownie użytego, a pochodzącego z wcześniejszych systemów. Mogą pojawić się także fragmenty pochodzące od dostawców zastosowanego sprzętu – np. sterowniki urządzeń peryferyjnych. Bywają też fragmenty kodu open-source, zaimportowanego do projektu. Ci, którzy nawołują do weryfikowania integralności kodu wbudowanego na wskroś, utrzymują też, że przynajmniej wszystkie części kodu aplikacji powinny być dostępne w postaci źródłowej.

Ilustracja 1. Oddzielenie sprzętu w mikrokontrolerze Cypress PSoC 6

Komputery stacjonarne przez wiele lat stanowiły pole walki pomiędzy hakerami i użytkownikami. Właśnie w tej przestrzeni wyewoluował ekosystem, który ma na celu walczyć z zagrożeniami bezpieczeństwa. Najbardziej oczywistym przypadkiem jest system operacyjny Windows i ciągłe prace Microsoftu, polegające na wydawaniu aktualizacji i usprawnień. Kluczowe w tym jest zwrócenie uwagi na fakt, że Microsoft bierze odpowiedzialność za utrzymywanie niezawodności swojego produktu. Analizuje również nowe, pojawiające się zagrożenia i dostarcza adekwatne poprawki.

Aktualizacje bezpieczeństwa w systemach wbudowanych

W świecie systemów wbudowanych nie ma takich struktur. W rzeczywistości kod do większości systemów wbudowanych dostarcza się w postaci pojedynczego, binarnego pliku wykonywalnego. Idea wprowadzania częściowej aktualizacji nie jest zatem łatwa do realizacji. Potrzeba przygotować kompletną, nowszą wersję oprogramowania, co w większości przypadków stanowi jedyną opcję i zazwyczaj wymaga interwencji użytkownika. Najczęściej odbywa się to w postaci załadowania nowej konfiguracji do pamięci Flash. Mechanizm to umożliwiający również musi zostać uwzględniony w trakcie projektowania i pomyślany tak, by był bezpieczny. W praktyce oznacza to, że trzeba przynajmniej pokonać barierę w postaci zapytania o login i hasło administratora, by system mógł przyjąć nową aktualizację. Jednym z producentów, który podkreśla ten aspekt jest STMicroelectronics. Firma ta poinformowała, że pracuje nad pakietem, który będzie potrzebny przy realizacji bezpiecznych aktualizacji firmware’u (Secure Firmware update). Zostanie on zaimplementowany w produktach z całej oferty firmy, z możliwością wyboru różnych rodzajów szyfrowania i autentykacji.

Ilustracja 2. Rozwiązania ST STSafe

Zalecenia

Zalecenia tego, co należy robić, by zagwarantować odpowiednie bezpieczeństwo produktu są liczne. Jednak ich wspólnym elementem jest by zacząć od podstaw i nie wahać się przed poszukaniem pomocy. Przemyślenie wszystkich sposobów, w jakie projekt może być podatny nie jest łatwe. Niekoniecznie przyjdą one do głowy projektantowi, szczególnie gdy inżynierowie dzielą swój czas na prace nad sprzętem i oprogramowaniem. Zarezerwowanie budżetu na zewnętrznego specjalistę do konsultacji może przynieść bardzo cenne wskazówki i (jak zaznaczono wcześniej) najlepiej jest to zrobić na etapie opracowywania architektury, zamiast w ramach audytu po zakończeniu głównych prac.

W odniesieniu do oprogramowania, zgodność z powszechnie akceptowanymi standardami powinna iść daleko, tak by wdrożyć zabezpieczenia przed wszystkimi dobrze znanymi metodami ataków. Niektórzy specjalistyczni producenci oprogramowania oferują narzędzia, które bazują na technikach takich jak statyczna analiza. Wykorzystuje się je w trakcie pisania kodu, by wprowadzić do kodu źródłowego fragmenty odpowiadające za zgodność z wymaganiami, jak MISRA, JSF lub HIC++. Kod zgodny z tymi standardami powinien być odporny na ataki wycelowane w konkretne urządzenia, jak próby wywołania przepełnienia stosu pamięci. Narzędzia te pomagają tworzyć bezpieczne rozwiązania, ale samo zagwarantowanie zgodności ze standardami nie jest wystarczające. Jest konieczne, ale trzeba podejmować także inne zabiegi.

Bezpieczeństwo w układach z rdzeniem ARM

Biorąc pod uwagę udział mikrokontrolerów opartych o rdzenie ARM w rynku systemów wbudowanych, jest wysokie prawdopodobieństwo, że w dowolnym tworzonym projekcie znajdzie się rdzeń ARM. Firma ARM rozszerzyła swoją technologię TrustZone by objąć nią nie tylko rdzenie serii Cortex-A, ale też mikrokontrolery z rdzeniami Cortex-M. TrustZone pozwala stworzyć bezpieczne środowisko wykonywania kodu, począwszy od samego startowania urządzenia. Jest ucieleśnieniem koncepcji równoległego działania zaufanych i niezaufanych kontekstów w jednym systemie. Separuje się sprzętowo środowisko bezpieczne i zwykłe. To drugie program blokuje przed bezpośrednim dostępem do zasobów przypisanych do środowiska bezpiecznego. Przedstawiciele firmy ARM mówią: „Technologię TrustZone w rdzeniach Cortex-M wykorzystuje się by chronić firmware, obwody peryferyjne oraz wejścia i wyjścia, a także zapewnić izolację na potrzeby bezpiecznego startowania systemu, jego zaufanej aktualizacji i stanowi podstawę do tworzenia bezpiecznych implementacji oprogramowania. Jednocześnie zapewnia deterministyczne reakcje systemu, zgodnie z rygorami czasu rzeczywistego, których oczekuje się od rozwiązań wbudowanych.”

Ilustracja 3. Ogólna idea technologii ARM TrustZone (https://www.arm.com/products/security-on-arm/trustzone)

Mikrokontrolery przeznaczone na rynek systemów wbudowanych zazwyczaj obejmują cechy, które mają uprościć implementowanie funkcji bezpieczeństwa. Są więc zoptymalizowane sprzętowo, by działały na nich algorytmy szyfrowania. Równie ważne jest, że producenci mikrokontrolerów zazwyczaj dostarczają bloki programowe, potrzebne do zaszycia tych funkcji wewnątrz aplikacji. Przykładowo Texas Instruments, w odniesieniu do serii CC3220 z Wi-Fi i rdzeniem ARM –  koncentruje się na zapewnieniu bezpieczeństwa na całej drodze pomiędzy komunikującymi się ze sobą urządzeniami. „… w IoT oznacza to, że mówimy o bezpieczeństwie układu scalonego, transmisji bezprzewodowej, serwera i aż do samej chmury”. Firma podkreśla, że bezpieczeństwo projektu (a w tym i łączności bezprzewodowej) musi być ciągłe w odniesieniu do weryfikacji użytkownika i ochrony kluczy, integralności danych oraz kodu programu, który składa się na projekt.

Pamiętaj o sprawach trywialnych

Można również skoncentrować się na aspektach bardziej subtelnych, zamiast przyziemnych. Wiele z podatności jest bardzo prostych. Niepowołany dostęp do systemu można uzyskać, ponieważ ludzie po prostu zapominają włączać mechanizmy bezpieczeństwa, albo zwyczajnie używają domyślnego hasła. „Sprawy trywialne odgrywają dużą rolę w bezpieczeństwie” – jak powiedziała jedna z osób zainteresowanych tym tematem.

Jeśli w twoim produkcie dostępny jest chroniony hasłem tryb pracy z uprawnieniami administratora, przynajmniej upewnij się, że każdy egzemplarz jest dostarczany z domyślnie ustawionym, unikalnym i silnym hasłem. Nawet jeśli projekt steruje oświetleniem lub monitoruje systemy klimatyzacji, będzie miał także dostęp do sieci IT firmy. Technik instalujący zaprojektowany przez ciebie sprzęt może pominąć ten fakt. Może też pozostawić urządzenie z hasłem „pa55word”, co nie jest idealnym rozwiązaniem.

Pod wieloma względami, nie jest to komfortowa sytuacja dla inżynierów. Nie istnieje jeden łatwy sposób na ocenę bezpieczeństwa i wskazanie niezawodnych metod poprawy zabezpieczeń. Mechanizmy aktualizacji są fragmentaryczne, a mimo to projektanci tworzą systemy, które obecnie są instalowane i będą pracować przynajmniej przez dekadę. Można spodziewać się pojawienia nowego rodzaju działań ze strony prawników, którzy zaczną analizować temat odpowiedzialności za produkt. W coraz bardziej połączonym ze sobą świecie, jak wiele uwagi poświęconej na bezpieczeństwo można uznać za „konieczne”, „adekwatne” lub „wystarczające”?

Jednakże pomoc jest pod ręką, a i sami producenci zdają sobie sprawę, że muszą nie tylko dostarczać obwody kryptograficzne i inne bezpieczne rozwiązania sprzętowe. Konieczna jest też pomoc klientom w połączeniu tego w kompletną całość.