[서론] 왜 이렇게 헷갈리는가 — 문제 공감 & 해결책 요약
정보보안기사 공부하다 보면 RSA, AES, 전자서명, PKI, SET, Kerberos가 전부 “암호화”라는 말로 뭉뚱그려져 보여서 머리가 꼬이기 쉽습니다.
핵심 원인은 같은 ‘키’가 아니라, 같은 ‘단어(암호화)’를 서로 다른 목적에 써서입니다.
해결책은 단 하나예요.
✅ 목적부터 분리(기밀성 vs 진정성) → 그 목적에 맞는 키를 고르는 방식으로 정리하면, 문제 유형이 바뀌어도 흔들리지 않습니다.
[본론] 목적 기준으로 “완전히 분리”해서 정리
0) 먼저 ‘키의 종류’부터 확정 (혼동 방지 1순위)
| 구분 | 예시 | 핵심 특징 | 시험 표현 |
|---|---|---|---|
| 대칭키 | AES, SEED | 같은 키 1개로 암·복호 | 공유 비밀키, 세션키 |
| 비대칭키 | RSA, ECC | 공개키+개인키 한 쌍(pair) | 키 쌍(Key Pair) |
0-1) 비대칭키가 “4개처럼 보이는” 이유: 키쌍 2세트(송신자 1쌍 + 수신자 1쌍)
비대칭키는 주체(사람/서버/계정)마다 공개키+개인키 한 쌍으로 존재합니다.
- 송신자 키쌍: (송신자 공개키 Pub_S, 송신자 개인키 Priv_S)
- 수신자 키쌍: (수신자 공개키 Pub_R, 수신자 개인키 Priv_R)
따라서 통신에 등장하는 비대칭키 요소가 Priv_S, Pub_S, Priv_R, Pub_R처럼 4개로 보이지만, 실제 구조는 키쌍 2세트입니다.
개인키(Priv)는 절대 외부로 나가지 않고, 공개키(Pub)는 인증서(PKI) 등을 통해 배포되어 “검증/암호화”에 사용된다고 이해하면 안전합니다.
➡️ 결론: 공개키/개인키는 둘 다 ‘비대칭키의 구성요소’입니다. “공개키는 대칭키냐?” 같은 질문이 나오는 순간, 개념이 섞인 상태예요.
✅ CASE A — 기밀성(비밀 유지): “남이 못 보게”
원칙(시험에 그대로 쓰는 문장)
👉 수신자 공개키로 암호화 → 수신자 개인키로 복호화
(“너만 열어보라는 봉투”)
| 단계 | 누가 | 무엇으로 | 왜 |
|---|---|---|---|
| 암호화 | 송신자 | 수신자 공개키 | 수신자만 열게 |
| 복호화 | 수신자 | 수신자 개인키 | 본인만 가능 |
실무형(하이브리드): RSA + AES가 같이 나오는 이유
- 큰 데이터는 RSA로 직접 암호화하면 느립니다.
- 그래서 현실은 거의 항상:
- 데이터는 AES(빠름)
- AES 세션키(K)는 수신자 공개키(RSA)로 보호(키 분배/보호)
📦 전송 패키지(기밀성 중심)
- Enc_AES(M) : AES로 암호화된 메시지
- Enc_RSA(K) : 수신자 공개키로 암호화된 세션키 K
📌 시험 트리거(기밀성)
- “비밀”, “남이 보면 안 됨”, “수신자만 복호화”
→ 수신자 공개키가 정답 방향
✅ CASE B — 진정성/무결성/부인방지: “내가 보냈다는 증거”
원칙(시험에 그대로 쓰는 문장)
👉 송신자 개인키로 서명 → 송신자 공개키로 검증
(“내 도장”)
| 단계 | 누가 | 무엇으로 | 왜 |
|---|---|---|---|
| 서명 생성 | 송신자 | 송신자 개인키 | 위조/부인 방지 |
| 서명 검증 | 누구나(수신자 포함) | 송신자 공개키 | 발신자 확인 |
실제 흐름(전자서명은 ‘메시지 전체’를 암호화하는 게 아님)
- 메시지 M → Hash(M)
- Hash(M) → 송신자 개인키로 서명(Sign)
- 수신자는 송신자 공개키로 서명 검증 + 본인이 다시 Hash(M) 비교
📌 시험 트리거(진정성/부인방지)
- “위조”, “서명”, “부인방지”, “무결성 검증”
→ 송신자 개인키가 정답 방향
✅ CASE C — 현실 시스템(하이브리드형): 기밀성 + 진정성 “둘 다”
대부분의 보안 프로토콜은 A와 B를 합칩니다.
| 구성요소 | 역할 | 키 |
|---|---|---|
| AES | 데이터 암호화(속도) | 세션키 K(대칭키) |
| RSA(수신자 공개키) | 세션키 K 보호(기밀성) | 수신자 공개키 |
| RSA(송신자 개인키) | 전자서명(진정성) | 송신자 개인키 |
📦 최종 전송 패키지(가장 자주 나오는 형태)
- Enc_AES(M)
- Enc_RSA_receiver(K)
- Sign_sender(Hash(M))
하이브리드형에서 등장하는 비대칭키 4개 중 실제 사용처
- 기밀성(키 보호): Pub_R → Priv_R (수신자 키쌍)
- 진정성(서명): Priv_S → Pub_S (송신자 키쌍)
즉, 하이브리드형은 “수신자 키쌍은 기밀성”, “송신자 키쌍은 진정성” 담당으로 역할 분담이 됩니다.
✅ “송신자 대칭키/수신자 대칭키”가 위험한 이유 (시험 함정 방지)
현실에서 대칭키는 보통 송·수신자가 공유하는 ‘하나의 세션키 K’입니다.
- ❌ 송신자 대칭키 / 수신자 대칭키 (서로 다른 2개처럼 오해 유발)
- ✅ 공유 세션키 K (대칭키 1개)
➡️ 시험 풀이에서도 “대칭키=공유 세션키”로 고정하는 게 안전합니다.
[시스템별 위치 정리표] PKI/SET/Kerberos를 ‘목적’으로 재배치
| 기술 | 핵심 목적 | 키/구조 포인트 | 자주 헷갈리는 지점 |
|---|---|---|---|
| PKI | 신뢰(누구 키가 맞는지) | 인증서, CA, 공개키 배포/검증 | PKI 자체가 “암호”가 아니라 신뢰 인프라 |
| 전자서명 | 진정성/부인방지 | 송신자 개인키로 서명 | “암호화”랑 혼동 |
| 일반 암호화(기밀성) | 비밀 유지 | 수신자 공개키(또는 AES+RSA 하이브리드) | 서명과 반대로 키가 움직임 |
| SET(전자상거래) | 결제 보안 | 암호화+서명 혼합(기밀성+진정성) | “결제=서명+암호화 세트”로 보면 편함 |
| Kerberos | 인증/SSO | 대칭키 중심, 티켓 기반(TGT/서비스 티켓) | “공개키로 암호화?”로 접근하면 꼬임 |
[시험에서 바로 쓰는 판별법] 3단 공식(거의 모든 문제에 통함)
비대칭키는 송신자 키쌍(Pub_S/Priv_S)과 수신자 키쌍(Pub_R/Priv_R) 두 세트가 있다는 것부터 인지합니다. 그 다음 목적을 읽으면 키 선택이 자동으로 따라옵니다.
- “몰래 보지 마(기밀성)” → 수신자 공개키
- “내가 보냈다(진정성/부인방지)” → 송신자 개인키
- “대용량/속도” → 대칭키(AES 세션키)
[암기법] 기존 구호를 시험형으로 교정: “기수–진송–속대”
헷갈림이 줄어드는 형태로 재설계하면 이렇습니다.
- 기수: 기밀성 = 수신자 공개키
- 진송: 진정성 = 송신자 개인키
- 속대: 속도 = 대칭키(AES 세션키)
👉 이 3개만 머리에 고정해두면, SET/PKI/TLS류 문제도 목적만 읽고 풀 수 있어요.
[실무 팁] 실제 운영에서 자주 만나는 “키 사고” 포인트
- 인증서 검증 실패는 “암호 알고리즘 문제”가 아니라 신뢰 체인(CA/기간/도메인) 문제인 경우가 많습니다. (PKI 관점)
- “서명 OK인데 내용이 안 보임”이면
→ 서명(진정성)과 암호화(기밀성)는 별개라서 동시에 켜져 있을 수 있습니다. - 대칭키는 “누구 키냐”가 아니라
→ 세션마다 잠깐 쓰고 버리는 공유 키(K)로 보는 게 실무 감각에 맞습니다.
[결론] 3줄 요약
- 비대칭키는 **주체당 1쌍(공개키+개인키)**이고, 통신에서는 송신자 1쌍 + 수신자 1쌍이라서 4개처럼 보입니다.
- 기밀성은 수신자 공개키→수신자 개인키, 진정성은 송신자 개인키→송신자 공개키로 목적 기준 분리하세요.
- 현실 시스템은 AES(데이터) + RSA(세션키 보호) + 전자서명(검증) 하이브리드형이 기본입니다.