# 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.