138. AEAD 암호화 강제 (TLS 1.3의 대학살)

⚠️ 이 문서는 과거 개발자들의 어설픈 조립(MAC-then-Encrypt)으로 인해 발생한 수많은 치명적 해킹 사태를 영구히 종결시키기 위해, 최신 보안 표준인 TLS 1.3이 기밀성(암호화)과 무결성(인증)이 하나의 칩으로 완벽하게 일체화된 AEAD 알고리즘 5개만을 남기고 과거의 모든 쓰레기 암호들을 법으로 강제 퇴출시킨 역사적 대청소 사건을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: TLS 1.3 스펙은 암호 통신을 맺을 때, 평문을 암호화하는 동시에 해커의 위변조를 막는 인증 태그(MAC)를 한 번의 수학적 연산으로 무결점 처리하는 AEAD(인증 및 연관 데이터 암호화) 모드만을 사용하도록 강제한다.
  2. 가치: CBC 블록 암호 모드나 구형 스트림 암호(RC4)를 썼을 때 터져 나왔던 악몽 같은 패딩 오라클 공격, Lucky13, POODLE 공격의 위협 표면(Attack Surface) 자체를 물리적으로 원천 소거해 버렸다.
  3. 융합: 선택의 폭을 줄인 것이 오히려 호환성과 보안성을 극대화했다. 현재 지구상의 모든 TLS 1.3 통신은 AES-GCM 이나 ChaCha20-Poly1305 라는 검증된 최정예 AEAD 용병들의 보호 아래 한 치의 오차 없이 강력하게 융합되어 돌아가고 있다.

Ⅰ. 개요 및 과거의 참상 (Context & Necessity)

2010년대 중반, 전 세계의 보안 담당자들은 아침마다 터져 나오는 새로운 해킹 논문 이름에 노이로제가 걸릴 지경이었다. BEAST, POODLE, Lucky13, CRIME... 이름은 화려하지만 본질은 하나였다. **"서버가 암호문을 해독할 때 생기는 에러 메시지의 차이나 시간 지연을 이용해, 비밀키 없이 평문을 벗겨먹는 부채널 공격 / 패딩 오라클 공격"**이었다.

왜 이런 일이 반복되었을까? 원흉은 TLS 1.2까지 허용되었던 **'블록 암호 CBC 모드'**와 **'MAC-then-Encrypt(인증 후 암호화)'**라는 조립식 설계의 치명적 결함 때문이었다. 개발자가 암호화와 무결성 검증을 수동으로 따로따로 조립하다 보니 자꾸 구멍이 났던 것이다.

그래서 IETF(국제 인터넷 표준화 기구)의 학자들은 TLS 1.3 규격을 새로 짜며 칼을 뽑았다. "개발자들을 믿지 마라. 자유도를 주지 마라. 암호화와 인증이 분리될 수 없는 일체형 다이아몬드 칩(AEAD) 외에는 전부 호환 명단에서 삭제해 버려라!"

📢 섹션 요약 비유: 옛날엔 사람들이 자전거 바퀴 따로, 브레이크 따로 사서 자기 맘대로 조립해서 타다가 자꾸 브레이크가 빠져서 절벽으로 떨어졌습니다(CBC 모드 한계). 빡친 법률 사무소(TLS 1.3)가 "앞으로 도로에는 공장에서 바퀴와 자동 제동 브레이크가 용접되어 절대 분해할 수 없게 일체형으로 나온 자동차(AEAD) 말고는 다 진입 금지!"라고 선포한 안전 대청소 사건입니다.

Ⅱ. 대학살의 현장: 퇴출당한 구시대의 유물들

TLS 1.3 규격 문서(RFC 8446)가 발표되면서 그동안 우리가 사랑했던, 혹은 어쩔 수 없이 썼던 암호학 교과서의 레전드들이 모조리 쓰레기통으로 직행했다.

