EFF: A titkosított üzenetküldés és az AI ütközése megmarad a TEE ígéretének ellenére (2026-09-18)

Szerzők: Erica Portnoy és Thorin Klosowski (EFF, Deeplinks Blog) Forrás: https://www.eff.org/deeplinks/2026/09/secure-messaging-and-ai-remain-conflict-despite-promise-tees Megjelenés: 2026. szeptember 18. Hossz: ~1900 szó angolul → ez a magyar összefoglaló 1480 szó Típus: civil szervezeti elemzés (EFF Deeplinks) — biztonsági és adatvédelmi threat model

Összegzés

• A TEE nem titkosítás. Az EFF alaptétele: a bizalmi végrehajtási környezet (TEE) hasznos lehet, de soha nem éri el a valódi titkosítás vagy a lokális futtatás szintjét. A kettőt összemosni félrevezető, és aki ezt teszi, az a felhasználók biztonsági garanciáit hígítja.
• A különbség a matematika és a mérnöki tudomány között. A titkosítás matematikán alapul, évtizedek óta vizsgált problémákon, és nincs ismert rövid út a feltöréséhez. A TEE mérnöki megoldás: minden egyes rendszer a saját bugjaival születik, és ezeket utólag fedezik fel. Évente jelennek meg új TEE-feltörési kutatások, és a rendszer sosem lesz tökéletes.
• A mélyebb ok szerkezeti. A TEE-nél a titkosítási kulcs fizikailag ugyanazon az eszközön van, mint a rendszer többi része, amiből el kell zárni. A támadások jellemzően mellékcsatornásak (side channel): elektromos impulzusokból és időzítésből következtetnek a kulcsra. A végpontok közötti titkosításnál a kulcs sosem kerül arra a szerverre, ezért a támadónak a felhasználó eszközét is meg kellene támadnia.
• A gyakorlati szabály, amit kérnek: egy felhasználói eszköz soha ne küldjön automatikusan adatot TEE-be. Ha a felhasználó maga választja ki, mi kerül ki (akár egy „olvasatlan üzenetek” csomag), van lehetősége megállni és mérlegelni. Ha automatikus, a kiszivárogtatás a rendszer egészének jellemzőjévé válik, és egy korábban végpontok közötti titkosított rendszer megszűnik annak lenni.
• A homomorf titkosítás a matematikailag tiszta alternatíva, de senki nem tudta elég gyorsra tenni, hogy LLM-inferenciára használható legyen. Ezért választják a cégek a TEE-t, nem azért, mert az egyenértékű.
• A saját rendszerünkre nézve ez a legfontosabb következtetés: a lokális inferencia (Ollama, lokális modellek) teljesen megkerüli a kérdést, mert az adat el sem hagyja a gépet. A felhőalapú „privacy-preserving” megoldás ehhez képest mindig visszalépés, még akkor is, ha jobb a titkosítás nélküli szerveroldali futtatásnál.

Miről szól a cikk és miért most

A cikk egy egyszerű feltevésből indul: a titkosított üzenetküldő platformok (Signal, WhatsApp, és nemrég a titkosított RCS) a beszélgetés mindkét végén azt garantálják, hogy a tartalom a résztvevők magánügye. A végpontok közötti titkosítás matematikai garanciát ad arra, hogy az üzemeltető cég nem fér hozzá az üzenetek tartalmához.

A gond ott kezdődik, hogy nincs garancia arra, mi történik, miután az üzenet megérkezik a telefonra. Ahogy egyre több eszköz és szolgáltatás tesz mesterséges intelligencia funkciókat az üzenetküldő alkalmazásokba, ez a határvonal elmosódik.

Az EFF különbséget tesz az esetek között:

• Ha az AI-számítás teljesen az eszközön történik, az kevésbé aggasztó.
• Ha a számítási igény olyan nagy, hogy szerverre kell vinni, akkor az adat elhagyja az eszközt, és ez adatvédelmi kompromisszum.

Erre a cégek a TEE-t kínálják megoldásként. A cikk kérdése: ez valóban megoldja a problémát? A szerzők válasza: nem, mert a TEE és a titkosítás más, és a TEE soha nem fogja elérni a titkosítás szintjét. Ezért fogalmazzák meg a szabályt, hogy egy eszköz soha ne küldjön automatikusan adatot TEE-be.

A nagy szolgáltatók közül konkrétan megnevezik az Apple Private Cloud Compute, a Google Private AI Compute és a WhatsApp Private Processing rendszereket, és megjegyzik, hogy nem csak a nagy tech cégek építenek TEE-re chatbotokat.

Mi az a TEE pontosan

