Linux 6.9 이후 LUKS suspend가 디스크 암호화 키를 메모리에서 지우지 못함

8 hours ago 6

Linux 6.9부터 노트북 suspend 시 드라이브를 잠그는 도구가 조용히 실패해, LUKS 전체 디스크 암호화 키가 메모리에 남아 있었음
원인은 2024년 5월 Linux 6.9에 들어간 블록 디바이스 접근 리팩터링과 암호화 코드의 예상 밖 상호작용이며, 제안된 수정은 한 줄짜리 패치임
전체 종료에서는 문제가 드러나지 않았지만 suspend-to-RAM에서는 키가 남아, 전원이 켜진 노트북을 확보한 공격자가 RAM에서 키를 빼낼 수 있는 상태가 됨
발견은 Debian cryptsetup-suspend의 NixOS 포트를 정리하던 중 /proc/keys 항목을 본 데서 시작됐고, QEMU 메모리 덤프로 지워졌어야 할 volume key가 남아 있음을 확인함
NixOS 통합 테스트와 cryptsetup 경고 패치가 제안됐으며, suspend 직전 키 삭제 같은 보안 기능은 정상처럼 보여도 실제 메모리 검증 없이는 실패를 놓치기 쉬움

Linux 6.9 이후 suspend 중 LUKS 키가 남은 문제

Linux 6.9, 즉 2024년 5월부터 노트북 suspend 시 드라이브를 잠그는 도구가 조용히 실패하고 있었음
LUKS 전체 디스크 암호화는 노트북 분실, 압수, 도난 시 데이터를 보호하기 위해 쓰이지만, 이번 경우 suspend 동안 암호화 키가 메모리에 남아 있었음
전체 종료에서는 여전히 동작했지만, 노트북을 완전히 끄기보다 suspend-to-RAM으로 두는 경우가 많다는 점에서 영향이 커짐
전원이 켜진 상태로 노트북을 확보한 사람이 있다면, 메모리에 남은 키가 노출될 수 있는 상태였음
Windows에서 같은 목적의 소프트웨어로 VeraCrypt가 언급됐으나, 이후 댓글에서 “canonical software”는 가장 널리 쓰이는 소프트웨어가 아니라 IT 보안 쪽의 대표 추천이라는 뜻으로 정정됨

원인은 Linux 커널 리팩터링 커밋인 md: port block device access to file였음
- 변경 자체는 합리적이고 유용한 리팩터링이었지만, 암호화 코드와 장거리 상호작용을 일으킴
제안된 수정은 한 줄짜리 패치임
패치 작성자는 형식 검증 없이는 이 패치가 올바르고 다른 장거리 상호작용이 없다고 말할 수 없다고 밝힘
재발 방지를 위한 후속 작업도 함께 나옴
- NixOS 자동 테스트: 향후 회귀를 감지하기 위한 통합 테스트
- cryptsetup 병합 요청: 조용히 실패하지 않고 경고를 출력하도록 하는 패치

시작점은 Debian cryptsetup-suspend의 NixOS 포트를 정리하는 작업이었음
Debian 원본과 NixOS 포트 모두 노트북이 가끔 잠들지 못하게 하는 불편하지만 해롭지는 않은 경쟁 조건을 갖고 있었음
이를 해결하려고 Pali Rohár의 병합되지 않은 커널 패치인 dm-crypt suspend/hibernation 키 삭제 패치를 되살리려 했음
그 과정에서 cryptsetup과 커널 소스 코드를 살펴보다가, 문서상 keyring이 호출 스레드에 붙고 스레드 종료 시 제거된다는 점을 확인함
그러나 이전에 알지 못했던 /proc/keys에서 항목이 보였고, 이 부분이 의심을 키움
결국 QEMU 가상머신을 띄워 메모리를 덤프했고, 지워졌어야 할 LUKS volume key가 그대로 남아 있음을 확인함

별도로 공개된 secure-suspend 프로젝트는 NixOS에서 실험적 secure suspend-to-RAM을 제공함
일반적인 전체 디스크 암호화는 노트북이 suspend 상태일 때 키가 메모리에 남아 있어, cold boot attack이나 RAM 유출 방식에 취약할 수 있음
이 프로젝트는 Pali Rohár의 오래된 커널 패치를 되살려 suspend 시 LUKS 암호화 키를 지우는 방식임
Debian cryptsetup-suspend에서 영감을 받았지만, 커널 패치를 사용해 노트북이 가끔 잠들지 못하는 경쟁 조건을 피하고 추가 예방책을 더함
암호화된 root filesystem을 완전히 지원하며, 통합 테스트도 제공됨
커널 패치와 사용자 공간 도구는 다른 Linux 배포판에도 맞춰 적용할 수 있음
프로젝트는 secure-suspend로 공개돼 있음

suspend 후 화면 잠금이 보인다고 해서 저장장치가 실제로 잠겼다고 볼 수는 없음
suspend에서 깨어난 직후 디스크에 바로 접근 가능하다면, 저장장치는 처음부터 잠기지 않은 상태였음을 알 수 있음
- 예를 들어 잠금 화면 뒤에서 계속 실행되는 스크립트로 디스크 접근을 확인할 수 있음
- suspend 후 SSH 공개키로 먼저 암호화 저장장치를 해제하지 않고 접속 가능하다면, 저장장치가 잠기지 않았음을 확인하기 쉬움
Ubuntu나 Debian 기본 설정은 이런 보호를 제공하려는 시도 자체가 없었다는 댓글도 있음
저장장치를 잠그려는 시도가 실제로 올바르게 동작했는지는 별도로 검증해야 함
- 로그 타임스탬프는 suspend 전 생성됐지만 wake 후 기록됐을 수 있음
- 반대로 wake 직후 시스템 시간이 조정되기 전에 생성된 로그가 suspend 시점의 시간처럼 보일 수도 있음
저장장치 잠금이 suspend 직전에 일어난 것인지, resume 직후 일어난 것인지는 사용자 경험상 같아 보여도 보안상으로는 결정적으로 다름
NixOS 통합 테스트는 가상머신으로 시스템을 부팅하고 메모리를 덤프해, 키가 suspend 시 실제로 지워졌는지 확인하는 방식임