𝗖𝗕𝗖 𝗕𝗶𝘁 𝗙𝗹𝗶𝗽𝗽𝗶𝗻𝗴 𝗘𝘅𝗽𝗹𝗮𝗶𝗻𝗲𝗱

Encryption does not mean your data is safe from tampering.

Many developers make this mistake. They think if an attacker cannot read the data, they cannot change it. This is wrong. Cryptography treats secrecy and integrity as two different tasks.

The CBC Bit Flipping attack proves this. An attacker can change your data without knowing your secret key.

Here is how it works:

AES does not encrypt data in one large piece. It breaks data into 16-byte blocks. In CBC mode, these blocks chain together. The encrypted output of the first block mixes into the plaintext of the second block.

This chain creates a weakness during decryption. To get the original text of Block 2, the server decrypts it and combines it with the ciphertext from Block 1.

An attacker can exploit this:

The attacker does not need to read the message. They just flip bits to change the final result.

Consider an old web app using encrypted cookies for sessions. A cookie might hold: userid=994;role=user;

An attacker intercepts this cookie and flips bits in the ciphertext. They send many requests until the server accepts one. Because the server only checks if the data decrypts, it processes the modified text. Suddenly, the decrypted string reads: userid=994;role=admi;

The attacker now has admin access. They never read the key or the original cookie.

The mistake is assuming encryption guarantees integrity.

To fix this, use Authenticated Encryption like AES-GCM. It creates a cryptographic tag. This tag acts like a seal. If an attacker changes even one bit, the seal breaks. The server rejects the data immediately.

If you must use CBC, use an Encrypt-then-MAC architecture. Create an authentication code for the ciphertext and verify it before you start decryption.

Secret data is not always trustworthy data. Always prove your data is unchanged before you use it to make decisions.

Пояснення атаки перемикання бітів у режимі CBC: чому одне лише шифрування не гарантує цілісність

У світі криптографії ми часто чуємо про дві фундаментальні властивості: конфіденційність та цілісність.

Хоча ці терміни часто використовуються разом, вони стосуються зовсім різних аспектів безпеки:

  1. Конфіденційність (Confidentiality): Гарантує, що лише авторизовані особи можуть прочитати дані. Шифрування — це основний інструмент для забезпечення конфіденційності.
  2. Цілісність (Integrity): Гарантує, що дані не були змінені або підроблені під час передачі чи зберігання.

Поширена помилка полягає в переконанні, що якщо дані зашифровані, вони автоматично є цілісними. Це не так. У цій статті ми розглянемо, як саме атака перемикання бітів (bit-flipping attack) у режимі шифрування CBC (Cipher Block Chaining) дозволяє зловмиснику змінити дані, навіть не знаючи ключа шифрування.

Що таке режим CBC?

У режимі Cipher Block Chaining (CBC) кожен блок відкритого тексту перед шифруванням проходить через операцію XOR з попереднім блоком шифротексту. Для першого блоку використовується ініціалізаційний вектор (IV).

Математично процес розшифрування блоку $P_i$ виглядає так: $P_i = D_k(C_i) \oplus C_{i-1}$

Де:

Вразливість: Атака перемикання бітів

Зверніть увагу на формулу розшифрування: $P_i = D_k(C_i) \oplus C_{i-1}$.

Ця формула показує, що значення розшифрованого блоку $P_i$ безпосередньо залежить від попереднього блоку шифротексту $C_{i-1}$. Якщо зловмисник змінить певний біт у блоці $C_{i-1}$, це призведе до точно такої ж зміни у відповідному біті розшифрованого блоку $P_i$.

Хоча зміна біта в $C_{i-1}$ повністю зіпсує (перетворить на випадковий шум) попередній блок $P_{i-1}$, зловмисник може використовувати це, щоб передбачувано змінити наступний блок $P_i$.

Практичний приклад

Уявіть, що додаток використовує CBC для шифрування сесійних кук (cookies), які містять роль користувача.

Відкритий текст (Plaintext): user_id=1234&role=user

Припустимо, цей текст розбивається на блоки, і блок з роллю виглядає так: role=user

Зловмисник не може прочитати цей текст, бо він зашифрований. Проте він знає структуру куки. Він хоче змінити role=user на role=admin.

  1. Зловмисник вираховує різницю між user та admin за допомогою операції XOR.
  2. Він застосовує цю різницю до відповідного байта в попередньому блоці шифротексту ($C_{i-1}$).
  3. Коли сервер розшифрує наступний блок, замість role=user він отримає role=admin.

Хоча попередній блок шифротексту буде пошкоджений і перетвориться на "сміття", зловмисника це не хвилює, оскільки він досяг своєї мети — отримав права адміністратора.

Як запобігти цій атаці?

Щоб захистити дані не лише від читання, а й від маніпуляцій, необхідно використовувати методи, що забезпечують автентифікацію.

1. Використання MAC (Message Authentication Code)

Найкращий спосіб — це використання підпису HMAC (Hash-based Message Authentication Code). Ви шифруєте повідомлення, а потім створюєте MAC на основі шифротексту. При отриманні сервер спочатку перевіряє MAC. Якщо хоча б один біт шифротексту було змінено, MAC не співпаде, і сервер відхилить повідомлення ще до розшифрування.

Це підхід Encrypt-then-MAC.

2. Використання режимів AEAD

Сучасні стандарти криптографії пропонують режими AEAD (Authenticated Encryption with Associated Data), такі як AES-GCM або ChaCha20-Poly1305. Ці режими поєднують шифрування та автентифікацію в одному процесі. Вони автоматично гарантують, що якщо шифротекст було змінено, розшифрування завершиться помилкою.

Висновок

Шифрування забезпечує конфіденційність, але воно не є панацеєю від усіх атак. Режим CBC без додаткового механізму перевірки цілісності вразливий до маніпуляцій. Завжди використовуйте автентифіковане шифрування (AEAD) або комбінацію шифрування з HMAC, щоб гарантувати, що ваші дані залишаються не лише секретними, а й незмінними.