인증 스티커의 배신
정부나 금융권 프로젝트를 해보신 분이라면 'FIPS 140 인증 받은 암호 모듈만 쓰세요'라는 요구사항을 한 번쯤 만나보셨을 거예요. 미국 정부에 소프트웨어를 납품하려면 사실상 필수인 인증인데요. 최근 한 보안 엔지니어가 쓴 글이 이 인증의 불편한 진실을 정면으로 짚었어요. 요지는 간단해요. FIPS 140-3 인증은 '이 소프트웨어가 안전하다'는 보증이 아니라는 것, 그리고 이를 심사하는 감사인(auditor)들도 이 사실을 이미 알고 있다는 거예요.
FIPS 140-3이 뭐냐면, 미국 국립표준기술연구소(NIST)가 운영하는 암호 모듈 검증 제도예요. OpenSSL 같은 암호 라이브러리가 '정부가 승인한 알고리즘을, 정해진 방식대로 구현했는지'를 지정된 시험기관이 검사하고 인증서를 발급해 주는 거죠. 기존의 FIPS 140-2를 대체하는 새 버전으로, 국제 표준인 ISO/IEC 19790을 기반으로 만들어졌어요.
인증이 검사하는 것과 검사하지 않는 것
문제는 이 인증이 검사하는 범위가 생각보다 좁다는 데 있어요. 인증 심사는 '승인된 알고리즘(AES, SHA-2 같은)을 쓰는가', '키를 지우는 제로화 기능이 있는가', '부팅 시 자가 테스트를 수행하는가' 같은 체크리스트를 확인하는 과정이거든요. 이게 뭐냐면, 자동차 검사에서 '안전벨트가 달려 있는가'를 확인하는 것과 비슷해요. 안전벨트가 있다고 해서 그 차가 사고를 안 낸다는 보장은 아니잖아요? 실제 코드에 버퍼 오버플로 같은 구현 버그가 있는지, 사이드 채널 공격(전력 소모나 실행 시간 같은 부수적인 정보를 관찰해서 비밀 키를 알아내는 공격)에 취약한지 같은 건 심사 범위 밖이거나 아주 제한적으로만 다뤄져요.
더 심각한 건 인증 제도의 구조적인 모순이에요. 인증은 '특정 버전'에 대해 발급되거든요. 그런데 인증을 받는 데 보통 1~2년씩 걸려요. 그 사이에 보안 취약점이 발견되면 어떻게 될까요? 패치를 하면 인증받은 버전이 아니게 되니까, '알려진 취약점이 있는 구버전'을 그대로 쓰는 게 오히려 규정 준수가 되는 황당한 상황이 벌어져요. 실제로 OpenSSL의 FIPS 모듈이 이런 문제로 여러 번 도마에 올랐고요. 보안을 위해 만든 제도가 보안 패치를 가로막는 역설이죠.
감사인도 알고, 업계도 알아요
글쓴이가 특히 꼬집는 부분은 감사 현장의 실태예요. 컴플라이언스 감사에서 감사인이 확인하는 건 사실상 '인증서 번호가 NIST 데이터베이스에 있는가'까지예요. 그 모듈이 실제로 어떤 설정으로 돌아가고 있는지, 애플리케이션이 암호화를 올바르게 사용하고 있는지는 대부분 들여다보지 않아요. 그러니까 인증은 실질적인 보안 검증이라기보다 책임 분산 장치에 가까워요. 사고가 났을 때 '우리는 인증받은 모듈을 썼다'고 말할 수 있게 해주는 거죠. 감사인도, 벤더도, 발주처도 이 게임의 규칙을 다 알면서 서로 모르는 척하는 셈이에요.
이건 FIPS만의 문제는 아니에요. SOC 2, ISO 27001 같은 다른 컴플라이언스 제도들도 정도의 차이는 있지만 비슷한 비판을 받아요. '컴플라이언스는 보안이 아니다'라는 말이 보안 업계의 오래된 격언이 된 이유죠.
한국 개발자에게는
한국에도 판박이 같은 제도가 있어요. 국내 공공기관 납품 시 필수인 KCMVP(암호모듈검증제도)인데요, 인증 대기열이 길고 특정 버전에 인증이 묶이는 구조까지 FIPS와 닮았어요. 인증 자체를 무시하라는 얘기가 아니에요. 규제 시장에 들어가려면 어차피 받아야 하니까요. 다만 인증 마크를 보안의 증거로 착각하지 말자는 거예요. 인증받은 라이브러리를 쓰더라도 잘못된 암호화 모드 선택(예: ECB 모드), 부실한 키 관리, IV 재사용 같은 실수는 전부 우리 애플리케이션 코드의 몫이거든요. 인증은 출발선이지 결승선이 아니에요.
정리하며
FIPS 140-3은 '규제 시장의 입장권'이지 '보안 품질 보증서'가 아니다 — 이게 이 글의 한 줄 요약이에요. 여러분의 조직에서는 컴플라이언스와 실질 보안 사이의 간극을 어떻게 메우고 계신가요? 인증 요구사항 때문에 오히려 보안 패치가 늦어졌던 경험, 있으신가요?
🔗 출처: Hacker News