Linux 커널 회귀: LUKS 암호화 키가 Suspend 시 삭제되지 않음

Linux 6.9(2024년 5월)에서 도입된 회귀 버그로 인해 LUKS 디스크 암호화 키가 suspend-to-RAM 중에도 메모리에 남아 있게 되었으며, 이로 인해 키를 삭제하도록 설계된 보안 메커니즘이 사실상 무력화되었습니다. 이 취약점은 노트북이 전원이 켜진 채로 정지 상태에 있을 때 압류당하면, 콜드 부트 공격이나 기타 RAM 덤핑 기법을 통해 암호화된 데이터를 탈취당할 위험이 있었습니다.

근본 원인: 조용히 실패한 리팩토링

암호화 키는 스레드 종료 시점에 삭제되어야 한다는 기대와 달리, 커널 내 블록 디바이스 접근을 리팩토링하면서 키 삭제 도구가 조용히 실패하게 되었습니다. 문제는 블록 디바이스 접근을 파일 기반으로 포팅한 특정 커밋에서 시작되었으며, 이 커밋이 암호화 코드와 예상치 못한 장기적인 상호작용을 일으켰습니다.

시스템은 정상적으로 동작했으며—노트북이 오류 없이 정지하고 다시 시작되었기 때문에—이 회귀는 2년 넘게 감지되지 않았습니다. 커뮤니티 구성원들이 지적했듯이, 이러한 유형의 보안 버그는 시스템 충돌이나 기능 장애를 일으키지 않기 때문에 스스로 알리기 어렵습니다.

탐지 및 완화

이 취약점은 Ingo Blechschmidt가 소스 코드 분석과 메모리 포렌식을 결합해 발견했습니다. Debian에서 영감을 받은 cryptsetup-suspend 도구를 NixOS에 통합하려던 중, /proc/keys에 키 항목이 여전히 보이는 것을 확인했으며, 문서에서는 해당 키가 삭제되어야 한다고 명시되어 있었습니다. 그는 QEMU 가상 머신을 실행하고 메모리를 덤프하여 볼륨 키가 RAM에 남아 있음을 확인함으로써 버그를 입증했습니다.

현재 수정 및 우회 방법

• 커널 패치: 물리 블록 디바이스에 대한 암호화 볼륨의 일반적인 경우를 해결하기 위해 한 줄짜리 커널 패치가 개발되었습니다. 그러나 이 패치는 가상 루프 디바이스를 포함하지 않아 완전하지 않다는 점이 나중에 밝혀졌습니다.
• Cryptsetup 업데이트: cryptsetup 팀의 Ondrej Kozina가 커널 버그를 회피하는 우회 방법을 개발했습니다. 이 수정은 cryptsetup 2.8.7 릴리스에 포함될 예정입니다.
• NixOS 구현: NixOS용 실험적인 "secure suspend-to-RAM" 프로젝트가 출시되었으며, 이는 Pali Rohár가 만든 오래된 커널 패치를 재활용해 suspend 시 LUKS 키를 삭제합니다.
• 대체 전원 상태: 이 취약점이 우려되는 사용자는 **suspend-to-disk(하이버네이션)**을 사용할 수 있습니다. suspend-to-RAM과 달리 하이버네이션은 RAM 내용을 암호화된 스왑 파티션에 기록하고 메모리를 완전히 전원 차단하므로 키가 평문 RAM에 남지 않습니다.

위협 모델 및 기술적 배경

이 수정이 주로 방어하는 위협은 콜드 부트 공격이며, 이는 물리적으로 접근 가능한 전원이 켜진(하지만 정지된) 머신의 RAM 내용을 덤프해 암호화 키를 복구하는 공격입니다.

메모리 보안에 대한 커뮤니티 관점

이 버그에 대한 기술 토론에서는 여러 방어‑심층 전략이 강조되었습니다:

"CPU가 지원한다면 메모리 암호화를 활성화하세요... 평문이 CPU 패키지를 떠나지 않습니다. DIMM 스왑 공격은 무의미해집니다."

다른 사용자들은 부팅 시 메모리를 삭제하도록 MemoryOverwriteRequestControl 같은 TPM 기능을 활용할 것을 제안했습니다. 또한 버그의 범위에 대한 논쟁도 있었는데, 일부는 cryptsetup luksSuspend가 주로 Debian 전용 확장 기능이며 핵심 업스트림 Linux 기능이 아니므로 영향이 특정 배포판에만 제한된다고 주장했습니다.

복구 요약

방법	보안 수준	편의성
Suspend-to-RAM (패치 미적용)	낮음 (키가 RAM에 존재)	높음
Suspend-to-RAM (패치 적용)	중간 (키 삭제)	높음
Hibernate (Suspend-to-Disk)	높음 (RAM 전원 차단)	중간
하드웨어 메모리 암호화	매우 높음	높음