Trojan w tranzystorze, czyli atomowy sposób na szyfrowanie

17 września 2013, 23:52 | Aktualności | komentarzy 7
: oglądaj sekurakowe live-streamy o bezpieczeństwie IT.

Międzynarodowy zespół naukowców opracował bardzo interesującą i potencjalnie niezwykle skuteczną metodę wprowadzania złośliwych funkcji do komputerowych układów elektronicznych. Pomysł nie polega tu jednak na stosunkowo łatwym do wykrycia przeprojektowaniu samego układu, lecz na wprowadzeniu zmian w strukturze i zachowaniu samych tranzystorów!

Badacze przedstawili swój koncept m.in. na przykładzie opisu modyfikacji wprowadzonej do sprzętowego generatora liczb (RNG) losowych będącego częścią współczesnych procesorów Intela (instrukcja procesora RDRAND). Spójrzmy w jaki sposób możemy wpłynąć na pracę takiego układu.

Metody złośliwego modyfikowania struktury układów elektronicznych są już oczywiście znane od dłuższego czasu. Typowe zmiany w projekcie układu są stosunkowo proste do wykrycia (np. wizualna inspekcja struktury układy, analiza danych wynikowych, itp.).

Jednak wprowadzając odpowiednie modyfikacje jeszcze głębiej, czyli do wewnętrznej struktury tranzystorów, jesteśmy w stanie osiągnąć zamierzone rezultaty w sposób niemożliwy do wykrycia za pomocą tradycyjnych testów.

Dokładnie chodzi tutaj o takie domieszkowanie, czyli modyfikowanie wewnętrznej struktury półprzewodnika, by trwale i w sposób oczekiwany zmienić jego zachowanie. W efekcie takiego zabiegu możliwa jest przykładowo zmiana zachowania całego układu RNG tak, by był on bardziej „przewidywalny”.

Układ z trojanem (po prawej) kontra stan pierwotny

Układ z trojanem (po prawej) kontra stan pierwotny

Instrukcja RDRAND w zamyśle zwraca 128-bitową liczbę losową, a całe rozwiązanie Intela jest zgodne z kontrowersyjnym standardem NIST SP800-90.

Poprzez opisane powyżej modyfikacje, możliwe jest jednak ustawienie wartości wybranych bitów „na sztywno”, dzięki czemu dowolnemu zmniejszeniu ulegnie entropia (np. do 32 bitów). Tym samym mechanizmy szyfrowania danych korzystające z wyników takiego generatora nie zapewnią nam już oczekiwanego bezpieczeństwa…

Jak już wspomniałem, tego typu modyfikacje będą bardzo trudne do wykrycia. Nie pomoże tutaj ani procedura BIST (Built-In Self Test) wbudowana w CPU, ani nawet mikroskopowa weryfikacja całej struktury chipu. Generator z trojanem pozytywnie przechodzi również testy z wykorzystaniem zalecanych przez NIST zbiorów danych testowych.

Na koniec pozostaje oczywiście pytanie o możliwość oraz opłacalność praktycznego zastosowania takiego ataku. Czy jest to jedna z metod stosowanych przez NSA w celu skutecznego obchodzenia algorytmów szyfrowania danych, a może Chińczycy „instalują” tego typu trojany we wszystkich CPU opuszczających jedyną chińską fabrykę Intela?

Oczywiście sceptycy słusznie zauważą, że opisane powyżej rozwiązanie nie jest możliwe do osiągnięcia prostymi środkami i wymaga od potencjalnego intruza sporych nakładów, a bardziej realnym zagrożeniem może być dla nas przysłowiowa „kryptoanaliza gumowej pałki”.

Niemniej jednak, biorąc pod uwagę najnowsze doniesienia o programach masowej inwigilacji oraz przechwytywaniu transmisji szyfrowanych, warto zdawać sobie sprawę z tego typu nowych potencjalnych zagrożeń.

– Wojciech Smol, (wojciech.smol<at>sekurak.pl)

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. MarcinM

    Zastanawiam się jak to jest możliwe, że nie da się wykryć słabego RNG. Nie wystarczy wylosować liczbę odpowiednio dużo razy, aby sprawdzić jakość losowości? Przecież jeżeli zamiast 128 bitów entropi mamy tylko 32 to powinno być to widoczne.

    Odpowiedz
    • MarcinM,
      Wynikowa liczba losowa nadal będzie się zmieniać, ponieważ nawet jeśli zostaną nam 32 „działające” bity, to sumaryczne wyniki ze wszystkich bitów będą przecież zmienne. Poza tym, kiedy po raz ostatni przyglądałeś się niskopoziomowym wynikom wylatującym z RNG wbudowanego w Twoje CPU?

      Dodatkowo, nie ma tutaj mowy o tym, że ta metoda jest zupełnie niewykrywalna, tylko o tym, że jest ona niewidoczna dla typowych stosowanych obecnie metod weryfikowania tego typu układów oraz testów przewidzianych w ramach standardów, z którymi ten konkretny RNG jest zgodny.

      Odpowiedz
  2. Magia :) i nic nie rozumiem.

    Odpowiedz
  3. MateuszM

    Czy ja dobrze zrozumiałem, że „zainfekować” można się (a raczej swój CPU) tylko w fabryce?

    Pytanie drugie ale nieco ważniejsze: co się stanie z firmą (np. Intel, AMD, …) po przyłapaniu jej na takim procederze? Nie ma możliwości, żeby przy tak znaczącej ilości produkowanych procesorów, na dłuższą metę nie udało się wykryć takiego działania. No i jeszcze pracownicy mogą sypnąć. Producent nakryty na psuciu swoich układów straci wiarygodność i zbankrutuje. Zatem gra jest bardzo ryzykowna.

    No i ostatnia kwestia. Przy tak ogromnym poziomie skomplikowania układów scalonych np. CPU, nie da się uniknąć innych błędów, niecelowych. Owszem jest QA i testy ale czasem zdarza się, że coś źle działa i następnej generacji jest poprawione.

    Odpowiedz
    • MateuszM,
      Tak, generalnie po wyjściu z fabryki raczej nasz CPU się tego typu trojanem zainfekować już nie może :).

      Wiele wielkich firm zostało już de facto na współpracy ze służbami „złapane” i nadal sobie spokojnie prosperują. Pewnie w wypadu opisanym powyżej producent mógłby się po prostu tłumaczyć jakimś niezamierzonym błędem w procesie produkcyjnym…

      Odpowiedz
  4. MateuszM

    Wojciech Smol, czyli cel takiego działania to zaaplikowanie „back door-a” i rżnięcie głupa, że nic się nie dzieje. Czy nie łatwiej uchwalić ustawowo, że wszystkie procki mają wydzieloną jednostkę np. o nazwie NSA czy KGB (coś jak ALU), służącą tylko i wyłącznie szpiegowaniu i sabotażowi? Nie wiem po co ta cała obłuda. Oczywiście nic jeszcze nie udowodniono więc rozmawiamy czysto teoretycznie.

    Odpowiedz
    • MateuszM,
      Obywatele są chyba jednak nieco bardziej spokojni, gdy stosowane metody inwigilacji są bardziej subtelne niż to opisałeś :). Nie bez powodu np. dokumenty dotyczące programów PRISM i jemu podobnych były przecież objęte tajemnicą państwową.

      Odpowiedz

Odpowiedz na MateuszM