진짜 돈을 미끼로 거는 보안 실험
'Steal My Bitcoin'이라는 사이트가 공개됐어요. 이름 그대로 운영자가 실제 비트코인을 걸어두고 '가져갈 수 있으면 가져가 보라'고 공개적으로 도전장을 내민 프로젝트예요. 장난처럼 들리지만 보안 업계에서는 꽤 오래됐고 진지하게 쓰이는 검증 방식이에요. 키를 구체적으로 어떻게 보관하는지, 도전 규칙이 뭔지는 사이트에서 직접 확인해 보세요. 이 글에서는 이런 도전이 왜 의미가 있는지를 풀어볼게요.
보안을 증명하는 건 원래 정말 어렵거든요. '우리 시스템은 안전합니다'라고 말하기는 쉬워요. 그런데 남들이 그 말을 믿게 만드는 건 완전히 다른 문제예요. 그래서 나온 아이디어가 '진짜 보상을 걸고 아무나 공격하게 두기'예요. 보상이 크면 실력자들이 진지하게 덤벼들 거예요. 그런데도 오랫동안 아무도 못 가져갔다면 그 사실 자체가 꽤 강력한 증거가 돼요.
비트코인이 이런 실험에 잘 맞는 이유
블록체인은 누구나 볼 수 있는 공개 장부예요. 지갑 주소만 알면 블록 익스플로러(블록체인 거래 내역을 웹에서 조회하는 사이트)에서 잔액이 얼마인지, 언제 빠져나갔는지 누구나 확인할 수 있어요.
이게 중요한 이유는 운영자가 '아직 아무도 못 뚫었어요'라고 거짓말을 할 수 없기 때문이에요. 돈이 그대로 있으면 안 뚫린 거고, 빠져나가면 뚫린 거예요. 옛날 광부들은 유독가스를 먼저 알아채려고 탄광에 카나리아를 데리고 들어갔는데요. 여기서는 지갑 잔액이 그 카나리아처럼 침입 여부를 알려주는 경보 장치가 되는 거예요. 게다가 비트코인 소유권은 결국 개인키(지갑의 비밀번호에 해당하는 아주 큰 숫자) 하나로 결정돼요. 그래서 '키를 지키는 방식'이 안전한지 검증하기에 아주 깔끔한 구조예요.
공격자는 어디를 노릴까
이런 도전에서 비트코인 암호 자체(타원곡선 암호)를 정면으로 깨는 경우는 사실상 없어요. 현실적인 공격은 거의 항상 그 주변에서 일어나거든요.
- 약한 난수: 개인키는 예측할 수 없는 무작위 숫자여야 해요. 그런데 키를 만드는 과정이 허술하면 경우의 수가 확 줄어들어요. 대표적인 예가 2023년 'Milk Sad' 사건이에요. Libbitcoin Explorer라는 도구가 현재 시간을 시드로 쓰는 32비트 난수 생성기를 쓰는 바람에 가능한 키가 약 43억 개로 줄었고, 실제로 많은 지갑이 털렸어요.
- 사람이 만든 비밀: '브레인 월렛'처럼 기억하기 쉬운 문장으로 키를 만들면 공격자는 사전 단어와 유명한 문구를 대량으로 넣어보는 것만으로 키를 찾아낼 수 있어요. 이런 지갑에 돈이 들어오면 몇 초 만에 쓸어가는 봇들이 늘 돌아가고 있고요.
- 키를 다루는 환경: 서버 취약점, 의존성 라이브러리, 부채널 공격(전력 소모나 응답 시간 같은 간접 신호로 비밀을 추측하는 방법), 운영자를 속이는 사회공학까지 모두 공격 대상이 돼요.
비슷한 선례들
원조 격으로 자주 언급되는 사례가 2015년 MirageOS 팀의 'BTC Piñata'예요. 팀은 직접 구현한 TLS 스택을 검증하려고 10 BTC의 개인키를 품은 서버를 공개했고, TLS를 뚫으면 키를 가져가도 된다고 했어요. 운영 기간 내내 아무도 키를 빼내지 못했고, 그 결과 자체가 구현이 튼튼하다는 걸 보여주는 홍보가 됐어요.
2015년에 누군가 키 범위를 단계적으로 넓혀가며 여러 주소에 비트코인을 넣어둔 이른바 '비트코인 퍼즐'도 유명해요. 키 범위가 좁은 앞쪽 퍼즐들은 이미 풀렸어요. 하지만 뒤로 갈수록 난이도가 기하급수적으로 올라가서 지금도 GPU를 동원한 도전이 이어지고 있어요. 키 길이가 조금만 늘어도 무작위 대입이 얼마나 비현실적이 되는지 보여주는 살아있는 교과서 같은 사례예요.
물론 한계도 있어요. '아무도 못 뚫었다'가 '뚫을 수 없다'와 같은 말은 아니거든요. 상금이 공격 비용보다 작으면 실력자들이 굳이 시간을 쓰지 않을 수도 있어요. 진짜 고수라면 찾은 취약점을 아껴뒀다가 더 큰 표적에 쓸 수도 있고요. 그래서 이런 도전은 정식 보안 감사를 대신하는 게 아니라 보완하는 장치로 보는 게 맞아요.
한국 개발자에게 주는 시사점
암호화폐를 다루지 않더라도 가져갈 교훈이 많아요. 첫째, 보안 주장은 검증 가능한 형태일 때 설득력이 생겨요. 사내 시스템이라도 버그바운티나 레드팀 훈련처럼 '깨보라고 열어두는' 문화를 들이면 생각하지 못한 구멍을 찾을 수 있어요.
둘째, 난수는 아무거나 쓰지 마세요. 토큰, 세션 ID, 비밀번호 재설정 링크처럼 예측되면 안 되는 값이 있잖아요. 이런 값에는 Math.random() 같은 일반 난수 대신 Node.js의 crypto.randomBytes()나 Python의 secrets 모듈 같은 암호학적으로 안전한 난수 생성기를 써야 해요. Milk Sad 사건도 결국 이 기본 하나를 놓쳐서 생긴 일이었어요.
셋째, 지갑이나 결제처럼 돈이 직접 걸린 서비스를 만든다면 위의 공격 유형들을 위협 모델링(누가, 어디를, 어떻게 공격할지 미리 그려보는 작업) 체크리스트로 써보세요. 내 서비스의 키가 어디서 만들어지고, 어디에 저장되고, 누가 접근할 수 있는지 하나씩 따라가 보기만 해도 많은 게 보여요.
마무리
한줄 정리: 진짜 돈을 걸고 '털어보라'고 하는 건 말이 아니라 결과로 보안을 증명하는 가장 솔직한 방법이에요.
여러분 서비스에 상금을 걸고 공개 도전을 연다면, 가장 먼저 뚫릴 곳은 어디일까요? 코드일까요, 인프라일까요, 아니면 사람일까요?
🔗 출처: Hacker News