Skip to content

코인크래프트

비트코인·이더리움·Web3 전문 분석 블로그

COINCRAFT_로고원본
Primary Menu
  • Home
  • Blog
    • 시장 분석
    • 기술 가이드
    • 온체인 분석
    • 칼럼
  • 알트코인
  • 뉴스레터
  • Books
    • WEB3
    • 온체인 시그널
  • Contact & Tips
  • Community
    • 공지사항
    • 건의사항
    • 자유게시판
  • 회원가입
  • 로그인
  • 시장 분석

AWS KMS DER 서명을 EVM 65바이트로 변환하는 법

aws-kms-der-서명을-evm-65바이트로-변환하는-법
CoinCraft 4월 18, 2026

Patent-D 시리즈 D-5 | KMS DER 서명 to EVM 65바이트 변환 알고리즘

난이도: ★★★★ | #DER서명 #EVM서명 #ECDSA #LowS정규화 #복구ID #secp256k1

문제: KMS와 EVM이 말하는 서명 형식이 다르다

AWS KMS에 서명을 요청하면 DER(Distinguished Encoding Rules) 인코딩 바이트 배열을 반환한다 (가변 길이, 약 70~72바이트). 그런데 EVM은 {r: bytes32, s: bytes32, v: uint8} 구조 (65바이트 고정)를 요구한다.

단순 형식 변환이 아니다. 두 가지 추가 처리가 필요하다.

문제 1 서명 가단성(Signature Malleability): ECDSA 서명에서 (r, s) 쌍이 있을 때, (r, n-s) 쌍도 수학적으로 유효한 서명이다. EIP-2는 s 값이 n/2보다 크면 (n-s)로 대체하도록 규정한다(Low-S 정규화).

문제 2 복구 ID(v) 결정: EVM 서명에는 r, s 외에 v라는 값이 필요하다. AWS KMS는 이 값을 제공하지 않는다. 직접 계산해야 한다.

3단계 변환 파이프라인

AWS KMS 서명 결과 수신
DER 바이트: [0x30, len, 0x02, r_len, r_bytes..., 0x02, s_len, s_bytes...]
     |
1단계: DER 파싱
r = BigInteger(r_bytes)
s = BigInteger(s_bytes)
     |
2단계: Low-S 정규화 (EIP-2)
s > secp256k1_n / 2 ?
  YES: s = secp256k1_n - s  (서명 가단성 방지)
  NO:  s 그대로 사용
     |
3단계: v(복구 ID) 결정
recId=0: r, s, digest to 공개키 복원 to 등록 주소와 비교
recId=1: r, s, digest to 공개키 복원 to 등록 주소와 비교
일치하는 recId to v = recId + 27 (27 또는 28)
     |
최종: {r: bytes32, s: bytes32, v: uint8} to EVM 트랜잭션 서명 완료

DER 구조 상세

DER 서명 구조:
  Byte 0:    0x30 (SEQUENCE 태그)
  Byte 1:    전체 길이
  Byte 2:    0x02 (INTEGER 태그)
  Byte 3:    r의 길이 (r_len)
  Byte 4...: r 값 (최고위 비트가 1이면 앞에 0x00 패딩)
  다음:      0x02 / s의 길이 / s 값

KMS가 r 최고위 비트가 1인 값을 반환하면 DER 인코딩에서 0x00 패딩이 붙어 33바이트가 된다. 파싱 시 이 패딩을 제거해야 진짜 32바이트 r을 얻을 수 있다.

ETH 출금 서명 전체 흐름

1. 트랜잭션 데이터 구성 (from, to, value, nonce, gas...)
2. 트랜잭션 해시 계산 (keccak256)
3. KMS에 서명 요청: KMS.sign(keyId, digest=txHash)
4. DER 서명 수신 (약 70바이트)
5. DerToEvmSignatureConverter.convert(derSignature, txHash)
   to r: 32바이트, s: 32바이트 (Low-S), v: 27 또는 28
6. {r, s, v}를 트랜잭션에 포함 to Ethereum 네트워크 제출

v 값이 27이냐 28이냐는 수학적으로 결정된다. 틀리면 서명 검증 실패로 트랜잭션이 reject된다. 하드코딩으로 접근하면 약 50% 확률로 실패한다.

핵심 요약

  • KMS(DER) to EVM({r,s,v}) 변환은 단순 형식 변환이 아닌 수학적 처리 필요
  • Low-S 정규화(EIP-2): s 가 n/2 초과이면 s = n-s로 대체 to 서명 가단성 제거
  • v 값은 recId 0/1 시도 후 공개키 복원으로 수학적 결정 to 하드코딩 불가
  • 공개키를 별도 저장 없이 r, s, digest로부터 수학적으로 복원

다음 편: D-6 출금 이중 레이어 추적, 요청과 실행을 왜 분리해야 하는가

About the Author

CoinCraft

Administrator

Author's website Author's posts

Continue Reading

Previous: Zero Trust 서명 재검증: Signer 독립 검증 프로토콜
Next: 출금 이중 레이어 추적: 요청과 실행을 왜 분리해야 하는가

Related Stories

  • 시장 분석

블록체인 최종성 확인: 3차원 FinalityPolicy 원장 시스템

CoinCraft 4월 18, 2026
  • 시장 분석

출금 이중 레이어 추적: 요청과 실행을 왜 분리해야 하는가

CoinCraft 4월 18, 2026
  • 시장 분석

Zero Trust 서명 재검증: Signer 독립 검증 프로토콜

CoinCraft 4월 18, 2026
© 2026 코인크래프트(CoinCraft). 비트코인 · 이더리움 · Web3 전문 분석 블로그.