[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7516 Microsoft
Category: Standards Track J. Hildebrand
ISSN: 2070-1721 Cisco
May 2015
JSON 웹 암호화 (JWE)
요약
JSON 웹 암호화(JWE)는 JSON 기반 데이터 구조를 사용하여
암호화된 콘텐츠를 표현한다. 이 명세와 함께 사용하기 위한
암호 알고리즘과 식별자는 별도의 JSON 웹 알고리즘(JWA)
명세와 해당 명세에서 정의된 IANA 레지스트리에 설명되어 있다.
관련된 디지털 서명 및 메시지 인증 코드(MAC) 기능은
별도의 JSON 웹 서명(JWS) 명세에 설명되어 있다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 인터넷 공학 태스크 포스(IETF)의 산물이다.
이는 IETF 커뮤니티의 합의를 반영한다.
공개 검토를 거쳤으며, 인터넷 공학 운영 위원회(IESG)에 의해
출판 승인을 받았다. 인터넷 표준에 대한 추가 정보는
RFC 5741의 섹션 2에서 확인할 수 있다.
이 문서의 현재 상태, 모든 정오표, 그리고 이에 대한 피드백을
제공하는 방법에 대한 정보는 다음에서 얻을 수 있다.
http://www.rfc-editor.org/info/rfc7516.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones & Hildebrand Standards Track [Page 1]
RFC 7516 JSON Web Encryption (JWE) May 2015
목차
1. 서론 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 표기 규칙 . . . . . . . . . . . . . . . . . . . . . . . 4
2. 용어 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON 웹 암호화(JWE) 개요 . . . . . . . . . . . . . . . . 8
3.1. JWE 컴팩트 직렬화 개요 . . . . . . . . . . . . . . . . 8
3.2. JWE JSON 직렬화 개요 . . . . . . . . . . . . . . . . . 9
3.3. JWE 예제 . . . . . . . . . . . . . . . . . . . . . . . 10
4. JOSE 헤더 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. 등록된 헤더 매개변수 이름 . . . . . . . . . . . . . . 11
4.1.1. "alg"(알고리즘) 헤더 매개변수 . . . . . . . . . . 12
4.1.2. "enc"(암호화 알고리즘) 헤더 매개변수 . . . . . . 12
4.1.3. "zip"(압축 알고리즘) 헤더 매개변수 . . . . . . 12
4.1.4. "jku"(JWK 세트 URL) 헤더 매개변수 . . . . . . . 13
4.1.5. "jwk"(JSON 웹 키) 헤더 매개변수 . . . . . . . . 13
4.1.6. "kid"(키 ID) 헤더 매개변수 . . . . . . . . . . . 13
4.1.7. "x5u"(X.509 URL) 헤더 매개변수 . . . . . . . . . 13
4.1.8. "x5c"(X.509 인증서 체인) 헤더 매개변수 . . . 13
4.1.9. "x5t"(X.509 인증서 SHA-1 지문) 헤더
매개변수 . . . . . . . . . . . . . . . . . . . . . . 14
4.1.10. "x5t#S256"(X.509 인증서 SHA-256 지문)
헤더 매개변수 . . . . . . . . . . . . . . . . . . 14
4.1.11. "typ"(타입) 헤더 매개변수 . . . . . . . . . . . . 14
4.1.12. "cty"(콘텐츠 타입) 헤더 매개변수 . . . . . . . . 14
4.1.13. "crit"(중요) 헤더 매개변수 . . . . . . . . . 14
4.2. 공개 헤더 매개변수 이름 . . . . . . . . . . . . . . 14
4.3. 개인 헤더 매개변수 이름 . . . . . . . . . . . . . . 15
5. JWE 생성 및 소비 . . . . . . . . . . . . . . . . . . . . 15
5.1. 메시지 암호화 . . . . . . . . . . . . . . . . . . . 15
5.2. 메시지 복호화 . . . . . . . . . . . . . . . . . . . 17
5.3. 문자열 비교 규칙 . . . . . . . . . . . . . . . . . . 20
6. 키 식별 . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. 직렬화 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. JWE 컴팩트 직렬화 . . . . . . . . . . . . . . . . . 20
7.2. JWE JSON 직렬화 . . . . . . . . . . . . . . . . . . 20
7.2.1. 일반 JWE JSON 직렬화 구문 . . . . . . . . . . . 21
7.2.2. 평탄화된 JWE JSON 직렬화 구문 . . . . . . . . . 23
8. TLS 요구 사항 . . . . . . . . . . . . . . . . . . . . . . 24
9. JWS 객체와 JWE 객체의 구분 . . . . . . . . . . . . . . . 24
10. IANA 고려 사항 . . . . . . . . . . . . . . . . . . . . . . 25
10.1. JSON 웹 서명 및 암호화 헤더 매개변수
등록 . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. 레지스트리 내용 . . . . . . . . . . . . . . . . 25
11. 보안 고려 사항 . . . . . . . . . . . . . . . . . . . . . . 27
11.1. 키 엔트로피 및 난수 값 . . . . . . . . . . . . . 27
11.2. 키 보호 . . . . . . . . . . . . . . . . . . . . . . 27
11.3. 일치하는 알고리즘 강도 사용 . . . . . . . . . . . 28
Jones & Hildebrand Standards Track [Page 2]
RFC 7516 JSON Web Encryption (JWE) May 2015
11.4. 적응적 선택 암호문 공격 . . . . . . . . . . . . . . . . 28
11.5. 타이밍 공격 . . . . . . . . . . . . . . . . . . . . 28
12. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . 29
12.2. 정보 제공 참고 문헌 . . . . . . . . . . . . . . . . . 30
부록 A. JWE 예제 . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1. RSAES-OAEP 및 AES GCM을 사용하는 JWE 예제 . . . . . 32
A.1.1. JOSE 헤더 . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. 콘텐츠 암호화 키(CEK) . . . . . . . . . . . . . 32
A.1.3. 키 암호화 . . . . . . . . . . . . . . . . . . . . 33
A.1.4. 초기화 벡터 . . . . . . . . . . . . . . . . . . . 34
A.1.5. 추가 인증 데이터 . . . . . . . . . . . . . . . . . 35
A.1.6. 콘텐츠 암호화 . . . . . . . . . . . . . . . . . . 35
A.1.7. 전체 표현 . . . . . . . . . . . . . . . . . . . . 36
A.1.8. 검증 . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. RSAES-PKCS1-v1_5 및
AES_128_CBC_HMAC_SHA_256을 사용하는 JWE 예제 . . . . . . . . . . . . . . . . 36
A.2.1. JOSE 헤더 . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. 콘텐츠 암호화 키(CEK) . . . . . . . . . . . . . 37
A.2.3. 키 암호화 . . . . . . . . . . . . . . . . . . . . 38
A.2.4. 초기화 벡터 . . . . . . . . . . . . . . . . . . . 39
A.2.5. 추가 인증 데이터 . . . . . . . . . . . . . . . . . 40
A.2.6. 콘텐츠 암호화 . . . . . . . . . . . . . . . . . . 40
A.2.7. 전체 표현 . . . . . . . . . . . . . . . . . . . . 40
A.2.8. 검증 . . . . . . . . . . . . . . . . . . . . . . . 41
A.3. AES 키 래핑 및
AES_128_CBC_HMAC_SHA_256을 사용하는 JWE 예제 . . . . . . . . . . . . . . . . 41
A.3.1. JOSE 헤더 . . . . . . . . . . . . . . . . . . . . . 41
A.3.2. 콘텐츠 암호화 키(CEK) . . . . . . . . . . . . . 42
A.3.3. 키 암호화 . . . . . . . . . . . . . . . . . . . . 42
A.3.4. 초기화 벡터 . . . . . . . . . . . . . . . . . . . 42
A.3.5. 추가 인증 데이터 . . . . . . . . . . . . . . . . . 43
A.3.6. 콘텐츠 암호화 . . . . . . . . . . . . . . . . . . 43
A.3.7. 전체 표현 . . . . . . . . . . . . . . . . . . . . 43
A.3.8. 검증 . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. 일반 JWE JSON 직렬화를 사용하는 JWE 예제 . . . . 44
A.4.1. 수신자별 비보호 JWE 헤더 . . . . . . . . . . . . 45
A.4.2. JWE 보호 헤더 . . . . . . . . . . . . . . . . . . 45
A.4.3. JWE 공유 비보호 헤더 . . . . . . . . . . . . . . 45
A.4.4. 전체 JOSE 헤더 값 . . . . . . . . . . . . . . . . 45
A.4.5. 추가 인증 데이터 . . . . . . . . . . . . . . . . . 46
A.4.6. 콘텐츠 암호화 . . . . . . . . . . . . . . . . . . 46
A.4.7. 전체 JWE JSON 직렬화 표현 . . . . . . . . . . . 47
A.5. 평탄화된 JWE JSON 직렬화를 사용하는 JWE 예제 . . . 47
부록 B. AES_128_CBC_HMAC_SHA_256 계산 예제 . . . . 48
B.1. 키에서 MAC_KEY 및 ENC_KEY 추출 . . . . . . . . . . 48
B.2. 평문을 암호화하여 암호문 생성 . . . . . . . . . . 49
B.3. AAD 길이의 64비트 빅엔디언 표현 . . . . . 49
Jones & Hildebrand Standards Track [Page 3]
RFC 7516 JSON Web Encryption (JWE) May 2015
B.4. 초기화 벡터 값 . . . . . . . . . . . . . . . . . . . 49
B.5. HMAC 계산을 위한 입력 생성 . . . . . . . . . . . . 50
B.6. HMAC 값 계산 . . . . . . . . . . . . . . . . . . . 50
B.7. 인증 태그 생성을 위한 HMAC 값 절단 . . . . . 50
감사의 글 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1. 서론
JSON 웹 암호화(JWE)는 JSON 기반 데이터 구조를 사용하여
암호화된 콘텐츠를 표현한다 [RFC7159]. JWE 암호화 메커니즘은
임의의 옥텟 시퀀스에 대해 암호화를 수행하고 무결성 보호를
제공한다.
JWE에 대해 서로 밀접하게 관련된 두 가지 직렬화가 정의되어 있다.
JWE 컴팩트 직렬화는 HTTP Authorization 헤더 및 URI 쿼리
매개변수와 같은 공간 제약 환경을 위한 간결하고 URL 안전한
표현이다. JWE JSON 직렬화는 JWE를 JSON 객체로 표현하며
동일한 콘텐츠를 여러 당사자에게 암호화할 수 있게 한다.
두 직렬화는 동일한 암호학적 기반을 공유한다.
이 명세와 함께 사용하기 위한 암호 알고리즘과 식별자는
별도의 JSON 웹 알고리즘(JWA)
[JWA] 명세와 해당
명세에서 정의된 IANA 레지스트리에 설명되어 있다.
관련된 디지털 서명 및 MAC 기능은
별도의 JSON 웹 서명(JWS)
[JWS]
명세에 설명되어 있다.
이 명세에서 정의된 이름은 결과 표현을 간결하게 만드는 것이
핵심 목표이므로 짧다.
1.1. 표기 규칙
이 문서에서 사용되는 키워드 "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", 및
"OPTIONAL"은
"Key words for use in RFCs to Indicate Requirement Levels"
[RFC2119]에
설명된 대로 해석되어야 한다.
이러한 해석은 용어가 모두 대문자로 나타날 때에만 적용된다.
BASE64URL(OCTETS)는
[JWS]의
섹션 2에 따라 OCTETS의 base64url 인코딩을 의미한다.
UTF8(STRING)은 STRING의 UTF-8
[RFC3629]
표현의 옥텟을 의미하며, 여기서 STRING은
0개 이상의 유니코드
[UNICODE]
문자로 이루어진 시퀀스이다.
Jones & Hildebrand Standards Track [Page 4]
RFC 7516 JSON Web Encryption (JWE) May 2015
ASCII(STRING)는 STRING의 ASCII
[RFC20]
표현의 옥텟을 의미하며, 여기서 STRING은
0개 이상의 ASCII 문자로 이루어진 시퀀스이다.
두 값 A와 B의 연결은 A || B로 표기한다.
2. 용어
"JSON Web Signature (JWS)", "Base64url Encoding",
"Collision-Resistant Name", "Header Parameter", "JOSE Header", 및
"StringOrURI"라는 용어는 JWS 명세
[JWS]에 정의되어 있다.
"Ciphertext", "Digital Signature", "Initialization Vector
(IV)", "Message Authentication Code (MAC)", 및 "Plaintext"라는
용어는
"Internet Security Glossary, Version 2"
[RFC4949]에
정의되어 있다.
다음 용어는 이 명세에서 정의된다:
JSON Web Encryption (JWE)
암호화되고 무결성이 보호된 메시지를 나타내는 데이터 구조.
연관 데이터가 포함된 인증된 암호화(AEAD)
AEAD 알고리즘은 평문을 암호화하고, 추가 인증 데이터
(Additional Authenticated Data)를 지정할 수 있으며,
암호문과 추가 인증 데이터에 대해 통합된 콘텐츠 무결성
검사를 제공한다. AEAD 알고리즘은 두 입력,
즉 평문과 추가 인증 데이터 값을 받아,
두 출력인 암호문과 인증 태그 값을 생성한다.
AES Galois/Counter Mode(GCM)는 이러한 알고리즘 중 하나이다.
추가 인증 데이터(AAD)
암호화되지는 않지만 무결성 보호가 되는 AEAD 연산의 입력.
인증 태그
암호문과 추가 인증 데이터의 무결성을 보장하는 AEAD 연산의 출력.
일부 알고리즘은 인증 태그를 사용하지 않을 수 있으며,
이 경우 이 값은 빈 옥텟 시퀀스이다.
콘텐츠 암호화 키(CEK)
평문을 암호화하여 암호문과 인증 태그를 생성하는 데 사용되는
AEAD 알고리즘의 대칭 키.
Jones & Hildebrand Standards Track [Page 5]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE 암호화된 키
암호화된 콘텐츠 암호화 키 값.
일부 알고리즘의 경우 JWE 암호화된 키 값은
빈 옥텟 시퀀스로 지정된다.
JWE 초기화 벡터
평문을 암호화할 때 사용되는 초기화 벡터 값.
일부 알고리즘은 초기화 벡터를 사용하지 않을 수 있으며,
이 경우 이 값은 빈 옥텟 시퀀스이다.
JWE AAD
인증된 암호화 연산에 의해 무결성 보호되는 추가 값.
이는 JWE JSON 직렬화를 사용할 때만 존재할 수 있다.
(JWE 컴팩트 직렬화 또는 JWE JSON 직렬화를 사용할 때
AAD 값을 무결성 보호되는 헤더 매개변수 값으로 포함시켜
동일한 효과를 얻을 수도 있으나,
이 경우 값이 이중으로 base64url 인코딩되는 비용이 발생한다.)
JWE 암호문
추가 인증 데이터를 사용하여 평문을 인증된 암호화한 결과로
생성된 암호문 값.
JWE 인증 태그
추가 인증 데이터를 사용하여 평문을 인증된 암호화한 결과로
생성된 인증 태그 값.
JWE 보호 헤더
인증된 암호화 연산에 의해 무결성 보호되는 헤더 매개변수를
포함하는 JSON 객체.
이러한 매개변수는 JWE의 모든 수신자에게 적용된다.
JWE 컴팩트 직렬화의 경우 이는 전체 JOSE 헤더를 구성한다.
JWE JSON 직렬화의 경우 이는 JOSE 헤더의 한 구성 요소이다.
JWE 공유 비보호 헤더
무결성 보호되지 않지만 JWE의 모든 수신자에게 적용되는
헤더 매개변수를 포함하는 JSON 객체.
이는 JWE JSON 직렬화를 사용할 때만 존재할 수 있다.
JWE 수신자별 비보호 헤더
JWE의 단일 수신자에게 적용되는 헤더 매개변수를 포함하는
JSON 객체.
이러한 헤더 매개변수 값은 무결성 보호되지 않는다.
이는 JWE JSON 직렬화를 사용할 때만 존재할 수 있다.
JWE 컴팩트 직렬화
JWE를 간결하고 URL 안전한 문자열로 표현한 것.
Jones & Hildebrand Standards Track [Page 6]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE JSON 직렬화
JWE를 JSON 객체로 표현한 것.
JWE JSON 직렬화는 동일한 콘텐츠를 여러 당사자에게
암호화할 수 있게 한다.
이 표현은 간결성을 위해 최적화되어 있지 않으며
URL 안전하지도 않다.
키 관리 모드
사용할 콘텐츠 암호화 키 값을 결정하는 방법.
CEK 값을 결정하는 데 사용되는 각 알고리즘은
특정 키 관리 모드를 사용한다.
이 명세에서 사용하는 키 관리 모드는
키 암호화, 키 래핑, 직접 키 합의,
키 래핑을 사용하는 키 합의, 및 직접 암호화이다.
키 암호화
비대칭 암호화 알고리즘을 사용하여
의도된 수신자에게 CEK 값을 암호화하는 키 관리 모드.
키 래핑
대칭 키 래핑 알고리즘을 사용하여
의도된 수신자에게 CEK 값을 암호화하는 키 관리 모드.
직접 키 합의
키 합의 알고리즘을 사용하여 CEK 값을 합의하는
키 관리 모드.
키 래핑을 사용하는 키 합의
키 합의 알고리즘을 사용하여 대칭 키를 합의한 후,
해당 대칭 키 래핑 알고리즘을 사용하여
의도된 수신자에게 CEK 값을 암호화하는 키 관리 모드.
직접 암호화
사용되는 CEK 값이 당사자 간에 공유되는
비밀 대칭 키 값인 키 관리 모드.
Jones & Hildebrand Standards Track [Page 7]
RFC 7516 JSON Web Encryption (JWE) May 2015
3. JSON Web Encryption (JWE) 개요
JWE는 JSON 데이터 구조와 base64url 인코딩을 사용하여
암호화된 콘텐츠를 표현한다. 이러한 JSON 데이터 구조는
RFC 7159의 섹션 2
[RFC7159]에 따라,
어떤 JSON 값이나 구조 문자 앞이나 뒤에 공백 및/또는
줄 바꿈을 포함할 수 있다. JWE는 다음의 논리적 값들을
표현한다(각각은 섹션 2에 정의되어 있다):
o JOSE 헤더
o JWE 암호화된 키
o JWE 초기화 벡터
o JWE AAD
o JWE 암호문
o JWE 인증 태그
JWE의 경우, JOSE 헤더 멤버는 다음 값들의 멤버들의 합집합이다
(각각은 섹션 2에 정의되어 있다):
o JWE 보호된 헤더
o JWE 공유 비보호 헤더
o JWE 수신자별 비보호 헤더
JWE는 인증된 암호화를 사용하여 평문의 기밀성과 무결성,
그리고 JWE 보호된 헤더와 JWE AAD의 무결성을 보장한다.
이 문서는 JWE를 위한 두 가지 직렬화를 정의한다:
JWE 컴팩트 직렬화라 불리는 컴팩트하고 URL-안전한 직렬화와,
JWE JSON 직렬화라 불리는 JSON 직렬화이다. 두 직렬화 모두에서,
JWE 보호된 헤더, JWE 암호화된 키, JWE 초기화 벡터,
JWE 암호문, 그리고 JWE 인증 태그는,
JSON이 임의의 옥텟 시퀀스를 직접 표현하는 방법이 없기 때문에
base64url로 인코딩된다. 존재하는 경우, JWE AAD 역시
base64url로 인코딩된다.
3.1. JWE 컴팩트 직렬화 개요
JWE 컴팩트 직렬화에서는 JWE 공유 비보호 헤더나
JWE 수신자별 비보호 헤더가 사용되지 않는다.
이 경우, JOSE 헤더와 JWE 보호된 헤더는 동일하다.
Jones & Hildebrand Standards Track [Page 8]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE 컴팩트 직렬화에서 JWE는 다음을 연결한 것으로 표현된다:
BASE64URL(UTF8(JWE 보호된 헤더)) || '.' ||
BASE64URL(JWE 암호화된 키) || '.' ||
BASE64URL(JWE 초기화 벡터) || '.' ||
BASE64URL(JWE 암호문) || '.' ||
BASE64URL(JWE 인증 태그)
JWE 컴팩트 직렬화에 대한 자세한 정보는
섹션 7.1을 참조하라.
3.2. JWE JSON 직렬화 개요
JWE JSON 직렬화에서는 JWE 보호된 헤더,
JWE 공유 비보호 헤더, 그리고 JWE 수신자별 비보호 헤더 중
하나 이상이 반드시 존재해야 한다. 이 경우,
JOSE 헤더의 멤버는 존재하는 JWE 보호된 헤더,
JWE 공유 비보호 헤더, 그리고 JWE 수신자별 비보호 헤더
값들의 멤버들의 합집합이다.
JWE JSON 직렬화에서 JWE는 다음의 여덟 멤버 중 일부 또는 전부를
포함하는 JSON 객체로 표현된다:
"protected", 값은 BASE64URL(UTF8(JWE 보호된 헤더))
"unprotected", 값은 JWE 공유 비보호 헤더
"header", 값은 JWE 수신자별 비보호 헤더
"encrypted_key", 값은 BASE64URL(JWE 암호화된 키)
"iv", 값은 BASE64URL(JWE 초기화 벡터)
"ciphertext", 값은 BASE64URL(JWE 암호문)
"tag", 값은 BASE64URL(JWE 인증 태그)
"aad", 값은 BASE64URL(JWE AAD)
여섯 개의 base64url로 인코딩된 결과 문자열과
두 개의 비보호 JSON 객체 값은 JSON 객체의 멤버로
표현된다. 이들 값 중 일부의 포함은 선택 사항이다.
JWE JSON 직렬화는 평문을 여러 수신자에게 암호화할 수도 있다.
JWE JSON 직렬화에 대한 자세한 정보는
섹션 7.2를 참조하라.
Jones & Hildebrand Standards Track [Page 9]
RFC 7516 JSON Web Encryption (JWE) May 2015
3.3. JWE 예제
이 예제는 평문
"The true sign of intelligence is
not knowledge but imagination."
을 수신자에게 암호화한다.
다음 예제의 JWE 보호된 헤더는 다음을 선언한다:
o 콘텐츠 암호화 키는 RSAES-OAEP
[RFC3447]
알고리즘을 사용하여 수신자에게 암호화되며,
그 결과 JWE 암호화된 키가 생성된다.
o 인증된 암호화는 256비트 키를 사용하는
AES GCM
[AES]
[NIST.800-38D]
알고리즘을 사용하여 평문에 대해 수행되며,
그 결과 암호문과 인증 태그가 생성된다.
{"alg":"RSA-OAEP","enc":"A256GCM"}
이 JWE 보호된 헤더를 BASE64URL(UTF8(JWE 보호된 헤더))로
인코딩하면 다음 값이 된다:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
이 JWE를 완성하기 위한 나머지 단계는 다음과 같다:
o 임의의 콘텐츠 암호화 키(CEK)를 생성한다.
o RSAES-OAEP 알고리즘을 사용하여
수신자의 공개 키로 CEK를 암호화하여
JWE 암호화된 키를 생성한다.
o JWE 암호화된 키를 base64url로 인코딩한다.
o 임의의 JWE 초기화 벡터를 생성한다.
o JWE 초기화 벡터를 base64url로 인코딩한다.
o 추가 인증 데이터 암호화 매개변수를
ASCII(BASE64URL(UTF8(JWE 보호된 헤더)))로 설정한다.
o CEK를 암호화 키로, JWE 초기화 벡터와
추가 인증 데이터 값을 사용하여
AES GCM 알고리즘으로 평문에 대해
인증된 암호화를 수행하고,
128비트 인증 태그 출력을 요청한다.
o 암호문을 base64url로 인코딩한다.
o 인증 태그를 base64url로 인코딩한다.
Jones & Hildebrand Standards Track [Page 10]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 최종 표현을 조립한다: 이 결과의 컴팩트 직렬화는
BASE64URL(UTF8(JWE 보호된 헤더)) || '.' ||
BASE64URL(JWE 암호화된 키) || '.' ||
BASE64URL(JWE 초기화 벡터) || '.' ||
BASE64URL(JWE 암호문) || '.' ||
BASE64URL(JWE 인증 태그)
문자열이다.
이 예제의 최종 결과는 (표시 목적상 줄 바꿈을 포함하여)
다음과 같다:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
이 JWE 계산의 전체 세부 사항은
부록 A.1을 참조하라.
JWE JSON 직렬화를 사용하는 A.4 및 A.5 섹션의 예제를 포함한
추가 예제는 부록 A를 참조하라.
4. JOSE 헤더
JWE의 경우, JOSE 헤더를 나타내는 JSON 객체의 멤버들은
평문에 적용된 암호화와,
선택적으로 JWE의 추가 속성들을 설명한다.
JOSE 헤더 내의 헤더 매개변수 이름은
[JWS]의 섹션 4에 설명된 것과 같이
반드시 고유해야 한다.
구현이 이해하지 못하는 헤더 매개변수를 처리하는 규칙 또한
동일하다.
헤더 매개변수 이름의 분류 역시 동일하다.
4.1. 등록된 헤더 매개변수 이름
JWEs에서 사용하기 위한 다음의 헤더 매개변수 이름들은
[JWS]에 의해 설정된
IANA "JSON Web Signature and Encryption Header Parameters"
레지스트리에 등록되어 있으며,
그 의미는 아래에 정의되어 있다.
공통 레지스트리에 의해 표시된 바와 같이,
JWS와 JWE는 공통의 헤더 매개변수 공간을 공유한다;
어떤 매개변수가 두 명세 모두에서 사용되는 경우,
그 사용은 명세들 간에 호환되어야 한다.
Jones & Hildebrand Standards Track [Page 11]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.1. "alg" (알고리즘) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.1에 정의된
"alg" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
헤더 매개변수는 CEK의 값을 암호화하거나
결정하는 데 사용되는 암호 알고리즘을 식별한다는 점이 다르다.
"alg" 값이 지원되는 알고리즘을 나타내지 않거나,
수신자가 해당 알고리즘과 함께 사용할 수 있는 키를
보유하고 있지 않은 경우,
암호화된 콘텐츠는 사용할 수 없다.
이 용도를 위한 정의된 "alg" 값의 목록은,
[JWA]에 의해 설정된
IANA "JSON Web Signature and Encryption Algorithms"
레지스트리에서 찾을 수 있으며,
이 레지스트리의 초기 내용은
[JWA]의 섹션 4.1에
정의된 값들이다.
4.1.2. "enc" (암호화 알고리즘) 헤더 매개변수
"enc"(암호화 알고리즘) 헤더 매개변수는
암호문과 인증 태그를 생성하기 위해
평문에 대해 인증된 암호화를 수행하는 데 사용되는
콘텐츠 암호화 알고리즘을 식별한다.
이 알고리즘은 지정된 키 길이를 가진
AEAD 알고리즘이어야 한다.
"enc" 값이 지원되는 알고리즘을 나타내지 않는 경우,
암호화된 콘텐츠는 사용할 수 없다.
"enc" 값은
[JWA]에 의해 설정된
IANA "JSON Web Signature and Encryption Algorithms"
레지스트리에 등록되거나,
충돌 저항 이름을 포함하는 값이어야 한다.
"enc" 값은 StringOrURI 값을 포함하는
대소문자를 구분하는 ASCII 문자열이다.
이 헤더 매개변수는 반드시 존재해야 하며,
구현에 의해 이해되고 처리되어야 한다.
이 용도를 위한 정의된 "enc" 값의 목록은,
[JWA]에 의해 설정된
IANA "JSON Web Signature and Encryption Algorithms"
레지스트리에서 찾을 수 있으며,
이 레지스트리의 초기 내용은
[JWA]의 섹션 5.1에
정의된 값들이다.
4.1.3. "zip" (압축 알고리즘) 헤더 매개변수
"zip"(압축 알고리즘)은,
존재하는 경우 암호화 전에 평문에 적용된다.
이 명세에서 정의된 "zip" 값은 다음과 같다:
o "DEF" - DEFLATE
[RFC1951]
알고리즘을 사용한 압축
다른 값들도 사용할 수 있다.
압축 알고리즘 값은
[JWA]에 의해 설정된
IANA "JSON Web Encryption Compression Algorithms"
레지스트리에 등록될 수 있다.
"zip" 값은 대소문자를 구분하는 문자열이다.
"zip" 매개변수가 존재하지 않으면,
암호화 전에 평문에 압축이 적용되지 않는다.
사용되는 경우,
이 헤더 매개변수는 무결성 보호되어야 하므로,
JWE 보호된 헤더 내에만 존재해야 한다.
이 헤더 매개변수의 사용은 선택 사항이다.
이 헤더 매개변수는 구현에 의해
반드시 이해되고 처리되어야 한다.
Jones & Hildebrand Standards Track [Page 12]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.4. "jku" (JWK 세트 URL) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.2에 정의된
"jku" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
JWK 세트 리소스에는
JWE가 암호화된 대상인 공개 키가 포함되어 있으며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
4.1.5. "jwk" (JSON Web Key) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.3에 정의된
"jwk" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
키는 JWE가 암호화된 대상인 공개 키이며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
4.1.6. "kid" (키 ID) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.4에 정의된
"kid" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
키 힌트는 JWE가 암호화된 대상인 공개 키를 참조하며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
이 매개변수는 발신자가
JWE 수신자에게 키 변경을 명시적으로
알릴 수 있도록 한다.
4.1.7. "x5u" (X.509 URL) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.5에 정의된
"x5u" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
X.509 공개 키 인증서 또는 인증서 체인
[RFC5280]
에는 JWE가 암호화된 대상인 공개 키가 포함되어 있으며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
4.1.8. "x5c" (X.509 인증서 체인) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.6에 정의된
"x5c" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
X.509 공개 키 인증서 또는 인증서 체인
[RFC5280]
에는 JWE가 암호화된 대상인 공개 키가 포함되어 있으며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
"x5c" 값의 예제는
[JWS]의
부록 B를 참조하라.
Jones & Hildebrand Standards Track [Page 13]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.9. "x5t" (X.509 인증서 SHA-1 지문) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.7에 정의된
"x5t" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
지문이 참조하는 인증서에는
JWE가 암호화된 대상인 공개 키가 포함되어 있으며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
인증서 지문은 때때로
인증서 핑거프린트라고도 불린다.
4.1.10. "x5t#S256" (X.509 인증서 SHA-256 지문) 헤더
매개변수
이 매개변수는
[JWS]의 섹션 4.1.8에 정의된
"x5t#S256" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
지문이 참조하는 인증서에는
JWE가 암호화된 대상인 공개 키가 포함되어 있으며,
이를 통해 JWE를 복호화하는 데 필요한
개인 키를 결정할 수 있다는 점이 다르다.
인증서 지문은 때때로
인증서 핑거프린트라고도 불린다.
4.1.11. "typ" (타입) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.9에 정의된
"typ" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
타입은 이 전체 JWE의 타입이라는 점이 다르다.
4.1.12. "cty" (콘텐츠 타입) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.10에 정의된
"cty" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
타입은 보호된 콘텐츠(평문)의 타입이라는 점이 다르다.
4.1.13. "crit" (중요) 헤더 매개변수
이 매개변수는
[JWS]의 섹션 4.1.11에 정의된
"crit" 헤더 매개변수와
동일한 의미, 구문, 처리 규칙을 갖지만,
JWS용 헤더 매개변수가 아니라
JWE용 헤더 매개변수를 참조한다는 점이 다르다.
4.2. 공개 헤더 매개변수 이름
추가적인 헤더 매개변수 이름은
JWE를 사용하는 자에 의해 정의될 수 있다.
그러나 충돌을 방지하기 위해,
새로운 헤더 매개변수 이름은
[JWS]에 의해 설정된
IANA "JSON Web Signature and Encryption Header Parameters"
레지스트리에 등록되거나,
공개 이름, 즉 충돌 저항 이름을 포함하는 값이어야 한다.
각 경우에 있어서,
이름 또는 값을 정의하는 자는 합리적인 주의를 기울여야 한다.
Jones & Hildebrand Standards Track [Page 14]
RFC 7516 JSON Web Encryption (JWE) May 2015
자신들이 사용하는 네임스페이스의 일부를 제어하는 방법을 확인하기 위한 예방 조치를
취해야 합니다.
새로운 헤더 파라미터는 신중하게 도입되어야 하며, 그렇지 않으면 호환되지 않는 JWE가
발생할 수 있습니다.
4.3. 개인 헤더 파라미터 이름
JWE의 생산자와 소비자는 헤더 파라미터 이름으로 개인 이름을 사용할 것에 대해 동의할
수 있습니다. 개인 이름은 등록된 헤더 파라미터 이름(섹션 4.1)이나
공개 헤더 파라미터 이름(섹션 4.2)이 아닌 이름입니다. 공개 헤더
파라미터 이름과 달리, 개인 헤더 파라미터 이름은 충돌의 가능성이 있으며 신중하게 사용해야
합니다.
5. Producing and Consuming JWEs
5.1. Message Encryption
메시지 암호화 과정은 다음과 같습니다. 단계들 간에 입력과 출력에 의존성이 없을 경우, 단계들의 순서는 중요하지 않습니다.
1. 콘텐츠 암호화 키 값을 결정하는 데 사용되는 알고리즘에 의해 채택된 키 관리 모드를 결정합니다. (이 알고리즘은 결과 JWE의 "alg" (알고리즘) 헤더 파라미터에 기록됩니다.)
2. 키 래핑, 키 암호화, 또는 키 래핑을 통한 키 합의가 사용되는 경우, 무작위 CEK 값을 생성합니다. 무작위 값 생성에 대한 고려 사항은 RFC 4086을 참조하십시오. CEK는 콘텐츠 암호화 알고리즘에 요구되는 길이와 동일해야 합니다.
3. 직접 키 합의 또는 키 래핑을 통한 키 합의가 사용되는 경우, 키 합의 알고리즘을 사용하여 합의된 키 값을 계산합니다. 직접 키 합의가 사용될 경우, CEK는 합의된 키가 됩니다. 키 래핑을 통한 키 합의가 사용될 경우, 합의된 키는 CEK를 래핑하는 데 사용됩니다.
4. 키 래핑, 키 암호화, 또는 키 래핑을 통한 키 합의가 사용되는 경우, CEK를 수신자에게 암호화하고, 그 결과는 JWE 암호화된 키가 됩니다.
5. 직접 키 합의 또는 직접 암호화가 사용될 경우, JWE 암호화된 키는 빈 바이트 시퀀스가 됩니다.
Jones & Hildebrand Standards Track [Page 15]
RFC 7516 JSON Web Encryption (JWE) May 2015
6. 직접 암호화가 사용될 경우, CEK는 공유 대칭 키가 됩니다.
7. 인코딩된 키 값을 BASE64URL(JWE 암호화된 키)로 계산합니다.
8. JWE JSON 직렬화가 사용되는 경우, 이 과정을 각 수신자에 대해 반복합니다 (1-7단계).
9. 콘텐츠 암호화 알고리즘에 대해 요구되는 크기의 무작위 JWE 초기화 벡터를 생성합니다 (알고리즘에 따라 다름); 그렇지 않으면 JWE 초기화 벡터는 빈 바이트 시퀀스가 됩니다.
10. 인코딩된 초기화 벡터 값을 BASE64URL(JWE 초기화 벡터)로 계산합니다.
11. "zip" 파라미터가 포함된 경우, 지정된 압축 알고리즘을 사용하여 평문을 압축하고, M은 압축된 평문의 바이트 시퀀스가 됩니다. 그렇지 않으면 M은 평문의 바이트 시퀀스가 됩니다.
12. 원하는 헤더 파라미터 집합을 포함하는 JSON 객체를 생성합니다. 이는 JOSE 헤더를 구성하며, JWE 보호 헤더, JWE 공유 비보호 헤더, JWE 수신자별 비보호 헤더 중 하나 이상을 포함합니다.
13. 인코딩된 보호 헤더 값을 BASE64URL(UTF8(JWE 보호 헤더))로 계산합니다. JWE 보호 헤더가 없으면 (JWE JSON 직렬화에서 "보호된" 멤버가 없을 경우) 이 값은 빈 문자열이 됩니다.
14. 추가 인증된 데이터 암호화 파라미터는 ASCII(인코딩된 보호 헤더)입니다. 그러나 JWE AAD 값이 존재하면 (JWE JSON 직렬화에서만 발생할 수 있음) 추가 인증된 데이터 암호화 파라미터는 ASCII(인코딩된 보호 헤더 || '.' || BASE64URL(JWE AAD))가 됩니다.
15. M을 CEK, JWE 초기화 벡터, 추가 인증된 데이터 값 및 지정된 콘텐츠 암호화 알고리즘을 사용하여 JWE 암호문 값과 JWE 인증 태그를 생성합니다. 이 태그는 암호화 작업에서 생성된 인증 태그입니다.
16. 인코딩된 암호문 값을 BASE64URL(JWE 암호문)으로 계산합니다.
Jones & Hildebrand Standards Track [Page 16]
RFC 7516 JSON Web Encryption (JWE) May 2015
17. 인코딩된 인증 태그 값을 BASE64URL(JWE 인증 태그)로 계산합니다.
18. JWE AAD 값이 존재하면, 인코딩된 AAD 값을 BASE64URL(JWE AAD)로 계산합니다.
19. 원하는 직렬화된 출력을 생성합니다. 이 결과의 컴팩트 직렬화는 문자열 BASE64URL(UTF8(JWE 보호 헤더))
|| '.' || BASE64URL(JWE 암호화된 키) || '.' || BASE64URL(JWE 초기화 벡터) || '.' || BASE64URL(JWE 암호문)
|| '.' || BASE64URL(JWE 인증 태그)입니다. JWE JSON 직렬화는 섹션 7.2에서 설명됩니다.
5.2. 메시지 복호화
메시지 복호화 프로세스는 암호화
프로세스의 역순이다. 단계들의 순서는 입력과 출력 간에
의존성이 없는 경우에는 중요하지 않다.
단계들 중 하나라도 실패하면 암호화된 내용은
검증될 수 없다.
수신자가 여러 명인 경우, 수신자의 암호화된
내용을 검증해야 JWE가 수락될 것인지에 대한
결정은 애플리케이션에 달려 있다. 어떤 경우에는
모든 수신자의 암호화된 내용을 검증해야 하며,
그렇지 않으면 JWE가 무효로 간주된다. 다른 경우에는
단일 수신자의 암호화된 내용만 검증에 성공하면 된다.
하지만 모든 경우에 있어서, 적어도 한 명의 수신자에
대한 암호화된 내용은 반드시(MUST) 검증이
성공해야 하며, 그렇지 않으면 JWE는 반드시 무효로
간주되어야(MUST) 한다.
1. JWE 표현을 구문 분석하여 JWE 구성 요소의
직렬화된 값을 추출한다. JWE Compact
Serialization을 사용하는 경우, 이러한 구성 요소들은
JWE Protected Header, JWE Encrypted Key,
JWE Initialization Vector, JWE Ciphertext,
JWE Authentication Tag의 base64url로
인코딩된 표현이며, JWE JSON Serialization을
사용하는 경우에는 여기에는 JWE AAD의 base64url로
인코딩된 표현과 JWE Shared Unprotected Header 및
JWE Per-Recipient Unprotected Header 값도 포함된다.
JWE Compact Serialization을 사용하는 경우,
JWE Protected Header, JWE Encrypted Key,
JWE Initialization Vector, JWE Ciphertext,
JWE Authentication Tag는 그 순서대로 base64url로
인코딩된 값으로 표현되며, 각 값은 점('.')
문자로 구분되며, 정확히 네 개의 구분용
점 문자가 사용된다. JWE JSON Serialization은
7.2절에 설명되어 있다.
Jones & Hildebrand Standards Track [Page 17]
RFC 7516 JSON Web Encryption (JWE) May 2015
2. JWE Protected Header, JWE Encrypted Key, JWE Initialization
Vector, JWE Ciphertext, JWE Authentication Tag 및
JWE AAD의 인코딩된 표현을 base64url로
디코딩한다. 이때 줄바꿈, 공백, 기타
추가 문자가 사용되지 않았다는 제한을 따른다.
3. 디코딩된 JWE Protected Header에서 나온 옥텟
시퀀스가 RFC 7159에 따라 완전하고
유효한 JSON 객체의 UTF-8로 인코드된
표현인지 확인하고, JWE Protected Header를
이 JSON 객체로 간주한다.
4. JWE Compact Serialization을 사용하는 경우,
JOSE Header는 JWE Protected Header로 둔다.
JWE JSON Serialization을 사용하는 경우에는,
JOSE Header는 JWE Protected Header,
JWE Shared Unprotected Header, JWE Per-Recipient
Unprotected Header 구성원들의 합집합으로 둔다.
이 단계에서, JOSE Header가 중복된 Header Parameter
이름을 갖고 있지 않은지 검증한다. JWE JSON Serialization을
사용하는 경우, JOSE Header를 구성하는 별도의 JSON 객체
값에서 동일한 Header Parameter 이름이 나타나지 않아야 함을
포함한다.
5. 구현체가 이 명세에서 요구하거나 사용 중인
알고리즘, 또는 "crit" Header Parameter 값에 의해
지원해야 하는 모든 필드를 처리하고 이해할 수 있는지
확인하며, 해당 매개변수 값들도 이해되고
지원되는지 확인한다.
6. "alg" (알고리즘) Header Parameter에 의해
지정된 알고리즘이 사용하는 키 관리 모드를
결정한다.
7. JWE가 수신자가 알고 있는 키를 사용하는지
확인한다.
8. Direct Key Agreement 또는 Key Agreement with Key Wrapping이
사용되는 경우, 키 합의 알고리즘을 사용하여 합의된 키 값을
계산한다. Direct Key Agreement가 사용되는 경우,
CEK를 이 합의된 키로 설정한다. Key Agreement with Key Wrapping이
사용되는 경우, 이 합의된 키가 JWE Encrypted Key를
복호화하는 데 사용된다.
9. Key Wrapping, Key Encryption, 또는 Key Agreement with Key Wrapping이
사용되는 경우, JWE Encrypted Key를 복호화하여 CEK를 생성한다.
CEK의 길이는 콘텐츠 암호화 알고리즘에서 요구되는
길이와 동일해야 한다(MUST). 수신자가 여러 명인 경우,
각 수신자는 자신의 소유한 키로 암호화된 JWE Encrypted Key만
복호화할 수 있다. 따라서 수신자별 JWE Encrypted Key 값 중에서
하나만 복호화하여 CEK 값을 얻는 것이 정상이다.
타이밍 공격에 대한 보안 고려 사항은 11.5절을
참조하라.
10. Direct Key Agreement 또는 Direct Encryption이 사용되는 경우,
JWE Encrypted Key 값이 빈 옥텟 시퀀스인지 확인한다.
11. Direct Encryption이 사용되는 경우, CEK를 공유 대칭 키로 설정한다.
12. 이 수신자에 대해 CEK가 성공적으로 결정되었는지 여부를
기록한다.
13. JWE JSON Serialization이 사용되는 경우, 표현에 포함된 각
수신자에 대해 단계 4~12를 반복한다.
14. Encoded Protected Header 값을 BASE64URL(UTF8(JWE Protected Header))로
계산한다. JWE Protected Header가 존재하지 않는 경우
(이는 JWE JSON Serialization에서 "protected" 멤버가 없을 때만 발생),
이 값을 빈 문자열로 설정한다.
15. 추가 인증 데이터(Additional Authenticated Data) 암호화 매개변수를
ASCII(Encoded Protected Header)로 설정한다. 그러나 JWE AAD 값이
존재하는 경우(이는 JWE JSON Serialization에서만 발생할 수 있음),
추가 인증 데이터를 ASCII(Encoded Protected Header || '.' ||
BASE64URL(JWE AAD))로 설정한다.
16. 지정된 콘텐츠 암호화 알고리즘을 사용하여 CEK, JWE Initialization Vector,
추가 인증 데이터 값 및 JWE Authentication Tag를 입력으로 하여
JWE Ciphertext를 복호화한다. 복호화된 평문을 반환하고,
알고리즘에 지정된 방식으로 JWE Authentication Tag를 검증하며,
JWE Authentication Tag가 올바르지 않은 경우 복호화된 출력을
내보내지 않고 입력을 거부해야 한다.
17. "zip" 매개변수가 포함된 경우, 복호화된 평문을 지정된
압축 알고리즘을 사용하여 압축 해제한다.
18. 모든 복호화 단계가 어느 누구에게도 성공하지 않은 경우,
JWE는 반드시(MUST) 무효로 간주되어야 한다. 그렇지 않다면
평문을 출력한다. JWE JSON Serialization일 경우, 복호화가 성공과 실패한
수신자의 결과를 애플리케이션으로 반환한다.
Jones & Hildebrand Standards Track [Page 19]
RFC 7516 JSON Web Encryption (JWE) May 2015
마지막으로, 특정 컨텍스트에서 사용할 수 있는 알고리즘에 대한 결정은
애플리케이션에 달려 있음을 유의하라. JWE가 성공적으로 복호화될 수 있다
하더라도, JWE에 사용된 알고리즘이 애플리케이션에서 허용되지 않은 경우,
이를 무효화해야 한다(SHOULD).
5.3. 문자열 비교 규칙
이 명세의 문자열 비교 규칙은 [JWS]
5.3절에 정의된 규칙과 동일하다.
6. 키 식별
이 명세의 키 식별 방법은 [JWS]
6절에 정의된 방법과 동일하지만, 식별되는 키는 JWE가 암호화된
공개 키라는 점이 다르다.
7. 직렬화
JWE는 두 가지 직렬화 방식을 사용한다: JWE Compact Serialization 또는
JWE JSON Serialization. 이 명세를 사용하는 애플리케이션은
해당 애플리케이션에서 사용하는 직렬화 방식과 직렬화 기능을
지정해야 한다. 예를 들어, 애플리케이션은 JWE JSON Serialization만
사용하거나 단일 수신자에 대한 JWE JSON Serialization 지원만
사용하도록 지정하거나 다중 수신자에 대한 지원을 지정할 수 있다.
JWE 구현체는 자신이 지원하도록 설계된 애플리케이션에
필요한 기능만 구현하면 된다.
7.1. JWE Compact Serialization
JWE Compact Serialization은 암호화된 콘텐츠를 간결하고,
URL-안전 문자열로 표현한다. 이 문자열은 다음과 같다:
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)
JWE Compact Serialization은 단일 수신자만 지원하며, JWE 공유 비보호
헤더, JWE 수신자별 비보호 헤더 또는 JWE AAD 값을
표현하기 위한 구문을 제공하지 않는다.
7.2. JWE JSON Serialization
JWE JSON Serialization은 암호화된 콘텐츠를 JSON 객체로
표현한다. 이 표현은 간결성에 최적화되어 있지 않으며
URL-안전하지도 않다.
Jones & Hildebrand Standards Track [Page 20]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE JSON Serialization을 위해 두 가지 밀접하게 관련된
구문이 정의되어 있다: 다중 수신자가 암호화될 수 있는
완전 일반 구문, 그리고 단일 수신자 구문으로 최적화된
평탄화 구문.
7.2.1. 일반 JWE JSON 직렬화 구문
완전 일반 JWE JSON 직렬화 구문에서 최상위
JSON 객체에 대해 다음 구성원이 정의되어 있다:
protected
"protected" 구성원은 반드시 존재해야 하며(MUST), JWE
Protected Header 값이 비어있지 않을 경우,
BASE64URL(UTF8(JWE Protected Header)) 값을 포함해야 한다.
그렇지 않은 경우에는 존재해서는 안 된다(MUST NOT).
이 헤더 매개변수 값은 무결성 보호를 받는다.
unprotected
"unprotected" 구성원은 반드시 존재해야 하며(MUST), JWE
Shared Unprotected Header 값이 비어있지 않을 경우,
해당 값을 포함해야 한다. 그렇지 않은 경우에는 존재해서는 안 된다.
이 값은 문자열이 아닌 인코딩되지 않은 JSON 객체로 표현된다.
이 헤더 매개변수 값은 무결성 보호를 받지 않는다.
iv
"iv" 구성원은 반드시 존재해야 하며(MUST), JWE Initialization
Vector 값이 비어있지 않을 경우, BASE64URL(JWE Initialization
Vector) 값을 포함해야 한다. 그렇지 않은 경우에는 존재해서는
안 된다.
aad
"aad" 구성원은 반드시 존재해야 하며(MUST), JWE AAD 값이 비어있지
않을 경우, BASE64URL(JWE AAD) 값을 포함해야 한다. 그렇지 않은
경우에는 존재해서는 안 된다. JWE AAD 값은 무결성을 보호받도록
포함될 수 있지만 암호화되지 않은 상태로 base64url-인코딩된 값을
제공한다.
ciphertext
"ciphertext" 구성원은 반드시 존재해야 하며(MUST), BASE64URL(JWE
Ciphertext) 값을 포함해야 한다.
tag
"tag" 구성원은 JWE Authentication Tag 값이 비어있지 않을 경우,
반드시 BASE64URL(JWE Authentication Tag) 값을 포함해야 한다.
그렇지 않은 경우에는 존재해서는 안 된다.
recipients
"recipients" 구성원 값은 반드시 JSON 객체의 배열이어야 하며(MUST),
각 객체에는 한 명의 특정 수신자 정보를 포함해야 한다.
이 구성원은 반드시 존재해야 하며(MUST), 각 수신자마다 정확히
하나의 배열 요소를 포함해야 한다.
Jones & Hildebrand Standards Track [Page 21]
RFC 7516 JSON Web Encryption (JWE) May 2015
수신자가 일부 또는 모든 배열 요소 값에 대해 비어 있는 JSON 객체 "{}"를 사용하는 경우(모든 헤더 매개변수 값이
모든 수신자 간에 공유되고 암호화된 키가 사용되지 않는 경우와 같이), 이를 허용합니다.
"recipients" 배열의 JSON 객체에서 사용할 수 있는 다음 구성원을 정의합니다:
header
JWE 개별 수신자 보호되지 않은 헤더 값이 비어 있지 않은 경우, "header" 구성원은 JWE 개별 수신자
보호되지 않은 헤더의 값을 포함하고 반드시 존재해야 합니다. 그렇지 않으면
제외되어야 합니다. 이 값은 문자열이 아니라 인코딩되지 않은 JSON 객체로 표현됩니다.
이러한 헤더 매개변수 값은 무결성 보호를 받지 않습니다.
encrypted_key
"encrypted_key" 구성원은 JWE 암호화 키 값이 비어 있지 않은 경우, BASE64URL(JWE
Encrypted Key)를 포함하고 반드시 존재해야 합니다. 그렇지 않으면 제외되어야 합니다.
"header", "protected", "unprotected" 구성원 중 하나 이상은 반드시 존재해야 합니다.
수신자 계산을 위한 "alg" 및 "enc" 헤더 매개변수 값을 전달할 수 있도록 보장합니다.
위에서 정의된 JSON 객체에는 추가 구성원이 존재할수 있습니다. 구현이
이를 이해하지 못한 경우 무시해야 합니다.
일부 헤더 매개변수(예: "alg" 매개변수)는 모든 수신자 계산에서 공유될 수 있습니다.
JWE 보호된 헤더와 JWE 공유되지 않은 보호 헤더 값에서 헤더 매개변수가
모든 수신자 간에 공유됩니다.
개별 수신자 암호문 및 인증 태그 값을 생성하거나 검증할 때 사용되는
헤더 매개변수 값은 다음 세 가지 세트의 헤더 매개변수 값의 합집합으로 구성됩니다: (1)
"protected" 구성원에 나타나는 JWE 보호 헤더, (2) "unprotected" 구성원에 나타나는 JWE
공유되지 않은 보호 헤더 및 (3) 수신자의 배열 요소 내의 "header" 구성원에 나타나는
JWE 개별 수신자 보호되지 않은 헤더. 이러한 헤더 매개변수의
세트를 합친 값이 JOSE 헤더를 구성합니다. 세 가지 위치에서의 헤더 매개변수 이름은
반드시 겹치지 않아야 합니다.
각 JWE 암호화 키 값은 동일한 매개변수를 사용하여 JWE 간략화 직렬화와 동일한 방식으로
생성됩니다. 이로 인해 "recipients" 배열 내의 각 JWE 암호화 키 값이 동일해지는
바람직한 결과를 가져옵니다.
Jones & Hildebrand Standards Track [Page 22]
RFC 7516 JSON Web Encryption (JWE) May 2015
마찬가지로, JWE 암호문 및 JWE 인증 태그 값은 JWE 보호 헤더 값이 JWE
간략화 직렬화에서 사용된 값과 일치하는 경우, JWE 간략화 직렬화에 대해 생성된 값과
일치합니다(이는 무결성 보호된 헤더 매개변수 값을 나타냅니다).
모든 수신자는 동일한 JWE 보호 헤더, JWE 초기화 벡터, JWE 암호문 및 JWE 인증 태그 값을
사용하며, 이는 메시지가 클 경우 잠재적으로 큰 공간 절약을 제공합니다. 따라서,
평문 값의 처리를 지정하는 모든 헤더 매개변수는 모든 수신자에 대해 동일해야 합니다.
이는 주로 각 수신자에 대한 JOSE 헤더의 "enc"(암호화 알고리즘) 헤더 매개변수 값과 해당
알고리즘의 모든 매개변수가 동일해야 함을 의미합니다.
요약하면, 일반 JWE JSON 직렬화를 사용하는 JWE의 구문은 다음과 같습니다:
{
"protected":"<무결성 보호된 공유 헤더 내용>",
"unprotected":<무결성 보호되지 않은 공유 헤더 내용>,
"recipients":[
{"header":<수신자별 보호되지 않은 헤더 1 내용>,
"encrypted_key":"<암호화된 키 1 내용>"},
...
{"header":<수신자별 보호되지 않은 헤더 N 내용>,
"encrypted_key":"<암호화된 키 N 내용>"}],
"aad":"<추가 인증된 데이터 내용>",
"iv":"<초기화 벡터 내용>",
"ciphertext":"<암호문 내용>",
"tag":"<인증 태그 내용>"
}
일반 JWE JSON 직렬화 구문을 사용하는 JWE의 예는 부록 A.4에서
확인할 수 있습니다.
7.2.2. 단일화된 JWE JSON 직렬화 구문
단일화된 JWE JSON 직렬화 구문은 일반 구문을 기반으로 하며 단일 수신자
사례에 최적화하여 단일화합니다. "recipients" 구성원을 제거하고 대신
"recipients" 배열에서 사용하기로 정의된 구성원("header" 및 "encrypted_key" 구성원)을
최상위 JSON 객체(즉, "ciphertext" 구성원과 동일한 수준)에 배치합니다.
Jones & Hildebrand Standards Track [Page 23]
RFC 7516 JSON Web Encryption (JWE) May 2015
이 구문을 사용할 때는 "recipients" 구성원이 존재해서는 안 됩니다. 이 구문 차이 외에는
단일화된 구문을 사용하는 JWE JSON 직렬화 객체를 일반 구문을 사용하는 객체와 동일한
방식으로 처리합니다.
요약하면, 단일화된 JWE JSON 직렬화를 사용하는 JWE의 구문은 다음과 같습니다:
{
"protected":"<무결성 보호된 헤더 내용>",
"unprotected":<무결성 보호되지 않은 헤더 내용>,
"header":<더 많은 무결성 보호되지 않은 헤더 내용>,
"encrypted_key":"<암호화된 키 내용>",
"aad":"<추가 인증된 데이터 내용>",
"iv":"<초기화 벡터 내용>",
"ciphertext":"<암호문 내용>",
"tag":"<인증 태그 내용>"
}
단일화된 구문을 사용할 때, 일반 구문을 사용할 때와 마찬가지로, 보호되지 않은 헤더
매개변수 값은 "unprotected" 구성원이나 "header" 구성원에 있거나 둘 다에 있을 수
있습니다.
단일화된 JWE JSON 직렬화 구문을 사용하는 JWE의 예은 부록 A.5를
참고하십시오.
8. TLS 요구사항
이 사양에 대한 전송 계층 보안(TLS) 요구사항은 [JWS]의
섹션 8에 정의된 요구사항과 동일합니다.
9. JWS와 JWE 객체 구별하기
객체가 JWS인지 JWE인지 구별할 수 있는 몇 가지 방법이 있습니다. 이러한 모든
방법은 모든 유효한 입력값에 대해 동일한 결과를 산출합니다. 잘못된 입력값의
경우에는 다른 결과를 산출할 수 있습니다.
o 객체가 JWS 간략화 직렬화 또는 JWE 간략화 직렬화를 사용하는 경우,
JWS와 JWE의 base64url-encoded 세그먼트 개수는 다릅니다. JWS는 두 개의 마침표('.')
문자로 구분된 세 개의 세그먼트를 가지고, JWE는 네 개의 마침표('.') 문자로
구분된 다섯 개의 세그먼트를 가집니다.
o 객체가 JWS JSON 직렬화 또는 JWE JSON 직렬화를 사용하는 경우, 사용된 구성원이 다릅니다.
JWS는 "payload" 구성원을 가지며 JWE는 가지지 않습니다. JWE는 "ciphertext" 구성원을 가지며
JWS는 가지지 않습니다.
Jones & Hildebrand Standards Track [Page 24]
RFC 7516 JSON Web Encryption (JWE) May 2015
o JWS의 JOSE 헤더는 "alg"(알고리즘) 헤더 파라미터 값을 검토하여 JWE의 JOSE 헤더와 구분할 수 있습니다.
값이 디지털 서명 또는 MAC 알고리즘이거나 "none"일 경우 JWS용입니다.
값이 키 암호화, 키 래핑, 직접 키 합의, 키 래핑이 포함된 키 합의 또는 직접 암호화 알고리즘일 경우 JWE용입니다.
("alg" 값을 추출해 검사하는 것은 JWS Compact Serialization 또는
JWE Compact Serialization을 사용할 때는 쉽고, JWS JSON Serialization이나
JWE JSON Serialization을 사용할 때는 더 어려울 수 있습니다.)
o JWS의 JOSE 헤더는 "enc"(암호화 알고리즘) 멤버 존재 여부로도 JWE의 JOSE 헤더와 구분할 수 있습니다.
"enc" 멤버가 있으면 JWE이고, 없으면 JWS입니다.
10. IANA 고려사항
10.1. JSON 웹 서명 및 암호화 헤더 파라미터 등록
이 절에서는 4.1절에서 정의된 헤더 파라미터 이름을
[JWS]에서 설정한 IANA "JSON Web Signature and Encryption Header
Parameters" 레지스트리에 등록합니다.
10.1.1. 레지스트리 내용
o 헤더 파라미터 이름: "alg"
o 헤더 파라미터 설명: 알고리즘
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.1절
o 헤더 파라미터 이름: "enc"
o 헤더 파라미터 설명: 암호화 알고리즘
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.2절
o 헤더 파라미터 이름: "zip"
o 헤더 파라미터 설명: 압축 알고리즘
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.3절
Jones & Hildebrand Standards Track [Page 25]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 헤더 파라미터 이름: "jku"
o 헤더 파라미터 설명: JWK 세트 URL
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.4절
o 헤더 파라미터 이름: "jwk"
o 헤더 파라미터 설명: JSON 웹 키
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.5절
o 헤더 파라미터 이름: "kid"
o 헤더 파라미터 설명: 키 ID
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.6절
o 헤더 파라미터 이름: "x5u"
o 헤더 파라미터 설명: X.509 URL
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.7절
o 헤더 파라미터 이름: "x5c"
o 헤더 파라미터 설명: X.509 인증서 체인
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.8절
o 헤더 파라미터 이름: "x5t"
o 헤더 파라미터 설명: X.509 인증서 SHA-1 지문
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.9절
o 헤더 파라미터 이름: "x5t#S256"
o 헤더 파라미터 설명: X.509 인증서 SHA-256 지문
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.10절
o 헤더 파라미터 이름: "typ"
o 헤더 파라미터 설명: 타입
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.11절
Jones & Hildebrand Standards Track [Page 26]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 헤더 파라미터 이름: "cty"
o 헤더 파라미터 설명: 콘텐츠 타입
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.12절
o 헤더 파라미터 이름: "crit"
o 헤더 파라미터 설명: 중요
o 헤더 파라미터 사용 위치: JWE
o 변경 제어자: IESG
o 명세 문서: RFC 7516의 4.1.13절
11. 보안 고려사항
모든 암호화 애플리케이션에 관련된 보안 이슈는 JWS/JWE/JWK 에이전트에서 반드시 해결해야 합니다.
여기에는 사용자의 비대칭 개인키 및 대칭 비밀키 보호,
다양한 공격에 대한 대응책 적용 등이 포함됩니다.
JWS 명세의 모든 보안 고려사항은 이 명세에도 적용됩니다.
마찬가지로, XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411]의
모든 보안 고려사항도, XML 특정 고려사항을 제외하고 적용됩니다.
11.1. 키 엔트로피 및 임의값
키 엔트로피 및 임의값에 대한 보안 고려사항은
[JWS]의 10.1절을 참조하십시오.
거기 나열된 임의값의 사용 외에도, 암호화 수행시에는 콘텐츠 암호화 키(CEK)와
초기화 벡터(IV)에도 임의값이 사용됨을 유의하십시오.
11.2. 키 보호
키 보호에 대한 보안 고려사항은
[JWS]의 10.2절을 참조하십시오.
거기서 보호해야 할 키 외에도, 암호화를 수행하는 구현체는
키 암호화 키와 콘텐츠 암호화 키를 보호해야 합니다.
키 암호화 키가 노출되면 해당 키로 보호된 모든 내용이
노출될 수 있습니다. 마찬가지로, 콘텐츠 암호화 키가 노출되어도
관련된 암호화 콘텐츠가 공개될 수 있습니다.
Jones & Hildebrand Standards Track [Page 27]
RFC 7516 JSON Web Encryption (JWE) May 2015
11.3. 일치하는 알고리즘 강도 사용
가능한 경우, 강도가 일치하는 알고리즘을 함께 사용해야 합니다.
예를 들어, AES 키 래핑을 특정 키 사이즈로 사용할 때,
AES GCM도 같은 키 사이즈로 사용하는 것이 권장됩니다.
키 암호화 알고리즘과 콘텐츠 암호화 알고리즘이 다르면,
실질적인 보안 강도는 두 알고리즘 중 더 약한 쪽에 의해 결정됩니다.
또한, 대칭 키 교환에 사용되는 공개키 강도 산정 관련 정보는
RFC 3766 [RFC3766]를 참고하십시오.
11.4. 적응형 선택-암호문 공격(CCA)
복호화 시, JWE 수신자가 메시지 복호화 오라클로 악용되지 않도록 특별히 주의해야 합니다.
RFC 3218 [RFC3218]를 참조하여
RSAES-PKCS1-v1_5 공격에 대한 구체적 대응책을 확인하십시오.
공격자는 "alg" 헤더 파라미터 값을 "RSA-OAEP"에서 "RSA1_5"로 변경시켜,
포맷 오류를 발생시키고 이를 이용해 CEK를 복구하려 할 수 있습니다(비록 CEK는 RSAES-OAEP로 암호화되었더라도).
따라서, 암호화된 내용을 거부할 때 반드시 CEK, 추가 인증 데이터, 암호문 모두에 대해 단일 오류로 보고해야 합니다.
또한 특정 키를 제한된 알고리즘(일반적으로 하나)에서만 사용하도록 하면
이런 유형의 공격을 예방할 수 있습니다.
예를 들어, 키가 "RSA-OAEP" 용으로만 마킹되어 있으면
그 키로 "RSA1_5" 알고리즘 복호화 시도는
즉시 잘못된 키 사용임을 이유로 실패해야 합니다.
11.5. 타이밍 공격
RFC 3218 [RFC3218]에 설명된 공격을 완화하기 위해,
수신자는 암호화된 키의 포맷, 패딩, 길이 오류를 구분해서는 안 됩니다.
잘못된 포맷의 키가 수신되면,
수신자가 임의로 생성한 CEK를 대체하여 다음 단계로 진행하는 것이
타이밍 공격 완화에 강력히 권장됩니다.
Jones & Hildebrand Standards Track [Page 28]
RFC 7516 JSON Web Encryption (JWE) May 2015
12. 참조
12.1. 규범적 참조
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7518>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015년
5월, <http://www.rfc-editor.org/info/rfc7515>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, 1996년 5월,
<http://www.rfc-editor.org/info/rfc1951>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969년 10월,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003년 11월,
<http://www.rfc-editor.org/info/rfc3629>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007년 8월,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 2008년 5월,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 2014년 3월,
<http://www.rfc-editor.org/info/rfc7159>.
Jones & Hildebrand Standards Track [Page 29]
RFC 7516 JSON Web Encryption (JWE) May 2015
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
12.2. 참고 문헌
[AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197,
2001년 11월, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", 2010년 9월,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", 진행 중인 작업,
draft-rescorla-jsms-00, 2011년 3월.
[NIST.800-38D]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
2007년 11월, <http://csrc.nist.gov/publications/
nistpubs/800-38D/SP-800-38D.pdf>.
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218,
DOI 10.17487/RFC3218, 2002년 1월,
<http://www.rfc-editor.org/info/rfc3218>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, 2003년 2월,
<http://www.rfc-editor.org/info/rfc3447>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, 2004년 4월,
<http://www.rfc-editor.org/info/rfc3766>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, 2005년 6월,
<http://www.rfc-editor.org/info/rfc4086>.
Jones & Hildebrand Standards Track [Page 30]
RFC 7516 JSON Web Encryption (JWE) May 2015
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, 2009년 9월,
<http://www.rfc-editor.org/info/rfc5652>.
[W3C.REC-xmlenc-core1-20130411]
Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
"XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium 권고안
REC-xmlenc-core1-20130411, 2013년 4월,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones & Hildebrand Standards Track [Page 31]
RFC 7516 JSON Web Encryption (JWE) May 2015
Appendix A. JWE 예제
이 절에서는 JWE 계산의 예제를 제공합니다.
A.1. 예제: RSAES-OAEP 및 AES GCM을 사용하는 JWE
이 예제는 평문 "The true sign of intelligence is
not knowledge but imagination."을 수신자에게 RSAES-OAEP을 키 암호화에,
AES GCM을 내용 암호화에 사용하여 암호화합니다. 이 평문의 표현( JSON 배열 표기법 사용)은:
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32,
111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99,
101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108,
101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105,
110, 97, 116, 105, 111, 110, 46]
A.1.1. JOSE 헤더
다음 JWE 보호 헤더는 다음을 선언합니다:
o 콘텐츠 암호화 키(CEK)가 수신자에게 RSAES-OAEP 알고리즘을 사용하여 암호화되어 JWE 암호화 키를 생성함.
o 인증된 암호화는 AES GCM 알고리즘과 256비트 키를 사용하여 평문을 암호화하고 암호문 및 인증 태그를 생성함.
{"alg":"RSA-OAEP","enc":"A256GCM"}
이 JWE 보호 헤더를 BASE64URL(UTF8(JWE Protected
Header))로 인코딩하면 다음 값이 됩니다:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
A.1.2. 콘텐츠 암호화 키(CEK)
256비트의 무작위 CEK를 생성합니다. 이 예제에서 값( JSON 배열 표기법 사용)은:
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,
212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,
234, 64, 252]
Jones & Hildebrand Standards Track [Page 32]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.3. 키 암호화
수신자의 공개 키를 사용하여 RSAES-OAEP 알고리즘으로 CEK를 암호화하여 JWE 암호화 키를 생성합니다. 이 예제는 아래에 JSON Web Key [JWK] 형식으로 표현된 RSA 키를 사용합니다(표시 목적으로 값 내 줄 바꿈이 포함되어 있음):
{"kty":"RSA",
"n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW
cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S
psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a
sbOenSZeyaxziK72UwxrrKoExv6kc5twXTq4h-QChLOln0_mtUZwfsRaMS
tPs6mS6XrgxnxbWhojf663tuEQueGC-FCMfra36C9knDFGzKsNa7LZK2dj
YgyD3JR_MB_4NUJW_TqOQtwHYbxevoJArm-L5StowjzGy-_bq6Gw",
"e":"AQAB",
"d":"kLdtIj6GbDks_ApCSTYQtelcNttlKiOyPzMrXHeI-yk1F7-kpDxY4-WY5N
WV5KntaEeXS1j82E375xxhWMHXyvjYecPT9fpwR_M9gV8n9Hrh2anTpTD9
3Dt62ypW3yDsJzBnTnrYu1iwWRgBKrEYY46qAZIrA2xAwnm2X7uGR1hghk
qDp0Vqj3kbSCz1XyfCs6_LehBwtxHIyh8Ripy40p24moOAbgxVw3rxT_vl
t3UVe4WO3JkJOzlpUf-KTVI2Ptgm-dARxTEtE-id-4OJr0h-K-VFs3VSnd
VTIznSxfyrj8ILL6MG_Uv8YAu7VILSB3lOW085-4qE3DzgrTjgyQ",
"p":"1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tZI3Mgf2EuFVbUoDBvaRQ-
SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv_hI2_1eTSPVZfzL0lf
fNn03IXqWF5MDFuoUYE0hzb2vhrlN_rKrbfDIwUbTrjjgieRbwC6Cl0",
"q":"wLb35x7hmQWZsWJmB_vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm
UDdaDYVTSNx_8Fyw1YYa9XGrGnDew00J28cRUoeBB_jKI1oma0Orv1T9aX
IWxKwd4gvxFImOWr3QRL9KEBRzk2RatUBnmDZJTIAfwTs0g68UZHvtc",
"dp":"ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ_OTowiFvgfeQ3SiresXjm9gZ5KL
hMXvo-uz-KUJWDxS5pFQ_M0evdo1dKiRTjVw_x4NyqyXPM5nULPkcpU827
rnpZzAJKpdhWAgqrXGKAECQH0Xt4taznjnd_zVpAmZZq60WPMBMfKcuE",
"dq":"Dq0gfgJ1DdFGXiLvQEZnuKEN0UUmsJBxkjydc3j4ZYdBiMRAy86x0vHCj
ywcMlYYg4yoC4YZa9hNVcsjqA3FeiL19rk8g6Qn29Tt0cj8qqyFpz9vNDB
UfCAiJVeESOjJDZPYHdHY8v1b-o-Z2X5tvLx-TCekf7oxyeKDUqKWjis",
"qi":"VIMpMYbPf47dT1w_zDUXfPimsSegnMOA1zTaX7aGk_8urY6R8-ZW1FxU7
AlWAyLWybqq6t16VFd7hQd0y6flUK4SlOydB61gwanOsXGOAOv82cHq0E3
eL4HrtZkUuKvnPrMnsUUFlfUdybVzxyjz9JF_XyaY14ardLSjf4L_FNY"
}
Jones & Hildebrand Standards Track [Page 33]
RFC 7516 JSON Web Encryption (JWE) May 2015
결과 JWE 암호화 키 값은:
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203,
22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216,
82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220,
145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214,
74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182,
13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228,
173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158,
89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138,
243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6,
41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126,
215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58,
63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98,
193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215,
206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216,
104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197,
89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219,
172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134,
117, 114, 135, 206]
이 JWE 암호화 키를 BASE64URL(JWE Encrypted Key)로 인코딩하면
다음 값이 됩니다(표시 목적의 줄 바꿈 포함):
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
A.1.4. 초기화 벡터
96비트의 무작위 JWE 초기화 벡터를 생성합니다. 이 예제에서 값은:
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
이 JWE 초기화 벡터를 BASE64URL(JWE
Initialization Vector)로 인코딩하면 다음 값이 됩니다:
48V1_ALb6US04U3b
Jones & Hildebrand Standards Track [Page 34]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.5. 추가 인증 데이터
추가 인증 데이터 암호화 매개변수를 ASCII(BASE64URL(UTF8(JWE Protected Header)))로 둡니다. 이 값은:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73,
54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
A.1.6. 내용 암호화
CEK를 암호화 키로 사용하고, JWE 초기화 벡터 및 위의 추가 인증 데이터를 사용하여 AES GCM 알고리즘으로 평문에 대해 인증된 암호화를 수행합니다. 128비트 인증 태그 출력을 요청합니다. 결과 암호문은:
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122,
233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111,
104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32,
123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205,
160, 109, 64, 63, 192]
결과 인증 태그 값은:
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91,
210, 145]
이 JWE 암호문을 BASE64URL(JWE Ciphertext)로 인코딩하면 다음
값이 됩니다(표시 목적의 줄 바꿈 포함):
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A
이 JWE 인증 태그를 BASE64URL(JWE Authentication
Tag)로 인코딩하면 다음 값이 됩니다:
XFBoMYUZodetZdvTiFvSkQ
Jones & Hildebrand Standards Track [Page 35]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.7. 완전한 표현
최종 표현을 조립합니다: 이 결과의 컴팩트 직렬화는 문자열 BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag) 입니다.
이 예제의 최종 결과(표시 목적으로 줄 바꿈 포함)는:
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
A.1.8. 검증
이 예제는 키 암호화에 RSAES-OAEP를, 내용 암호화에 AES GCM을 사용하여 JWE를 생성하는 과정을 설명합니다.
이 결과들은 이러한 알고리즘에 대한 JWE 복호화 구현을 검증하는 데 사용할 수 있습니다. RSAES-OAEP 계산에는 무작위 값이 포함되므로 위의 암호화 결과는 완전히 재현 가능하지 않습니다. 하지만 AES GCM 계산은 결정적이므로, 이 입력들을 사용하여 수행된 모든 암호화에 대해 JWE 암호화된 암호문 값은 동일합니다.
A.2. 예제: RSAES-PKCS1-v1_5 및 AES_128_CBC_HMAC_SHA_256을 사용하는 JWE
이 예제는 평문 "Live long and prosper."을 수신자에게 RSAES-PKCS1-v1_5를 키 암호화에,
AES_128_CBC_HMAC_SHA_256을 내용 암호화에 사용하여 암호화합니다. 이 평문의 표현( JSON 배열 표기법 사용)은:
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
Jones & Hildebrand Standards Track [Page 36]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.1. JOSE 헤더
다음 JWE 보호 헤더는 다음을 선언합니다:
o 콘텐츠 암호화 키가 수신자에게 RSAES-PKCS1-v1_5 알고리즘을 사용하여 암호화되어 JWE 암호화 키를 생성함.
o 인증된 암호화는 AES_128_CBC_HMAC_SHA_256 알고리즘을 사용하여 평문을 암호화하고 암호문 및 인증 태그를 생성함.
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
이 JWE 보호 헤더를 BASE64URL(UTF8(JWE Protected
Header))로 인코딩하면 다음 값이 됩니다:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.2.2. 콘텐츠 암호화 키(CEK)
256비트의 무작위 CEK를 생성합니다. 이 예제에서 키 값은:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
Jones & Hildebrand Standards Track [Page 37]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.3. 키 암호화
수신자의 공개 키를 사용하여
RSAES-PKCS1-v1_5 알고리즘으로 CEK를 암호화하여 JWE 암호화 키를 생성합니다. 이
예제는 아래에 JSON Web Key [JWK] 형식으로
표현된 RSA 키를 사용합니다(값 내의 줄 바꿈은 표시 용도일 뿐입니다):
{"kty":"RSA",
"n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl
UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre
cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_
7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI
Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU
7-VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw",
"e":"AQAB",
"d":"VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq
1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-ry
nq8cxjDTLZQ6Fz7jSjR1Klop-YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_
0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj
-VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj
T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ",
"p":"9gY2w6I6S6L0juEKsbeDAwpd9WMfgqFoeA9vEyEUuk4kLwBKcoe1x4HG68
ik918hdDSE9vDQSccA3xXHOAFOPJ8R9EeIAbTi1VwBYnbTp87X-xcPWlEP
krdoUKW60tgs1aNd_Nnc9LEVVPMS390zbFxt8TN_biaBgelNgbC95sM",
"q":"uKlCKvKv_ZJMVcdIs5vVSU_6cPtYI1ljWytExV_skstvRSNi9r66jdd9-y
BhVfuG4shsp2j7rGnIio901RBeHo6TPKWVVykPu1iYhQXw1jIABfw-MVsN
-3bQ76WLdt2SDxsHs7q7zPyUyHXmps7ycZ5c72wGkUwNOjYelmkiNS0",
"dp":"w0kZbV63cVRvVX6yk3C8cMxo2qCM4Y8nsq1lmMSYhG4EcL6FWbX5h9yuv
ngs4iLEFk6eALoUS4vIWEwcL4txw9LsWH_zKI-hwoReoP77cOdSL4AVcra
Hawlkpyd2TWjE5evgbhWtOxnZee3cXJBkAi64Ik6jZxbvk-RR3pEhnCs",
"dq":"o_8V14SezckO6CNLKs_btPdFiO9_kC1DsuUTd2LAfIIVeMZ7jn1Gus_Ff
7B7IVx3p5KuBGOVF8L-qifLb6nQnLysgHDh132NDioZkhH7mI7hPG-PYE_
odApKdnqECHWw0J-F0JWnUd6D2B_1TvF9mXA2Qx-iGYn8OVV1Bsmp6qU",
"qi":"eNho5yRBEBxhGBtQRww9QirZsB66TrfFReG_CcteI1aCneT0ELGhYlRlC
tUkTRclIfuEPmNsNDPbLoLqqCVznFbvdB7x-Tl-m0l_eFTj2KiqwGqE9PZ
B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-V7TbpxIhvepTfE0NNo"
}
Jones & Hildebrand Standards Track [Page 38]
RFC 7516 JSON Web Encryption (JWE) May 2015
결과 JWE 암호화 키 값은:
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151,
176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181,
156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156,
116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223,
226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66,
212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253,
215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128,
66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199,
54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151,
250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197,
21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102,
166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222,
150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241,
124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242,
16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244,
248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167,
101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169,
146, 114, 165, 204, 71, 136, 41, 252]
이 JWE 암호화 키를 BASE64URL(JWE Encrypted Key)로 인코딩하면
다음 값이 됩니다(표시 목적의 줄 바꿈 포함):
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A
A.2.4. 초기화 벡터
무작위 128비트 JWE 초기화 벡터를 생성합니다. 이
예제에서 값은:
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
이 JWE 초기화 벡터를 BASE64URL(JWE
Initialization Vector)로 인코딩하면 다음 값이 됩니다:
AxY8DCtDaGlsbGljb3RoZQ
Jones & Hildebrand Standards Track [Page 39]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.5. 추가 인증 데이터
추가 인증 데이터 암호화 매개변수를
ASCII(BASE64URL(UTF8(JWE Protected Header)))로 둡니다. 이 값은:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105,
74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85,
50, 73, 110, 48]
A.2.6. 내용 암호화
CEK를 암호화 키로 사용하고, JWE 초기화 벡터 및 위의 추가 인증
데이터를 사용하여 AES_128_CBC_HMAC_SHA_256 알고리즘으로 평문에 대해 인증된 암호화를 수행합니다. 부록 A.3의 값을 사용하여 이를 수행하는 단계는 부록 B에 자세히 설명되어 있습니다. 결과 암호문은:
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
결과 인증 태그 값은:
[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100,
191]
이 JWE 암호문을 BASE64URL(JWE Ciphertext)로 인코딩하면 다음
값이 됩니다:
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
이 JWE 인증 태그를 BASE64URL(JWE Authentication
Tag)로 인코딩하면 다음 값이 됩니다:
9hH0vgRfYgPnAHOd8stkvw
A.2.7. 완전한 표현
최종 표현을 조립합니다: 이 결과의 컴팩트 직렬화는 문자열 BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag) 입니다.
Jones & Hildebrand Standards Track [Page 40]
RFC 7516 JSON Web Encryption (JWE) May 2015
이 예제의 최종 결과(표시 목적의 줄 바꿈 포함)는:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw
A.2.8. 검증
이 예제는 키 암호화에 RSAES-PKCS1-v1_5를, 내용 암호화에 AES_CBC_HMAC_SHA2를 사용하여 JWE를 생성하는 과정을 설명합니다. 이러한 결과들은 이러한 알고리즘에 대한 JWE 복호화 구현을 검증하는 데 사용할 수 있습니다. RSAES-PKCS1-v1_5 계산에는 무작위 값이 포함되므로 위의 암호화 결과는 완전히 재현 가능하지 않습니다. 그러나 AES-CBC 계산은 결정적이므로, 이 입력들을 사용하여 수행된 모든 암호화에 대해 JWE 암호화된 암호문 값은 동일합니다.
A.3. 예제: AES Key Wrap 및 AES_128_CBC_HMAC_SHA_256을 사용하는 JWE
이 예제는 평문 "Live long and prosper."을 수신자에게 AES Key Wrap을 키 암호화에,
AES_128_CBC_HMAC_SHA_256을 내용 암호화에 사용하여 암호화합니다. 이 평문의 표현( JSON 배열 표기법 사용)은:
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
A.3.1. JOSE 헤더
다음 JWE 보호 헤더는 다음을 선언합니다:
o 콘텐츠 암호화 키(CEK)가 128비트 키를 사용하는 AES Key Wrap 알고리즘으로 수신자에게 암호화되어 JWE 암호화 키를 생성함.
o 인증된 암호화는 AES_128_CBC_HMAC_SHA_256 알고리즘을 사용하여 평문을 암호화하고 암호문 및 인증 태그를 생성함.
{"alg":"A128KW","enc":"A128CBC-HS256"}
Jones & Hildebrand Standards Track [Page 41]
RFC 7516 JSON Web Encryption (JWE) May 2015
이 JWE 보호 헤더를 BASE64URL(UTF8(JWE Protected
Header))로 인코딩하면 다음 값이 됩니다:
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.3.2. 콘텐츠 암호화 키(CEK)
256비트의 무작위 CEK를 생성합니다. 이 예제에서 값은:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
A.3.3. 키 암호화
공유된 대칭 키를 사용하여 AES Key Wrap 알고리즘으로 CEK를 암호화하여 JWE 암호화 키를 생성합니다. 이 예제는 아래에 JSON Web Key [JWK] 형식으로 표현된 대칭 키를 사용합니다:
{"kty":"oct",
"k":"GawgguFyGrWKav7AX4VKUg"
}
결과 JWE 암호화 키 값은:
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216,
22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3,
76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
이 JWE 암호화 키를 BASE64URL(JWE Encrypted Key)로 인코딩하면
다음 값이 됩니다:
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
A.3.4. 초기화 벡터
무작위 128비트 JWE 초기화 벡터를 생성합니다. 이
예제에서 값은:
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
이 JWE 초기화 벡터를 BASE64URL(JWE
Initialization Vector)로 인코딩하면 다음 값이 됩니다:
AxY8DCtDaGlsbGljb3RoZQ
Jones & Hildebrand Standards Track [Page 42]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.3.5. 추가 인증 데이터
추가 인증 데이터 암호화 매개변수를
ASCII(BASE64URL(UTF8(JWE Protected Header)))로 둡니다. 이 값은:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]
A.3.6. 내용 암호화
CEK를 암호화 키로 사용하고, JWE 초기화 벡터 및 위의 추가 인증
데이터를 사용하여 AES_128_CBC_HMAC_SHA_256 알고리즘으로 평문에 대해 인증된 암호화를 수행합니다. 이 예제의 값을 사용하여 이를 수행하는 단계는 부록 B에 자세히 설명되어 있습니다. 결과 암호문은:
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
결과 인증 태그 값은:
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]
이 JWE 암호문을 BASE64URL(JWE Ciphertext)로 인코딩하면 다음
값이 됩니다:
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
이 JWE 인증 태그를 BASE64URL(JWE Authentication
Tag)로 인코딩하면 다음 값이 됩니다:
U0m_YmjN04DJvceFICbCVQ
A.3.7. 완전한 표현
최종 표현을 조립합니다: 이 결과의 컴팩트 직렬화는 문자열 BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag) 입니다.
Jones & Hildebrand Standards Track [Page 43]
RFC 7516 JSON Web Encryption (JWE) May 2015
이 예제의 최종 결과(표시 목적의 줄 바꿈 포함)는:
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
U0m_YmjN04DJvceFICbCVQ
A.3.8. 검증
이 예제는 키 암호화에 AES Key Wrap을, 내용 암호화에 AES GCM을 사용하여 JWE를 생성하는 과정을 설명합니다. 이러한 결과들은 이러한 알고리즘에 대한 JWE 복호화 구현을 검증하는 데 사용할 수 있습니다. 또한 AES Key Wrap과 AES GCM 계산은 둘 다 결정적이므로, 이 입력들을 사용하여 수행된 모든 암호화에 대해 생성되는 최종 JWE 값은 동일합니다. 계산이 재현 가능하므로, 이러한 결과들은 이러한 알고리즘에 대한 JWE 암호화 구현을 검증하는 데에도 사용할 수 있습니다.
A.4. 일반 JWE JSON 직렬화 사용 예
이 절에는 일반 JWE JSON 직렬화 구문을 사용하는 예제가 포함되어 있습니다. 이 예제는
동일한 평문을 여러 수신자에게 암호화할 수 있는 기능을 보여줍니다.
이 예제에는 두 개의 수신자가 있습니다. 첫 번째 수신자에게 사용된 알고리즘과 키는
부록 A.2에서 사용된 것과 동일합니다. 두 번째 수신자에게 사용된 알고리즘과 키는
부록 A.3에서 사용된 것과 동일합니다. 따라서 결과 JWE
암호화 키 값들도 동일합니다; 해당 계산들은 여기서 반복하지 않습니다.
평문, CEK, JWE 초기화 벡터 및 JWE 보호 헤더는 암호문과 인증 태그도 공유되므로 모든 수신자에게 공유됩니다.
Jones & Hildebrand Standards Track [Page 44]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.4.1. JWE Per-Recipient Unprotected Headers
첫 번째 수신자는 RSAES-PKCS1-v1_5 알고리즘을 사용하여
CEK를 암호화합니다. 두 번째 수신자는 CEK를 암호화하기 위해 AES Key Wrap을 사용합니다. 두 키
모두에 대해 Key ID 값이 제공됩니다. 이러한 알고리즘과 키를
나타내는 데 사용되는 두 개의 JWE 수신자별
비보호 헤더 값은 다음과 같습니다:
{"alg":"RSA1_5","kid":"2011-04-29"}
그리고
{"alg":"A128KW","kid":"7"}
A.4.2. JWE Protected Header
평문에 대해 AES_128_CBC_HMAC_SHA_256 알고리즘을 사용하여
인증된 암호화를 수행하여 공통 JWE
Ciphertext 및 JWE Authentication Tag 값을 생성합니다. 이를 나타내는 JWE 보호
헤더 값은 다음과 같습니다:
{"enc":"A128CBC-HS256"}
이 JWE 보호 헤더를 BASE64URL(UTF8(JWE Protected
Header))로 인코딩하면 다음 값이 됩니다:
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.4.3. JWE Shared Unprotected Header
이 JWE는 JWK 세트를 참조하기 위해 "jku" 헤더 매개변수를 사용합니다.
이는 다음 JWE 공유 비보호 헤더 값으로 표현됩니다:
{"jku":"https://server.example.com/keys.jwks"}
A.4.4. Complete JOSE Header Values
제공된 JWE 수신자별 비보호 헤더, JWE 보호 헤더, 및 JWE 공유 비보호 헤더 값을 결합하면,
각각 첫 번째 및 두 번째 수신자에 대해 사용되는 JOSE
헤더 값은 다음과 같습니다:
{"alg":"RSA1_5",
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
Jones & Hildebrand Standards Track [Page 45]
RFC 7516 JSON Web Encryption (JWE) May 2015
and
{"alg":"A128KW",
"kid":"7",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
A.4.5. Additional Authenticated Data
추가 인증 데이터 암호화 매개변수를
ASCII(BASE64URL(UTF8(JWE Protected Header)))로 둡니다. 이 값은:
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73,
52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
A.4.6. Content Encryption
CEK를 암호화 키로 사용하고, JWE 초기화 벡터 및 위의 추가 인증
데이터를 사용하여 AES_128_CBC_HMAC_SHA_256 알고리즘으로 평문에 대해 인증된 암호화를 수행합니다. 부록 A.3의 값을 사용하여 이를 수행하는 단계는 부록 B에 자세히 설명되어 있습니다. 결과 암호문
은:
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
결과 인증 태그 값은:
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47,
207]
이 JWE 암호문을 BASE64URL(JWE Ciphertext)로 인코딩하면 다음
값이 됩니다:
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
이 JWE 인증 태그를 BASE64URL(JWE Authentication
Tag)로 인코딩하면 다음 값이 됩니다:
Mz-VPPyU4RlcuYv1IwIvzw
Jones & Hildebrand Standards Track [Page 46]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.4.7. Complete JWE JSON Serialization Representation
이러한 값들에 대한 완전한 JWE JSON 직렬화는 다음과 같습니다
(값 내부의 줄 바꿈은 표시 목적입니다):
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"recipients":[
{"header":
{"alg":"RSA1_5","kid":"2011-04-29"},
"encrypted_key":
"UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-
kFm1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKx
GHZ7PcHALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3
YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPh
cCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPg
wCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A"},
{"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ"}],
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
A.5. Example JWE Using Flattened JWE JSON Serialization
이 절에는 플래트닝된 JWE JSON 직렬화 구문을 사용하는 예제가 포함되어 있습니다. 이 예제는
평문을 단일 수신자에게 플래트닝된 JSON 구조로 암호화하는 기능을 보여줍니다.
이 예제의 값들은 이전 예제의 두 번째
수신자에 대한 값들과 동일합니다(부록 A.4).
Jones & Hildebrand Standards Track [Page 47]
RFC 7516 JSON Web Encryption (JWE) May 2015
이러한 값들에 대한 완전한 JWE JSON 직렬화는 다음과 같습니다
(값 내부의 줄 바꿈은 표시 목적입니다):
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation
이 예제는 부록 A.3의 값을 사용하여 AES_128_CBC_HMAC_SHA_256
인증된 암호화 계산에서의 단계를 보여줍니다. JWA의 해당 알고리즘이
정의된 섹션 5.2 및 5.2.3에서 설명된 바와 같이,
AES_CBC_HMAC_SHA2 계열 알고리즘은 고급 암호 표준(AES)을 사용한
암호 블록 연결(CBC) 모드와 PKCS #7 패딩을 결합하여 암호화를 수행하고,
무결성 계산을 수행하기 위해 HMAC SHA-2 함수를 사용하는 방식으로 구현됩니다 — 이 경우 HMAC SHA-256입니다.
B.1. Extract MAC_KEY and ENC_KEY from Key
이 예제에서 사용된 256비트 AES_128_CBC_HMAC_SHA_256 키 K는
(JSON 배열 표기법 사용) 다음과 같습니다:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
이 키의 처음 128비트를 HMAC SHA-256 키인 MAC_KEY로 사용합니다.
그 값은 다음과 같습니다:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206]
Jones & Hildebrand Standards Track [Page 48]
RFC 7516 JSON Web Encryption (JWE) May 2015
이 키의 마지막 128비트를 AES-CBC 키인 ENC_KEY로 사용합니다. 그
값은 다음과 같습니다:
[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44,
207]
MAC 키가 입력 키 K에서 암호화 키보다 먼저 온다는 점에 유의하십시오; 이는 식별자
"AES_128_CBC_HMAC_SHA_256" 및 "A128CBC-HS256"에 있는 알고리즘 이름의 순서와는 반대입니다.
B.2. Encrypt Plaintext to Create Ciphertext
위의 ENC_KEY를 사용하여 PKCS #7 패딩을 적용한 AES CBC 모드로
평문을 암호화합니다. 이 예제의 평문은:
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
암호화 결과는 다음과 같으며, 이는 암호문 출력입니다:
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
B.3. 64-Bit Big-Endian Representation of AAD Length
이 예제의 추가 인증 데이터(AAD)는 다음과 같습니다:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]
이 AAD는 51바이트이며, 이는 408비트입니다. AAD의 비트 수를 빅엔디안
64비트 부호 없는 정수로 표현한 옥텟 문자열 AL은 다음과 같습니다:
[0, 0, 0, 0, 0, 0, 1, 152]
B.4. Initialization Vector Value
이 예제에서 사용된 초기화 벡터 값은 다음과 같습니다:
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
Jones & Hildebrand Standards Track [Page 49]
RFC 7516 JSON Web Encryption (JWE) May 2015
B.5. Create Input to HMAC Computation
AAD, 초기화 벡터, 암호문, 및 AL 값을 연결합니다. 이 연결의 결과는:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111,
116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24,
152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215,
104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
B.6. Compute HMAC Value
위에서 연결한 값의 HMAC SHA-256을 계산합니다. 이 결과 M은:
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105,
86, 229, 116]
B.7. Truncate HMAC Value to Create Authentication Tag
HMAC 출력 M의 앞 절반(128비트)을 인증 태그 출력 T로 사용합니다. 이 잘린 값은:
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]
Acknowledgements
JSON 콘텐츠 암호화에 대한 솔루션은 "JSON Simple Encryption"
[JSE] 및 "JavaScript Message
Security Format" [JSMS]에서도 탐구되었으며, 이들 모두는 본 문서에 상당한 영향을 주었습니다. 이
문서는 가능한 한 XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] 및
RFC 5652 [RFC5652]의 관련 개념들을 명시적으로 재사용하려고 시도하면서,
단순하고 컴팩트한 JSON 기반 데이터 구조를 활용합니다.
이 사양의 내용을 형성하는 데 도움을 준 논의에 대해 John Bradley, Eric Rescorla,
Nat Sakimura에게 특별히 감사드립니다; 본 문서에서 [JSMS]의 텍스트 재사용을 허용해 준 Eric Rescorla와 Joe Hildebrand에게도 감사드립니다; 그리고 이 사양의 많은 초안을 공동 저술한 Eric Rescorla에게도 감사드립니다.
예제의 검증에 도움을 준 Axel Nennker, Emmanuel Raviart, Brian Campbell, 및 Edmund
Jay에게 감사드립니다.
Jones & Hildebrand Standards Track [Page 50]
RFC 7516 JSON Web Encryption (JWE) May 2015
이 사양은 JOSE 작업 그룹의 산물이며, 수십 명의 활동적이고 헌신적인 참가자를 포함합니다. 특히,
다음 개인들은 이 사양에 아이디어, 피드백 및 문구적 기여를 했습니다:
Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley,
Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger,
Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel
Nennker, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat
Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad 및 Karen O'Donoghue가 JOSE 작업 그룹을 의장했으며
Sean Turner, Stephen Farrell, 및 Kathleen Moriarty가 이 사양 작성 기간 동안
보안 영역 이사(Security Area Directors)로 봉사했습니다.
Authors' Addresses
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joe Hildebrand
Cisco Systems, Inc.
EMail: jhildebr@cisco.com
Jones & Hildebrand Standards Track [Page 51]