Choi.ethTech Blog

Cryptography

난수 재사용 취약점(Nonce Reuse Vulnerability) 분석

업비트 해킹 사례

작성자: Choi.eth

8 min read

image.png

2025년 11월 27일, 국내 최대 암호화폐 거래소 업비트가 대규모 해킹 사고를 겪었다. 솔라나(Solana) 계열 자산 약 445억 원 상당이 외부로 유출되었으며, 업비트는 내부 지갑에서 비정상 출금 패턴을 감지한 즉시 입·출금 전면 중단과 긴급 점검을 진행했다. 이후 추가 피해를 막기 위한 온체인 동결 조치와 함께 국내외 수사 기관과의 공조도 예고한 상태다.

https://x.com/tanselkayatr/status/1994508462508720253?s=46

사고 원인은 공식적으로 아직 발표되지 않았지만, 국내외 여러 개발자 커뮤니티와 보안 분석 게시판에서는 이미 가장 유력한 공격 벡터로 ‘난수 재사용 취약점(Nonce Reuse Vulnerability)’을 지목하고 있다. 이는 잘 알려진 암호학적 위험 요소로, 개인키 자체가 노출되지 않아도 서명에 사용되는 난수(k)가 반복될 경우 비밀키가 역산될 수 있는 치명적 취약점이다.

본 글에서는 해당 난수 재사용 취약점이 어떤 방식으로 발생하며, 어떤 암호학적 원리에 의해 비밀키가 노출되는지를 기술적으로 설명할 예정이다. 또한 커스터디 서비스를 운영하는 기업에서 충분히 발생할 수 있는 구조적 문제라는 점을 짚어 보고자 한다.

트랜잭션과 디지털 서명

블록체인 네트워크에서 내 지갑에 보유중인 자산을 전송하기 위해서 트랜잭션을 만들어야 한다. 이때 트랜잭션 내부 데이터에는 디지털 서명과 서명 메시지(Message)가 작성되어 있다. 서명 메시지에는 나는 B에게 100 솔라나를 전송한다.와 같은 온체인 활동(Activity)에 대한 내용은 적혀있다. 그리고 디지털 서명은 나는 B에게 100 솔라나를 전송한다.에서 나를 증명하는 데이터이다.

블록체인 관점에서 나는 블록체인 지갑을 의미한다. 그리고 지갑의 소유권은 개인키를 보유한 사람이 갖는다. 따라서 디지털 서명은 개인키를 사용해 생성되며, 네트워크는 서명 검증 알고리즘을 통해 “이 메시지를 보낸 주소의 실제 소유자가 맞는가?” 를 판단한다. 이 과정은 개인키를 공개하지 않고도 소유권을 증명할 수 있게 해주는 암호학적 프로토콜(ECDSA, EdDSA 등)에 의해 안전하게 수행된다.

디지털 서명 생성 원리

디지털 서명은 ‘r’, ‘s’ 두가지 파라미터로 구성되어 있으며, 아래와 같은 과정을 통해 생성된다.

Ethereum과 같이 타원곡선 서명을 사용하는 일부 블록체인의 경우 **v**가 추가되어 총 세 개의 값이 전송되지만, 엄밀한 암호학적 관점에서 디지털 서명의 핵심 구성 요소는 **r**과 **s**이다.

  1. 임의의 숫자(난수) k 선택한다.

  2. 선택한 k에 생성점(G)를 곱하여 R(x,y)를 통해 구한다. 이때 구한 좌표 R의 x는 r로 정의한다.

    !) 서명 데이터는 (x,y) 좌표 상의 한점으로 표현된다.

    !) 생성점(G)는 공통으로 사용하는 값임으로 모두가 알 수 있다.

  3. 서명하고자 하는 메시지(m)를 해시(hash)하여 z를 구한다.

  4. 지금까지 정의한 변수 k, m, r와 개인키(sk)를 통해 서명값 s를 구한다.

난수 재사용 취약점(Nonce Reuse Vulnerability)

https://notsosecure.com/ecdsa-nonce-reuse-attack

난수 재사용 취약점(Nonce Reuse Vulnerability)은 디지털 서명 생성 과정에서 사용되는 난수 k가 두 번 이상 재사용될 때 발생하는 심각한 보안 문제를 말한다. 서명 알고리즘(ECDSA 등)은 동일한 메시지라도 매번 다른 k 값을 사용해야 안전성이 보장되는데, 만약 k가 반복 사용되면 개인키가 역산될 수 있다.

