8비트의 신뢰, eMudhra의 CA 개인 키가 밀리초 만에 복구됨

eMudhra의 중간 인증기관 8개가 사용한 P-384 개인 키가 모두 한 바이트 값에 불과했으며, 공개 인증서만으로 노트북에서 1초 안에 전부 복구됨 정상적인 P-384 개인 키는 무작위 384비트 값이어야 하지만, 해당 키는 최대 255번의 계산으로 찾을 수 있었음에도 인증서의 구조적 검사를 모두 통과함 Chrome과 Firefox는 해당 중간 인증서를 차단했으며, Chrome은 인증서 투명성(CT) 검사 덕분에 이 CA를 이용한 위조 TLS 인증서가 기본 설정에서 신뢰받을 수 없었다고 확인함 기본적으로 폐기 여부와 CT를 확인하지 않는 비브라우저 TLS 클라이언트는 여전히 영향을 받을 수 있으며, 로컬 실험에서 curl, Python, Node가 위조한 api.stripe.com 인증서를 받아들임 CA 번들 업데이트와 컨테이너 이미지 재빌드가 필요하며, 업데이트할 수 없는 기기는 인증서 만료 시점인 2039년 7월까지 해당 인증서를 신뢰할 수 있음 신고와 브라우저의 차단 조치 2026년 10월 17일 토요일, 보안 연구자가 Apple, Google, Microsoft, Mozilla, eMudhra에 중간 인증서 8개의 개인 키 노출을 신고함 Chrome은 당일 저녁 CRLSet 업데이트로 차단했고, Mozilla는 몇 시간 뒤 OneCRL을 통해 Firefox에서 차단함 10월 20일 Mozilla는 사건을 공개하고 eMudhra 루트를 제거한 NSS 업데이트를 배포함 Chrome은 Chrome Root Store v43에서 해당 루트를 제거한다고 확인함 대상은 TLS 발급 CA 6개와 코드 서명 CA 2개이며, 모두 2025년 4월 생성됨 TLS CA는 DV, OV, EV 각각 두 세대로 구성됨 모두 2025년 5월 Sectigo의 AAA Certificate Services 루트로도 교차 서명됨 P-384 키가 8비트로 줄어든 방식 P-384 타원곡선에서 개인 키는 숫자 d, 공개 키는 d × G 임 G는 모두가 사용하는 고정된 곡선 위 점이며, 곱셈은 타원곡선 연산으로 G를 d번 더하는 것에 해당함 개인 키로 공개 키를 계산하기는 쉽지만, 공개 키에서 개인 키를 역산하기는 현실적으로 불가능해야 함 이 보안 모델은 충분히 큰 무작위 개인 키를 전제로 함 정상적인 P-384 개인 키는 무작위 384비트 값으로, 가능한 값의 수는 약 2³⁸⁴, 즉 약 10¹¹⁵개임 문제의 키 8개는 모두 앞의 47바이트...