Czy naprawdę nie można powiedzieć, co robi procesor? [Zamknięte]

24

Programiści komputerowi często recytują mantrę, że instrukcje x86 są całkowicie nieprzejrzyste: Intel mówi nam, że coś robią, ale nie ma nadziei, że każdy może sprawdzić, co się dzieje, więc jeśli NSA powie im, aby wycofali się z RNG, to nie możemy tak naprawdę zrób coś z tym.

Uważam, że programiści komputerowi nie mogą nic poradzić na ten problem. Ale jak zaatakowałby to inżynier elektryk? Czy istnieją techniki, które inżynier elektryk mógłby zastosować, aby sprawdzić, czy obwód faktycznie wykonuje operacje opisane w specyfikacji i żadnych innych operacji?

użytkownik14717
źródło
5
Będziesz musiał zrobić coś takiego jak xray the die i przeanalizować wszystko, aby zobaczyć, co faktycznie robi. Zasadniczo dokonaj inżynierii wstecznej układu i uwzględnij funkcję każdego obwodu. Całkowicie niepraktyczne.
DKNguyen
7
Żaden obwód elektryczny nie działa dokładnie z powodu hałasu i niewielkiej możliwości, że pewnego dnia pojawi się usterka, która będzie „wystarczająco duża”.
Andy aka
5
Zabawna informacja: jest to niejasno związane z demonem Laplace'a .
Harry Svensson
6
Łatwiej będzie ukraść wewnętrzne dokumenty z bazy danych Intela niż odwrócić inżynierię nawet jednego nowoczesnego, złożonego procesora Intel.
las
14
@Postrzegasz, że twoje podejście jest niekonstruktywne, a twoje twierdzenie, że backdoora nie da się ukryć w sprzęcie, nie jest prawdziwe.
pjc50

Odpowiedzi:

14

Najlepszy artykuł, jaki przeczytałem na ten temat, to „Stealthy Dopant-Level Hardware Trojans” (Becker i in.) Z 2014 roku.

Ponieważ zmodyfikowany obwód wydaje się uzasadniony na wszystkich warstwach okablowania (w tym na wszystkich metalach i polikrzemu), nasza rodzina trojanów jest odporna na większość technik wykrywania, w tym drobnoziarnistą inspekcję optyczną i sprawdzanie pod kątem „złotych chipów”. ​​Pokazujemy skuteczność naszego podejścia poprzez umieszczenie trojanów w dwóch projektach - cyfrowym przetwarzaniu końcowym pochodzącym z kryptograficznie bezpiecznego projektu Intel RNG stosowanego w procesorach Ivy Bridge oraz implementacji SBox odpornej na kanał boczny - oraz poprzez badanie ich wykrywalności i ich wpływu na bezpieczeństwo.

W artykule opisano, w jaki sposób dokonano zmiany, jak bardzo trudno jest wykryć po sprawdzeniu krzemu, techniki ukrywania go przed testem produkcyjnym i jak można to zrobić, aby zmniejszyć bezpieczeństwo sprzętowego szyfrowania RNG lub wyciec kluczowe informacje poprzez boczny kanał szyny zasilającej wdrożenia AES.

Kanały boczne to nowe pole zainteresowań. Intel nękają problemy związane z wykonywaniem spekulacyjnym, wycieku informacji z pamięci, które nawet nie były używane przez program. Czy to może być celowa wada projektowa? Prawie niemożliwe jest powiedzieć.

pjc50
źródło
Czy kanał boczny nie wymagałby jakiegoś nadajnika do wysyłania informacji do NSA? W przeciwnym razie na pewno zauważę, że ktoś mierzy prąd szyny zasilającej na moim laptopie podczas pracy nad nim.
Dmitrij Grigoriew
24

Czy istnieją techniki, które inżynier elektryk mógłby zastosować, aby sprawdzić, czy obwód faktycznie wykonuje operacje opisane w specyfikacji i żadnych innych operacji?

Teoretycznie tak, myślę, że jest to możliwe. Jednak w przypadku złożonego procesora zajmie to dużo czasu i pieniędzy. Ponadto, jeśli nie w pełni znasz i nie rozumiesz projektu, nie będziesz w stanie ocenić, czy jakiekolwiek działanie jest „legalne”, czy nie.

Procesor jest „tylko” złożonym układem cyfrowym składającym się z wielu komórek logicznych.

Możliwe jest wykonanie inżynierii wstecznej układu i zrekonstruowanie projektu poprzez obserwację metalowych połączeń. Może istnieć wiele takich warstw połączeń, na przykład do 8 warstw lub więcej.

