보안메일, 정말 안전할까?

PDF부터 HTML 보안메일까지, 국내 암호화 이메일의 보안 강도를 직접 검증해 보았다.

매달 이메일로 날아오는 통신사 명세서, 은행 거래내역서, 전자세금계산서. 첨부된 PDF나 HTML 파일을 열려면 주민번호 앞 6자리를 입력해야 한다. 이름하여 '보안메일'. 과연 이 방식은 얼마나 안전할까?

PDF 암호화뿐 아니라, 국내에서 널리 사용되는 HTML 보안메일 4종의 암호화 구조까지 분석해 보았다.

1. PDF 암호 크래킹 테스트

KT에서 발송한 2026년 4월 이메일 명세서다. 파일명에 친절하게 '문서열기암호: 주민번호 앞 6자리'라고 적혀 있다. 주민번호 앞 6자리는 곧 생년월일이므로, 유효한 날짜 조합은 약 24,000개에 불과하다.

세 가지 방법으로 비밀번호 크래킹을 시도했다.

방법별 크래킹 소요 시간

방법	도구	소요 시간	비고
쉘 스크립트 반복	qpdf	약 62초	기준 (1x)
Python 코드	pikepdf	약 3초	약 20배 빠름
전용 크래킹 도구	pdfcrack	약 0.6초	약 108배 빠름

각 방법은 어떻게 다른가

qpdf 쉘 스크립트는 가장 단순한 방법이다. 비밀번호 후보를 하나씩 넣어 복호화를 시도하지만, 매번 프로세스를 새로 띄우기 때문에 오버헤드가 크다. 24,000개를 다 돌리면 1분이 넘게 걸린다.

Python pikepdf는 라이브러리를 통해 프로세스 생성 없이 인메모리에서 암호를 검증한다. 같은 작업이 3초 만에 끝난다.

pdfcrack은 C로 작성된 전용 크래킹 도구다. PDF에서 암호화 해시를 추출한 뒤 해시값만 비교하므로 전체 복호화 과정이 필요 없다. 0.57초, 사실상 즉시 뚫린다.

2. HTML 보안메일 포맷 분석

PDF만 문제가 아니다. 국내 기업과 기관에서 발송하는 HTML 보안메일도 분석해 보았다. 현재 널리 사용되는 포맷은 크게 4종이다.

국내 보안메일 4종 비교

포맷	제공사	사용처	암호 알고리즘	비밀번호
HomeTax	국세청	전자세금계산서	AES/SEED/ARIA-CBC 128	사업자번호 10자리 / 주민번호 13자리
XecureExpress	Softforum	LG U+, 기업 보안메일	SEED-CBC 128	생년월일 6자리 / 사업자번호 10자리
StatiCrypt	오픈소스	토스뱅크	AES-256-CBC	생년월일 6자리
VestMail	YettieSoft	신한은행, 금융기관	SEED-CBC 128	생년월일 6자리 / 사업자번호 10자리

암호화는 제각각, 비밀번호는 똑같다.

네 가지 포맷은 암호화 알고리즘도 다르고, 키 파생 방식도 제각각이다. 국세청은 AES/SEED/ARIA를 선택할 수 있게 했고, 토스뱅크는 오픈소스인 StatiCrypt를 채택해 AES-256을 사용한다. Softforum의 XecureExpress와 YettieSoft의 VestMail은 국산 알고리즘인 SEED-CBC를 쓴다.

하지만 어떤 알고리즘을 쓰든 비밀번호는 대부분 생년월일 6자리다. 일부는 사업자번호 10자리나 주민번호 13자리를 사용하지만, 개인 사용자에게 발송되는 메일은 거의 예외 없이 6자리 생년월일이다.

키 파생 함수의 문제

현대 보안 기준에서 비밀번호 기반 암호화는 Argon2id나 scrypt 같은 느린 키 파생 함수를 사용하고, 최소 60만 회 이상 반복하도록 권장한다. 비밀번호를 시도하는 데 의도적으로 시간이 걸리게 만들어 무차별 대입 공격을 어렵게 하는 것이다.

국내 보안메일의 현실은 어떨까?

포맷	키 파생 방식	반복 횟수	권장 기준
HomeTax	MD5 1회	0	600,000+
XecureExpress	커스텀 SHA256	약 100회	600,000+
StatiCrypt	MD5 3회 (EVP_BytesToKey)	0	600,000+
VestMail	SHA256 2회	0	600,000+

어떤 포맷도 권장 기준에 근접하지 못한다. 가장 나은 XecureExpress조차 100회 반복에 불과하다. 나머지는 해시 함수를 1~3회 돌리는 것이 전부다.

실제 크래킹에 걸리는 시간

