이 기사는Medium번역기 | 모니

번역기 | 모니

에디터 | 루샤오밍

에디터 | 루샤오밍

편집자 주: 이 글은 University of Illinois at Urbana-Champaign(UIUC) 산하 분산 시스템 연구실(Decentralized Systems Lab) 연구팀이 작성한 "자원 고갈 취약점"에 대한 연구 보고서입니다. , Yunqi Li, Yuguang Chen, Joseph Kuo 및 컨설턴트 Andrew Miller. 이러한 취약점은 지분증명 기반으로 총 26개 이상의 암호화폐에 영향을 미쳤으며, 사이버 공격자는 아주 작은 "지분"(stake)만 사용하면 해당 소프트웨어를 실행하는 모든 네트워크 노드를 충돌시킬 수 있습니다. 연구팀은 2018년 10월에 잠재적으로 영향을 받는 암호화폐의 개발자에게 문제를 알리기 위해 조사를 공개하기 시작했으며 대부분은 현재 완화 조치를 배포했습니다.

PoS(Proof-of-Stake) 암호화폐, 특히 Bitcoin과 유사한 PoSv3(지분증명 버전 3: Proof-of-Stake 버전 3) 암호화폐는 기본적으로 UTXO(Unspent Transaction Output: Unspent Transaction Output) 모델을 사용하며 최장 체인 합의 규칙. 소위 UTXO는 비트코인 ​​주소와 관련된 비트코인 ​​금액의 집합을 말하며, 비트코인 ​​시스템에는 계정 개념이 없기 때문에 전체 네트워크의 블록체인 전체에 걸쳐 소비되지 않은 트랜잭션 출력만 있을 뿐이며, 이는 본질적으로 데이터를 포함하는 데이터입니다. 데이터 및 실행 가능한 코드 구조. UTXO의 기본 단위는 "사토시"이며, "사토시"는 비트코인의 가장 작은 측정 단위이며, 1비트코인은 10^8 사토시와 같습니다. UTXO는 한번 생성되면 나눌 수 없으며 거래의 입력으로만 소비할 수 있으며 소비 후에는 새로운 UTXO가 생성되어 통화의 가치 이전이 반복적으로 실현될 수 있습니다. 따라서 Bitcoin 지갑에서 볼 수 있는 계정 잔액은 실제로 사용되지 않은 트랜잭션 출력의 집계 계산 결과입니다.

"작업 증명"과 비교하여 지분 증명은 에너지 소비가 적고 환경에 영향을 미치지 않으며 51% 공격에 대한 보안이 향상되는 등 몇 가지 잠재적인 이점이 있습니다. 사실 오늘날 시장에 나와 있는 많은 암호화폐는 비트코인 ​​코드베이스(또는 비트코인의 파생물)를 포크한 후 지분 증명 합의 메커니즘을 접목한 것이지만 일부 설계 개념이 안전하게 복사되지 않아 일부 새로운 버그가 수정되었습니다. 원래 코드베이스에 없었습니다.

또한 이 기사의 나머지 부분에서는 취약점과 공격에 대해 자세히 설명하고 이들이 어떤 미묘한 결과를 초래할 수 있는지 설명합니다. 나중에 보면 취약점 자체가 복잡해 보이지 않을 수 있지만 완전히 해결하는 것은 까다로우며 현재 시행 중인 완화 조치로 인해 블록체인 포크가 발생할 위험이 있습니다(자세한 내용은 나중에 설명).

보조 제목

"False Stake" 취약점에 대해 자세히 알아보기 전에 Proof-of-Stake 작동 방식을 살펴보겠습니다.

보조 제목

지분 증명 마이닝:

