연합 노드 등록 인증 설계 (연합 API :9160 보안 갭 해소)
개요
크라우니게이트웨이 연합 API(:9160 POST /register)는 현재 누구나 노드를 등록할 수 있다.
악성 노드가 가짜 loc/services 를 연합체인(nodes.ndjson)에 append 하면 통합 라우트맵이 오염된다.
핵심 구분:
- 이전해시 체인 = 무결성(변조 감지) 보장 — 이미
크라우니게이트웨이연합.한선에 구현됨 - 서명/인증 = 신원·권한(위조 차단) 보장 — 이번 설계가 채우는 갭
무엇을 했는지
연합인증설계.한선 신규 작성 — 2계층 인증 모델 + 공통 replay 방어. 컴파일 통과, 자가 단위검증 8/8 PASS.
라이브 미적용(설계/컴파일 검증용). 기존 연합 파일은 읽기만 하고 수정하지 않음.
2계층 인증 모델
계층 A — 공유키 HMAC (간단/소규모, 즉시 적용)
- 앵커·노드가 사전에 노드별 공유 비밀키를 안전 채널로 교환
- 등록 요청 본문 +
nonce+ts를 정규문으로 직렬화 후HMAC-SHA256(공유키)서명 - 앵커가 같은 키로 재계산해 상수시간 비교 → 권한 검증
- 장점: 단순. 단점: 대칭키(부인방지 불가, 양쪽 보관)
- 노드가 최초 1회
등록키(pubkey 역할)를 앵커에 enroll - enroll 은 루트
부트스트랩토큰HMAC 으로 보호 → 아무나 enroll 못 함 - 이후 등록은 그 노드의 등록키 기반 서명으로 검증
- 등록키는
node-keys.ndjson(append-only)에 보관. revoke/rotate = 새 블록 append (최신 블록이 유효 상태)
공통 방어 (replay 차단)
ts허용창 ±300초 — 만료 요청 거부nonce1회성 —used-nonces.log대조, 재사용 거부- 상수시간 비교 — 서명 비교 타이밍 사이드채널 완화
통합 게이트 반환 코드
등록인증(모드,...):
1통과 (nonce 소비)0서명 불일치-1미등록·폐기 노드-2ts 만료-3nonce 재사용
주요 함수
정규문(노드ID,위치,서비스직렬,헬스,nonce,ts)— 결정적 직렬화(파이프 구분)A서명생성 / A서명검증— 계층 Aenroll검증 / 등록키저장 / 등록키폐기 / 등록키조회 / B서명검증— 계층 Bts유효 / nonce미사용 / nonce소비— 공통 방어상수시간비교— 타이밍 누수 완화등록인증(모드,...)— 통합 게이트
자가 단위검증 결과 (8/8 PASS)
A1 올바른서명 통과(1) A2 위조서명 거부(0)
C1 nonce재사용 거부(-3) C2 ts만료 거부(-2)
B1 enroll검증 통과(1) B2 등록키서명 통과(1)
B3 미등록노드 거부(-1) B4 폐기후 거부(-1)
연합 API 통합 지점 (다음 단계 — 미적용)
연합API.한선 의 등록처리(전체요청) 에서 노드등록() 호출 전에 게이트 삽입:
변수 nonce = 본문값(본문,"nonce") 변수 ts = 본문값(본문,"ts")
변수 서명 = 본문값(본문,"sig") 변수 모드 = 본문값(본문,"auth")
변수 인증 = 등록인증(모드, 노드, 위치, 서비스, 헬스, nonce, ts, 서명, 공유키)
만약 (인증 != 1) { 반환 응답("401 Unauthorized", ..., code) }
POST /enroll 추가: enroll검증()==1 → 등록키저장().한선씨 함정 회피 기록
- 인라인
;다단어 주석 →//로 (미정의 변수컴파일 오류 유발) HMAC_SHA256은해시.한선RFC2104 스타일(SHA256 str→hex 기반 근사) 사용파일존재()-1 →읽기()글자수 판정- 글로벌 배열 인덱스 대입 금지 → 노드키/nonce 저장 모두 append-only ndjson
- 맵 인덱스반환 → 키 조회는 ndjson 라인 스캔(J값 철학)
관련 파일
- 신규 설계:
/Users/ef/crowny-gateway/한선게이트웨이/연합인증설계.한선(컴파일 OK, 8/8 PASS) - 기존(읽기만):
/Users/ef/crowny-gateway/한선게이트웨이/크라우니게이트웨이연합.한선 - 기존(읽기만):
/Users/ef/crowny-gateway/한선게이트웨이/크라우니게이트웨이연합API.한선 - 재사용 라이브러리:
/Users/ef/CrownyOS/crownyc/libs/해시.한선(HMAC_SHA256,랜덤토큰)
잔여 이슈
해시.한선의 HMAC 은 바이트 XOR 근사(VM SHA256 이 문자열 기반). 진짜 RFC2104 바이트 XOR 이 필요하면 버퍼 기반 SHA256 추가 필요. 현재 용도(내부 노드 인증)에는 일관성만 보장되면 충분.- 계층 A 의 노드별 공유키 저장소(
노드공유키조회)는 미구현 — 적용 시 enroll 과 유사한 ndjson 저장소로 추가. used-nonces.log무한 증가 — ts 기반 주기적 정리(만료 nonce 삭제) 필요.- 실제 라이브 적용은 별도 통합 단계(연합API.한선 등록처리 게이트 삽입 + /enroll 추가).