6
나는 우리의 인증 서버에서 JSON Web Token (JWT)을 지원하는 것으로서, latest draft being 08으로 JSON 웹 암호화 (JWE) 사양을 읽었습니다. 이 정의 비대칭 암호화 방법을 사용JSON 웹 암호화 (JWE)로 암호화 된 보안 토큰의 발급자를 확인합니까?
는대칭 키 (콘텐츠 마스터 키)를받는 공개 키를 이용하여 암호화된다. 이는받는 사람 만 해독 할 수 있고 토큰이 의도 된 것인지 확인할 수 있도록하는 것이 좋습니다.
일반적으로 토큰이 인 사람이 누구인지 증명할 수도 있습니다. 예를 들어에서 볼 수 있습니다. 공개 키를 사용하여 검증 할 수있는 발급자의 개인 키를 사용하여 생성 된 서명. 그러나 서명은 발급자의 개인 키에 대한 언급없이 콘텐츠 마스터 키 또는받는 사람의 공개 키에서 파생 된 것처럼 보입니다. 만큼 알려졌다 예상 토큰의 형식으로 - -이없이
, 그것은 같은 날 것으로 보인다받는 사람의 공개 키 (즉, 사람)가 누구 유효한 토큰을 생성 할 수; 신뢰할 수있는 인증 서버가 아닙니다.
나는 (멀리에서) 암호화에 대한 전문가가 아니에요 그래서 내가 여기서 뭔가를 누락 확신 해요. 수신자는 비대칭으로 암호화 된 토큰이 신뢰할 수있는 발급자로부터 왔는지 어떻게 확인합니까?
json으로 웹 서명 (JWS)는 발행자의 개인 키를 사용하여 자신의 공개 키를 검증 할 수있다 서명을 정의 않는 사양 , 내가 생각하던 것이 JWE 토큰의 페이로드해야인지 궁금 점을 감안 JWS 토큰이 될까요?
멋지다. 참조 용으로 감사드립니다. 스펙을 좀더 조심스럽게 다시 읽으면 섹션 10에서도이 문제를 다루고 있으며 다음과 같은 추가 지침이 있습니다. "중첩 된 JWT의 구문 및 서명 작업은 순서에 관계없이 적용될 수 있지만 일반적으로 보낸 사람은 메시지에 서명해야하며 결과를 암호화하여 서명을 암호화합니다. 이렇게하면 서명을 제거한 공격을 방지하고 암호화 된 메시지 만 남기고 서명자에게 개인 정보를 제공 할 수 있습니다. 또한 암호화 된 텍스트의 서명은 많은 관할 지역에서 유효하지 않습니다. " –
예, 암호화 된 메시지 자체가 GCM 또는 암호화 후 HMAC 체계를 통해 무결성 보호되므로 이해가됩니다. 이것은 또한 메일 링리스트에서 Mike Jonessuggested와 반대입니다. 이 물건을 구현하는 동안 항상 어딘가에 빠지기위한 충분한 범위가 있습니다 :). –
JWE를 해독하고 JAVA에서 클레임 세트를 추출해야합니다. 거기에 도서관이 있나요? – user243655