본문으로 건너뛰기
페이지 목차
이 페이지에서 검색

EIS

이 페이지에 묻기

EIS · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.

생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.

EIS · SECURITY

EIS

생성 수정

정보보안기사의 시스템·네트워크·애플리케이션 보안과 암호·관리·실기 내용을 개념의 경계와 실습으로 연결합니다.

29개 문서 · 4 · 정보보안일반 · 19 / 29

18 · 키 분배 · 전자서명 · PKI

지도 위치 : 4과목 정보보안 일반 · README 4장 ② 부품 층 (무엇으로 지키나) | 출제기준: 1. 보안요소 기술 > 3. 키 분배 프로토콜, 4. 디지털서명 | 이전: 17 인증과 접근통제 | 다음: 19 암호 알고리즘 출제 빈도 : ⭐⭐ (회당 약 4.8문항 — 출제분석.md) · 변화 ▼ (이전 5.6 → 현행 4.0. 공인인증서 문항 감소, OCSP · CRL · X.509는 계속 출제) 세세항목 : (키 분배 프로토콜) 1. 대칭 키 기반 분배 방식의 원리 및 운영 / 2. 공개 키 기반 분배 방식의 원리 · (디지털서명) 1. 인증서 구조 및 주요 특징 / 2. 디지털서명의 이해(종류, 보안 요구 조건, 특징, 서명 방식 등) / 3. PKI 구성방식 및 관리(계층구조, 네트워크 구조, 복합형 구조, CRL, OCSP 등) / 4. 디지털서명 응용 원리 및 구조(은닉서명, 이중서명 등)

이 노트를 다 읽으면

  1. 대칭키의 키 배송 문제 를 n(n-1)/2로 설명하고, 해결책 네 가지(사전 분배 · KDC · 키 합의 · 공개키)와 해결책이 아닌 것을 구별할 수 있다.
  2. Diffie-Hellman 키 교환을 직접 계산하고, 왜 중간자 공격 에 취약한지 말할 수 있다.
  3. KDC · Needham-Schroeder 의 동작과 약점을 설명할 수 있다.
  4. 전자서명의 다섯 요건 과 서명 · 검증에 쓰는 키 를 헷갈리지 않고 고를 수 있다.
  5. 은닉서명 · 이중서명 · 그룹서명 이 각각 무엇을 숨기거나 나누는지 말할 수 있다.
  6. X.509 v3 인증서의 기본 필드와 확장 필드, PKI 구성 요소 (CA · RA · 저장소 · 사용자)의 역할을 댈 수 있다.
  7. CRL과 OCSP 를 실시간성 · 부하 · 정보 내용으로 비교할 수 있다.

0. 이 노트의 판별 축

#축왼쪽 (0)오른쪽 (1)이 축으로 갈리는 것큰 축 (README 5장)
1키가 몇 개인가대칭키 기반 분배공개키 기반 분배KDC · Needham-Schroeder · Kerberos ↔ DH · RSA 키 전송⑤ 대칭 ↔ 비대칭
2키를 누가 만드나한쪽(또는 센터)이 만들어 전달 (키 분배 · 전송)양쪽이 함께 계산 (키 합의)KDC · RSA 키 전송 ↔ Diffie-Hellman이 노트의 축
3어느 키로 무엇을 하나공개키로 암호화 → 기밀성개인키로 서명 → 인증 · 부인방지수신자 공개키 암호화 ↔ 송신자 개인키 서명⑤의 파생 (이 노트의 축)
4인증서 상태를 언제 확인하나주기적으로 목록을 받아 봄 (일괄)필요할 때 물어봄 (실시간)CRL ↔ OCSP이 노트의 축
5누가 무엇을 모르게 하나서명자가 내용을 모름검증자가 일부만 봄은닉서명 ↔ 이중서명이 노트의 축

이 노트가 답하는 질문은 "암호를 쓰려면 키를 어떻게 나눠 갖고, 그 공개키가 정말 그 사람 것인지 어떻게 믿는가?" 입니다. 탑다운 순서상 앞에서 배운 대칭키 · 공개키 암호(19번 노트)와 해시(20번 노트), Kerberos(17번 노트)가 여기서 조립됩니다. 보안 목표(21번 노트)로 보면 전자서명은 무결성 · 인증 · 부인방지 를 주는 부품이고, 기밀성은 주지 않습니다.


1. 키 배송 문제 ⭐

1.1 왜 문제인가

대칭키 암호는 빠르지만 보내는 쪽과 받는 쪽이 같은 키를 미리 가져야 합니다. 그 키를 네트워크로 보내면 도청당하고, 직접 만나 건네면 규모가 커질 수 없습니다. 이것이 키 배송(분배) 문제 입니다.

