Атаката с избран шифротекст (CCA) е модел на атака за криптоанализ, при който криптоаналитикът събира информация, поне отчасти, като избира шифров текст и получава неговото декриптиране под неизвестен ключ. В този модел атакуващият има достъп до „ор Oracle за декриптиране“ — възможност да подаде произволни шифротекстове и да получи обратно техните плейнтексти (или уведомен резултат за грешка). Целта обикновено е да се разкрие ключът, да се възстанови важна част от съобщението или да се фалшифицира съобщение, което да премине проверка. Много важен критерий за сигурност е понятието IND-CCA (indistinguishability under chosen-ciphertext attack) — схемите, които са IND-CCA сигурни, запазват конфиденциалността си дори при наличието на такъв декрипционен орeкъл.

Видове CCA и тяхната сложност

Обикновено се разграничават два основни варианта:

  • CCA1 (non-adaptive chosen-ciphertext attack) — атакуващият има достъп до декрипционен орeкъл само преди да види целевия шифротекст. След като получи целевия шифротекст, не може да прави повече заявки.
  • CCA2 (adaptive chosen-ciphertext attack) — по-силен модел: атакуващият може да прави декрипционни заявки и преди, и след като види целевия шифротекст, с изключение на самата целева заявка. Това е моделът, използван за дефиниране на IND-CCA сигурност и често е изискваната гаранция в практиката.

Защо това е проблем — практическите рискове

Когато дадена криптосистема е податлива на атака с избран шифротекст, изпълнителите трябва да внимават да избегнат ситуации, в които нападателите могат да декриптират избрани шифротекстове (т.е. да избегнат предоставянето на схема за декриптиране). Това може да се окаже по-трудно, отколкото изглежда, тъй като дори частично избрани шифротекстове могат да позволят фини атаки.

В практиката няколко известни примера демонстрират опасността:

  • Атаки от типа припадане на пълен padding — например Bleichenbacher атака върху RSA PKCS#1 v1.5, където ореъл за грешки при падинга позволява възстановяване на плейнтекст.
  • Padding oracle атаки (Vaudenay) в протоколи и уеб приложения — когато съобщения за грешки или времеви разлики разкриват дали падингът е бил валиден.
  • Атаки по канали на изпълнение (side-channel), при които странични индикатори (време, грешки, кеш поведение) се използват като „декрипционен ореъл“.
  • Комбиниране на една и съща примитив за подписване и декриптиране — някои реализации на RSA без коректно хеширане на подписваното съобщение позволяват атаки, които разкриват информация за плейнтекста или ключа.

Защита: криптографски схеми и практики

По-добрият подход е да се използва криптосистема, която е доказано сигурна при атака с избран шифротекст, включително (наред с други) RSA-OAEP, Cramer-Shoup и много форми на удостоверено симетрично криптиране. По-конкретно:

  • Използвайте схеми с доказана IND-CCA сигурност: RSA-OAEP (за публично-ключово криптиране), Cramer–Shoup, както и модерни KEM/DEM конструкции, които комбинират ключово обменяне и симетрично шифроване.
  • Използвайте AEAD (authenticated encryption with associated data): алгоритми като AES-GCM, ChaCha20-Poly1305 предоставят едновременно конфиденциалност и целостност и са проектирани да предотвратят CCA-подобни атаки. Общ принцип — предпочитайте encrypt-then-MAC или AEAD пред encrypt-then-sign или само шифроване без удостоверяване.
  • Правилно подписване: при цифрови подписи не използвайте същия механизъм както за декриптиране; винаги хеширайте съобщението преди подписване (например RSA-PSS за RSA подписи).
  • Строга обработка на грешките: не разкривайте подробни съобщения за грешки при неуспешно разпаковане/проверка — върнете унифициран отговор и използвайте константно време проверки, за да избегнете тайминг ореали.
  • Ограничаване на ореъла: затруднете достъпа до всякакви декрипционни услуги — лимитирайте заявки, изисквайте автентикация, логвайте и следете аномалии.
  • Използвайте утвърдени библиотеки и протоколи: не проектирайте собствени криптопротоколи. Възползвайте се от актуални стандарти и имплементации (TLS 1.3, libsodium, BoringSSL/LibreSSL/OpenSSL с правилна конфигурация).

Препоръки за разработчици и администратори

  • Предпочитайте AEAD алгоритми (AES-GCM, ChaCha20-Poly1305) за нови приложения.
  • За публично-ключово шифроване използвайте RSA-OAEP или KEM-базирани схеми и проверявайте параметрите и пъдинга коректно.
  • Не показвайте подробности за причината за отхвърляне на криптографски операции в потребителски интерфейс или API (единен generic error).
  • При уязвимости в криптографията, актуализирайте бързо библиотеките и конфигурациите (например преход към TLS 1.3, ако е възможно).
  • Провеждайте кодови и сигурностни одити за странични канали и съобразявайте имплементациите с изискванията за константно време.
  • Разделяйте функции: отделете подписване от декриптиране и не позволявайте едни и същи интерфейси да изпълняват незащитени декрипционни операции за външни потребители.

Бележки за теоретични гаранции и реалната сигурност

Доказателствата за сигурност (например IND-CCA) обикновено се формулират в математически модели (например ROM — Random Oracle Model) и зависят от правилната употреба на предположенията и параметрите. Дори схема, която е теоретично сигурна, може да бъде компрометирана чрез лоша имплементация, странични канали или нещателно обработване на грешки. Затова практическата сигурност изисква както избор на подходящи, доказани алгоритми, така и строго инженерно изпълнение и поддръжка.

Като обобщение: атаките с избран шифротекст са мощен модел, който показва защо е важно да се използват IND-CCA-резистентни конструкции, AEAD-схеми и добри практики при имплементацията — и да се избягва всяка форма на „декрипционен ореъл“ в производствени системи.