인터넷 엔지니어링 태스크 포스 (IETF)

M. Thomson

요청 의견(Request for Comments): 8188

Mozilla

분류: 표준 트랙

2017년 6월

ISSN: 2070-1721

HTTP용 암호화된 콘텐츠 인코딩

초록

이 메모는 메시지 페이로드를 암호화할 수 있게 해주는 HTTP용 콘텐츠 코딩을 소개합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이는 IETF 커뮤니티의 합의를 반영합니다. 이 문서는 공개 검토를 거쳤고 인터넷 엔지니어링 운영 그룹(IESG)에 의해 게재 승인을 받았습니다. 인터넷 표준에 대한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.

이 문서의 현재 상태, 정정 사항(errata), 및 피드백 제공 방법에 대한 정보는 http://www.rfc-editor.org/info/rfc8188에서 확인할 수 있습니다.

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.

1. 소개
- 1.1. 요구사항 언어
2. "aes128gcm" HTTP 콘텐츠 코딩
3. 예시
- 3.1. 응답의 암호화
- 3.2. 여러 레코드로 암호화
4. 보안 고려사항
- 4.1. 자동 복호화
- 4.2. 메시지 잘림
- 4.3. 키 및 논스 재사용
- 4.4. 데이터 암호화 한계
- 4.5. 콘텐츠 무결성
- 4.6. 헤더 필드에서 정보 유출
- 4.7. 저장소 오염
- 4.8. 크기 및 타이밍 공격
5. IANA 고려사항
- 5.1. "aes128gcm" HTTP 콘텐츠 코딩
6. 참고 문헌
- 6.1. 규범 참조
- 6.2. 참고자료
부록 A. JWE 맵핑
감사의 말
저자 연락처

1. 소개

HTTP 메시지(요청 또는 응답)의 내용을 암호화하여 페이로드가 저장될 때(예: HTTP PUT) 적절한 키를 가진 사람만 내용을 읽을 수 있도록 하는 것이 때때로 바람직합니다.

예를 들어, 서버에 파일을 저장하되 그 서버에 파일 내용이 노출되지 않도록 해야 할 수 있습니다. 또한 동일한 파일을 다른 서버로 복제하거나(서버 또는 네트워크 장애에 더 강하도록), 클라이언트가 다운로드하여 오프라인으로 이용할 수 있게 하는 등 내용이 노출되지 않으면서 다양한 방식으로 처리될 수 있습니다.

이러한 용도는 전송 계층 보안(TLS) [RFC5246] 의 사용으로 충족되지 않습니다. TLS는 클라이언트와 서버 사이의 채널만 암호화하기 때문입니다.

이 문서는 이러한 및 기타 사용 사례를 위해 HTTP용 콘텐츠 코딩(참조 Section 3.1.2 of [RFC7231]) 을 지정합니다.

이 콘텐츠 코딩은 메시지 기반 암호화 포맷(예: [RFC4880], [RFC5652], [RFC7516], 및 [XMLENC]에 설명된 포맷) 을 직접적으로 변환한 것은 아닙니다. 이러한 포맷은 스트림 처리에 적합하지 않으며, HTTP에 필요합니다. 여기서 설명하는 포맷은 [RFC5116] 에 설명된 더 낮은 수준의 구성요소에 더 가깝게 따릅니다.

메시지 기반 암호화 포맷이 동일한 기본 원시(primitives)를 사용할 경우, 이 포맷은 특정 프로필을 가진 암호화된 메시지들의 연속으로 간주될 수 있습니다. 예를 들어, 부록 A는 이 포맷이 고정 헤더를 가진 연속적인 JSON Web Encryption [RFC7516] 값들과 어떻게 일치하는지 설명합니다.

이 메커니즘은 콘텐츠 암호화를 사용하는 더 큰 설계의 일부일 가능성이 큽니다. 클라이언트와 서버가 키를 획득하고 식별하는 방법은 사용 사례에 따라 달라집니다. 특히, 키 관리 시스템은 이 문서에 설명되어 있지 않습니다.

1.1. 요구사항 언어

이 문서에서 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 BCP 14 [RFC2119] 및 [RFC8174] 에서 설명된 대로, 그리고 오직 모두 대문자로 나타날 때에만 해석되어야 합니다.

2. "aes128gcm" HTTP 콘텐츠 코딩