n명이 서로 1:1로 비밀 통신 하려면 필요한 대칭키 수는

n(n-1)/2      예) 10명 → 45개, 100명 → 4,950개, 1,000명 → 499,500개

공개키 방식이면 사람마다 키 쌍 1개씩, 2n개 (공개키 n + 개인키 n)면 됩니다.

📝 기출 포인트 — "n명에게 필요한 대칭키 수" 계산이 2013년부터 2024년까지 반복(19번 노트 문항으로도 분류됨). 공식 n(n-1)/2 만 정확히.

1.2 해결책 네 가지

해결책방식대표축 2
키 사전 분배통신 전에 미리 키(또는 키를 만들 재료)를 나눠 줌오프라인 배포, Blom 방식분배
키 분배 센터 (KDC)신뢰할 수 있는 센터가 필요할 때마다 세션키를 만들어 줌Needham-Schroeder, Kerberos분배
키 합의 (Diffie-Hellman)공개된 값만 주고받아 양쪽이 같은 비밀값을 계산DH, ECDH합의
공개키 암호로 전송세션키를 수신자의 공개키로 암호화해 보냄RSA 키 전송분배(전송)

⚠️ 반례 — 전자서명은 키 배송 문제의 해결책이 아닙니다. 서명은 "누가 보냈나"를 증명할 뿐 키를 비밀리에 전달하지 않습니다(2018 · 2019 출제). "역할 기반 접근관리"도 키 분배와 무관합니다.

세션키 — [암호 키]인데, [ 한 번의 통신(세션)에서만 쓰고 버린다 ]는 점에서 오래 쓰는 마스터키(장기 키)와 구별된다. 세션키가 노출돼도 그 세션만 피해를 봅니다.

Blom 방식 — [키 사전 분배 방식]인데, [ 센터가 각 사용자에게 비밀 함수값을 미리 나눠 주면, 임의의 두 사용자가 센터 없이 서로의 공유키를 계산한다 ]는 점에서 통신할 때마다 센터에 묻는 KDC와 구별된다.


2. 대칭키 기반 분배 — KDC · Needham-Schroeder

2.1 KDC

KDC (Key Distribution Center) — [키 분배 방식]인데, [ 각 사용자가 센터와만 비밀키(마스터키)를 공유하고, 통신이 필요할 때 센터가 세션키를 만들어 각자의 마스터키로 암호화해 나눠 준다 ]는 점에서 사용자끼리 직접 키를 맞추는 키 합의와 구별된다.

특징내용
필요한 장기 키 수사용자 n명이면 센터와의 키 n개 (n(n-1)/2 문제 해결)
사용하는 암호대칭키 (공개키를 쓰지 않음)
약점센터가 단일 실패 지점 , 센터에 모든 키가 모임, 사용자가 늘면 센터 부하 증가

📝 기출 포인트 — "KDC는 공개키 암호를 사용한다"는 틀린 설명(2022). "사용자가 늘면 KDC에 미치는 영향"(부하 · 병목)도 출제.

2.2 Needham-Schroeder 프로토콜

Needham-Schroeder (대칭키 버전) — [KDC 기반 키 분배 프로토콜]인데, [ 난수(Nonce)로 응답의 새로움을 확인하며 두 사용자에게 세션키를 나눠 준다 ]는 점에서 타임스탬프를 쓰는 Kerberos의 원형이다.

① A → KDC : A, B, Na                              (Na: A가 만든 난수)
② KDC → A : E_Ka[ Na, B, Ks, E_Kb[Ks, A] ]       (Ks: 세션키)
③ A → B   : E_Kb[Ks, A]                           (KDC가 만든 B용 티켓 전달)
④ B → A   : E_Ks[Nb]
⑤ A → B   : E_Ks[Nb - 1]                          (Ks를 가졌음을 증명)

🔍 읽는 포인트 : E_Ka[...]는 "A와 KDC만 아는 키로 암호화". ②의 Na가 그대로 돌아와야 A는 이것이 방금 요청에 대한 새 응답 임을 압니다. ③의 묶음이 Kerberos의 티켓 에 해당합니다.

⚠️ 취약점 — ③에는 새로움을 보장하는 값이 없어서, 공격자가 예전 세션키 Ks를 알아낸 뒤 옛 ③을 재전송 하면 B는 속습니다(재전송 공격, Denning-Sacco가 지적). 그래서 Kerberos는 타임스탬프 를 넣었습니다.

2.3 Kerberos 다시 보기

Kerberos는 인증 프로토콜(17번 노트)이면서 KDC 기반 대칭키 분배 프로토콜 입니다. 티켓 안에 세션키 가 들어 있어 사용자와 서버가 같은 세션키를 갖게 됩니다. v4는 DES만, v5는 여러 알고리즘을 씁니다. 설계 요구사항은 보안성 · 신뢰성 · 투명성 · 확장성 으로 정리됩니다.

