● news.bsdnet.hu

A technológiai beszállítók igyekeznek a bizalmas számítástechnikát (confidential computing) Európa szuverén felhőstratégiájának műszaki alapjaként bemutatni. Egy új kutatás azonban arra utal, hogy az a biztonsági protokoll, amelynek feladata a rendszer kriptográfiai megbízhatóságának igazolása, alapvető architekturális hibát tartalmazhat.   A bizalmas számítástechnika a távoli hitelesítésnek (remote attestation) nevezett mechanizmusra épül. Ennek során egy szerver kriptográfiai bizonyítékkal igazolja a kliens számára, hogy valódi, módosítatlan Trusted Execution Environmentben (TEE) fut, még mielőtt bármilyen érzékeny adat cserélne gazdát. Az Intel termékoldalai szerint a TDX „további garanciákat nyújt az adatszuverenitás és az adatirányítás számára”. A Google Cloud úgy jellemzi bizalmas számítástechnikai infrastruktúráját, hogy az „teljes, auditálható ellenőrzést biztosít az ügyféladatokhoz való hozzáférés felett”. A The Register májusban arról számolt be, hogy az operációs rendszer alatt működő, Intel- és AMD-processzorokba épített menedzsmentmotorok kívül esnek azon a vizsgálati körön, amelyet az olyan európai szuverenitási keretrendszerek, mint a SecNumCloud, ténylegesen ellenőriznek. Ez nyitva hagyta a kérdést a szilícium feletti réteggel kapcsolatban: vajon megbízható-e maga az a protokoll, amelynek bizonyítania kellene a chip hitelességét? Egy új, függetlenül ellenőrzött kutatás erre megadta a választ – és az korántsem megnyugtató. Egy protokoll, amely többet ígér, mint amennyit bizonyítani tud Muhammad Usama Sardar, a TU Dresden kutatója az elmúlt két évben azt vizsgálta formális módszerekkel, hogy a hitelesített TLS (attested TLS) valóban azt teszi-e, amit állít magáról. A ProVerif nevű, protokollok szimbolikus biztonsági elemzésére szolgáló eszköz segítségével ő és szerzőtársai arra jutottak, hogy a válasz nagyrészt: nem. Legutóbbi tanulmányuk, az Identity Crisis in Confidential Computing, amelyet Mariam Moustafa és Tuomas Aura társszerzőkkel készítettek, és amelyet az AsiaCCS 2026 konferencián mutattak be, úgynevezett eltérítési támadásokat (diversion attacks) mutatott ki két korszerű attesztált TLS-protokoll ellen. Egy eredetileg egy adott szervernek szánt kapcsolat észrevétlenül átirányítható egy másik, kompromittált gépre, amely a világ bármely pontján ugyanazt a szoftvert futtatja – úgy, hogy a kliens erről semmit sem vesz észre. A célként kijelölt szerver nem hibázik; a támadó egyszerűen kihasználja, hogy a protokoll a szoftver sértetlenségét ellenőrzi, nem pedig annak fizikai helyét. A legfrissebb tanulmány, az Intra-handshake.fail, amelyet Viacheslav Dubeyko és Jean-Marie Jacquet társszerzőkkel készítettek, és amelyet az ESORICS 2026 konferenciára fogadtak el, még tovább megy. Ez az iparág által intra-handshake hitelesítésnek nevezett megközelítést vizsgálja, amelyben a bizonyíték a TLS-kézfogás során keletkezik. A kutatók hét különböző módszert elemeztek arra, miként lehetne ezt a bizonyítékot kriptográfiailag összekötni az alapul szolgáló kapcsolattal. Egyik módszer sem képes megakadályozni az úgynevezett relay, vagyis közvetítő támadásokat. Ilyenkor a kliens ugyan egy valódi, megbízható mesterségesintelligencia-ügynök vagy szerver bizonyítékát ellenőrzi, végül azonban titkosított forgalmát egy teljesen más, rosszindulatú rendszernek küldi. Az egész elemzés abból az alapfeltevésből indul ki, hogy maga a hardver megbízható. „A bizalmas számítástechnikában eleve meg kell bízni a hardvergyártóban. Ezt semmilyen módon nem lehet megkerülni” – mondta Sardar. Ha ezt az alapvető bizalmi pontot elfogadjuk, akkor a protokollrétegnek kellett volna biztosítania minden további garanciát. A kutatás azonban azt mutatja, hogy jóval kevesebbet nyújt, mint azt eddig feltételezték. A bizalom három szintje A kutatók a problémát három, egyre szigorúbb kriptográfiai kötési (binding) szinttel írják le, amelyek az hitelesítés bizonyítékát a TLS-kapcsolathoz kötik. A leggyengébb, első szint csak a kézfogás első kulcscseréjéhez, a Diffie–Hellman lépéshez köti a bizonyítékot. Ekkor a kliens és a szerver közös titkot állapít meg, mielőtt bármelyik fél igazolná saját kilétét. A második szint már a kliens kézfogási forgalmának kulcsához kapcsolja a bizonyítékot, lefedve mindazt a kommunikációt, amely a szerver személyazonosságának megerősítéséig zajlik. A harmadik, legerősebb szint – amely gyakorlati szempontból a legfontosabb – már ahhoz az alkalmazásforgalmi kulcshoz köti a bizonyítékot, amellyel a kliens élő kapcsolat esetén ténylegesen titkosítja érzékeny adatait. Sardar részletes ProVerif-elemzése kizárólag az intra-handshake hitelesítésre koncentrált; a kézfogás utáni (post-handshake) hitelesítés kívül esett a vizsgálat hatókörén. A hét elemzett kötési mechanizmus közül három éri el az első szintet. A többi még ezt az alapkövetelményt sem teljesíti. A kutatócsoport saját javasolt megoldása – egy, a TLS kézfogási titkából és a szerver nyilvános kulcsából felépített kriptográfiai kötőelem – formálisan eléri a második szintet. A harmadik szint azonban a tanulmány szerint „lehet, hogy egyáltalán nem valósítható meg” a jelenlegi intra-handshake architektúrán belül anélkül, hogy fel ne áldoznák a TLS 1.3 olyan tulajdonságait, amelyekről a protokollt eleve nem úgy tervezték, hogy lemondjon. Egyszerűbben fogalmazva: a ma ismert legjobb javítás csak azt bizonyítja, hogy a kliens a kézfogás kezdetén a megfelelő géppel kommunikál. Azt már nem képes igazolni, hogy a percekkel később továbbított adatok még mindig ugyanarra a gépre kerülnek. Nem laboratóriumi modell, hanem éles rendszerek A sérülékenység nem csupán elméleti modellekben létezik. Sardar kutatócsoportja négy valós, intra-handshake hitelesítést használó megvalósítást elemzett formális módszerekkel: a Meta WhatsApp számára készült Private Processing rendszerét; az Edgeless Systems Contrast platformját; a nyílt forráskódú Cocos AI rendszert; valamint a Confidential Computing Consortium (CCC) Attestation Special Interest Group által fenntartott referencia-implementációt. Az első három jelenleg is éles üzemi környezetben működik. A támadások a Cocos AI valamennyi 0.4.0 és 0.8.2 közötti verzióját érintik. A hibatípus önmagában nem új, de a kutatók szerint annyira kifinomult, hogy éveken át rejtve maradt, míg a formális elemzés fel nem tárta. A felelős sérülékenység-bejelentési folyamat eredményeként megszületett a CVE-2026-33697, amely a Common Vulnerability Scoring System (CVSS) szerint 7,5 pontos, vagyis magas súlyosságú besorolást kapott. Összehasonlításként a kutatók megjegyzik, hogy a nagy visszhangot kiváltó, 2024-es BadRAM memóriacímezési támadás az AMD SEV-SNP technológiája ellen mindössze 5,3 pontot kapott. A CCC Attestation SIG adattára szerint a CVE-2026-33697 jelenleg a legmagasabb pontszámú sérülékenység a bizalmas számítástechnikát érintő közelmúltbeli hibák között, megelőzve a Fabricked (5,9), BreakFAST (5,9) és Staleus (4,0) sebezhetőségeket. Mind a CCC munkacsoportja, mind az IETF TLS munkacsoport hivatalosan elismerte a relay támadásokat. „A mai formájában a hitelesített TLS még nem tekinthető kiforrottnak” – mondta Sardar. „Folytatjuk a vizsgálatokat, és biztosak vagyunk benne, hogy további problémák is elő fognak kerülni.” A megállapítás súlyát növeli, hogy a Meta korábban a neves Trail of Bits biztonsági céggel vizsgáltatta át WhatsApp-megvalósítását, mielőtt Sardar csapata elemezte volna azt. Az audit nem fedezte fel a relay támadást. A különbség oka nem a szakértelem hiánya, hanem az alkalmazott módszertan. Az ESORICS-tanulmány szerint Sardar csapata közvetlenül felvette a kapcsolatot a Trail of Bits szakembereivel, akik megerősítették, hogy vizsgálatuk során nem alkalmaztak formális verifikációs módszereket. Az olyan eszközök, mint a ProVerif, egy protokollt teljes körűen vizsgálnak végig minden olyan forgatókönyvre, amelyet a fenyegetési modell megenged. Egy kézi biztonsági audit – legyen bármilyen alapos – szükségszerűen csak mintavételez. Emiatt egy finom hiba, amely a bizonyíték és a kapcsolat összekapcsolásában rejlik, könnyen észrevétlen maradhat, miközben formális elemzéssel bizonyíthatóan sérülékeny. A CCC Attestation Special Interest Groupja – amelynek referencia-projektjét Sardar is vizsgálta – végül maga is megállapította, hogy saját rendszere ugyanazon relay támadásokkal szemben sebezhető. A matematikát nem lehet marketinggel felülírni A sérülékenység bejelentése hosszú és szabályos folyamatban zajlott. Sardar csapata 2025 októberében értesítette a Cocos AI fejlesztőit, akik két hónappal később visszaigazolták a hibát, a CVE pedig 2026 márciusában jelent meg. Ezután azonban szokatlan események következtek. 2026. június 14-én Sardar kérte a CCC Attestation Special Interest Group vezetőitől egy új, nyilvános GitHub-tároló létrehozását, hogy a relay támadásokat bemutató formális elemzési anyagokat Apache 2.0 licenc alatt közzétehesse a kutatói közösség és a szabványosítási szervezetek számára. Három nappal később emlékeztetőt küldött, majd újabbat, később pedig már nyíltan kifogásolta a késlekedést: „Nem látok jó indokot erre a késedelemre, hiszen a kért tároló egy már elfogadott projekt része, és egy új repository létrehozása nem különösebben időigényes feladat.” Az új adattár ennek ellenére sem készült el. A CCC Attestation Special Interest Group tagjai azoknak a hardver- és felhőszolgáltató cégeknek a képviselői, amelyek termékeit a kutatás érintette. Ez önmagában figyelemre méltó tény: egy olyan munkacsoport, amelynek tagjai éppen azok a vállalatok, amelyek implementációiról bebizonyosodott, hogy relay támadásoknak vannak kitéve, több mint egy héten át és három írásos emlékeztető ellenére sem intézkedett a bizonyítékok közzétételéről. Mivel a tanulmány végleges változatának leadásáig nem jött létre az új adattár, Sardar végül egy már meglévő, CCC-hez kapcsolódó tárolóban tette közzé az elemzési anyagokat. A CVE ettől függetlenül nyilvános és hivatalosan elismert maradt. A késlekedés semmit sem változtatott a matematikai bizonyítékokon. A kutató következtetéseit a Német Szövetségi Információbiztonsági Hivatal (BSI) is lényegében megerősítette. A hivatal szerint a bizalmas számítástechnika hasznos, „többrétegű védelmi” elem, de önmagában nem képes biztosítani a digitális szuverenitást, különösen azért, mert nem oldja meg az identitáskezelési és kulcskezelési infrastruktúrától való függőséget. A BSI szóvivője ennél is egyértelműbben fogalmazott: „A gyártók túl nagy hangsúlyt tulajdoníthatnak a bizalmas számítástechnika műszaki képességeinek. Önmagában a »confidential computing« nem képes kielégíteni a digitális szuverenitás követelményeit.” Az Intel megvédte saját TDX architektúráját, hangsúlyozva, hogy hitelesítő infrastruktúrája nem fér hozzá az ügyfelek titkosítatlan adataihoz, és a bizalmi döntés független hitelesítőre vagy magára az ügyfélre is átruházható. Arra a kérdésre azonban nem válaszolt, hogy az infrastruktúra jelent-e szuverenitási kockázatot az amerikai RISAA törvény fényében, amely bizonyos esetekben titkos hírszerzési együttműködésre kötelezheti a hardvergyártókat. A Google nem reagált a lap megkeresésére. Mindenki elismeri – kivéve a marketinganyagok Sardar kutatási eredményei négy különböző intézményi reakciót váltottak ki. Az IETF Secure Evidence and Attestation Transport (SEAT) munkacsoportja – amely azután alakult meg, hogy egy Sardar részvételével működő csoport sikeresen érvelt létrehozása mellett az IETF 123 madridi konferenciájának 2025. júliusi Birds of a Feather ülésén – közvetlenül beépítette Sardar korrelációs követelményeit a munkacsoport alapító dokumentumába. Ezeket minden új szabványtervezet kötelező követelményeként rögzítették. Ez pontosan az, amit egy szabványosító szervezettől elvárható: a formális verifikációt már a szabványalkotási folyamatba építi be, nem pedig utólag próbálja hozzáilleszteni. Az IETF TLS munkacsoportja szintén hivatalosan elismerte ugyanazokat a támadásokat, saját kötelező előírást azonban nem vezetett be. A Confidential Computing Consortium (CCC) tíznapos tétlensége miatt Sardar végül saját maga tette közzé a bizonyítékokat, a munkacsoport közreműködése nélkül. Mindez azonban nem jelent meg az értékesítési kommunikációban. Az Intel és a Google továbbra is úgy reklámozza a bizalmas számítástechnikát, mint a szuverén, hitelesen ellenőrzött védelem bizonyítékát. Amikor azonban közvetlenül rákérdeztek az ezt alátámasztó infrastruktúrára, az Intel válasza nem tért ki az ügy központi jogi kérdésére. A Google pedig egyáltalán nem válaszolt. Az európai informatikai vezetők és beszerzési szakemberek számára ez új kérdést vet fel. Már nem csupán az a kérdés, hogy melyik vállalat birtokolja a felhőt, vagy melyik kormány kötelezhet együttműködésre egy adott hardvergyártót. Hanem az is, hogy egyáltalán megbízható-e az a kriptográfiai kézfogás, amelynek azt kellene bizonyítania, hogy egy adott munkaterhelés valóban ott fut, ahol állítása szerint fut. Az a biztonsági szint, amelyet az időzítés kizár Sardar saját javasolt megoldása eléri a második biztonsági szintet. A harmadik szint – amely valójában az ügyfelek számára a legfontosabb lenne, hiszen azt igazolná, hogy a munkaterhelés az adatforgalom megindulása után is védett marad – a jelenlegi intra-handshake attesztációs architektúrában valószínűleg egyáltalán nem érhető el. Ebben a megközelítésben ugyanis a bizonyíték még a TLS-kézfogás során jön létre. A problémát az időzítés okozza. A harmadik szint megköveteli, hogy a bizonyíték ahhoz a kulcshoz kapcsolódjon, amely a tényleges alkalmazásadatokat titkosítja. Mire azonban ez a kulcs létrejön, a bizonyítékot már elküldték – hacsak magát a TLS protokollt nem alakítják át jelentősen. A post-handshake attesztáció ezzel szemben kivárja ezt a pillanatot, így a kulcs már rendelkezésre áll ahhoz, hogy a bizonyíték hozzá kapcsolható legyen. „Úgy gondoljuk, hogy kizárólag a post-handshake attesztáció képes elérni a harmadik szintű kötést” – mondta Sardar. Egyúttal arra figyelmeztetett, hogy azok az újabb javaslatok, amelyek a két megközelítést próbálják ötvözni, szükségtelenül növelik a rendszer bonyolultságát anélkül, hogy valódi biztonsági előnyt nyújtanának. Az IETF TLS munkacsoportjának szóló ajánlása egyértelmű: a fejlesztőknek teljesen fel kellene hagyniuk az intra-handshake hitelesítés alkalmazásával. Forrás: https://www.theregister.com