인터넷 엔지니어링 태스크포스 (IETF) M. Thomson
의견 요청서: 8291 Mozilla
분류: 표준 트랙 2017년 11월
ISSN: 2070-1721
Web Push를 위한 메시지 암호화
초록
이 문서는 Web Push 프로토콜을 위한 메시지 암호화 방식을 설명한다.
이 방식은 애플리케이션 서버에서 사용자 에이전트로 전송되는
메시지에 대해 기밀성과 무결성을 제공한다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 인터넷 엔지니어링 태스크포스(IETF)의 산출물이다. 이는
IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 거쳤으며,
인터넷 엔지니어링 운영 그룹(IESG)에 의해 출판 승인을 받았다.
인터넷 표준에 대한 추가 정보는 RFC 7841의 Section 2에서
확인할 수 있다.
이 문서의 현재 상태, 모든 정오표, 그리고 이에 대한 피드백 제공
방법에 관한 정보는 다음에서 얻을 수 있다.
https://www.rfc-editor.org/info/rfc8291.
Copyright Notice
Copyright (c) 2017 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
(https://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.
Thomson 표준 트랙 [Page 1]
RFC 8291 Web Push 암호화 2017년 11월
목차
1. 소개 ...........................................................2
1.1. 표기 규칙 .................................................3
2. Push 메시지 암호화 개요 .......................................3
2.1. 키 및 비밀 값 배포 .......................................4
3. Push 메시지 암호화 ............................................4
3.1. Diffie-Hellman 키 합의 ...................................5
3.2. Push 메시지 인증 .........................................5
3.3. 공유 비밀 값과 인증 비밀 값의 결합 ......................5
3.4. 암호화 요약 ..............................................6
4. "aes128gcm" 콘텐츠 코딩 사용 제한 .............................7
5. Push 메시지 암호화 예제 .......................................8
6. IANA 고려 사항 ................................................8
7. 보안 고려 사항 ................................................8
8. 참고 문헌 .....................................................10
8.1. 규범 참고 문헌 ..........................................10
8.2. 정보 참고 문헌 ..........................................11
부록 A. 암호화를 위한 중간 값 .................................12
저자 주소 .......................................................13
1. 소개
Web Push 프로토콜 [RFC8030]은 필연적으로 중개되는 프로토콜이다.
애플리케이션 서버의 메시지는 Figure 1에 표시된 것처럼 push
서비스를 통해 사용자 에이전트(UA)로 전달된다.
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ +-------------+
| | |
| Setup | |
|<====================>| |
| Provide Subscription |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
Figure 1
이 문서는 이 프로토콜을 사용하여 전송되는 메시지가 push 서비스에
의한 검사, 수정 및 위조로부터 어떻게 보호될 수 있는지를 설명한다.
Thomson 표준 트랙 [Page 2]
RFC 8291 Web Push 암호화 2017년 11월
Web Push 메시지는 HTTP 메시지 [RFC7230]의 페이로드이다.
이러한 메시지는 암호화된 콘텐츠 인코딩 [RFC8188]을 사용하여
암호화된다. 이 문서는 이 콘텐츠 인코딩이 적용되는 방법을
설명하고, 권장되는 키 관리 방식을 설명한다.
동일한 사용자 에이전트에서 Web Push를 사용하는 여러 사용자는
종종 push 기능을 집계하는 중앙 에이전트를 공유한다. 이 에이전트는
push 메시징을 사용하는 애플리케이션이 이 암호화 방식을 사용하도록
강제할 수 있다. 올바르게 암호화된 메시지만 전달하는 에이전트는
메시지의 종단 간 보호를 강하게 장려한다.
Push API [API]를 구현하는 웹 브라우저는 올바르게 암호화된
메시지만 전달함으로써 암호화 사용을 강제할 수 있다.
1.1. 표기 규칙
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", "OPTIONAL"은 여기에 표시된 것처럼
모두 대문자로 나타날 때에만 BCP
14 [RFC2119] [RFC8174]에 설명된 대로 해석된다.
이 문서는 [RFC8030]의 용어, 주로 "user agent",
"push service", "application server"를 사용한다.
2. Push 메시지 암호화 개요
push 메시지 암호화는 공유 비밀 값(Section 3.1 참조)과
인증용 대칭 비밀 값(Section 3.2 참조)을 설정하기 위해
P-256 곡선 [FIPS186]에서 Elliptic Curve Diffie-Hellman(ECDH)
[ECDH]을 사용한다.
사용자 에이전트는 생성하는 각 subscription과 연결되는 ECDH 키 쌍과
인증 비밀 값을 생성한다. ECDH 공개 키와 인증 비밀 값은 push
subscription의 다른 세부 정보와 함께 애플리케이션 서버로 전송된다.
메시지를 보낼 때 애플리케이션 서버는 ECDH 키 쌍과 임의의 salt를
생성한다. ECDH 공개 키는 암호화된 콘텐츠 코딩 헤더의 "keyid"
매개변수에 인코딩되고, salt는 같은 헤더의 "salt" 매개변수에
인코딩된다([[RFC8188]의 Section 2.1] 참조). ECDH 키 쌍은
메시지를 암호화한 후 폐기할 수 있다.
Thomson 표준 트랙 [Page 3]
RFC 8291 Web Push 암호화 2017년 11월
push 메시지의 내용은 콘텐츠 암호화 키와 nonce를 사용하여
암호화되거나 복호화된다. 이러한 값은 Section 3에 설명된
프로세스에 "keyid"와 "salt"를 입력으로 사용하여 파생된다.
2.1. 키 및 비밀 값 배포
subscription을 사용하는 애플리케이션은 subscription 공개 키와 인증
비밀 값을 승인된 애플리케이션 서버에 배포한다. 이는 push
subscription URI와 같이 사용자 에이전트가 제공하는 다른
subscription 정보와 함께 전송될 수 있다.
애플리케이션은 이 목적을 위해 인증되고 기밀성이 보호되는 통신
매체를 반드시 사용해야 한다. [RFC8030]에 설명된 이유에 더해,
이 사용은 인증 비밀 값이 권한 없는 엔터티에 노출되지 않도록
보장한다. 그렇지 않으면 해당 엔터티는 사용자 에이전트가 수락할
push 메시지를 생성할 수 있다.
push 메시징을 사용하는 대부분의 애플리케이션은 subscription 데이터
배포에 사용할 수 있는 애플리케이션 서버와의 기존 관계를 가진다.
HTTPS [RFC2818]와 같이 충분한 기밀성 및 무결성 보호를 제공하는
인증된 통신 메커니즘이면 충분하다.
3. Push 메시지 암호화
Push 메시지 암호화는 네 단계로 수행된다.
o ECDH [ECDH]를 사용하여 공유 비밀 값을 파생한다(이 문서의
Section 3.1 참조).
o 그런 다음 공유 비밀 값은 인증 비밀 값과 결합되어 [RFC8188]에서
사용되는 입력 키 자료(IKM)를 생성한다(이 문서의 Section 3.3
참조).
o [RFC8188]의 프로세스를 사용하여 콘텐츠 암호화 키와 nonce를
파생한다.
o [RFC8188]에 따라 암호화 또는 복호화를 수행한다.
키 파생 프로세스는 Section 3.4에 요약되어 있다.
암호화된 콘텐츠 코딩 사용에 대한 제한은 Section 4에 설명되어
있다.
Thomson 표준 트랙 [Page 4]
RFC 8291 Web Push 암호화 2017년 11월
3.1. Diffie-Hellman 키 합의
사용자 에이전트가 애플리케이션에 대해 생성하는 각각의 새
subscription에 대해, 사용자 에이전트는 ECDH [ECDH]에서 사용할
P-256 [FIPS186] 키 쌍도 생성한다.
push 메시지를 보낼 때 애플리케이션 서버도 동일한 P-256 곡선에서
새 ECDH 키 쌍을 생성한다.
애플리케이션 서버의 ECDH 공개 키는 암호화된 콘텐츠 코딩 헤더의
"keyid" 매개변수로 포함된다([[RFC8188]의 Section 2.1] 참조).
애플리케이션 서버는 [ECDH]에 설명된 프로세스를 사용하여 자신의
ECDH 개인 키를 사용자 에이전트가 제공한 공개 키와 결합한다.
push 메시지를 수신하면 사용자 에이전트는 자신의 개인 키를
"keyid" 매개변수의 애플리케이션 서버가 제공한 공개 키와 같은
방식으로 결합한다. 이러한 연산은 ECDH 공유 비밀 값에 대해
동일한 값을 생성한다.
3.2. Push 메시지 인증
push 메시지가 올바르게 인증되도록 보장하기 위해, 대칭 인증 비밀
값이 사용자 에이전트가 생성한 정보에 추가된다. 인증 비밀 값은
Section 3.3에 설명된 키 파생 프로세스에 혼합된다.
사용자 에이전트는 push 메시지 인증에 사용되는 추측하기 어려운
16 octet의 시퀀스를 반드시 생성하여 제공해야 한다. 이는
암호학적으로 강한 난수 생성기 [RFC4086]로 생성하는 것이 좋다.
3.3. 공유 비밀 값과 인증 비밀 값의 결합
ECDH에 의해 생성된 공유 비밀 값은 HMAC 기반 키 파생 함수(HKDF)
[RFC5869]를 사용하여 인증 비밀 값과 결합된다. 이는 [RFC8188]에서
사용되는 입력 키 자료를 생성한다.
HKDF 함수는 SHA-256 해시 알고리즘 [FIPS180-4]을 다음 입력과
함께 사용한다.
salt: 인증 비밀 값
IKM: ECDH를 사용하여 파생된 공유 비밀 값
Thomson 표준 트랙 [Page 5]
RFC 8291 Web Push 암호화 2017년 11월
info: ASCII로 인코딩된 문자열 "WebPush: info"(이 문자열은 NUL로
종료되지 않음), zero octet, 사용자 에이전트 ECDH 공개 키,
그리고 애플리케이션 서버 ECDH 공개 키의 연결(두 ECDH 공개
키는 모두 [X9.62]에 정의된 비압축 포인트 형식임). 즉:
key_info = "WebPush: info" || 0x00 || ua_public || as_public
L: 32 octet(즉, 출력은 기반 SHA-256 HMAC 함수 출력의 길이)
3.4. 암호화 요약
그 결과 최종 콘텐츠 암호화 키와 nonce가 다음 순서를 사용하여
생성된다. 여기서는 HKDF를 SHA-256 기반 HMAC을 사용하는 별개의
단계로 확장한 의사 코드로 표시한다.
-- 사용자 에이전트의 경우:
ecdh_secret = ECDH(ua_private, as_public)
auth_secret = random(16)
salt = <from content coding header>
-- 애플리케이션 서버의 경우:
ecdh_secret = ECDH(as_private, ua_public)
auth_secret = <from user agent>
salt = random(16)
-- 양쪽 모두:
## ECDH와 인증 비밀 값을 결합하기 위해 HKDF 사용
# HKDF-Extract(salt=auth_secret, IKM=ecdh_secret)
PRK_key = HMAC-SHA-256(auth_secret, ecdh_secret)
# HKDF-Expand(PRK_key, key_info, L_key=32)
key_info = "WebPush: info" || 0x00 || ua_public || as_public
IKM = HMAC-SHA-256(PRK_key, key_info || 0x01)
## RFC 8188의 HKDF 계산
# HKDF-Extract(salt, IKM)
PRK = HMAC-SHA-256(salt, IKM)
# HKDF-Expand(PRK, cek_info, L_cek=16)
cek_info = "Content-Encoding: aes128gcm" || 0x00
CEK = HMAC-SHA-256(PRK, cek_info || 0x01)[0..15]
# HKDF-Expand(PRK, nonce_info, L_nonce=12)
nonce_info = "Content-Encoding: nonce" || 0x00
NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01)[0..11]
Thomson 표준 트랙 [Page 6]
RFC 8291 Web Push 암호화 2017년 11월
push 메시지는 단일 레코드만 포함하고(Section 4 참조), 첫 번째
레코드의 시퀀스 번호는 zero이므로, 여기서는 최종 nonce와 레코드
시퀀스 번호의 exclusive-OR를 생략한다는 점에 유의한다.
4. "aes128gcm" 콘텐츠 코딩 사용 제한
애플리케이션 서버는 push 메시지를 단일 레코드로 반드시
암호화해야 한다. 이를 통해 단일 레코드를 처리하는 최소 수신자
구현이 가능하다. 애플리케이션 서버는 "aes128gcm" 콘텐츠 코딩
헤더의 "rs" 매개변수를 plaintext, padding delimiter(1 octet),
모든 padding 및 인증 태그(16 octet)의 길이 합보다 큰 크기로
반드시 설정해야 한다.
push 메시지는 암호화된 콘텐츠 코딩 헤더의 "keyid" 매개변수에
애플리케이션 서버 ECDH 공개 키를 반드시 포함해야 한다. [X9.62]에
정의된 비압축 포인트 형식(즉, 0x04 octet으로 시작하는 65-octet
시퀀스)이 "keyid" 전체를 이룬다. 이는 "keyid" 매개변수가
[RFC8188]에서 권장하는 것처럼 유효한 UTF-8이 아님을 의미한다는
점에 유의한다.
push 서비스는 payload body를 4096 octet보다 많이 지원할 필요가
없다([[RFC8030]의 Section 7.2] 참조). 헤더(86 octet), padding
(최소 1 octet), 그리고 AEAD_AES_128_GCM에 대한 확장(16 octet)을
제외하면, 이는 최대 3993 octet의 plaintext에 해당한다.
애플리케이션 서버는 push 메시지에 대해 다른 콘텐츠 인코딩을
사용해서는 안 된다. 특히 압축을 수행하는 콘텐츠 인코딩은 push
메시지 내용의 유출을 초래할 수 있다. 따라서 Content-Encoding
헤더 필드는 정확히 하나의 값, 즉 "aes128gcm"만 가진다. 여러
"aes128gcm" 값은 허용되지 않는다.
사용자 에이전트는 여러 레코드를 지원할 필요가 없다. 사용자
에이전트는 "rs" 매개변수를 무시할 수 있다. 레코드 크기를
검사하지 않으면, 모든 유효한 경우에 대해 복호화가 높은 확률로
실패한다. padding delimiter octet은 반드시 검사해야 하며, 0x02가
아닌 값은 메시지가 폐기되도록 해야 한다.
Thomson 표준 트랙 [Page 7]
RFC 8291 Web Push 암호화 2017년 11월
5. Push 메시지 암호화 예제
다음 예제는 push 서비스로 전송되는 push 메시지를 보여준다.
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 10
Content-Length: 145
Content-Encoding: aes128gcm
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml
mlMoZIIgDll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A_yl95bQpu6cVPT
pK4Mqgkf1CXztLVBSt2Ks3oZwbuwXPXLWyouBWLVWGNWQexSgSxsj_Qulcy4a-fN
이 예제는 ASCII로 인코딩된 문자열 "When I grow up, I want
to be a watermelon"을 보여준다. 콘텐츠 본문은 표시 제약 조건을
충족하기 위해 line wrapping과 URL-safe base64url [RFC4648] 인코딩을
사용하여 여기에 표시된다.
사용된 키는 아래에 base64url로 인코딩된 비압축 형식 [X9.62]으로
표시되어 있다.
Authentication Secret: BTBZMqHH6r4Tts7J_aSIgg
Receiver:
private key: q1dXpw3UpT5VOmu_cf_v6ih07Aems3njxI-JWgLcM94
public key: BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-JvLexhqUzORcx
aOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4
Sender:
private key: yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw
public key: BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg
Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8
이 예제의 중간 값은 Appendix A에 포함되어 있다.
6. IANA 고려 사항
이 문서는 IANA 조치를 요구하지 않는다.
7. 보안 고려 사항
[RFC8030]의 개인정보 및 보안 고려 사항은 모두 이 메커니즘의
사용에도 적용된다.
[RFC8188]의 Security Considerations 섹션은 콘텐츠 인코딩의 한계를
설명한다. 특히 콘텐츠 인코딩 방식으로 보호되는 HTTP 헤더 필드는
없다. 사용자 에이전트는 HTTP 헤더 필드가 push 서비스에서 온
것으로 반드시 간주해야 한다.
Thomson 표준 트랙 [Page 8]
RFC 8291 Web Push 암호화 2017년 11월
헤더 필드는 HTTP 응답을 올바르게 처리하는 데 필요할 수 있지만,
프로토콜의 올바른 동작에는 필요하지 않다. 헤더 필드의 정보를
사용하여 push 메시지 처리를 변경하는 사용자 에이전트의
애플리케이션은 push 서비스에 의한 공격 위험에 노출된다.
통신의 timing과 length는 push 서비스로부터 숨길 수 없다. 외부
관찰자는 개별 메시지가 서로 섞여 있는 것을 볼 수 있지만, push
서비스는 어떤 애플리케이션 서버가 어떤 사용자 에이전트와
통신하는지, 그리고 사용되는 subscription을 볼 수 있다. 또한
콘텐츠 인코딩 방식이 제공하는 padding을 사용하여 길이를 숨기지
않는 한 메시지 길이가 드러날 수 있다.
사용자 에이전트와 애플리케이션은 수신한 공개 키가 P-256 곡선
위에 있는지 반드시 검증해야 한다. 공개 키 검증에 실패하면
공격자가 개인 키를 추출할 수 있다. 적절한 검증 절차는 [X9.62]의
Section 4.3.7 및 대안적으로 [KEYAGREEMENT]의 Section 5.6.2.3에
정의되어 있다. 이 프로세스는 세 단계로 구성된다.
1. Y가 무한원점(O)이 아님을 확인한다.
2. Y = (x, y)에 대해 두 정수가 모두 올바른 구간에 있음을
확인한다.
3. (x, y)가 타원 곡선 방정식의 올바른 해임을 보장한다.
이러한 곡선의 경우, 구현자는 올바른 부분군에 속하는지를 검증할
필요가 없다.
이 암호화 방식을 교체해야 하는 경우, 새로운 콘텐츠 코딩 방식을
정의할 수 있다. 새로운 방식의 점진적 배포를 관리하기 위해
사용자 에이전트는 자신이 지원하는 콘텐츠 코딩 방식에 대한 정보를
노출할 수 있다. Push API [API]의 "supportedContentEncodings" 매개변수는
이를 수행하는 방법의 한 예이다.
Thomson 표준 트랙 [Page 9]
RFC 8291 Web Push 암호화 2017년 11월
8. 참고 문헌
8.1. 규범 참고 문헌
[ECDH] SECG, "SEC 1: Elliptic Curve Cryptography", Version 2.0,
2009년 5월, <http://www.secg.org/>.
[FIPS180-4]
National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, 2015년 8월.
[FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, 2013년 7월.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, 2005년 6월,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, 2010년 5월,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, 2016년 12월,
<https://www.rfc-editor.org/info/rfc8030>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2017년 5월, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8188] Thomson, M., "Encrypted Content-Encoding for HTTP",
RFC 8188, DOI 10.17487/RFC8188, 2017년 6월,
<https://www.rfc-editor.org/info/rfc8188>.
[X9.62] ANSI, "Public Key Cryptography for the Financial Services
Industry: the Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 2005.
Thomson 표준 트랙 [Page 10]
RFC 8291 Web Push 암호화 2017년 11월
8.2. 정보 참고 문헌
[API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", 2017년 10월,
<https://www.w3.org/TR/push-api/>.
[KEYAGREEMENT]
Barker, E., Chen, L., Roginsky, A., and M. Smid,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, Revision 2,
DOI 10.6028/NIST.SP.800-56Ar2, 2013년 5월.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, 2000년 5월,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, 2006년 10월,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, 2014년 6월,
<https://www.rfc-editor.org/info/rfc7230>.
Thomson 표준 트랙 [Page 11]
RFC 8291 Web Push 암호화 2017년 11월
부록 A. 암호화를 위한 중간 값
Section 5의 예제에 대해 계산된 중간 값이 여기에 표시되어 있다.
이 예제의 base64url 값에는 제거할 수 있는 whitespace가 포함되어
있다.
다음은 계산의 입력 값이다.
Plaintext: V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0byBiZSBhIHdhdGVybWVsb24
Application server public key (as_public):
BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg
Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8
Application server private key (as_private):
yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw
User agent public key (ua_public): BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-
JvLexhqUzORcx aOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4
User agent private key (ua_private):
q1dXpw3UpT5VOmu_cf_v6ih07Aems3njxI-JWgLcM94
Salt: DGv6ra1nlYgDCS1FRnbzlw
Authentication secret (auth_secret): BTBZMqHH6r4Tts7J_aSIgg
private key 중 하나만 알면 된다는 점에 유의한다. 애플리케이션
서버는 salt 값을 임의로 생성하는 반면, salt는 수신자에게는
입력 값이다.
이는 다음 중간 값을 생성한다.
Shared ECDH secret (ecdh_secret):
kyrL1jIIOHEzg3sM2ZWRHDRB62YACZhhSlknJ672kSs
Pseudorandom key (PRK) for key combining (PRK_key):
Snr3JMxaHVDXHWJn5wdC52WjpCtd2EIEGBykDcZW32k
Info for key combining (key_info): V2ViUHVzaDogaW5mbwAEJXGyvs3942BVG
q8e0PTNNmwR zr5VX4m8t7GGpTM5FzFo7OLr4BhZe9MEebhuPI-OztV3
ylkYfpJGmQ22ggCLDgT-M_SrDepxkU21WCP3O1SUj0Ew
bZIHMtu5pZpTKGSCIA5Zent7wmC6HCJ5mFgJkuk5cwAv MBKiiujwa7t45ewP
Input keying material for content encryption key derivation (IKM):
S4lYMb_L0FxCeq0WhDx813KgSYqU26kOyzWUdsXYyrg
Thomson 표준 트랙 [Page 12]
RFC 8291 Web Push 암호화 2017년 11월
PRK for content encryption (PRK):
09_eUZGrsvxChDCGRCdkLiDXrReGOEVeSCdCcPBSJSc
Info for content encryption key derivation (cek_info):
Q29udGVudC1FbmNvZGluZzogYWVzMTI4Z2NtAA
Content encryption key (CEK): oIhVW04MRdy2XN9CiKLxTg
Info for content encryption nonce derivation (nonce_info):
Q29udGVudC1FbmNvZGluZzogbm9uY2UA
Nonce (NONCE): 4h_95klXJ5E_qnoN
salt, record size 4096, 그리고 애플리케이션 서버 공개 키는 다음과
같은 86-octet 헤더를 생성한다.
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z 9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml
mlMoZIIgDll6e3vCYLocInmYWAmS6Tlz AC8wEqKK6PBru3jl7A8
push 메시지 plaintext에는 padding delimiter octet(0x02)이 추가되어
다음을 생성한다.
V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0 byBiZSBhIHdhdGVybWVsb24C
그런 다음 plaintext는 AES-GCM으로 암호화되며, 다음 ciphertext를
출력한다.
8pfeW0KbunFT06SuDKoJH9Ql87S1QUrd irN6GcG7sFz1y1sqLgVi1VhjVkHsUoEs
bI_0LpXMuGvnzQ
헤더와 ciphertext가 연결되어 Section 5에 표시된 결과를
생성한다.
저자 주소
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
Thomson 표준 트랙 [Page 13]