작업증명 마이닝과 마찬가지로 지분증명 마이닝에는 블록 헤더 해시 값과 난이도 목표가 포함됩니다(참고: 난이도 목표는 전체 네트워크의 컴퓨팅 성능이 대략 블록을 생성하는 데 필요한 난이도 값입니다. 10분마다). Proof-of-Stake의 높은 수준의 목표는 각 이해관계자가 그들이 통제하는 암호화폐의 양에 비례하여 다음 블록을 채굴할 기회를 갖도록 하는 것입니다. 이를 달성하기 위해 지분 증명 합의 메커니즘에서 해시 값은 블록 헤더뿐만 아니라 이해 관계자가 블록에 삽입한 특별한 "coinstake" 트랜잭션에 포함된 코인의 수에 따라 달라집니다.

• "Coinstake"는 권익 증명 창시자인 Sunny King이 특별히 고안한 특별 거래입니다. 비트코인 ​​창시자 "Satoshi Nakamoto"의 Coinbase 설계를 따릅니다. 입력 및 출력에는 몇 가지 엄격한 제한이 있습니다.

• Coinbase 구조에서는 입력 수량이 1이어야 하고 입력 Prevout 필드(이전 트랜잭션의 출력 지정)가 비어 있어야 하며 출력 수량이 1보다 크거나 같아야 합니다.

Coinstake 구조는 입력 수가 1보다 크거나 같고 첫 번째 입력의 Prevout 필드가 비어 있을 수 없습니다. 즉, 커널이 존재해야 하며 출력 수가 2보다 크거나 같고 첫 번째 출력은 비어 있어야 합니다.

또한 이 두 가지 특별한 트랜잭션은 블록체인의 저장 위치에 대한 특별한 요구 사항도 가지고 있는데, Satoshi Nakamoto는 각 블록의 첫 번째 트랜잭션이 Coinbase에 있어야 하며 이는 Coinbase가 블록의 다른 위치에 나타날 수 없음을 의미합니다. Sunny King은 분명히 이 규칙을 깨고 싶지 않았지만 "Proof of Stake" 블록의 두 번째 거래에 대해 Coinstake를 배치해야 한다는 규칙을 추가했으며 이는 또한 Coinstake가 블록체인의 다른 곳에 나타날 수 없음을 의미합니다. 즉, 두 번째 트랜잭션이 Coinstake인 한 이 블록은 지분 증명 블록으로 취급되어야 합니다.

지분 증명 마이닝에는 많은 세부 사항이 포함되므로 여기서는 자세히 설명하지 않겠습니다. 당분간 다음 두 가지 측면에 중점을 둘 것입니다.

2. Coinstake 트랜잭션에서 사용된 UTXO(사용되지 않은 트랜잭션 출력).

보조 제목

블록 유효성 검사 리소스 보안에서 작업 증명의 역할

우리 모두 알다시피 작업 증명은 비트코인 ​​합의에서 중요한 역할을 했지만 디스크, 대역폭, 메모리 및 CPU와 관련된 일련의 문제로 인해 인기가 떨어졌습니다. 분산형 암호화폐 네트워크에서 트랜잭션의 전제는 실제로 신뢰를 기반으로 하지 않으므로 자원 고갈 공격(자원 고갈 공격)을 방지하기 위해 비트코인 ​​노드는 먼저 더 많은 자원(예: RAM에 블록 저장 또는 디스크에)을 제출합니다. 작업 증명 메커니즘으로 모든 트랜잭션 수신 블록을 확인합니다. 그러나 블록을 확인하기 위해 Proof of Stake를 사용하는 것은 작업 증명보다 훨씬 더 복잡하고 이 합의 메커니즘은 상황에 따라(또는 상황에 따라) 많은 Proof of Stake는 실제로 구현할 때 확인하기가 매우 어렵습니다. 검증 "인색".

리소스 고갈 취약점이 어떻게 발생하는지 이해하기 전에 먼저 블록이 검증되기 전에 어떻게 저장되는지 자세히 설명해야 합니다. 실제로 블록체인 노드는 현재 가장 긴 체인을 추적해야 할 뿐만 아니라 포크 체인의 전체 트리도 추적해야 합니다. 그 중 하나가 가장 긴 체인이 될 수 있기 때문이며 시간대 블록체인 노드가 전환하려면 "재구성"해야 합니다. 준비되지 않은 업그레이드, 이중 지출 공격(Ethereum Classic에 대한 51% 공격 등) 또는 일시적인 네트워크 분할 등의 경우와 같이 가장 긴 체인에 "재구성"이 가능합니다.