"aes128gcm" HTTP 콘텐츠 코딩은 페이로드가 AEAD_AES_128_GCM으로 식별되는 Galois/Counter Mode(GCM)의 Advanced Encryption Standard(AES)를 사용하여 암호화되었음을 나타냅니다([RFC5116], Section 5.1). AEAD_AES_128_GCM 알고리즘은 128비트 콘텐츠 암호화 키를 사용합니다.

이 콘텐츠 코딩을 사용하려면 키에 대한 지식이 필요합니다. 이 키를 획득하는 방법은 이 문서에 정의되어 있지 않습니다.

"aes128gcm" 콘텐츠 코딩은 고정된 암호화 원시 집합을 사용합니다. 암호 알고리즘 민첩성(cipher agility)은 새로운 콘텐츠-코딩 스킴을 정의함으로써 달성됩니다. 이는 암호화 사용을 협상하기 위해 HTTP Accept-Encoding 헤더 필드만 필요함을 보장합니다.

"aes128gcm" 콘텐츠 코딩은 고정 레코드 크기를 사용합니다. 최종 인코딩은 헤더(섹션 2.1 참조)와 0개 이상의 고정 크기 암호화된 레코드로 구성되며; 마지막 레코드는 레코드 크기보다 작을 수 있습니다.

레코드 크기는 암호화되는 각 평문 부분의 길이를 결정합니다. 레코드 크기("rs")는 콘텐츠-코딩 헤더에 포함됩니다(섹션 2.1 참조).

+-----------+             content
|   data    |             any length up to rs-17 octets
+-----------+
     |
     v
+-----------+-----+       add a delimiter octet (0x01 or 0x02)
|   data    | pad |       then 0x00-valued octets to rs-16
+-----------+-----+       (or less on the last record)
         |
         v
+--------------------+    encrypt with AEAD_AES_128_GCM;
|    ciphertext      |    final size is rs;
+--------------------+    the last record can be smaller

AEAD_AES_128_GCM은 입력 평문보다 16옥텟 더 긴 암호문을 생성합니다. 따라서 각 레코드의 비암호화된 내용은 레코드 크기보다 16옥텟 짧습니다. 유효한 레코드는 항상 최소한의 패딩 구분자 옥텟과 16옥텟 인증 태그를 포함합니다.

각 레코드는 단일 패딩 구분자 옥텟과 그 뒤를 따르는 임의 개수의 0 옥텟을 포함합니다. 마지막 레코드는 패딩 구분자 옥텟 값이 2로 설정되며, 그 외의 모든 레코드는 패딩 구분자 값이 1입니다.

복호화 시 패딩 구분자는 레코드의 마지막 0이 아닌 옥텟입니다. 레코드에 0이 아닌 옥텟이 없으면 복호화자는 실패해야 합니다. 마지막 레코드가 값이 2가 아닌 패딩 구분자를 포함하거나 마지막이 아닌 레코드가 값이 1이 아닌 패딩 구분자를 포함하면 복호화자는 실패해야 합니다.

각 레코드의 논스는 레코드 시퀀스 번호와 입력-키링 재료(input-keying material)로부터 구성된 96비트 값입니다. 논스 유도는 섹션 2.3에서 다룹니다.

AEAD_AES_128_GCM에 전달되는 추가 데이터(additional data)는 길이 0의 옥텟 시퀀스입니다.

이 레코드 구조의 결과로 범위 요청([RFC7233]) 및 암호화된 페이로드 바디에 대한 임의 접근이 레코드 크기 단위로 가능해집니다. 범위의 끝에 있는 부분 레코드는 복호화할 수 없습니다. 따라서 범위 요청은 레코드 경계에서 시작하고 끝나는 것이 가장 좋습니다. 그러나 패딩의 존재는 암호화된 데이터의 특정 부분에 대한 임의 접근을 혼란시킬 수 있습니다.

적합한 레코드 크기를 선택하는 것은 트레이드오프가 필요합니다. 작은 레코드 크기는 평문 옥텟을 더 빨리 해제(해독 후 이용 가능하게)할 수 있어 응답성이 중요한 애플리케이션에 적합할 수 있습니다. 작은 레코드는 또한 암호문 내부의 임의 접근이 필요할 때 필요한 추가 데이터를 줄여줍니다.

스트리밍, 임의 접근 또는 임의 패딩에 의존하지 않는 애플리케이션은 더 큰 레코드 또는 단일 레코드를 사용할 수 있습니다. 더 큰 레코드 크기는 처리 및 데이터 오버헤드를 줄입니다.

