데이터 구조에 서명할 때 빠지기 쉬운 함정: 도메인 분리를 제대로 해야 하는 이유

서명이란 게 그냥 해시 돌리고 키로 암호화하면 끝 아닌가요?

암호학적 서명(digital signature)은 "이 데이터가 진짜 내가 만든 거다"를 증명하는 기술이에요. 보통은 데이터를 직렬화(serialize)하고, 해시를 구한 다음, 개인 키로 서명하면 된다고 생각하죠. 그런데 여기에 아주 교묘한 함정이 숨어 있거든요. 바로 도메인 분리(domain separation)라는 개념인데요, 이걸 제대로 안 하면 전혀 다른 종류의 메시지가 같은 서명값을 가질 수 있는 심각한 보안 문제가 생겨요.

최근 FOKS 프로젝트 블로그에서 이 문제를 IDL(Interface Definition Language) 수준에서 어떻게 해결할 수 있는지에 대한 깊이 있는 글이 공개됐어요. 단순한 이론이 아니라, 실제 프로토콜을 설계할 때 흔히 저지르는 실수와 그 해결책을 구체적으로 다루고 있어서 소개해 드릴게요.

도메인 분리가 뭔데, 왜 중요한 건가요?

쉽게 비유하자면 이런 거예요. 여러분이 은행에 "100만 원을 이체해 주세요"라는 요청서에 서명했다고 해볼게요. 그런데 그 서명이 "100만 원의 대출을 승인합니다"라는 문서에도 유효하다면? 완전히 다른 의미의 문서인데 같은 서명으로 통과되는 거죠. 이게 바로 도메인 분리가 안 됐을 때 벌어지는 일이에요.

기술적으로 말하면, 서로 다른 타입의 데이터 구조가 직렬화됐을 때 동일한 바이트열을 만들어낼 수 있는 상황이 문제예요. 예를 들어 UserAuth 메시지와 PaymentRequest 메시지가 우연히 같은 바이트 패턴으로 직렬화될 수 있고, 이때 한쪽에 대한 서명이 다른 쪽에서도 유효해지는 크로스 프로토콜 공격(cross-protocol attack)이 가능해져요.

흔히 저지르는 실수들

가장 전형적인 실수는 직렬화 포맷만 믿고 타입 정보를 서명에 포함하지 않는 거예요. JSON이든 Protocol Buffers든 MessagePack이든, 직렬화된 바이트열 자체에는 "이게 어떤 종류의 메시지인지"에 대한 정보가 명확하게 들어가지 않는 경우가 많거든요.

Protocol Buffers를 예로 들면, 필드 번호와 와이어 타입만 기록되지 메시지 이름은 바이트열에 포함되지 않아요. 그래서 필드 구조가 비슷한 두 메시지가 동일한 바이트열로 직렬화될 수 있죠. 이건 정상적인 사용에서는 문제가 안 되지만, 암호학적 서명이 개입되는 순간 보안 취약점이 돼요.

또 다른 실수는 서명 대상 데이터에 컨텍스트 문자열을 추가하는 "수동 도메인 분리"를 하다가 일관성 없이 적용하는 거예요. 어떤 메시지에는 프리픽스를 붙이고, 어떤 메시지에는 안 붙이고, 프리픽스 형식도 제각각이면 결국 어딘가에 구멍이 생기게 되거든요.

IDL 수준에서 해결하는 접근법

FOKS 프로젝트에서 제안하는 해결책은 꽤 우아해요. IDL 정의 자체에 도메인 분리 정보를 내장하는 거예요. 이게 뭐냐면, 데이터 구조를 정의할 때부터 "이 구조체는 서명 대상이고, 서명할 때 이런 컨텍스트 문자열을 자동으로 포함해라"라는 정보를 명시하는 거죠.

이렇게 하면 개발자가 일일이 "이 메시지 서명할 때 프리픽스 붙여야지"를 기억할 필요가 없어요. 코드 생성기(code generator)가 IDL 정의를 읽고 자동으로 도메인 분리가 적용된 서명/검증 코드를 만들어주니까요. 사람이 실수할 여지를 시스템 수준에서 없애는 거예요.

핵심 아이디어는 각 메시지 타입에 고유한 태그(tag)를 부여하고, 서명 시 이 태그를 해시 입력에 포함시키는 거예요. 태그는 보통 패키지 이름과 타입 이름을 조합해서 만드는데, 이렇게 하면 서로 다른 타입의 메시지가 절대로 같은 서명값을 가질 수 없게 돼요.

비슷한 접근을 하는 다른 프로젝트들

이 문제를 인식하고 해결하려는 시도는 여러 곳에서 이루어지고 있어요. TLS 1.3에서는 Handshake 메시지에 컨텍스트 문자열을 포함하도록 설계됐고, CBOR(Concise Binary Object Representation)의 태그 시스템도 비슷한 역할을 해요. Sigstore 같은 코드 서명 프로젝트에서도 서명 페이로드에 타입 정보를 명시적으로 포함하는 방식을 쓰고 있죠.

하지만 대부분은 프로토콜 수준에서 개별적으로 해결하는 방식이에요. IDL 수준에서 체계적으로 해결하려는 FOKS의 접근은 좀 더 근본적인 해법이라고 볼 수 있어요. 매번 새 프로토콜을 만들 때마다 "도메인 분리 했나?"를 체크하는 게 아니라, 도구가 알아서 해주니까요.

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

솔직히 대부분의 웹 개발에서는 이 수준의 암호학적 고려가 필요하지 않을 수 있어요. 하지만 JWT를 다루거나, 블록체인 관련 개발을 하거나, 결제 시스템에서 서명을 직접 구현하는 분들이라면 꼭 알아둬야 할 내용이에요. 특히 마이크로서비스 간 통신에서 메시지 무결성을 서명으로 보장하는 아키텍처를 쓰고 있다면, 도메인 분리가 제대로 되어 있는지 한번 점검해 볼 필요가 있어요.

또 한 가지, 이 글에서 얻을 수 있는 더 큰 교훈은 "사람이 기억해서 하는 보안은 반드시 뚫린다"는 거예요. 체크리스트를 아무리 잘 만들어도 누군가는 까먹거든요. 보안 규칙을 도구와 프레임워크 수준에서 강제하는 게 훨씬 안전하다는 관점은 어떤 프로젝트에서든 적용할 수 있는 원칙이에요.

마무리

데이터 구조에 서명할 때는 "무엇에 서명하는가"를 서명 자체에 포함시켜야 해요. 이걸 빠뜨리면 전혀 의도하지 않은 곳에서 서명이 유효해지는 보안 사고가 날 수 있죠. 여러분이 다루는 시스템에서 서명 로직이 있다면, 혹시 도메인 분리 없이 바이트열만 달랑 서명하고 있지는 않은지 한번 살펴보시는 건 어떨까요?