10월 17일, 한 연구자가 브라우저 제조사들에 한꺼번에 제보를 넣었습니다. 인도의 인증기관 eMudhra가 발급한 중간 CA 8개의 비밀키를 자기가 가지고 있다는 내용이었습니다. 어딘가에서 훔쳐 온 것이 아니라, 누구나 내려받을 수 있는 공개 인증서만 보고 계산해 냈다고 했고요. 구글은 제보를 받고 한 시간 사십 분 만에 차단 목록을 배포했습니다. 모질라도 같은 날, 애플은 19일, 마이크로소프트는 20일에 막았습니다.
계산해 냈다니, 무슨 말일까요?
타원곡선 키쌍은 생각보다 단순한 물건입니다. 비밀키는 그냥 수 하나입니다. d라고 해 두죠. 공개키는 곡선 위에 정해진 출발점 G를 d번 더한 결과 지점입니다. 인증서에 실려서 세상에 공개되는 것은 이 도착 지점이고, 출발점도 공개돼 있습니다. 그러니까 여러분이 인증서를 열어 보면 "G에서 출발해 d번 뛰었더니 여기 도착했다"는 말까지는 다 읽을 수 있습니다. 안전의 근거는 그다음입니다. 도착 지점을 보고 몇 번 뛰었는지를 거꾸로 알아내는 것이 현실적으로 불가능하다는 것. P-384 곡선이면 d가 384비트짜리 수라서, 하나씩 세어 보는 방법으로는 우주가 끝날 때까지 못 찾습니다.
그런데 이 여덟 개는 d가 전부 256보다 작았습니다. 48바이트짜리 수여야 하는데 앞의 47바이트가 전부 0이고 마지막 한 바이트에만 값이 들어 있었습니다. 그러면 할 일은 하나뿐이죠. 한 번 뛴 지점, 두 번 뛴 지점, 세 번 뛴 지점을 차례로 계산해서 인증서에 적힌 지점과 같은 것을 찾으면 됩니다. 많아야 255번입니다. 실제로 한 보안 연구자가 노트북으로 여덟 개를 전부 1초 안에 복구했습니다. 나온 값은 4, 56, 66, 115, 155, 156, 230, 237. 하나는 정말로 숫자 4였습니다.
그러니까 이 비밀키들은 유출된 적이 없습니다. 2025년 4월에 인증서가 만들어진 그날부터 인증서 안에 사실상 적혀 있었던 셈입니다.
중간 CA라는 자리가 왜 문제인지도 같이 봐야 합니다. 브라우저가 직접 믿는 것은 많아야 수백 개쯤 되는 루트 인증서뿐입니다. 루트가 중간 CA를 서명하고, 중간 CA가 개별 사이트의 인증서를 서명합니다. 그리고 중간 CA에는 보통 "너는 이 도메인만 서명해라" 같은 제약이 걸려 있지 않습니다. 중간 CA의 비밀키를 손에 넣으면 은행이든 메일 서비스든 원하는 도메인 이름으로 브라우저가 믿는 인증서를 직접 찍어 낼 수 있다는 뜻입니다. 이번 여덟 개 중 여섯 개가 웹 인증서 발급용, 그러니까 도메인을 위조할 수 있는 쪽이고 나머지 두 개는 코드 서명용이었습니다.
그러면 약 17개월 동안 왜 큰 사고가 안 났을까요. 인증서 투명성(Certificate Transparency) 덕이 컸습니다. 크롬은 공개 로그에 기록되지 않은 인증서를 기본적으로 거부하는데, 웹 인증서용 여섯 개에서 내려온 인증서가 이 로그에 올라온 적이 한 번도 없었습니다. 다만 사고가 없었다는 증명은 아닙니다. 로그를 강제하지 않는 쪽, 그러니까 브라우저가 아닌 클라이언트들은 이 보호를 받지 못한 채로 17개월을 보냈습니다.
여기가 오늘 실무자가 손을 대야 할 지점입니다. 브라우저는 제조사가 직접 밀어 넣는 차단 목록을 쓰기 때문에 몇 시간 만에 막혔습니다. 사용자가 업데이트를 누를 필요도 없었습니다. 그런데 그 목록을 읽는 것은 브라우저뿐입니다. 컨테이너 이미지에 구워져 있는 ca-certificates, 자바의 cacerts, Node와 Go와 파이썬 certifi가 들고 있는 번들, 상호 인증용으로 올려 둔 CA 목록, 펌웨어에 박아 넣은 신뢰 스토어 — 이쪽에서는 지금 이 순간에도 아무 일도 일어나지 않습니다. 런타임 쪽은 벌써 긴급 업데이트가 나온 곳도 있지만, 어차피 패키지를 올리고 이미지를 다시 빌드해서 재배포해야 바뀝니다. 간접 의존성으로 딸려 들어온 번들까지 훑어야 하고요. 브라우저로 열어 보고 멀쩡하니 됐다고 넘기면 안 됩니다. 애플리케이션이 실제로 타는 TLS 경로를 각각 확인해야 합니다. 그리고 오류가 거슬린다고 인증서 검증을 끄는 것이 제일 나쁜 선택입니다. 하나 더, 10월 27일부터는 이 중간 CA들을 서명한 eMudhra의 ECC 루트를 제거한 설정이 크롬 사용자 전체에 적용됩니다. 그 루트에 체인이 걸린 인증서가 약 3만 장으로 추산되니, 조달 담당자가 챙길 일이 하나 생긴 셈입니다.
생각해 볼 것이 하나 더 있습니다. 공개키는 이름 그대로 공개돼 있고, "이 인증서의 비밀키가 터무니없이 작은 수는 아닌가"를 확인하는 비용은 1초입니다. 그런데 이번 결함은 한 해 반이 지난 뒤에 연구자 한 사람의 손에서 나왔습니다. 구글이 자기 루트 스토어의 다른 키들도 같은 문제가 없는지 점검해 봤다고 밝힌 것 역시 사고가 터진 다음이었고요. 그렇다면 공개 신뢰 CA들의 공개키를 상시로 긁어서 이런 검사를 돌리는 공용 장치가 아직 없다는 이야기가 됩니다. 예측은 아닙니다. 다만 그런 장치가 없다면 다음 결함도 똑같이 사후에, 누군가의 호기심으로 발견될 거라는 가정입니다.
eMudhra의 설명으로는 2025년 4월 키 생성 의식에서 쓴 스크립트에 오류가 있었고, 그 바람에 약한 키쌍이 한 벌 더 만들어졌는데 이름표가 비슷해서 사람이 그걸 집어 들었다고 합니다. 근본 원인은 아직 확정되지 않았고, 회사는 지금까지 치른 키 생성 의식을 전부 다시 들여다보겠다고 했습니다. 인터넷의 신뢰가 결국 난수 하나에 기대고 있었다는 게 새삼스럽고, 우리 이미지 안에 박힌 CA 번들은 마지막으로 언제 갱신됐나 괜히 찾아보게 되네요.
커버 이미지: 하드웨어 보안 모듈(HSM) nShield F3 — Wikimedia Commons, Alexander Klink
전체 사이트에서 댓글·관련 글을 함께 보시려면
이야기 공장에서 보기 →