Bezpieczeństwo danych w systemach wbudowanych

Poziom ochrony zależy od rodzaju transmitowanych informacji. Można rozróżnić dwa ich typy, prywatne oraz chronione. Nieautoryzowany dostęp do informacji prywatnej naraża na straty tylko jedną, konkretną osobę, np. klienta banku. Informacje chronione odnoszą się najczęściej do cyfrowych treści multimedialnych udostępnianych po dokonaniu płatności. W tym wypadku brak należytej ochrony naraża na straty podmiot udostępniający te dane oraz powiązane z nim jednostki (np. grupę muzyczną).

Rys. 1. Podstawę mechanizmów bezpieczeństwa większości systemów stanowi klucz szyfrujący

Na poufność informacji składa się, oprócz bezpiecznego połączenia, także przechowywanie i przetwarzanie danych. Zabezpieczenie samej transmisji to zbyt mało, gdyż chronione zbiory mogą zostać skradzione z urządzenia, w którym są przechowywane. Przykładem może być pobieranie plików muzycznych z sieci np. na telefon komórkowy. Pomimo że proces transmisji może być dobrze zabezpieczony, co stanie się z utworami po zapisaniu w urządzeniu? Przy braku dodatkowej ochrony istnieje możliwość ich skopiowania i rozpowszechniania, co naraża cały system ochrony. Podstawę mechanizmów bezpieczeństwa w takiej sytuacji stanowi klucz szyfrujący (rys. 1). Jest to ciąg złożony z kilkuset bitów, znany tylko uprawnionym do korzystania z chronionych zasobów. Odpowiednia jego długość sprawia, że jest praktycznie niemożliwy do odgadnięcia. Klucz szyfrujący jest niezbędny, gdyż przesyłanie danych najczęściej polega na przenoszeniu pakietów pomiędzy różnymi punktami sieci aż do końcowego użytkownika. Dzięki szyfrowaniu, skradzione pakiety stają się bezużyteczne dla złodzieja.

Istnieje szereg algorytmów szyfrujących, m.in. DES (Data Encryption Standard), 3DES (Triple Data Encryption Standard) czy AES (Advances Encryption Standard), które łączy konieczność wymiany klucza w sposób bezpieczny, np. offline. Problem klucza nie ogranicza się tylko do jego wymiany, ale także do jego przechowywania, szczególnie gdy jest on identyczny dla dużej liczby urządzeń. Ponieważ w sieci mogą pracować setki urządzeń, zarządzanie wszystkimi kluczami szybko okaże się zadaniem bardzo trudnym lub wręcz niemożliwym.

Rozwiązanie stanowi algorytm uzgadniania klucza (Key Agreement Algorithm). Jego zaletą jest ustanawianie szyfrowanego połączenia bez potrzeby wymiany jakichkolwiek informacji w bezpiecznym kanale. Algorytm ten wykorzystuje dwa klucze: prywatny oraz publiczny. Pierwszy z nich jest zazwyczaj losowo wygenerowanym ciągiem długości setek bądź kilku tysięcy bitów. Klucz publiczny powstaje w wyniku nieodwracalnego przekształcenia wykonywanego na kluczu prywatnym. Przekształcenie to jest prostą pod względem obliczeniowym funkcją matematyczną, ale funkcja odwrotna umożliwiająca odtworzenie pierwotnej wartości w oparciu o znany wynik jest już bardzo skomplikowana.

Jej złożoność obliczeniowa czyni ją w praktyce niemożliwą do wykonania. Nawiązanie bezpiecznego połączenia rozpoczyna się od wymiany publicznego klucza oraz dodatkowych parametrów. Następnie w oparciu o klucz prywatny wyliczany jest wspólny klucz. W obu urządzeniach będzie on identyczny i może być wykorzystany do szyfrowania. Prywatny klucz jest krytycznym elementem bezpieczeństwa i nie może zostać nigdy ujawniony. Co więcej, nie można dopuścić do jego odczytania nawet przez właściciela urządzenia. Innym problemem jest brak mechanizmów weryfikacji "tożsamości" systemu, z którym ma być nawiązana komunikacja. Stwarza to możliwość podszywania się nieuprawnionym jednostkom pod wybranego użytkownika.

