Инструменты разработчика · Декодер JWT
JWE Объяснение: почему зашифрованный JWT состоит из пяти частей и не имеет читаемой полезной нагрузки
· Фон
JWT шифрование форматы данных
Некоторые токены имеют четыре точки вместо двух и полезную нагрузку, отличную от JSON. В этом посте объясняется компактная сериализация JWE, что содержит каждая из ее пяти частей и почему ни один инструмент, предназначенный только для декодирования, не может показать свои утверждения.
Четыре точки и полезная нагрузка, отличная от JSON — признаки того, что вы держите JWE, а не JWS.
Четыре точки и пять сегментов обозначают компактный конверт, отличный от привычной трехчастной подписанной формы. Попытка проанализировать его средние байты как утверждения JWT приводит к абсурду, поскольку содержимое представляет собой зашифрованный текст, а не написание base64url открытого текста JSON.
ToolAcre проверяет количество сегментов перед декодированием. Пять частей запускают сообщение INVALID_JWT, которое идентифицирует JWE и объясняет, почему на этом маршруте, предназначенном только для декодирования, нет ничего, что можно было бы отобразить без ключа дешифрования. Это точная граница, а не расплывчатый сбой анализа.
Пять частей — защищенный заголовок, зашифрованный ключ, вектор инициализации, зашифрованный текст и тег аутентификации.
Компактные части JWE представляют собой защищенный заголовок, материал зашифрованного ключа, значение инициализации, зашифрованный текст и тег аутентификации. Каждый из них имеет определенную криптографическую роль. Сама по себе позиция сегмента не делает второе или четвертое поле читаемыми полезными данными JWT.
Декодер может разделить и декодировать в base64url некоторые байты, но необработанные байты не являются расшифровкой. Отображение их в виде текста приведет к созданию заменяющих символов или вводящих в заблуждение фрагментов. Правильным действием будет идентифицировать конверт и перейти к реализации авторизованного получателя.
alg и enc — управление ключами и шифрование контента, и почему заголовок JWE называет два алгоритма
Заголовок JWE может содержать `alg` для управления ключами и `enc` для шифрования контента. Эти метки описывают различные операции. Как и в случае с подписанными токенами, значения заголовка — это входные данные, которые должны соответствовать политике получателя, а не разрешать токену выбирать произвольные алгоритмы.
Примечания к алгоритму ToolAcre, состоящие из трех частей, не реализуют обработку JWE, а ветвь из пяти частей завершается перед анализом заголовка. Поэтому на странице не отображаются и не одобряются определенные алгоритмы шифрования. Обратитесь к библиотеке-получателю и договору с издателем, чтобы узнать о поддерживаемых вариантах.
Ключи шифрования контента — как случайный ключ защищает полезную нагрузку и сам упаковывается для получателя.
Для шифрования контента обычно используется сгенерированный ключ шифрования контента, в то время как сегмент зашифрованного ключа передает или извлекает этот ключ в соответствии с соглашением получателя. Такое разделение позволяет защищать байты полезной нагрузки с помощью шифра содержимого, а политика управления ключами определяет, кто может восстановить ключ.
Эта концептуальная модель объясняет, почему обладания компактной строкой недостаточно для восстановления открытого текста. Требуемые секреты и политика получателя не закодированы как свободно используемые инструкции. Публичный декодер не может их изобрести и никогда не должен просить пользователей вставлять частные ключи дешифрования в общую страницу.
Когда эмитенты выбирают JWE — претензии, которые должны оставаться конфиденциальными от клиента или посредников.
Эмитенты могут выбрать шифрование, когда претензии должны оставаться конфиденциальными от владельцев или посредников, которые могут видеть подписанный токен. Правильный ли это выбор, зависит от модели угроз, распределения ключей и эксплуатационных требований. Минимизация содержимого заявки все же может быть предпочтительнее шифрования ненужных данных.
Шифрование не устраняет проблемы авторизации, проверки или метаданных. Получатель должен аутентифицировать защищенный контент и применить политику токенов после расшифровки. Читаемый результат, полученный авторизованным получателем, не является автоматически приемлемым для каждой услуги.
Почему декодирование останавливается на заголовке: полезные данные представляют собой зашифрованный текст, поэтому его может прочитать только владелец ключа.
Декодирование останавливается на структуре, поскольку предполагаемый сегмент полезной нагрузки представляет собой зашифрованный текст. ToolAcre намеренно избегает представления произвольного двоичного файла как JSON и вместо этого выдает конкретное сообщение. Это удерживает пользователей от интерпретации тарабарщины как повреждения в действительном зашифрованном конверте.
Если вы являетесь предполагаемым получателем, используйте контролируемое программное обеспечение, настроенное с использованием соответствующего ключа и алгоритмов. В противном случае нечитаемая полезная нагрузка является ожидаемым свойством безопасности. Никакой трюк с заполнением или альтернативный декодер символов не заменят расшифровку.
Что здесь не распространяется — вложенные JWT, которые подписаны, а затем зашифрованы, а также сериализация JWE JSON.
Вложенные конструкции могут подписывать контент, а затем шифровать результат или иным образом объединять слои в рамках определенного профиля. JWE также имеет представления, выходящие за рамки компактной строки из пяти частей. ToolAcre не обрабатывает эти случаи, и в этой статье не делается вывод о вложенности просто на основе метки заголовка.
Перед устранением неполадок задокументируйте, какой уровень ожидает ваша система. В противном случае команда может попытаться проверить подпись на зашифрованном тексте или декодировать внутренний токен, который не был аутентифицирован. Пусть выбранная библиотека JOSE обрабатывает порядок в соответствии с явной политикой.
Вывод: декодер может показывать только то, что не зашифровано — декодер ToolAcre JWT показывает заголовок и полезные данные подписанного токена; Полезная нагрузка JWE изначально нечитабельна
Декодер может показать только то, что не зашифровано. ToolAcre считывает JSON из заголовка и полезных данных входных данных со знаком, состоящих из трех частей, а пять сегментов вызывают пояснительную остановку. Это различие не позволяет интерфейсу, предназначенному только для декодирования, притворяться, что у него есть возможности получателя.
Используйте количество сегментов как ключ к маршрутизации, а не как результат доверия. Три читаемые части по-прежнему требуют проверки подписи; пять зашифрованных частей требуют авторизованной расшифровки и проверки. Ни в одном случае визуальный вывод сам по себе не подтверждает подлинность утверждений и не предоставляет доступ.