❌ 무덤으로 들어간 것들 (Deprecated in TLS 1.3)

  1. 블록 암호 CBC 모드 전체: 패딩 오라클 공격의 영원한 먹잇감. AES-CBC, 3DES-CBC 모조리 짤렸다.
  2. 정적(Static) RSA 및 DH 키 교환: 해커가 나중에 키를 훔쳐 과거 데이터를 푸는 짓(전방 비밀성 부재) 때문에 모조리 짤렸다. 무조건 1회용인 DHE나 ECDHE만 살아남았다.
  3. RC4 (스트림 암호): 무선 랜(WEP) 시절부터 썼지만 수학적 편향성(초기 바이트가 평문을 유추하게 함) 때문에 짤렸다.
  4. MD5, SHA-1 (해시 함수): 구글 등에 의해 충돌 저항성이 깨졌으므로 당연히 무덤으로 갔다.

🛡️ 살아남은 5인의 최정예 용병 (허용된 AEAD Cipher Suites)

TLS 1.3에서 데이터를 암호화할 수 있는 유일하게 합법적인 무기는 단 5개뿐이다. 이것들은 모두 **"암호화를 뚫어보려 1비트라도 찌르면 펑 터져서 에러조차 뱉지 않고 닫혀버리는 AEAD 구조"**를 100% 충족한다.

  1. TLS_AES_128_GCM_SHA256 (★ 범용 1순위 제왕)
  2. TLS_AES_256_GCM_SHA384 (군사급 고강도)
  3. TLS_CHACHA20_POLY1305_SHA256 (★ 모바일/스마트폰 생태계의 패왕)
  4. TLS_AES_128_CCM_SHA256 (초경량 IoT용)
  5. TLS_AES_128_CCM_8_SHA256 (초경량 IoT용 특수 버전)
┌─────────────────────────────────────────────────────────────────────────────────────┐
│           TLS 1.2 vs TLS 1.3 암호 묶음(Cipher Suite)의 다이어트 시각화              │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│ 🗑️ [ TLS 1.2의 지저분한 암호 메뉴판 (수십 가지 조합) ]                              │
│  - TLS_RSA_WITH_AES_128_CBC_SHA  (위험: RSA 키교환 + CBC 모드)                      │
│  - TLS_ECDHE_RSA_WITH_RC4_128_SHA  (위험: RC4 암호 사용)                            │
│  - TLS_RSA_WITH_3DES_EDE_CBC_SHA  (위험: 3DES 사용, 무지하게 느림)                  │
│  -> 너무 많아서 개발자가 뭐 켤지 몰라 실수하면 바로 해킹당함!                       │
│                                                                                     │
│ 💎 [ TLS 1.3의 깔끔한 독재 (AEAD 5개 한정) ]                                        │
│  1. TLS_AES_128_GCM_SHA256      (컴퓨터/서버용 왕)                                  │
│  2. TLS_CHACHA20_POLY1305_SHA256 (핸드폰/모바일용 왕)                               │
│  3. (나머지 3개 생략)                                                               │
│  -> 개발자는 암호학 몰라도 돼! 저 5개 중에 암거나 써도 무조건 안전해! (Fool-proof)  │
└─────────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 그림에서 보듯 TLS 1.3의 Cipher Suite 이름표에는 앞부분에 덕지덕지 붙어있던 키 교환 방식(RSA/ECDHE) 이름이 싹 지워졌다. 어차피 1회용 키 교환(ECDHE/DHE)만 쓰도록 헌법으로 강제해 놨으니 메뉴판에 적을 필요조차 없어진 것이다. 이제 메뉴판에는 오직 100% 안전한 'AEAD 데이터 암호화 알고리즘 + 해시 함수' 딱 두 글자만 명확하게 남게 되었다.

  • 📢 섹션 요약 비유: 식당 메뉴판에 복어 요리를 "독 빼고 요리하기, 독 넣고 대충 요리하기, 내장만 요리하기" 등 수십 가지 옵션을 써놓고 손님에게 고르라고 했던 게 TLS 1.2입니다. 식중독(해킹) 사고가 끊이지 않자 1.3에서는 식약처가 출동해 싹 다 불태워버리고, "무기농 안심 샐러드 1, 2, 3번" 단 3개의 무공해 메뉴만 강제로 팔게 만든 완벽한 위생 조치입니다.

