eMudhra 사건으로 본 웹 애플리케이션 개발자가 점검해야 할 사항

무슨 일이 있었나요?

2026년 10월 17일(세계표준시), 일본 시간으로 10월 18일에 연구자들이 문제를 보고했습니다. eMudhra는 디지털 인증서를 발급하는 인증기관(CA)입니다. 이 회사의 중간 CA 키 8개의 개인 키를 제3자가 쉽게 알아낼 수 있었습니다. 그중 6개는 HTTPS 암호화(TLS)에 쓰였고, 2개는 소프트웨어 서명(코드 서명)에 쓰였습니다.

핵심 숫자와 사실

• 키는 P-384 타원 곡선 방식을 사용했습니다. 이론상 약 384비트 범위의 값을 가질 수 있어야 합니다.
• 하지만 각 키의 비밀 숫자는 항상 256보다 작았습니다. 즉 실제 강도는 약 8비트뿐이라 추측하기 쉬웠습니다.
• 영향을 받은 중간 CA 키는 8개입니다. TLS용 6개, 코드 서명용 2개입니다.
• 암호화 방식 자체가 깨진 것은 아닙니다. 문제는 키를 만드는 방법이 잘못된 것이었습니다.

왜 인증서 체인이 중요한가요?

HTTPS는 데이터를 암호화할 뿐 아니라, 상대가 진짜 서버인지도 확인합니다. 서버 인증서는 도메인 이름과 공개 키를 묶어 줍니다. 브라우저는 운영체제나 브라우저가 믿는 루트 CA에서 시작해 중간 CA, 서버 인증서로 이어지는 인증서 사슬을 확인합니다. 사슬이 믿을 수 있는 루트까지 이어지면 브라우저는 그 사이트를 믿습니다.

왜 중요한가요?

도난당한 TLS 키가 있으면 공격자는 다른 사람의 도메인에 대한 인증서를 만들 수 있습니다. 이 CA를 믿고 추가 검사를 하지 않는 프로그램은 그 인증서를 진짜로 받아들입니다. 더 큰 위험은 단순한 피싱이 아닙니다. 피싱 사이트도 이미 정상 인증서를 받을 수 있기 때문입니다. 진짜 위험은 회사 업무 포털 같은 실제 사이트를 경고 없이 흉내 낼 수 있다는 점입니다. 다만 공격자가 가짜 와이파이나 조작된 DNS 서버 등으로 피해자의 접속 경로를 바꿔야 한다는 조건은 여전히 필요합니다. 코드 서명 키는 또 다른 위험이 있습니다. 가짜 서명으로 악성 소프트웨어가 믿을 만한 것처럼 보일 수 있습니다.

개발자가 확인할 점

• 서버, 컨테이너, CI/CD 시스템, 데스크톱 앱, 개발 환경마다 영향을 받는 CA가 있는지 확인하세요.
• 필요하면 영향을 받은 루트 CA에 대한 신뢰를 제거하세요. 다만 Java, Python certifi, Node.js는 자체 인증서 저장소를 쓰므로 따로 확인해야 합니다.
• curl, Git, AWS CLI 같은 명령줄 도구를 점검하고, 업데이트하거나 CA 번들 설정을 바꾸세요.
• 브라우저 차단 목록과 공급업체 수정 사항을 지켜보세요. Sectigo 루트를 제거하면 Sectigo 인증서를 쓰는 일부 웹사이트가 접속되지 않을 수 있습니다.