Bezpieczeństwo danych w systemach wbudowanych

| Technika

Na rynku pojawia się coraz więcej urządzeń zdolnych wymieniać informacje w sieci lokalnej bądź w Internecie. Prawdopodobnie ten trend będzie ulegał dalszemu nasileniu. Możliwość komunikacji elektronicznych gadżetów między sobą niesie jednak zagrożenia związane z dostępem do publicznych sieci informatycznych. Niezbędne jest zapewnienie ochrony przesyłanych treści przed dostępem do nich osób nieuprawnionych.

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.

Rys. 2. 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

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).

X.509

Standard X.509 został opracowany przez ITU-T na potrzeby systemów z kluczem publicznym z jednokrotnym podpisem systemów z zarządzaniem przywilejami (Privilege Management Infrastructure). Definiuje m.in. format certyfikatów z kluczem publicznym, jego atrybuty, algorytm weryfikacyjny itp. W standardzie tym urząd certyfikacji przypisuje klucz publiczny do identyfikatora, którym może być np. adres e-mail bądź wpis DNS. Struktura takiego certyfikatu (w wersji trzeciej) jest następująca:

  • certyfikat:
  • wersja,
  • numer seryjny,
  • identyfikator algorytmu,
  • wystawca,
  • ważność: data wystawienia, data
  • upływu ważności,
  • podmiot,
  • informacje o kluczu publicznym podmiotu (wartość klucza, algorytm),
  • unikalny identyfikator wystawcy (opcjonalnie),
  • unikalny identyfikator podmiotu (opcjonalnie),
  • rozszerzenia (opcjonalnie),
  • algorytm wyznaczania sygnatury certyfikatu,
  • sygnatura certyfikatu.
Przykładowy, zdekodowany certyfikat wygląda następująco:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape,
L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress
=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland,
L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/
emailAddress=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:
b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:
f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:
e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:
de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:
1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:
c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:
b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:
bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:
fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:
ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:
f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:
b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:
f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:
b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:
ef:9b:bf:de:b5:22:
68:9f

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.

Rys. 3. Pozyskanie certyfikatu wymaga wysłania do centrum autoryzacji klucza publicznego, numeru seryjnego oraz innych potrzebnych informacji

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.

Atak typu middleman (Man-in-the-middle attack)

Jest to rodzaj ataku oparty na aktywnym podsłuchiwaniu. W tym przypadku atakujący nie ogranicza się jedynie do przechwytywania pakietów z danymi, ale wysyła również własne komunikaty. W normalnej sytuacji dwa urządzenia A i B ustanawiają połączenie, aby mogły się między sobą komunikować.

Atak typu man-in-the-middle w założeniu opiera się na uniemożliwieniu nawiązania komunikacji pomiędzy A i B. Zamiast tego napastnik sam ustanawia połączenie z oboma systemami. Pełni rolę hosta, zapewniając przekierowanie odebranych pakietów z jednego urządzenia do drugiego. Zyskuje tym samym możliwość analizowania w międzyczasie otrzymanych informacji bądź manipulowania nimi.

Powodzenie ataku tego typu wymaga spełnienia przynajmniej dwóch podstawowych warunków. Po pierwsze oryginalny pakiet nie może dotrzeć do odbiorcy. Odbiera go tylko napastnik i musi zapobiec odebraniu pakietu przez prawdziwego odbiorcę. Drugim warunkiem powodzenia jest przesłanie odebranego przed chwilą pakietu do urządzenia, które miało je oryginalnie odebrać. Atakujący musi być przy tym w stanie możliwie dobrze "udawać" nadawcę, aby kierowane pakiety nie zostały odrzucone jako nieprawidłowe.

Przykładowe metody przeciwdziałania tego typu atakom to:

  • stosowanie infrastruktury opartej na kluczach publicznych,
  • bardziej złożony, dwustronny proces autoryzacji,
  • niejawne klucze,
  • hasła,
  • dodatkowe zabezpieczenia (np. rozpoznawanie głosu, metody biometryczne),
  • weryfikacja poza kanałem transmisyjnym.

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.

CryptoMemory – bezpieczna pamięć szeregowa