A TEE a számítógép egy megerősített szakasza, amely úgy futtat szoftvert, hogy az a gép többi folyamata elől is titkos maradjon. A TEE-k arra is lehetőséget adnak, hogy a felhasználó ellenőrizze: valóban az a kód fut, amiről azt hiszi, és nem egy hátsó ajtóval ellátott változat. Ezt a folyamatot attestation-nek (tanúsításnak) hívják. A fogalom más néven secure enclave, illetve a gyártói nevek közül az SGX és a TrustZone.

A felhőalapú TEE szándéka egyszerű: a cég futtathat egy szervert a saját adatközpontjában, és feldolgozhatja a felhasználótól kapott adatot anélkül, hogy maga látná azt.

Itt érdemes megjegyezni, hogy a TEE-k eredetileg nem erre valók. Sokféle funkciót szolgálnak, a DRM-tartalomvédelemtől a telefon mobilpénztárcájában tárolt adatok védelméig. A cikk kizárólag az AI-eszközökhöz használt változatukra koncentrál.

Biztonságos-e a TEE: matematika kontra mérnöki tudomány

A cikk érvelésének a magja ez a megkülönböztetés, és érdemes szó szerint megőrizni a logikáját.

A gyakorlatban évente látni több rést és feltörést, amelyek megmutatják, hogy lehetséges hozzáférni a TEE-ben tárolt adathoz. Ennek az az oka, hogy míg a titkosítás a matematikára támaszkodik, a TEE a mérnöki munkára.

• A szabványos titkosítási algoritmusokat évekig tartó, matematikusok világméretű együttműködésével létrehozott folyamatok alkotják, és évtizedek óta vizsgált problémákon alapulnak. A matematika megbízható, és nincs olyan rövid út a feltöréséhez, amely ne borítaná fel a matematika mint tudomány alapvetéseit.
• A mérnöki munka nem így működik. Minden egyes rendszer egy mérnökcsoport terméke, és minden terméknek megvannak a saját furcsaságai és bugjai, amelyeket egyenként kell felfedezni és javítani. Ezeket a bugokat a rendszer megépítése után találják meg, nem előtte. Még senki nem épített feltörhetetlen rendszert, és folyamatosan jelenik meg új kutatás, amely új behatolási módokat talál. A réseket javítják, ahogy előkerülnek, de valószínűtlen, hogy valaha tökéletessé válnak, és bizonyosan nem a közeljövőben.

A TEE-k különösen nehéz mérnöki probléma, mert a titkosítási kulcs fizikailag ott van az eszközön. TEE-t építeni azt jelenti, hogy a kulcsot teljesen elkülönítve és elérhetetlenül kell tartani, miközben ugyanazon a fizikai eszközön vannak a rendszer azon részei, amelyeknek nem szabadna hozzáférniük a kulcshoz.

A TEE elleni támadások sok esetben mellékcsatornásak (side channel attack). A támadó megméri az elektromos impulzusokat vagy más hatásokat, hogy kikövetkeztesse a TEE-n belüli műveletek időzítését, majd ebből a felhasznált kulcsot. Ha megvan a kulcs, az összes adat olvasható. Ezzel szemben a végpontok közötti titkosításnál a kulcs eleve nincs azon a gépen, ezért a támadónak hasonló támadást kellene futtatnia a felhasználó eszközén is.

A cikk elismeri azt is, hogy a TEE nem haszontalan. Azok a cégek, amelyek TEE-hez fordulnak, egyszerre akarják a kulcsot a szerveren tartani, védeni azt, és közben komplex műveleteket futtatni (például egy LLM-et), ami sokkal nehezebbé teszi a kulcsok védelmét. A TEE és a szerveren tárolt nyílt szöveg között mégis az a különbség, hogy az egyik adatot könnyű olvasni, a másikhoz speciális munka kell, ami gyakran a fizikai gép elérését igényli. Ez tömeges megfigyelés ellen releváns, és sok embernek ez elég biztonság lehet.

És itt jön a szerzők szerinti lényeg:

„Secure enough for most cases” és az „encrypted as in math” nem ugyanaz, és fontos, hogy a kettőt ne mossuk össze. Azok a szolgáltatások, amelyek jelenleg „matematikai titkosítást” kínálnak, valódi biztonsági visszalépést szenvednek el, amikor TEE-alapú biztonságra váltanak.

Mit köze mindennek az LLM-ekhez és az AI-hoz

Néha a szervezetek olyan LLM-et akarnak kínálni, amely bizalmas módon válaszol a kérdésekre. Léteznek eszközön futó LLM-ek, de méretben korlátozottak. Ezért fordulnak a TEE-hez, ha úgy akarnak kérdésekre válaszolni, hogy közben ne lássák a beszélgetést. Ez hasznos mód egy viszonylag privát chatbot futtatására, és ezt teszi az Apple, a Google, a WhatsApp és mások.

