
## 📡 디지털 서명이란


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.15.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236434433-0)
디지털 서명(digital signature)은 손으로 직접 서명을 하는 것처럼, 문서의 작성자와 진위를 증명할 수 있게 해주는 암호 기술이다. 서명을 통해 ‘이 문서는 내가 작성한 것이고, 그 내용은 바뀌지 않았다’는 사실을 수학적으로 보장할 수 있다.


위 디지털 서명의 예시를 들어보자. Bob이 Alice에게 편지를 보내며 ‘내가 진짜 보낸 편지’라는 것을 증명하고 싶다고 하자. Bob은 이 편지의 내용을 자신의 개인키(private key)를 사용해 암호화한다. 이렇게 하면 그 누구도 (Alice조차도) 이 서명된 내용을 위조하거나 조작할 수 없다. 왜냐하면, Bob의 개인키는 오직 그만 가지고 있기 때문이다.


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.23.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236437503-1)
Alice는 이 서명된 편지를 받으면, Bob의 공개키(public key)를 이용해 복호화할 수 있다. 복호화 결과가 원래의 편지 내용과 일치하면, 다음 두 가지 사실을 동시에 확인할 수 있다.

1. 이 편지는 반드시 Bob이 서명한 것이다.
    - Bob의 공개키로 복호화가 가능하다는 것은 개인키로 암호화했다는 뜻이다.
2. 편지 내용이 바뀌지 않았다.
    - 서명된 데이터가 조금이라도 바뀌었으면 복호화가 깨졌을 것이다.

이 구조 덕분에 디지털 서명은 위조 방지(non-forgeability)와 부인 방지(non-repudiation)의 기능을 동시에 제공한다. Alice는 제3자에게 ‘이 메시지는 확실히 Bob이 보낸 것이다’라고 증명할 수 있다. 그리고 Bob은 ‘나는 그런 메시지 보낸 적 없다’고 주장할 수 없다.


## 📡 메시지 다이제스트


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.34.30.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236440009-2)
디지털 서명을 적용할 때 이런 문제를 마주하게 된다.

> 긴 메시지를 그대로 개인키로 암호화하려면 너무 많은 계산이 필요하다. 
>
> 그럼에도 메시지의 진위와 무결성을 어떻게 효율적으로 확인할 수 있을까?
>
>

이 문제를 해결해주는 것이 바로 메시지 다이제스트(message digest)다. 메시지 다이제스트는 원래의 긴 메시지를 고정된 길이의 짧은 값으로 요약하는 방식이다. 이를 위해 해시 함수(hash function)라는 수학적 함수를 사용한다.


해시 함수는 어떤 크기의 입력이 들어와도 항상 일정한 크기의 출력을 생성한다. 이 출력값은 흔히 디지털 지문(fingerprint)이라고 불리고 메시지를 대표하는 고유한 값처럼 사용된다. 예를 들어 수백 줄의 이메일 본문을 입력으로 넣어도, 해시 함수는 그 내용을 압축해서 단 몇 바이트 길이의 다이제스트를 만들어준다.


이 다이제스트는 다음과 같은 성질을 갖는다.

- 길이가 고정되어있다. 입력 길이에 관계없이 출력은 일정하다. (예: SHA-1은 160비트)
- 많은 입력, 같은 출력(many-to-one). 무한한 입력 공간을 유한한 출력에 맵핑하기 때문에, 서로 다른 메시지가 같은 해시 값을 가질 수도 있다. 하지만 이건 설계상 허용되며, 중요한 건…
- 역으로 찾기 어렵다. 어떤 해시 값 $x$가 주어졌을 때, 이를 만들어내는 입력 $m$을 찾는 건 계산적으로 불가능에 가깝다. 이것이 해시 함수의 핵심 보안 성질이다.

이러한 성질 덕분에 해시 함수는 디지털 서명과 결합되어 사용된다. 실제 서명 과정에서는 메시지 전체가 아닌, 해시 함수로 요약한 다이제스트에만 서명을 한다. 그 결과 서명은 빠르고 간결하면서도 메시지 전체의 무결성을 검증할 수 있게 된다.


