384비트 곡선 암호, 실제 비밀키는 고작 4였다
2026년 10월 17일 토요일, 보안 연구자들이 애플, 구글, 마이크로소프트, 모질라 및 인도의 공인인증기관 eMudhra에 충격적인 조사 결과를 전달했습니다. eMudhra가 보유한 8개 중간 CA 인증서의 개인키가 일반 노트북에서 1초도 안 되어 뚫릴 수 있다는 사실이었습니다.
이 인증서들은 P-384 타원곡선 표준을 사용했습니다. 규격 설계상 개인키는 약 10^115가지 경우의 수를 지닌 384비트 난수여야 마땅합니다. 하지만 실제로 생성된 개인키는 47바이트 분량의 0 뒤에 1바이트 크기의 숫자가 붙은 형태였습니다. 확인된 8개 키의 값은 각각 4, 56, 115, 155, 156, 230, 66, 237이었습니다. 그중 하나는 말 그대로 숫자 4였습니다.
이러한 키를 크랙하는 데 필요한 타원곡선 점 덧셈 연산은 최대 255회에 불과하며, 일반 가정용 노트북으로도 1초 미만이 소요됩니다. 연구자들은 모질라 공지사항에 첨부된 16개 인증서에서 8개 개인키 전량을 온전히 복원해 냈습니다. 해당 개인키들은 인증서가 발급된 2025년 4월 이래 사실상 일반에 완전히 공개된 상태나 다름없었습니다.
그림: 파괴된 자물쇠. 출처: Ars Technica
형식 검사는 모두 통과했다: 그렇다면 문제는 어디에 있었나
HTTPS 신뢰 사슬은 루트 인증서부터 아래로 단계별 발행 절차를 거치며, 매 단계마다 엄격한 유효성 검증을 받습니다. 곡선 규격의 적합성, ASN.1 인코딩 유효성, 서명 구조 정합성 등을 모두 점검합니다. eMudhra의 8개 인증서(DV/OV/EV를 망라한 TLS 발급용 CA 6개와 코드 서명용 CA 2개)는 모두 2025년 4월에 생성된 뒤, 5월에 Sectigo의 AAA Certificate Services 루트로부터 교차 서명을 획득하며 모든 기술 검사를 통과했습니다.
하지만 규격 검사 항목 그 어디에도 개인키가 진정한 난수인지 검증하는 항목은 존재하지 않습니다. 개인키 생성은 인증기관 내부에서 전적으로 수행되며, 외부에는 공개키만이 노출되기 때문입니다. P-384가 제공하는 10^115 수준의 수학적 보안성은 개인키가 거대한 후보군 속에서 무작위로 추출된다는 전제하에서만 성립합니다. eMudhra의 치명적 결함은 외부의 자동화 도구가 들여다볼 수 없는 바로 그 지점에서 터져 나왔습니다.
커뮤니티에서는 키 생성 스크립트에서 매개변수 순서가 뒤바뀌었거나, 코드 내에서 key[0] 형태로 래핑 키의 첫 1바이트만 잘못 추출해 대입했을 것이라는 등 기술적 원인을 추정했습니다. 다른 한편에서는 개인키는 당연히 하드웨어 보안 모듈(HSM) 내부에서 생성되어야 하며, 외부 스크립트로 생성되고 이토록 엉터리 값이 방치되었다는 사실 자체가 절차와 운영 프로세스가 처음부터 붕괴되어 있었음을 방증한다고 비판했습니다.
브라우저 진영의 즉각적인 차단 조치: 나흘간 이어진 여파
10월 17일 밤, 구글 크롬 팀은 해당 8개 인증서를 긴급 차단하는 CRLSet 업데이트를 배포했고, 몇 시간 뒤 모질라도 OneCRL 긴급 배포를 통해 보조를 맞췄습니다. 10월 20일, 모질라는 사건을 공식 발표하며 NSS 업데이트를 통해 eMudhra 루트 인증서를 신뢰 저장소에서 완전히 삭제했습니다. 구글 역시 Chrome Root Store v43 정책을 통해 루트 폐기를 확인했습니다.
브라우저 진영이 이토록 신속하게 움직인 이유는 무엇일까요? 보안 연구자 Ian Carroll의 평가에 답이 있습니다. “본질적으로 누구나 인수분해할 수 있는 1바이트 크기의 키였기 때문에 피해 범위를 통제하는 것이 불가능했습니다.” 탈취 시점을 특정할 수 있는 침해 사고가 아니었으므로, 지난 17개월 동안 언제든 누구라도 위조 인증서를 만들어 냈을 위험이 존재했습니다.
크롬 엔지니어들은 중요한 세부 정보를 덧붙였습니다. 문제의 중간 CA들이 인증서 투명성(CT, Certificate Transparency) 로그에 발급 내역을 기록한 적이 없었기 때문에, 크롬 환경에서는 위조된 인증서가 기본적으로 신뢰받지 못하도록 방어선이 구축되어 있었습니다. 그러나 CT는 부적절한 인증서 발행을 사후 감지할 뿐 발행 행위 자체를 막지는 못하며, 수많은 비브라우저 소프트웨어는 CT 유효성을 전혀 검증하지 않습니다.
그림: 신뢰 사슬은 상위 단계의 검증에 의존하지만, 최하단 개인키의 무작위성은 검사 체계가 부재하다. 출처: Keytos
가장 위험에 노출된 대상: curl | sh 파이프 스크립트
주요 웹 브라우저 사용자들은 긴급 폐기 목록 배포와 CT 의무화라는 이중 방어막 덕분에 안전을 유지할 수 있었습니다. 진짜 문제는 브라우저 외부의 생태계에 있었습니다.
curl, 파이썬, Node.js, Go, 자바, git, 그리고 각 운영체제의 패키지 관리자 같은 비브라우저 TLS 클라이언트들은 로컬 디스크에 보관된 정적 CA 번들을 기본적으로 신뢰합니다. 또한 폐기 여부(OCSP/CRL)를 확인하지 않으며 CT 로그도 검증하지 않습니다. 이러한 클라이언트들에게 인증기관 폐기 공지는 무용지물에 가깝습니다. 시스템의 CA 번들에 남아 있는 한, 8비트 개인키를 지닌 중간 CA는 여전히 신뢰할 수 있는 발행자로 취급됩니다.
가장 치명적인 위협 시나리오는 두 곳에서 발생합니다. 첫째는 소프트웨어 자동 업데이트 도구 및 curl | sh 방식의 설치 스크립트입니다. 위조 인증서가 통과하면 공격자의 임의 코드가 일반 사용자 권한은 물론 관리자(root) 권한으로 즉시 실행됩니다. 둘째는 CI/CD 빌드 파이프라인입니다. 빌드 컨테이너에는 클라우드 접속 자격 증명, 패키지 저장소 토큰, 서명 키 등 핵심 자산이 집중되어 있습니다. 공격자가 중간자 공격을 성사시키는 데 필요한 장비는 일반 노트북 1대와 1초도 안 되는 연산 자원이 전부였습니다.
eMudhra의 해명과 시장 철수
10월 22일, eMudhra는 글로벌 SSL/TLS 인증서 사업에서 전면 철수하겠다고 발표했습니다. 사측이 내세운 이유는 세 가지였습니다. 글로벌 SSL/TLS 사업 매출 비중이 전체의 약 1%에 불과하다는 점, 데이터 주권 요구와 규제 준수 비용이 급증하는 반면 대형 빅테크의 무료 인증서 발급으로 채산성이 크게 악화되었다는 점, 그리고 “이번 사태를 둘러싼 소셜 미디어 상의 과도한 논란과 감시 압박이 우리 사업 내 실제 비중에 비해 지나치게 과장되었다”는 불만이었습니다. 동시에 문제의 CA를 14시간 만에 폐기했고, 최종 사용자용 인증서를 발행한 이력이 없으며, 내부 인프라 침해 사고는 없었다고 강조했습니다.
개발자 커뮤니티는 “과장된 논란”이라는 사측의 변명을 결코 받아들이지 않았습니다. 비판의 초점은 단 하나였습니다. 17개월 동안 어떻게 내부 검증 절차에서 개인키의 엔트로피 결핍을 단 한 번도 걸러내지 못했는가 하는 점입니다. 암호화 키는 당연히 HSM 장비 안에서 안전하게 생성되었어야 하며, 이를 외부에서 생성하고 방치한 행위 자체가 인증기관으로서의 기본 자격을 상실했음을 드러낸다는 반박이 잇따랐습니다.
마지막 방어선은 사람이며 자동화된 안전망은 없다
이번 참사에서 수학적 암호 알고리즘 자체에는 아무런 오류도 없었습니다. 타원곡선 규격은 표준이었고, 인코딩은 완벽했으며, 데이터 구조는 정합했고, Sectigo 같은 글로벌 대형 루트로부터의 교차 서명도 갖추고 있었습니다. 8개의 인증서는 17개월 동안 수많은 자동화 점검을 통과했습니다. 파국의 원인은 기계도 감사관도 기본적으로 확인하지 않는 단 하나의 사소한 기본 확인을 생략한 데서 비롯되었습니다. 384비트여야 할 개인키가 실제로 8비트 정수에 불과하지 않은지 직접 확인한 사람이 아무도 없었던 것입니다.
HTTPS 신뢰 사슬의 끝자락에는 웹 브라우저가 버티고 있지만, 중간 단계 인증기관들이 사용하는 개인키의 품질은 오직 공개키를 역산해서 추정하는 수밖에 없습니다. eMudhra 사태의 경우 그 역산에 17개월이 걸렸고, 결국 외부 보안 연구자의 수동 분석에 의해서야 밝혀졌습니다. 공개키 기반 구조(PKI)의 안보 경계선은 근본적으로 운영 주체의 엄격한 규율에 달려 있습니다. 그리고 그 규율은 curl 명령어 한 줄처럼 손쉽게 자동 검증할 수 있는 성질의 것이 아닙니다. eMudhra는 1% 비중의 비수익 사업을 접는 것으로 사태를 수습하려 했으나, “감시자를 누가 감시하는가”라는 물음 앞에 다음번 사고를 일으킬 주체에게도 포기할 수 있는 1%짜리 퇴로가 남아 있을지는 알 수 없습니다.
참고 자료:
- 모질라 Bugzilla 공지 및 NSS 릴리스 노트
- Chrome Root Store v43 업데이트 안내
- eMudhra 글로벌 SSL/TLS 사업 철수 성명
- Ian Carroll 분석 논평
- Hacker News 토론 스레드 (item?id=50177916)