Felmerül a kézenfekvő kérdés: miért nem titkosítást használnak? Hiszen az LLM-inferencia is matematika, mint a számítógép bármely más művelete: bemenetet ad egy nagyon nagy függvénynek, és kimenetet kap. Van rá matematika, hogy úgy számoljunk, hogy a bemenet és a kimenet rejtve maradjon a számítást végző elől: ez a homomorf titkosítás. Csak éppen rendkívül drága, és senki nem találta ki, hogyan legyen elég gyors ahhoz, hogy ilyen számításra értelmes legyen.

A TEE vonzereje ehelyett az, hogy a számítást egy különleges, átláthatatlan szerverrészben végzi el. A TEE gyártói igyekeznek minél nehezebbé tenni, hogy a TEE-t futtató személy belenézhessen. De továbbra is meg kell bízni az üzemeltetőben, hogy nem tesz sztetoszkópot a dobozra, hogy kitalálja, mi történik odabent.

A szerzők ebből vezetik le a megfogalmazási szabályt: ezeket a rendszereket ésszerű „adatvédelem-megőrzőnek” (privacy-preserving) nevezni, de nem „titkosítottnak” (encrypted). A különbség különösen akkor fontos, amikor a TEE-k és a titkosított üzenetküldés találkoznak. Amikor egy végpontok közötti titkosított csevegőalkalmazás felhasználója arra kéri az LLM-et, hogy foglalja össze, nézze át vagy tárolja el az üzeneteit, azoknak az üzeneteknek a tartalma elhagyja az eszközt, és egy titkosítatlan harmadik féltől származó szerverre kerül. Ez komoly fenyegetés a titkosított csevegőalkalmazások magánéletére, és egyre nehezebb a felhasználónak kézben tartania.

A gyakorlati tanács

A válasz a szerzők szerint egyéni fenyegetésmodelltől (threat model) függ, de az ökölszabály világos: egy felhasználói eszköz soha ne küldjön automatikusan adatot TEE-be.

• Ha a telefont tartó ember maga választhatja meg, milyen információ kerül ki, akár egy adatcsomagot (például „olvasatlan üzenetek”), akkor van alkalma megállni és mérlegelni, hogy az az adat túl érzékeny-e a kockázathoz.
• Ha viszont az adat automatikusan megy ki, az automatikus küldés a rendszer egészének jellemzőjévé válik. Ha a rendszer korábban végpontok közötti titkosított volt, egy automatikus adatkiszivárogtatás hozzáadása az egész rendszert megszünteti végpontok közötti titkosítottként.

A cikk két címzettnek fogalmaz meg kérést:

• Fejlesztőknek: ne építsetek olyan rendszereket, amelyek automatikusan küldenek adatot az eszközről TEE-be, különösen akkor, ha az adat egy egyébként végpontok közötti titkosított alkalmazásból jön.
• Felhasználóknak: ha a fejlesztők ezt mégis megépítik, kapcsoljátok ki az automatikus adatküldő funkciókat, és szánjatok egy pillanatot annak mérlegelésére, mennyit kockáztattok, amikor adatot küldtök ki az eszközről.

Mitől kell tartani és mit nem

Az EFF nem mondja azt, hogy a TEE-k rosszak. A cikk elismeri, hogy a TEE-k számos helyzetben hasznosak a biztonság szempontjából: a telefonban valószínűleg van egy TEE, amely a biometrikus feloldást és a jelszókezelő kulcskarika alapját titkosító kulcsot tárolja. TEE teszi lehetővé bizonyos mentési rendszereket is, például hogy a telefont jelkóddal lehessen visszaállítani, vagy hogy a WhatsApp és a Signal biztonsági mentéseit helyre lehessen állítani.

A felhőalapú feldolgozás esetében viszont kulcsfontosságú tisztázni, hogy ez nem ugyanaz, mint a végpontok közötti titkosítás, és nem kínál azonos szintű adatvédelmet.

A cikk zárása a tágabb kontextust adja: magánéletünk nagy része a telefonunkon és az üzeneteinkben van. Az EFF évek óta dolgozik ezek védelmén, olyan eredményekkel, mint a titkosított RCS, és a Signal és a WhatsApp felhasználói élményének folyamatos javítása. Valódi javulás történt a biztonsági mentések védelmében is, például az Advanced Data Protection funkcióval, amely végpontok közötti titkosítást hoz az üzenetküldésen kívüli adatokra (jegyzetek, fotók). De ahogy a cégek olyan AI-funkciókat vezetnek be, amelyek ezekkel a titkosított szolgáltatásokkal érintkeznek, és adatot húznak le az eszközökről egy felhőalapú TEE-be, aláássák a végpontok közötti titkosítás adatvédelmi védelmét, és komoly zavart kockáztatnak abban, hogy mi védett és mi nem.