📝 기출 포인트 — "MIT가 개발한 대칭키 기반 인증 · 키 분배 시스템", "Kerberos V5의 개선점이 아닌 것", Needham-Schroeder 식별과 절차 · 취약점(2022 · 2023).


3. 공개키 기반 분배 — Diffie-Hellman · RSA ⭐⭐

3.1 Diffie-Hellman 키 교환

Diffie-Hellman (DH) — [키 합의 프로토콜]인데, [ 공개된 값만 주고받고도 양쪽이 같은 비밀값을 각자 계산한다 ]는 점에서 한쪽이 만든 키를 암호화해 보내는 RSA 키 전송과 구별된다. 1976년 Diffie와 Hellman이 발표한 최초의 공개키 개념이며, 안전성은 이산대수 문제 (g^x mod p에서 x를 찾기 어려움)에 기반합니다.

공개: 소수 p, 생성원 g
A: 비밀 a 선택 → YA = g^a mod p 를 B에게 보냄
B: 비밀 b 선택 → YB = g^b mod p 를 A에게 보냄
A: K = YB^a mod p = g^ab mod p
B: K = YA^b mod p = g^ab mod p      → 같은 값

계산 예 (p = 23, g = 5, a = 6, b = 15)

단계계산값
A의 공개값5^6 mod 238
B의 공개값5^15 mod 2319
A가 계산한 키19^6 mod 232
B가 계산한 키8^15 mod 232

🔍 읽는 포인트 : 도청자는 p, g, 8, 19를 다 보지만 a나 b를 모르면 2를 계산할 수 없습니다. 실제로는 p가 수천 비트라서 a를 거꾸로 찾는 것이 불가능합니다.

DH의 약점 — 중간자 공격

DH는 상대가 누구인지 확인(인증)하지 않습니다. 공격자 M이 중간에서 A에게는 B인 척, B에게는 A인 척 각자와 DH를 따로 맺으면, A-M 키와 M-B 키로 모든 내용을 풀어 보고 다시 암호화해 넘길 수 있습니다.

DH의 특징내용
기반 문제이산대수
제공하는 것키 합의 (암호화 · 서명 기능은 없음)
약점중간자 공격 (MITM) , 인증 없음, 서비스 거부(계산 부담)
보완공개값에 전자서명 · 인증서 를 붙임 (인증된 DH), 타원곡선 버전 ECDH

📝 기출 포인트 — G1.3에서 Diffie-Hellman이 12회 로 압도적. "1976년 제안된 키 교환", "이산대수 기반", " 중간자 공격에 취약 "(2016 · 2025 연속), "공유 비밀값 계산"이 반복. DH와 같은 이산대수 기반인 ElGamal 을 함께 고르게 하는 문항도(2025).

3.2 RSA를 이용한 키 전송

① A: 세션키 Ks를 난수로 생성
② A → B : E_PUb[Ks]          (B의 공개키로 암호화)
③ B: D_PRb[E_PUb[Ks]] = Ks   (B의 개인키로 복호화)
④ 이후 A, B는 Ks로 대칭키 암호 통신

🔍 읽는 포인트 : 세션키는 수신자(B)의 공개키 로 암호화합니다. 송신자 개인키로 암호화하면 누구나 송신자 공개키로 풀 수 있어 비밀이 아닙니다. 이 구조가 하이브리드 암호(디지털 봉투) 이며 PGP · TLS의 기본입니다(19번 노트).

⚠️ 공개키 전송에도 같은 질문이 남습니다. "B의 공개키라고 받은 것이 정말 B의 것인가?" 이 질문에 답하는 것이 5절의 PKI와 인증서 입니다.

📝 기출 포인트 — "RSA 기반 세션키 공유 절차에서 틀린 것"(2022 · 2024): 어느 단계에서 누구의 어떤 키 를 쓰는지가 함정.


4. 전자서명 ⭐⭐

4.1 정의와 원리

전자서명 (디지털서명) — [암호 기술]인데, [ 송신자의 개인키로 메시지(의 해시값)에 서명하고 누구나 송신자의 공개키로 검증한다 ]는 점에서 송신자와 수신자가 같은 키를 쓰는 MAC과 구별된다. 서명키를 송신자만 가지므로 부인방지 가 됩니다.

[서명]  메시지 M → 해시 H(M) → 송신자 개인키로 서명 S → (M, S) 전송
[검증]  받은 M → 해시 H(M)   ┐
        받은 S → 송신자 공개키로 검증 → 두 값이 같으면 유효
