해시는 입력의 digest를 계산해 변경 여부를 비교할 수 있지만, 해시값 자체가 공개되어 있다면 변경한 사람도 새 해시를 계산할 수 있습니다. MAC은 비밀키를 가진 참여자만 올바른 인증값을 계산할 수 있게 설계되어, 키를 모르는 사람이 메시지를 바꿨는지 확인하는 데 쓰입니다.
HMAC은 공유 비밀키를 사용하는 MAC입니다. 송신자와 검증자가 같은 키를 가진 구조이므로 검증자가 외부 제삼자에게 공개적으로 증명하는 전자서명이나 부인방지와 같지 않습니다.
둘 다 바뀐 메시지를 찾을 수 있지만 조건이 다릅니다
해시 함수는 임의 길이 메시지에서 고정 길이 digest를 계산합니다. 원본과 전달된 파일을 각각 해시해 값이 다르면 파일 내용이 달라졌다고 알 수 있습니다. 그러나 체크섬을 파일과 함께 공개된 위치에 둔다면, 공격자가 파일과 체크섬을 함께 바꾸어 공개할 수 있습니다. 해시는 ‘이 데이터에서 어떤 digest가 나왔나’를 말하지만, 공개 해시 하나만으로 ‘누가 이 파일을 만들었나’를 인증하지 않습니다.
| 검증 방식 | 필요한 입력 | 검증 결과로 말할 수 있는 것 | 단독으로 말할 수 없는 것 |
|---|---|---|---|
| SHA-256 체크섬 | 파일과 공개된 기대 digest | 파일이 알려진 digest와 일치하는지 | digest를 게시한 사람이 정당한지 |
| HMAC-SHA-256 | 파일과 사전에 안전하게 공유한 비밀키 | 키를 모르는 제삼자의 변조를 검출할 수 있는지 | 어느 공유 키 보유자가 만들었는지 또는 외부인이 검증 가능한지 |
| 전자서명 | 서명된 데이터와 공개 검증키 | 정책에 맞게 서명이 검증되는지 | 키 소유자와 실제 행위자·의사가 항상 같다는 결론 |
RFC 2104는 HMAC을 해시 함수와 공유 비밀키를 결합하는 메시지 인증 방식으로 정의합니다. HMAC의 강도는 기반 해시 함수의 성질에도 의존합니다. SHA-256은 FIPS 180-4에 정의된 해시 함수 중 하나입니다. 역할을 정확히 말하려면 ‘해시가 무결성을 제공한다’처럼 한 단어로 뭉뚱그리지 말고, 해시값을 누가 어떤 경로로 신뢰하게 됐는지, MAC 키를 누가 보유했는지 덧붙여야 합니다.
두 파일 검증을 직접 비교합니다
가상 배포 서버가 설치파일과 SHA-256 값을 같은 웹 페이지에 공개한다고 합시다. 게시물을 바꾸는 사람이 파일 내용을 바꾸고 새 SHA-256도 계산하면 이용자는 수정된 파일과 새 값이 일치하는 것을 볼 수 있습니다. 이 비교는 전송 뒤 우연한 손상이나 잘못된 파일을 찾는 데 쓸 수 있지만, 게시 주체의 신원을 증명하지 않습니다.
이번에는 배포 담당자와 검증 시스템만 아는 HMAC 키 K를 별도 안전 경로로 공유했다고 가정합니다. 담당자는 HMAC(K, 파일)을 전달하고 시스템은 가진 K로 같은 값을 확인합니다. K가 없는 사람이 파일만 수정하면 인증값 검증에 실패합니다. 하지만 담당자와 검증 시스템은 같은 비밀을 공유하므로 둘 다 유효한 인증값을 만들 수 있습니다. 그 결과를 제삼자가 공개 검증해 어느 쪽이 생성했는지 판별할 수 있는 구조는 아닙니다.
답안에 보장을 정확히 쓰는 순서
- 해시 계산에 비밀키가 들어가는지 확인합니다.
- 검증자가 그 키를 가지고 있는지, 외부에 공개되는 키인지 표시합니다.
- 누가 검증값을 만들 수 있는지 당사자 목록을 씁니다.
- 변경 탐지·키 보유자 확인·제삼자 검증을 각각 따로 결론 냅니다.
자주 하는 실수는 공개 해시와 MAC을 모두 ‘인증 코드’라고 부르거나, HMAC 검증이 성공하면 문서 작성자를 한 사람으로 특정할 수 있다고 말하는 것입니다. 같은 HMAC 키를 받은 여러 참여자는 모두 유효한 값을 만들 수 있습니다. 공개 해시를 안전한 서명된 목록, 검증된 배포 채널과 함께 쓸 수도 있지만, 그때 신뢰는 해시 알고리즘만이 아니라 목록의 인증 경로에도 달려 있습니다. 반대로 키 없는 단순 해시가 아무 쓸모가 없다는 뜻도 아닙니다. 저장·전송 중 우발 오류 검사나 다른 신뢰된 채널의 값과 대조할 때는 유용하지만, 출처 인증 주장에는 별도 근거가 필요합니다.
검증 주체를 가려 보고 답합니다
교육용 회상 문제입니다. 게시판에 파일과 SHA-256 digest가 함께 공개되어 있습니다. 공격자가 새 파일과 그에 맞는 digest를 둘 다 올려 바꿨다면, 수신자의 공개 해시 비교만으로 발신자를 인증할 수 있나요? 같은 파일에 사전에 공유한 비밀키로 만든 HMAC 태그가 있고 키가 안전하게 유지됐다면 무엇이 달라지나요?
공개 해시만 비교해서는 발신자를 인증할 수 없습니다. 파일과 공개 digest를 함께 바꿀 수 있기 때문입니다. 공유 비밀키를 모르는 공격자는 적합한 HMAC 태그를 만들기 어렵지만, 키를 가진 참여자는 생성과 검증을 모두 할 수 있습니다. 따라서 HMAC은 키 없는 공개 해시보다 키 보유자 집단에 대한 변조 확인을 제공하며, 특정 한 사람이 만들었다는 제3자 증명이나 부인방지를 제공하지 않습니다. 이 예시는 파일과 공개 digest를 함께 바꾸는 경우를 구별하도록 새로 만든 것입니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
공격자가 게시판의 파일과 공개 SHA-256 digest를 함께 바꾸면 수신자의 비교는 발신자를 인증하는가? 공유 비밀키 HMAC은 키 없는 공격자에 대해 무엇을 추가하는가?
정답과 해설 확인
아닙니다. 공개 digest는 파일과 함께 교체될 수 있으므로 발신자를 인증하지 않습니다. 비밀키가 유지되면 키를 모르는 공격자는 올바른 HMAC 태그를 만들기 어렵지만, 키를 가진 참여자들은 모두 태그를 만들 수 있습니다.공개 해시는 데이터와 digest가 일치하는지만 보여 주며 digest 게시자를 인증하지 않습니다. RFC 2104의 HMAC은 공유 비밀키를 사용하므로 키 보유자 집단과 키 없는 공격자를 구별할 수 있지만, 한 키 보유자가 만든 사실을 제3자에게 증명하는 전자서명은 아닙니다.