103. HMAC (Hash-based Message Authentication Code)

⚠️ 이 문서는 데이터가 1비트도 조작되지 않았음을 보장하는 해시 함수에 '비밀키(Secret Key)'를 기묘하게 혼합하여, "이 문서는 안 깨진 게 맞고, 나아가 내가 신뢰하는 진짜 그 사람이 보낸 게 맞다"는 무결성과 인증(Authentication)을 한 방에 달성하는 HMAC 아키텍처를 다룹니다.

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

  1. 본질: HMAC은 단순히 데이터를 해시하는 것(무결성)을 넘어, 송신자와 수신자만 아는 비밀키(Key)를 평문과 특수한 수학적 방법(XOR 패딩 2번)으로 비벼서 해시 믹서기에 돌리는 메시지 인증 코드(MAC) 구조다.
  2. 가치: 해시 함수 자체는 열쇠가 없으므로 해커가 데이터를 고치고 새로운 해시를 떠서 덮어씌우면 속수무책이다. 하지만 HMAC은 해커가 '비밀키'를 모르면 애초에 올바른 인증 태그(Tag)를 계산해 낼 수 없으므로 중간자 조작(Tampering)을 완벽하게 차단한다.
  3. 융합: HMAC 자체는 암호화(기밀성 숨기기)를 수행하지 않으므로 데이터는 평문으로 날아간다. 따라서 실무에서는 AES(암호화)와 HMAC(인증)을 결합하거나, OAuth/JWT 토큰 서명 등 API 서버 간의 신원 증명에 가장 널리 융합되어 사용된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

단순한 해시 함수(SHA-256)의 치명적 맹점은 누구나 지문(Digest)을 뜰 수 있다는 점이다.

  • 해커의 공격 (단순 해시의 무력함): 내가 은행에 [송금액: 10만 원]과 이 데이터의 [SHA-256 해시값: ABC]를 보낸다. 해커가 중간에 가로채서 [송금액: 100억 원]으로 글씨를 고친다. 그리고 해커도 자기 컴퓨터에서 SHA-256 믹서기를 돌려 [새로운 해시값: XYZ]를 뽑아내어 은행에 보낸다. 은행은 해시값이 100억 원과 일치하므로 정상이라고 속아 넘어간다.

이를 막으려면 은행과 나만이 아는 **비밀번호(Key)**를 해시 믹서기 안에 같이 털어 넣어야 한다. 해커가 송금액을 100억으로 고치더라도 비밀번호를 모르기 때문에 은행 서버가 요구하는 완벽한 해시값을 만들어 낼 수 없다. 이렇게 "해시 함수에 비밀키를 버무리는 기술"이 바로 **MAC (메시지 인증 코드)**이며, 그중 해시 함수를 엔진으로 쓰는 가장 안전한 표준 구조가 HMAC이다.

📢 섹션 요약 비유: 단순 해시가 편지 봉투에 '도장'을 찍는 거라면(누구나 똑같은 도장을 파서 가짜 봉투에 찍을 수 있음), HMAC은 은행과 나만 아는 '마법의 왁스(비밀키)'를 녹여서 도장을 찍는 것입니다. 도둑이 편지를 뜯고 자기가 새로 도장을 찍어봤자 왁스의 성분이 달라서 바로 들통납니다.

Ⅱ. HMAC의 핵심 구조: 왜 그냥 비비지 않는가?

초보 개발자들은 "그럼 평문 데이터 끝에 비밀키 문자열을 이어 붙여서( Hash(Data + Key) ) 해시 돌리면 되는 거 아냐?"라고 생각한다. 하지만 이렇게 단순하게 붙이면 **길이 연장 공격 (Length Extension Attack)**이라는 해킹 수법에 5분 만에 털린다. 해커가 훔친 해시값의 꼬리에 자기의 악성 데이터를 슬쩍 이어 붙여서 수학적으로 완벽하게 통과되는 가짜 해시를 만들어내기 때문이다.

이 참사를 막기 위해 1996년 미히르 벨라레(Mihir Bellare) 등은 비밀키를 한 번이 아니라 안과 밖에서 두 번 샌드위치처럼 감싸서 해싱하는 구조를 창안했다. 이것이 HMAC의 본체다.

HMAC의 샌드위치 연산 공식

$HMAC(K, M) = H \Big( (K \oplus opad) \parallel H( (K \oplus ipad) \parallel M ) \Big)$

  1. 내부 해시 (속 감싸기): 비밀키($K$)를 ipad(안쪽 패딩 찌꺼기, 0x36)와 XOR로 섞어버린다. 그리고 그 결과물 뒤에 진짜 메시지($M$)를 이어 붙여서 해시 믹서기($H$)에 넣고 간다. $\rightarrow$ 결과물: 속 해시
  2. 외부 해시 (겉 감싸기): 이번엔 비밀키($K$)를 아까와 다른 opad(바깥 패딩 찌꺼기, 0x5C)와 XOR로 섞는다. 그리고 그 뒤에 방금 만든 '속 해시' 덩어리를 통째로 이어 붙여서 해시 믹서기에 한 번 더 넣고 간다. $\rightarrow$ 최종 결과물: HMAC 태그