Będziesz potrzebować ekspertów w tej dziedzinie, aby rozpoznać komórki logiczne, a następnie może niektóre programy mogą dowiedzieć się, w jaki sposób są one połączone, abyś mógł zrekonstruować listę sieci.

Gdy masz już listę sieci, „znasz” projekt. To nie znaczy, że teraz już wiesz, jak to działa!

Może się zdarzyć, że pewna funkcja aktywuje 2 sekcje projektu, podczas gdy uważasz, że jedna powinna wystarczyć, więc podejrzewasz, że dzieje się podejrzana aktywność. Jednak konstrukcja ma sprytną sztuczkę, o której nie wiesz, aby przyspieszyć operacje.

Bez znajomości i zrozumienia projektu wszelkie wyciągnięte wnioski mogą być błędne. Tylko inżynierowie, którzy zaprojektowali procesor, mają wszystkie informacje projektowe i mają największą szansę, aby dowiedzieć się lub zgadnąć, co się właściwie dzieje lub co powinno się wydarzyć w procesorze.

Bimpelrekkie
źródło
77
Tylko inżynierowie, którzy zaprojektowali procesor, wiedzą wszystko, co się dzieje - tak się składa, że jestem inżynierem pracującym w tej branży i oceniam to stwierdzenie jako bardzo optymistyczne :)
Eugene Sh.
18
Nie, projektanci procesorów nie wiedzieliby wszystkiego, co się dzieje - projektowanie na tym poziomie zależy od narzędzi do syntezy, a te mogą wprowadzać zachowania wykraczające poza projekt HDL. Aby wziąć pod uwagę niegodziwy przykład, wiele narzędzi FPGA pozwoli Ci skompilować analizator logiczny.
Chris Stratton
9
Inżynieria wsteczna układu z „miliardami tranzystorów” stanowiłaby wyzwanie. spectrum.ieee.org/semiconductors/processors/…
Skok napięcia
4
@Wilson Ponieważ złożone obwody (w tym procesory) będą zawierać wiele zastrzeżonych (i tajnych, opatentowanych lub opatentowanych) projektów, które nie są udostępniane ogółowi społeczeństwa, ponieważ firmy, które są właścicielami tych projektów, chcą z nich korzystać (zarabiać pieniądze). 6502 to stary projekt , nie ma już żadnych cennych informacji projektowych, więc tak, jest w pełni otwarty i dostępny dla wszystkich.
Bimpelrekkie
3
@Bimpelrekkie: Jeśli są opatentowane, z definicji nie są tajne. To jest sens patentu. Wymieniasz sekret na tymczasowy monopol.
MSalters
9

Uważam, że programiści komputerowi nie mogą nic poradzić na ten problem. Ale jak zaatakowałby to inżynier elektryk?

Nie ma dobrych sposobów na znalezienie tylnych drzwi, jednym ze sposobów na znalezienie sprzętowego backdoora byłoby przetestowanie kombinacji lub nieudokumentowanych instrukcji. Oto dobra rozmowa o kimś, kto to robi i przeprowadza audyty na sprzęcie x86 . Można to zrobić bez łamania układu. Jednym z problemów z intelem (nie jestem pewien co do innych układów) jest to, że tak naprawdę ma on procesor z Linuksem, więc na niektórych procesorach działa także oprogramowanie i nie masz do niego dostępu.

Czy istnieją techniki, które inżynier elektryk mógłby zastosować, aby sprawdzić, czy obwód faktycznie wykonuje operacje opisane w specyfikacji i żadnych innych operacji?

Istnieją sposoby przetestowania używania samego sprzętu do testowania funkcjonalności. Ponieważ x86 ma nieudokumentowaną część zestawu instrukcji, wprowadzanie backdoorów w normalnych instrukcjach byłoby niezwykłe, ponieważ wprowadzałoby to możliwość błędów (tak jakbyś miał backdoora w instrukcji add lub mult), więc pierwsze miejsce na spojrzenie będzie w nieudokumentowanych instrukcjach.

Jeśli trzeba było przetestować funkcjonalność regularnych instrukcji, można było obserwować czas potrzebny na wykonanie instrukcji, obserwować ilość energii potrzebnej do uruchomienia instrukcji, aby sprawdzić, czy istnieją różnice w stosunku do tego, czego można oczekiwać.

