Режим CCM: устройство и параметры

Общая модель CCM (Counter with CBC-MAC)

CCM (Counter with CBC-MAC) представляет собой комбинированный режим аутентифицированного шифрования, объединяющий:

  • CBC-MAC для вычисления кода аутентичности (MAC)
  • CTR (Counter Mode) для шифрования данных

Ключевая идея режима заключается в разделении процесса на две независимые части:

  1. Сначала вычисляется контрольная сумма (MAC) по данным и дополнительным ассоциированным данным.
  2. Затем выполняется шифрование данных в режиме счётчика.
  3. Итоговый тег аутентичности также шифруется через CTR.

Таким образом обеспечивается одновременно конфиденциальность и целостность.

Архитектура реализации в SJCL

В Stanford JavaScript Crypto Library CCM реализован как часть sjcl.mode.ccm и опирается на AES как базовый блочный шифр.

Внутренний процесс можно условно разделить на этапы:

  • подготовка входных данных
  • формирование B0-блока (служебная структура CCM)
  • вычисление CBC-MAC
  • шифрование текста через CTR
  • шифрование тега аутентичности

Основные параметры SJCL CCM

Функции encrypt и decrypt принимают объект параметров, ключ и данные.

Ключевые параметры:

1. iv (или nonce)

Инициализационный вектор (nonce), уникальный для каждой операции шифрования.

  • Обязательный параметр
  • Обычно 7–13 байт (в зависимости от L)
  • Должен быть уникален при одном ключе

Нарушение уникальности iv полностью разрушает безопасность режима.

2. adata (associated data)

Ассоциированные данные, которые не шифруются, но участвуют в аутентификации.

Используется для:

  • заголовков протоколов
  • метаданных
  • идентификаторов сообщений

Любое изменение adata приводит к ошибке проверки целостности при расшифровании.

3. ts (tag size)

Размер тега аутентичности в битах.

Типичные значения:

  • 64 бит
  • 96 бит
  • 128 бит

Чем больше ts, тем выше стойкость к подделке, но тем больше накладные расходы.

4. ks (key size)

Размер ключа AES (обычно задаётся при создании ключа SJCL, например 128/192/256 бит).

5. l (implicit parameter CCM)

Параметр CCM, определяющий размер поля длины сообщения.

В SJCL он выбирается автоматически на основе длины IV:

  • L = 15 - длина nonce

То есть:

  • короткий nonce → больше места под длину
  • длинный nonce → меньше L

Формат входных данных

В SJCL режим CCM работает с:

  • plaintext — данные для шифрования (строка или битовый массив SJCL)
  • adata — необязательные ассоциированные данные
  • iv — nonce

Пример структуры вызова:

  • ключ AES
  • данные
  • параметры CCM (iv, adata, ts)

Процесс шифрования в SJCL CCM

1. Формирование B0 блока

B0 содержит метаданные:

  • флаги (presence of AAD, tag length)
  • nonce
  • длина сообщения

Этот блок участвует в вычислении CBC-MAC.

2. Вычисление CBC-MAC

CBC-MAC строится по схеме:

  • вход: B0 + AAD + plaintext
  • AES используется как блочный шифр
  • результат: промежуточный тег

3. Шифрование данных (CTR mode)

Данные шифруются через счётчик:

  • nonce + counter
  • AES encrypt(counter)
  • XOR с plaintext

4. Шифрование тега

Итоговый MAC также шифруется в CTR-режиме, что предотвращает его подмену.

Процесс расшифрования

Расшифрование выполняется в обратном порядке:

  1. Восстановление тега через CTR
  2. Расшифрование ciphertext
  3. Повторное вычисление CBC-MAC
  4. Сравнение тегов

Если теги не совпадают — данные считаются подделанными.

Особенности реализации SJCL

1. Работа с битовыми массивами

SJCL использует внутренний тип sjcl.bitArray, поэтому:

  • строки автоматически преобразуются в битовые массивы
  • операции выполняются на уровне битов, а не байтов

2. Строгая проверка целостности

Даже изменение одного бита:

  • в ciphertext
  • в adata
  • в iv

приводит к провалу проверки MAC.

3. Зависимость от уникальности nonce

Критически важно:

  • повторное использование iv с тем же ключом = компрометация ключа
  • особенно опасно в CTR-части

Типичные ошибки при использовании CCM в SJCL

Повтор nonce

Одна из самых серьёзных ошибок:

  • одинаковый iv → повтор keystream
  • возможное восстановление plaintext

Игнорирование adata

Если ассоциированные данные используются, но не проверяются корректно:

  • возможна логическая подмена сообщений

Неправильный размер ts

Слишком маленький tag:

  • упрощает подбор поддельных сообщений

Несогласованность параметров при decrypt

Любое расхождение:

  • ts
  • iv
  • adata

приводит к ошибке проверки целостности

Внутренний вызов SJCL CCM

Типовая структура API:

  • sjcl.mode.ccm.encrypt(prf, key, plaintext, iv, adata, ts)
  • sjcl.mode.ccm.decrypt(prf, key, ciphertext, iv, adata, ts)

Где prf — AES-псевдоним (обычно sjcl.cipher.aes).

Практическое поведение режима

  • Шифрование и аутентификация связаны
  • Нельзя изменить ciphertext без обнаружения
  • AAD защищает структуру сообщения
  • CTR обеспечивает высокую скорость обработки

Структура данных CCM в SJCL

Итоговое сообщение обычно включает:

  • ciphertext
  • tag (встроенный или отдельный)
  • параметры iv (передаются отдельно)
  • adata (внешний контекст)

Ограничения CCM в SJCL

  • фиксированная зависимость от AES
  • отсутствие потоковой обработки (всё сообщение целиком)
  • необходимость корректного управления nonce на стороне разработчика
Оглавление