하고 싶은 것쓰는 키얻는 것
서명 생성송신자 개인키인증 · 무결성 · 부인방지
서명 검증송신자 공개키
기밀성 암호화수신자 공개키기밀성
기밀성 복호화수신자 개인키

📝 기출 포인트 — "서명 생성 · 검증에 쓰는 키" 가 2015, 2024, 2025년에 연속 출제(2025년에만 3문항). "서명 = 송신자 개인키, 검증 = 송신자 공개키, 기밀성 = 수신자 공개키" 세 줄을 외우세요. 해시를 먼저 쓰는 이유는 긴 메시지를 서명하면 느리기 때문 (공개키 연산이 느림)입니다.

4.2 전자서명의 다섯 요건

요건뜻무엇으로 보장되나
위조 불가 (Unforgeable)서명자만 서명을 만들 수 있다개인키는 서명자만 가짐
서명자 인증 (User Authentication)서명을 보고 누가 서명했는지 확인할 수 있다서명자 공개키로 검증
부인 방지 (Non-repudiation)서명자가 나중에 서명 사실을 부인할 수 없다개인키는 본인만 가짐
변경 불가 (Unalterable)서명된 문서 내용을 바꿀 수 없다해시값이 달라져 검증 실패
재사용 불가 (Not Reusable)한 문서의 서명을 다른 문서에 옮겨 쓸 수 없다서명이 문서의 해시에 묶임

⚠️ 반례 — 기밀성은 전자서명의 요건이 아닙니다. 서명만 한 메시지는 누구나 읽을 수 있습니다. 기밀성이 필요하면 따로 암호화합니다(2022 출제).

4.3 서명 방식

방식기반 문제특징
RSA 서명소인수분해암호화와 서명을 모두 할 수 있음. 현대 권고 패딩은 RSA-PSS
ElGamal 서명이산대수같은 메시지도 매번 다른 서명(난수 사용), 서명 길이가 김
Schnorr 서명이산대수ElGamal 계열을 짧고 효율적으로 개선
DSA / DSS이산대수미국 NIST 전자서명 표준 (DSS)의 알고리즘. 서명 전용 (암호화 불가)
ECDSA타원곡선 이산대수DSA의 타원곡선 버전. 짧은 키로 같은 안전성
KCDSA / EC-KCDSA이산대수 / 타원곡선국내 표준 전자서명

⚠️ 반례 — A5 · RC4는 스트림 암호, AES · SEED는 블록 암호로 전자서명 알고리즘이 아닙니다 (2019 출제).

4.4 특수 서명 — 은닉 · 이중 · 그룹 ⭐

서명정의 (유 + 종차)쓰임
은닉서명 (Blind Signature)[전자서명]인데, [ 서명자가 메시지 내용을 보지 못한 채 서명한다 ]는 점에서 내용을 보고 서명하는 일반 서명과 구별된다전자화폐 · 전자투표의 익명성 (은행이 지폐 일련번호를 모르고 서명)
이중서명 (Dual Signature)[전자서명]인데, [ 두 정보를 각각 해시해 연결한 뒤 한 번 서명해, 검증자가 자기에게 필요한 정보만 보고도 두 정보의 연결을 확인한다 ]는 점에서 하나의 메시지에 서명하는 일반 서명과 구별된다SET : 상점은 주문정보만, 은행은 지불정보만 봄
그룹서명 (Group Signature)[전자서명]인데, [ 검증자는 그룹 구성원 누군가가 서명했다는 것만 알고 누구인지는 모르며, 분쟁 시 관리자만 서명자를 밝힐 수 있다 ]는 점에서 서명자가 드러나는 일반 서명과 구별된다익명 내부 고발, 익명 인증

그 밖에 서명자의 협조가 있어야만 검증되는 부인방지 서명 (Undeniable), 원서명자 대신 위임받은 자 가 서명하는 대리 서명 (Proxy)이 있습니다.

이중서명의 구조 (SET)

PI(지불정보) → H(PI) = PIMD ┐
                             ├─ 연결 → H(PIMD ‖ OIMD) → 고객 개인키로 서명 = 이중서명
OI(주문정보) → H(OI) = OIMD ┘
상점: OI + PIMD + 이중서명 로 검증 (지불정보 내용은 모름)
은행: PI + OIMD + 이중서명 로 검증 (주문정보 내용은 모름)

🔍 읽는 포인트 : 상대 정보는 해시값으로만 받으므로 내용은 몰라도 "이 주문과 이 지불이 한 묶음"임은 확인됩니다. 이중서명의 목적은 정보 분리 · 프라이버시 이며, 서명 주체는 고객 입니다.

