공개키 기반구조(PKI)의 신뢰는 궁극적으로 하나의 숫자, 즉 아무도 추측할 수 없을 만큼 거대한 개인키 d에 달려 있다. 그런데 인증기관(CA) eMudhra의 중간 인증서 여덟 개는 그 개인키가 각각 4, 56, 115 같은 한 자릿수에서 세 자릿수 사이의 작은 정수였다. 보안 연구자는 모질라가 공개한 인증서에서 이 값들을 노트북으로 1초도 안 되어 복원했다고 밝혔다. 수백 자리의 난수가 있어야 할 자리에, 사실상 누구나 즉시 알아낼 수 있는 숫자가 들어 있었던 것이다.
384비트여야 할 자리에 8비트
문제의 키는 모두 P-384 타원곡선 기반이다. 이 곡선에서 공개키는 고정점 G에 개인키 d를 곱한 값(d×G)으로, 공개키에서 d를 거꾸로 알아내는 것은 d가 충분히 클 때만 비현실적으로 어렵다. 정상적인 P-384 개인키는 약 2³⁸⁴가지 경우의 수를 갖는 무작위 384비트 값이어야 한다. 그러나 eMudhra의 여덟 개 키는 47바이트가 전부 0이고 마지막 1바이트에만 값이 들어 있는 형태였다. 한 바이트는 256가지 값만 가지므로, 1×G, 2×G 순서로 계산해 인증서와 일치하는 지점을 찾는 데 최대 255번이면 충분하다. 사실상 8비트짜리 탐색인 셈이다.
해당 인증서가 발급할 수 있었던 모든 인증서, 이를 신뢰한 모든 클라이언트의 안전이 이 8비트에 걸려 있었다. 문제의 중간 인증서는 2025년 4월에 생성된 TLS 발급용 CA 여섯 개(DV·OV·EV 각 2세대)와 코드 서명용 CA 두 개이며, 2025년 5월 세티고(Sectigo)의 AAA Certificate Services 루트로부터 교차 서명까지 받았다. 연구자는 eMudhra와 세티고가 각각 사용한 열여섯 개 인증서를 모두 뽑아 전부 즉시 복원해냈다.
도둑이 없는 유출
이 사건이 보통의 키 탈취와 다른 지점은 '훔친 사람'이 없다는 데 있다. 일반적인 CA 키 유출에는 범인과 사건 발생 시점이 존재하고, 적어도 누가 접근 권한을 갖게 됐는지 추론할 여지가 있다. 하지만 이 경우 키는 인증서가 존재한 순간부터 사실상 공개된 것이나 마찬가지였다. 2025년 4월 이후 약 17개월 동안, 이 인증서를 들여다본 사람이라면 누구나 평범한 하드웨어에서 밀리초 단위로 개인키를 복원할 수 있었고, 실제로 그렇게 한 사람이 있었는지는 확인할 방법이 없다. 더 당혹스러운 점은 인증서 자체에는 아무런 이상이 없다는 것이다. d=4로 유도한 공개키도 곡선 위의 유효한 점이고, 인코딩과 구조 검사는 모두 통과한다. 약함을 확인하는 유일한 방법은 실제로 깨뜨려 보는 것뿐이다.
보고는 2026년 10월 17일 토요일 애플·구글·마이크로소프트·모질라와 eMudhra에 전달됐다. 크롬은 그날 저녁 CRLSet 업데이트로, 파이어폭스는 몇 시간 뒤 OneCRL로 해당 인증서를 차단했다. 20일 화요일 모질라가 이를 공개하며 NSS에서 eMudhra 루트를 제거했고, 크롬도 Chrome Root Store v43에서 루트를 빼기로 확정했다.
브라우저는 괜찮고, 나머지가 문제다
최신 주류 브라우저 사용자는 사실상 안전하다. 크롬과 파이어폭스는 중간 인증서를 직접 차단하고 인증서 투명성(CT)을 강제하며, 사파리도 CT를 요구한다. 크롬 측은 CT를 강제하기 때문에 이들 CA로 연결되는 TLS 인증서가 CT 로그에 전혀 나타나지 않았고, 따라서 위조 인증서가 크롬에서 기본적으로 신뢰될 수 없었다고 설명했다. 다만 CT는 오발급을 사후에 탐지할 뿐 예방하지는 못하며, 상당수 소프트웨어는 CT를 아예 확인하지 않는다.
실질적 위험은 브라우저 바깥에 있다. curl, 파이썬, Node, Go, 자바, git, 패키지 매니저를 비롯해 사실상 대부분의 비(非)브라우저 TLS 클라이언트는 기본 설정에서 디스크의 CA 번들을 신뢰하고, 폐기(revocation)를 확인하지 않으며, CT도 검사하지 않는다. 그래서 eMudhra와 세티고가 중간 인증서를 폐기해도 이들에게는 아무 효과가 없다. 데스크톱 브라우저에서 잘 작동하는 CRLite 같은 최신 폐기 메커니즘도 다른 클라이언트에는 도움이 되지 않는다. 연구자가 api.stripe.com 이름으로 발급한 인증서를 로컬 서버로 시험한 결과, 기본 설정의 curl은 인증서 검증 성공, 파이썬은 핸드셰이크 완료, Node는 authorized: true를 반환했으며 이는 테스트한 모든 리눅스·macOS 장비에서 동일했다. 윈도우의 CryptoAPI는 폐기 검사를 켜지 않으면 체인을 수용했고, 켜더라도 두 경로 중 하나만 폐기로 표시됐다.
대응책은 결국 '루트 저장소를 업데이트하라'로 요약된다. 업데이트가 쉬운 장비라면 절차는 복잡하지 않지만, 쉽게 갱신할 수 없거나 아예 갱신이 불가능한 장치들이 진짜 문제다. 네트워크 경로에 끼어들 수만 있으면 임의의 호스트명으로 트래픽을 가로챌 수 있는 상황이, 수많은 소프트웨어에서 17개월간 방치돼 있었다는 뜻이다.
eMudhra는 모질라 인시던트 티켓을 통해 경위를 설명했다. 키 생성 의식(ceremony)에 사용한 스크립트의 버그로 HSM에 두 번째 약한 키 쌍이 만들어졌고, 이름이 비슷했던 탓에 사람이 CSR에 엉뚱한 키를 사용하는 실수를 저질렀다는 것이다. 연구자는 이 새 정보가 기사 내용을 바꾸지는 않는다고 덧붙이며, AI 에이전트에 간단한 프롬프트 하나를 넣는 것만으로도 CA의 개인키를 복원할 수 있었다고 확인했다. 결국 이 사건은 암호 알고리즘의 결함이 아니라, 키 생성이라는 가장 기초적인 절차에서의 자동화 오류와 사람의 실수가 신뢰 전체를 무너뜨릴 수 있음을 보여준다. 실무자 입장에서는 비브라우저 클라이언트의 폐기·CT 미검사라는 구조적 사각지대를 전제로, 루트 저장소 관리와 갱신 불가능한 레거시 장비 목록부터 점검해야 할 사안이다.