Intel romansuje z Fundacją Linux. Będzie udawać, że zależy mu na prywatności użytkownika

Rozpoczynając Open Source Summit w San Diego, Fundacja Linuksa ogłosiła powstanie nowego porozumienia. Confidential Computing Consortium, bo o nim tu mowa, ma być inicjatywą wspierającą bezpieczne wykonywanie kodu. Brzmi to co najmniej intrygująco, prawda? Do czasu aż człowiek zda sobie sprawę, że na czele po stronie producentów sprzętu stanąć ma Intel. Wtedy robi się Bareja. Przepraszam za uszczypliwość, inaczej się nie da.

No dobra, kłamstwem byłoby stwierdzenie, że Confidential Computing Consortium to mariaż Intela z Fundacją Linuksa, bo partycypantów jest więcej, a mianowicie Arm, Baidu, Google Cloud, Microsoft, Red Hat, Swisscom i Tencent. Niemniej wśród postanowień na pierwszym miejscu wymieniono prace z technologią Software Guard Extensions, a to wręcz zaproszenie do śmieszkowania.

Ale najpierw oficjalne know-how. Konsorcjum chce pracować nad otwartoźródłowanymi rozwiązaniami w ramach Trusted Execution Environment (TEE), czyli zaufanych środowisk wykonawczych. Czym są TEE, najłatwiej wyrazić na przykładzie. Chodzi o to, aby wykonać program w izolacji od głównego systemu operacyjnego i przestrzeni użytkownika. I tak, na przykład, w procesorach ARM z technologią TrustZone każdy rdzeń fizyczny wykorzystuje wirtualizację do stworzenia dwóch rdzeni wirtualnych.

Pierwszy z tych rdzeni, zwany Światem Normalnym, prowadzi główny system operacyjny, którym na ogół jest Android, a także aplikacje użytkownika. Drugi natomiast, aka Świat Bezpieczny, ma własny mikrosystem Secure OS i wykona tylko ten kod, który został podpisany certyfikatem bezpieczeństwa. Operuje w izolowanej enklawie pamięci, a za przełączanie kontekstu odpowiada tzw. Monitor. W ten sposób obsługiwane są wszelkie DRM-y, jak również poświadczenia na poziomie sprzętowym czy Secure Boot. Krótko – wszystko to, co powinno być jak najdalej przestrzeni użytkownika.

Nowo utworzone Confidential Computing Consortium obiecuje wspierać tego rodzaju projekty, zgłaszając chęć szerszego wykorzystania Microsoft Open Enclave SDK czy Red Hat Enarx, środowisk do budowy TEE. To bardzo szczytna idea. Tylko, czy teraz możemy poczuć się bezpieczniejsi, czy może jedynie ktoś próbuje mamić nas uśmiechem a la konsultantka kredytowa?

Nie bez kozery we wstępie zahaczyłem Intela, i to nie tylko dlatego, że jego Software Guard Extensions (SGX) widnieje na pierwszej pozycji listy postanowień Confidential Computing Consortium. Akurat zaufane środowisko niebieskich jest żywym dowodem na to, że zachęcająca teoria nie zawsze idzie w parze z praktyką. Oto opis, jaki widnieje na oficjalnej stronie producenta:

Technicznie rzecz ujmując, Intel SGX działa na nieco innej zasadzie niż ARM TrustZone. Nie korzysta z wirtualizacji i odrębnego OS-u, ale pozwala nadrzędnemu systemowi utworzyć enklawy w pamięci o zawartości szyfrowanej algorytmem RSA, gdzie trafić może tylko kod zaufany. Następnie przyjęty zostaje model, w którym wszystko poza enklawą traktowane jest jako niebezpieczne. Nikt i nic z zewnątrz nie ma tam dostępu, włącznie z procesami systemu operacyjnego i modułem hipernadzorcy.

Cóż, tak przynajmniej życzyliby sobie niebiescy. W rzeczywistości bezpieczeństwo SGX zostało już kilkukrotnie podważone. W marcu 2017 roku naukowcy z Uniwersytetu w Grazu zaprezentowali, jak można wyciągnąć klucz prywatny z pamięci podręcznej. Natomiast w lutym 2019 roku temu samemu zespołowi udało się załadować do enklawy szkodliwe oprogramowanie – a gdy już tam trafiło, wszystkie antywirusy siłą rzeczy okazały się bezsilne. W międzyczasie wyszła jeszcze na jaw luka Foreshadow, związana bezpośrednio z SGX i chronioną przestrzenią adresową. Jak ustalono, analiza wzorów bitowych przyjęcia i transkrypcji danych przez SRAM umożliwia pobranie całej zawartości pamięci L1, a w konsekwencji także danych chronionych przez funkcję SGX.

Tak czy inaczej, to można byłoby wybaczyć. Rzucę truizmem, ale dziury się po prostu zdarzają. Taka natura odwiecznej rywalizacji na linii crackerzy-przedsiębiorstwa, że na każde rozwiązanie znajdzie się kontr-rozwiązanie. Kłopot w tym, że od 2006 roku, jak wiadomo, Intel serwuje nam jeszcze ustrojstwo zwane Management Engine. W każdym procesorze siedzi sobie zupełnie legalny backdoor.

Jeśli nie znacie sprawy, to tłumaczę. Współczesne czipy realizują kod na różnych poziomach uprzywilejowania, określanych terminem pierścieni. Systemy operacyjne, takie jak Windows czy Linux, znajdują się w warstwie 0. Ponad nimi znajdują się uruchamiane programy, a pod nimi, odpowiednio – powłoka sprzętowa, UEFI i właśnie Management Engine. Tymczasem uprawnienia są dziedziczone w dół. System nadzoruje program, a UEFI – i system, i program itd. Łatwo zauważyć, że w takim układzie intelowski Management Engine jest sam sobie sterem, żeglarzem i rybą.

Badacz Google'a nazwiskiem Matthew Garrett odkrył, że rolę silnika pełni uniksowy system operacyjny Minix. System-niespodzianka legitymuje się m.in. obsługą stosów protokołów TCP / IP, serwerów sieciowych i systemów plików, a ponadto może zmodyfikować firmware, a nawet pobrać wpisywane hasła. Cudownie otrzymać tak fenomenalny worek prezentów – chciałoby się rzec ;)

I oto dochodzimy do sedna sprawy. Jakże iluzoryczne są bezpieczeństwo i prywatność, gdy rozpatrujemy izolację na pierścieniu 0, mając wszystkomogącego Miniksa na pierścieniu -3. To trochę tak, jakby zainstalować w domu antywłamaniowe okna i rolety, zostawiając jednocześnie drzwi otwarte na oścież. Co oczywiste, chciałbym się w tej kwestii mylić, ale póki co Confidential Computing Consortium nie wygląda poważnie. Jeszcze tylko pytanie, co chce tutaj ugrać Fundacja Linuksa.