Mit ígér és mit teljesít valójában az attesztált TLS?
Az informatikai biztonsági szakemberek éveken át formális bizonyításokkal igyekeztek alátámasztani, hogy az attesztált TLS-protokoll tényleg garantálja-e azt, amit a gyártók állítanak. A kutatók a ProVerif nevű eszközzel szimulálták a lehetséges támadási vektorokat, és kiderült, hogy a protokoll valójában csak részben tölti be a rendeltetését.
Két tanulmányban, függetlenül és más kutatókkal együttműködve, egymástól eltérő, de egyező eredmények születtek: a tesztelt protokollokat diverzióval, azaz csomagok eltérítésével lehet támadni. Egy kliens úgy hiheti, hogy az adatokat egy adott, ellenőrzött szervernek küldi, de közben egy kompromittált, azonos szoftvert futtató szerver kapja meg bárhol a világon, mindez teljesen láthatatlan marad a felhasználó számára. A protokoll ugyanis csak a szoftver integritását, nem pedig annak fizikai helyét vagy tényleges identitását ellenőrzi.
A bizalom három szintje – és a határok
A jelenség lényegét három szintre bontották:
– Az első szint csak az elsődleges kulcscseréhez kötött attesztációt tesz lehetővé, amikor még egyik fél sem igazolta magát teljesen.
– A második szint a kliens kézfogás során használt forgalmi kulcsához kapcsolja a bizonyítékot, már közelebb kerülve a szerver identitásához.
– A harmadik, legerősebb szint a tényleges adatforgalmi kulcshoz kötné a hitelesítést – ehhez viszont jelenleg egyik tervezett vagy implementált mechanizmus sem kínál megoldást: a bizonyíték már korábban elhagyja a rendszert, mielőtt a végső kulcs létrejönne.
A vizsgált hét kötési mechanizmus közül három érte el az első szintet, egyedül a kutatócsoport új javaslata éri el a másodikat. A harmadik szint jelen állapotban elméletileg elérhetetlen az eddigi architektúrában anélkül, hogy a TLS 1.3 szabvány alapvető elemeit teljesen újragondolnák.
Nemcsak elmélet – piacvezető rendszerek is érintettek
Az intra-handshake attesztáció gyengeségei nem pusztán tankönyvi példák. Részletes elemzés alapján olyan ipari rendszerek, mint a Meta WhatsApp-hoz fejlesztett Private Processing rendszere, az Edgeless Systems Contrast megoldása, a nyílt forráskódú Cocos AI platform és a Confidential Computing Consortium tesztprojektje mind sebezhetők a relé-támadásokkal szemben. Az említett hibák évekig rejtve maradhattak, amíg a formális bizonyítási eszközök felszínre nem hozták őket.
A Cocos AI védelmi hibája 7,5-ös erősséget kapott a CVSS skálán – ez számottevőbb, mint számos korábbi, nagy figyelmet kapott memóriabiztonsági támadás (pl. BadRAM, Staleus). Mégis a sérülékenységet elsőként feltáró kutatókat késleltetéssel követte csak a szabványokat irányító testület, és a fejlesztés alá tartozó hivatalos GitHub-repozitórium kiépítése is elmaradt – így végül a felfedezésre informális úton hívták fel a szakma figyelmét.
Bürokrácia és a biztonsági gyakorlat kettőssége
Az ipari visszajelzések is mutatják, mennyire különbözik a marketing és a valóság. Németország kiberbiztonsági hatósága szerint a titkosított számítás csak egy a több védelmi réteg közül, a hozzá tartozó infrastruktúra (pl. kulcs- és identitáskezelés) sebezhetőségeit nem orvosolja önmagában. Ez pontosan visszhangozza a kriptográfiai elemzés fő üzenetét: a hardverbe fektetett bizalom eredendő, ám minden, erre épülő szoftveres garancia csalóka lehet.
Az Intel, saját TDX technológiáját védve, leszögezi: nem tartja magát akadálynak a szuverenitás szempontjából, mivel nem lát rá az adatokra, és a végső bizalmi döntés átadható független auditoroknak. Viszont arról a kérdésről, hogy a 2024-es RISAA törvény alapján az amerikai állam titkosított utasításokkal utasíthatja a hardvergyártót, nem adott választ.
Megelőző lépés nélkül nincs teljes biztonság
Az IETF szabványosítási munkacsoportja, amely a Secure Evidence and Attestation Transport (SEAT) protokoll fejlesztéséért felelős, meghatározó kriptográfiai követelménnyé emelte a kutatási eredmények által feltárt korlátozásokat. Ugyanakkor sem az ipari, sem a gyártói oldal nem volt hajlandó elismerni a szűkre szabott bizalmi garanciákat.
Az igazi kérdés tehát nem csupán az, mely cég birtokolja a felhőt vagy mely kormány képes beavatkozni a hardvergyártásba, hanem hogy maga a protokoll képes-e valóban bizonyítani: a terhelés ténylegesen ott fut, ahol állítják.
Az egyetlen megoldás: újragondolni mindent?
Az eddigiekkel ellentétben már világos: a jelenlegi intra-handshake attesztációs megközelítés technikailag nem erősíthető a maximumig – egyszerűen a létrejövő titkosítókulcs létrejötte után a bizonyíték már elküldésre került. Egyedül a kézfogás utáni attesztáció adhat reményt a legerősebb, ténylegesen hiteles adatvédelmi szint elérésére, még ha ez bonyolultabbá is teszi a rendszert.
A végkövetkeztetés egyértelmű: a bizalmi protokoll jelen formájában csak részleges védelmet ad – az igazi, teljes adatbiztonsághoz más, alaposabban felépített megközelítés szükséges.