Skok napięcia
źródło
3
Nie zgodziłbym się, że nie jest niemożliwe, aby ktoś to zrobił, ale mało prawdopodobne. powiedzmy, że zrobiłeś backdoored zwykłą instrukcję, taką jak instrukcja add, a jeśli wykonałeś dodatkową instrukcję, powiedzmy, że otworzyła backdoora. Następnie klient opracowuje program, który ma dokładnie tę kombinację, zagląda do niego, znajduje tylne drzwi i wszyscy się wściekają, a ty zostajesz pozwany. Znacznie bezpieczniej jest umieścić backdoor w nieudokumentowanych instrukcjach (lub komputerze z Linuxem wbudowanym w procesor)
Skok napięcia w
4
IME uruchamia Minix, który nie jest Linuksem i jest znacznie mniejszy i prostszy. Linux został zainspirowany istnieniem Minix i pierwotnie używał swojego systemu plików i został ogłoszony na swojej grupie dyskusyjnej, ale wtedy były one zupełnie inne i teraz są tak bardzo.
Chris Stratton
5
@ user14717 - nieprzyjemną możliwością może być sekwencja wyzwalacza w uwięzionym natywnym pliku wykonywalnym, coś w rodzaju natywnego klienta. Ale nie ma powodu, żeby to był kod, a nie dane .
Chris Stratton
5
@ laptop2d Bugs gdzie CPU nie rób, co teoretyczne dokumentacja zestawu instrukcji powiedzie się zdarzyć cały czas ; nikt nie zostaje pozwany, zwykle: Przeczytaj na przykład sekcję errata w aktualizacji dokumentów rodziny Intel Core i7 siódmej generacji. Użycie nieudokumentowanej instrukcji natychmiast uruchomi alarm każdego badacza szkodliwego oprogramowania. Użycie nietypowej kombinacji rytmicznych ADD z właściwymi rejestrami MOV między rejestrami jest mniej prawdopodobne, aby wywołać alarm.
Marcus Müller
6
@ laptop2d Ogłuszyło mnie „osadzone linux w procesorze”. Więc przeprowadziłem trochę badań, myślę, że mówisz o silniku Intel ME. Cóż, nie działa na samym procesorze, ale na chipsecie mostka północnego. Wygląda na to, że wprowadzono wiele błędnych informacji na ten temat, patrz itsfoss.com/fact-intel-minix-case
dim
6

Jedynym sposobem byłoby zdejmowanie mikroukładu warstwa po warstwie i rejestrowanie każdego tranzystora za pomocą mikroskopu elektronowego, a następnie wprowadzanie go do jakiegoś programu symulacyjnego, a następnie obserwowanie jego działania.

Jest to w zasadzie problem czarnej skrzynki, w którym próbujesz zrekonstruować elementy wewnętrzne z pomiarów wejść i wyjść. Gdy złożoność elementów wewnętrznych lub liczba wejść / wyjść wykracza poza trywialny, następuje kombinatoryczna eksplozja, w której liczba możliwych stanów wewnętrznych staje się astronomiczna. Gdzie rzucane są liczby takie jak Googol .

Dirk Bruere
źródło
2
... i łatwiej jest ukraść projekt za pomocą socjotechniki :)
Eugene Sh.
8
Nie. Rażącym błędem tutaj jest to, że symulacja nie byłaby wystarczająca. Nawet jeśli zostały podane jest dokładny model symulacyjny, nadal nie będzie w stanie znaleźć starannie ukryty problem, bo nie masz pojęcia, jak wyzwolić go.
Chris Stratton
4
@ChrisStratton Nie nazwałbym tego błędu rażącym . Uzasadnione jest założenie, że projekt opierał się na uproszczeniach, które są fizycznie zwyczajne, np. Że nie umieszczasz tak blisko siebie dwóch śladów metalizacji, że łączą się one wystarczająco indukcyjnie, aby zmienić stan bramki MOSFET. Jest to tylko błąd, jeśli a) Twoje uproszczenia nie pasują do modelu fizycznego użytego przez projektanta lub b) projektant celowo ukrywa coś, celowo przekraczając wymagania dotyczące tych uproszczeń w nieoczywisty sposób.
Marcus Müller
7
@ChrisStratton ah, przepraszam, ok, myślę, że teraz rozumiem o co ci chodzi. Mówisz, że nawet cyfrowe / taktowane behawioralnie modele procesorów są wystarczająco złożone, aby ukryć przypadki, w których zrozumienie / założenia programisty po prostu nie mają zastosowania. To prawda. Można by udokumentować efekty prowadzące do SPECTER w dręczących szczegółach, a większość ludzi nigdy nie pomyślałaby o buforowaniu posiadania efektów ubocznych związanych z przepływem danych lub programu. W rzeczy samej!
Marcus Müller
3
Dzięki :) Twój argument przywraca na myśl cały temat formalnej weryfikacji poprawności ISA („czy ten ISA faktycznie gwarantuje, że zgodny procesor nie przyznaje uprawnień RING 0 nieuprzywilejowanemu kodowi?”) I formalnej weryfikacji HDL / RTL przeciwko takim specyfikacjom ISA (szczególnie podoba mi się ten projekt weryfikacji rdzenia procesora RISC-V ).
Marcus Müller
5

