TL;DR — 산업용 게이트웨이는 현장에 물리적으로 놓여 있어 공격자가 파일을 읽고 고칠 수 있다. 초기 설계는 기기 비밀값(device_secret)을 서버 DB에 평문으로 두었는데, 이러면 DB 유출 한 번으로 전 기기 위조가 가능하다. 비밀값을 저장하지 않고 요청마다 재계산하는 구조로 바꿔, DB가 통째로 새도 위조 재료가 남지 않게 했다.

배경

• 프로젝트/기능: KC License Server — 게이트웨이 장비에 배포되는 클라이언트의 실행 권한을 검증하는 서버
• 환경: Java 21, Spring Boot 3.x, MySQL 8(Flyway), Docker, TLS 1.3
• 전제: 장비가 현장에 있으므로 클라이언트는 공격자 손 안에 있다. Python 클라이언트라 디컴파일도 쉽다

문제 (증상)

• 라이선스 검증은 클라이언트가 보낸 값을 서버가 믿는 순간 무의미해진다
• 초기 설계는 기기별 비밀값을 DB 컬럼에 평문 저장 — 서버가 그 값을 꺼내 대조하는 방식
• 이 구조에서는 DB 한 번 유출 = 전 기기 위조다. 공격자가 비밀값을 알면 정상 기기와 구별되지 않는 요청을 만들 수 있다

원인 분석

• 위협 모델을 "클라이언트는 신뢰할 수 없다"까지만 잡고, "서버 DB도 유출될 수 있다"를 넣지 않은 것이 근본 원인이었다
• 비밀값을 저장하는 한, 저장소의 보안 수준이 시스템 전체의 상한이 된다 — 암호화해 저장해도 복호화 키가 같은 서버에 있으면 한 단계 늘어날 뿐이다
• 설계 기준을 **"DB가 통째로 유출돼도 위조가 불가능해야 한다"**로 올려 잡고 다시 시작했다

해결

비밀값을 어디에도 저장하지 않는다. 대신 서버만 아는 마스터 키와 기기 식별자로 요청마다 재계산한다.

• device_secret을 DB에서 제거하고, 검증 시점에 결정적으로 재유도(derive)하는 방식으로 전환
• 클라이언트는 그 비밀값으로 proof를 만들어 보내고, 서버는 같은 방식으로 재계산해 대조한다
• 해시·HMAC의 직렬화 규칙을 명세로 고정했다 — 필드 순서·구분자가 한 글자만 달라도 값이 갈리므로, 규칙이 곧 프로토콜이다
• 비밀값이 로그로 새지 않도록 로깅 경로에서 차단

검증 자산도 함께 만들었다.