페이지 목차
이 페이지에서 검색
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. 디지털서명 응용 원리 및 구조(은닉서명, 이중서명 등)
이 노트를 다 읽으면
- 대칭키의 키 배송 문제 를 n(n-1)/2로 설명하고, 해결책 네 가지(사전 분배 · KDC · 키 합의 · 공개키)와 해결책이 아닌 것을 구별할 수 있다.
- Diffie-Hellman 키 교환을 직접 계산하고, 왜 중간자 공격 에 취약한지 말할 수 있다.
- KDC · Needham-Schroeder 의 동작과 약점을 설명할 수 있다.
- 전자서명의 다섯 요건 과 서명 · 검증에 쓰는 키 를 헷갈리지 않고 고를 수 있다.
- 은닉서명 · 이중서명 · 그룹서명 이 각각 무엇을 숨기거나 나누는지 말할 수 있다.
- X.509 v3 인증서의 기본 필드와 확장 필드, PKI 구성 요소 (CA · RA · 저장소 · 사용자)의 역할을 댈 수 있다.
- 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 23 | 8 |
| B의 공개값 | 5^15 mod 23 | 19 |
| A가 계산한 키 | 19^6 mod 23 | 2 |
| B가 계산한 키 | 8^15 mod 23 | 2 |
🔍 읽는 포인트 : 도청자는 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) | v1 | v1 · v2 · v3 |
| 일련번호 (Serial Number) | v1 | CA가 부여하는 고유 번호 — CRL에서 폐지 인증서를 가리킬 때 사용 |
| 서명 알고리즘 (Signature Algorithm ID) | v1 | CA가 이 인증서에 서명한 알고리즘 (예: sha256WithRSAEncryption) |
| 발급자 (Issuer) | v1 | 발급한 CA의 이름 |
| 유효기간 (Validity) | v1 | 시작 · 만료 일시 |
| 주체 (Subject) | v1 | 인증서 소유자 이름 |
| 주체 공개키 정보 (Subject Public Key Info) | v1 | 소유자의 공개키 와 알고리즘 — 인증서의 존재 이유 |
| 발급자 고유 ID · 주체 고유 ID | v2 | 이름이 재사용될 때 구별용 |
| 확장 (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. 스스로 확인하기
| # | 질문 | 답이 있는 곳 |
|---|---|---|
| 1 | n명 대칭키 통신에 필요한 키 수와 공개키 방식의 키 수는? | 1.1 |
| 2 | 키 배송 문제의 해결책 네 가지와, 해결책이 아닌 것의 예는? | 1.2 |
| 3 | KDC가 쓰는 암호는 대칭키인가 공개키인가? 약점은? | 2.1 |
| 4 | Needham-Schroeder의 취약점과 Kerberos의 보완책은? | 2.2 |
| 5 | DH의 기반 문제와 중간자 공격에 취약한 이유는? | 3.1 |
| 6 | RSA 키 전송에서 세션키는 누구의 어떤 키로 암호화하나? | 3.2 |
| 7 | 서명 생성 · 검증 · 기밀성 암호화에 각각 쓰는 키는? | 4.1 |
| 8 | 전자서명 다섯 요건과, 요건이 아닌 것은? | 4.2 |
| 9 | 은닉서명 · 이중서명 · 그룹서명은 각각 누가 무엇을 모르나? | 4.4 |
| 10 | CA와 RA의 역할 차이는? | 5.1 |
| 11 | X.509 v2와 v3에서 추가된 것은? 필수 항목인 공개키는 어느 필드? | 5.3 |
| 12 | CRL과 OCSP의 차이, OCSP 상태값 세 가지는? | 5.4 |
| 13 | 인증서 폐지 사유가 아닌 것은? | 5.4 |
| 14 | 2020년 전자서명법 개정의 핵심은? | 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 비교"는 반드시 포함해줘.
내가 답하면 채점하고, 틀린 보기가 왜 틀렸는지 노트의 판별 축과 절 번호로 설명해줘.
LangTailor