요약 — KC License Server에서 기기별 device_secret을 DB에 직접 저장하는 대신 검증 시 재계산하도록 구성했다. 확인된 원본의 유도식은 SHA256(license_key ‖ mac_hash ‖ RV)이며 마스터키를 사용하지 않는다. 세 입력이 같은 DB에 있으므로 비저장만으로 DB 유출 시 위조를 막지는 못한다. 핵심 경험은 검증 절차와 직렬화 규칙을 고정하고, 수용한 잔여 위험을 구분한 것이다.

배경

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

문제 (증상)

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

원인 분석

• 위협 모델을 "클라이언트는 신뢰할 수 없다"까지만 잡고, "서버 DB도 유출될 수 있다"를 넣지 않은 것이 근본 원인이었다
• 저장 여부뿐 아니라 secret을 재계산할 수 있는 입력의 위치도 위협 모델에 포함해야 한다. 파생값을 저장하지 않더라도 입력이 함께 유출되면 재현될 수 있다. 암호화 저장·키 분리·마스터키 도입은 서로 다른 설계이며 이 구현에 도입했다고 주장하지 않는다.
• 확인한 원본은 마스터키 미도입을 선택했고, DB 유출 시 전 장비 secret을 재현할 수 있다는 한계를 명시한다. 비저장 설계의 결과를 DB 유출 방어로 확대하지 않으며 DB 접근 통제와 유출 방어는 별도 과제로 남긴다.

해결

device_secret 자체를 DB에 저장하지 않고 검증 시 SHA256(license_key ‖ mac_hash ‖ RV)로 재계산한다. 확인한 revision에서는 서버만 아는 마스터키를 도입하지 않았으며, license_key·mac_hash·RV는 DB에 저장된다. 기존 글의 마스터키 설명은 확인한 원본과 충돌하므로 철회한다.

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

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