┌────────────────────────────────────────────────────────────────────────────────┐
│           HMAC의 샌드위치 구조 (안쪽과 바깥쪽 이중 해시) 시각화                │
├────────────────────────────────────────────────────────────────────────────────┤
│                                                                                │
│ [ 1단계: 내부 속 채우기 ]                                                      │
│   ( 비밀키 ⊕ ipad )  +  [ 진짜 메시지 ] ──▶ [ 해시 함수(SHA) 윙윙 ]            │
│                                             │                                  │
│                                             ▼                                  │
│                                      [ 속 해시 덩어리 ]                        │
│                                                                                │
│ [ 2단계: 외부 껍질 한 번 더 감싸기 ]                                           │
│   ( 비밀키 ⊕ opad )  +  [ 속 해시 덩어리 ] ──▶ [ 해시 함수(SHA) 윙윙 ]         │
│                                             │                                  │
│                                             ▼                                  │
│                                   ★ [ 최종 HMAC 인증 태그 ] ★                  │
│                                                                                │
│ * 핵심: 믹서기를 두 번 돌리는 이 샌드위치 방식 때문에, 해커가 뒤에 뭔가        │
│   데이터를 더 붙이려(길이 연장 공격) 해도 바깥 껍질에 막혀 수학적으로 차단됨!  │
└────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 단순히 믹서기에 키를 같이 넣는다고 안전해지는 것이 아니다. 암호학은 해커의 온갖 꼼수(길이 연장 공격 등)를 막아내야 한다. HMAC 구조는 비밀키를 다르게 변형시킨 두 개의 껍질로 메시지를 철통같이 둘러쌈으로써, 안에 쓰인 해시 함수 엔진(SHA-2, MD5)이 약간의 취약점을 갖고 있더라도 전체 방어력은 완벽하게 유지되는 기적의 아키텍처를 이룩했다. (실제로 MD5는 단독으로 쓰면 박살 나지만, HMAC-MD5 구조 안에서는 아직도 안전하게 동작한다.)

  • 📢 섹션 요약 비유: 독이 묻은 바늘(해킹 공격)이 뚫고 들어오지 못하게, 고기를 방탄유리 상자(내부 해시)에 한 번 넣고 자물쇠를 채운 뒤, 그 상자를 다시 더 큰 강철 상자(외부 해시)에 넣고 또 자물쇠를 채우는 완벽한 이중 포장 시스템입니다.

Ⅲ. 실무 적용 시나리오: API 인증과 JWT

인터넷에 수백 대의 서버가 떠 있는 클라우드 시대에, 서버 A가 서버 B에게 "나 진짜 서버 A 맞으니까 내 데이터 좀 처리해 줘"라고 인증할 때 HMAC이 절대적으로 쓰인다.

  1. 클라우드 API 서명 (예: AWS S3 접근)
    • 개발자가 AWS에 데이터를 쏠 때, 전송하는 URL과 시간 정보(메시지)를 자신의 **AWS Secret Key(비밀키)**를 써서 HMAC-SHA256으로 서명(태그 생성)하여 같이 보낸다.
    • AWS 서버는 자기가 갖고 있는 비밀키로 똑같이 태그를 계산해 보고, 일치하면 "오! 우리 고객이 진짜 보낸 거 맞네!" 하고 통과시킨다.
  2. JSON Web Token (JWT)
    • 모바일 앱이 로그인한 후 받아오는 토큰(JWT)의 구조를 까보면, 제일 마지막 꼬다리(Signature)가 바로 이 HMAC으로 만든 도장이다.
    • 해커가 토큰 내용의 admin: false를 true로 고치려 해도, 서버의 비밀키를 모르기 때문에 HMAC 도장을 위조할 수 없어서 로그인에 100% 실패한다.

Ⅳ. 결론

"암호화가 비밀을 속삭이는 것이라면, HMAC은 광장에서 확성기로 소리치되 그 말이 진실임을 신(God)의 도장으로 증명하는 것이다." 데이터를 가리는 기밀성이 필요 없고 오직 **"이 데이터가 훼손되지 않았고, 진짜 그 사람이 보낸 게 확실하다"**는 사실 하나만 증명하고 싶을 때 HMAC은 세상에서 가장 빠르고 완벽한 해답이다. 대칭키 암호와 해시 함수의 수학적 장점만을 쏙 빼내어 융합한 HMAC은 오늘날 REST API, 결제 연동, IoT 기기 통신 등 모든 '시스템 간의 대화'를 지켜주는 무적의 신분증이다.

📌 관련 개념 맵

  • 상위 개념: MAC (Message Authentication Code, 메시지 인증 코드)
  • 내부 구성 부품: 암호학적 해시 함수 (SHA-256, BLAKE 등)
  • 제공하는 보안 속성: 무결성 (Integrity), 인증 (Authentication)
  • 실전 활용처: JWT (JSON Web Token), IPsec VPN 통신 인증, AWS API 서명

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

  1. 그냥 지문(해시)만 찍어 보내면, 나쁜 도둑도 자기 지문을 몰래 덮어찍어서 가짜 편지를 진짜인 척 보낼 수 있어요.
  2. HMAC은 지문을 찍을 때, 나랑 내 친구만 아는 '마법의 잉크(비밀키)'를 섞어서 두 번 꾹꾹 눌러 찍는 거예요.
  3. 도둑이 가짜 편지를 써도 이 마법의 잉크 색깔을 똑같이 만들어낼 수가 없어서, 내 친구는 한눈에 "이거 잉크 색깔이 가짜네!" 하고 도둑의 편지를 쓰레기통에 버릴 수 있답니다.