Poważne zagrożenie stanowi atak typu man-in-the-middle (patrz ramka - Atak typu middleman). Pojawia się w związku z tym potrzeba weryfikacji, czy klucz publiczny otrzymany w czasie nawiązywania połączenia pochodzi od uprawnionego użytkownika. Odpowiedź stanowią sygnatury cyfrowe, które również są złożone z pary kluczy: prywatnego oraz publicznego. Pierwszy z nich jest używany do szyfrowania przesyłanej wiadomości. Wynik tej operacji stanowi właśnie sygnatura. Każde urządzenie udostępniające swój klucz publiczny jest w stanie zweryfikować, czy wiadomość została podpisana przez posiadacza adekwatnego klucza prywatnego.

Gdy dojdzie do zmian w treści przesyłanego komunikatu, weryfikacja da wynik negatywny. Będzie to oznaczało, że dane zostały po drodze zmodyfikowane i pochodzą od kogoś innego (rys. 2). Ponownie powraca kwestia tajności klucza prywatnego używanego do tworzenia sygnatur, bo tylko w ten sposób można uniknąć fałszerstwa. Przykładowe algorytmy obsługujące system certyfikatów to RSA, DSA (Digital Signature Algorithm) czy ECDSA (Eliptic Curve Signature Algorithm).

Niestety, sygnatury nie rozwiązują wszystkich problemów, gdyż wymagają bezpiecznego kanału wymiany klucza publicznego do ich weryfikacji. Bez tego nie ma możliwości sprawdzenia, czy otrzymany klucz pochodzi od zaufanego urządzenia. W praktyce rozwiązanie tego problemu stanowi urząd certyfikacji CA (Certificate Authority).

Jest on traktowany przez wszystkie urządzenia pracujące w sieci jako jednostka zaufana. Rola CA polega na generowaniu i dystrybucji certyfikatów składających się z dwóch elementów dla wszystkich użytkowników. Pierwszym elementem jest sygnatura wygenerowana przy użyciu klucza prywatnego należącego do urzędu certyfikacji na podstawie klucza publicznego urządzenia oraz jego numeru identyfikacyjnego. Drugą część stanowią informacje takie, jak klucz publiczny i numer seryjny. Każdy, kto zna klucz publiczny CA, jest w stanie zweryfikować autentyczność certyfikatu, tzn. sprawdzić, czy urządzenie o danym identyfikatorze rzeczywiście używa określonego klucza publicznego. Pozyskanie certyfikatu wymaga wysłania do centrum autoryzacji klucza publicznego, numeru seryjnego oraz innych, potrzebnych informacji (rys. 3). Zazwyczaj CA sprawdza, czy może przyznać certyfikat, czy nie. Certyfikaty rzadko ulegają zmianom i bywają przydzielane w trybie offline.

Warta rozważenia jest kwestia czasu systemowego. Większość urządzeń daje możliwość zmodyfikowania zarówno daty, jak i godziny. Certyfikaty mogą posiadać ograniczoną ważność, która musi być porównywana z czasem systemowym. Jego zmiana mogłaby doprowadzić do posługiwania się nieważnym certyfikatem. Należy mieć na uwadze, że czas musi być zliczany także po wyłączeniu urządzenia. Istnieją jednak zastosowania, w których nie ma to większego znaczenia, gdy certyfikat jest obowiązujący w całym cyklu życia produktu.

Omówione metody ustanawiania bezpiecznego połączenia w dużej mierze oparte są na założeniu, że prywatne klucze nigdy nie zostaną skradzione przez osoby niepowołane. Słabym ogniwem może tu być fizyczne urządzenie, które je przechowuje. Na projektantach spoczywa obowiązek opracowania oprogramowania i platformy sprzętowej w taki sposób, aby żadnymi metodami nie udało się pozyskać informacji stanowiących podstawę bezpieczeństwa. Kradzież klucza jest niedopuszczalna, nawet gdy atakujący ma fizyczny dostęp do urządzenia i narzędzia do manipulowania zawartością pamięci czy śledzenia ruchu na wewnętrznych magistralach. Ma to szczególne znaczenia dla treści chronionych (np. filmów, muzyki, etc.), gdyż obejście zabezpieczeń może doprowadzić do ich nielegalnego rozprzestrzeniania.

