요약
이무드라의 중간 CA 인증서 8개는 개인 키가 255 이하의 숫자여서 노트북으로 1초도 안 걸려 풀렸습니다.
보안 연구자 스콧 헬름의 분석입니다. 10월 17일 한 연구자가 이무드라 중간 인증서(루트 아래에서 실제 인증서를 발급하는 인증서)의 키가 노출됐다고 알리자 Chrome과 Firefox가 곧바로 차단했습니다. 모질라와 구글은 이무드라 루트 인증서도 빼기로 했습니다.
왜 중요한가
- 키를 훔칠 필요 없이 누구나 계산으로 얻을 수 있었으므로, 약 17개월 동안 누가 키를 가졌는지 알 길이 없습니다.
- 브라우저는 인증서 투명성(CT, 발급 인증서를 공개 기록하는 제도) 덕에 대체로 안전하지만 curl·Python·Node는 위조 인증서를 믿습니다.
- 업데이트할 수 없는 공유기·프린터·TV는 만료일인 2039년 7월까지 이 인증서를 계속 신뢰합니다.
핵심 내용
- 키는 P-384 타원곡선 키인데 마지막 1바이트만 값이 있어, 많아야 255번 계산하면 찾을 수 있었습니다.
- 실제 키 값은 4, 56, 115처럼 작은 수였고, 헬름은 공개된 인증서만으로 8개를 모두 되찾았습니다.
- 대상은 2025년 4월에 만든 TLS 발급용 6개와 코드 서명용 2개이며, 섹티고 루트의 교차 서명까지 합쳐 16개 인증서가 영향을 받습니다.
- 헬름이 위조한 api.stripe.com 인증서를 리눅스와 맥의 curl, Python, Node가 기본 설정에서 모두 받아들였습니다.
- 이무드라는 키 생성 스크립트 오류로 약한 키 쌍이 함께 만들어졌고, 이름이 비슷해 그 키를 잘못 썼다고 해명했습니다.
HN 반응
- 처음 신고한 연구자는 구글의 공개 도구 paranoid_crypto를 그대로 돌려 찾았다며, 다들 남이 했으리라 여긴 기본 점검이 빠져 있었다고 밝혔습니다.
- CA 감사가 인증받은 키 생성기를 쓰는지 같은 절차만 본다는 지적에, 그런 생성기가 4를 내놓을 리 없으니 검사가 허술했을 뿐이라는 반론이 붙었습니다.
최초 제보자인 웨인이 새 메일을 보냈습니다.
"*이걸 어떻게 발견했느냐고 묻는 메일을 꽤 많이 받았습니다. 답은 간단합니다. https://github.com/google/paranoid_crypto 입니다.
네, 별다른 설정 없이 그대로 돌렸습니다. CCADB는 가입자 인증서를 살펴보기 전에 빠르게 돌려 보는 코퍼스 테스트 정도로 생각했습니다...
CCADB에 있는 기존 인증서는 훨씬 더 꼼꼼하게 전부 검사했고, 다행히 더 나온 것은 없습니다. 제 시간은 대부분 '누군가 이미 했겠지' 하고 모두가 넘어간 기본적인 부분을 훑는 데 들어갔습니다. 보안 근처에서는 절대 해서는 안 되는 치명적인 실수입니다.
그러니 누군가 훨씬 많은 연산 자원이나 더 앞선 암호 해독 연구에 접근할 수 있는 게 아니라면, 손쉽게 딸 수 있는 열매는 지금까지 다 걸러졌다고 봐야 합니다.*"
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE
솔직히 제가 비밀번호 크래커를 만든다면 "1"부터 시작할 생각은 못 했을 것 같아요.
당연하죠, 우리는 음수 0부터 시작하니까요.
https://en.wikipedia.org/wiki/Signed_zero
학교에서 "음수 0"이라는 개념을 배웠던 게 아직도 기억에 남아요. 교수님이 1의 보수 때문에 한참 머리를 싸매게 만든 다음, 십계명 돌판을 들고 산에서 내려오는 모세처럼 2의 보수를 소개해 주셨던 수업이었거든요.
저는 술집에 들어가면 일단 바텐더에게 음수 0잔을 달라고 해요. 가게 분위기를 살펴보려고요. 진짜 주문은 그다음이고요.
아직 방화범으로 몰린 적은 없지만, 시간문제겠죠.
글쎄요, 저는 비밀번호 크래킹을 돌릴 때 항상 아주 짧은 비밀번호부터 무차별 대입으로 훑습니다. 그래도 크래킹 시간은 거의 늘지 않고, 짧은 비밀번호를 허용하는 시스템에서 그런 게 의외로 많이 나오거든요.
제가 이해하기로는 N 이하의 개인 키는 √N 단계면 깨뜨릴 수 있습니다. 어떤 임계값을 썼는지는 모르겠지만, 아마 작은 개인 키를 대상으로 스캔을 돌렸을 겁니다.
그건 사실이 아닌 것 같은데요. 출처 있으세요?
baby-step giant-step 알고리즘이라는 건데, Mozilla에 올라온 제보 스레드에도 언급돼 있습니다.
"baby-step giant-step 이산 로그 알고리즘으로 거의 즉시 복구할 수 있고, 더 단순하게는 '처음' 256개의 P384 키를 생성해 보기만 해도 됩니다."
이 저장소는 2026년 8월 19일에 소유자가 보관 처리했습니다. 이제 읽기 전용입니다.
이제 확인도 마쳤으니 이런 실수는 앞으로 아무도 안 할 테고, 그래서 더 필요 없다는 거겠죠? :)
보관(archive) 처리는 그냥 방치해서 썩게 두는 것과 아예 삭제하는 것 사이의 괜찮은 절충안입니다. 저장소를 열어 둔 채로 두면 이 코드베이스가 더 이상 개발되지 않는다는 사실이 사용자에게 바로 전해지지 않아서, 마지막 커밋이 언제인지 직접 확인해야 하거든요. 그마저도 알 수 있는 게 많지 않습니다. 이 앱이 워낙 단순해서 오랫동안 고치거나 올릴 게 없는 걸까요? 오래된 파일 형식을 개방형 형식으로 바꿔 주는 파이썬 스크립트는 사실상 완성되어 더 추가하거나 고칠 것도, 악용할 만한 위협 경로도 없을 수 있습니다. 아니면 누군가 수년간 매일 커밋하던 최첨단 앱인데 지금은 1년째 멈춰 있는 걸까요?
보관 처리에서 마음에 들지 않는 점은 새 이슈를 등록할 수 없다는 것입니다. 새로운 문제를 발견해도 굳이 포크해서 그 이슈를 제가 직접 추적하고 싶지는 않습니다. 코드를 책임지고 싶은 게 아니라, 관심 있는 누군가가 고칠 수 있도록 알려만 주고 싶을 뿐이니까요.
보관 처리했다는 건 저장소는 그대로 볼 수 있지만 더는 개발하지 않는다는 신호입니다.
어차피 마지막 커밋도 2년 전이고요.
우리 대신 NSA가 계속 확인해 주겠죠, 뭐.
아마 이 코드일 것 같습니다.
https://github.com/google/paranoid_crypto/blob/main/paranoid_crypto/lib/ec_single_checks.py#L91
돌이켜 보면 신뢰하는 인증 기관이 100개나 되는 건 지나쳤는지도 모르겠네요.
돌이켜 보면 아주 사소한 역량 검사조차 없었다는 게 허점이었나 싶네요.
역량은 체계적으로 검사하기가 어렵습니다. 문제는 감사 절차에 있습니다. 인증 기관 감사관이 확인하는 목록은 FIPS 준수가 필요한 애플리케이션이 받는 검사보다 훨씬 짧습니다. 인증 기관이 FIPS를 준수하는 키 생성기를 쓰는지, 그리고 기록이 남는 표준적인 다인 절차를 따르는지 같은 기본적인 것만 확인합니다.
은행이나 정부용 시스템을 만드는 사람은 코드 한 줄 한 줄이 암호 키를 가지고 멍청한 짓을 하지 않는지 전부 검사받아야 합니다. 그 정도 수준의 보증이었다면 이 문제를 잡아냈을 겁니다. 하지만 절차가 너무 느슨하게 정의돼 있었습니다.
(번역: 인증 기관이 FIPS를 준수하는 키 생성기를 쓰는지, 그리고 기록이 남는 표준적인 다인 절차를 따르는지 같은 기본적인 것만 확인합니다.)
FIPS를 준수하는 키 생성기가 키 값을 4로 만들어도 된다고요?
아니죠, 그냥 충분히 꼼꼼하게 확인하지 않은 겁니다.
키 생성기는 FIPS 인증을 받은 HSM이었고, 강력한 키를 만들어 냈습니다. 그런데 그 키를 어떤 한심한 스크립트에 통과시켰고, 그 스크립트가 마지막 바이트 하나만 남기고 나머지 바이트를 전부 0으로 만들어 버렸습니다. 전체 FIPS 감사의 요점은 암호 관련해서 뭘 직접 구현하려 드는 것 같은 멍청한 짓을 하지 않고, 인증받은 구현만 쓰는지 확인하는 것입니다. 그런데 그 기준이 CA에는 적용되지 않는 모양입니다. 키를 생성할 때만 FIPS 모듈을 쓰면 되고, 그 뒤로는 어떤 바보짓을 해도 상관없습니다. 진짜 문제는 바로 거기에 있습니다.
스크립트가 개인 키를 0으로 만들어 버렸다면 공개 키가 더는 동작하지 않는 거 아닌가요?
공개 키는 개인 키에서 계산되기 때문에 전부 그대로 동작합니다. 개인 키가 4인 공개 키일 뿐입니다.
물론 그렇죠. 이것들이 만들어지던 당시에는 크래킹이 훨씬 더 큰일이었을 거고요. 그래도 4라니요.
이 키 4는 새로 연 키 세리머니에서 나온 겁니다. 아마 가장 높은 보안 수준의 키까지 최근에 다 써 버려서 한 바퀴 돌아 처음으로 돌아온 거겠죠.
그것도 하나의 가설이죠. 또 다른 가설은 명령어를 잘못 입력했는데 그냥 그대로 밀고 나갔다는 거고요.
제 말은, 오타라기보다는 누가 아무 숫자나 마구 쳐 넣은 것처럼 키가 생겼다는 거예요. 게다가 회사도 절차에서 벗어난 부분이 있었다고 밝혔고요.
"신뢰하는 인증 기관"을 어떻게 정의하느냐에 따라 달라집니다.
루트 인증서를 말한다면 주요 운영자 중 적어도 한 곳이 현재 신뢰하는 것이 약 350개입니다.
중간 인증서까지 포함하면 3,600개가 넘습니다!
인증서 투명성(Certificate Transparency) 요건은 사실상 인증 기관에서 권한을 빼앗는 겁니다.
대신 자기 도메인에 대해 아무도 부정하게 인증서를 발급하지 않았는지 확인할 부담을 다시 개별 웹마스터에게 지웁니다. 악의적일 수 있는 CT 로그와 관련된 새로운 취약점도 몇 가지 있고요.
그게 도메인 소유자에게 지워지는 부담이라는 데는 동의합니다. 그런데 'scotthelme.co.uk'의 인증서가 발급돼도 되는지 아닌지를 'scotthelme.co.uk'의 소유자인 저 말고 누가 알 수 있겠어요?
악의적인 CT 로그에 관한 정보가 있으신가요? 관련 글이 있으면 읽어 보고 싶습니다!
CT 로그가 도메인 이름이나 IP 주소 공간에 관한 정보, 혹은 구현 세부 사항을 통해 원래는 공개되지 않았을 다른 정보를 드러내는 경우가 아닐까요.
CT 로그가 증명은 붙여 주면서 정작 그 인증서를 로그에는 넣지 않는 경우요.