Een chosen-ciphertext attack (CCA) is een aanvalsmodel voor cryptoanalyse waarbij de aanvaller informatie verzamelt door (gedeeltelijk of volledig) zelf cijfertekst te kiezen en vervolgens de bijbehorende ontcijfering te verkrijgen met een onbekende sleutel. In praktische termen betekent dit dat de aanvaller toegang heeft tot een "ontcijferingsoracle": een mechanisme (bijvoorbeeld een server of apparaat) dat, op verzoek, gekozen ciphertexts ontcijfert en een reactie terugstuurt. Zelfs beperkte of gecontroleerde toegang tot zo'n oracle kan leiden tot ernstige lekken.
Typen CCA en formele veiligheidsniveaus
Er wordt onderscheid gemaakt tussen verschillende varianten van gekozen-cijfertekstaanvallen:
- Niet-adaptieve CCA (CCA1, "lunchtime"): de aanvaller mag vóór het ontvangen van de uitdaging meerdere ontcijferingsvragen stellen, maar niet daarna.
- Adaptieve CCA (CCA2): de aanvaller mag ook na ontvangst van de uitdaging verder ontcijferingsvragen stellen, met uitzondering van het exacte uit te dagen ciphertext. Dit is het strengste en meest relevante model voor moderne beveiligingsdefinities.
Cryptografische systemen worden vaak geëvalueerd op hun indistinguishability-eigenschappen, zoals IND-CPA (niet kwetsbaar voor chosen-plaintext attacks) en IND-CCA (weerstand tegen chosen-ciphertext attacks). Een scheme dat IND-CCA veilig is, biedt sterkere garanties tegen praktische aanvalsscenario's waarbij een ontcijferingsoracle kan bestaan.
Waarom CCA's problematisch zijn
Wanneer een cryptosysteem gevoelig is voor een aanval met gekozen cijferteksten, moeten implementatoren erop letten situaties te vermijden waarin een aanvaller gekozen cijferteksten kan laten ontcijferen. Dit blijkt vaak lastiger dan in eerste instantie lijkt, omdat:
- Zelfs gedeeltelijk gekozen of licht gemanipuleerde ciphertexts subtiele en doorgaans niet-triviale informatie kunnen prijsgeven.
- Veel systemen hetzelfde mechanisme gebruiken voor verschillende bewerkingen (bijvoorbeeld zowel ontcijferen als ondertekenen), waardoor functionaliteit die bedoeld is voor handtekeningen of foutenhandling kan fungeren als een ontcijferingsoracle.
- Foutmeldingen, timingverschillen of ander gedrag bij het verwerken van ongeldige ciphertexts fungeren als side-channels die informatie lekken.
Praktische voorbeelden van CCA-aanvallen
- Bleichenbacher-aanval (1998) op RSA met PKCS#1 v1.5-padding: door slimme, adaptieve queries kon een aanvaller stapsgewijs informatie over de plaintext verkrijgen via de serverrespons op foutieve paddings.
- Padding-oracle-aanvallen op blockciphers in CBC-modus: wanneer een systeem onderscheid maakt tussen verschillende fouttypes (bijv. padding-fout versus MAC-fout) kan een aanvaller een oracle creëren en stapsgewijs de plaintext reconstrueren (Vaudenay e.a.).
- Malleability-kwetsbaarheden en bit-flipping: sommige niet-geauthenticeerde encrypties laten gecontroleerde wijzigingen in plaintexts toe door manipulatie van ciphertexts.
- Verwarring tussen ondertekenen en ontcijferen: bij systemen zoals RSA kan hetzelfde wiskundige mechanisme voor ondertekenen en ontcijferen leiden tot misbruik wanneer berichten niet eerst correct worden gehashd (hashing) of wanneer input niet wordt gescheiden.
Bescherming en best practices
Er zijn meerdere, complementaire maatregelen om CCA's te mitigeren. Belangrijke aanbevelingen:
- Gebruik cryptosystemen die bewezen IND-CCA veilig zijn: voorbeelden zijn RSA-OAEP voor publieke sleutel encryptie en schemes zoals Cramer–Shoup die specifiek ontworpen zijn tegen adaptieve CCA's.
- Gebruik geauthenticeerde encryptie: voor symmetrische encryptie verdient het de voorkeur om vormen van geauthenticeerde symmetrische encryptie (AEAD) te gebruiken, zoals AES-GCM of ChaCha20-Poly1305. Deze combineren encryptie en integriteitscontrole en voorkomen dat een aanvaller een bruikbare ontcijferingsoracle kan creëren.
- Encrypt-then-MAC: als aparte encryptie- en MAC-algoritmes worden gebruikt, is de constructie encrypt-then-MAC de aanbevolen volgorde (MAC wordt over de ciphertext berekend en eerst gecontroleerd bij ontvangst) omdat dit voorkomt dat ongeldige ciphertexts tot ontcijferingspogingen leiden.
- Wees zuinig met foutinformatie: geef geen onderscheidende foutmeldingen of timingverschillen terug die gebruikt kunnen worden als oracle. Gebruik uniforme foutcodes en constant-time verwerking waar mogelijk.
- Gebruik verschillende sleutels en scheiding van functies: gebruik nooit exact hetzelfde sleutelmateriaal of exacte cryptografische operatie voor zowel ondertekenen als ontcijferen; hash het bericht altijd vóór het ondertekenen volgens de aanbevelingen van het gebruikte signatuurschema.
- Beperk toegang tot ontcijferingsfunctionaliteit: bijvoorbeeld door authenticatie, autorisatie, rate-limiting en logging. Een ontcijferingsfunctie moet niet publiekelijk beschikbaar zijn zonder strikte controles.
- Volg actuele standaarden en bibliotheken: gebruik goed onderhouden, cryptografische libraries en profielen die moderne, bewezen constructies implementeren in plaats van zelfgemaakte protocollen.
- Verifieer validatie en canonicalisatie: valideer alle protocollen- en berichtformaten strikt en canonicaliseer data vóór verwerking (bijvoorbeeld vóór ondertekenen of ontcijferen).
Implementatie en operationele aandachtspunten
Zelfs met theoretisch veilige bouwstenen kunnen implementatiefouten of onjuiste integratie tot CCA-achtige lekken leiden. Practische aandachtspunten:
- Voer constant-time implementaties uit voor gevoelige operaties om timing side-channels te verminderen.
- Wees voorzichtig met legacy-protocollen en backward compatibility die oudere, kwetsbare padding- of formaatconventies toestaan.
- Houd key-rotatie en sleutelbeheer op orde: fouten daarin kunnen tot onbedoelde oracles of hergebruik leiden.
- Onderwerp systemen aan beveiligingstesten (penetratietests) en cryptografische reviews om onderschatte oracles te vinden, zoals foutafhandeling die te veel informatie geeft.
Samenvatting: Een aanval met gekozen cijfertekst (CCA) richt zich op het verkrijgen van ontcijferingen van door de aanvaller gekozen ciphertexts en is een van de sterkste praktische bedreigingen voor zowel publieke sleutel- als symmetrische systemen. Bescherming vereist zowel het gebruik van cryptografische primitieven die bewezen CCA-resistent zijn (bijv. RSA-OAEP, Cramer–Shoup, AEAD) als zorgvuldige implementatiekeuzes om ontcijferingsoracles en side-channels te vermijden.