Notice
Recent Posts
Recent Comments
Link
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Tags
more
Archives
Today
Total
관리 메뉴

백엔드 개발 블로그

HMAC의 구조 및 필요성 본문

인증 & 보안

HMAC의 구조 및 필요성

베꺼 2022. 8. 31. 22:00
  • API 통신 등을 할 때, 보안 등의 이유로 통신되는 메시지의 위변조를 막아야 할 경우가 있다.
  • 이 때 어떠한 토큰을 사용하여 메시지가 위변조가 되지 않았는지 검증하는 기법이 주로 사용되는데, 이 때 사용되는 토큰을 MAC(Message Authentication Code)라고 한다.
  • 그 중 HMAC(Hash-based MAC)은 SHA256 등의 해시 함수 기반으로 안전하게 MAC을 생성하는 것을 이른다.
  • HTTPS, JWT 등 다양한 레벨의 보안 통신 프로토콜에서 사용된다.

단순히 해시함수만을 사용할 때의 취약점

  • 패스워드와 같이 원본 데이터는 알 수 없되 그 값의 동일성만 비교하는 경우, H(password || salt || secretKey)와 같이 암호화 후에 DB에 저장하는 것이 보편적이다. (이러한 방식은 패스워드를 탈취하기 위한 Rainbow table 공격을 효과적으로 방어할 수 있다.)
  • 하지만 HMAC으로 사용하기에는 위와 같은 한번의 해싱으로는 부족하다. 공격자가 원본 데이터의 값을 알고 있기 때문이다.
    • 먼저, H(secretKey || message)의 경우, 공격자가 비밀키를 몰라도, 원본데이터의 길이와 해시 함수만 안다면 원본 데이터에 악성 데이터를 append하는 동시에 유효한 MAC을 생성할 수 있다고 알려져 있다. 이를 Length extension 공격이라고 한다.
    • 반대로, H(message || secretKey)와 같이 비밀키를 뒤에 두어 append를 막는다고 하자. 공격자가 비밀키를 몰라도, 대부분의 해시 함수는 H(m1) = H(m2)라면 H(m1 || key) = H(m2 || key)를 만족하므로 MD5와 같은 약한 해시함수를 사용할 경우 해시함수 conflict를 이용한 공격에 이론적으로 취약해진다.
    • 심지어 H(k1 || message || k2) when k1 != k2 또한 취약점이 있다고 알려져 있다.
  • 따라서 해싱 함수가 다소 취약하더라도 복잡한 방법으로 해싱하여 보안성을 높인 것이 HMAC이다.

HMAC 생성 로직

ipad = 0x5c5c5c…5c5c
opad = 0x363636…3636
ikeypad = key XOR ipad
okeypad = key XOR opad
output = H(okeypad || H(ikeypad || message))
  • 위와 같이 두 번 해싱을 수행하면 안전하다고 한다.
  • ipad와 opad의 값은 ikeypad와 okeypad 사이의 hamming distance를 최대화하기 위한 것이라고 한다.

참고 자료

'인증 & 보안' 카테고리의 다른 글

JWT의 구조 및 사용 예  (0) 2022.09.12
Comments