MAC은 보통 생성자와 검증자가 공유하는 비밀키를 사용합니다. 키를 가진 쪽은 태그를 만들 수도 있고 검증할 수도 있으므로, MAC 하나만으로 제3자에게 어느 쪽이 만들었는지 증명하기 어렵습니다.
전자서명은 개인키로 서명하고 대응하는 공개키로 검증합니다. 공개키를 가진 여러 사람이 검증할 수 있지만, 서명만으로 실제 사람이 키를 사용했다거나 법적 부인방지가 절대 보장된다고 결론 내릴 수는 없습니다.
둘 다 변조 탐지에 쓰일 수 있지만 키 관계가 다릅니다
메시지를 받은 사람이 내용이 바뀌었는지 확인해야 할 때 MAC과 전자서명을 모두 고려할 수 있습니다. 이 공통점만 외우면 두 방식이 같은 것처럼 보입니다. 차이를 가르는 질문은 ‘누가 검증 정보를 만들 수 있는가’입니다. RFC 2104의 HMAC은 비밀 공유키와 해시 함수를 사용해 메시지 인증값을 계산하고 검증합니다. NIST FIPS 186-5는 디지털 서명 알고리즘을 정하며, 전자서명에는 개인키와 그에 대응하는 공개키의 역할이 있습니다.
| 비교 항목 | HMAC 같은 MAC | 전자서명 |
|---|---|---|
| 생성할 때 쓰는 키 | 검증자와 공유하는 비밀키 | 서명자의 개인키 |
| 검증할 때 쓰는 값 | 같은 공유 비밀키 | 대응하는 공개키 |
| 검증 가능한 사람 | 그 비밀키를 가진 구성원 | 공개키를 가진 사람 |
| 검증자도 생성 가능한가 | 가능합니다 | 공개키만 가진 검증자는 서명을 만들 수 없습니다 |
세 조직이 기록을 확인하는 상황에 적용합니다
가상의 연구팀 A와 B가 서로 문서 전송을 확인한다고 합시다. 둘이 HMAC 비밀키 K를 공유하면 A는 문서 M과 K로 태그를 계산해 보내고, B도 같은 K로 태그를 다시 계산해 비교합니다. 내용이나 태그가 맞지 않으면 통과시키지 않습니다. 그런데 B도 K를 가진 이상 같은 문서와 같은 태그를 만들 수 있습니다. 따라서 B가 나중에 ‘이 태그는 A만 만들 수 있었다’고 제3자에게 보이기는 어렵습니다. MAC은 당사자끼리의 인증과 무결성 확인에는 쓸 수 있지만 생성자와 검증자를 키 소유만으로 분리하지 못합니다.
이번에는 A가 개인키 SK_A로 문서에 서명하고, 여러 감사자가 공개키 PK_A로 확인한다고 합시다. 공개키만 가진 감사자 C와 D는 서명을 검증할 수 있지만, 그 공개키만으로 A의 서명을 새로 생성할 수는 없습니다. 이 구조는 공유키 MAC보다 제3자 검증에 맞는 증거 형태를 만들 수 있습니다. 하지만 공개키가 실제 A에게 연결되어 있다는 인증서·신뢰 판단이 필요하고 개인키가 안전하게 관리되었는지도 중요합니다. 서명값이 유효하다는 사실은 지정된 공개키로 검증되는 값이라는 뜻이지, 키를 소유한 사람이 어떤 현실 행위를 했는지까지 무조건 증명하지 않습니다.
- 메시지를 누가 만들고 누가 확인해야 하는지 역할을 적습니다.
- 검증자가 같은 비밀키를 가진다면 MAC 생성도 가능하다는 점을 확인합니다.
- 검증자가 여러 명이고 키를 공유시키고 싶지 않다면 공개 검증이 필요한지 살핍니다.
- 전자서명에서는 공개키와 서명자의 연결, 개인키 보호, 서명 대상 데이터와 검증 절차를 함께 확인합니다.
- 기밀성이 필요하면 별도 암호화가 필요한지 판단합니다. MAC과 전자서명은 그 자체로 메시지 내용을 숨기지 않습니다.
부인방지를 절대적 사실 증명처럼 쓰지 않습니다
FIPS 186-5는 디지털 서명이 데이터의 허가되지 않은 변경을 탐지하고 서명자의 신원을 인증하는 데 쓰일 수 있으며, 수신자가 서명이 주장된 서명자에 의해 생성되었다는 증거로 제3자에게 제시할 수 있다고 설명합니다. 동시에 표준의 설명도 ‘쉽게 부인하기 어렵다’는 표현으로 한계를 드러냅니다. 전자서명을 확인했다고 실제 사람이 직접 승인했다는 결론으로 바로 넘어가면 안 됩니다. 개인키 탈취나 공유 여부, 인증서 유효성, 검증 시점, 서명 정책, 법적 맥락을 따로 살펴야 합니다.
RFC 2104는 HMAC의 원 문서지만 Informational RFC이며 Internet Standards Track 규격은 아닙니다. HMAC은 특정 해시 함수를 기반으로 한 MAC의 한 예입니다. 여기서 설명한 대칭키 방식은 모든 MAC 구현이 HMAC이라는 뜻이 아니고, 전자서명도 하나의 알고리즘으로 고정되지 않습니다. 시험 문제에서 ‘검증키를 다수가 공유하는가’라고 물으면 비밀키를 가진 당사자가 생성과 검증을 모두 할 수 있는지, 공개키만으로 검증이 가능한지를 축으로 비교하면 됩니다.
회상 연습: 검증자에게 어떤 키를 주어야 할까요
교육용 문제입니다. 세 명의 독립 감사자가 한 작성자의 기록을 확인해야 합니다. 감사자에게 같은 HMAC 비밀키를 나누어 주면 각자가 기록을 검증할 수 있습니다. 그렇다면 감사자는 기록에 맞는 새 MAC 태그도 만들 수 있을까요? 전자서명에서는 검증자에게 어떤 키를 주며, 그 키만으로 작성자의 서명을 만들 수 있나요?
공유 비밀키를 받은 감사자는 MAC 태그를 검증할 수 있을 뿐 아니라 새 태그도 만들 수 있습니다. 전자서명에서는 작성자의 공개키를 검증자에게 주고, 공개키만으로 서명 생성은 할 수 없습니다. 다만 공개키가 누구의 것인지 확인하는 과정과 개인키 보호가 필요하며, 이 결과만으로 현실의 행위나 법적 효력을 절대 증명한다고 말해서는 안 됩니다. 이 비교는 원리를 설명하기 위해 새로 만든 예시입니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
HMAC 검증자와 전자서명 검증자가 각각 보유한 키는 무엇이며, 검증자가 새 인증값을 만들 수 있는가?
정답과 해설 확인
HMAC 검증자는 생성자와 공유한 비밀키를 가지므로 태그를 검증하고 만들 수도 있습니다. 전자서명 검증자는 공개키를 가지고 서명을 검증하지만 그 공개키만으로 서명을 만들 수는 없습니다.RFC 2104는 HMAC의 계산과 검증에 공유 비밀키를 사용한다고 설명합니다. FIPS 186-5는 서명 알고리즘과 서명이 제3자에게 증거로 제시될 수 있는 역할을 설명하지만 절대적인 현실 행위 증명으로 보증하지 않습니다.