📝 기출 포인트 — 은닉서명(5회) : "서명자에게 내용을 숨기고 받는 서명", RSA 기반 은닉서명 원리. 이중서명 : "SET에서 주문 · 지불 정보 분리", "검증 주체 · 특징 오류". 은닉 = 서명자가 모름, 이중 = 검증자가 일부만 봄.

앞으로 다시 만납니다 — SET · 전자화폐에서 이중서명 · 은닉서명이 실제로 어디에 들어가는지는 15번 노트, 전자서명이 메일 보안에 쓰이는 방식(PGP · S/MIME)은 12번 노트.


5. 인증서와 PKI ⭐⭐

5.1 PKI와 공개키 인증서

공개키 인증서 — [전자 문서]인데, [ 신뢰할 수 있는 인증기관(CA)이 "이 공개키는 이 사람의 것"이라고 자기 개인키로 서명해 보증한다 ]는 점에서 공개키만 덩그러니 주는 방식과 구별된다. 3.2절 끝의 질문("이 공개키가 정말 B의 것인가?")에 대한 답입니다.

PKI (공개키 기반구조) — [보안 기반구조]인데, [ 인증서의 발급 · 배포 · 갱신 · 폐지와 상태 확인까지 관리하는 기관 · 정책 · 절차 · 소프트웨어의 묶음 ]이라는 점에서 단일 암호 알고리즘과 구별된다.

구성 요소역할
CA (인증기관)인증서 발급 · 폐지 , CRL 발행 , 인증서에 CA 개인키로 서명
RA (등록기관)신청자의 신원 확인 과 등록 대행. 인증서를 직접 발급하지는 않음
저장소 · 디렉터리인증서와 CRL을 게시 · 배포 (주로 LDAP )
사용자 (End Entity)인증서를 받아 쓰고, 상대 인증서를 검증
(검증 서버, VA)OCSP 응답 등 인증서 상태 확인 서비스

계층형 PKI의 기관 이름도 나옵니다: PAA (정책 승인 기관, 최상위 정책 수립 · 하위 기관 인증) → PCA (정책 인증 기관, 하위 CA 정책 · 인증) → CA → RA → 사용자. 가장 위의 CA를 Root CA 라고 하며, Root CA의 인증서는 자기가 자기에게 서명한 자체 서명 인증서 입니다.

📝 기출 포인트 — "PKI 구성요소의 역할"(CA는 발급 · CRL, RA는 신원 확인)이 2014 · 2015 · 2022 · 2024 · 2025년 반복. "PKI 구성과 무관한 것 "을 고르는 유형도.

5.2 PKI 구조 — 계층 · 네트워크 · 혼합

구조신뢰 관계장점단점
계층형 (Hierarchical)하나의 Root CA 아래 트리인증 경로가 단순 · 짧음, 정책 일관Root CA가 단일 실패 지점 (Root 키 유출 시 전체 붕괴)
네트워크형 · 메시형 (Mesh)CA끼리 상호 인증(Cross Certification)한 CA가 뚫려도 영향 국한, 유연인증 경로가 복잡 · 길어짐
혼합형 · 브리지형 (Hybrid, Bridge CA)각 조직은 계층형, 조직 간은 브리지 CA 를 통해 연결두 구조의 장점 절충브리지 CA 관리 부담

5.3 X.509 인증서 구조 ⭐

X.509 — [인증서 표준 형식]인데, [ ITU-T가 정한 공개키 인증서의 필드 구조 ]라는 점에서 다른 신뢰 모델(예: PGP의 사용자 간 신뢰망)과 구별된다. 현재 쓰는 것은 버전 3 입니다.

필드도입 버전내용
버전 (Version)v1v1 · v2 · v3
일련번호 (Serial Number)v1CA가 부여하는 고유 번호 — CRL에서 폐지 인증서를 가리킬 때 사용
서명 알고리즘 (Signature Algorithm ID)v1CA가 이 인증서에 서명한 알고리즘 (예: sha256WithRSAEncryption)
발급자 (Issuer)v1발급한 CA의 이름
유효기간 (Validity)v1시작 · 만료 일시
주체 (Subject)v1인증서 소유자 이름
주체 공개키 정보 (Subject Public Key Info)v1소유자의 공개키 와 알고리즘 — 인증서의 존재 이유
발급자 고유 ID · 주체 고유 IDv2이름이 재사용될 때 구별용
확장 (Extensions)v3아래 표
CA의 서명—위 내용 전체에 대한 CA의 전자서명

⚠️ 반례 — 인증서에는 소유자의 개인키가 들어 있지 않습니다. "인증서에 포함되는 항목"에서 개인키 · 비밀번호는 오답입니다.

