Структура sealed-токена

Sealed-токен в Iron представляет собой компактную строку, в которой зашифрованные данные объединены с метаданными о криптографических операциях. Внешне это выглядит как последовательность сегментов, разделённых символом *, где каждый сегмент несёт строго определённую смысловую нагрузку.

Базовая форма:

Fe26.2*<key id>*<encrypted key>*<iv>*<ciphertext>*<mac>*<expiration>

Несмотря на кажущуюся простоту, каждый элемент является результатом отдельного этапа криптографического преобразования.

Версия протокола

Первый элемент строки:

Fe26.2

Он фиксирует версию алгоритма Iron. Это критически важная часть, так как формат и правила обработки токена могут меняться между версиями. Проверка версии происходит до любых других операций.

Идентификатор ключа

Следующий сегмент:

<key id>

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

Ключевой момент: идентификатор не является секретом и может безопасно передаваться вместе с токеном.

Зашифрованный ключ (encrypted key)

<encrypted key>

Этот элемент содержит симметричный ключ, зашифрованный мастер-ключом системы. Iron использует концепцию обёртывания ключей: данные шифруются временным ключом, а сам ключ дополнительно защищается.

Такой подход повышает безопасность при масштабировании систем.

Вектор инициализации (IV)

<iv>

IV (Initialization Vector) используется для предотвращения детерминированности шифрования. Даже одинаковые входные данные при разных IV дают разные результаты шифрования.

В Iron IV всегда уникален для каждого токена, что исключает повторяемость шифротекста.

Шифротекст

<ciphertext>

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

Важно:

  • без ключа и IV расшифровка невозможна
  • длина зависит от исходного payload и режима шифрования

MAC (Message Authentication Code)

<mac>

Криптографическая подпись токена. Используется для проверки целостности данных.

MAC защищает от:

  • подмены ciphertext
  • изменения структуры токена
  • атак с модификацией сегментов

Проверка MAC выполняется до попытки расшифровки.

Временные ограничения

<expiration>

Финальный сегмент отвечает за срок жизни токена. Обычно содержит timestamp или TTL-значение.

При обработке токена выполняется проверка:

  • не истёк ли срок действия
  • соответствует ли текущее время допустимому диапазону

Логическая структура формирования

Процесс создания sealed-токена можно разложить на последовательность операций:

  1. Генерация случайного симметричного ключа
  2. Шифрование полезной нагрузки этим ключом
  3. Генерация IV
  4. Шифрование симметричного ключа мастер-ключом
  5. Вычисление MAC по всем компонентам
  6. Кодирование всех частей в строку

Внутренний порядок сборки

Формирование строки всегда строго детерминировано:

version * keyId * encryptedKey * iv * ciphertext * mac * ttl

Любое нарушение порядка делает токен недействительным, поскольку MAC рассчитывается на основе конкретной структуры.

Роль разделителя

Символ * выбран не случайно:

  • не встречается в base64-представлениях при стандартной кодировке Iron
  • упрощает парсинг без дополнительного декодирования JSON
  • снижает вероятность коллизий в строковом представлении

Особенности кодирования данных

Каждый бинарный сегмент токена кодируется в текстовую форму (обычно Base64URL). Это обеспечивает:

  • безопасную передачу через HTTP заголовки
  • отсутствие необходимости в экранировании символов
  • совместимость с URL и cookies

Проверка токена при расшифровке

При восстановлении данных выполняется строгая последовательность:

  1. Разбор строки по *
  2. Проверка версии
  3. Извлечение key id
  4. Восстановление симметричного ключа
  5. Проверка MAC
  6. Проверка срока действия
  7. Расшифровка ciphertext

Любое несоответствие на любом этапе приводит к отклонению токена без раскрытия внутреннего состояния.

Значение структуры для безопасности

Фиксированная структура sealed-токена решает сразу несколько задач:

  • предотвращает частичную подмену данных
  • исключает скрытые модификации payload
  • обеспечивает независимую проверку целостности
  • поддерживает безопасную ротацию ключей

Комбинация шифрования, подписи и строгого формата делает токен устойчивым к классическим атакам на сессионные данные и передачу состояния между сервисами.

Оглавление