### 작동 예시


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.33.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236442069-3)
실제 구현에서는 전체 메시지가 아니라, 그 메시지의 요약 값(hash)에 대해 서명을 한다. 이 구조를 사용하면 성능은 빠르면서도 무결성과 인증을 동시에 보장할 수 있다.


예를 들어 Bob이 Alice에게 메시지 m을 보내며 디지털 서명을 추가한다고 하자. 이때 전체 과정은 다음과 같이 이뤄진다.


<u>서명 생성: Bob → Alice</u>

- Bob은 먼저 메시지 $m$에 대해 해시 함수를 적용해 메시지 다이제스트 $H(m)$를 계산한다. 이 다이제스트는 메시지를 요약한 고정 길이의 값이다.
- 이어서, 이 $H(m)$을 자신의 개인키 $K_B^-$로 암호화한다. 이 암호화된 다이제스트가 곧 디지털 서명이다.
- Bob은 이제 두 가지를 Alice에게 전송한다.
    - 원본 메시지 $m$
    - 디지털 서명 $K_B^-(H(m))$

<u>서명 검증: Alice</u>

- Alice가 이 메시지를 받으면, 다음과 같은 과정을 통해 서명이 유효한지 확인할 수 있다.
    - Alice는 메시지 $m$에 똑같은 해시 함수를 적용해 자신만의 $H(m)$을 만든다.
    - 동시에 Bob이 보낸 디지털 서명을 Bob의 공개키 ${K_B}^+$를 사용해 복호화한다.
        - 이 결과는 Bob이 실제로 서명할 때 사용한 $H(m)$이어야 한다.
    - 마지막으로 두 개의 다이제스트를 비교한다.
        - Alice가 직접 계산한 $H(m)$
        - 서명으로부터 복호화한 $H(m)$
- 이 둘이 일치한다면, Alice는 다음 두 가지를 확신할 수 있다.
    - 이 메시지는 Bob이 보낸 것이고 제3자가 위조한 것이 아니다.
    - 메시지 내용은 전송 중에 변경되지 않았다.

## 📡 암호에는 부적절한 인터넷 체크섬


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.25.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236444978-4)
## 📡 실제로 사용되는 해시 함수들


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.41.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236447404-5)
위에서 봤듯이 디지털 서명과 메시지 무결성 검증에는 반드시 **해시 함수**가 필요하다. 하지만 해시 함수는 단지 ‘있으면 되는 도구’가 아니다. 충분히 안전하고, 빠르며, 충돌 가능성이 낮아야 실전에서 쓸 수 있다. 지금까지 널리 사용된 대표적인 해시 함수로는 MD5와 SHA-1이 있다.


### MD5


MD5(Message Digest 5)는 1991년, 로널드 리베스트(Ron Rivest)가 설계한 해시 함수로 RFC 1321에 표준으로 정의되어 있다. 이 알고리즘은 어떤 크기의 입력 메시지가 들어와도 **128비트의 고정된 해시 값**을 만들어낸다. 내부적으로는 4단계 과정을 거쳐 입력을 압축하고, 최종 요약값을 계산한다.


MD5는 오랜 기간 동안 암호화 검증, 파일 무결성 체크, 디지털 서명 등에 널리 사용되었다. 특히 계산이 매우 빠르다는 장점이 있어 시스템 전반에 많이 채택되었지만, 시간이 지나면서 보안 취약점이 드러났다.


2000년대 중반 이후에는 서로 다른 두 입력이 같은 해시 값을 갖는 ’충돌(collisions)’을 비교적 쉽게 찾을 수 있음이 밝혀졌고, 그 이후 보안 분야에서는 더 이상 안전한 해시 함수로 간주되지 않는다.


### **SHA-1**


