AES шифрование для разработчиков Когда это нужно и как оно работает

Если вы храните чувствительные данные — персональные данные пользователей, API-ключи, финансовые записи — AES-шифрование — это инструмент, который вы выберете. Это отраслевой стандарт для симметричного шифрования в состоянии покоя: быстро, проверено в бою и поддерживается встроенными средствами в каждом из основных языков программирования.

Но неверное использование AES хуже, чем бесполезно. Режим ECB раскрывает паттерны. Использование одного и того же IV с GCM полностью нарушает его безопасность. А хранение ключа рядом с шифрованным текстом лишает весь смысл.

Вот что вам действительно нужно для правильного использования AES в производстве.

Что такое AES?

AES (Advanced Encryption Standard) — это симметричный блочный шифр. Симметричный шифр означает, что один и тот же ключ используется для шифрования и дешифрования. Блочный шифр работает с фиксированными блоками данных размером 128 бит.

AES заменил DES в 2001 году, и сегодня он используется повсеместно: в TLS, шифровании дисков, в менеджерах паролей, в шифровании полей базы данных. В отличие от асимметричного шифрования (RSA, ECDH), AES достаточно быстр, чтобы шифровать большие объёмы данных в реальном времени. Стоимость: обе стороны должны иметь один и тот же ключ, поэтому распределение ключа становится вашей проблемой.

AES-128 против AES-256: какой размер ключа?

AES представлен тремя размерами ключей: 128, 192 и 256 бит. На практике вы выберете между 128 и 256.

	AES-128	AES-256
Длина ключа	128 бит	256 бит
Количество раундов	10	14
Производительность	Быстрее	~40% медленнее
Безопасность	Сильный — нет известных практических атак	Более сильный — защищён от будущих квантовых компьютеров
Вердикт	Подходит для большинства приложений	Используйте для высокочувствительных данных или долгосрочного хранения

AES-128 не сломан. Нет практических атак. Но если вы шифруете данные, которые должны оставаться защищёнными на 20 лет и более, или ваша угроза включает квантовые компьютеры, то AES-256 добавляет значимый запас. Для большинства приложений шифрования полей базы данных сегодня достаточно AES-128. Если есть сомнения, используйте AES-256; потеря производительности для типичных нагрузок ничтожна.

Режим работы: почему GCM, а не ECB

AES сам по себе шифрует только один блок 128 бит. Для реальных данных вам нужно режим работы, который обрабатывает несколько блоков и правильно их последовательно соединяет. Это решение имеет огромное значение.

Режим	Авторизованный	Требуется IV	Вердикт
ECB	Нет	Нет	Никогда не используйте — одинаковые исходные данные приводят к одинаковым зашифрованным данным, раскрывают паттерны
CBC	Нет	Да	Устарел — нет аутентификации, уязвим к атакам на паддинг
GCM	Да (AEAD)	Да (nonce)	Используйте это — шифрует и аутентифицирует за один проход

Используйте GCM. GCM (Galois/Counter Mode) — это шифр AEAD (шифрование с аутентификацией и связанными данными). Он делает две вещи одновременно:

1. Шифрует данные, чтобы они были непрочитаемы без ключа
2. Генерирует тег аутентификации, чтобы любое вмешательство было немедленно обнаружено

Без аутентификации атакующий может изменить биты в зашифрованном тексте, и вы получите мусор при дешифровке, не зная об этом. С GCM при попытке изменения зашифрованного текста происходит сбой при дешифровке — до того, как будет возвращён исходный текст.

IV/Nonce: случайный, никогда не повторяется

GCM требует вектора инициализации (IV), также называемого nonce — «число, используемое один раз». IV не должен быть секретным, но он должен:

• Случайный — генерироваться с помощью криптографически безопасного генератора случайных чисел
• Уникальный — никогда не повторяться с тем же ключом

Повторное использование IV с тем же ключом в GCM является катастрофическим. Атакующий, который видит два зашифрованных текста, зашифрованных с тем же ключом и IV, может их XOR-суммировать и восстановить оба исходных текста. Это не теоретическая угроза — она уже происходила в реальных системах.

Используйте 96-битный (12-байтовый) случайный IV на каждой операции шифрования. Поскольку он нужен для дешифровки, храните его вместе с зашифрованным текстом — традиционный формат — IV, предшествующий зашифрованному тексту.

Рабочий код: AES-256-GCM

Вот готовые фрагменты для использования в производстве. Оба хранят IV и тег аутентификации вместе с зашифрованным текстом, чтобы дешифровка была автономной.

