Объединение JWE и JWS

Просто изучая JOSE, я понимаю, что JWE для шифрования, а JWS для подписи. Мне кажется, что я не могу найти примеров полезных данных, которые зашифрованы и подписаны.

Давайте представим, что у меня есть полезная нагрузка hello world, Правильно ли делать что-то подобное? JWS(JWE('hello world') с зашифрованным JWE в качестве полезной нагрузки JWS?

Источник

2 ответа

Решение

JSON Web Token (JWT) - это открытый стандарт, который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. JWT - это общее имя для следующих типов токенов:

  • JSON Web Signature (JWS): полезная нагрузка кодируется и подписывается, чтобы можно было проверить целостность утверждений.

  • JSON Web Encryption (JWE): их полезная нагрузка зашифрована, поэтому претензии скрыты от других сторон.

JWT, JWS и JWE
Изображение было извлечено с этой страницы.

Правильно ли делать что-то подобное? JWS(JWE('hello world') с зашифрованным JWE в качестве полезной нагрузки JWS?

Это вложенный JWT, и его концепция определена в RFC 7519:

JWT, в котором используются вложенные подписи и / или шифрование. Во вложенных JWT JWT используется в качестве полезной нагрузки или значения открытого текста вмещающей структуры JWS или JWE соответственно.

Вы можете добавить JWE в качестве заявки на полезную нагрузку JWS, однако рекомендуется другой способ: сначала подписать сообщение, а затем зашифровать результат, как указано в том же документе:

11.2. Порядок подписи и шифрования

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

Источник

Вам следует обратить внимание, когда вы говорите о подписи или шифровании в случае асимметричных ключей.
предположим, что вы хотите отправить свой токен от производителя к потребителю.
Подпись и шифрование должны выполняться с использованием разных пар ключей.
Вы должны подписать закрытый ключ производителя
И
вы должны зашифровать с помощью открытого ключа потребителя
ТАК
--> потребитель ДОЛЖЕН иметь возможность получить ПРАВИЛЬНЫЙ открытый ключ производителя для проверки подписи, обычно это должно быть сделано с получением сертификата и его проверкой. сертификат путем проверки цепочки доверия. Если сертификат действителен, используйте его открытый ключ.
--> таким же образом ПРОИЗВОДИТЕЛЬ ДОЛЖЕН иметь действительный сертификат потребителя для шифрования.

Я думаю, что для большей безопасности того, что описано в спецификации, недостаточно для общего случая: JWK(JWS('hello world!')) подразумевает, что ваш потребитель должен систематически расшифровывать все входящие сообщения, чтобы узнать личность отправителя. Таким образом, поскольку мир в целом может знать открытый ключ потребителя, злоумышленник может попытаться провести DoS-атаку, отправив большой пакет больших зашифрованных сообщений. Поэтому хорошо фильтровать их дополнительным MAC-адресом с использованием закрытого ключа отправителя или обмениваться всем в безопасном TLS-туннеле с взаимной аутентификацией...

Источник
Другие вопросы по тегам