v3 확장 분류대표 필드
키 · 정책 정보기관 키 식별자, 주체 키 식별자, 키 용도 (Key Usage — 서명용 · 암호화용 등), 인증서 정책
주체 · 발급자 속성주체 대체 이름 (Subject Alternative Name — 이메일 · 도메인 · IP), 발급자 대체 이름
인증 경로 제약기본 제약 (Basic Constraints — 이 인증서가 CA인가), 이름 제약, 정책 제약
기타 자주 보이는 것CRL 배포 지점 (CRL Distribution Points), 기관 정보 접근(AIA — OCSP 서버 주소)

📝 기출 포인트 — "인증서 포함 항목"(4회 이상), "X.509 버전별 도입 항목"(v2 = 고유 ID, v3 = 확장), "v3 확장 영역 분류와 필수 항목은 공개키 "(2025).

5.4 인증서 폐지 — CRL과 OCSP ⭐⭐

인증서는 유효기간 전이라도 폐지 될 수 있습니다.

폐지 사유 ⭕폐지 사유가 아닌 것 ❌
개인키 손상 · 유출, CA 키 손상, 소속 · 정보 변경, 상위 인증서로 대체, 운영 중단, 가입자의 폐지 신청, 일시 정지(Hold)유효기간 만료 — 만료는 폐지가 아니라 자연 소멸. CRL에 올리지 않음
CRL (Certificate Revocation List)OCSP (Online Certificate Status Protocol)
정의[인증서 상태 확인 방식]인데, [ CA가 폐지된 인증서 일련번호 목록을 주기적으로 서명해 게시한다 ][인증서 상태 확인 방식]인데, [ 클라이언트가 특정 인증서 하나의 상태를 서버에 실시간으로 묻는다 ]
실시간성❌ 다음 발행 전까지 공백 이 생김⭕ 실시간
부하목록이 커질수록 내려받기 부담요청당 응답이 작음, 대신 서버에 질의 집중
내용폐지 인증서 일련번호 , 폐지 일시, 사유 코드(확장), 이번 · 다음 발행일, CA 서명상태값 good · revoked · unknown , CA(또는 위임받은 응답자) 서명
표준X.509 (v2 CRL)IETF RFC 6960 (구 RFC 2560), 주로 HTTP로 전송
  • CRL의 확장에는 CRL 번호, 델타 CRL 지시자 등 CRL 전체 에 대한 것과, 사유 코드(Reason Code) · 무효 일자처럼 각 폐지 항목 에 대한 것이 있습니다.
  • 델타 CRL 은 직전 전체 CRL 이후 바뀐 것만 담아 크기 문제를 줄입니다.
  • OCSP와 함께 나오는 위임 검증 서비스로 DPV (경로 검증 위임)와 DPD (경로 탐색 위임)가 있습니다.

📝 기출 포인트 — G1.4에서 OCSP(7회) , CRL(5회) 가 1 · 2위. "CRL 없이 실시간 으로 상태 확인"(→ OCSP), "CRL을 보완하는 실시간 검증", "OCSP 응답 상태값", " CRL에 포함되는 것 = 폐지 인증서 일련번호 ", " 폐지 사유가 아닌 것 = 만료 ", "CRL 발행 주체 = CA".

5.5 브라우저 인증서 경고 · WPKI · 전자서명법

브라우저가 인증서 경고를 띄우는 대표 원인은 유효기간 만료 , 도메인 이름 불일치 (주체 대체 이름에 없는 주소), 신뢰하지 않는 발급자 (자체 서명 등), 폐지됨 입니다. 브라우저 주소창의 자물쇠를 눌러 인증서의 유효기간 · 발급자 · 주체를 확인합니다.

WPKI — [PKI]인데, [ 무선 단말의 낮은 성능 · 대역폭에 맞춰 인증서와 검증을 가볍게 한다 ]는 점에서 유선 PKI와 구별된다. 폐지 확인 부담을 줄이려 유효기간이 짧은 인증서(Short-lived Certificate) 를 씁니다. 최근에는 오래된 주제로 분류되지만 2025년에도 나왔습니다.

전자서명법 개정 — 현행: 2020년 12월 10일 시행 전부개정으로 공인인증서 · 공인인증기관 제도가 폐지 되고, 모든 전자서명이 동등하게 경쟁하는 전자서명인증사업자 평가 · 인정 제도 로 바뀌었습니다. 기존 공인인증서는 "공동인증서"라는 이름으로 계속 쓰입니다. / 개정 전: 공인인증기관이 발급한 공인인증서에 우월한 법적 효력(시험 문제은행에 "공인인증서" 문항이 남아 있을 수 있음). 시험 전 국가법령정보센터에서 현행 조문을 확인하세요.

앞으로 다시 만납니다 — 전자서명법의 용어 정의와 개정 전후 비교는 23번 노트.