Wymagania bezpieczeństwa są mniejsze, gdy urządzenie służy do przechowywania oraz przetwarzania prywatnych danych (np. plików, dostępu do elektronicznych usług bankowych). Za należytą ochronę kluczy odpowiada wtedy użytkownik i to on ponosi konsekwencje swoich działań. Z tego względu zalecane jest stosowanie indywidualnych kluczy zamiast jednego wspólnego, gdyż w przypadku jego utraty podatne na ataki staje się tylko jedno urządzenie, a nie wszystkie. Optymalne pod względem bezpieczeństwa są systemy SoC (System on Chip), gdyż mogą zostać zaprojektowane w taki sposób, aby zagwarantować równocześnie ochronę sprzętową i programową. Sposobem na ograniczenie dostępu do klucza może być jego zaszyfrowanie i umieszczenie w pamięci.

Użycie do tego celu znanego algorytmu, np. AES, spowoduje konieczność ukrycia kolejnego klucza, aby zabezpieczenie spełniało swoją funkcję. Inną możliwością jest zastosowanie zmodyfikowanego algorytmu bądź opracowania autorskiego. Unika się w ten sposób konieczności przechowywania klucza, a o bezpieczeństwie decyduje tajność użytego rozwiązania.

Szczególnie narażone są systemy z zewnętrzną pamięcią programu, gdyż istnieje możliwość odczytania jej zawartości i przeprowadzenie tzw. inżynierii wstecznej (ang. reverse engineering) pozwalającej odtworzyć użyty algorytm szyfrujący. Pewniejszym rozwiązaniem jest umieszczenie kluczy w wewnętrznej, strzeżonej pamięci ROM. Jest ona wbudowana w układ SoC i nie zawiera zewnętrznych wyprowadzeń, więc jest niemożliwa do odczytania przez intruza. W przypadku jej ograniczonej pojemności lub wstępnego zaprogramowania przez producenta wystarczające będzie zapisanie klucza nadrzędnego, który jest unikalny dla każdego urządzenia. Może on zostać następnie wykorzystany do zaszyfrowania innych kluczy wykorzystywanych przy ustanawianiu bezpiecznego połączenia lub generowaniu sygnatur.

Niebezpieczeństwo pojawia się podczas kopiowania klucza do pamięci operacyjnej RAM na czas pracy systemu. Dane są transportowane do zewnętrznej pamięci, więc magistrala może być monitorowana. Ponownie najlepszym wyjściem jest umieszczenie pamięci RAM lub jej części wewnątrz układu SoC (rys. 4). Unika się tym samym transportowania poufnych danych przez magistralę. W pozostałej części pamięci mogą być przechowywane ogólnie dostępne informacje lub można ją wykorzystać jako bufory przeznaczone do obsługi portów komunikacyjnych, które muszą być współdzielone z różnymi aplikacjami. Obowiązkowo należy wykluczyć odwoływanie się aplikacji użytkownika do fragmentu pamięci przechowującego hasło.

W związku z tym firmware oraz układ MMU muszą być przygotowane w taki sposób, aby tylko proces z odpowiednimi uprawnieniami mógł uzyskać dostęp do chronionego obszaru. Co zrobić w momencie, gdy proces mniej uprzywilejowany chce zaszyfrować dane, aby np. przesłać je w sieci? Istnieje kilka sposobów rozwiązania tego problemu. Przykładowo, proces nieuprzywilejowany umieszcza dane w wyznaczonym buforze, do którego dostęp nie wymaga specjalnych uprawnień i ustawia odpowiednią flagę. Spowoduje to uruchomienie procesu z prawami dającymi dostęp do klucza szyfrującego, który zakoduje zawartość bufora i umieści ją w buforze wyjściowym. Dane te będą wtedy dostępne dla procesu bez specjalnych uprawnień.

