eMudhra 중간 CA 침해 세부 사항 및 해결 가이드

8개의 eMudhra 중간 인증 기관(CA) 인증서의 개인 키가 침해되어 웹사이트 사칭의 심각한 위협이 발생했습니다. 이러한 침해된 인증서는 Mozilla, Microsoft, Apple, Chrome을 포함한 주요 공급업체가 신뢰하는 루트 프로그램에 연결되므로 사용자와 개발자의 즉각적인 조치가 필요합니다.

침해 이해

이 침해는 일반적인 키 도난이 아니라 eMudhra의 키 생성 절차 과정의 근본적인 결함으로 인해 발생했습니다. 8개의 중간 CA에 사용된 개인 키는 본질적으로 취약했으며, 특히 ECC 키 생성에서 256보다 작은 정수를 사용했습니다. 이 약점으로 인해 개인 키는 쉽게 복구될 수 있었고, 사실상 1바이트 키가 되었습니다.

근본 원인 분석

eMudhra의 예비 평가에 따르면 근본 원인은 키 생성 과정 중 인간의 실수였습니다. CA는 수출을 위한 랩/언랩 절차를 테스트하기 위해 일반적인 키 생성 의식(KGC) 스크립트에 승인된 편차를 도입했습니다. 이 결함 있는 스크립트는 실수로 두 번째로 약한 테스트 키 세트를 생성했습니다. 이러한 약한 키는 실수로 인증서 서명 요청(CSR)을 만드는 데 사용되었고, 이후 루트 CA에 의해 서명되고 Sectigo에 의해 교차 서명되었습니다.

즉각적인 조치 및 보안 결과

주요 신뢰 저장소 운영자는 사칭 위험을 완화하기 위해 신속하게 조치했습니다. 침해된 인증서는 주요 플랫폼에서 차단되었으며, CA 자체도 영향을 받은 중간 인증서를 폐기했습니다.

브라우저 및 OS 해결 타임라인

• Firefox 및 Chrome: 2026년 10월 17일부터 인증서 차단 시작.
• Apple 기기: 2026년 10월 19일부터 차단 시작.
• Microsoft: 2026년 10월 20일부터 차단 시작.

보안 위험 평가

침해된 중간 CA의 개인 키를 보유한 공격자는 모든 웹사이트나 서비스를 사칭할 수 있습니다. 브라우저 공급업체는 사용자를 보호하기 위해 폐기 도구(예: OneCRL, CRLite, CRLSets)를 사용했지만, 폐기 정보를 소비하지 않고 소프트웨어 업데이트가 필요한 클라이언트의 경우 위험이 여전히 높습니다.

사용자 및 개발자를 위한 해결 단계

사용자는 가능한 한 빨리 브라우저와 운영 체제를 최신 버전으로 업데이트해야 합니다. 개발자와 시스템 관리자의 경우 다양한 소프트웨어 패키지에 대한 특정 패치가 필요합니다.

개발자 및 소프트웨어 패치

소프트웨어	패치 버전	링크
Go	1.27.3, 1.26.10	golang-announce
Electron	44.9.1, 43.8.1, 42.11.16	electron/electron/releases/tag/v44.9.1
Python certifi	2026.10.19	certifi/python-certifi/releases/tag/2026.10.19
Rust rustls-webpki	0.103.16	rustls/webpki/releases/tag/v%2F0.103.16
Rust webpki-roots / webpki-root-certs	1.0.10	rustls/webpki-roots/releases/tag/v%2F1.0.10
Homebrew ca-certificates	2026-09-25_1	Homebrew/homebrew-core/blob/d02b8762f4a29859c47a635a0d2683223fea9812/Formula/c/ca-certificates.rb
NSS	3.131.1	mozilla.org/g/dev-tech-crypto/c/vSxZxnOMMvs
uv	0.13.4	astral-sh/uv/releases/tag/0.13.4

고급 시스템 해결 방법

운영 체제를 즉시 업데이트할 수 없는 사용자의 경우 영향을 받은 루트를 수동으로 신뢰하지 않도록 설정할 수 있지만, 일반 사용자에게는 권장되지 않습니다.

• macOS: 사용자는 awk를 사용하여 /etc/ssl/cert.pem에서 영향을 받은 루트를 제거하여 내장된 /usr/bin/curl이 침해된 중간 인증서를 신뢰하지 않도록 할 수 있습니다.
• Linux (Debian/Ubuntu): /etc/ca-certificates.conf를 수정하고 update-ca-certificates를 실행하여 영향을 받은 루트를 신뢰하지 않도록 설정할 수 있습니다.
• Linux (Fedora/RHEL/CentOS): 영향을 받은 루트를 시스템 블록리스트 디렉토리(/etc/pki/ca-trust/source/blocklist)에 추가하고 trust extract 및 update-ca-trust를 사용하여 신뢰 저장소를 업데이트할 수 있습니다.
• NetBSD: certctl untrust를 사용하여 영향을 받은 루트를 신뢰하지 않도록 설정할 수 있습니다.

PKI의 시스템적 취약점

이 사건은 현재 공개 키 인프라(PKI) 생태계의 여러 시스템적 약점을 강조하며, 특히 인증서 폐기 및 신뢰 배포와 관련된 문제를 드러냅니다.

폐기 과제

중간 CA는 루트 CA에 영향을 주지 않고 신속하게 폐기할 수 있도록 설계되었지만, 이 메커니즘의 효과는 불균등합니다. 주요 브라우저 공급업체는 고급 폐기 도구에 투자했지만, 많은 다른 클라이언트와 소프트웨어 패키지에는 이 기능이 없어 침해를 인식하기 위해 소프트웨어 업데이트에 의존해야 합니다.

내장 신뢰 저장소

많은 소프트웨어 공급업체는 자체 버전의 CA 신뢰 저장소를 바이너리에 내장합니다. 이는 시스템 전체 CA 번들을 패치해도 이러한 응용 프로그램을 자동으로 보호하지 않기 때문에 심각한 취약점을 만듭니다. 특정 응용 프로그램이 업데이트될 때까지 많은 시스템이 취약한 상태로 남아 있습니다.

정책 개혁의 필요성

이 사건에 대한 논평은 핵심 문제가 단순히 기술적인 것이 아니라 근본적인 인증서 정책 및 집행 실패임을 시사합니다. 현재 시스템은 지리적 또는 조직적 범위에 관계없이 CA가 모든 도메인을 보증할 수 있도록 허용합니다. 비평가들은 SPF가 메일 서버 표현을 제한하는 것과 유사하게 도메인별 제한으로 전환하여 이러한 대규모 침해가 광범위한 영향을 미치지 않도록 해야 한다고 주장합니다.