Választott kódszöveges támadás (chosen-ciphertext attack, CCA) olyan kriptoanalízis modellje, amelyben a támadó (kriptoanalitikus) képes kiválasztani egy vagy több kódszöveget és megszerezni azok visszafejtését egy ismeretlen kulcs alatt, vagy más módon visszajelzést kapni a dekódolásról. A támadó célja, hogy ezeket az információkat felhasználva további titkos üzenetekről (vagy a titkos kulcsról) több tudást szerezzen. Ha egy rendszer érzékeny a választott kódszöveges támadásra, akkor a titkosítási szolgáltatások olyan hozzáférési pontokat biztosítanak, amelyek dekódolási „orákulumként” működhetnek — ezeket kerülni kell.
Típusok és formális szemlélet
Gyakorlatban két fontosabb típust különböztetnek meg:
- CCA1 (non-adaptive, "lunchtime"): a támadó a „szünet” előtt kérhet dekódolásokat, majd megpróbál a megszerzett információval egy célkód szöveg (ciphertext) visszafejtésére következtetni.
- CCA2 (adaptive, erősebb): a támadó a célkód megszerzése után is folytathat dekódolási lekérdezéseket, és ezek alapján adaptívan dönt a következő lekérdezésekről, kivéve természetesen azt, hogy közvetlenül azonos célkódot (challenge ciphertext) ne dekódolhassa. A modern elméletben a biztonságot általában a CCA2-re tesztelik (IND-CCA/IND-CCA2), mert ez a legszigorúbb és leggyakrabban releváns modell.
Példák a gyakorlatban
- Az RSA korai alkalmazásai (például PKCS#1 v1.5) sérülékenyek lehettek olyan támadásokkal szemben — például a Bleichenbacher-féle támadással (1998) — amelyek visszajelzést használtak a szerver oldali dekódolásról, és így lehetővé tették titkos üzenetek rekonstruálását.
- A „padding oracle” támadások (például Vaudenay-féle támadás) a blokk-kódolásoknál (pl. CBC) a visszajelzések alapján működnek: ha a szerver más hibajelzést ad a rossz padding miatt, mint más hibák miatt, az információ kiszivárogtatható.
- TLS és más protokollok múltbeli hibái (például Lucky Thirteen) jól mutatják, hogy még protokoll- vagy implementációs apróságok is lehetővé tehetnek CCA-szerű kihasználást.
Kockázatok
- Teljes titoktartás sérülése: egy sikeres CCA a titkos üzenetek rekonstruálásához vagy akár a titkos kulcs megszerzéséhez vezethet.
- Aláírás- és hitelesítési problémák: ha ugyanazt a mechanizmust használják aláírásra és visszafejtésre, a támadó aláírási orákulumot használhat a dekódolás megkerülésére.
- Protokolltörések: a hibás hibaüzenetek, időzítések vagy különböző válaszok információt adhatnak a támadónak.
Védelem — elvek és gyakorlat
A védelem két szinten fontos: a kriptográfiai sémák helyes megválasztása és az implementáció biztonsága.
- Használjon CCA-biztos (IND-CCA2) sémákat: olyan sémákat, amelyek bizonyíthatóan ellenállnak választott kódszöveges támadásoknak. Példák: RSA-ra az RSA-OAEP, a Cramer–Shoup nyilvános kulcsú séma, valamint modern hibridek, amelyek KEM (key-encapsulation) + DEM (data-encapsulation with AEAD) megközelítést használnak.
- Hitelesített titkosítás (AE/AEAD): szimmetrikus oldalon az hitelesített szimmetrikus titkosítás formái (pl. AES-GCM, ChaCha20-Poly1305) biztosítják, hogy a dekódolás előtt a titkosság és integritás ellenőrzése megtörténjen — így nincs dekódolási orákulum.
- Encrypt-then-MAC elv: szimmetrikus sémáknál az encrypt-then-MAC gyakorlatilag megszünteti azt a lehetőséget, hogy hibás ciphertextekre részleges információt adjon a rendszer.
- Megfelelő padding és padding-ellenőrzés: használjon korszerű padoló sémákat (például OAEP RSA esetén), és kerülje az olyan viselkedést, amely különbséget mutat hibák között (azonos hibakezelés minden hibára).
- Külön kulcsok külön célokra: soha ne használjon ugyanazt a kulcsot aláírásra és dekódolásra; alapelv, hogy a kulcsok célhoz kötöttek legyenek.
Implementációs óvintézkedések
- Ne adjon részletes hibajelzéseket a kliensnek: a támadók ezeket felhasználhatják orákulumként. Egységes, nem-informatív hibaválaszok használata ajánlott.
- Időzítés-ellenes védelem: a dekódolási műveletek időzítése ne szivárogtasson információt (constant-time megvalósítási technikák).
- Korlátozza a dekódolási lekérdezéseket és naplózza azokat: rate limiting, hozzáférés-ellenőrzés, és riasztások gyanús lekérdezések esetén.
- Használjon bevált, auditált kriptográfiai könyvtárakat és protokollokat; ne írjon saját titkosítást kritikus rendszerekhez.
- Hash-elés aláírás előtt: az aláírandó üzeneteket előbb mindig megfelelő, biztonságos hash-elési sémával dolgozza fel (például RSA-PSS ajánlott aláíráshoz), hogy elkerülje az aláírás-orákulumok miatti visszaéléseket.
Ajánlott sémák és gyakorlatok
- RSA-OAEP – RSA dekódolásnál padding kötelező és megfelelő kivitelezéssel érhető el jobb CCA-biztonság.
- RSA-PSS – aláírásnál ajánlott, mert robusztusabb a korábbi sémákkal szemben.
- Cramer–Shoup – nyilvános kulcsú eljárás, amely bizonyíthatóan CCA-biztos.
- AEAD konstrukciók (pl. AES-GCM, ChaCha20-Poly1305) – szimmetrikus hitelesített titkosítás, általánosan javasolt modern protokollokban.
- Hibrid kriptorendszerek KEM+DEM kombinációval: KEM biztosítja a kulcsosztást, DEM pedig AEAD-del védi az adatot.
Összefoglalás
A választott kódszöveges támadások súlyos kockázatot jelentenek: még látszólag kismértékű visszajelzések vagy eltérések is lehetővé tehetik a teljes kompromittálást. Megfelelő védelemhez elengedhetetlen a bizonyíthatóan CCA-biztos sémák választása, hitelesített titkosítás alkalmazása, valamint gondos, egységes hibakezelés és implementációs óvintézkedések. A bevált, auditált algoritmusok és protokollok, valamint a külön kulcsok és a padding/helyes aláírási gyakorlatok követése jelentősen csökkentik a sikeres CCA-k lehetőségét.