2013-03-19 4 views
6

Я читал спецификацию JSON Web Encryption (JWE) с помощью latest draft being 08, так как мы смотрим на поддержку JSON Web Tokens (JWT) на нашем сервере аутентификации.Проверка эмитента маркера безопасности, зашифрованного с помощью JSON Web Encryption (JWE)?

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

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

Без этого мне кажется, что до тех пор, пока известен формат токена, который ожидался, - любой, у кого есть открытый ключ получателя (то есть кто-либо), может генерировать действительный токен; а не только доверенный сервер аутентификации.

Я не эксперт по криптографии (далеко от него), поэтому я уверен, что здесь что-то отсутствует. Как получатель проверяет, что асимметрично зашифрованный токен получен от доверенного эмитента?

Учитывая, что JSON Web Подписи (JWS) спецификация имеет определить подписи, которые используют секретный ключ эмитента и может быть проверена с их помощью открытого ключа, я задаюсь вопросом, является ли идея заключается в том, что полезная нагрузка маркера JWE должна быть токеном JWS?

ответ

4

JWT, конечно, позволяет использовать вложенные полезные нагрузки. На самом деле есть specific reference, что и в спецификации, где параметр заголовка cty (content-type) может быть установлен в JWT, чтобы указать, что полезная нагрузка - это фактически другая JWT.

Таким образом, вы, скорее всего, создадите JWE и оберните его в JWS, подписанный вашим личным ключом. Это также похоже на вывод (или хотя бы одно решение) от this thread в списке рассылки JOSE. Есть еще related thread по уменьшению размера полезной нагрузки. В общем, список рассылки, вероятно, стоит следить за тем, как люди, стоящие за спецификацией, выходят на улицу.

+1

Прохладный, спасибо за ссылки. При более тщательном повторном просмотре спецификации раздел 10 также, как представляется, охватывает это, и содержит некоторые дополнительные указания: «Хотя синтаксически операции подписи и шифрования для вложенных JWT могут применяться в любом порядке, обычно отправители должны подписывать сообщение и затем шифровать результат (таким образом, шифруя подпись). Это предотвращает атаки, в которых подпись лишается, оставляя только зашифрованное сообщение, а также обеспечивая конфиденциальность подписывающего лица. Кроме того, подписи по зашифрованному тексту не считаются действительными во многих юрисдикциях. " –

+0

Да, я думаю, это имеет смысл, поскольку зашифрованное сообщение само по себе защищено целостностью через GCM или схему encrypt-then-HMAC. Это также противоположно тому, что Майк Джоннес предложил в списке рассылки. Всегда есть много возможностей для того, чтобы что-то ускользнуть, реализуя этот материал :). –

+0

Мне нужно расшифровать JWE и извлечь заявку в JAVA. Есть ли библиотека, которая это делает? – user243655