1년 반 동안 아무도 몰랐다: 리눅스 디스크 암호화가 '잠금' 상태에서 키를 흘리고 있었습니다

노트북을 덮으면 안전하다고 믿으셨나요. 리눅스에서 디스크 전체를 암호화하고, 화면을 잠그고, 서스펜드(절전)로 보내면 누가 훔쳐가도 데이터는 못 본다고요. 그런데 그 믿음의 한 축이 조용히 무너져 있었습니다. 그것도 무려 1년 반 동안, 아무도 눈치채지 못한 채로요.

이번 주제는 리서치 시점 기준으로 커뮤니티에서 갓 뜨겁게 논의된 사안은 아닙니다. 신선한 토론 데이터가 많지 않다는 점은 미리 솔직하게 말씀드릴게요. 하지만 리눅스 노트북을 쓰는 분이라면, 그리고 “암호화했으니 괜찮아"라고 생각해온 분이라면 반드시 알아야 할 이야기입니다.

잠깐, LUKS와 ‘서스펜드’가 뭔가요

먼저 기본부터 짚고 갈게요. LUKS는 Linux Unified Key Setup의 약자로, 리눅스에서 디스크 전체를 암호화할 때 쓰는 표준 방식입니다. 우분투나 페도라를 설치할 때 “디스크 암호화” 옵션을 켜면 바로 이 LUKS가 동작합니다.

핵심은 이렇습니다. 디스크에 저장된 데이터는 암호로 잠겨 있습니다. 하지만 여러분이 부팅할 때 암호를 입력하는 순간, 시스템은 진짜 암호화 키를 만들어 메모리(RAM)에 올려둡니다. 디스크를 실시간으로 읽고 쓰려면 이 키가 항상 메모리에 살아 있어야 하니까요.

여기서 문제가 시작됩니다. 컴퓨터를 절전 모드로 보내면 어떻게 될까요. 화면은 꺼지지만 RAM에는 전원이 계속 공급됩니다. 즉, 암호화 키가 메모리에 그대로 남아 있다는 뜻입니다. 누군가 잠든 노트북을 훔쳐서 특수 장비로 메모리를 덤프하면, 이론적으로 그 키를 뽑아낼 수 있습니다. 이걸 콜드 부트 공격이라고 부릅니다.

그래서 만든 안전장치, ‘LUKS suspend’

이 위협을 막으려고 리눅스는 영리한 기능을 마련해뒀습니다. 바로 cryptsetup luksSuspend입니다.

동작 원리는 간단하고 우아합니다. 시스템이 절전에 들어가기 직전, 디스크 입출력을 잠시 얼려버립니다. 그리고 메모리에 있던 암호화 키를 깨끗하게 지웁니다. 절전 상태에서는 키가 아예 존재하지 않게 되는 거죠. 나중에 노트북을 다시 깨우면 암호를 한 번 더 입력하고, 그때 키를 다시 메모리에 올립니다.

이 설계 덕분에 “잠든 노트북 = 키 없음 = 훔쳐가도 안전"이라는 공식이 성립했습니다. 많은 보안 지향 배포판과 프라이버시를 중시하는 사용자들이 바로 이 기능을 믿고 노트북을 들고 다녔습니다. 논리적으로도 흠잡을 데가 없었습니다.

문제는, 그 공식이 어느 순간부터 조용히 깨져 있었다는 겁니다.

커널 6.9, 조용한 회귀 버그

리눅스 커널 6.9 버전부터 문제가 생겼습니다. 커널 내부의 코드가 바뀌면서, luksSuspend가 메모리에서 암호화 키를 지우는 동작이 사실상 무력화된 것입니다.

이런 걸 보안 용어로 회귀(regression)라고 부릅니다. 예전에 잘 되던 기능이, 다른 부분을 고치는 과정에서 의도치 않게 망가지는 현상이죠. 개발자들이 A를 개선하다가 B가 부서지는, 소프트웨어 세계에서 드물지 않은 일입니다.

