117 / 736ECL

Eclipse Attack

노드는 연결되어 있지만 공격자가 나머지 네트워크를 가립니다

인터넷도 연결도 정상인데 노드가 Bitcoin의 실제 상황을 보지 못할 수 있습니다. Eclipse Attack은 다른 참여자로 향하는 경로를 장악해 어떤 메시지가 도착할지 공격자가 결정하는 공격입니다.

Eclipse Attack은 공격자와의 연결은 남긴 채 노드를 정직한 피어로부터 의도적으로 고립시킵니다. Full Node는 Bitcoin 규칙을 독립적으로 검증하는 프로그램입니다. 고립되어도 검증은 계속하지만 불완전하거나 오래된 정보만 받을 수 있습니다. 무효한 데이터를 유효하게 만드는 것이 아니라, 노드가 볼 수 없는 부분을 악용합니다.

안나가 비트코인 결제를 받으며 자신의 노드를 살펴봅니다. 노드는 Bitcoin 네트워크에 참여하는 프로그램을 실행하는 컴퓨터입니다. 활성 연결이 표시되지만 중요한 외부 경로는 모두 공격자가 통제합니다. 메시지는 오지만 공격자가 보여 주는 것만 도착합니다. 이것이 Eclipse Attack의 핵심입니다. 보통 악성 연결 하나만으로는 부족합니다. 정직한 노드로 통하는 경로가 작동하면 숨겨진 블록이 들어와 공격자의 통제를 깨뜨릴 수 있습니다. 블록은 공동 기록에 추가하는 거래 묶음입니다. [1] [6]

Ethan Heilman, Alison Kendler, Aviv Zohar, Sharon Goldberg는 2015년에 당시 Bitcoin 네트워크를 대상으로 한 공격을 설명했습니다. 노드의 주소 목록을 공격자 주소로 채워 재연결할 때 공격자의 컴퓨터에만 연결되게 하는 방법을 연구했습니다. 연결 선택을 악용한 것이며, 디지털 서명 등을 보호하는 수학적 원리를 무너뜨린 것은 아닙니다. 연구는 방어책도 제안했습니다. 당시 실험 결과를 오늘날 Bitcoin Core에 대한 공격 성공률로 볼 수는 없습니다. [1] [7]

고립에 성공하면 공격자는 어떤 블록과 거래를 안나에게 전달하고 무엇을 숨길지 고를 수 있습니다. 안나가 보내는 거래의 전파를 막거나 출처를 관찰할 수도 있습니다. 연결 장악 자체에는 채굴 능력의 과반수가 필요하지 않습니다. 그렇다고 뒤따르는 모든 공격을 추가 노력 없이 할 수 있다는 뜻은 아닙니다. 예를 들어 새 블록을 만들려면 실제 작업량이 필요합니다. [1] [6]

안나의 Full Node는 서명, 지출 조건, 허용된 채굴 보상을 계속 검증합니다. 여기서 서명은 비밀 숫자 값인 개인 키로 결제를 승인했다는 검증 가능한 증거를 만드는 작업입니다. 다른 사람은 그 비밀 값을 몰라도 서명을 확인할 수 있습니다. 안나의 노드는 유일하게 연결된 출처가 보냈다는 이유로 잘못된 거래를 받아들이지 않습니다. 하지만 도착하지 않은 유효한 블록을 검증만으로 알아낼 수는 없습니다. 받은 편지가 진짜인지는 확인해도 누군가 더 최근의 편지를 모두 숨겼다는 사실은 모를 수 있는 것과 같습니다. 정보의 유효성과 완전성은 서로 다른 문제입니다. [5] [9]

다른 노드가 진행하는 동안 고립된 노드는 마지막으로 안 블록에 머물 수 있습니다. 고립된 채굴자는 버려진 분기에서 계속 채굴하다 예상했던 보상을 잃을 수도 있습니다. 그러나 블록을 오래 기다리는 것만으로 공격이 증명되지는 않습니다. 채굴에는 무작위성이 있고 일반적인 장애도 지연을 만듭니다. 화면 갱신이 느리다는 사실 하나보다 여러 징후를 함께 봐야 합니다. [1] [5] [8]

