COLDCARD RNG Incident (2026)

Coinkite와 Block은 손실 신고를 받은 뒤 2026년 7월 30일 초기 분석을 공개했습니다. 제조사에 따르면 공격자는 다른 사람의 기기를 제어할 필요가 없었습니다. 약하게 생성된 비밀을 재현해 대응하는 개인 키를 얻고, 그 키로 송금에 서명할 수 있었습니다. 따라서 지갑을 인터넷에서 분리하는 것만으로는 충분하지 않았습니다. 다만 이 사건 설명이 개별 손실의 원인까지 확정하는 것은 아니며, 기기 브랜드만으로도 판단할 수 없습니다. [2] [3]

지갑은 TRNG라는 하드웨어 난수원을 사용하도록 설계됐습니다. 그러나 libNgU 라이브러리를 통합한 뒤 ngu.random.bytes가 MicroPython의 rng_get 함수와 Yasmarang 소프트웨어 생성기로 연결됐습니다. 프로그램을 빌드할 때 잘못된 구성 요소들이 연결된 것입니다. MICROPY_HW_ENABLE_RNG의 값은 0이었지만 #ifndef는 설정의 존재 여부만 확인하고 값은 확인하지 않았습니다. 올바른 하드웨어 코드가 파일 안에 있어도 seed 생성에는 쓰이지 않을 수 있었습니다. 칩 고장이나 의도적으로 만든 비상 모드가 아니었습니다. [1]

비밀을 고르는 후보가 적으면 공격자가 유리합니다. 여기서는 프로그램 상태가 기기 데이터, 타이머, 이전 호출에 의존했습니다. Block은 Mk4, Mk5, Q의 추가 상태 갱신이 32비트로 제한되어, 나머지 상태가 고정되면 출력 시퀀스가 최대 2^32개라고 설명합니다. Coinkite의 예비 추정은 전체 엔트로피, 즉 불확실성의 양이 Mk2/Mk3에서 약 40비트, 최신 모델에서 72비트라는 것이었습니다. 수치의 전제가 다르므로 모든 공격의 비용이나 모든 지갑을 즉시 뚫을 수 있다는 뜻으로 해석할 수 없습니다. [3] [1]

공식 경고는 Mk2/Mk3의 4.0.1–4.1.9를 명시합니다. Block의 초기 분석은 4.0.0과 2021년 3월의 변경까지 포함합니다. 영향이 시작되는 경계에 자료 간 차이가 있으므로 추측으로 불확실성을 덮어서는 안 됩니다. 출처가 불명확하면 이전 가이드는 영향을 받은 지갑으로 취급할 것을 권합니다. Mk4/Mk5와 Q도 해당 펌웨어 계열의 수정 전에는 영향을 받았습니다. 당시 모든 배포 버전이 해당한다는 설명을 이후 수정된 버전에 적용하면 안 됩니다. [2] [3] [5]

최초 수정 버전은 Mk2/Mk3 4.2.0, Mk4/Mk5 Standard 5.6.0, Q Standard 1.5.0Q, Mk4/Mk5 Edge 6.6.0X, Q Edge 6.6.0QX입니다. Standard와 Edge는 별도 계열이므로 다른 계열의 숫자가 더 크다는 사실만으로 판단할 수 없습니다. 이 글을 검토할 때 제조사 권장 버전은 Mk4/Mk5의 Standard 5.6.3과 Q의 1.5.3Q입니다. 설치 전에 최신 공식 페이지, 파일 해시, 배포 서명을 확인하세요. 해시는 내용의 지문이며 서명은 출처 확인을 돕습니다. 업데이트를 올바르게 해도 기존 seed는 바뀌지 않습니다. [4]

약하게 만든 seed를 새 기기에 복원했다고 생각해 보세요. 기기는 달라졌지만 비밀은 같습니다. 지갑 복제나 전송도 마찬가지입니다. 해시는 데이터의 지문을 계산할 뿐 가능한 입력을 늘리지 않습니다. BIP39 Checksum은 단어의 오류를 찾도록 돕지만 부족한 난수를 보충하지는 않습니다. 반대로 다른 곳에서 안전하게 만든 seed를 COLDCARD에 가져오는 것만으로 이 특정 결함 때문에 약해지지는 않습니다. 생성 과정이 핵심입니다. [3] [5]

제조사의 예외는 편향 없는 주사위를 독립적으로 최소 50회 던져, 원래 Add Dice Rolls 기능에 입력한 경우입니다. 결과 순서가 기록되거나 노출된 적이 없어야 하며, 주사위 입력 후 표시된 최종 단어를 지갑에 사용해야 합니다. 횟수가 적거나 불확실하면 이전을 권합니다. BIP39 Passphrase는 다른 수단입니다. Seed와 함께 별도의 지갑을 결정하는 추가 비밀 문구로, 강하고 고유하면 공격 장벽을 높이지만 seed를 고치지는 못합니다. 제조사는 그 사용자에게도 이전을 권합니다. PIN은 기기 접근만 보호합니다. 현재 신규 seed 규칙과 이 과거 예외는 구분해야 합니다. [2]

먼저 원래 지갑의 백업을 사용할 수 있는지 확인하세요. 이전 가이드에 따라 수정된 펌웨어에서 완전히 새로운 seed를 만들고 백업을 검증합니다. 지갑의 짧은 식별자인 fingerprint와 기기 화면의 수신 주소를 확인하세요. 소액을 시험 전송하고 목적지와 입금을 확인한 다음 나머지를 옮깁니다. 잔액이 있는 모든 계정, passphrase 지갑, 파생 지갑, multisig 구성을 포함해야 합니다. 전체 이전이 확인될 때까지 기존 백업을 보관하세요. 불일치가 있으면 전송하거나 지우지 마세요. 복구용 비밀을 웹 양식에 입력해서는 안 됩니다. [5]

Multisig는 여러 키 중 정해진 수의 서명을 송금에 요구합니다. 공격자가 조건을 채울 만큼 키를 얻으면 보호가 충분하지 않습니다. 남은 키를 평가하고 새 서명 정책을 준비해 기기에서 확인한 뒤 자금을 옮겨야 합니다. Block은 같은 생성기가 독립된 Paper Wallet 키와 일부 임시 암호화 키에도 쓰였다고 설명합니다. 영향은 구체적인 용도와 공격자가 가진 데이터에 따라 다르며 모든 기능에 똑같이 적용되지는 않습니다. [3] [5]

상태 페이지에는 실제 Mk4의 하드웨어 생성기 시험, 소스 코드 검토, 특정 수정판의 독립적인 재빌드가 기재돼 있습니다. 이는 설명된 작동 방식을 확인하는 데 도움이 되지만 모든 배포 파일이 안전하다는 증거는 아닙니다. 현재 Standard는 신규 seed 생성 시 사용자 자신의 난수 기여도 요구합니다. 따라서 항상 선택 사항이라고 했던 과거 안내는 이 계열의 현재 절차가 아닙니다. 페이지는 조치 진행 상황을 기록하며, 별도의 상세 기술 원인 보고서는 여전히 준비 중이라고 밝힙니다. [4]