리눅스 6.9부터 절전 시 디스크 암호화 키가 메모리에서 안 지워지고 있었어요

노트북 뚜껑을 덮어 절전 모드로 두면서 '어차피 디스크는 암호화돼 있으니까 괜찮겠지'라고 생각해본 적 있으시죠. 그런데 리눅스에서 그 믿음을 받쳐주던 기능 하나가 2년 넘게 조용히 고장 나 있었다는 사실이 최근 보고됐어요. 리눅스 커널 6.9부터 LUKS의 suspend 기능이 디스크 암호화 키를 메모리에서 제대로 지우지 못하고 있었다는 건데요, 그동안 아무도 눈치채지 못했다는 점이 더 뼈아픈 이야기예요.

LUKS와 luksSuspend가 뭐냐면

LUKS는 Linux Unified Key Setup의 약자로, 리눅스에서 디스크 전체를 암호화할 때 쓰는 사실상의 표준이에요. 우분투나 페도라 설치할 때 '디스크 암호화' 체크박스를 켜면 바로 이 LUKS가 동작하는 거거든요. 부팅할 때 패스프레이즈를 입력하면 마스터 키가 풀리고, 이 키는 커널 메모리에 올라가서 디스크를 읽고 쓸 때마다 실시간으로 암호화와 복호화를 처리해요. 그러니까 컴퓨터가 켜져 있는 동안에는 키가 항상 RAM 어딘가에 있는 셈이에요.

여기서 문제가 생겨요. 노트북이 절전 모드일 때도 RAM에는 전기가 공급되니까 키가 그대로 남아 있거든요. 이걸 노리는 게 바로 콜드 부트 공격이에요. RAM은 전원이 끊겨도 수 초에서 수 분 정도 데이터를 유지하는데, 냉각 스프레이로 얼리면 이 시간이 훨씬 길어져요. 공격자가 절전 중인 노트북을 손에 넣어서 메모리 내용을 덤프하면, 그 안에서 암호화 키를 찾아낼 수 있는 거죠. 썬더볼트 포트 같은 경로로 메모리를 직접 읽어가는 DMA 공격이라는 방법도 있고요.

그래서 만들어진 게 luksSuspend예요. cryptsetup luksSuspend 명령을 실행하면 해당 볼륨의 입출력을 얼려버리고 마스터 키를 커널 메모리에서 지워요. 잠들기 직전에 이 명령이 실행되도록 설정해두면, 절전 중인 노트북을 통째로 도둑맞아도 RAM 어디에도 키가 없으니 안전한 거예요. 깨어날 때 패스프레이즈를 다시 입력하면 luksResume으로 복구되고요. 보안에 민감한 리눅스 사용자들 사이에서는 오래된 정석 설정이에요.

그런데 6.9부터 조용히 깨졌어요

이번 보고의 핵심은, 리눅스 6.9부터 이 '키 지우기'가 실제로는 온전히 동작하지 않았다는 거예요. 커널 내부 변경의 여파로 luksSuspend를 실행해도 암호화 키가 메모리에서 완전히 사라지지 않게 된 거죠. 명령 자체는 아무 에러 없이 성공하니까, 사용자 입장에서는 보호받고 있다고 믿을 수밖에 없었어요. 6.9가 2024년에 나온 커널이니까, 대략 2년 동안 이 보호막이 사실상 장식이었던 셈이에요.

이 사건이 무서운 이유는 고장의 형태 때문이에요. 기능이 에러를 내며 실패하면 누군가는 금방 알아차리는데, '성공한 척하면서 실제로는 아무것도 안 하는' 고장은 아무도 모르게 지나가거든요. 특히 보안 기능은 정상일 때와 고장일 때 겉모습이 완전히 똑같아요. 키가 정말 지워졌는지 확인하려면 커널 메모리를 덤프해서 키 패턴을 뒤져봐야 하는데, 그런 검증을 자동화해둔 프로젝트는 거의 없죠.

업계 맥락에서 보면

조용히 깨지는 보안 기능은 사실 반복돼온 패턴이에요. 과거에도 난수 생성이 무력화된 채 오랫동안 배포됐던 유명한 사건들이 있었고, 그때마다 교훈은 같았어요. 보안 기능은 존재 여부가 아니라 실제 동작 여부를 검증해야 한다는 거예요. 이번 건은 systemd의 절전 연계 설정처럼 luksSuspend에 기대고 있던 구성들에 영향을 주는 만큼, 커널과 배포판 쪽에서 수정과 함께 회귀 테스트 논의가 이어질 것으로 보여요.

한국 개발자에게 주는 시사점

리눅스 노트북에 luksSuspend 기반 설정을 쓰고 계신 분이라면 커널 버전을 확인하고 패치 소식을 챙겨보세요. 당장은 대안도 있어요. 절전 대신 하이버네이트(최대 절전 모드)를 쓰면 메모리 내용이 암호화된 스왑에 저장되고 전원이 완전히 꺼지니까 RAM에 키가 남지 않거든요. 카페나 출장처럼 물리적 도난 위험이 있는 상황이라면 아예 종료하는 게 가장 확실하고요.

그리고 이건 우리가 만드는 서비스에도 그대로 적용되는 교훈이에요. 로그아웃하면 토큰이 정말 무효화되는지, 권한을 회수하면 실제로 접근이 막히는지 같은 '부정 경로'를 테스트로 박아두지 않으면, 언젠가 리팩터링 한 번에 조용히 깨져도 아무도 모르게 되거든요.

정리하면, 보안 기능은 깨져도 티가 나지 않으니 동작 검증을 자동화해야 한다는 이야기예요. 여러분의 팀은 보안 기능이 조용히 무력화되는 걸 어떻게 감지하고 계신가요?