Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Ataki typu side-channel na procesory w systemach wbudowanych

ghost666 30 Paź 2019 09:21 1089 7
  • Bezpieczne rejony procesora i inne zabezpieczenia stosowane dotychczasowo nie są już dostateczne w systemach wbudowanych. Sprzętowe podatności dotyczą układów w urządzeniach w motoryzacji, systemach medycznych i Internetu Rzeczy. Od stycznia 2018 znane są dwie podatności - Meltdown i Spectre - które wykorzystać można także przeciwko systemom wbudowanym.

    W przypadku urządzeń konsumenckich problemy te rozwiązują częste aktualizacje, ale w przypadku systemów wbudowanych nie jest to takie proste, ponieważ sprzęt jest o wiele trudniejszy w aktualizacji. Dodatkowo, aktualizacje ze zwiększonym poziomem bezpieczeństwa, często powodują, że spada wydajność systemu.

    Obecnie pojawia się coraz więcej kolejnych zagrożeń, takich jak Foreshadow, ZombieLoad, RIDL czy Fallout, które dotyczyć mogą także systemów w chmurze, urządzeń przenośnych jak i systemów wbudowanych.

    Ataki typu side-channel na procesory w systemach wbudowanych
    Czym są systemy wbudowane?

    Nowoczesne, wysokiej klasy procesory posiadają zaawansowane funkcje optymalizacji wydajności, które to zazwyczaj są brane na celownik przez luki bezpieczeństwa. Systemy wbudowane z kolei, zazwyczaj wykorzystują stosunkowo proste implementacje CPU.

    Jako zamknięte środowisko, układy wbudowane są często ściślej kontrolowane, a przynajmniej takie powinny być. W rzeczywistości zagadnienia te poruszone zostały dopiero niedawno, np. na DVCon 2019, przy okazji rozmów o otwartych zestawach instrukcji dla procesorów, takich jak RISC-V czy MIPS. Oferować one mają przewagę nad zamkniętymi architekturami w zakresie bezpieczeństwa i zyskują coraz większe zainteresowanie ze strony przemysłu półprzewodników i społeczności urządzeń wbudowanych.

    Wbudowane procesory są wykorzystywane w wielu systemach sieciowych, takich jak fabryki, inteligentne domy, urządzenia Internetu Rzeczy (IoT), systemy medyczne i elektronika użytkowa, a także w systemach autonomicznej jazdy, do sterowania samolotów czy w innych krytycznych aplikacjach. W przeciwieństwie do powszechnego przekonania, platformy wbudowane uruchamiają oprogramowanie z wielu niezaufanych źródeł. Jako przykłady wskazać można platformy, które umożliwiają użytkownikom uruchamianie aplikacji innych firm lub uruchamianie dużych pakietów oprogramowania pochodzących od wielu dostawców i bibliotek open source. Aby zmaksymalizować wykorzystanie sprzętu krytyczne i niekrytyczne, aplikacje są wykonywane na tym samym fizycznym procesorze fizycznym. Komputer samochodowy (ECU) może na przykład wykonywać jednocześnie kod aplikacji rozrywkowych wraz z funkcjami krytycznymi dla bezpieczeństwa jazdy.

    Do niedawna bezpieczeństwo skupiało się głównie na stosie oprogramowania, RISC-V kładzie jednak nacisk na umożliwienie wdrożenia bezpiecznych platform i mechanizmów zapobiegających wpływowi niezaufanego kodu na integralność krytycznych funkcji systemu. Te funkcje zabezpieczeń są niezbędne do uwierzytelniania aktualizacji oprogramowania. Teoretycznie wszystko powinno być w porządku - niezaufane oprogramowanie może działać tylko w obrębie zdefiniowanego obszaru i nie może wykraść danych z chronionej strefy.

    Podatności - teraz nie tylko w dużych procesorach

    Niedawno naukowcy odkryli nowy typ ataku, nazwany Orc Attack, który zagraża prostym procesorom powszechnie stosowanym w aplikacjach wbudowanych. Wykazali oni, że drobne decyzje dotyczące implementacji wpływać mogą na istnienie zagrożenia. "Kluczową kwestią jest to, że nawet proste kroki projektowe, takie jak dodawanie lub usuwanie bufora, mogą nieumyślnie wprowadzać ukryte luki w niemal każdym procesorze" mówi Mo Fadiheh, członek zespołu, który odkrył ten atak.

    Ataki side-channel przerywają izolację między domenami uprzywilejowanymi i użytkownika. Szyfrowanie można obejść, a złośliwe oprogramowanie może wnioskować o tajnych danych, hasłach itp. Ujawnienie tajnych kluczy używanych do uwierzytelniania aktualizacji oprogramowania układowego może umożliwić atakującemu załadowanie własnego kodu i wykonanie go z wyższymi uprawnieniami lub zastąpienie pewnych funkcji w systemie operacyjnym. Można dodać w ten sposób backdoor dołączyć urządzenie do botnetu. "Teoretycznie haker może wykorzystać Orc Attack, aby przejąć kontrolę nad autonomicznym pojazdem lub przejąć kontrolę nad komputerami podłączonymi do sieci w Internecie Rzeczy" - mówi prof. Subhasish Mitra, członek zespołu z uniwersytetu Stanforda.

    Branża jest świadoma tych zagrożeń i aktywnie poszukuje rozwiązań. Infineon, na przykład, był zaangażowany w badania, które przyczyniły się do odkrycia ataku.

    Ataki typu side-channel na procesory w systemach wbudowanych
    Jak zapobiegać atakom?

    Udowodnienie braku mikroarchitektonicznych kanałów ataku jest złożone. Weryfikacja bezpieczeństwa sprzętu wykracza poza zapewnienie samego prawidłowego wdrożenia funkcji zabezpieczeń. Opracowanie i analiza modelu zagrożenia jest również niewystarczająca, ponieważ wymaga wcześniejszego określenia scenariuszy ataku.

    Ten sam zespół, który odkrył ten atak, opracował skuteczną metodę wykrywania luk sprzętowych podczas projektowania układu przed masową produkcją i wdrożeniem. System wykrywa luki, które mogą wynikać z samej mikroarchitektury procesora i drobnych opcji implementacji.

    "Orc Attack pokazał, że poważne ryzyko wynika często z niewinnych decyzji na poziomie projektowania układu" -mówi prof. Mark D. Hill z uniwersytetu w Wisconsin-Madison. "Dzięki nowym narzędziom, projektanci mogą być o wiele bardziej świadomi i lepiej eliminować potencjalne zagrożenia w swoich układach".

    Bezpieczeństwo jest podstawą integralności układów scalonych, obok poprawności funkcjonalnej i bezpieczeństwa. Żadne nie są niezależne. Luki w zabezpieczeniach lub trojany sprzętowe mogą na przykład zagrażać bezpieczeństwu autonomicznego pojazdu. Integralność układów ma ogromne znaczenie dla naszego społeczeństwa cyfrowego.

    Źródło: https://www.eetimes.com/author.asp?section_id=36&doc_id=1334783

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 napisał 9461 postów o ocenie 7212, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • #2
    clubber84
    Poziom 15  
    Cytat:
    Do niedawna bezpieczeństwo skupiało się głównie na stosie oprogramowania, RISC-V kładzie jednak nacisk na umożliwienie wdrożenia bezpiecznych platform i mechanizmów zapobiegających wpływowi niezaufanego kodu na integralność krytycznych funkcji systemu.
    I tak dochodzimy do punktu, gdzie optymalizacja szybkości działania systemu czy mechanizmu jest na drugim miejscu. A powinna iść w parze z optymalizacją bezpieczeństwa w układach IoT.
  • #3
    osctest1
    Poziom 19  
    Jakiś bełkot. Jak błąd w mikrokodzie i jest sprzęt co ew to będzie wykrywać i zabezpieczać, to ten sprzęt zabezpieczający sam będzie miał mikrokod, bufory i inne pierdoły, które można pewnie wykorzystać do tego, aby obejść zabezpieczenie zabezpieczenia procka. Wtedy trzeba będzie dodać zabezpieczenie zabezpieczenia, które to będzie potrzebować czegoś co sprawdzi czy samo nie jest podatne na ataki itd itd.

    Dawajta elektronikę składania w Chinach, a na pewno zawsze będzie wracać wyprodukowane super i bez prób szpiegowania. Pozdrowienia.

    Szczególnie bezpieczne mi się widzą te uK i uP RISC-V zaprojektowane w ChRLD. Będą na pewno pozbawione furtek a zabezpieczenie mikrokodu i secure boot będzie nie do przejścia dla chińskich szpiegów. ROTFL
  • #4
    Jacek Rutkowski
    Poziom 26  
    clubber84 napisał:
    Cytat:
    Do niedawna bezpieczeństwo skupiało się głównie na stosie oprogramowania, RISC-V kładzie jednak nacisk na umożliwienie wdrożenia bezpiecznych platform i mechanizmów zapobiegających wpływowi niezaufanego kodu na integralność krytycznych funkcji systemu.
    I tak dochodzimy do punktu, gdzie optymalizacja szybkości działania systemu czy mechanizmu jest na drugim miejscu. A powinna iść w parze z optymalizacją bezpieczeństwa w układach IoT.

    Wolę żeby sterownik dłużej myślał np. przy sterowaniu ogrzewaniem czy oświetleniem i więcej energii zużył niż np. przegrzał dom czy wygasił ogrzewanie na wiele dni.
    O sterowaniu wind, ruchomych drzwi czy nie daj Boże inteligentnych/autonomicznych autach gdzie kierowanie, przyspieszanie czy hamowanie może być zhakowane już nie wspomnę...
  • #5
    clubber84
    Poziom 15  
    Jacek Rutkowski napisał:
    clubber84 napisał:
    Cytat:
    Do niedawna bezpieczeństwo skupiało się głównie na stosie oprogramowania, RISC-V kładzie jednak nacisk na umożliwienie wdrożenia bezpiecznych platform i mechanizmów zapobiegających wpływowi niezaufanego kodu na integralność krytycznych funkcji systemu.
    I tak dochodzimy do punktu, gdzie optymalizacja szybkości działania systemu czy mechanizmu jest na drugim miejscu. A powinna iść w parze z optymalizacją bezpieczeństwa w układach IoT.

    Wolę żeby sterownik dłużej myślał np. przy sterowaniu ogrzewaniem czy oświetleniem i więcej energii zużył niż np. przegrzał dom czy wygasił ogrzewanie na wiele dni.
    O sterowaniu wind, ruchomych drzwi czy nie daj Boże inteligentnych/autonomicznych autach gdzie kierowanie, przyspieszanie czy hamowanie może być zhakowane już nie wspomnę...

    To żeś teraz dał przykład...
    Właśnie w autonomicznych autach szybkość działania algorytmów/systemu powinna być na pierwszym miejscu albo równocześnie z optymalizacją bezpiecznego dostępu do systemu tylko przez użytkownika.
    Od szybkości działania modułów odpowiadających za bezpieczeństwo zależeć będzie czyjeś zdrowie i życie.
    Dlatego ja nie chcę, żeby np. moduł hamowania myślał dłużej nad rozpoczęciem hamowania niż ja bym tego oczekiwał.
  • #6
    osctest1
    Poziom 19  
    clubber84 napisał:
    Od szybkości działania modułów odpowiadających za bezpieczeństwo zależeć będzie czyjeś zdrowie i życie.
    Dlatego ja nie chcę, żeby np. moduł hamowania myślał dłużej nad rozpoczęciem hamowania niż ja bym tego oczekiwał.
    No to się Kolega popisał w temacie :). Tu jest mowa o tym co się łączy ze światem zewnętrznym, systemy które takiego połączenia nie mają - nie są wrażliwe na żadne ataki (bo atak nie ma skąd przyjść - no chyba, że żona przetnie przewody hamulcowe) i żadnych zabezpieczeń nie potrzeba. Takim systemem jest na pewno system hamulcowy - raczej poleceń przez internet mu Kolega nie wydaje.

    To tak jak komputer PC - bez podłaczenia z internetem,bez instalowania softu niewiadomego pochodzenia nie potrzebuje żadnych firewalli, antywirusów i innych wynalazków - bo po prostu nie jest narażony na żadne ataki.
  • #7
    clubber84
    Poziom 15  
    osctest1 napisał:
    clubber84 napisał:
    Od szybkości działania modułów odpowiadających za bezpieczeństwo zależeć będzie czyjeś zdrowie i życie.
    Dlatego ja nie chcę, żeby np. moduł hamowania myślał dłużej nad rozpoczęciem hamowania niż ja bym tego oczekiwał.
    No to się Kolega popisał w temacie :). Tu jest mowa o tym co się łączy ze światem zewnętrznym, systemy które takiego połączenia nie mają - nie są wrażliwe na żadne ataki (bo atak nie ma skąd przyjść - no chyba, że żona przetnie przewody hamulcowe) i żadnych zabezpieczeń nie potrzeba. Takim systemem jest na pewno system hamulcowy - raczej poleceń przez internet mu Kolega nie wydaje.

    To tak jak komputer PC - bez podłaczenia z internetem,bez instalowania softu niewiadomego pochodzenia nie potrzebuje żadnych firewalli, antywirusów i innych wynalazków - bo po prostu nie jest narażony na żadne ataki.

    Oczywiście, że z "internetem" w autonomicznym aucie łączy się tylko jeden moduł... proszę zapytać o to producenta TESLI. :lol:
  • #8
    Jacek Rutkowski
    Poziom 26  
    osctest1 napisał:
    clubber84 napisał:
    Od szybkości działania modułów odpowiadających za bezpieczeństwo zależeć będzie czyjeś zdrowie i życie.
    Dlatego ja nie chcę, żeby np. moduł hamowania myślał dłużej nad rozpoczęciem hamowania niż ja bym tego oczekiwał.
    No to się Kolega popisał w temacie :). Tu jest mowa o tym co się łączy ze światem zewnętrznym, systemy które takiego połączenia nie mają - nie są wrażliwe na żadne ataki (bo atak nie ma skąd przyjść - no chyba, że żona przetnie przewody hamulcowe) i żadnych zabezpieczeń nie potrzeba. Takim systemem jest na pewno system hamulcowy - raczej poleceń przez internet mu Kolega nie wydaje.

    To tak jak komputer PC - bez podłaczenia z internetem,bez instalowania softu niewiadomego pochodzenia nie potrzebuje żadnych firewalli, antywirusów i innych wynalazków - bo po prostu nie jest narażony na żadne ataki.

    Ciekawe to powiedz to google:
    Mapy nie działają w moim samochodzie
    Sprawdź, czy Twój samochód obsługuje tę funkcję. Oto lista samochodów, które ją obsługują (mogą wystąpić różnice w zależności od kraju):
    Audi
    BMW
    Infiniti
    Kia UVO
    MINI
    Nissan
    Toyota

    Do tych aut można wysyłać trasę na wbudowaną nawigację.
    Jesteś w 100% pewien że zajmuje się tym oddzielny fizyczny moduł a nie komputer pokładowy i nie maja żadnego fizycznego połączenia?
    Obstawiam że co najmniej przyciski są podłączone w jednej magistrali więc można się skomunikować tak jak przez oberwaną wiązkę od lusterka np. w niektórych mercedesach.