Внутренняя структура объекта ответа

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

Типичный результат работы Iron после сериализации и защиты данных выглядит следующим образом:

Fe26.2*<password-id>*<encryption-salt>*<encryption-iv>*<encrypted-data>*<hmac-salt>*<hmac>*<ttl>

Каждый элемент в этой последовательности кодируется в Base64Url, что позволяет безопасно передавать строку в URL, HTTP-заголовках и cookie без дополнительного экранирования.

Первый элемент Fe26.2 — это версия протокола. Он фиксирует формат и правила обработки строки. Это важно для обратной совместимости: разные версии Iron могут интерпретировать данные по-разному.

Идентификатор ключа и управление секретами

Второй сегмент — password-id. Он не содержит сам секретный ключ, а указывает на его идентификатор в наборе ключей, используемых для шифрования и подписи.

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

Соль и инициализационный вектор

Следующие два элемента отвечают за криптографическую уникальность каждого сообщения:

  • encryption-salt
  • encryption-iv

Соль используется для усложнения процесса получения ключа шифрования из пароля. Даже при одинаковом исходном ключе разные соли приводят к разным производным ключам.

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

Шифротекст

Центральная часть структуры:

<encrypted-data>

Этот сегмент содержит сериализованный и зашифрованный JSON-объект. Перед шифрованием объект проходит этап преобразования в строку (обычно JSON.stringify), после чего подвергается симметричному шифрованию.

На этом этапе данные становятся полностью нечитаемыми без ключа и параметров IV.

HMAC и проверка целостности

Следующий блок:

  • hmac-salt
  • hmac

HMAC (Hash-based Message Authentication Code) отвечает за проверку того, что данные не были изменены после создания.

Процесс включает:

  1. Генерацию ключа подписи из пароля и salt
  2. Вычисление хэша от всей строки шифротекста и служебных данных
  3. Сравнение полученного значения с переданным HMAC

Если хотя бы один символ в строке изменён, проверка не проходит, и объект считается повреждённым или поддельным.

TTL и ограничение времени жизни

Последний элемент:

<ttl>

TTL (time to live) задаёт время жизни защищённого объекта. Он может быть представлен в миллисекундах или специальном формате времени.

При расшифровке система сравнивает текущую метку времени с моментом создания объекта. Если TTL истёк, даже корректный HMAC не позволяет восстановить данные.

Внутренний объект после расшифровки

После успешной проверки и дешифровки формируется исходный JavaScript-объект. Его структура полностью соответствует данным, которые были переданы до вызова Iron.seal.

Пример логической структуры результата:

{
  data: Object,
  createdAt: Number,
  ttl: Number
}

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

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

Формирование sealed-строки проходит несколько последовательных этапов:

  1. Сериализация объекта в строку
  2. Генерация ключа шифрования из пароля и salt
  3. Шифрование данных с использованием IV
  4. Формирование HMAC по служебным и зашифрованным данным
  5. Кодирование всех компонентов в Base64Url
  6. Сборка итоговой строки с разделителями

Каждый этап строго детерминирован, что позволяет воспроизводить результат при наличии одинаковых входных параметров.

Разбор структуры при unseal

При обратной операции строка разбивается по символу *, после чего выполняется:

  • проверка версии протокола
  • извлечение ключа по password-id
  • восстановление salt и IV
  • проверка HMAC
  • расшифровка ciphertext
  • десериализация JSON

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

Криптографическая связность компонентов

Особенность структуры Iron заключается в том, что каждый элемент зависит от остальных:

  • изменение IV ломает расшифровку
  • изменение salt делает невозможным восстановление ключа
  • изменение ciphertext нарушает HMAC
  • изменение HMAC блокирует верификацию

Таким образом, строка представляет собой связанный криптографический контейнер, а не набор независимых полей.

Представление данных как защищённого контейнера

Внутренняя структура объекта ответа в Iron фактически превращает обычный JavaScript-объект в линейное представление криптографического контейнера. Он сочетает:

  • конфиденциальность (шифрование данных)
  • целостность (HMAC)
  • ограничение времени жизни (TTL)
  • управляемость ключами (password-id)

Каждый компонент выполняет строго определённую роль, а итоговая строка является единственной точкой взаимодействия между защищёнными данными и внешней средой.

Оглавление