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.