펌웨어 업데이트 한 번에 하드웨어가 영구 박제된 사연: Dasharo 임시 키 사고 분석

안녕하세요. 8년차 개발자 김테크입니다.

보통 우리가 백엔드나 인프라 작업을 할 때 실수로 서버를 날려먹더라도, 백업이 있거나 스냅샷으로 롤백하면 그만인 경우가 많습니다. "되돌릴 수 있다"는 믿음이 우리를 과감하게 만들죠. 하지만 하드웨어, 그중에서도 보안과 직결된 펌웨어 레벨로 내려가면 이야기가 완전히 달라집니다. 오늘은 최근 펌웨어 업계에서 발생한 아주 오싹한 사고 하나를 소개해드리려 합니다. 바로 Dasharo TrustRoot 임시 키 사고입니다.

이 사건은 2025년 12월, NovaCustom의 V540TU 및 V560TU 모델을 사용하는 사용자들에게 발생했습니다. 결론부터 말하자면, 펌웨어 릴리스 과정의 실수 하나로 인해 해당 시기에 보안 설정을 적용한 기기들이 영원히 펌웨어 업데이트를 받을 수 없는 상태가 되어버렸습니다. 소프트웨어적인 복구가 불가능한, 말 그대로 물리적인 '낙인'이 찍혀버린 것이죠.

도대체 무슨 일이 있었던 걸까요?

사건의 발단은 '릴리스 엔지니어링'의 실수였습니다. Dasharo 펌웨어는 사용자가 직접 자신의 하드웨어 보안을 강화할 수 있도록 'Fusing(퓨징)'이라는 기능을 제공합니다. 이 작업은 기기의 CPU 칩셋 내부에 있는, 한 번 쓰면 다시는 지울 수 없는 메모리 공간(OTP: One-Time Programmable)에 암호화 키의 해시값을 기록하는 과정입니다.

문제는 사용자에게 배포된 펌웨어 바이너리가 실제 운영 환경용 '프로덕션 키(Production Key)'가 아닌, 테스트용으로 잠깐 쓰고 버리는 '임시 키(Ephemeral Key)'로 서명되어 있었다는 점입니다.

사용자들은 Dasharo Tools Suite(DTS)라는 도구를 이용해 평소처럼 보안 설정을 적용했습니다. DTS는 설계된 대로 완벽하게 작동했습니다. 펌웨어를 다운로드하고, 사용자의 동의를 얻어 하드웨어 퓨즈를 태웠죠. 하지만 그 퓨즈에 기록된 것은 '임시 키'의 해시값이었습니다.

이게 왜 치명적일까요? 여기서 인텔의 'Boot Guard' 기술을 이해해야 합니다.

Intel Boot Guard는 PC가 켜질 때 가장 먼저 실행되어, 지금 로드하려는 펌웨어가 진짜 제조사가 만든 것인지 검증합니다. 이때 CPU는 자신의 퓨즈(FPF)에 기록된 '공개키 해시'와 펌웨어에 들어있는 '공개키'를 비교합니다. 이 두 값이 일치해야만 부팅이 진행됩니다.

그런데 이번 사고로 기기의 퓨즈에는 '임시 키'의 정보가 영구적으로 박제되었습니다. 이 퓨즈는 하드웨어적으로 딱 한 번만 쓸 수 있습니다. 되돌릴 수 없죠. 이제 이 기기는 오직 '임시 키'로 서명된 펌웨어만 신뢰하게 됩니다. 하지만 그 임시 키는 테스트용이라 보안상 폐기되었거나, 실제 프로덕션 펌웨어를 서명하는 데 사용할 수 없습니다. 결과적으로 해당 기기는 앞으로 나올 어떤 정식 보안 업데이트도 설치할 수 없게 된 것입니다.

우리가 흔히 말하는 '오너 컨트롤 보안(Owner-Controlled Security)'의 양면성이 드러난 사례이기도 합니다. 기존에는 제조사가 모든 키를 관리했지만, Dasharo 모델은 사용자가 직접 최종 조립 단계의 보안 설정을 하도록 권한을 줬습니다. "내 기기의 주인은 나"라는 철학은 훌륭하지만, 그만큼 공급망 신뢰도가 중요해집니다. 배포된 파일이 잘못되면 그 피해는 고스란히 사용자의 하드웨어 영구 손상으로 이어지니까요.

개발자로서 이 사건을 보며 등골이 서늘해지는 지점은 '프로세스'의 중요성입니다. 코드를 잘 짜는 것도 중요하지만, 빌드 파이프라인에서 올바른 키로 서명되었는지 검증하는 절차, 릴리스 아티팩트가 의도한 것인지 확인하는 과정이 얼마나 중요한지 다시금 깨닫게 됩니다.

특히 인프라나 보안을 다루는 분들이라면 'Immutable(불변)'이라는 단어의 무게를 다시 한번 생각해보셨으면 합니다. 클라우드 인프라에서의 불변성은 언제든 파기하고 새로 띄우면 그만이지만, 하드웨어 보안에서의 불변성은 말 그대로 '영원히'를 의미합니다.

이번 사고의 피해자들은 안타깝게도 하드웨어적인 조치 없이는 복구가 불가능합니다. 소프트웨어 업데이트로 해결할 수 있는 영역을 넘어섰기 때문입니다. 우리 개발자들도 배포 버튼을 누르기 전에, 이 설정이 정말 '되돌릴 수 있는 것'인지 한 번 더 확인하는 습관을 가져야겠습니다.

오늘의 트러블슈팅 사례는 여기까지입니다. 읽어주셔서 감사합니다.