Forrás

• Cikk: EFF Deeplinks Blog, „Secure Messaging and AI Remain In Conflict Despite the Promise of TEEs”
• Szerzők: Erica Portnoy és Thorin Klosowski
• URL: https://www.eff.org/deeplinks/2026/09/secure-messaging-and-ai-remain-conflict-despite-promise-tees
• Megjelenés: 2026. szeptember 18.
• Hossz: ~1900 szó angolul, képek és a kapcsolódó cikkek blokkja nélkül

Kapcsolódó külső források

• Apple Private Cloud Compute, az Apple TEE-alapú felhőfeldolgozási rendszere
• Google Private AI Compute, a Google megfelelője
• WhatsApp Private Processing, a Meta megoldása az üzenetfeldolgozásra
• Homomorf titkosítás, a matematikailag tiszta, de jelenleg túl drága alternatíva
• Intel SGX és ARM TrustZone, a TEE két gyártói megvalósítása
• Advanced Data Protection (Apple), végpontok közötti titkosítás az üzenetküldésen kívüli adatokra
• Az EFF kapcsolódó cikke: „How to Limit What Apple's New Siri AI Can Access in iOS 27” (2026. szeptember 9., Jillian C. York és Eva Galperin)

Kapcsolódó belső források

• a TEE-alapú Cashu mint-üzemeltetés és a trust-minimalizálás (ugyanaz a feszültség kriptográfiai oldalról)
• a Cashu on-chain TEE mint-tesztek szekciója (RHR #412)
• a lokális modell preferencia kontextus-igény szerint
• „a privacy bináris, vagy van vagy nincs” elv
• a TEE és kapcsolódó terminusok magyar megfelelői

Hogyan kapcsolódik ez a saját rendszerünkhöz

1. A lokális inferencia teljesen megkerüli a kérdést. A cikk legfontosabb tanulsága a saját setupunkra: ha a modell a saját gépünkön fut (Ollama, lokális modellek), az adat el sem hagyja a hardvert, és nem merül fel sem a TEE, sem a felhőbizalom kérdése. A model-routing skillünk jelenlegi elve (kontextus-igény szerinti modellválasztás, lokális előnyben ahol az inferencia-minőség elfogadható) pontosan ebbe az irányba mutat. A cikk egy érvvel egészíti ki: a felhőalapú „privacy-preserving” TEE nem egyenértékű a lokális futtatással, tehát a lokális modell nem csak olcsóbb, hanem biztonságilag is más kategória.

2. A Signal-only preferencia védve van, de csak ha nincs automatikus AI-funkció. A cikk konkrétan a Signal és a WhatsApp üzeneteinek TEE-be küldéséről beszél. A mi esetünkben a kockázat akkor jelenik meg, ha egy üzenetküldő kliens olyan AI-funkciót kap, amely automatikusan (nem felhasználói választásra) küldi ki az üzeneteket. Ez konkrét, ellenőrizhető szempont egy kliens vagy funkció bevezetése előtt: automatikus adatküldés = az adott funkció kizáró ok.

3. A TEE-vita ugyanaz, mint a Cashu trust-minimalizálási vita. A wiki már tartalmazza a Cashu TEE mint-teszteket (topics/privacy-tech.md) és Calle érvelését a TEE-alapú mint-üzemeltetésről (No Solutions #29). Ott a kérdés az, hogy a mint üzemeltetője ne tudja inflálni a supply-t, és a TEE az egyik eszköz közte (a Merkle-anchoring és a BLS aláírások mellett). Az EFF cikke ehhez képest a fogyasztói oldalt fogalmazza meg ugyanazzal a logikával: a TEE csökkenti a szükséges bizalmat, de nem szünteti meg, és nem azonos a kriptográfiai garanciával. A két forrás együtt egy koherens álláspontot ad: a TEE trust-redukció, nem trust-elimináció.

4. A threat model alapú döntés a helyes minta. Az EFF nem mondja, hogy a TEE-t soha ne használd. Azt mondja, hogy a döntés fenyegetésmodelltől függ, és az ökölszabály az automatikus adatküldés tiltása. Ez pontosan a decision-tradeoff-matrix skillünk logikája: nem abszolút tiltás, hanem kockázat és kontextus szerinti döntés, dokumentált indoklással.

5. A megfogalmazás-pontosság mint rendszerszintű tanulság. A cikk központi eleme egy terminológiai megkülönböztetés: „privacy-preserving” nem egyenlő „encrypted”. Ez a saját dokumentációinkra is érvényes elv: ha egy technológiát leírunk, pontosan kell megnevezni, milyen garanciát ad és milyet nem. A hungarian-terminology-postprocess és a szószedet-rendszerünk ugyanezt a célt szolgálja a magyar terminusok szintjén.