인증 프로토콜 실험들 (ap 1.0 ~ 5.0) | Notes

인증 프로토콜의 진화

네트워크 인증 프로토콜은 "상대방이 정말 그 사람인지 어떻게 확인할 것인가"라는 질문에 답한다. 완벽한 프로토콜을 처음부터 설계하기는 어렵다. 대신, 간단한 버전에서 시작해 취약점을 발견하고 보완하는 과정을 반복하며 발전해왔다. ap 1.0부터 5.0까지의 진화 과정은 이 원리를 잘 보여준다.

ap 1.0: 단순 선언 (보안 없음)

%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_5.52.41.png

가장 단순한 접근: Alice가 "나는 Alice야"라고 말하면 Bob은 그냥 믿는다.

문제점: 누구든 "나는 Alice야"라고 주장할 수 있다. 인증이라 부를 수 없는 수준이다.

ap 2.0: IP 주소 기반 인증

%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_5.52.50.png

Alice의 IP 주소를 확인해서 신원을 검증한다. 알려진 IP 주소에서 온 요청만 신뢰한다.

문제점: IP 주소는 위조할 수 있다(IP Spoofing). 공격자가 Alice의 IP 주소를 사용해 패킷을 보내면 Bob은 구분할 수 없다.

ap 3.0: 비밀 비밀번호

%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_5.52.59.png

Alice와 Bob이 사전에 비밀번호를 공유한다. Alice가 비밀번호를 보내면 Bob은 이를 검증해 인증한다.

문제점: 비밀번호가 평문으로 네트워크를 통해 전송된다. 도청자(Trudy)가 패킷을 캡처하면 비밀번호를 알게 되고, 이후 Alice를 사칭할 수 있다.

ap 3.1: 비밀번호 암호화

%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_5.53.10.png

비밀번호를 암호화해서 전송한다. 도청자는 암호문만 볼 수 있다.

문제점: 재전송 공격(Replay Attack). Trudy가 암호화된 비밀번호를 캡처해 나중에 그대로 재전송하면, Bob은 이를 정상적인 인증으로 받아들인다. 암호를 해독할 필요가 없다.

ap 4.0: Nonce를 이용한 Challenge-Response

%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_5.53.20.png

재전송 공격을 막기 위해 nonce(number used once)를 도입한다.

Alice가 인증 요청
Bob이 랜덤한 nonce R을 생성해서 전송
Alice가 공유 비밀키로 R을 암호화해서 응답: K(R)
Bob이 복호화해서 R과 일치하면 인증 성공

핵심: 매번 다른 nonce를 사용하므로 이전 응답을 재사용할 수 없다.

%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_5.53.32.png

ap 4.0은 대칭키 암호를 사용한다. Alice와 Bob이 같은 비밀키를 공유해야 한다는 전제가 있다. 이 키를 어떻게 안전하게 공유할 것인가가 다음 문제다.

ap 5.0: 공개키 암호 기반 인증

%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_5.53.43.png

공개키 암호를 사용하면 사전에 비밀키를 공유할 필요가 없다.

Bob이 nonce R을 전송
Alice가 자신의 개인키로 R에 서명해서 응답
Bob이 Alice의 공개키로 서명을 검증

Alice의 개인키는 Alice만 알고 있으므로, 올바른 서명을 생성할 수 있는 것은 Alice뿐이다.

%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_5.55.34.png

하지만 여기서도 문제가 있다: Bob은 "Alice의 공개키"라고 알고 있는 키가 정말 Alice의 것인지 어떻게 확신할 수 있나?

중간자 공격 (Man-in-the-Middle)

%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_5.55.42.png

공격자 Trudy가 Alice와 Bob 사이에 끼어들어 양쪽에 자신의 공개키를 전달한다:

Bob은 Trudy의 공개키를 Alice의 것으로 알고 있다
Alice는 Trudy의 공개키를 Bob의 것으로 알고 있다

Trudy는 양쪽의 메시지를 복호화하고 다시 암호화해서 전달할 수 있다. 통신 당사자들은 이를 알아차리지 못한다.

해결책: 인증서와 CA

%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_5.55.50.png

신뢰할 수 있는 제3자인 CA(Certificate Authority)가 공개키의 소유자를 보증한다. CA는 "이 공개키는 Alice의 것이다"라는 내용을 담은 인증서를 발급하고, 자신의 개인키로 서명한다.

Bob은 CA의 공개키를 미리 알고 있으므로, 인증서의 서명을 검증해 Alice의 공개키가 진짜인지 확인할 수 있다.

%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_5.56.00.png

이것이 현대 인터넷 보안(TLS/HTTPS)의 기반이다. 브라우저는 신뢰할 수 있는 CA들의 공개키를 미리 내장하고 있고, 웹사이트는 CA가 서명한 인증서를 제시해 자신의 신원을 증명한다.

인증 프로토콜 발전 요약

버전	방식	취약점
ap 1.0	단순 선언	사칭 가능
ap 2.0	IP 주소	IP 스푸핑
ap 3.0	평문 비밀번호	도청
ap 3.1	암호화된 비밀번호	재전송 공격
ap 4.0	Nonce + 대칭키	키 분배 문제
ap 5.0	Nonce + 공개키	중간자 공격
ap 5.0 + CA	인증서 기반	(현대 표준)

각 버전의 취약점을 이해하면 왜 현대 인증 프로토콜이 이렇게 복잡해졌는지 알 수 있다.

정리

ap 1.0~3.1까지는 정적 정보(선언, IP, 비밀번호)에 의존하므로 사칭·도청·재전송에 취약하다
ap 4.0의 nonce + challenge-response가 재전송 공격을 차단하는 핵심 전환점이고, 이후 대칭키→공개키로 키 분배 문제를 해결한다
공개키만으로는 중간자 공격을 막을 수 없어서 CA 기반 인증서 체계가 필요하며, 이것이 현대 TLS/HTTPS의 기반이다