이 경우 이러한 "오프 메인 체인"의 블록을 확인하는 것은 매우 어렵습니다. 블록을 완전히 검증하려면 이전 블록의 현재 시점에서 사용되지 않은 모든 트랜잭션 출력(UTXO)을 수집해야 합니다. 비트코인은 사용되지 않은 트랜잭션 출력 세트를 최고의 체인의 현재 끝에 유지하지만 분기된 블록체인의 블록은 비트코인의 접근 방식을 따르지 않을 수 있습니다. 포크의 블록을 완전히 검증하는 두 가지 주요 방법이 있습니다.

1. 현재 보기(사용되지 않은 트랜잭션 출력 집합)를 포크 이전 지점으로 "롤백"하거나,

2. 모든 초기 블록의 사용되지 않은 트랜잭션 데이터 컬렉션의 복사본을 저장합니다.

Bitcoin 코드베이스는 두 번째 접근 방식을 지원하지 않으며 가능하더라도 추가 스토리지 비용을 추가합니다(Bitcoin 노드 성능은 불필요한 데이터의 지속적인 "정리"에 의존합니다). 첫 번째 방법은 정확히 비트코인 ​​코드베이스가 현재 재구성을 처리하는 방법이지만 비용이 매우 많이 들 수 있으므로 분기된 체인의 작업 증명 양이 현재 메인 블록체인보다 크면 롤백 및 전체 유효성 검사가 다음 단계까지 연기됩니다. 마지막 순간. 따라서 노드가 가장 긴 체인의 일부가 아닌 블록 또는 헤더를 처음 수신하면 전체 유효성 검사를 건너뛰고 블록을 로컬 스토리지에 저장합니다.

Proof of Stake에서 유사한 초기 검사는 코인스테이크 트랜잭션의 유효성을 검사하고 이전 블록 커널의 난이도 목표를 통과했는지 확인합니다. 코인스테이크 트랜잭션의 컴퓨팅 파워를 계산하기는 쉽지만 코인스테이크 트랜잭션에 입력된 미사용 트랜잭션 데이터가 유효하고 소비되지 않았는지 확인하는 것은 정말 어렵습니다. 앞서 언급했듯이 이 작업은 사용되지 않은 트랜잭션 데이터의 수집을 확인해야 하므로 이전 블록에는 적용되지 않습니다. 코인스테이크 트랜잭션을 완전히 검증하는 것이 어렵기 때문에 대부분의 지분 증명 기반 블록체인은 "휴리스틱" 또는 "대략적인" 검사만 사용하며 이는 종종 부적절하고 악용될 수 있습니다.

보조 제목

허점 #1: "나는 그것이 주식이 아니라고 생각한다"

이 문제를 처음 조사했을 때 Qtum, Particl, Navcoin, HTMLcoin, Emercoin 등 5개의 암호화폐가 상당히 단순한 형태의 취약성을 가지고 있는 것으로 나타났습니다. 동전 거래를 전혀 확인하지 않습니다. 이 5가지 암호화폐의 공통점은 블록 전파가 두 개의 개별 메시지(하나는 블록용, 다른 하나는 영역용)로 분할되는 비트코인의 "헤더 우선" 기능을 사용한다는 것입니다. 블록 헤더가 작업 증명을 통과한 후 노드는 블록이 가장 긴 체인인지 여부만 묻습니다. 코인스테이크 트랜잭션은 블록 헤더가 아닌 블록에만 나타나기 때문에 노드는 자체적으로 블록 헤더를 확인할 수 없습니다. 대신 메모리 내 데이터 구조(mapBlockIndex)에 블록 헤더를 저장합니다. 따라서 지분이 없는 네트워크 공격자라도 잠재적인 피해 노드의 RAM을 채울 수 있습니다.