엔트로피는 비밀번호의 예측 불가능성을 비트 단위로 나타낸 것이다. NIST와 OWASP는 최소 72비트 이상의 엔트로피를 권장한다.

비밀번호 유형	엔트로피	권장 기준
생년월일 6자리	약 20-bit	72-bit 이상
사업자번호 10자리	약 33-bit	72-bit 이상
주민번호 13자리	약 43-bit	72-bit 이상
영숫자+특수문자 12자리	약 78-bit	72-bit 이상

생년월일 6자리의 엔트로피는 20비트에 불과하다. 권장 기준 72비트와 비교하면, 비밀번호 공간이 약 40억 배 좁다. AES-256이라는 최고 수준의 암호화를 적용하더라도, 비밀번호가 6자리 숫자이면 보안 효과는 사실상 없다.

왜 이런 방식을 쓰는 걸까

놀랍게도 '보안메일'을 직접 명시한 법률은 없다. 여러 법률에서 개인정보를 전송할 때 암호화하라고 규정하고 있고, 기업들이 이를 충족하기 위해 자율적으로 채택한 관행이 바로 이 방식이다.

법률	조항	내용
개인정보보호법	제29조	개인정보의 안전성 확보조치 의무
안전성 확보조치 기준 고시	제7조	정보통신망 송수신 시 암호화 의무
정보통신망법	제28조	정보통신서비스 제공자의 개인정보 보호조치
전자금융거래법	-	금융기관 전자적 전송 시 암호화 의무
신용정보법	-	신용정보 전송 시 안전성 확보 조치

법률은 '암호화하라'고만 말할 뿐, 구체적인 방식은 지정하지 않는다. 비밀번호를 생년월일 6자리로 설정하는 것도 법적 요구가 아닌 업계 관행이다.

도입 당시에는 안전했을까?

이 방식이 보편화된 것은 2010년대 초반이다. 그렇다면 당시에는 안전했을까?
결론부터 말하면, 아니다. 도입 당시부터 실질적 보안 효과가 없었다.

환경	속도 (RC4 128-bit)
CPU (Core i7 1세대, 2010년)	약 50,000~150,000 pw/sec
GPU	PDF 모듈 미지원 (2012년부터 추가)

2010년 보급형 PC의 CPU만으로도 초당 5만 개의 비밀번호를 시도할 수 있었다. 생년월일 24,000개를 전수탐색하면 24,000 / 50,000 = 0.48초. GPU 가속조차 필요 없는 수준이다.

도구	상태
pdfcrack	2006년부터 오픈소스로 공개
John the Ripper	2010년 PDF 지원 추가
Elcomsoft APDFPR	2000년대 중반부터 상용 판매
hashcat (GPU)	PDF는 2012년부터 (필요하지도 않았음)

핵심은 암호화 알고리즘이 RC4인지 AES인지, SEED인지가 아니다. 문제는 키스페이스, 즉 가능한 비밀번호의 수가 너무 적다는 점이다. 6자리 숫자의 전체 경우의 수는 100만 개지만, 유효한 생년월일로 한정하면 약 24,000개로 줄어든다. 이 정도 규모는 2000년대 초반 PC에서도 수초 내에 전수탐색이 가능했다.

형식적 보안의 한계

보안메일은 법에서 요구하는 '암호화 전송'의 형식만 갖춘 것이지, 실질적인 보안은 거의 제공하지 못한다. PDF든 HTML이든, 국세청이든 토스뱅크든, 어떤 암호화 알고리즘을 사용하든 비밀번호가 생년월일 6자리인 한 밀리초 단위로 크래킹이 가능하다.

도입 시점인 2010년에도 1초 이내에 크래킹이 가능했고, 16년이 지난 지금도 같은 방식이 사용되고 있다. 더 큰 문제는 이 방식이 오히려 보안 위협을 만들어낸다는 점이다. 보안메일을 가장한 피싱 메일이 빈번하게 유포되고 있으며, 사용자들은 진짜와 가짜를 구별하기 어렵다.

개선 방향

  - 생년월일 등 추측 가능한 정보를 비밀번호로 사용하지 말 것
  - 최소 12자 이상의 영문, 숫자, 특수문자 조합 권장 (72-bit 이상 엔트로피)
  - 키 파생 함수를 Argon2id 또는 scrypt로 교체하고, 충분한 반복 횟수 적용
  - PDF 암호화 시 AES-256 사용 권장 (RC4, SEED-128은 취약)
  - 보안메일 대신 본인인증 후 웹에서 열람하는 방식 도입 검토
  - 피싱 방지를 위해 발신자 서명(DKIM/DMARC) 강화 및 사용자 교육 병행