W ofercie firmy Atmel dostępne są specjalne pamięci szeregowe EEPROM o pojemności od 1kb (AT88SC0104C) do 256 kb (AT88SC25616C). Rodzina ta ma nazwę handlową CryptoMemory i charakteryzuje się zaawansowanymi mechanizmami bezpieczeństwa. Chronią one przechowywane dane, wykorzystując algorytmy szyfrujące, hasła oraz autoryzację.

Zostały one zaprojektowane w sposób uniemożliwiający kradzież chronionych informacji, nawet po wylutowaniu układu i poddaniu go badaniom w laboratorium. Wewnętrzna pamięć została podzielona na strefy, aby umożliwić przechowywanie w jednym układzie danych producenta oraz kilku użytkowników bez możliwości wzajemnego ich odczytywania.

Dostęp do zawartości pamięci możliwy jest jedynie za pomocą wbudowanego kontrolera odpowiedzialnego za bezpieczeństwo i udaremnianie prób ataku (Tamper Protection). Pozwala on na skonfigurowanie każdej strefy w sposób niezależny i ustalenie praw do pełnego odczytu/zapisu, tylko do odczytu, tylko do zapisu lub specjalnego trybu umożliwiającego blokowanie mniejszych obszarów pamięci. Dodatkowo można niezależnie określić poziom bezpieczeństwa dla każdej ze stref:

  • brak kontroli – wybrana strefa przechowuje dane publicznie dostępne
  • ochrona hasłem – dostęp do zawartości jest uzależniony od wprowadzenia prawidłowego hasła, obowiązuje tutaj limit czterech nieudanych prób, po których strefa zostanie nieodwracalnie zablokowana
  • autoryzacja – polega ona na wymianie zaszyfrowanej wiadomości za pomocą klucza 64-bitowego i sprawdzenie, czy wiadomość została przesłana przez niezależne urządzenie
  • szyfrowanie i MAC – w tym trybie oprócz wymogu autoryzacji wprowadzono również obowiązkowe szyfrowanie przesyłanych danych za pomocą wygenerowanego 64-bitowego klucza

Mechanizm udaremniający próby włamania (Tamper Protection) uniemożliwia ominięcie zabezpieczeń poprzez uruchomienie układu w warunkach pracy niedopuszczalnych przez producenta (np. zbyt niskie napięcie zasilające). W takiej sytuacji wykryta zostanie praca poza dopuszczalnymi granicami i nastąpi bezpieczne wyłączenie układu i zablokowanie dostępu do zawartości pamięci.

Praca z CryptoMemory sprowadza się do skonfigurowania poszczególnych stref za pomocą rejestrów konfiguracyjnych. Konieczne jest ustawienie poziomu ochrony, haseł oraz kluczy umożliwiających dostęp do danych w poszczególnych strefach. Konfiguracja przebiega w sposób podobny do zapisu zwyczajnej pamięci EEPROM.

Po zapisaniu ustawień w rejestrach aktywowane są bezpieczniki (fuse) i wykonywana jest specjalna komenda powodująca zablokowanie rejestrów konfiguracyjnych. Od tego momentu nie będzie możliwe wprowadzenie zmian w ustawieniach, a układ będzie w pełni dopasowany do wymogów aplikacji, w której został użyty.

Komunikacja z układami CryptoMemory może przebiegać z wykorzystaniem asynchronicznego protokołu ISO 7816-3 T=0 stosowanego w inteligentnych kartach (smart card). Możliwa jest współpraca ze standardowymi czytnikami PS/SC dostępnymi na rynku. Drugi interfejs komunikacyjny bazuje na popularnym, synchronicznym standardzie wykorzystującym dwie linie do wymiany danych. Jest on odpowiednikiem interfejsu używanego w szeregowych pamięciach EEPROM i bazuje na 4-bajtowych komendach.

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.

Rys. 4. 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. Najlepszym wyjściem jest umieszczenie pamięci RAM lub jej części wewnątrz układu SoC

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.

Rys. 5. Program ładujący umieszczony w wewnętrznej pamięci ROM układu SoC po uruchomieniu systemu pobiera z zewnętrznej pamięci sygnatury zapisane przez producenta. W urządzeniu zapisany jest klucz publiczny, który umożliwia weryfi kację oprogramowania pod względem zgodności z zapisaną sygnaturą

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.

Rys. 6. W interesie producenta leży nieujawnianie klucza. 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ż. Jedno z rozwiązań 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

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