2.1. 암호화 콘텐츠-코딩 헤더

콘텐츠 코딩은 콘텐츠를 복호화하는 데 필요한 모든 매개변수(키 제외)를 포함하는 헤더 블록을 사용합니다. 헤더 블록은 레코드 시퀀스 앞에 메시지 본문에 배치됩니다.

+-----------+--------+-----------+---------------+
| salt (16) | rs (4) | idlen (1) | keyid (idlen) |
+-----------+--------+-----------+---------------+

salt:: "salt" 매개변수는 "aes128gcm" 콘텐츠-코딩 헤더의 첫 16옥텟으로 구성됩니다. 동일한 입력-키링 재료를 가진 두 개의 서로 다른 페이로드 바디에 대해 동일한 "salt" 매개변수 값을 재사용해서는 안 됩니다; 콘텐츠 코딩을 적용할 때마다 랜덤한 salt를 생성하면 콘텐츠-암호화 키 재사용 가능성이 매우 낮아집니다.
rs:: "rs" 또는 레코드 크기 매개변수는 네트워크 바이트 오더의 부호 없는 32비트 정수로, 옥텟 단위의 레코드 크기를 설명합니다. 따라서 AEAD_AES_128_GCM의 평문 입력에 대한 2^36-31 제한을 초과할 수 없습니다. 값이 18보다 작은 것은 무효입니다.
idlen:: "idlen" 매개변수는 "keyid" 매개변수의 길이를 정의하는 부호 없는 8비트 정수입니다.
keyid:: "keyid" 매개변수는 사용되는 키링 재료를 식별하는 데 사용될 수 있습니다. 이 필드는 "idlen" 매개변수로 결정된 길이입니다. 메시지를 수신한 수신자는 키를 검색하는 방법을 알고 있어야 하며; "keyid" 매개변수는 그 과정의 입력이 될 수 있습니다. "keyid" 매개변수는 특히 식별자가 텍스트 형태로 렌더링되어야 할 수 있는 경우 UTF-8 인코딩된 [RFC3629] 문자열인 것이 권장됩니다.

2.2. 콘텐츠 암호화 키 유도

여러 다른 HTTP 메시지에 대해 키링 재료를 재사용할 수 있도록, 각 메시지에 대해 콘텐츠 암호화 키가 유도됩니다. 콘텐츠 암호화 키는 "salt" 매개변수로부터 HMAC 기반 키 유도 함수(HKDF, [RFC5869]) 를 사용하여 SHA-256 해시 알고리즘([FIPS180-4])로 유도됩니다.

"salt" 매개변수의 값은 HKDF에 대한 salt 입력입니다. "keyid" 매개변수가 식별하는 키링 재료는 HKDF의 입력-키링 재료(IKM)입니다. 입력-키링 재료는 수신자에게 별도로 제공되는 것으로 기대됩니다. 따라서 HKDF의 추출 단계는 다음과 같이 의사무작위 키(PRK)를 생성합니다:

   PRK = HMAC-SHA-256 (salt, IKM)

HKDF의 info 매개변수는 ASCII로 인코딩된 문자열 "Content-Encoding: aes128gcm"과 단일 0 옥텟으로 설정됩니다:

   cek_info = "Content-Encoding: aes128gcm" || 0x00

Note(1):: 옥텟 시퀀스의 연결은 || 연산자로 표시됩니다.
Note(2):: 여기 및 섹션 2.3에서 사용되는 문자열은 일부 프로그래밍 언어에서 사용하는 종결 0x00 옥텟을 포함하지 않습니다.

AEAD_AES_128_GCM은 16옥텟(128비트) 콘텐츠 암호화 키(CEK)를 요구하므로, HKDF에 대한 길이(L) 매개변수는 16입니다. 따라서 HKDF의 두 번째 단계는 단일 HMAC의 처음 16옥텟으로 단순화될 수 있습니다:

   CEK = HMAC-SHA-256(PRK, cek_info || 0x01)

2.3. 논스 유도

AEAD_AES_128_GCM에 대한 논스 입력은 각 레코드에 대해 구성됩니다. 각 레코드의 논스는 레코드 시퀀스 번호, 입력-키링 재료, 및 "salt" 매개변수로부터 유도된 12옥텟(96비트) 값입니다.

