Nightmare-Eclipse가 5월 17일에 공개한 YellowKey 저장소의 README는 단 한 줄이다. 'YellowKey Bitlocker Bypass Vulnerability'. 코드 설명도, 사용법도, 데모 영상도 없다. 그런데 이 한 줄이 보안 운영자에게 던지는 무게는 결코 가볍지 않다. 새로운 0-day의 등장이 아니라, 오랫동안 묵인되어온 운영 가정 — 'TPM만 있으면 충분하다' — 을 정면으로 다시 끌어내기 때문이다.
BitLocker는 키 보호 방식에 따라 보안 등급이 크게 달라진다. 사전 부팅 PIN이나 USB key protector를 함께 쓰면 사용자 인증이 키 봉인 해제의 전제가 된다. 반면 TPM-only 모드는 부팅 자체가 인증이다. 물리적으로 단말을 손에 넣은 공격자가 정상적으로 전원을 켜기만 해도, TPM은 측정값이 일치한다고 판단하고 VMK를 운영체제에 넘긴다. 그 순간 별도 칩 형태의 디스크리트 TPM과 CPU 사이를 잇는 LPC 혹은 SPI 버스 위로 키 머티리얼이 평문에 가까운 상태로 흐른다. YellowKey라는 이름이 풍기는 뉘앙스는 정확히 이 지점이다 — 노란 신호등처럼 짧지만 분명히 존재하는, 키가 노출되는 시간 창.
흥미로운 건 이게 학술적 가설이 아니라는 점이다. 디스크리트 TPM 환경에서의 버스 스니핑은 수년 전부터 반복적으로 시연되어왔고, 그때마다 결론은 같았다. PIN을 강제하거나, CPU에 내장된 fTPM 플랫폼을 선택하거나, 둘 중 하나는 해야 한다. 그러나 현실의 기업 표준 이미지 대다수는 여전히 TPM-only다. 헬프데스크 호출을 줄이려는 결정, 사용자 마찰을 낮추려는 결정, 그리고 '암호화는 켜져 있다'는 보고 한 줄이면 충분하다는 감사 관행이 겹쳐 만들어진 풍경이다. YellowKey의 한 줄 README는 그 풍경에 다시 불을 켠다.
그래서 오늘 해야 할 일은 코드를 분석하는 것보다 앞선다. 사내 자산 중 BitLocker가 어떤 protector 조합으로 운영되는지 manage-bde로 한 번 훑어보고, OEM 모델별로 dTPM과 fTPM을 구분한 인벤토리를 만들고, Group Policy에서 'Require additional authentication at startup'을 켜 TPM+PIN을 강제하는 흐름으로 옮겨가는 일이다. 분실된 노트북 한 대가 '암호화되어 있으니 안심'인지, 아니면 '몇 분의 물리 접근이면 풀린다'인지는 이 작은 설정 차이에서 갈린다. YellowKey가 화제가 되는 이유는 새로운 공격이라서가 아니라, 우리가 미뤄온 결정을 다시 책상 위로 올려놓기 때문이다.