6. 실기 연결

관련 수행준거 : 1-3-6 " 전자서명, 공개키 기반 구조 구성과 보안 특성 을 이해할 수 있다", 1-2-4 "SSL/TLS, IPSec 프로토콜의 동작절차와 취약점"(인증서 · 키 교환이 그 안에 들어감).

묻는 방식답안 핵심어
DH 키 교환 과정과 취약점공개값 g^a, g^b 교환 → g^ab 공유, 이산대수, 인증 부재로 중간자 공격 , 서명 · 인증서로 보완
CRL과 OCSP 비교주기적 목록 vs 실시간 질의, 일련번호, good/revoked/unknown
전자서명 생성 · 검증 절차해시 → 송신자 개인키 서명 → 송신자 공개키 검증 → 해시 비교
이중서명의 목적주문정보 · 지불정보 분리, 상점 · 은행이 필요한 정보만 확인

인증서 점검 예시

$ openssl x509 -in server.crt -noout -text
    Version: 3 (0x2)
    Serial Number: 04:a1:...
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=KR, O=Example CA, CN=Example CA R1
    Validity
        Not Before: Jan  1 00:00:00 2026 GMT
        Not After : Jan  1 23:59:59 2027 GMT
    Subject: CN=www.example.co.kr
    Subject Public Key Info:  Public Key Algorithm: rsaEncryption  Public-Key: (2048 bit)
    X509v3 extensions:
        X509v3 Key Usage: critical  Digital Signature, Key Encipherment
        X509v3 Subject Alternative Name:  DNS:www.example.co.kr, DNS:example.co.kr
        X509v3 CRL Distribution Points:  URI:http://crl.example.co.kr/r1.crl
        Authority Information Access:  OCSP - URI:http://ocsp.example.co.kr

🔍 읽는 포인트 : Version: 3 → X.509 v3. Not After → 만료일(지났으면 브라우저 경고). Subject Alternative Name → 접속 도메인이 여기에 있어야 함. CRL Distribution Points와 OCSP - URI → 폐지 여부를 확인할 두 경로 . 서명 알고리즘이 SHA-1 · MD5 계열이거나 공개키가 2048비트 미만이면 약한 인증서로 판단합니다(19 · 20번 노트).

앞으로 다시 만납니다 — TLS 핸드셰이크에서 인증서 검증과 키 교환이 어떻게 맞물리는지는 10번 노트, 실기 점검 서술은 25번 노트.


7. 확인 문제

1. 사용자 50명이 서로 1:1로 대칭키 암호 통신을 하려 할 때 필요한 비밀키의 수는? ① 50 ② 100 ③ 1,225 ④ 2,500

2. 대칭키 배송 문제를 해결하는 방법으로 보기 어려운 것은? ① 키 분배 센터(KDC) 이용 ② Diffie-Hellman 키 합의 ③ 수신자 공개키로 세션키 암호화 ④ 송신자 개인키로 메시지에 전자서명

3. Diffie-Hellman 키 교환에서 p = 11, g = 2, A의 비밀값 a = 3, B의 비밀값 b = 4일 때 두 사람이 공유하는 키는? ① 3 ② 4 ③ 5 ④ 9

4. Diffie-Hellman 키 교환에 대한 설명으로 옳지 않은 것은? ① 이산대수 문제의 어려움에 안전성을 둔다 ② 공개된 값만 주고받아 공유 비밀값을 만든다 ③ 상대방을 인증하는 기능이 내장되어 있어 중간자 공격에 안전하다 ④ 타원곡선 위에서 동작하는 변형(ECDH)이 있다

5. A가 B에게 문서를 보내면서 B가 "이 문서는 A가 작성했고 바뀌지 않았다"는 것을 확인할 수 있게 하려 한다. A가 서명에 쓰는 키와 B가 검증에 쓰는 키를 순서대로 고르면? ① A의 공개키, A의 개인키 ② A의 개인키, A의 공개키 ③ B의 공개키, B의 개인키 ④ A의 개인키, B의 공개키

6. 전자서명의 요건으로 보기 어려운 것은? ① 위조 불가 ② 부인 방지 ③ 재사용 불가 ④ 메시지 기밀성

7. 인증서 상태 확인에 대한 설명으로 옳은 것은? ① CRL은 클라이언트가 인증서 하나의 상태를 실시간으로 질의하는 프로토콜이다 ② OCSP 응답의 상태값에는 good, revoked, unknown이 있다 ③ 유효기간이 만료된 인증서는 즉시 CRL에 등록된다 ④ CRL에는 폐지된 인증서 소유자의 개인키가 포함된다