입력-키링 재료와 "salt" 매개변수는 서로 다른 info 및 길이(L) 매개변수로 HKDF에 입력됩니다.

길이(L) 매개변수는 12옥텟입니다. 논스에 대한 info 매개변수는 ASCII로 인코딩된 문자열 "Content-Encoding: nonce"이며 단일 0 옥텟으로 종결됩니다:

   nonce_info = "Content-Encoding: nonce" || 0x00

그 결과는 레코드 시퀀스 번호와 배타적 논리합(XOR)으로 결합되어 논스를 생성합니다. 레코드 시퀀스 번호(SEQ)는 네트워크 바이트 오더의 96비트 부호 없는 정수이며 0에서 시작합니다.

따라서 각 레코드의 최종 논스는 12옥텟 값입니다:

   NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01) XOR SEQ

이 논스 구성은 레코드의 제거 또는 재정렬을 방지합니다.

3. 예시

이 섹션에서는 암호화된 콘텐츠 코딩의 몇 가지 예를 보여줍니다.

참고: 이 섹션의 예제에 나오는 모든 이진 값은 URL 및 파일 이름에 안전한 알파벳을 사용하는 base64 인코딩(base64url)을 사용합니다([RFC4648]). 요청 본문도 포함됩니다. 형식 제약을 맞추기 위해 공백과 줄 바꿈이 추가되어 있습니다.

3.1. 응답의 암호화

여기서는 성공적인 HTTP GET 응답이 암호화된 예를 보여줍니다. 이 예는 4096옥텟의 레코드 크기를 사용하며 패딩은 없고(단일 옥텟 패딩 구분자만 있음) 따라서 부분 레코드만 존재합니다. 입력-키링 재료는 빈 문자열로 식별됩니다(헤더의 "keyid" 필드 길이가 0임).

이 예제에서 암호화된 데이터는 UTF-8로 인코딩된 문자열 "I am the walrus"입니다. 입력-키링 재료는 값 "yqdlZ-tYemfogSmv7Ws5PQ"(base64url)입니다. 54옥텟 콘텐츠 본문은 단일 레코드를 포함하며 프레젠테이션을 위해 여기서는 71개의 base64url 문자로 표시됩니다.

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 54
Content-Encoding: aes128gcm

I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
ly8Thjg

메디어 타입이 콘텐츠에 대한 정보를 노출하지 않기 위해 "application/octet-stream"으로 변경되었음을 주의하세요. 대안으로(동등하게), Content-Type 헤더 필드를 생략할 수도 있습니다.

이 예제의 중간 값(모두 base64url로 표시):

salt (from header) = I1BsxtFttlv3u_Oo94xnmw
PRK = zyeH5phsIsgUyd4oiSEIy35x-gIi4aM7y0hCF8mwn9g
CEK = _wniytB-ofscZDh4tbSjHw
NONCE = Bcs8gkIRKLI8GeI8
unencrypted data = SSBhbSB0aGUgd2FscnVzAg

3.2. 여러 레코드로 암호화

이 예제는 입력-키링 재료가 "BO3ZVPxUlnLORbVGMpbT1Q"인 동일한 메시지를 보여줍니다. 이 예에서 평문은 각 25옥텟의 레코드로 분할됩니다(즉, 헤더의 "rs" 필드는 25임). 첫 번째 레코드는 하나의 0x00 패딩 옥텟을 포함합니다. 이는 첫 번째 레코드에 7옥텟의 메시지가 있고 두 번째에는 8옥텟이 있음을 의미합니다. 헤더에는 UTF-8 인코딩된 문자열 "a1"의 키 식별자도 포함됩니다.

HTTP/1.1 200 OK
Content-Length: 73
Content-Encoding: aes128gcm

uNCkWiNYzKTnBN9ji3-qWAAAABkCYTHOG8chz_gnvgOqdGYovxyjuqRyJFjEDyoF
1Fvkj6hQPdPHI51OEUKEpgz3SsLWIqS_uA

4. 보안 고려사항

이 메커니즘은 유효한 송신자와 수신자 간의 키 배포를 관리하는 키 관리 프레임워크의 존재를 전제로 합니다. 키 관리를 정의하는 것은 이 메커니즘을 더 큰 애플리케이션, 프로토콜 또는 프레임워크에 구성하는 부분입니다.