Opisana metoda ma pewien słaby punkt – zmiana firmware'u producenta na wersję opracowaną przez włamywacza może doprowadzić do ujawnienia klucza. Powstaje zatem konieczność ochrony przed takimi praktykami. Pomocny okazuje się program ładujący (Secure Boot-Loader) umieszczony w wewnętrznej pamięci ROM układu SoC, co czyni go niemożliwym do zmiany lub modyfikacji. Po uruchomieniu systemu następuje pobranie z zewnętrznej pamięci sygnatury zapisanej przez producenta oraz programu. W urządzeniu zapisany jest klucz publiczny, który umożliwia weryfikację oprogramowania pod względem zgodności z zapisaną sygnaturą (rys. 5). Dopiero po stwierdzeniu autentyczności następuje jego uruchomienie. Fałszerstwo jest praktycznie niemożliwe, gdyż potrzebny byłby klucz prywatny, a ten jest w posiadaniu producenta.

Najbardziej radykalnym sposobem ochrony jest zastosowanie układu wykrywającego ingerencję w część sprzętową. System SoC może być rozbudowany o moduł automatycznego i natychmiastowego usuwania zapisanych danych po stwierdzeniu takiej ingerencji. Wymaga to specjalnego źródła zasilającego na potrzeby kasowania pamięci oraz rozwiązań sprzętowych, co przekłada się na wyższy koszt urządzenia.

Bezpieczeństwo systemów OEM

W wielu przypadkach moduły sprzętowe i oprogramowanie pochodzą od różnych dostawców. Rolą producenta jest opracowanie końcowego urządzenia na bazie dostarczonych modułów i jego sprzedaż na rynku. W interesie producenta leży nieujawnianie klucza współpracującym podmiotom, w tym dostawcy oprogramowania. Jest to o tyle utrudnione, że niektóre funkcje wymagają dostępu do klucza, a wsparcie producenta sprzętu jest niezbędne, aby przygotować stosowne mechanizmy uniemożliwiające jego kradzież.

Pierwsze rozwiązanie tego problemu polega na wyposażeniu systemu SoC w pamięć ROM jednokrotnego zapisu i umieszczeniu w niej unikalnego, losowego numeru, który będzie używany jako klucz nadrzędny do szyfrowania kluczy stosowanych do transmisji i generowania sygnatur (rys. 6). Zadanie to wymaga współpracy z dostawcą oprogramowania, który ma obowiązek przygotowania stosownych do tego celu funkcji. Losowe ciągi stwarzają warunki do szyfrowania własnych kluczy w sposób uniemożliwiający ich kradzież nawet przez podwykonawców.

Drugim rozwiązaniem jest wyposażenie systemu SoC w pamięć programowalną, służącą do przechowywania kluczy. Jest to również korzystne dla dostawców oprogramowania i sterowników. Zyskują oni w ten sposób możliwość decydowania, w którym obszarze pamięci mają zostać umieszczone klucze. Końcowemu producentowi pozostaje wygenerowanie kluczy, sygnatury dla dostarczonego oprogramowania i zapisanie tych informacji w pamięci pod wskazanym adresem.

Podsumowanie

Znane obecnie metody zabezpieczania transmisji danych są na tyle zaawansowane, że pozwalają skutecznie ograniczyć ryzyko kradzieży poufnych informacji.

Inaczej wygląda sprawa z ich przechowywaniem. Metody za to odpowiedzialne nie są jeszcze w pełni rozwinięte i całkowicie odporne na ataki. Może to wymagać stosowania układów detekcji włamań i stowarzyszonych z nimi układów zerowania pamięci, które zniszczą dane, ale nie pozwolą ich ukraść. Wzrost poziomu bezpieczeństwa zwiększa cenę urządzenia. Znalezienie rozwiązań efektywnych pod względem kosztów ma szczególnie duże znaczenie dla posiadaczy praw majątkowych do chronionych treści, szczególnie cyfrowych zbiorów multimedialnych.

Jakub Borzdyński