이 공격의 두 번째 변종은 코드 베이스를 대상으로 합니다. 약간 다른 방식으로 수행하고 다른 리소스를 대상으로 하지만 대상은 RAM이 아니라 디스크입니다. 틀림없이 디스크와 관련된 공격은 피해자 노드에 더 해롭기 때문에 RAM이 가득 차서 노드가 충돌하는 경우 간단한 재부팅이 필요하지만 디스크가 가득 차면 지우기 위해 외부 스크립트를 실행하는 것과 같은 수동 개입이 필요합니다. 디스크에서 사용되지 않는 블록.

이러한 취약점을 악용하면 지분이 없는 암호화폐에 영향을 미칠 수 있습니다. 대조적으로, RAM에 대한 공격은 덜 영향을 미칠 수 있는 반면, 디스크에 대한 공격은 기술적인 관점에서 약간 더 주의가 필요하며 지분 요구 사항이 없습니다.

보조 제목

취약점 2: Spent Stake 공격

이러한 코드베이스의 계보를 추적함으로써 우리는 버그 1이 원래 비트코인 ​​"헤더 우선" 기능을 PoSv3 코드베이스에 병합하고 있음을 발견했습니다. 그러나 이 공격은 이전 버전(예: Peercoin)에서는 작동하지 않으므로 디스크에 블록을 저장하기 전에 두 가지 추가 사전 확인이 필요합니다.

1. 모든 출력이 메인 체인에 존재하는지 확인하십시오.

2. Proof of Stake Kernel Hash가 난이도 목표 요구 사항을 충족하는지 확인합니다.

• 첫 번째 확인은 현재 메인 체인에서 지금까지 모든 트랜잭션을 추적하는 트랜잭션 데이터베이스(TxDB)에서 조회하여 수행됩니다. 즉, 예비 검증은 전혀 검증하지 않는 것보다 낫지만 완전한 검증은 여전히 ​​불가능하며 "휴리스틱" 및 "근사적" 검증만 수행할 수 있습니다. 이러한 사고 방식을 계속 설명하면 두 가지 다른 질문이 발생할 수 있습니다.

• 우려 사항 A: 첫 번째 확인은 토큰이 존재하는지 확인하지만 사용되지 않았는지 확인할 수는 없습니다. 이 상황은 즉시 다음에 논의되는 또 다른 취약점으로 이어집니다.

우려 사항 A를 바탕으로 우리는 "소모된 스테이크 공격"이라고 하는 보다 교묘한 공격을 사용하여 이러한 검사를 속이는 방법을 찾았습니다. 첫 번째 확인을 우회하려면 이미 소비된 출력을 노드에 표시하고, 두 번째 확인을 우회하려면 난이도 목표를 통과하는 유효한 블록을 먼저 채굴해야 합니다. 형평성. 그러나 우리는 불완전하게 검증된 몇 가지 거래를 취하고 "지분 증폭"이라는 기술을 사용하여 명백한 지분을 생성할 수 있음이 밝혀졌습니다.

보조 제목

주식 증폭

시스템에 0.01%의 지분만 있어도 공격자는 50%의 명백한 지분 블록을 채굴하는 데 5000개의 트랜잭션만 필요하다는 것을 알게 될 것입니다. 공격자가 많은 양의 명백한 지분을 수집한 후 새로 수집된 명백한 지분 출력을 사용하여 지분 증명 블록을 채굴하기 시작합니다. 마지막으로 공격자는 위 그림의 오른쪽과 같이 유효하지 않은 블록으로 피해 노드의 디스크를 채웁니다. 실제로 공격자는 암호화폐 거래소에서 일부 토큰을 구입하고 위의 방법을 통해 관심을 확장한 다음 이 토큰을 거래소에 다시 판매하고 나중에 공격을 실행할 수 있습니다. 그들이 부담하는 유일한 비용은 소액의 거래 수수료뿐입니다.

보조 제목

조정된 취약점 공개