암호화 구현, 특히 키 관리는 어렵습니다. 예를 들어, 구현체는 특정 연산을 수행하는 데 걸리는 시간에 의해 노출될 수 있는 사이드 채널에서 키링 재료가 노출될 가능성을 고려해야 합니다. 암호 알고리즘의 좋은 구현에 대한 요구사항은 시간이 지남에 따라 변할 수 있습니다.

4.1. 자동 복호화

콘텐츠 코딩으로서 "aes128gcm" 콘텐츠 코딩은 수신자에 의해 자동으로 제거되어 최종 소비자에게 명확하지 않게 될 수 있습니다. 이 메커니즘을 사용한 콘텐츠-출처 인증에 의존하는 수신자는 "aes128gcm" 콘텐츠 코딩이 포함되지 않은 메시지를 거부해야 합니다.

4.2. 메시지 잘림

이 콘텐츠 인코딩은 큰 메시지의 점진적 처리를 허용하도록 설계되었습니다. 또한 제한적인 방식으로 평문에 대한 임의 접근을 허용합니다. 이 콘텐츠 인코딩은 수신자가 메시지가 잘렸을 때 이를 감지할 수 있게 합니다.

부분적으로 전달된 메시지는 전체 메시지가 성공적으로 전달된 것처럼 처리되어서는 안 됩니다. 예를 들어, 부분적으로 전달된 메시리를 완전한 것처럼 캐시해서는 안 됩니다.

공격자는 부분 메시지를 처리하려는 경향을 악용하여 수신자가 특정 중간 상태에 머물게 할 수 있습니다. 부분 메시지에 대해 처리를 수행하는 구현체는 모든 중간 처리 상태가 공격자에게 유리하게 작용하지 않도록 해야 합니다.

4.3. 키 및 논스 재사용

동일한 콘텐츠-암호화 키와 논스를 사용하여 다른 평문을 AES-GCM으로 암호화하는 것은 안전하지 않습니다([RFC5116]). 여기서 정의된 스킴은 고정된 논스 진행을 사용합니다. 따라서 콘텐츠 코딩을 적용할 때마다 새로운 콘텐츠-암호화 키가 필요합니다. 입력-키링 재료는 재사용될 수 있으므로, 콘텐츠-암호화 키가 재사용되지 않도록 고유한 "salt" 매개변수가 필요합니다.

만약 콘텐츠-암호화 키가 재사용된다면 — 즉 입력-키링 재료와 "salt" 매개변수가 재사용된다면 — 이는 평문과 인증 키를 노출시켜 암호화가 제공하는 보호를 무효화할 수 있습니다. 따라서 동일한 입력-키링 재료가 재사용되는 경우에는 매번 "salt" 매개변수가 고유해야 합니다. 구현체는 메시지마다 랜덤한 "salt" 매개변수를 생성하는 것이 권장됩니다.

4.4. 데이터 암호화 한계

AEAD_AES_128_GCM이 암호화할 수 있는 데이터에는 한계가 있습니다. 레코드 크기의 최대값은 헤더의 "rs" 필드 크기에 의해 제한되며(섹션 2.1 참조), 이는 단일 AEAD_AES_128_GCM 적용에 대한 2^36-31 제한을 초과하지 않도록 보장합니다([RFC5116]). 선택 평문 공격(IND-CPA)에 대해 2^-40의 구별 불가능 확률을 보존하기 위해 동일한 입력-키링 재료와 salt에서 유도된 키로 암호화할 수 있는 평문의 총량은 2^44.5 블록(각 16옥텟)보다 작아야 합니다([AEBounds]).

레코드 크기가 16옥텟의 배수인 경우, 패딩 및 오버헤드를 포함하여 안전하게 암호화할 수 있는 양은 398테라바이트입니다. 그러나 레코드 크기가 16옥텟의 배수가 아닌 경우, 부분 AES 블록이 암호화되기 때문에 안전하게 암호화할 수 있는 전체 데이터 양은 줄어듭니다. 최악의 경우는 레코드 크기가 18옥텟인 경우로, 이 경우 최대 74테라바이트의 평문을 암호화할 수 있으며 그 중 최소 절반은 패딩입니다.

4.5. 콘텐츠 무결성

이 메커니즘은 콘텐츠-출처 인증만 제공합니다. 인증 태그는 콘텐츠-암호화 키에 접근할 수 있는 엔티티가 암호화된 데이터를 생성했음을 보장합니다.

