암호화에서 가장 어려운 문제 중 하나는 **"키를 어떻게 안전하게 전달할 것인가"**이다. 아무리 강력한 암호 알고리즘을 사용해도, 키가 노출되면 모든 것이 무너진다. 이 글에서는 대칭키 분배 문제부터 시작해 PKI(Public Key Infrastructure)까지 키 관리의 전체 그림을 살펴본다.
대칭키 분배 문제
대칭키 암호화는 비대칭키보다 빠르고 효율적이다. 하지만 치명적인 단점이 있다. 통신하려는 두 사람이 같은 비밀키를 공유해야 한다는 것이다.
n명이 서로 통신하려면 n(n-1)/2개의 키가 필요하다. 100명이면 4,950개, 1000명이면 약 50만 개의 키가 필요하다.
문제는 두 가지이다.
- 키의 개수: 사용자가 늘어날수록 관리할 키가 폭발적으로 증가한다.
- 키의 분배: 비밀키를 어떻게 안전하게 상대방에게 전달할 것인가?
해결책은 **신뢰할 수 있는 제3자(Trusted Third Party)**를 활용하는 것이다.
KDC (Key Distribution Center)
**KDC(키 분배 센터)**는 신뢰할 수 있는 중앙 기관이다. 모든 사용자는 KDC와만 비밀키를 공유하면 된다.
Alice가 Bob에게 기밀 메시지를 보내는 과정
- Alice가 KDC에 "Bob과 통신하고 싶다"고 요청한다.
- KDC가 Bob에게 Alice의 요청을 알린다.
- Bob이 동의하면, KDC가 둘 사이의 **세션 키(임시 비밀키)**를 생성한다.
KDC의 문제점
- KDC 데이터베이스가 공격의 주요 타겟이 된다.
- KDC에 장애가 발생하면 전체 네트워크가 마비된다.
- KDC에서 통신 병목 현상이 발생할 수 있다.
다중 KDC
단일 KDC의 문제를 해결하기 위해 여러 개의 KDC를 운영한다. 세계를 도메인으로 나누고, 각 도메인마다 하나 이상의 KDC를 둔다.
세션 키
KDC가 각 사용자에게 만들어주는 비밀키는 KDC와 사용자 간에만 사용된다. 사용자끼리 직접 통신할 수는 없다.
Alice가 Bob과 비밀 통신을 하려면 세션 키가 필요하다. KDC는 Alice와 Bob 각각의 키를 이용해 둘 사이의 세션 키를 생성한다. 이 세션 키는 한 번만 사용되고 폐기된다.
Needham-Schroeder 프로토콜
세션 키를 안전하게 교환하기 위한 대표적인 프로토콜이다.
Otway-Rees 프로토콜
Needham-Schroeder의 개선 버전이다.
대칭키 합의: Diffie-Hellman
Alice와 Bob이 KDC 없이 직접 세션 키를 만들 수 있을까? Diffie-Hellman 프로토콜이 그 해답이다.
동작 과정
- Alice가 큰 난수 x를 선택하고 R₁ = g^x mod p를 계산한다. (0 ≤ x ≤ p-1)
- Alice가 R₁을 Bob에게 전송한다. (x는 비공개)
- Bob이 큰 난수 y를 선택하고 R₂ = g^y mod p를 계산한다. (0 ≤ y ≤ p-1)
- Bob이 R₂를 Alice에게 전송한다. (y는 비공개)
- Alice가 K = (R₂)^x mod p를 계산한다.
- Bob이 K = (R₁)^y mod p를 계산한다.
결과적으로 Alice와 Bob은 같은 K 값을 얻는다. Bob은 x를 모르고, Alice는 y를 모르지만, 둘 다 같은 비밀키를 갖게 된다.
Primitive Root 예시
p = 7, g = 3일 때:
- 3¹ mod 7 = 3
- 3² mod 7 = 2
- 3³ mod 7 = 6
- 3⁴ mod 7 = 4
- 3⁵ mod 7 = 5
- 3⁶ mod 7 = 1
1부터 6까지 모든 나머지가 나온다. 이런 g를 Primitive Root라고 한다.
계산 예시
p = 23, g = 7인 경우:
- Alice: x = 3 선택, R₁ = 7³ mod 23 = 21
- Alice가 21을 Bob에게 전송
- Bob: y = 6 선택, R₂ = 7⁶ mod 23 = 4
- Bob이 4를 Alice에게 전송
- Alice: K = 4³ mod 23 = 18
- Bob: K = 21⁶ mod 23 = 18
둘 다 K = 18을 얻는다. (g^xy mod p = 7^18 mod 23 = 18)
현실적인 예시
실제로는 512비트 이상(이상적으로 1024비트)의 난수를 사용한다. p는 159자리 이상의 큰 수가 된다.
Diffie-Hellman 분석
Diffie-Hellman의 핵심 아이디어는 단순하지만 우아하다.
- 비밀키는 g, x, y 세 부분으로 구성된다.
- g는 공개값이고 (1/3), 나머지 2/3는 Alice와 Bob이 각각 기여한다.
- Alice의 키 (g, y, x)와 Bob의 키 (g, x, y)는 결국 같다. g^xy = g^yx이기 때문이다.
- modulo p 연산 덕분에 Alice는 Bob의 y를, Bob은 Alice의 x를 알아낼 수 없다.
Diffie-Hellman의 취약점
두 가지 공격에 취약하다.
1. 이산 로그 공격 (Discrete Logarithm Attack)
Eve가 R₁과 R₂를 가로채고, 여기서 x와 y를 역산해낼 수 있다면 K를 계산할 수 있다.
2. 중간자 공격 (Man-in-the-Middle Attack)
Eve는 x나 y를 알 필요가 없다. Eve가 Alice와 Bob 사이에 끼어들어 두 개의 키를 만들 수 있다. 하나는 Eve-Alice 간, 하나는 Eve-Bob 간이다. Alice와 Bob은 서로 통신한다고 생각하지만, 실제로는 Eve와 통신하고 있다.
Station-to-Station 프로토콜
Diffie-Hellman을 기반으로 하되, 디지털 서명과 공개키 인증서를 추가한 프로토콜이다.
중간자 공격을 방지할 수 있다. Eve가 자신의 R₂를 Bob인 척 Alice에게 보내려 해도, Bob의 개인키로 만든 서명을 위조할 수 없기 때문이다.
공개키 분배와 PKI
비대칭키 암호화에서는 대칭키처럼 비밀키를 공유할 필요가 없다. 각자 개인키는 비밀로 유지하고, 공개키는 공개하면 된다.
문제는 공개키를 어떻게 안전하게 배포할 것인가이다.
인증서를 이용한 공개키 배포
**CA(Certificate Authority, 인증 기관)**가 공개키와 사용자를 연결하고 인증서를 발급한다. CA는 신뢰할 수 있는 중앙 기관이다.
CA는 자신의 공개키를 널리 알리고, 인증서 위조를 방지하기 위해 CA의 개인키로 인증서에 서명한다.
PKI (Public Key Infrastructure)
**PKI(공개키 기반 구조)**는 X.509 표준을 기반으로 디지털 인증서를 생성, 배포, 폐기하는 체계이다. IETF에서 PKIX(Public Key Infrastructure X.509)를 정의했다.
PKI의 역할
- 인증서 발급, 갱신, 폐기
- 키 저장 및 업데이트
- 다른 프로토콜에 서비스 제공
- 접근 제어 제공
디지털 인증서
디지털 인증서는 종이 여권의 디지털 버전이다.
- 인터넷에서 사람/조직을 고유하게 식별한다.
- 사용자와 공개키를 연결한다.
- 운전면허증이나 여권처럼, 나와 내 공개키의 연관성을 증명한다.
이 연관성을 누가 승인하는가? **CA(Certificate Authority)**이다.
인증서에는 무엇이 들어있는가? X.509 표준을 따른다.
인증서의 내용
주요 내용은 주체 이름(사용자), 유효 기간, 공개키이다. CA가 서명하여 사용자 신원을 보증한다.
CA의 역할
- CA는 디지털 인증서를 발급할 수 있는 신뢰 기관이다. (VeriSign, Entrust 등)
- 정부가 누가 CA가 될 수 있는지 결정한다.
- CA는 인증서에 서명한다. "나 CA는 48924579가 A의 공개키임을 보증한다"라는 서명된 메시지이다.
- 모든 참여자가 인증서, 개인키, CA의 공개키를 가지면 상대방의 공개키를 인증할 수 있다.
X.509 인증서 형식
CA (Certificate Authority)
사용자는 자신의 개인키를 기억하고, 다른 사용자들의 공개키에 접근할 수 있어야 한다. 모든 사용자는 CA의 공개키 사본을 갖는다.
CA가 A의 인증서에 CA의 개인키로 서명하여 A에게 보낸다. B가 A의 인증서를 받으면, CA의 공개키로 검증할 수 있다. A는 CA와 상호작용 없이도 자신의 인증서를 전송할 수 있다.
CA가 인증서에 서명하는 방법
- 인증서의 마지막 필드를 제외한 모든 내용의 메시지 다이제스트를 생성한다. (SHA1 등 사용)
- 메시지 다이제스트를 CA의 개인키로 서명하여 디지털 서명을 만든다.
- 디지털 서명을 인증서의 마지막 필드에 저장한다.
인증서 검증 방법
- 인증서의 마지막 필드를 제외한 모든 내용의 메시지 다이제스트를 생성한다. → MD1
- 인증서 마지막 필드의 디지털 서명을 CA의 공개키로 복호화한다. → MD2
- MD1 = MD2이면 검증 성공, 아니면 거부
CA의 공개키는 어떻게 얻는가?
CA의 인증서를 얻으면 된다. 그런데 CA의 인증서는 누가 서명하는가?
CA 조직 구조
- CA 계층 구조와 자체 서명 인증서
- 상호 인증
CA 계층 구조
CA는 여러 단계로 존재할 수 있다. 업무 위임에 유용하며, 상위 CA가 하위 CA를 보증한다.
자체 서명 인증서
Root CA는 누가 서명하는가?
- Root CA는 자동으로 신뢰되는 CA로 간주된다.
- 소프트웨어에 미리 프로그램된 Root CA 인증서가 하드코딩되어 있다. (웹 브라우저 등에 포함)
- Root CA는 자신의 인증서에 스스로 서명한다. (Self-signed certificate)
상호 인증 (Cross-Certification)
Root CA가 다른 경우, 서로를 인증한다. 이를 통해 교차 신뢰가 형성된다.
PKI 구성 요소
PKI를 구성하는 요소들이다.
- End user (최종 사용자)
- CA (Certificate Authority)
- RA (Registration Authority)
- Key Recovery Server
- X.500 Directory
RA (Registration Authority)
RA는 최종 사용자와 CA 사이의 중간 기관이다.
RA의 역할
- 신규 사용자의 등록 정보 수락 및 검증
- 사용자를 대신해 키 생성
- 키 백업 및 복구 요청 수락 및 승인
- 인증서 폐기 요청 수락 및 승인
- 단, RA는 인증서를 직접 생성하지 않는다
CA의 업무를 분담하여 CA를 격리된 상태로 유지한다. 이로써 CA가 보안 공격에 덜 노출된다.
Key Recovery Server
사용자가 개인키를 분실하면 어떻게 해야 하는가?
방법 1: CA가 해당 인증서를 폐기 → 새 키 쌍 생성 → 새 인증서 발급
방법 2: Key Recovery Server 사용. CA가 키 생성 시점에 개인키를 백업해둔다.
Certificate Directory
인증서를 어디에 저장하는가?
방법 1: 사용자가 로컬 머신에 저장
방법 2: CA가 **인증서 디렉토리(중앙 저장소)**를 사용. 인증서 관리와 배포를 위한 단일 지점을 제공한다. (인증서 폐기 시에도 유용)
인증서 폐기 (Certificate Revocation)
인증서 폐기 사유
- 개인키가 유출됨
- CA가 인증서 발급 시 실수를 함
- 인증서 소유자가 퇴사함 등
인증서 사용 전 확인 사항
- 인증서가 소유자의 것인가? (인증서 서명 확인)
- 인증서가 유효한가, 폐기되었는가?
폐기 확인 메커니즘
인증서 사용 전에 유효성을 확인해야 한다. 온라인 확인과 오프라인 확인 두 가지 방법이 있다.
CRL (Certificate Revocation List)
CRL은 무효화된 인증서 목록을 담은 파일이다. CA가 주기적으로 발행한다.
CRL의 특징
- RA가 폐기된("bad") 인증서 목록을 발행한다.
- 정기적으로 갱신 및 공개된다. (예: 매일)
- 유효 기간이 끝난 인증서는 포함하지 않는다.
- 사용자는 만료일과 서명 확인 외에 최신 CRL도 확인해야 한다.
그렇다면 만료일은 왜 필요한가?
- 폐기 메커니즘을 효율적으로 만든다. 현재 만료되지 않은 인증서의 CRL만 관리하면 된다.
- 많은 시스템이 폐기 확인 없이 만료일만 확인한다.
CRL을 이용한 인증서 검증
OCSP (Online Certificate Status Protocol)
OCSP는 CRL을 대체하거나 보완하여 사용할 수 있다.
클라이언트가 CA가 제공하는 서버(OCSP Responder)에 인증서 상태 요청을 보낸다. 서버는 X.500 디렉토리를 참조하여 "good", "revoked", "unknown" 중 하나를 응답한다. 응답은 CA나 신뢰할 수 있는 Responder가 서명한다.
실시간으로 인증서 상태를 확인할 수 있다는 것이 CRL과의 차이이다.
HGU 전산전자공학부 고윤민 교수님의 24-2 컴퓨터 보안 수업을 듣고 작성한 포스트이며, 첨부한 모든 사진은 교수님 수업 PPT의 사진 원본에 필기를 한 수정본입니다.