2026년 10월 17일, 보안 연구자들은 Apple, Google, Microsoft, Mozilla 그리고 인증기관인 eMudhra에 치명적인 취약점을 동시에 보고했다. eMudhra가 발급한 중간 CA 인증서 8개의 개인키가 4, 56, 66, 115, 155, 156, 230, 237과 같은 1바이트 정수라는 사실이었다.
해당 인증서들은 타원곡선 암호 P-384를 기반으로 한다. 암호학 표준에 따르면 개인키는 약 3.9 × 10¹¹⁵에 달하는 키 공간에서 생성되는 384비트 무작위 난수여야 하므로 전수 조사는 불가능에 가깝다. 그러나 개인키가 4나 56처럼 지극히 작은 정수라면, 공격자는 타원곡선 기준점에 1배, 2배를 차례로 곱해 최대 255배까지만 계산하면 개인키를 즉시 복원해낼 수 있다. 16개 인증서에 걸친 8개의 개인키 전체를 보안 연구원 Scott Helme은 일반 노트북 한 대로 1초도 안 되어 모두 풀어냈다.
겉보기에는 완벽하게 정상인 인증서
이 결함은 자동화 감사 시스템이 가장 놓치기 쉬운 맹점에서 비롯되었다. 8개 개인키의 엔트로피는 바닥 수준이었지만, 구조적으로는 티끌 하나 없는 유효한 형태를 갖추고 있었다. P-384 기준점에 4를 곱해 산출된 공개키는 곡선 위의 완벽한 수학적 유효 좌표이며, 인코딩, 곡선 매개변수, 전자서명 알고리즘 검증까지 모두 통과했다. 인증서 체인, 유효 기간, 확장 필드 역시 빈틈없이 구성되어 있었다.
이 문제를 감지하려면 작은 정수들을 대입해보는 방법뿐인데, 주요 CA 감사 절차에는 그러한 검사 단계가 전혀 포함되어 있지 않았다. 이 취약한 인증서들이 공개 인터넷상에서 17개월 동안 아무런 제재 없이 살아남을 수 있었던 배경이다.
해당 중간 인증서 8개는 2025년 4월에 발급되었으며, 6개의 TLS 발급용 CA(DV, OV, EV 각 2세대)와 2개의 코드 서명 CA로 구성되어 있었다. 2025년 5월에는 Sectigo의 AAA Certificate Services 루트 인증서로부터 교차 서명을 받으면서 영향받는 인증서가 총 16개로 늘어났다. 인증서 만료일은 2039년 7월로 지정되어 있었다.
더욱 당혹스러운 부분은 eMudhra 측의 해명이었다. 그들은 개인키가 전 과정에서 하드웨어 보안 모듈(HSM) 내부에 안전하게 보관되어 있었다고 주장했다. 이것이 사실이라면, HSM은 단지 ‘값이 4인 개인키’를 충실하게 지키고 있었을 뿐이다. 하드웨어 규정 준수와 암호 키의 품질은 완전히 별개의 문제다. 커뮤니티 토론에서는 “키가 HSM 안에 철저히 갇혀 있었기 때문에 담당자 중 누구도 키의 실체를 확인하지 못했고, 결과적으로 난수 생성기가 전혀 작동하지 않고 있었다는 사실조차 몰랐던 것”이라는 비판이 이어졌다.
사진: 문제가 된 인증기관 eMudhra 로고. 8개의 중간 인증서가 17개월 동안 공개 인터넷에 무방비로 노출되어 있었다. 출처: Scott Helme 블로그 및 eMudhra 공식 웹사이트
개인키 4로 발급한 Stripe 인증서, curl은 의심 없이 통과시켰다
개인키가 사실상 공개된 것과 다름없는 상태에서 남은 과정은 인증서 위조뿐이었다.
Scott Helme은 개인키 4를 사용해 api.stripe.com 도메인용 인증서를 직접 서명한 뒤, 로컬에서 openssl s_server를 구동하고 기본 설정 상태의 클라이언트 프로그램으로 접속을 시도했다. 결과는 충격적이었다. Linux와 macOS 환경의 curl 명령은 SSL certificate verify ok를 출력했고, Python의 TLS 핸드셰이크는 정상적으로 체결되었으며, Node.js는 authorized: true를 반환했다. Windows CryptoAPI 역시 실시간 폐기 확인이 강제되지 않은 환경에서는 아무런 제재 없이 인증서를 신뢰했다.
여기서 결정적인 차이를 가른 것은 신뢰 저장소의 구조다. 웹 브라우저의 신뢰 기반은 중앙집중식이며 원격 푸시 업데이트가 가능하다. Chrome은 10월 17일 저녁 대상 인증서를 CRLSet에 등록해 즉각 차단했고, Mozilla 역시 수 시간 만에 OneCRL을 통해 대응했다. 이어 10월 20일 Mozilla는 공식 보안 공지를 배포하며 NSS에서 eMudhra 루트를 삭제했고, Chrome도 루트 저장소 v43에서 신뢰를 철회했다. 또한 브라우저가 의무화한 인증서 투명성(CT) 로그 감사 결과, 위조 인증서가 CT 로그에 제출된 정황은 확인되지 않아 일반 사용자의 웹 서핑에는 직접적인 피해가 미치지 않았다.
반면 커맨드라인 도구, 서버 SDK, IoT 기기들은 완전히 다른 방식으로 동작한다. 이들 환경의 신뢰 저장소는 프로그램 배포 시점에 포함되는 정적 파일일 뿐이며, 기본적으로 폐기 목록(CRL/OCSP)을 조회하지 않고 CT 로그도 참조하지 않는다. 브라우저에서 이미 무효화된 인증서라 할지라도, 이러한 시스템에서는 여전히 유효한 인증 수단으로 통용되는 것이다.
사진: 디지털 신뢰 사슬의 붕괴 지점은 암호학 알고리즘이 아니라 키 생성 과정에 있었다. 출처: Ars Technica
폐기 조치는 오직 브라우저에만 머물렀다
영향 범위를 정리해보면 위험의 꼬리가 얼마나 길게 이어질지 명확해진다.
curl | sh 방식의 설치 스크립트(rustup, nvm, Homebrew 등)가 HTTPS 검증에 의존할 때, 네트워크 경로를 장악한 공격자는 소스 서버를 위조하여 개발자 로컬 머신에 관리자 권한으로 악성 바이너리를 설치할 수 있다. CI/CD 환경은 더욱 심각하다. GitHub Actions, GitLab Runner, Jenkins 컨테이너에는 클라우드 플랫폼 접근 권한과 배포용 기밀 정보가 보관되어 있지만, 이러한 환경에서 시스템 인증서 저장소를 수동으로 갱신하는 경우는 거의 없다. 결제 연동, 웹훅, OAuth 호출 등 마이크로서비스 간 통신 역시 기본 베이스 이미지에 탑재된 CA 번들에 의존하므로 공격 영향권에 들어간다. Windows 코드 서명 인증서의 문제도 가볍지 않다. 위조된 서명이 포함된 실행 파일은 폐기 검사를 거치지 않는 머신에서 정상적인 소프트웨어로 인식된다.
암호학자 Filippo Valsorda는 이번 사태를 수습하기 위한 작업량이 Heartbleed 사태를 넘어설 것이라고 내다보았다. 방치된 Linux 서버, 업데이트가 중단된 컨테이너 이미지, 오래된 루트 번들을 자체 보관 중인 CLI 도구들이 기나긴 보안 사각지대를 형성하기 때문이다. Ben Cartwright-Cox는 예제 테스트 코드가 실수로 운영 환경에 배포되었을 가능성을 제기하며, 1년 반 동안 단 한 번의 감사에서도 이를 걸러내지 못했다는 점이 본질적인 문제라고 비판했다. Ian Carroll은 이 상황을 간결하게 압축했다. “1바이트 키는 누구나 복원할 수 있으며, 일단 노출된 이상 되돌릴 방법이 없다.”
13년간 이어질 긴 여파
인프라 운영진이 현실적으로 취할 수 있는 조치는 제한적이다. 통제 가능한 서버라면 eMudhra 루트 인증서를 제거하거나 중간 인증서를 차단 목록에 등록하는 것이 표준적인 대응이다. OpenSSL을 사용하는 환경에서는 시스템 인증서 번들이 최신 상태인지 확인해야 한다. 그러나 진짜 문제는 손길이 닿지 않는 기기들이다. 가정용 공유기, 보안 카메라, 산업용 제어 장비, 차량용 시스템, POS 단말기에 내장된 인증서 저장소는 출고 시점의 펌웨어에 고정되어 있다. 제조사가 펌웨어 지원을 중단한 기기라면 장비 자체를 교체하는 것 외에는 대안이 없으며, 이 인증서들의 자연 만료 시점은 2039년 7월이다.
시스템과 제품을 설계하는 엔지니어들에게 이번 사건은 뼈아픈 교훈을 남겼다. 루트 인증서 번들을 정적으로 고정하면 인증 확인에 필요한 네트워크 통신을 한 차례 줄일 수 있을지 모르지만, 그 대가로 향후 십수 년 동안 폐기 통로를 완전히 상실하게 된다. “누구도 개인키 내부를 직접 들여다보지 않을 것”이라는 맹목적인 믿음에 의존한 보안 설계는, 난수 생성기가 초기화되지 못한 채 돌아간 어느 날 오후의 실수 하나로 완전히 무너져 내렸다.
참고 자료:
- Scott Helme 기술 블로그
- We Have A Problem 인시던트 보고서
- Ars Technica 심층 분석 기사
- Mozilla 공식 보안 블로그
- Hacker News 커뮤니티 토론