따라서 콘텐츠-암호화 키를 가진 어떤 엔티티도 유효한 것으로 수용될 콘텐츠를 생성할 수 있습니다. 이는 동일한 HTTP 메시지의 모든 수신자를 포함합니다.

더욱이 Content-Encoding 헤더 필드와 HTTP 메시지 본문을 모두 수정할 수 있는 엔티티는 내용을 교체할 수 있습니다. 콘텐츠-암호화 키나 입력-키링 재료 없이는 페이로드 본문의 일부를 수정하거나 교체하는 것이 불가능합니다.

4.6. 헤더 필드에서 정보 유출

페이로드 본문만 암호화되므로 헤더 필드에 노출된 정보는 메시지를 읽을 수 있는 누구에게나 보입니다. 이는 사이드 채널 정보를 노출할 수 있습니다.

예를 들어 Content-Type 헤더 필드는 페이로드 본문에 관한 정보를 유출할 수 있습니다.

애플리케이션의 위협 모델과 사용자가 감수할 수 있는 정보 유출 허용도에 따라 이 위협을 완화할 수 있는 여러 전략이 있습니다:

문제가 되지 않는다고 판단합니다. 예를 들어 저장되는 모든 콘텐츠가 "application/json"과 같거나 다른 매우 일반적인 미디어 타입일 것으로 예상된다면 Content-Type 헤더 필드를 노출하는 것이 허용 가능한 위험일 수 있습니다.
민감한 정보로 간주되고 다른 수단(예: 대역 외, 다른 표현의 힌트 등)을 통해 이를 결정할 수 있다면, 관련 헤더를 생략하거나 정규화하십시오. Content-Type의 경우에는 항상 Content-Type: application/octet-stream(가장 일반적인 미디어 타입)을 보내거나 Content-Type 자체를 전혀 보내지 않는 방식으로 이를 달성할 수 있습니다.
민감한 정보로 간주되고 이를 다른 곳에서 전달할 수 없다면, 애플리케이션/http 미디어 타입을 사용하여 HTTP 메시지를 캡슐화(부록 참조: Section 8.3.2 of [RFC7230]) 하고 이를 "외부" 메시지의 페이로드로 암호화하십시오.

4.7. 저장소 오염

이 메커니즘은 데이터-출처 인증만 제공하며, 메시지 생성자의 인증 또는 권한 부여를 수행하지는 않습니다. 이는 여전히 수행되어야 할 수 있습니다(예: HTTP 인증 [RFC7235]).

이는 특히 서버가 페이로드를 복호화하지 않고 HTTP PUT 요청을 수락하는 경우에 관련성이 큽니다. 요청이 인증되지 않은 경우 제3자가 서비스 거부를 하거나 저장소를 오염시킬 수 있습니다.

4.8. 크기 및 타이밍 공격

이 메커니즘을 사용하는 애플리케이션은 암호화된 메시지의 크기뿐만 아니라 전송 시점, HTTP 메서드, URI 등이 민감한 정보를 유출할 수 있다는 점을 인식해야 합니다. 예를 들어 [NETFLIX] 또는 [CLINIC] 를 참조하세요.

이 위험은 이 메커니즘이 제공하는 패딩을 통해 완화할 수 있습니다. 또는 콘텐츠를 세그먼트로 나누어 별도로 저장하면 노출을 줄일 수 있습니다. HTTP/2([RFC7540])와 TLS([RFC5246]) 를 결합하면 개별 메시지의 크기를 숨기는 데 사용될 수 있습니다.

패딩 전략을 개발하는 것은 어렵습니다. 좋은 패딩 전략은 문맥에 따라 달라질 수 있습니다. 일반적인 전략으로는 소수의 고정 길이로 패딩하기, 값의 배수로 패딩하기, 2의 거듭제곱으로 패딩하기 등이 있습니다. 심지어 좋은 전략도 수신자의 처리 활동을 관찰할 수 있다면 크기 정보가 유출될 수 있습니다. 특히 메시지의 후속 레코드가 패딩만 포함하는 경우가 그러합니다. 크기 정보 유출을 피하기 위해 비패딩 데이터를 레코드에 분산시키는 것이 권장됩니다.

5. IANA 고려사항

5.1. "aes128gcm" HTTP 콘텐츠 코딩

이 메모는 "HTTP 콘텐츠 코딩 레지스트리"에 "aes128gcm" HTTP 콘텐츠 코딩을 등록합니다. 자세한 내용은 섹션 2를 참조하십시오.