특히 동일한 k로 생성된 서명은 r 값이 동일하게 나타나기 때문에, 온체인에 기록된 여러 서명 중 r 값이 반복되는 패턴만으로도 취약점의 존재를 쉽게 확인할 수 있다.

이제 공격자의 관점에서, 동일한 난수 k가 사용된 두 개의 서명(s1,s2)s_1, s_2) 이 공개되어 있다고 가정하고, 이 정보를 바탕으로 개인키를 어떻게 도출하는지 살펴보자.

난수 k 구하기

온체인 상에 공개되는 서명 데이터는 r, s 의 형태로 보이기에, k를 알 수 없지만, 동일한 k를 사용한 2개의 서명((s1,s2)(s_1, s_2)를 통해 아래와 같이 구할 수 있다.

k1=k2=k  ∣  r1=r2=rk_1 = k_2 = k ~~|~~ r_1 = r_2 = r

먼저 두 서명의 k, r, sk 모두 같은 값을 사용하기에 동일한 파라미터를 사용한다.

s1=k−1∗(z1+r∗sk)s_1 = k^{-1}*(z_1+ r*sk)
  • s1s_1: 서명1
  • z1z_1: 서명1의 메시지 해시
  • sksk: 개인키
s2=k−1∗(z2+r∗sk)s_2 = k^{-1}*(z_2+r*sk)
  • s2s_2: 서명2
  • z2z_2: 서명2의 메시지 해시
  • sksk: 개인키

여기서 s_1와 s_2를 빼면 k 값을 알아낼 수 있다.

(s1−s2)=k−1∗(z1+r∗sk)−k−1∗(z2+r∗sk)(s_1-s_2) = k^{-1}*(z_1+r*sk) - k^{-1}*(z_2+r*sk)
k∗(s1−s2)=(z1+r∗sk)−(z2+r∗sk)k*(s_1-s_2) = (z_1+r*sk) - (z_2+r*sk)
k∗(s1−s2)=z1−z2k*(s_1-s_2) = z_1 - z_2
k=z1−z2s1−s2k = \dfrac{z_1 - z_2}{s_1-s_2}

개인키(sk) 구하기

k를 알고 있다면, 이제 서명 데이터를 통해 개인키를 아래와 같이 구해낼 수 있다.

s1=k−1∗(z1+r∗sk)s_1=k^{-1}*(z_1+r*sk)
s1∗k=(z1+r∗sk)s_1*k=(z_1+r*sk)
s1∗k−z1=r∗sks_1*k - z_1=r*sk
s1∗k−z1r=sk\dfrac{s_1*k - z_1}{r}=sk

마무리

디지털 서명에서 nonce는 서명마다 안전하게 생성되어야 하는 핵심 값이다. 동일한 nonce가 서로 다른 메시지에 재사용되면 공개된 서명만으로 비밀 서명값을 복구하고, 유효한 서명을 위조할 수 있다. 개인키가 저장된 서버나 HSM에 직접 침입하지 않더라도 온체인에 공개된 서명 데이터만으로 공격이 가능하다는 점에서 매우 치명적인 취약점이다. 다만 현재 공개된 정보만으로 업비트 사고의 원인이 nonce 재사용 취약점이었다고 단정할 수는 없다.

암호화폐 거래소나 이용자의 개인키를 대신 관리하는 커스터디 서비스는 일반적으로 하드웨어 보안 모듈(HSM, Hardware Security Module)을 사용해 키를 보호한다. 업비트 같은 대형 플랫폼은 미국 NIST(국가표준기술연구소)가 제정한 암호 모듈 표준을 준수하는 장비를 사용하며, 대표적으로 FIPS 140-2 Level 3 등급의 HSM을 도입해 운영한다.

본 글에서 다룬 내용은 공개된 온체인 서명 패턴을 바탕으로 제기된 가설과 그 암호학적 원리를 설명한 것이다. 실제 사고 원인을 규명하려면 서명 구현, 키 관리 시스템, 접근 기록과 내부 인프라에 대한 추가적인 포렌식 분석이 필요하다.

이번 사례는 개인키를 안전한 장비에 보관하는 것만으로 서명 시스템 전체의 보안이 보장되지는 않는다는 점을 보여준다. 키 생성부터 메시지 구성, nonce 파생, 서명 실행, 결과 검증에 이르는 전체 서명 파이프라인을 함께 점검해야 하며, 구현체가 표준을 정확히 준수하는지 지속적으로 검증해야 한다.

Reference.

Keep reading

모두 보기