Node.js

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const IV_LENGTH  = 12; // 96 bits — recommended for GCM
const TAG_LENGTH = 16; // 128-bit auth tag

function encrypt(plaintext, key) {
  const iv = crypto.randomBytes(IV_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, iv);

  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();

  // Layout: [iv (12)] + [tag (16)] + [ciphertext]
  return Buffer.concat([iv, tag, encrypted]).toString('base64');
}

function decrypt(ciphertextB64, key) {
  const data      = Buffer.from(ciphertextB64, 'base64');
  const iv        = data.subarray(0, IV_LENGTH);
  const tag       = data.subarray(IV_LENGTH, IV_LENGTH + TAG_LENGTH);
  const encrypted = data.subarray(IV_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(tag);

  return Buffer.concat([decipher.update(encrypted), decipher.final()]).toString('utf8');
}

// Usage
const key        = crypto.randomBytes(KEY_LENGTH); // store this securely
const ciphertext = encrypt('sensitive data here', key);
const plaintext  = decrypt(ciphertext, key);

Питон

import os, base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

IV_LENGTH = 12  # 96 bits

def encrypt(plaintext: str, key: bytes) -> str:
    iv = os.urandom(IV_LENGTH)
    aesgcm = AESGCM(key)
    # encrypt() appends the 16-byte auth tag automatically
    ciphertext = aesgcm.encrypt(iv, plaintext.encode(), None)
    return base64.b64encode(iv + ciphertext).decode()

def decrypt(ciphertext_b64: str, key: bytes) -> str:
    data       = base64.b64decode(ciphertext_b64)
    iv         = data[:IV_LENGTH]
    ciphertext = data[IV_LENGTH:]
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(iv, ciphertext, None).decode()

# Usage
key        = AESGCM.generate_key(bit_length=256)  # store this securely
ciphertext = encrypt('sensitive data here', key)
plaintext  = decrypt(ciphertext, key)

Установите зависимость: pip install cryptography

Вы можете протестировать шифрование и дешифрование AES интерактивно — без каких-либо настроек — с помощью IO Tools инструмента шифрования/дешифрования AES.

Управление ключами: сложная часть

Ваше шифрование будет столь же безопасным, сколько ваше управление ключами. Наиболее распространённые ошибки:

• Ключ хранится в той же базе данных, что и зашифрованные данные — если злоумышленник получает ваш dump базы данных, он получает оба.
• Ключ помещён в систему контроля версий — даже если он игнорируется в git .env, обновление становится сложным и история сохраняется.
• Ключ появляется в логах — логи приложения передаются агрегаторам. Ключи никогда не должны появляться там.

Где хранить ключи шифрования:

• AWS KMS / Google Cloud KMS / Azure Key Vault — управление ключами с отслеживанием, автоматической сменой
• HashiCorp Vault — самодельный, подходит для многооблачных сред
• Переменные среды — приемлемо для низкочувствительных задач с ограниченной поверхностью риска

Для шифрования полей базы данных стандартная практика — оболочка шифрования: генерируется ключ шифрования данных (DEK) на каждую запись или столбец, затем DEK шифруется с помощью основного ключа, хранящегося в KMS. В базе данных содержатся только зашифрованные DEK и шифрованные тексты — основной ключ никогда не касается базы данных.

Когда использовать AES и когда не использовать

AES — подходящий инструмент для:

• Шифрования полей в базе данных — SSN, номера карт, медицинские данные
• Шифрования файлов в состоянии покоя до хранения в облаке
• Обмен секретами между сервисами которые обмениваются заранее установленным ключом

AES — не подходящий инструмент, когда:

• Вы передаёте данные по сети — используйте TLS. Не создавайте собственный слой передачи.
• Требуется асимметричное шифрование — если отправитель и получатель не могут обменяться ключом заранее, используйте RSA или ECDH для обмена ключами.
• Вы храните пароли — используйте bcrypt, scrypt или Argon2. Зашифрованные пароли могут быть дешифрованы; правильно хешированные — нет.
• Использование управляющего решения — AWS Secrets Manager, Vault и подобные решают задачи по вращению, контролю доступа и журналированию событий. Предпочтительнее использовать это, чем ручное AES, если оно покрывает вашу задачу.

Ошибкой, которую чаще всего совершают разработчики, является то, что они рассматривают AES как полное решение по безопасности. Это примитив — элементарный блок. Сочетайте его с аутентифицированным режимом (GCM), уникальными IV для каждой операции и надлежащим управлением ключами, и тогда он будет чрезвычайно эффективным. Если пропустить любую из этих частей, вы построите что-то, которое выглядит безопасно, но на деле не является безопасным.

Вам также может понравиться