Ⅲ. 실무의 양대 산맥: AES-GCM vs ChaCha20-Poly1305

살아남은 5개 중에서도, 실무 서버 설정 파일에 박히는 알고리즘은 딱 두 개로 양분된다.

  1. AES-GCM의 제국 (인텔/AMD 서버 진영)
    • AES는 완벽하지만 수학이 너무 복잡해서 배터리를 많이 먹는다.
    • 하지만 서버 컴퓨터의 CPU(인텔, AMD) 안에는 아예 쇠를 깎아 만든 AES 전용 고속도로 칩셋(AES-NI 하드웨어 가속기)이 내장되어 있다. 이걸 쓰면 CPU 클럭을 거의 안 먹고 1초에 수기가를 갈아버린다. 따라서 PC 브라우저나 클라우드 서버는 100% 이걸 쓴다.
  2. ChaCha20-Poly1305의 반란 (스마트폰 진영)
    • 구글이 만든 모바일 전용 암호다. ChaCha20은 암호화를 하고, Poly1305는 인증(MAC)을 하는 완벽한 AEAD 콤비다.
    • 이유: 싸구려 안드로이드폰이나 라즈베리파이 같은 작은 기기에는 비싼 AES-NI 가속 칩이 없다! AES를 순수하게 코드(소프트웨어)로만 돌리면 폰이 미친 듯이 뜨거워진다.
    • 반면 ChaCha20은 오직 기본 덧셈, 엑스오어, 비트 회전 3가지만 쓰는 무식하고 단순한 스트림 암호라 소프트웨어로 돌려도 AES보다 3배 이상 빠르고 가볍다. 스마트폰 배터리를 구원한 모바일의 황태자다.

Ⅳ. 결론

"완벽함이란 더 이상 더할 것이 없을 때가 아니라, 뺄 것이 없을 때 이루어진다." TLS 1.3의 대숙청은 보안 업계에 뼈아픈 교훈을 남겼다. 해커에게 공격 표면(Attack Surface)을 주는 가장 큰 원인은 '너무 많은 선택지'였다. AEAD 강제 규정은 개발자의 자유를 뺏은 것이 아니라, 개발자가 보안 취약점을 만들 수 있는 권한 자체를 박탈하여 시스템을 원천적으로 보호하는 '안전한 독재'다. 오늘날 인터넷은 이 가혹한 다이어트 덕분에 1-RTT의 빛의 속도와 오라클 찌르기가 통하지 않는 다이아몬드 방패를 동시에 쥐게 되었다.

📌 관련 개념 맵

  • 전체 규격: TLS 1.3 (RFC 8446)
  • 강제 적용 대상: AEAD (Authenticated Encryption with Associated Data)
  • 제공하는 보안 속성: 기밀성 (Confidentiality) + 무결성/인증 (Integrity/Authentication) 동시 달성
  • 대표 알고리즘 투톱: AES-GCM (하드웨어 가속), ChaCha20-Poly1305 (소프트웨어/모바일 친화)

👶 어린이를 위한 3줄 비유 설명

  1. 옛날 인터넷(TLS 1.2)은 레고 블록 조립 세트였어요. 사람들이 바퀴랑 프로펠러를 맘대로 끼워 맞추다 보니 조립을 잘못해서 사고(해킹)가 매일 났죠.
  2. 그래서 안전 관리자(TLS 1.3) 화가 잔뜩 나서 낡은 레고 블록을 다 버리고, 공장에서 아예 용접해서 절대로 분해할 수 없고 고장도 안 나는 티타늄 자동차 장난감(AEAD) 5개만 딱 던져줬어요.
  3. 이제 사람들은 조립할 필요도 없이 그냥 티타늄 자동차(AES-GCM, ChaCha20) 중 맘에 드는 색깔 하나만 골라서 타기만 하면, 절대 사고가 나지 않는 안전한 인터넷 고속도로를 달릴 수 있게 되었답니다!