19장. 전자 메일 보안
학습 목표
- 인터넷 메일 아키텍처의 핵심 구성 요소를 요약한다.
- SMTP, POP3, IMAP의 기본 기능을 설명한다.
- MIME의 필요성과 핵심 요소를 설명한다.
- S/MIME의 기능과 대응하는 보안 위협을 이해한다.
- STARTTLS, DANE, SPF, DKIM, DMARC의 기본 메커니즘과 역할을 이해한다.
19.1 인터넷 메일 아키텍처
RFC 5598 기반. 사용자 세계(MUA)와 전송 세계(MHS)로 구분된다.
핵심 구성 요소
| 구성 요소 | 역할 |
|---|---|
| MUA (Message User Agent) | 사용자 대리인. 메시지 작성·표시. 이메일 클라이언트 프로그램 |
| MSA (Mail Submission Agent) | MUA로부터 메시지를 접수하고 도메인 정책·표준을 적용 |
| MTA (Message Transfer Agent) | 메시지를 한 홉씩 릴레이. 라우팅 판단 + 추적 정보 추가. SMTP 사용 |
| MDA (Mail Delivery Agent) | MHS에서 MS로 메시지를 전달 |
| MS (Message Store) | 메시지 장기 저장. MUA가 POP3 또는 IMAP으로 접근 |
ADMD (Administrative Management Domain): 이메일 제공자 (부서 릴레이, 기업 릴레이, ISP 등). 각 ADMD는 서로 다른 운영 정책과 신뢰 기반 의사결정을 가진다.
이메일 프로토콜
SMTP (Simple Mail Transfer Protocol): 텍스트 기반 클라이언트-서버 프로토콜. 메시지를 봉투(envelope)에 캡슐화하여 MTA 간 릴레이. TCP 포트 25. 주요 명령: HELO, MAIL FROM, RCPT TO, DATA, QUIT.
RFC 3207. SMTP 에이전트 간 TLS를 추가하여 기밀성·인증을 제공. 단일 포트에서 보안/비보안 연결을 모두 제공할 수 있다. POP3, IMAP에도 유사 메커니즘이 존재한다.
POP3 (Post Office Protocol): 이메일 클라이언트가 서버에서 메일을 다운로드. TCP 포트 110.
IMAP (Internet Message Access Protocol): POP3보다 강력한 인증·기능 제공. TCP 포트 143.
19.2 이메일 형식
RFC 5322
인터넷 텍스트 메시지의 표준 형식. 메시지 = 헤더 (From, To, Subject, Date 등) + 본문 (비정형 텍스트). 빈 줄로 구분.
MIME (Multipurpose Internet Mail Extensions)
SMTP/RFC 5322의 한계(바이너리 전송 불가, 비ASCII 문자 미지원, 크기 제한 등)를 해결.
5가지 MIME 헤더 필드:
| 필드 | 설명 |
|---|---|
| MIME-Version | 1.0 (필수) |
| Content-Type | 본문 데이터의 유형·하위유형 (필수) |
| Content-Transfer-Encoding | 메일 전송을 위한 변환 방식 (필수) |
| Content-ID | MIME 엔티티의 고유 식별자 (선택) |
| Content-Description | 비가독 객체의 텍스트 설명 (선택) |
7가지 콘텐츠 유형:
| 유형 | 하위유형 | 설명 |
|---|---|---|
| text | plain, enriched | 비정형/서식 텍스트 |
| multipart | mixed, parallel, alternative, digest | 독립적 부분들의 조합 |
| message | rfc822, partial, external-body | 캡슐화된 메시지, 분할, 외부 참조 |
| image | jpeg, gif | 이미지 |
| video | mpeg | 비디오 |
| audio | basic | 오디오 |
| application | PostScript, octet-stream | 바이너리 데이터, 앱 데이터 |
전송 인코딩:
| 인코딩 | 설명 |
|---|---|
| 7bit / 8bit / binary | 인코딩 없음 (데이터 특성 표시) |
| quoted-printable | 비안전 문자를 16진수로 표현. 대부분 ASCII인 데이터에 적합 |
| base64 (radix-64) | 3바이트 → 4 ASCII 문자 매핑. 임의 바이너리에 적합 |
| x-token | 벤더/앱 특정 인코딩 |
정규형(Canonical Form): 시스템 간 표준화된 형식. 로컬 형식(native form)과 구별되며, 전송 전 정규형으로 변환 후 전송 인코딩을 적용한다.
19.3 이메일 위협과 종합적 보안
이메일 위협 분류
| 위협 | 영향 | 대응 |
|---|---|---|
| 비인가 MTA에서 발송 (봇넷 등) | 평판 손실, 스팸/피싱 | 도메인 기반 인증, 전자서명 |
| 스푸핑/미등록 도메인 사용 | 평판 손실, 악성 메일 | 도메인 기반 인증 |
| 위조 발신 주소 (피싱) | 민감 정보 유출 | 도메인 기반 인증, 전자서명 |
| 전송 중 메시지 변조 | 정보 유출, 악성 정보 삽입 | TLS 암호화, 종단간 암호화 |
| 트래픽 모니터링/캡처 | 민감 정보 유출 | TLS, 종단간 암호화 |
| UBE (스팸) | 악성 링크 전달 | UBE 대응 기술 |
| DoS/DDoS | 이메일 송수신 불능 | 다중 서버, 클라우드 기반 이메일 |
종합적 보안 프로토콜
| 프로토콜 | 보호 대상 | 기능 |
|---|---|---|
| STARTTLS | 전체 SMTP 메시지 | SMTP over TLS — 인증, 무결성, 기밀성 |
| S/MIME | 메시지 본문 | 전자서명, 암호화 (종단간) |
| DNSSEC | DNS 데이터 | DNS 레코드의 인증·무결성 보호 |
| DANE | TLS 인증서 | CA 시스템의 대안 — DNSSEC 기반 공개키 인증 |
| SPF | 발신자 IP | 도메인 소유자가 허용된 발신 IP를 DNS에 게시 |
| DKIM | 메시지 헤더+본문 | MTA가 도메인 개인키로 서명 → 발신 도메인 인증 + 본문 무결성 |
| DMARC | SPF+DKIM 정책 | SPF/DKIM 정책의 효과를 수신자에게 알리고, 실패 시 처리 방침을 지정 |
19.4 S/MIME
MIME 기반 보안 확장. RSA Data Security 기술에 기반. RFC 5751 (Message Specification), RFC 5652 (CMS) 등.
S/MIME의 4가지 서비스
| 서비스 | 알고리즘 | 동작 |
|---|---|---|
| 인증 (전자서명) | RSA + SHA-256 | SHA-256으로 다이제스트 생성 → 송신자 개인키로 서명 → 메시지에 첨부 |
| 기밀성 (암호화) | AES-128-CBC + RSA | 1회용 세션키로 AES 암호화 → 세션키를 수신자 공개키로 RSA 암호화 |
| 압축 | 미지정 | 저장·전송 공간 절약. 서명 전 또는 후에 적용 가능 |
| 이메일 호환성 | Base64 (Radix-64) | 바이너리 데이터를 인쇄 가능한 ASCII 문자열로 변환 |
서명 먼저: 서명자 신원이 암호화로 은닉됨. 평문과 서명을 함께 저장 가능. 제3자 검증 시 대칭키 불필요. 암호화 먼저: 메시지 내용 노출 없이 서명 검증 가능. 자동 서명 검증에 유용.
S/MIME 콘텐츠 유형
| 유형 | 설명 |
|---|---|
| Data | 내부 MIME 인코딩 메시지 — SignedData/EnvelopedData/CompressedData에 캡슐화 |
| SignedData | 전자서명 적용. SignerInfo 블록에 인증서·알고리즘 ID·암호화된 다이제스트 포함 |
| EnvelopedData | 세션키로 암호화된 콘텐츠 + 수신자별 RecipientInfo (RSA 암호화된 세션키) |
| CompressedData | 데이터 압축 적용 |
Clear Signing: multipart/signed 형식. 메시지 본문은 평문으로 유지하고, 분리된 서명(detached signature)을 별도 파트로 첨부. S/MIME 미지원 수신자도 메시지를 읽을 수 있다.
S/MIME 암호 알고리즘
| 기능 | MUST | SHOULD |
|---|---|---|
| 다이제스트 | SHA-256 | SHA-1, MD5(하위호환) |
| 서명 | RSA + SHA-256 | DSA+SHA-256, RSASSA-PSS+SHA-256, RSA+SHA-1, RSA+MD5 |
| 세션키 암호화 | RSA | RSAES-OAEP, 임시 DH |
| 메시지 암호화 | AES-128-CBC | AES-192/256-CBC, 3DES-CBC |
S/MIME 인증서 처리
X.509 v3 인증서를 사용. 사용자의 책임: 키 생성(DH·DSS 필수, RSA 권장, 768~1024비트), CA에 공개키 등록, 인증서 저장·검색.
향상된 보안 서비스 (RFC 2634)
서명된 수신 확인(signed receipts), 보안 레이블(security labels), 보안 메일링 리스트(MLA를 통한 수신자별 암호화 위임), 서명 인증서(signing certificates).
19.5 PGP (Pretty Good Privacy)
S/MIME과 동일한 기능을 제공하는 대안적 이메일 보안 프로토콜. OpenPGP는 RFC 4880으로 표준화.
S/MIME과의 주요 차이:
| 구분 | S/MIME | PGP |
|---|---|---|
| 키 인증 | X.509 인증서 (CA 발급) → PKIX 체인 | 사용자가 직접 키 생성, 신뢰하는 개인/조직의 서명 → 신뢰의 웹 (Web of Trust) |
| 키 분배 | 메시지에 송신자 공개키 포함 | 별도 획득 필요 (웹사이트, 키 서버). 키 서버에는 누구나 키를 게시 가능 (검증 없음) |
NIST SP 800-177은 공개키 검증의 신뢰도 면에서 S/MIME 사용을 권장한다.
19.6 DNSSEC (DNS Security Extensions)
DNS 데이터의 출처 인증과 무결성 검증을 제공한다.
DNSSEC 동작 원리
DNS 존 관리자가 모든 RRset(동일 라벨·클래스·유형의 RR 집합)에 전자서명하고, 서명과 공개키를 DNS에 게시한다. 클라이언트는 서명을 검증하여 데이터의 진정성을 확인한다.
신뢰는 루트 존에서 시작하여 부모가 자식의 공개키를 서명하는 방식으로 신뢰 체인을 형성한다.
DNSSEC 리소스 레코드
| RR 유형 | 설명 |
|---|---|
| DNSKEY | 공개키를 포함 |
| RRSIG | RRset에 대한 전자서명 |
| DS (Delegation Signer) | 존 간 키 서명·인증 체인 구축 |
| NSEC | 존재하지 않는 도메인/레코드 유형의 인증된 부재 증명 |
19.7 DANE (DNS-Based Authentication of Named Entities)
RFC 6698. CA 시스템의 취약점을 극복하기 위해, DNSSEC 기반으로 TLS 인증서를 DNS 이름에 바인딩한다.
TLSA 리소스 레코드
도메인에 대한 인증서 정보를 DNS에 게시. 클라이언트는 TLS 협상 시 수신한 인증서를 TLSA RR과 대조하여 검증한다.
4가지 인증서 사용 모델:
| 모델 | 설명 | CA 의존 |
|---|---|---|
| PKIX-TA | 특정 CA를 신뢰 앵커로 지정 → CA 범위 제한 | Yes |
| PKIX-EE | 특정 종단 인증서를 지정 | Yes |
| DANE-TA | 도메인 자체 CA를 신뢰 앵커로 지정 | No |
| DANE-EE | 도메인이 직접 발급한 인증서 사용 | No |
DANE와 SMTP
STARTTLS와 함께 사용하여: (1) TLSA RR 존재 = 암호화 필수 → 다운그레이드 공격 방지, (2) DNSSEC 서명된 TLSA RR로 TLS 인증서 인증.
19.8 SPF (Sender Policy Framework)
RFC 7208. 도메인 소유자가 허용된 발신 IP 주소를 DNS TXT RR로 게시하여, 수신자가 발신자를 검증할 수 있게 한다.
SPF 메커니즘과 수정자
주요 메커니즘: ip4 (IPv4 범위), ip6 (IPv6 범위), mx (MX RR의 호스트), include (다른 도메인의 SPF 참조), all (나머지 모든 IP)
수정자: + (통과, 기본값), - (거부), ~ (전환 중, 수락하되 주의), ? (명시 없음)
SPF 동작
송신 측: 도메인의 모든 발신자를 식별하고 SPF 구문으로 DNS TXT RR에 인코딩.
수신 측: SMTP 봉투의 MAIL FROM 도메인과 발신 IP로 SPF TXT RR을 조회. 메시지 본문 수신 전에 검사 가능. SPF RR이 없거나 형식 오류이면 기본적으로 수락.
19.9 DKIM (DomainKeys Identified Mail)
RFC 6376. MTA가 선택된 헤더와 본문에 도메인 개인키로 서명. 수신 MDA가 DNS에서 공개키를 조회하여 서명을 검증한다.
S/MIME과의 차이
| 구분 | DKIM | S/MIME |
|---|---|---|
| 서명 키 | 도메인(ADMD)의 개인키 | 개인 사용자의 개인키 |
| 서명 범위 | RFC 5322 헤더 + 본문 | 메시지 본문만 |
| 사용자 관여 | 투명 (MUA 불필요) | MUA에 S/MIME 설치 필요 |
| 적용 범위 | 협력 도메인의 모든 메일 | S/MIME 사용자 간에만 |
DKIM-Signature 헤더 필드
서명은 RFC 5322 메시지에 DKIM-Signature: 헤더로 삽입. 서명 전에 **정규화(canonicalization)**를 수행 (simple / relaxed).
주요 태그: v= (버전), a= (알고리즘, rsa-sha256 기본), c= (정규화 방법), d= (서명 도메인 SDID), s= (셀렉터, 키 검색용), h= (서명된 헤더 필드 목록), bh= (본문 해시), b= (서명 데이터, base64)
DKIM 기능 흐름
- 발신 ADMD의 서명 모듈이 키 저장소의 개인키로 메시지에 서명
- MTA 릴레이를 거쳐 수신 ADMD에 도착
- 수신 측이 서명 존재 여부 확인:
- 서명 있음 → 검증: DNS에서 DNSKEY RR로 공개키 조회 → 서명 검증 → 통과 시 평판 정보 참조 → 메시지 필터링
- 서명 없음: 송신자의 서명 관행(signing practices) 조회 → 메시지 필터링 (예: gmail이 DKIM을 사용하는데 서명이 없으면 사기 가능성)
19.10 DMARC (Domain-based Message Authentication, Reporting, and Conformance)
RFC 7489. SPF와 DKIM을 통합·보완하여, 수신자에게 실패 시 처리 방침을 알리고, 송신자에게 피드백을 제공한다.
식별자 정렬 (Identifier Alignment)
DMARC는 RFC 5322 From 주소(MUA에 표시되는 발신자)를 중심 ID로 사용. 이 주소가 DKIM 서명 도메인 또는 SPF 인증 도메인과 **일치(정렬)**해야 한다.
DMARC 정책 (DNS TXT RR)
| 태그 | 설명 |
|---|---|
v= | 버전 (DMARC1) |
p= | 필수 정책: none (특정 조치 없음), quarantine (의심스러운 메일로 처리), reject (거부) |
aspf= | SPF 정렬 모드: r (완화, 기본) / s (엄격) |
adkim= | DKIM 정렬 모드: r (완화, 기본) / s (엄격) |
fo= | 실패 보고 옵션: 0 (모두 실패 시), 1 (하나라도 실패 시), d (DKIM 실패), s (SPF 실패) |
ruf= | 포렌식(개별 실패) 보고 수신 URI |
rua= | 집계 보고 수신 URI |
ri= | 보고 간격 (초, 기본 86400) |
pct= | DMARC 정책 적용 비율 (%, 기본 100) — 점진적 정책 강화에 사용 |
sp= | 하위 도메인 정책 (선택, 기본 none) |
DMARC 수신 측 처리
- 표준 검증 (IP 차단 목록, 평판, 속도 제한)
- RFC 5322 From 주소 추출
- DMARC DNS RR 조회
- DKIM 서명 검증
- SPF 검증
- 식별자 정렬 검사 (From ↔ DKIM 도메인 / SPF 도메인)
- DMARC 정책 적용 → pass/fail 결정
- 정책에 따라 전달/격리/거부
- 보고 데이터 수집 (집계 보고 + 포렌식 보고)
DMARC 보고
집계 보고: 주기적으로 전송. 성공/실패 인증 통계, 메시지 처분, SPF/DKIM 결과, 정렬 여부, 적용된 정책 등을 포함. 송신자는 p=none에서 시작하여 보고를 수집한 후 점진적으로 p=reject로 강화한다.
포렌식 보고: 개별 메시지 실패에 대한 상세 보고. 메시지 헤더·내용 일부를 포함하여 송신 도메인이 SPF/DKIM 메커니즘을 개선하거나, 자사 도메인이 피싱/스팸에 이용되고 있음을 감지할 수 있다.
주요 용어
| 한글 | 영문 |
|---|---|
| 관리 도메인 | Administrative Management Domain (ADMD) |
| DANE | DNS-based Authentication of Named Entities |
| DKIM | DomainKeys Identified Mail |
| DMARC | Domain-based Message Authentication, Reporting, and Conformance |
| DNSSEC | DNS Security Extensions |
| 메시지 전송 에이전트 | Message Transfer Agent (MTA) |
| 메시지 사용자 에이전트 | Message User Agent (MUA) |
| MIME | Multipurpose Internet Mail Extensions |
| PGP | Pretty Good Privacy |
| S/MIME | Secure/Multipurpose Internet Mail Extensions |
| SPF | Sender Policy Framework |
| STARTTLS | SMTP Security Extension for TLS |
| 신뢰의 웹 | Web of Trust |