Name: aes128gcm
Description: 128비트 콘텐츠-암호화 키를 사용하는 AES-GCM 암호화
Reference: 이 명세서

6. 참고 문헌

6.1. 규범 참조

[FIPS180-4]: National Institute of Standards and Technology, “Secure Hash Standard (SHS)”, FIPS PUB 180-4, DOI 10.6028/NIST.FIPS180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.
[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://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, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5116]: McGrew, D., “An Interface and Algorithms for Authenticated Encryption”, RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869]: Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC7230]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC8174]: Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2. 참고자료

[AEBounds]: Luykx, A. and K. Paterson, “Limits on Authenticated Encryption Use in TLS”, March 2016, <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[CLINIC]: Miller, B., Huang, L., Joseph, A., and J. Tygar, “I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis”, DOI 10.1007/978-3-319-08506-7_8, March 2014, <https://arxiv.org/abs/1403.0297>.
[NETFLIX]: Reed, A. and M. Kranch, “Identifying HTTPS-Protected Netflix Videos in Real-Time”, Proceedings of the Seventh ACM on Conference on Data and Application Security and Privacy CODASPY '17, DOI 10.1145/3029806.3029821, 2017.
[RFC4648]: Josefsson, S., “The Base16, Base32, and Base64 Data Encodings”, RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4880]: Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format”, RFC 4880, DOI 10.17487/RFC4880, November 2007, <https://www.rfc-editor.org/info/rfc4880>.
[RFC5246]: Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5652]: Housley, R., “Cryptographic Message Syntax (CMS)”, STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC7233]: Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7235]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7516]: Jones, M. and J. Hildebrand, “JSON Web Encryption (JWE)”, RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7540]: Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[XMLENC]: Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, “XML Encryption Syntax and Processing Version 1.1”, World Wide Web Consortium Recommendation REC-xmlenc-core1-20130411, April 2013, <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411>.

부록 A. JWE 맵핑

"aes128gcm" 콘텐츠 코딩은 각각 후행 패딩을 포함하는 단일 고정 크기 레코드에 해당하는 JSON Web Encryption(JWE) [RFC7516] 객체들의 연속으로 간주될 수 있습니다. JWE Compact Serialization을 사용하여 표현될 수 있는 JWE 객체에 다음 변환이 적용됩니다:

JWE Protected Header는 { "alg": "dir", "enc": "A128GCM" }으로 고정되어 있으며, 128비트 콘텐츠-암호화 키를 사용하는 AES-GCM을 이용한 직접 암호화를 설명합니다. 이 헤더는 전송되지 않고 Content-Encoding 헤더 필드 값에 의해 암시됩니다.
JWE Encrypted Key는 직접 암호화 알고리즘에 따라 비어 있습니다.
각 레코드의 JWE Initialization Vector("iv")는 0에서 시작하는 96비트 레코드 시퀀스 번호와 입력-키링 재료로부터 유도된 값의 배타적 논리합으로 설정됩니다(섹션 2.3 참조). 이 값도 전송되지 않습니다.
최종 값은 헤더, JWE 암호문, 그리고 JWE 인증 태그를 이어붙인 것이며, 모두 base64url 인코딩 없이 표현됩니다. 필드 길이가 알려져 있으므로 "." 구분자는 생략됩니다.

따라서 섹션 3.1의 예는 JWE Compact Serialization을 사용하여 다음과 같이 렌더링할 수 있습니다:

eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..Bcs8gkIRKLI8GeI8.
-NAVub2qFgBEuQKRapoZuw.4jGQi9rcwQHU8P6XLxOGOA

첫 번째 줄은 고정된 JWE Protected Header, 빈 JWE Encrypted Key, 그리고 알고리즘적으로 결정된 JWE Initialization Vector를 나타냅니다. 두 번째 줄은 인코딩된 본문을 JWE 암호문과 JWE 인증 태그로 나누어 포함합니다.

감사의 말

Mark Nottingham은 이 문서의 초창기 저자였습니다.

다음 사람들은 귀중한 의견을 제공했습니다: Richard Barnes, David Benjamin, Peter Beverloo, JR Conlin, Mike Jones, Stephen Farrell, Adam Langley, James Manger, John Mattsson, Julian Reschke, Eric Rescorla, Jim Schaad, 및 Magnus Westerlund.

저자 연락처

Martin Thomson
Mozilla
EMail: martin.thomson@gmail.com