공격자는 안나의 결제가 담긴 유효한 비공개 분기를 보여 주면서 나머지 네트워크에서는 같은 자금을 다른 곳에 쓸 수 있습니다. 연결이 회복되면 노드는 누적 작업량이 더 많은 유효한 분기로 전환할 수 있습니다. 이것이 Reorg, 즉 받아들인 역사의 일부를 교체하는 일입니다. 버려진 분기의 결제는 확인 상태를 잃을 수 있습니다. 하지만 공격자도 자신의 블록에 Proof of Work를 제공해야 합니다. 이는 많은 계산이 필요한 탐색의 결과를 검증할 수 있는 증거이며, 이 블록들도 같은 요건을 충족해야 합니다. 필요한 작업량은 공격자가 고립시킨 채굴자에게서 나올 수도 있습니다. 꾸며 낸 확인 횟수로 Full Node를 속일 수 없으며 성공은 고립 시간과 자원에도 달려 있습니다. [1] [5] [6]

방어는 모든 연결이 한 공격자에게 모이는 것을 막으려 합니다. Bitcoin Core는 알려진 주소를 그룹화하고 외부로 나가는 연결을 선택할 때 네트워크 다양성을 추구합니다. IP 주소는 프로그램이 연결할 네트워크상의 위치를 나타냅니다. 그래도 다른 IP 주소가 같은 운영자에게 속하거나 같은 기반 시설을 통과할 수 있습니다. 이런 조치는 집중을 줄이고 공격을 어렵게 하지만 모든 피어의 독립성을 증명하지는 않습니다. [3] [4]

Bitcoin Core는 feeler라는 짧은 연결로 다른 주소에 도달할 수 있는지 확인합니다. 추가 블록 중계 연결은 다른 역할을 합니다. 새 블록 헤더, 즉 블록의 간결한 기술 기록과 체인의 진행 상황에 대한 또 다른 정보를 가져올 수 있습니다. 따라서 모든 feeler가 곧바로 최신 역사를 내려받는다는 설명은 부정확합니다. 인용한 Bitcoin Core 29.0 코드는 이처럼 다른 방어 수단을 보여 주며, 어느 하나도 고립 해제를 보장하지 않습니다. [4] [8]

알고 있는 피어를 수동으로 추가하면, 상대가 접속 가능하고 나머지 네트워크와 실제로 연결된 경우 새 경로가 될 수 있습니다. 다만 같은 제공업체를 거치는 여러 연결은 독립적이지 않을 수 있습니다. 남의 주소 목록을 무작정 복사하기보다 지원되는 소프트웨어를 유지하고 연결 설정을 이해하는 편이 좋습니다. 직접 검증은 그대로 유지됩니다. 출처가 접속 가능하다고 믿는 것이 무효한 블록을 보낼 권한을 주는 것은 아닙니다. [2] [4] [6]

Sybil Attack은 한 공격자가 여러 신원으로 활동하는 것으로 Eclipse Attack을 도울 수 있습니다. Eclipse는 특정 노드나 선택한 집단을 정직한 출처에서 고립시키는 데 성공한 상태를 말합니다. 더 넓은 네트워크 분할은 전체 네트워크의 여러 부분을 나누며 반드시 이런 방식으로 생기지는 않습니다. 사용자에게 중요한 점은 Full Node로 직접 검증하더라도 공격자가 통제하지 않는 정보에 접근할 수 있어야 한다는 것입니다. [1] [6]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Sybil Attack, Block Propagation, Compact Blocks, Nakamoto Consensus, Bitcoin, Full Node. 다음 항목에서도 이 글을 참조합니다 이중 지불, Byzantine Generals Problem, Nakamoto Consensus, Sybil Attack.

DOC · 001Heilman et al. — Eclipse Attacks on Bitcoin1차 출처 DOC · 002Bitcoin Developer Guide — P2P Network문서 DOC · 003Bitcoin Core v29.0 — addrman문서 DOC · 004Bitcoin Core v29.0 — Peer connections문서 DOC · 005Bitcoin Developer Guide — Block Chain문서 DOC · 006Bitcoin Optech — Eclipse attacks문서 DOC · 007USENIX Security 2015 — Eclipse Attacks on Bitcoin’s Peer-to-Peer Network1차 출처 DOC · 008Bitcoin Core v29.0 — Message processing문서 DOC · 009Bitcoin Core v29.0 — Block validation문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다