포네 지갑 ECDSA 도입 준비 (한선씨 인터페이스 동결)

현재 상태 (2026-05-28)

시간서버인증.한선 + 포네인증.한선이 SHA256 challenge-response로 임시 구현. 실제 포네 지갑은 ECDSA secp256k1 서명을 사용해야 함.

교체 시 유지되어야 할 인터페이스 (동결)

시간서버인증

• 시간인증_발급(사용자) → 토큰 (32+ hex chars)
• 시간인증_검증(토큰) → 사용자명 또는 ""
• 시간인증_헤더추출(요청) → 토큰

포네인증

• 포네_챌린지발급(사용자) → nonce (32 hex)
• 포네_서명검증(사용자, 서명) → 토큰 또는 ""
• API: /api/wallet/challenge /api/wallet/verify

HTTP 표면

• Authorization: Bearer TOKEN 헤더 검증 흐름은 그대로
• 토큰 = SHA256 → 향후 JWT (ES256k)로 교체 가능, payload에 사용자명 포함

ECDSA 교체 단계 (한선씨 SHA256만 가능 → 외부 의존 필요)

옵션 A: bash 보조 + openssl

포네인증.한선 검증 함수 내부에서:
  /bin/bash -c "echo '$nonce' | openssl dgst -sha256 -verify pubkey.pem -signature <(echo '$sig' | base64 -d)"
호출 후 결과 파싱

• 한선씨 외부 명령 실행 능력 필요 (현재 없음)
• 대안: 시스템(cmd) 내장 추가 후 사용

옵션 B: WASM 외주

• 클라이언트가 secp256k1 서명 + 공개키 제공
• 서버는 외부 검증기(node secp256k1 라이브러리)에 위임
• 한선씨 서버는 HTTP 프록시 역할만

옵션 C: 점진적 — JWT 도입

• 1) 시간인증 토큰을 JWT(HS256, 비밀키 공유)로 교체 — 한선씨 SHA256 + Base64 가능
• 2) 검증 측은 JWT 표준 라이브러리 사용 가능
• 3) 추후 ES256k로 마이그레이션

권장: 옵션 C (JWT) → 옵션 A/B (ECDSA)

현재 임시 인증의 한계 (운영 노출 전 해결 필수)

1. 비밀키 평문 저장 — /Users/ef/crowny-time/data/포네_지갑.dat에 secret 그대로 (개발용)
2. nonce 1회용 검증 없음 — 같은 nonce 재사용 가능
3. 토큰 무효화 메커니즘 없음 — 발급 후 7일 TTL만, 즉시 폐기 불가
4. rate limit 미적용 — 무차별 시도 가능 (레이트제한.한선으로 보강 가능)

마이그레이션 체크리스트

• 한선씨 시스템 명령 실행 기능 또는 외부 호출 인프라
• secp256k1 검증 라이브러리 (Node/Python 보조)
• JWT 인코딩/디코딩 한선씨 모듈
• 클라이언트 SDK: 공개키 등록 + 서명 생성 (브라우저 SubtleCrypto + secp256k1)
• DB 마이그레이션: 비밀키 → 공개키 (해시 검증 → 서명 검증)
• 토큰 폐기 목록 (revocation list)
• rate limit (분당 N challenge 시도)

관련 파일

• 포네인증.한선 — 임시 SHA256 구현
• 시간서버인증.한선 — Bearer 토큰
• 로그인.html — UI (포네 지갑 탭, SubtleCrypto SHA-256 사용)
• 레이트제한.한선 — 보강 가능 (Phase 9 신규)