한 인증 기관이 XKCD의 농담 같은 실수를 저질렀습니다
10월 17일 보안 연구원 "Wayne"이 공개한 충격적인 폭로에 따르면, 공개 키 인프라(PKI)에서 심각한 결함이 발견되었습니다. TLS 및 코드 서명 기관을 포함한 8개의 eMudhra 중간 인증서가 손상되었습니다. 17개월 동안 주요 브라우저와 운영 체제에서 신뢰받았던 이 인증서들의 기본 개인 키는 사실상 매우 작은 정수였으며, 그중 하나는 문자 그대로 숫자 4였습니다.
이 키들은 P-384 타원 곡선을 기반으로 하는데, 이는 일반적으로 개인 스칼라(d)가 10^115개 정도의 가능성을 가진 크고 예측 불가능한 384비트 숫자여야 합니다. 하지만 손상된 eMudhra 키들은 앞부분에 0 바이트가 47개나 포함되어 있었고, 마지막 바이트의 값은 최대 255개의 후보군 내에서 무차별 대입 공격(brute-force)이 가능할 정도로 작았습니다.
이 치명적인 취약점으로 인해 개인 키를 즉시 복구할 수 있었습니다. 확인된 값은 다음과 같습니다:
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
매우 작은 크기임에도 불구하고, 이 정수들은 수학적으로 곡선 상에서 유효한 공개 키 지점을 생성합니다. 즉, 인증서가 표준 구조 검사를 통과하여 근본적인 암호학적 취약성을 감추고 있었습니다. Google Chrome과 Firefox는 즉시 해당 인증서를 차단했으며, Apple과 Microsoft도 뒤를 따랐습니다.
실수에는 흔적이 있었고, 놓쳐버린 경고도 있었습니다
보고된 원인은 2025년 4월 키 생성식(key ceremony)으로 거슬러 올라갑니다. 당시 eMudhra는 키 내보내기를 테스트하기 위해 스크립트를 수정했습니다. 이 스크립트는 실수로 하드웨어 보안 모듈(HSM)에 취약한 추가 키 쌍을 생성했습니다. 운영자들은 유사한 라벨에 속아 의도했던 암호학적으로 강력한 키 대신 이 손상된 키들을 인증서 요청에 사용했습니다.
결정적으로 2025년 6월에 경고가 있었습니다. 교차 서명 기관인 Sectigo는 eMudhra의 인증서 폐기 목록(CRL)에서 유효하지 않은 서명을 보고했습니다. 이러한 불일치는 eMudhra가 원래의 강력한 키로 CRL에 서명하려고 시도했으나, 발급된 인증서에 포함된 취약한 키와 일치하지 않았기 때문에 발생했습니다.
근본적인 불일치를 조사하는 대신, eMudhra는 취약한 키를 사용하여 폐기 목록에 다시 서명했습니다. 이 임시방편은 증상을 효과적으로 숨겼고, 근본적인 보안 결함이 16개월 더 지속되도록 만들었습니다.
운영 측면에서 이번 사건은 두 가지 중요한 교훈을 줍니다. 키 생성식에서는 생성된 모든 암호학적 자산에 대해 독립적인 신원 및 강도 검사가 필수적입니다. 또한, 특히 공개 키 인프라 환경에서 서명 불일치가 발생하면 피상적인 임시방편이 아닌 즉각적인 사고 대응이 이루어져야 합니다.
브라우저에는 안전장치가 있었지만, 빌드 시스템은 그렇지 않은 경우가 많습니다
Sectigo는 eMudhra 중간 인증서에 교차 서명하여 플랫폼 신뢰 저장소 전반에 걸쳐 광범위한 영향력을 부여했습니다. 연구원 Wayne은 손상된 8개의 키 각각으로 "We have a problem here"라는 증명 메시지에 서명하여 제어권을 입증했습니다. 이는 키가 손상되었음을 확인해주었으며, 악용될 가능성이 널리 퍼져 있음을 시사했습니다.
Google Chrome 및 Mozilla Firefox와 같은 브라우저는 몇 시간 내에 해당 인증서를 신속하게 폐기했습니다. 이들은 신뢰할 수 있는 모든 TLS 인증서를 공개적으로 기록하는 Certificate Transparency(CT) 로그를 강제합니다. 브라우저는 일반적으로 이 로그에 없는 인증서를 거부하며, 이는 직접적인 브라우저 악용을 방지하는 중요한 안전장치입니다.
그러나 브라우저가 아닌 클라이언트는 이러한 강력한 방어 기능이 부족한 경우가 많습니다. curl, Python, Node, Go, Git과 같은 도구는 종종 로컬 CA 번들에 의존하며 CT 또는 폐기 확인을 완전히 건너뜁니다. 이로 인해 MITM(Machine-in-the-Middle) 공격에 취약해집니다.
실질적인 위험은 상당합니다. 이러한 위조 키를 가진 공격자는 다음을 표적으로 삼을 수 있습니다:
- API 호출
- 설치 스크립트
- CI 러너
- 클라우드 자격 증명
또한 두 개의 손상된 코드 서명 키는 악성 업데이트나 애플리케이션을 배포할 수 있는 위조 소프트웨어에 대한 우려를 불러일으켰습니다. 자세한 기술적 내용은 Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates를 참조하십시오.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
신뢰 저장소를 패치하고 전체 파이프라인을 테스트하십시오
브라우저 공급업체와 플랫폼 운영자는 영향을 받는 인증서에 대한 신뢰를 즉시 철회했습니다. Apple, Google Chrome, Microsoft, Mozilla는 며칠 내에 손상된 중간 인증서를 차단했으며, Sectigo는 eMudhra와의 교차 서명 계약을 종료했습니다. Go는 표준 라이브러리 내에서 이 8개의 중간 인증서를 직접 차단하는 긴급 릴리스 버전 1.27.3을 발표했습니다.
장치 및 소프트웨어 업데이트 범위는 특히 임베디드 시스템의 경우 다를 수 있습니다. 위험을 완화하려면 운영 체제와 CA 패키지를 즉시 업데이트하십시오. Go와 같은 언어 런타임은 1.27.3으로, Python의 certifi 패키지는 2026.10.19로 업데이트하십시오. 컨테이너 이미지와 CI/CD 러너를 다시 빌드하여 모든 종속성이 최신 상태인지 확인하십시오.
공개된 사고 테스트 엔드포인트인 DV G3B eMudhra.we-have-a-problem.com을 사용하여 클라이언트를 테스트하십시오. 클라이언트가 오류와 함께 인증서 체인을 거부하면 안전한 것입니다. 이 검증 단계는 인증서 신뢰에 의존하는 모든 시스템에 매우 중요합니다.
이번 사건은 PKI의 중요한 교훈을 강조합니다. 형식 검사만으로는 무작위성이나 의도를 증명할 수 없습니다. 키 생성 절차의 일부로 키 강도 검사를 자동화하십시오. 인증서 공개 키가 단순히 구조적으로 유효한지뿐만 아니라 의도한 HSM 키와 정확히 일치하는지 확인하십시오. CT(Certificate Transparency) 로그를 모니터링하고, Sectigo의 2025년 6월 경고와 같은 유효하지 않은 폐기 서명은 심각한 보안 비상사태로 처리하십시오.
자주 묻는 질문
eMudhra의 개인 키에 어떤 문제가 있었나요?
8개의 중간 CA 인증서가 예측 불가능한 384비트 값 대신 4를 포함한 매우 작은 개인 키 값을 사용했습니다. 해당 키는 몇 가지 가능성만 테스트해도 복구할 수 있었습니다.
일반 브라우저 사용자가 위험에 처했나요?
최신 브라우저의 CT(Certificate Transparency) 요구 사항은 기록되지 않은 위조 인증서를 차단하는 데 도움이 되었지만, 보호 수준과 업데이트 상황은 달랐습니다. 브라우저가 아닌 소프트웨어는 종종 이와 동등한 확인 절차가 부족합니다.
CI 파이프라인이 우려되는 이유는 무엇인가요?
빌드 파이프라인의 도구와 서비스는 CT나 인증서 폐기 확인 없이 로컬 CA 번들을 신뢰할 수 있으며, 이로 인해 위조된 서버 인증서를 수락할 가능성이 있습니다.
개발자는 무엇을 해야 하나요?
운영 체제 및 언어 런타임 신뢰 저장소를 업데이트하고, 영향을 받는 컨테이너를 다시 빌드하며, 브라우저가 아닌 클라이언트와 CI 러너의 인증서 검증 동작을 테스트하십시오.