Niezwykle trudne jest udowodnienie, że procesor nie robi czegoś podstępnego. Klasycznym przykładem jest automat do głosowania. Jeśli ma w sobie choćby odrobinę, która pobiera kopię twojego głosu, a później przekracza ją dyktatorowi, w niektórych miejscach może to być dla ciebie życie lub śmierć. A udowodnienie, że wśród miliardów nie ma nawet jednego takiego, jest dość trudne.

Możesz pomyśleć o fizycznym odizolowaniu układu, więc dobrze jest zauważyć, że nie ma do niego niewłaściwych połączeń przewodów. I umieszczenie innego układu lub więcej niż jednego układu szeregowo (z różnych źródeł) w jego połączeniu sieciowym, co gwarantuje, że łączy się tylko we właściwym miejscu. Następnie włączaj i wyłączaj zasilanie po głosowaniu. I mając nadzieję, że nie ma tam nielotnych kawałków. Lub podstępne połączenia bezprzewodowe. Ale czy zaufałbyś swojemu życiu?

emrys57
źródło
5

Przesyłanie dowolnych danych do NSA będzie wymagało dostępu do sieci, więc dość łatwo będzie wykryć takie backdoor, uruchamiając system operacyjny z wyłączonymi usługami sieciowymi i sprawdzając ruch w interfejsach sieciowych. W przypadku systemu operacyjnego typu open source możliwe jest nawet uruchomienie z pełną obsługą sieci i wykrycie nieuczciwego połączenia według docelowego adresu IP, który nie będzie pasował do żadnego adresu, do którego system operacyjny mógłby uzyskać dostęp.

Backdoor oparty na RNG bez transmisji danych będzie miał bardzo ograniczoną użyteczność. O ile CPU RNG nie jest jedynym źródłem entropii, szanse, że taki backdoor zapewni atakującemu jakąkolwiek korzyść, a jednocześnie nie będzie oczywiste, są praktycznie zerowe . O ile nie upierasz się, że czajnik Russela jest na miejscu, mimo że nie ma żadnego dobrego powodu, powinieneś być w stanie zastosować ten sam argument do backdoorów sprzętowych RNG.

Dmitrij Grigoriew
źródło
5
Zakładasz więc, że przeciwnik ma czas, pieniądze i umiejętności, aby stworzyć i ukryć sprzętowego konia trojańskiego, ale pierwszą rzeczą, którą robią, jest telnet www.nsa.gov? To wydaje się bardzo naiwnym punktem widzenia.
Elliot Alderson
1
Gdyby NSA ukryła lukę, to tak, mieliby nadzieję, że ludzie wykorzystają ją rdrandlub rdseedjak sugeruje Intel: jako jedyne źródło entropii dla materiału siewnego PRNG. Linux (jądro) nie zdecydował się to zrobić za /dev/random, ale glibc / libstdc ++ 's prąd std::random_device robi wykorzystania tylko rdrandjeśli jest ona dostępna w czasie wykonywania zamiast otwierania /dev/random. Wejdź do standardowego połączenia z biblioteką z godbolt
Peter Cordes
@ElliotAlderson Jaki jest zatem twój punkt widzenia? Jak ktoś może ukraść cenne dane, nie przesyłając ich gdzieś?
Dmitrij Grigoriew
@PeterCordes std::random_devicenie jest kryptograficznie silnym RNG. Standard C ++ pozwala zaimplementować go za pomocą PRNG, skutecznie zwracając tę samą sekwencję za każdym razem , więc jest oczywiste, że nikt nie powinien używać go do szyfrowania.
Dmitrij Grigoriew
No tak, zapomniałem, że nie ma gwarancji, że to coś dobrego, xD. To jest dobre na wielu implementacjach, ale MinGW jest wyjątkiem rewelacyjna do założeń projektowych że daje równie dobre jakości liczb losowych jako platforma jest w stanie, pokonując główny cel bibliotece. (Które, jak mówisz, nie jest krypto, ale wysiewaniem PRNG do innych celów). ( Dlaczego otrzymuję tę samą sekwencję dla każdego uruchomienia ze std :: random_device z mingw gcc4.8.1? ). Byłoby to dopuszczalne na platformie bez entropii (minimalne urządzenie osadzone), ale nie na Windows x86!
Peter Cordes