🚀 2026 스타트업 컨퍼런스

보안 기능을 켰는데 CPU만 낭비하고, 정작 해커에겐 문을 열어줬던 '장식용 암호화'의 배신

보안 기능을 켰는데 CPU만 낭비하고, 정작 해커에겐 문을 열어줬던 '장식용 암호화'의 배신

James·2026년 1월 5일·3

보안을 위해 활성화한 TPM 암호화 기능이 오히려 CPU를 낭비하고 보안 구멍을 만든 사례를 통해, 엔지니어가 경계해야 할 '장식용 암호화'와 신뢰 사슬의 중요성을 다룹니다.

실리콘밸리에서 Staff 엔지니어로 일하다 보면, 종종 '보안'이라는 이름의 성역과 마주하게 됩니다. 누군가 "이거 보안 취약점입니다"라고 말하는 순간, 모든 효율성 논의는 중단되고 우리는 맹목적으로 그 구멍을 메우기 위해 달려듭니다. 저 또한 그랬습니다. 리눅스 커널 설정을 들여다보다 TCG_TPM2_HMAC라는 옵션을 발견했을 때, 저는 주저 없이 'Y'를 눌렀습니다.

이 기능의 설명은 매혹적이었습니다. TPM(Trusted Platform Module)과 CPU 사이의 통신 버스(Bus)를 누군가 물리적으로 훔쳐보는 '인터포저(Interposer)' 공격을 막아준다는 내용이었습니다. 하드웨어 레벨의 해킹까지 막아주는 커널이라니, SRE로서 이보다 든든한 보험은 없어 보였습니다. 하지만 저는 그 순간, 제 시스템의 가용성을 갉아먹고, 거짓된 안도감만 주는 '장식품'을 시스템 깊숙이 들이고 말았습니다.

우리는 흔히 암호화(Cryptography)가 모든 보안 문제를 해결해 줄 요술 지팡이라고 착각합니다. 하지만 최근 리눅스 커널 6.18에서 이 TCG_TPM2_HMAC 기능이 기본적으로 비활성화된 사건은, 우리가 기술을 얼마나 피상적으로 소비하고 있는지를 적나라하게 보여줍니다.

이야기의 핵심은 이렇습니다. 공격자가 메인보드에 칩을 붙여 TPM으로 오가는 데이터를 가로채거나 변조한다고 가정해 봅시다. 이를 막기 위해 커널은 TPM과 암호화된 세션을 맺습니다. 매번 PCR(Platform Configuration Register)을 확장하거나 난수를 생성할 때마다 HMAC을 붙이고 암호화를 수행합니다. 당연히 시스템 오버헤드는 급증합니다. "성능 좀 희생하더라도 보안이 중요하니까"라고 자위하며 넘어갈 수 있는 수준이 아닙니다.

문제는 그 '비싼' 암호화가 정작 핵심인 '키 관리(Key Management)' 문제를 해결하지 못했다는 점입니다. 커널이 TPM과 안전하게 대화하려면, 상대방이 진짜 TPM인지 확인하기 위한 '키'가 필요합니다. 이 기능은 'Null Primary Key'라는 것을 사용하는데, 황당하게도 커널은 이 키가 진짜인지 검증할 능력이 없습니다. 대신 커널은 이 키의 이름(해시)을 유저스페이스(Userspace) 파일 시스템 어딘가(/sys/class/tpm/...)에 적어두고, 나중에 부팅이 끝난 뒤 유저스페이스 애플리케이션이 이를 검증해 줄 것이라 믿어버립니다.

여기서 '신뢰의 사슬(Chain of Trust)'이 박살 납니다. 보안 부팅의 핵심은, 먼저 실행된 코드(커널)가 나중에 실행될 코드(유저스페이스)를 검증하는 단방향성에 있습니다. 그런데 이 기능은 거꾸로, 커널이 자신의 보안성을 아직 검증되지 않은(혹은 이미 오염되었을 수도 있는) 유저스페이스에게 의탁하고 있는 꼴입니다.

공격자가 유저스페이스를 장악할 수 있다면? 공격자는 가짜 키를 만들고, TPM인 척 연기하며 커널을 속일 수 있습니다. 커널은 열심히 암호화를 수행하지만, 그건 도둑이 만든 자물쇠에 열쇠를 꽂는 행위나 다름없습니다. Chris Fenner가 지적했듯, 이것은 "장식적 암호화(Decorative Cryptography)"입니다. 보안 문제를 해결한 게 아니라, 보안 문제를 키 관리 문제로 치환해 놓고는 정작 키 관리는 방치한 것입니다.

이 경험이 저에게 남긴 교훈은 씁쓸하지만 명확합니다.

  • 첫째, 설명되지 않는 보안 기능은 마케팅 용어일 뿐입니다. 암호화 알고리즘의 이름이 화려하다고 해서 보안이 보장되는 것은 아닙니다. "키를 누가, 어떻게 관리하는가?"라는 질문에 답하지 못하는 암호화는 리소스만 낭비하는 장식품입니다.
  • 둘째, '거짓된 안전감각'은 무방비 상태보다 더 위험합니다. 차라리 "여기는 뚫릴 수 있다"고 인지하면 다른 모니터링 수단을 강구하거나 물리적 보안을 강화했을 겁니다. 하지만 "암호화했으니 안전하다"는 착각은 SRE를 나태하게 만들고, 결국 새벽 3시의 재앙으로 돌아옵니다.

우리는 종종 복잡한 기술 스택과 난해한 설정을 도입하며 "열심히 일했다"고 착각합니다. 하지만 넷플릭스에서 수많은 장애를 겪으며 배운 건, 엔지니어의 진짜 실력은 무엇을 더하느냐가 아니라 무엇을 빼느냐에서 나온다는 사실입니다.

당신의 시스템에도 혹시 '장식용 자물쇠'가 달려 있지는 않습니까? 남들이 좋다고 하니까, 혹은 있어 보이니까 켜둔 그 설정 하나가, 어쩌면 당신의 CPU를 태우고 해커에게는 레드카펫을 깔아주고 있을지도 모릅니다. 오늘 동료들과 커피 한잔하며, 우리 시스템의 '신뢰 사슬'은 올바른 방향으로 흐르고 있는지 점검해 보시길 바랍니다.

James
James실리콘밸리 15년차 Staff SRE

연봉 3억과 캘리포니아의 햇살, 그리고 공황장애. 화려한 빅테크 간판 뒤에 가려진 '생존의 청구서'를 정산해드립니다. 기술적 탁월함만큼 중요한 건 엔지니어로서의 지속 가능성임을 병상에서 깨달았습니다.

James님의 다른 글

댓글 0

첫 번째 댓글을 남겨보세요!