암호화는 내용을 읽기 어렵게 만드는 기밀성 목표를 제공할 수 있지만, 암호화라는 말만으로 변경 탐지까지 보장하지는 않습니다. 변경을 검증하려면 MAC이나 인증 암호화(AEAD) 같은 인증 수단의 조건을 확인해야 합니다.
TLS 1.3 레코드는 AEAD를 사용해 암호화와 인증을 함께 처리합니다. 이 설명은 TLS 1.3의 레코드 보호 범위이며, 모든 암호 방식에 일반화할 수 없습니다.
읽을 수 없음과 바뀌지 않았음은 다른 주장입니다
암호화된 데이터가 외부인에게 읽히지 않는다는 주장은 기밀성에 관한 것입니다. 데이터가 전송 중 바뀌지 않았거나, 바뀌면 알아챌 수 있다는 주장은 무결성·인증에 관한 별도 조건을 요구합니다. 암호화 알고리즘, 모드, nonce·IV 사용 방식, 인증 태그나 MAC의 존재를 모르면 ‘암호화되어 있으니 안전하다’고 결론 내릴 수 없습니다. NIST SP 800-57은 암호 키와 암호 서비스의 관리 맥락을 안내하고, 어떤 서비스가 제공되는지는 실제 알고리즘과 프로토콜 선택에 달려 있다고 봐야 합니다.
| 구성 | 주로 답하는 질문 | 확인할 조건 |
|---|---|---|
| 암호화만 명시된 구성 | 내용을 제삼자가 읽기 어려운가? | 암호 방식·키·모드와 올바른 사용 조건 |
| MAC 추가 | 메시지가 공유 키 없는 자에 의해 바뀌었는가? | 키 분배, 태그 검증, 메시지와 맥락의 결합 |
| AEAD | 암호화된 본문과 인증 대상이 검증되는가? | 키, 고유 nonce, 추가 인증 데이터, 태그 검증 |
| TLS 1.3 레코드 | 정해진 TLS 레코드 처리가 적용되는가? | AEAD 검증 성공 여부와 레코드 순서·키 상태 |
여기서 ‘무결성’은 데이터가 어떤 기대 기준과 비교해 정확한지에 관한 속성입니다. AEAD 태그가 확인되면 해당 키와 nonce, 인증 대상 아래에서 변경·위조를 검출할 수 있지만, 그 자체가 사용자 신원을 증명하거나 데이터가 처음부터 진실이었다고 보증하지는 않습니다. 암호화는 데이터가 처음 생성될 때의 오류를 고치지 않으며, 권한 있는 키 보유자가 만든 잘못된 메시지도 정상적으로 인증될 수 있습니다.
TLS 1.3 레코드에서 실제 인증 범위를 읽습니다
RFC 8446은 TLS 1.3의 TLSCiphertext에 AEAD 암호문이 들어가며, AEAD 복호·검증 결과가 평문 또는 오류라고 설명합니다. 레코드 본문은 암호화되고 인증됩니다. 레코드 헤더 일부는 추가 인증 데이터(AAD)로 입력되어 인증되지만 암호화되지는 않습니다. 즉, 수신자는 해당 헤더가 인증 과정에서 바뀌지 않았는지 확인할 수 있지만, 네트워크 관찰자에게 헤더가 숨겨진다고 말하면 틀립니다.
| 필드 | 길이 |
|---|---|
| opaque_type | 1바이트 |
| legacy_record_version | 2바이트 |
| length | 2바이트 |
| AAD로 결합되는 헤더 합계 | 1+2+2=5바이트, 즉 40비트 |
이 계산은 헤더 세 필드의 길이를 더한 결과입니다. RFC 8446에서 AEAD 입력에는 키, nonce, 평문, additional data가 들어가고 TLS 레코드 헤더가 additional data로 사용됩니다. 복호화와 인증이 실패하면 프로토콜은 해당 레코드 오류로 연결을 종료해야 합니다. 같은 쓰기 키를 유지하는 동안 레코드 순번으로 nonce를 만들고 반복하지 않아야 하며, 순번이 한계에 도달하기 전에 키를 바꾸거나 연결을 종료하는 규칙도 따릅니다. 이는 RFC 8446이 정한 레코드 규칙이며, 모든 AEAD API가 nonce를 자동 관리한다는 뜻은 아닙니다.
문제에서 보장 범위를 확인하는 순서
- 기밀성만 묻는지, 변경 검출도 묻는지 표시합니다.
- 암호화에 MAC 또는 AEAD 인증이 결합됐는지 확인합니다.
- 키·nonce·인증 태그의 생성과 검증 조건을 확인합니다.
- 인증된 메타데이터와 암호화된 본문을 구분합니다.
- 프로토콜 검증 성공과 실제 사용자·데이터의 진실성을 별개로 씁니다.
흔한 실수는 암호문을 사람이 읽을 수 없다는 관찰만으로 변조 방지까지 추론하는 것입니다. 반대 실수는 태그만 확인되면 메시지 내용을 승인해도 된다고 생각하는 것입니다. 운영에서는 표준 프로토콜과 검증된 라이브러리를 사용하고, 실패한 태그나 복호 결과를 무시한 채 애플리케이션에 전달하지 않아야 합니다. 이 글은 암호문 조작 절차나 특정 모드 구현을 안내하지 않습니다. TLS 1.3 설명은 RFC 8446이 정한 레코드 범위에만 한정합니다.
본문과 헤더 중 무엇이 숨고 무엇이 인증되는지 답합니다
교육용 회상 문제입니다. TLS 1.3 레코드에서 AEAD 검증이 성공했고 AAD에는 opaque_type, legacy_record_version, length가 들어갔습니다. 이 세 필드는 암호화되는가요? 그렇지 않다면 검증 과정에서 어떤 보호를 받나요?
세 필드는 이 AEAD 인증 데이터로 포함되지만 그 자체가 암호화된 본문은 아닙니다. 따라서 내용을 감추는 기밀성은 적용되지 않지만, 태그 확인은 해당 AAD가 인증 과정에서 변경되지 않았는지 검증합니다. 프로토콜의 구체 규칙을 모든 암호화 방식의 일반 규칙으로 확대하지 마세요. 이 문항은 설명을 위해 새로 만든 예시입니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
TLS 1.3 레코드의 AAD에 포함된 헤더 필드는 본문처럼 암호화되는가, 아니면 인증되는가?
정답과 해설 확인
인증되지만 암호화되지는 않습니다.RFC 8446에서 레코드 헤더는 AEAD additional data로 들어가 인증에 포함되며, TLSCiphertext의 encrypted_record 본문과 보호 방식이 다릅니다.