8. 전자화폐에서 은행이 화폐 내용(일련번호)을 모른 채 서명하여 사용자의 익명성을 보장하는 서명 방식은? ① 이중서명 ② 은닉서명 ③ 그룹서명 ④ 부인방지 서명

정답과 해설

#정답해설 (판별 축)
1③50 × 49 / 2 = 1,225. ②는 공개키 방식의 키 수(2n)
2④전자서명은 출처 · 무결성 증명이지 키를 비밀리에 전달하지 않음 . ①은 분배, ②는 합의, ③은 공개키 전송(축 2)
3②YA = 2^3 mod 11 = 8 , YB = 2^4 mod 11 = 5 . A: 5^3 mod 11 = 125 mod 11 = 4 , B: 8^4 mod 11 = 4096 mod 11 = 4 . ③ 5는 B의 공개값 이지 공유키가 아님
4③DH는 인증이 없어서 중간자 공격에 취약. 서명 · 인증서로 보완
5②서명 = 송신자 개인키 , 검증 = 송신자 공개키 (축 3). ④는 서명과 기밀성 키를 섞은 함정
6④서명은 기밀성을 주지 않음. 필요하면 수신자 공개키로 따로 암호화
7②①은 OCSP 설명(축 4 반대쪽), ③ 만료는 폐지 사유가 아님, ④ 인증서 · CRL 어디에도 개인키는 없음
8②서명자가 내용을 모름 = 은닉(축 5). 이중서명은 검증자 가 일부만 보는 것

💡 DH 계산 문제는 A 쪽 키와 B 쪽 키를 둘 다 계산해 같은지 확인하면 계산 실수를 스스로 잡을 수 있습니다.


부록 A. 스스로 확인하기

#질문답이 있는 곳
1n명 대칭키 통신에 필요한 키 수와 공개키 방식의 키 수는?1.1
2키 배송 문제의 해결책 네 가지와, 해결책이 아닌 것의 예는?1.2
3KDC가 쓰는 암호는 대칭키인가 공개키인가? 약점은?2.1
4Needham-Schroeder의 취약점과 Kerberos의 보완책은?2.2
5DH의 기반 문제와 중간자 공격에 취약한 이유는?3.1
6RSA 키 전송에서 세션키는 누구의 어떤 키로 암호화하나?3.2
7서명 생성 · 검증 · 기밀성 암호화에 각각 쓰는 키는?4.1
8전자서명 다섯 요건과, 요건이 아닌 것은?4.2
9은닉서명 · 이중서명 · 그룹서명은 각각 누가 무엇을 모르나?4.4
10CA와 RA의 역할 차이는?5.1
11X.509 v2와 v3에서 추가된 것은? 필수 항목인 공개키는 어느 필드?5.3
12CRL과 OCSP의 차이, OCSP 상태값 세 가지는?5.4
13인증서 폐지 사유가 아닌 것은?5.4
142020년 전자서명법 개정의 핵심은?5.5

부록 B. 자주 하는 실수 · 함정

실수바로잡기
"전자서명으로 키 배송 문제를 해결"❌ 서명은 키를 비밀리에 전달하지 않음
"KDC는 공개키로 세션키를 나눠 준다"❌ KDC는 대칭키(마스터키) 기반
"DH는 상호 인증까지 해 준다"❌ 인증 없음 → 중간자 공격 취약
"서명은 수신자 공개키로 검증"❌ 검증은 송신자 공개키
"전자서명은 기밀성을 보장"❌ 기밀성은 요건이 아님
"이중서명은 두 사람이 서명"❌ 한 사람(고객) 이 두 정보를 묶어 한 번 서명
"은닉서명 = 서명자를 숨기는 서명"⚠️ 은닉서명은 메시지 내용 을 서명자에게 숨김. 서명자를 숨기는 것은 그룹서명
"RA가 인증서를 발급한다"❌ RA는 신원 확인 · 등록 , 발급은 CA
"만료된 인증서는 CRL에 올라간다"❌ 만료는 폐지가 아님
"공인인증서는 지금도 법적으로 우월한 효력"⚠️ 2020.12.10 개정으로 폐지 . 단, 문제은행에 옛 기준 문항이 남아 있을 수 있음

부록 C. AI · NotebookLM 복습 프롬프트

이 18번 노트만 근거로 4지선다 8문제를 내줘. 노트 밖 지식은 쓰지 마.
"n(n-1)/2 계산", "DH 계산과 중간자 공격", "서명·검증·암호화에 쓰는 키",
"전자서명 요건", "은닉·이중서명 구분", "CRL과 OCSP 비교"는 반드시 포함해줘.
내가 답하면 채점하고, 틀린 보기가 왜 틀렸는지 노트의 판별 축과 절 번호로 설명해줘.