우리는 먼저 Particl과 Qtum이라는 두 개의 암호화폐에 "취약점 1"이 있는지, 즉 블록이 RAM이나 디스크에 커밋되기 전에 이러한 암호화폐가 코인스테이크 트랜잭션을 확인하는지 여부를 조사했습니다. 취약점의 규모를 파악하기 위해 2018년 8월 9일 CoinMarketCap.com에서 시가 총액으로 알려진 암호화폐 목록을 수집하고 블록체인 기반 지분 증명 합의 유형으로 필터링했습니다. 참고로 비트코인에서 코드베이스를 포크한 암호화폐만 연구한 결과 총 26종의 암호화폐를 검사한 결과 Qtum, Navcoin, HTMLcoin, Emercoin, Partickl 등 5종의 암호화폐가 취약점에 영향을 받은 것으로 나타났습니다. 우리의 공격은 다른 암호화폐에는 적용되지 않는 것 같습니다.

취약성을 추가로 확인하기 위해 영향을 받는 5개의 추가 코드베이스에서 공격을 구현했습니다. 우리는 비트코인 ​​소프트웨어의 기존 테스트 세트, 특히 시뮬레이션된 타임스탬프와 손쉬운 블록 생성을 지원하는 "regtest" 모드를 활용합니다. 또한 Bitcoin TestFramework를 기반으로 Python 개발 언어를 기반으로 테스트 노드를 구축하고 공격자 행동에 의해 확장될 수 있도록 합니다. 우리는 테스트를 위해 Docker 컨테이너를 사용했으며, 취약성 공개의 일부로 종속성 및 영향을 받는 특정 커밋 해시를 재사용 가능한 툴킷으로 패키징하여 영향을 받는 5개 개발 팀 모두와 이 정보를 쉽게 공유할 수 있습니다.

그러나 여기에는 여전히 더 "문제가 되는" 문제가 있습니다. 즉, 대부분의 코드 베이스는 "regtest" 모드를 사용하지 않기 때문에 공격을 시각적으로 시연하거나 여러 번 사용할 수 있는 각 코드 베이스에 대한 툴킷을 제공할 수 없습니다. 따라서 우리는 stratisX의 C++ 코드 베이스 데모만 제공합니다. 코드베이스의 유사성을 기반으로 우리는 영향을 받을 가능성이 있는 15개의 암호화폐 개발 팀 모두에게 그들의 토큰이 익스플로잇의 영향을 받을 것이라고 생각한다고 알렸습니다. 이 중 5개의 암호화폐 개발팀은 취약점을 인정했고, 3개의 암호화폐 개발팀은 아직 조사 중이며, 나머지 3개 팀은 취약점을 인지하지 않은(일부 업그레이드 변경 사항이 구현될 경우), 4개의 팀은 여전히 ​​취약점을 조사 중이라고 답했다. 주어졌다. 답장을 보내지 않은 4개 팀에 대해서는 홈페이지를 통해 연락처를 찾아 깃허브 코드 저장소에 취약점 확인을 위한 재현성 툴킷을 넣었다.

보조 제목

완화

이미 일부 암호화폐 개발 팀이 이 기사에서 공개된 취약점에 대한 일련의 완화 조치를 구현하는 것을 보았습니다. 완화 조치를 구현한 암호화폐는 익스플로잇을 탐지할 수 있을 뿐만 아니라 위반 포크를 분리할 수도 있습니다. 간단히 말해서 노드는 분기된 체인에서 많은 수의 블록 헤더를 보내는 것과 같은 비정상적인 동작을 모니터링할 수 있습니다.

그러나 일부 완화 조치는 정직한 노드를 잘못 금지할 위험이 있을 수 있기 때문에 실제 공격의 "가짜 지분"을 합법적인 개편의 정직한 노드와 구별하는 방법에 어려운 문제가 남아 있습니다. 지금까지 본 완화 조치 중 일부는 합리적으로 잘 구현되었지만 후속 효과를 보려면 추가 조사와 분석이 필요합니다.

