eMudhra, 키 이전 스크립트 오류로 약한 중간 인증서 발급…RSA 8개도 추가 폐기

eMudhra는 11월 10일 공개한 사후 사고 보고서에서 2025년 중간 인증서 키를 이전하는 시험 과정의 오류가 HSM 자체가 아니라 자체 Python 스크립트와 절차에서 비롯됐다고 밝혔습니다. 앞서 영향을 받지 않았다고 설명했던 RSA 중간 인증서 8개도 자체 키 관리 규정에 맞게 취급됐는지 입증하지 못해 11월 7일 추가 폐기했습니다.

인증기관(CA)은 웹사이트나 조직의 신원을 확인하는 디지털 인증서를 발급합니다. 중간 인증기관의 개인키는 여러 웹사이트의 TLS 인증서에 서명하는 데 쓰입니다. 공격자가 그 키를 얻으면 자신이 통제하지 않는 도메인의 가짜 인증서를 발급해 실제 사이트로 가장할 수 있습니다. Mozilla는 2026년 10월 17일 신고된 eMudhra 중간 인증서 8개의 개인키를 직접 복구해 키 생성 과정에 결함이 있음을 확인했다고 Bugzilla에 기록했습니다. 이 가운데 6개는 TLS용, 2개는 코드 서명용이었습니다.

문제가 된 키들은 2025년 4월 30일 생성한 B·C 계열 중간 인증서용 키쌍입니다. eMudhra 보고서에 따르면 16개 키쌍을 HSM에서 생성했으며, 8개는 P-384 타원곡선 키, 8개는 RSA 키였습니다. 회사는 키를 미국과 유럽 데이터센터로 옮길 예정이었지만 장비 운송이 늦어졌습니다. 6월 15일 적용될 인증서 정책과 Sectigo 교차 서명 기한에 맞추려면 5월 말 전 키 생성이 필요해, 목적지 장비가 도착하기 전에 키를 만들고 이전 절차를 시험했다고 설명했습니다.

키 래핑은 HSM에 보관한 키를 다른 장비로 옮길 때 암호화된 형태로 감싸 내보내고 목적지 HSM에서 푸는 절차입니다. HSM은 키를 생성·보관하는 전용 하드웨어입니다. eMudhra는 이전 절차를 시험하려고 자체 Python 스크립트를 작성했습니다. 보고서에 따르면 4월 시험에서는 HSM의 FIPS 승인 모드를 끄고, 스크립트가 키를 푼 뒤 호스트 컴퓨터 메모리에서 값을 다시 읽어 새 키 객체를 만들었습니다.

문제는 이 값을 읽는 과정에서 생겼습니다. 스크립트가 P-384 개인키 값을 한 바이트 수준으로 잘라냈고, Mozilla는 영향을 받은 키 값이 모두 256 미만이었다고 기록했습니다. eMudhra는 원래 생성한 키와 새로 만든 키의 라벨이 거의 같아 약한 복사본을 잘못 골라 인증서 서명 요청(CSR)에 넣었다고 설명했습니다. 루트 CA는 CSR에 담긴 공개키를 포함한 중간 인증서를 서명해 발급했습니다.

인증서 발급 전에는 키의 강도를 검사하거나, 인증서 요청에 쓰인 공개키가 HSM에서 처음 만든 공개키와 같은지 대조하지 않았습니다. eMudhra는 두 검사 가운데 하나만 있었어도 약한 키를 발견했을 것이라고 밝혔습니다. 약한 개인키로도 유효한 서명을 만들 수 있어 인증서가 두 차례 감사 과정에서 걸러지지 않았다는 설명도 내놨습니다.

회사는 앞서 RSA 발급기는 다른 경로를 거쳐 영향을 받지 않았다고 설명했습니다. 이번 보고서에 따르면 Python 스크립트의 P-384 키 값 잘라내기 오류는 RSA 키 값에 같은 영향을 주지 않았습니다. 다만 RSA 키의 속성은 Python 프로세스가 실행된 컴퓨터의 휘발성 메모리에 있었습니다. 결함이 있는 읽기 코드는 2025년 7월 실제 키 반입에 사용되지 않았지만, 첫 반입 작업이 끝나지 않아 다시 진행됐습니다. eMudhra는 이 과정에서 자체 규정에 맞게 키를 다뤘는지 입증하지 못해 RSA 중간 인증서 8개를 추가 폐기했다고 밝혔습니다. 회사는 RSA 키 자체의 무결성은 유지됐다고 설명했습니다.

처음 문제가 된 중간 인증서 8개는 2026년 10월 18일 폐기됐으며, 주요 브라우저와 운영체제 공급사도 차단 조치를 진행했습니다. RSA 인증서의 추가 폐기는 개인키가 약화됐다는 판정이 아니라, 키 관리 규정 준수를 입증하지 못한 데 따른 조치입니다.