요약
이무드라가 최근 인증서 사고 뒤 글로벌 SSL/TLS 인증서 사업에서 스스로 물러나기로 했습니다.
인도의 디지털 인증 기업 이무드라가 10월 22일 보도자료로 이사회 결정을 알렸습니다. 전날에는 일부 중간 인증기관(CA, 웹사이트 인증서를 발급하는 기관)과 루트 CA 하나의 신뢰 철회에 관한 입장문을 냈습니다.
왜 중요한가
- 사고를 낸 인증기관이 브라우저의 신뢰 철회 직후 웹 인증서 시장을 떠나는 셈입니다.
- 이 회사 인증서를 쓰는 고객은 전환 기간 안에 다른 파트너의 인증서로 바꿔야 합니다.
- 회사는 이 사업이 매출의 1% 정도라며 전자서명·기업용 PKI(인증서 기반 보안 체계) 같은 나머지 사업은 영향이 없다고 선을 그었습니다.
핵심 내용
- 철수 이유로 데이터 주권(데이터를 특정 나라 안에 두라는 요구)과 규제 강화, 늘어나는 비용을 들었습니다.
- 일부 대형 기관이 인증서를 무료로 발급해 수익성이 떨어졌다고도 했습니다.
- 사고에 쏠린 소셜미디어의 관심이 사업 비중에 비해 지나치다고 주장했고, 사과는 하지 않았습니다.
- 문제의 CA는 발견 14시간 안에 폐기했고 최종 사용자 인증서 발급이나 데이터 유출은 없었다고 밝혔습니다.
- 전환이 끝날 때까지 G1 RSA 루트로 고객을 지원하고, 브라우저 루트 프로그램에 근본 원인 보고서를 내겠다고 했습니다.
HN 반응
- 많은 이용자가 소셜미디어 탓을 한 대목을 비판했고, 이 회사의 OTP 로그인도 뚫린다는 지적까지 나오며 다른 서비스도 믿기 어렵다는 말이 이어졌습니다.
- 스크립트 결함과 사람의 실수가 원인이라는 설명에, HSM(키를 만들고 보관하는 전용 장비) 업체 직원은 HSM을 제대로 썼다면 생길 수 없는 일이라고 반박했습니다.
비판의 강도는 그들이 쓴 개인 키의 비트 복잡도에 반비례하죠. 사과도 없고, 사람의 실수였는지 프로세스의 실수였는지 같은 사고 경위도 밝히지 않았으니 이쪽 입장에서는 꽤 나빠 보이는 게 당연해요.
이 시점에서 이것들에 보안이나 신뢰와 관련된 무언가를 맡기는 사람은 러시안룰렛을 하는 겁니다.
"여러 번의 인적 오류"였다고 합니다. 하지만 어떤 경우에도, 어떤 예외적인 상황에서도 이런 일은 일어나선 안 되었던 건 맞습니다.
eMudhra가 Mozilla 트래커에 밝힌 바에 따르면, 키는 2025년 4월 30일 키 생성 의식(key generation ceremony)에서 만들어졌습니다. 키 생성 의식은 키를 보관하도록 만들어진 변조 방지 장치인 하드웨어 보안 모듈(HSM) 안에서 키를 생성하는, 기록으로 남기는 절차입니다. 이 키들은 해당 지역에 데이터를 저장해야 하는 고객을 위해 미국과 유럽의 데이터센터로 옮겨질 예정이었습니다. 옮기기 위해 회사는 각 키를 '래핑(wrap)', 즉 전송용으로 암호화하고 반대편에서 '언래핑(unwrap)'하는 단계를 추가했습니다. eMudhra는 소프트웨어 스크립트의 결함 때문에 이 단계에서 더 약한 두 번째 키 세트가 만들어졌고, 두 세트의 이름이 비슷해서 직원들이 실수로 약한 쪽을 썼다고 설명했습니다. 또한 여러 단계에서 인적 오류가 있었다고 밝혔습니다.
출처:
What's the eMudhra security scare that has rattled the internet?
https://theprint.in/tech/whats-the-emudhra-security-scare-that-has-rattled-the-internet-all-you-need-to-know/3077744/
이 "래핑" 키들은 "더 약한" 정도가 아니었어요. 목적에 아예 맞지 않는 물건이었죠. 이 용도에 왜 3비트짜리 키를 썼는지는 설명도 없고요.
굳이 래핑까지 하는 수고를 들일 거면 제대로 된 키를 쓰세요. 아니면 하지를 말든가요.
그리고 이걸 1년 반 동안 눈치채지 못한 것도 엄청난 "인적 오류"예요.
그 3비트 숫자는 HSM의 슬롯이나 인덱스였고, 실제 키를 가져오는 대신(아니면 가져오기는 했는데) 슬롯 번호가 그대로 키로 쓰인 게 아닐까 싶습니다. 그렇지 않고서야 그렇게 작은 숫자의 키가 어떻게 생성됐는지 상상이 안 됩니다...
이런 장치와 인터페이스를 다뤄 본 경험으로 말씀드리면, 일부러 약한 키를 만들려던 건 아니었을 거라고 봅니다.
위치 기반 인자를 쓰는 식으로 스크립트가 파라미터를 엉뚱한 필드에 넣었거나, 어떤 인터페이스의 문서를 잘못 읽었을 가능성이 더 높습니다.
그래도 무능인 건 마찬가지입니다. 제 가설이 맞는지 틀린지 확인되는 걸 꼭 보고 싶네요.
지난 토론에서는 문자열 처리를 잘못했을 거라는 가설이 나왔어요. 예를 들어 Python에서
key가 배열이라고 생각하고output = key[0]을 썼는데 실제로는 문자열이면, "4" 같은 1바이트짜리 키가 나오거든요.이건 장치와 인터페이스의 문제가 아닙니다. 래핑 키는 HSM 안에서 직접 생성하게 되어 있습니다. 그러면 HSM이 키가 충분히 강한 보안 파라미터로 생성되도록 보장하지, 1바이트짜리 우스꽝스러운 문자열 같은 건 나오지 않습니다. 그런 다음 HSM이 내부에서 키를 래핑해 암호화된 형태로 내보냅니다. 이 암호문과 래핑 키를 상대방에게 보내면 됩니다.
그러니 래핑 키를 이상한 값으로 생성했다면 HSM으로 생성하지 않고 시스템의 openssl로 만들었다는 뜻입니다. 그런데 HSM은 보통 보안 플래그를 건드리지 않는 한(전혀 권장하지 않습니다) 개인 키를 래핑하지 않고는 내보내지 못하게 합니다. 아니면 개인 키 자체도 시스템 openssl로 생성하는 수밖에 없죠(ㅋㅋㅋ).
출처: 저는 주요 HSM 벤더 중 한 곳에서 일합니다.
이런 실수가 보통 어떻게 일어나는지는 공감합니다. 그런데 스크립트가 애초에 왜 키를 두 세트나 만들었을까요? 직접적인 원인은 누군가 강한 키가 아니라 약한 키를 골랐다는 거지만, 애초에 약한 키를 만들어 낸 이유는 뭐죠? 스크립트가 결과물을 두 개 만들었다고 하는데, 대체 무슨 용도로요??
한 걸음 물러서서 이 작업의 취지와 무게를 생각해 보면, 왜 그냥 직접 들고 날아가지 않았는지 궁금해집니다.
맞아요. 개발 과정에서 프로덕션급 키를 안 쓰는 경우가 어디 있겠어요. 사실 우리도 개발할 때는 snake oil 키를 그렇게 쓰고요.
"4"짜리 키를 만든 건 아마 농담이었겠지만, 어떤 개발자의 컴퓨터 밖으로 한 번이라도 나갔다는 것 자체가 제정신이 아니에요.
소셜 미디어 탓을 하는 걸 보니 "저 참견쟁이 꼬마들만 아니었으면 들키지 않고 넘어갔을 텐데" 하는 냄새가 폴폴 나요. [1]
[1] https://www.youtube.com/watch?v=hXUqwuzcGeU
들킨 것, 그리고 덮지 못한 것에 대해 깊이 진심으로 사과드립니다.
안타깝게도 인도에서는 꽤 흔한 일입니다. 정실 자본주의가 이 나라의 지배적인 사업 동력이라, 특히 정부 의무 서비스(eMudhra 사업의 대부분이 여기에 속합니다) 같은 규제 분야에서는 어떤 의미 있는 사업도 상당한 뇌물 없이는 시작조차 할 수 없습니다.
그 결과 이런 기업들은 정상적인 시장의 힘에서 아주 잘 보호받고 사실상 법 위에 있습니다. 이번 일이 국제적인 사건이 아니었다면 충분히 그냥 넘어갈 수 있었을 테고, 이 사실을 보고한 사람들은 감옥에 갔을 겁니다.
100% 정확한 말씀입니다. 국제적인 사건 대응이 아니었다면 국영 언론이 이 기사를 눌러 버렸을 겁니다. 국가 이미지에 영향을 주고 사회 불안을 일으킬 수 있다는 이유로 이런 공개를 막는 연방법도 있고요.
이 주제를 잘 아시는 것 같아서 여쭙습니다.
시스템이 사람들을 그렇게 만드는 걸까요, 아니면 사람들 때문에 시스템이 그렇게 된 걸까요?
그런 시스템 출신과 거래하시겠습니까(즉, 신뢰하시겠습니까)?
닭이 먼저냐 달걀이 먼저냐 하는 질문이라고 봅니다. 서로를 강화하는 순환 고리가 되죠.
거래에 관해서라면, 남을 이용해 먹는 문화가 있는 부패한 사회 출신은 당연히 같은 동네에서 자란 사람보다 더 조심스럽게 대해야 합니다.
저도 다른 나라로 이주해서 모두에게 열린 마음으로 너그럽게(시간도, 자원도, 도와주려는 마음도) 대했다가, 어떤 문화권 사람들은 그런 태도를 약함으로 착각하고 최대한 이용하려 든다는 걸 깨닫는 쓴 경험을 하고 배운 교훈입니다.
어느 나라인가요? 피해 가게요.
법원 문제입니다. 법원은 오류를 바로잡는 장치 역할을 하게 되어 있습니다. 법원이 실패하면 나라는 개루프 제어 상태에 들어갑니다. 어떤 오류도 바로잡히지 않고, 결국 사람들은 오류를 알아차리는 것조차 그만두게 됩니다. https://x.com/captgouda24/status/2110089855380369511
엄격하게, 그리고 지속적으로 검증하세요! 작은 거래로 시작해서 개인적인 신뢰를 바탕으로 키워 가세요. 시스템에 책임을 묻는 장치가 없으니 그건 직접 확인해야 합니다.
우리 의료 데이터가 거기에 있다니 기가 막히네요.
의료 기관이나 보험사 등이 IT를 맡긴 곳과 어떤 계약을 맺었느냐에 따라 다릅니다.
출처: 저는 의료 IT 프로젝트를 하는데, 고객사와의 계약 때문에 미국 밖에 있는 사람은 누구도 프로덕션 데이터를 볼 수 없습니다. 예외는 없습니다.
그렇긴 한데, 그 말투가 얼마나 문화적인 걸까 하는 생각도 듭니다.
전 세계 여러 기업과 일하면서 느낀 건, 인도 쪽은 사고에 대응하는 서신이 내용에 명백히 근거가 없어도 강한 모습부터 보여 주려는 경향이 있다는 겁니다.
반면 서유럽 쪽 서신은 대체로 더 사과하고 공감하는 어조입니다. 피해를 본 사람들에게는 진심 없게 들릴 수도 있지만요.
하지만 결국 다 말일 뿐입니다. 비슷한 문제를 막고 아직 공개하지 않은 기존 문제를 해결하기 위해 기업이 실제 변화를 뒷받침할 의지가 없다면 별 의미가 없죠. 다만 그런 일이 일어나고 있는지 아닌지 우리로서는 알 방법이 없습니다.
특정 문화만의 문제인지는 모르겠습니다. 미국 기업들이 길고 긴 법적 공방을 거친 뒤를 보세요. 잘못한 게 뻔하고, 벌금을 내거나 법원이 정한 조치를 따라야 하는 상황인데도 보도자료는 이렇습니다.
"우리는 잘못을 인정하지 않습니다. 이 일을 매듭짓기 위해 합의할 뿐입니다. 우리 사업은 튼튼하고/안전하고/유능합니다."
기업 커뮤니케이션에 들어가면 가장 먼저 배우는 규칙이 절대 잘못을 인정하지 말고, 자신감과 정확함 말고는 아무것도 내비치지 말라는 것인 듯해요.
저쪽 OTP 솔루션도 무차별 대입이 가능합니다: https://mastodon.catgirl.cloud/@49016/117475921584308861
이러면 거꾸로 된 러시안룰렛이 되네요. 여섯 칸 중 딱 한 칸만 비어 있는 거죠.
이런 발표문이 나오기를 기다리는 중이에요. "... 이번 사건을 둘러싼 소셜 미디어의 증폭 수준은 우리 사업에서 OTP 1FA가 차지하는 비중에 비해 과도한 비판을 불러왔습니다. 이에 따라 면밀한 숙의 끝에 이사회는 글로벌 OTP 1FA 사업에서 철수하는 것이 eMudhra와 주주들에게 옳은 결정이라고 결론지었습니다"
어느 시점부터 글록으로 하는 러시안룰렛이 되는 걸까요?
러시안룰렛은 한 칸이면 충분합니다... 딱 한 번은요. 다만 두 번째 기회가 올 확률은 꽤 낮죠.
링크가 깨져 있습니다. 안드로이드의 Brave에서 열면 무작위로 생성된 텍스트가 나옵니다. AI 봇 탐지가 그리 좋지 않네요.
그 웹사이트는 어째서인지 제 브라우저를 AI 스크레이퍼로 판단하네요.
이게 오히려 더 심각하게 만드는 것 같아요. 아내에게 이 일을 설명하려는데, 저들이 한 짓만큼 터무니없는 비유나 우화가 도저히 생각나지 않아요. 좋은 비유 있으신 분?
예를 들면, 좌핸들과 우핸들 차량을 둘 다 만드는 공장에서 2년 내내 앞좌석이 두 개인 차를 만들었는데 아무도 눈치채지 못한 상황 같은 거 어떨까요?