특정 길이 내에서 기능을 부분적으로 검증하는 일부 암호 화폐에 대한 완화도 있습니다. 메인 체인에서 지정된 길이를 초과하는 분기된 블록이 수신되면 해당 블록은 폐기됩니다. 예를 들어, Bitcoin Cash ABC 코드베이스는 이 접근 방식을 취하여 10번째 블록마다 롤링 체크포인트를 설정합니다. 그러나이 접근 방식에는 "블록 체인 분할"의 가능성과 같은 다른 단점도 있습니다. 점점 더 많은 정직한 노드가 블록체인의 다른 포크에 나타날 때 블록체인 분할이 발생하기 때문입니다. 특히 네트워크 연결이 좋지 않아 노드가 동기화되지 않고 충돌하는 체크포인트를 생성할 만큼 충분히 길지 않은 경우 "블록체인 분할"로 이어질 수도 있습니다. 노드가 다시 연결되더라도 체인의 공통 뷰에 도달할 수 없습니다.

그러나 비판적으로 우리는 이러한 완화 조치를 취하더라도 현재 체인의 트랜잭션 출력을 사용하여 코인스테이크 트랜잭션이 검증되는 경우 노드가 일시적으로 포크에서 자신을 발견하기 때문에 "블록체인 분할"의 위험이 있다는 점에 주목합니다. , 실제 메인 체인으로 전환하지 못할 수 있습니다.

"블록체인 분할" 위험은 또한 긴 체인을 비밀리에 채굴한 다음 블록체인 분할을 유발하기 위해 노드의 하위 집합에 게시하려고 시도할 수 있는 적대적 채굴자에 대한 새로운 공격 벡터를 도입합니다. 초기 블록 다운로드(Initial Block Download)에 있는 노드와 오랫동안 오프라인 상태였다가 다시 시작한 노드는 이러한 유형의 공격에 특히 취약하며 이 공격은 Eclipse 공격과 결합하여 정직한 노드를 "도입"할 수도 있습니다. 블록체인에 대한 공격자의 제어권에 포함됩니다.

따라서 이러한 모든 완화 기능은 공격을 실행하기 어렵게 만들 뿐 실제로 전체 인증을 대체하지는 않습니다. Qtum을 비롯한 일부 암호화폐는 향후 버전에서 메인이 아닌 블록체인의 블록을 완전 검증할 계획인 것으로 전해졌다.

보조 제목

마지막 생각들

마지막 생각들

"가짜 지분" 공격은 이론적으로 간단하지만 지분 증명 암호화폐의 설계에 가능한 문제가 있음을 드러냅니다. 작업 증명에서 의미가 있는 일부 아이디어는 지분 증명으로 안전하게 변환되지 않았습니다. 비트코인 코어 코드쉐어가 PoSv3 암호화폐의 "업스트림"이라는 점을 감안할 때, 우리는 이러한 지분증명 암호화폐가 더 많은 조사를 받아야 한다고 생각합니다. 이러한 취약점을 조사하는 동안 다른 코드 기반에서 수행된 작업과 주석 처리된 코드에서 몇 가지 예를 발견했습니다. 우리에게 이것은 일부 지분증명 암호화폐 개발자가 암호화폐를 설계할 때 이 합의 메커니즘을 완전히 이해하지 못한다는 것을 보여줍니다.

한편으로는 블록체인의 처리 효율성을 개선하기 위해 가능한 한 빨리 유효하지 않은 블록을 거부하기를 희망하지만, 다른 한편으로는 실제 거래에 영향을 미치고 지연시키는 포크된 블록체인에서 막힘이 발생하는 것을 원하지 않습니다. 메인 체인에서 처리 이 문제에 대한 체계적인 해결책은 현재 작업 그룹에서 열린 질문으로 남아 있습니다.

이 취약점이 최근 최소 두 개의 코드베이스(예: 비트코인의 CVE 2018-17144)에 영향을 미치는 것을 보았지만, 우리가 아는 한 20개 이상의 암호화폐가 영향을 받았는데 이는 많지 않습니다. 암호 화폐에서 디자인 아이디어의 중복 및 코드 재사용이 널리 퍼져 있는 점을 감안할 때 앞으로 이러한 취약점이 더 많이 발생할 것으로 예상됩니다.