SHA-1(Secure Hash Algorithm 1)은 미국 NIST(국립표준기술연구소)에서 표준으로 채택한 해시 함수로, 160비트의 메시지 다이제스트를 생성한다. MD5보다 출력이 길기 때문에 이론상 충돌 가능성이 더 낮으며, 한동안 보안적으로 더 안전한 대안으로 여겨졌다.


하지만 SHA-1 역시 2010년대 중반 이후 이론적 충돌 공격이 가능하다는 연구 결과가 발표되었고, 2017년에는 실제 충돌을 만들어내는 사례(SHAttered attack)도 등장했다. 그 결과 현재는 대부분의 보안 프로토콜이 SHA-1 사용을 중단하고, SHA-256이나 SHA-3 같은 더 강력한 해시 함수로 전환하고 있다.


## 📡 공개키 인증 방식은 안전할까?


![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-09_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_6.35.49.png](https://jant31jr2n1d0dxw.public.blob.vercel-storage.com/digital-signature/image-1753236449176-6)
공개키 암호화는 인증과 보안 통신에서 매우 강력한 도구다. 그래서 ap5.0 프로토콜에서는 다음과 같은 방식으로 인증을 시도한다.

1. Alice는 Bob에게 ‘나는 Alice야’라고 주장하며 공개키 기반 인증을 시작한다.
2. Bob은 Alice에게 난수 $R$을 보내고, 이것을 Alice의 비밀키로 암호화해 되돌려 달라고 한다.
3. 암호문을 Bob이 Alice의 공개키로 복호화했을 때 $R$과 일치한다면, 그 상대방은 Alice라고 확신할 수 있다.

이론상 아주 깔끔한 방식처럼 보이지만, 여기에 **치명적인 허점**이 있다.


### **ap5.0의 실패 시나리오, Trudy의 공격**


공격자인 Trudy는 다음과 같은 방식으로 공격을 수행할 수 있다.

1. Bob에게 접근해 ‘나는 Alice야’라고 주장한다.
2. Bob이 Trudy에게 공개키를 달라고 요청하자, Trudy는 자신의 공개키를 보내지만 그것이 Alice의 것처럼 속인다.
3. Bob은 이 키가 진짜 Alice의 것이라고 믿고, 거기에 난수 $R$을 보내 암호화된 응답을 기대한다.
4. Trudy는 자신의 비밀키로 $R$을 암호화해 다시 Bob에게 보낸다.
5. Bob은 그 암호문을 Trudy가 준 공개키로 복호화하므로, 결과적으로 R이 제대로 복호화된다고 착각하고 Trudy를 Alice로 신뢰하게 된다.

이 시점에서 Bob은 Trudy를 Alice로 완전히 잘못 인증하고, 이후 개인적인 메시지 $m$를 암호화해 보내게 된다.


Trudy는 이 메시지를 쉽게 복호화할 수 있다. 왜냐하면 메시지는 Trudy가 넘긴 공개키로 암호화되었고, Trudy는 그에 해당하는 비밀키를 가지고 있기 때문이다. 게다가 Trudy는 이 메시지를 다시 Alice의 공개키로 재암호화해서 전달할 수도 있다. 결과적으로 Alice와 Bob은 서로 안전하게 통신했다고 믿지만, 그 사이에서 Trudy는 모든 내용을 엿볼 수 있게 된다.


### **문제점**


이 시나리오의 가장 큰 문제는 다음 한 줄로 요약할 수 있다.

> Bob은 Trudy가 보내온 공개키가 진짜 Alice의 것인지 검증하지 않았다.

즉, 공개키 자체는 안전하더라도, **그 키가 실제 Alice에게 속하는지 확인하지 않으면 전체 인증 체계가 무너질 수 있다.** 이를 해결하려면 공개키와 사용자의 신원을 묶어주는 **공인 인증서(Certificate Authority)** 시스템이 필요하다.



📡 암호에는 부적절한 인터넷 체크섬

📡 실제로 사용되는 해시 함수들

📡 공개키 인증 방식은 안전할까?

ap5.0의 실패 시나리오, Trudy의 공격

Digital Signature (디지털 서명)