무서운 건 이게 ‘조용한’ 회귀였다는 점입니다. 겉으로는 아무 문제가 없어 보였습니다. luksSuspend 명령은 정상적으로 실행되고, 에러도 뜨지 않고, 노트북은 멀쩡하게 절전에 들어갔다가 잘 깨어났습니다. 사용자 입장에서는 모든 게 완벽해 보였습니다. 하지만 무대 뒤에서는 지워졌어야 할 키가 메모리에 그대로 남아 있었습니다. 눈에 보이지 않는 실패, 이것이 가장 위험한 종류의 보안 결함입니다.

1년 반, 아무도 몰랐던 이유

가장 충격적인 부분은 시간입니다. 이 문제가 약 1년 반 동안 발견되지 않은 채로 방치됐다는 사실이요.

왜 이렇게 오래 걸렸을까요. 이유를 곱씹어보면 씁쓸합니다.

첫째, 증상이 없었기 때문입니다. 기능이 겉으로 멀쩡하게 동작하니 아무도 의심하지 않았습니다. 화면이 안 켜진다거나 부팅이 안 된다면 즉시 버그 리포트가 쏟아졌겠죠. 하지만 “메모리에 키가 남아 있는지"는 특수한 도구로 직접 덤프해서 확인하지 않으면 알 방법이 없습니다.

둘째, 검증이 어렵기 때문입니다. 이 기능이 제대로 동작하는지 확인하려면 절전 상태의 메모리를 실제로 들여다봐야 합니다. 일반 사용자는 물론이고, 대부분의 개발자도 일상적으로 하지 않는 작업입니다. 자동화된 테스트로 잡기도 까다롭습니다.

셋째, 믿음의 함정입니다. 한번 “이 기능은 안전하다"고 검증되고 나면, 사람들은 그 뒤로 다시 의심하지 않습니다. 커널이 6.8에서 6.9로, 다시 그 이후로 올라가는 동안 아무도 “혹시 이 기능이 아직도 동작하나"를 재확인하지 않았습니다. 보안에서 가장 위험한 순간은 바로 이 “당연히 되겠지"라는 방심입니다.

이 사건이 남기는 진짜 교훈

이 이야기는 단순히 리눅스 버그 하나의 문제가 아닙니다. 보안이라는 것이 얼마나 미묘하고 깨지기 쉬운지 보여주는 사례입니다.

우리는 흔히 보안을 ‘켜거나 끄는 스위치’처럼 생각합니다. 암호화를 켰으니 안전하다, 이렇게요. 하지만 실제 보안은 수많은 부품이 맞물려 돌아가는 정교한 기계에 가깝습니다. 그중 부품 하나가 조용히 헐거워지면, 겉으로는 멀쩡히 돌아가는 것처럼 보여도 전체가 위험해집니다.

특히 보이지 않는 실패의 무서움을 기억해야 합니다. 눈에 띄는 고장은 오히려 다행입니다. 바로 고치니까요. 진짜 위험한 건 아무 신호 없이 조용히 무너지는 결함입니다.

물론 현실적으로 이 문제를 악용하려면 공격자가 여러분의 잠든 노트북을 물리적으로 손에 넣고, 메모리를 덤프할 장비와 기술까지 갖춰야 합니다. 아무나 당하는 공격은 아닙니다. 하지만 기자, 활동가, 기업의 민감 정보를 다루는 사람처럼 물리적 탈취 위협이 현실인 이들에게는 결코 가벼운 문제가 아닙니다. 애초에 luksSuspend는 바로 그런 사람들을 위해 만들어진 기능이었으니까요.

리눅스 노트북에서 디스크 암호화와 서스펜드를 보안의 핵심으로 삼고 계신다면, 지금 쓰는 커널 버전과 이 문제의 패치 여부를 한번 확인해보시길 권합니다. 여러분이 “잠갔다"고 믿는 그 순간, 시스템이 정말로 잠겨 있는지 어떻게 확신하시겠습니까. 때로는 가장 오래 믿어온 안전장치가, 가장 오래 방치된 구멍일 수 있습니다.