본문으로 이동
Financial Context Wiki

콜드 월렛: 오프라인 서명, 복구 및 운영 통제

키 생성, 지갑 아이덴티티, 백업, 거래 검토, 오프라인 서명, 멀티시그, 복구 및 사고 대응 전반에 걸쳐 콜드 월렛 보관을 설계하고 검증하는 방법을 배우세요.

업데이트

교육 목적으로만 사용됩니다; 투자 조언이 아닙니다. 투자는 손실을 초래할 수 있습니다.

직접적인 답변

콜드 월렛은 비밀 서명 자료와 결정적 승인 단계를 인터넷에 연결된 소프트웨어의 일반적인 노출 밖에 보관하는 관리 시스템입니다. 자산은 블록체인에 그대로 남아 있으며, 시스템은 상태 변경을 승인할 수 있는 키나 기타 권한을 제어합니다. ’콜드 월렛’은 운영상의 명칭이지 프로토콜로 정의된 장치 클래스가 아니며, 콜드함은 브랜드나 연결 유형이 아닌 전체 워크플로우의 속성입니다.

하드웨어 서명기는 개인 키가 격리된 상태로 유지될 수 있기 때문에 USB로 연결된 상태에서도 콜드 스토리지를 지원할 수 있습니다. 그러나 사용자가 검증되지 않은 목적지나 불투명한 계약 호출에 서명하면 워크플로우는 안전하지 않습니다. 반대로, 에어갭 컴퓨터는 단순히 네트워크 인터페이스가 없다고 해서 안전한 것은 아닙니다. 손상된 엔트로피, 설치 미디어, 트랜잭션 파서, 이동식 미디어, 백업 또는 디스플레이가 여전히 경계를 무력화할 수 있습니다. 콜드 스토리지는 원격 키 추출 위험을 줄여주지만, 트랜잭션 의도, 소프트웨어 정확성, 복구, 프라이버시, 또는 최종성을 증명하지는 않습니다.

복구 사본은 단순한 ’백업’이 아닙니다. 니모닉, 원시 시드, 확장 개인 키 또는 동등한 복구 공유는 지출 권한을 재생성할 수 있으므로 서명자와 동등한 보호가 필요합니다. 비밀번호, 파생 경로, 네트워크, 스크립트 유형, 지갑 디스크립터, 키 순서 및 임계값 정책 또한 예상되는 주소를 복구하는 데 필요할 수 있습니다. 공개 감시 전용 지갑은 일반적으로 서명할 수 없지만, xpub 또는 디스크립터는 주소 관계와 거래 내역을 공개할 수 있으며, BIP-32는 일반 공개 키보다 강한 보안 의미를 가진 확장 공개 키를 제공합니다.

콜드 월렛
0 / 5
0 개 항목 검토; 5 개 항목 미해결

모든 항목을 검토해도 자산, 거래 또는 시스템의 안전이 입증되는 것은 아닙니다.

콜드 스토리지를 설계하고 검증하는 방법

1. 권한과 위협 모델 정의

정확한 네트워크, 자산, 계정 또는 출력 정책, 소유자, 수혜자, 복구 권한, 예상 거래 빈도 및 최대 운영 노출을 기록하십시오. 원격 악성코드, 악성 애플리케이션, 공급망 침해, 내부 공모, 물리적 도난, 강요, 화재, 홍수, 손실, 무능력, 상속을 별도의 위협으로 식별하십시오. 무엇을 콜드 상태로 유지해야 하는지 결정하십시오: 단일 개인 키, 임계값 내 모든 키, 서명자 정족수, EIP-712 승인 키 또는 지갑 코드를 변경할 수 있는 관리자.

2. 신뢰할 수 있는 엔트로피와 소프트웨어 초기화

인증된 경로를 통해 장치와 소프트웨어를 획득하고, 초기화 상태를 점검하며, 지원되는 경우 릴리스를 검증하고, 포장이나 도우미가 제공한 사전 생성된 니모닉이나 비밀은 거부하십시오. 통제된 환경에서 엔트로피를 생성하고, 어떤 표준과 구현이 이를 생성했는지 기록하십시오. BIP-39는 128를 256 비트 엔트로피로 니모닉에 인코딩하고, 선택적 패스프레이즈과 함께 니모닉에서 512-bit 시드를 파생합니다; 이는 기억하기 쉬운 문장을 안전한 지갑으로 전환하는 표준이 아닙니다.

2-of-3 서명 구성의 복원력

상당한 자금이 입금되기 전에 네트워크, 마스터 지문, 파생 표준과 전체 경로, 계정 인덱스, 주소 또는 스크립트 유형, 그리고 최초 확인된 수신 주소를 기록하세요. Bitcoin 정책의 경우 출력 디스크립터, 체크섬, 키 출처, 임계값, 서명자 수, 키 순서, 변경 브랜치를 보존하세요. 각 서명자에 대해서는 해당 키와 화면에 표시된 정책이 의도한 것인지 독립적으로 확인하세요. xpub는 민감한 메타데이터로 취급하세요: 비강화 공개 하위 키를 파생할 수 있으며, 프라이버시를 손상시키고, 대응하는 비강화 하위 개인 키와 함께 사용하면 BIP-32 하에서 상위 확장 개인 키가 노출될 수 있습니다.

4. 백업 및 복구 테스트

니모닉이나 조각을 포함한 모든 필수 복구 입력, 선택적 패스프레이즈, 디스크립터 또는 스마트 계정 구성, 파생 경로 및 복구 지침을 보호하십시오. 니모닉 단어를 임의로 나누어 방식을 만들지 마십시오. 단일 사본으로 충분하지 않은 경우 지정된 임계값 또는 다중서명 설계를 사용하십시오. 사본을 실제로 독립적인 장애 영역에 배치하고 내용을 노출하지 않고 접근을 추적하십시오. 신뢰할 수 있는 예비 장치나 재초기화된 서명자에서 복원을 연습하고 테스트 환경을 지우기 전에 예상 지문, 정책, 수신 주소를 비교하십시오.

5. 전체 서명 의도 구성 및 검증

온라인 코디네이터는 체인 상태를 얻고 서명되지 않은 요청을 만들 수 있지만 신뢰할 수 없습니다. Bitcoin PSBT의 경우, 네트워크, 모든 입력 및 UTXO 금액, 수신자 출력, 금액, 수수료, 수수료율, 잠금 시간, 서명 해시 정책, 그리고 다른 모든 출력이 인증된 변경인지 확인하십시오. EVM 거래의 경우, chainId, nonce, to, value, 가스 한도, 수수료 상한, 그리고 디코딩된 data을 확인하십시오; EIP-712의 경우, 도메인, chainId, verifyingContract, 메시지 필드, 논스 및 적용 가능한 경우 기한을 확인하십시오. EIP-712는 데이터를 구성하고 도메인을 분리하지만, 표준 자체는 재생 보호를 명시적으로 제공하지 않습니다.

6. 통제된 전송 경계를 거쳐 서명

승인된 QR, 카드, 케이블 또는 다른 채널을 통해 필요한 unsigned 또는 부분적으로 서명된 페이로드만 이동하십시오. 에어 갭과 QR 코드는 파서나 매체를 신뢰할 수 있게 만들지 않습니다: 서명자는 페이로드를 파싱하고, 정책과 변경 사항을 인증하며, 중요한 결과를 표시하고, 지원되지 않는 필드는 거부해야 합니다. 다중 서명에서는 서명자, 운영자, 위치, 공급업체 및 복구 경로를 위협 모델에 맞을 정도로 독립적으로 유지하십시오; 조정자는 교체 가능하고 정책을 눈치채지 않고 변경할 수 없다고 간주하십시오. 방송 전에 서명된 트랜잭션이나 작업을 승인된 의도와 비교하십시오.

7. 대조, 유지보수 및 마이그레이션 준비

방송 후, 거래 식별자, 포함된 거래, 출력 또는 로그, 실제 수수료, 잔돈, 계정 논스, 허용 한도 및 결과 잔액을 서명된 의도와 비교한 다음, 체인 및 사용 사례에 적합한 최종성을 기다립니다. 호환 가능한 소프트웨어, 검증된 펌웨어 경로, 읽을 수 있는 백업, 문서화된 디스크립터 및 주기적인 복구 연습을 유지하되, 생산 비밀을 온라인 장치에 입력하지 마십시오. 서명 또는 복구 비밀이 노출될 수 있는 경우, 일반 단일 키 계정은 해당 키를 폐기할 수 없습니다: 새로운 권한을 설정하고, 자산과 역할을 이전하며, 프로토콜이 허용하는 경우 남은 권한을 무효화하고, 사건 기록을 보존하십시오.

작동된 예제

단계적 할당 및 자금 지원

수탁 계획은 온라인 상호작용 지갑을 자산 가치의 5%, 즉 총 100,000 units 중 핫 지갑의 100,000 × 5% = 5,000 units로 제한하고 콜드 지갑에는 95,000 units를 둡니다. 콜드 주소로 먼저 100-unit 테스트 전송을 하고, 나머지는 95,000 - 100 = 94,900 units입니다. 두 전송 뒤 콜드 잔액 목표는 100 + 94,900 = 95,000 units입니다. 소액 테스트는 한 시점의 설정 오류만 제한하며 향후 서명이나 백업 복구까지 검증하지는 않습니다.

Bitcoin PSBT 요금 및 변경

PSBT는 0.80 BTC와 0.35 BTC 입력을 사용하며 합계는 1.15 BTC입니다. 수취인에게 1.00 BTC를 보내고 수수료를 250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC로 산정합니다. 따라서 인증된 잔돈은 1.15 - 1.00 - 0.000020 = 0.149980 BTC여야 합니다. 서명 장치가 기록된 정책에서 해당 잔돈 출력을 식별할 수 없다면 총액 계산이 맞더라도 서명해서는 안 됩니다.

EVM 최대 예산 대비 실제 수수료

EVM 계정은 5 ETH로 시작하며 1.2 ETH의 이체를 승인합니다. 30,000 gas 한도와 50 gwei 최대 수수료는 30,000 × 50 gwei = 0.001500 ETH의 수수료 예산을 의미합니다. 거래가 21,000 gas를 25 gwei의 유효 가격으로 사용하면 실제 수수료는 21,000 × 25 gwei = 0.000525 ETH가 되며 5 - 1.2 - 0.000525 = 3.799475 ETH가 남습니다. 서명자는 수수료 한도와 data를 검토해야 하며, 최대 예산이 청구될 것이라고 가정하거나 빈 인터페이스처럼 보인다고 해서 일반적인 이체가 증명된다고 생각해서는 안 됩니다.

3. 재현 가능한 지갑 식별 정보 고정

2-of-3 정책은 서명 장치 A, B, C로 구성되며 유효한 서명 조합은 3개, 즉 AB, AC, BC입니다. 하나를 사용할 수 없으면 정확히 1개 조합이 남고, 하나만 침해되면 공격자가 단독으로 지배하는 유효 조합은 0개입니다. 두 개가 침해되면 공격자가 1개 유효 조합을 지배하여 지출할 수 있습니다. 따라서 이 설계는 한 번의 손실 또는 고립된 한 건의 침해는 견디지만 두 건은 견디지 못하며, 복구에는 올바른 디스크립터, 파생 데이터, 키 순서가 여전히 필요합니다.

위험과 검토 실패

  • 네트워크 또는 정책 오류: 잘못된 체인, 주소 형식, 스크립트, 계정 또는 스마트 계정 정책에서 유효한 키를 복구하면 다른 주소나 사용할 수 없는 주소가 나타날 수 있습니다.
  • 엔트로피 부족: 예측 가능한 난수, 브레인월렛 또는 침해된 생성기는 오프라인 키도 추측 가능하게 만듭니다.
  • 타인이 제공한 비밀: 미리 인쇄되거나 가져온 니모닉, 촬영한 니모닉, 조력자가 제공한 니모닉은 이미 공격자가 통제할 수 있습니다.
  • 백업 유출: 종이, 금속 매체, 클라우드 사본, 프린터, 카메라, 배송 과정 또는 상속 문서에서 전체 지출 권한이 유출될 수 있습니다.
  • 패스프레이즈 오류: BIP-39 패스프레이즈를 잃거나 잘못 입력하면 오류 없이 다른 지갑이 파생될 수 있습니다.
  • 파생 설정 불일치: 경로, 코인 유형, 계정 인덱스 또는 지갑별 규칙이 빠지면 복구 가능한 자산이 표시되지 않을 수 있습니다.
  • 구성 정보 손실: 멀티시그 키만 있고 디스크립터, 임계값, 스크립트 유형, 키 출처, 키 순서가 없으면 자금이 든 지갑을 재현하지 못할 수 있습니다.
  • 공개 메타데이터 유출: xpub, 디스크립터, 주소 목록 또는 코디네이터 데이터베이스는 잔액, 주소 관계, 향후 주소를 노출할 수 있습니다.
  • 공급망 침해: 변조된 하드웨어, 펌웨어, 소프트웨어, 포장 또는 업데이트 채널이 엔트로피, 주소 또는 서명을 바꿀 수 있습니다.
  • 호스트 대체: 온라인 코디네이터는 수취인, 금액, 수수료, 잔돈, calldata, 타입 메시지 또는 미서명 페이로드를 바꿀 수 있습니다.
  • 표시 한계: 잘린 표시, 블라인드 서명, 미지원 스크립트 또는 불완전한 디코딩은 중요한 권한을 숨길 수 있습니다.
  • 잔돈 주소 공격: 서명 장치가 지갑 정책에 따라 잔돈을 인증하지 않으면 Bitcoin 거래의 위장된 잔돈 출력이 공격자에게 전송될 수 있습니다.
  • 수수료 또는 nonce 오류: 과도한 수수료, 오래된 EVM nonce, 잘못된 locktime 또는 의도하지 않은 sighash 모드는 실행을 지연, 대체 또는 왜곡할 수 있습니다.
  • 지속되는 컨트랙트 권한: 토큰 승인, permit, 모듈, 위임 및 관리자 호출은 눈앞의 거래보다 오래 유효할 수 있습니다.
  • 전송 채널 공격: QR, USB, 메모리 카드, 케이블 및 파서 형식은 악성 페이로드를 운반하거나 메타데이터를 유출할 수 있습니다.
  • 임계값 상관관계: 서명 장치의 동일 장소 보관, 시드 공유, 단일 공급업체, 단일 운영자 또는 단일 복구 장소 의존은 임계값 독립성을 훼손합니다.
  • 물리적 공격: 도난, 강압, 감시, 변조 및 비밀 노출은 네트워크 연결이 없어도 발생할 수 있습니다.
  • 환경적 손실: 화재, 홍수, 부식, 매체 열화, 금고 접근 불가, 사망 또는 무능력으로 올바른 비밀도 사용할 수 없게 됩니다.
  • 호환성 저하: 오래된 펌웨어, 미지원 파생 또는 스크립트 유형, 기록되지 않은 마이그레이션은 향후 복구나 서명을 막을 수 있습니다.
  • 불완전한 사고 대응: 키, 역할, 승인 및 복구 권한을 이전하지 않고 잔액만 확인하면 기존 침해가 계속 유효할 수 있습니다.

일반적인 오해

콜드 지갑은 영원히 물리적으로 분리된 상태로 있어야 하나요?

아니요. 보안 속성은 비밀 권한이 격리된 상태로 유지되고 서명이 통제되고 검증 가능한 경계를 통해 이루어진다는 것입니다. 케이블로 연결된 하드웨어 서명기는 그 속성을 유지할 수 있지만, 설정이나 페이로드 검토가 손상된 공기차단 컴퓨터는 그렇지 않을 수 있습니다.

코인이 하드웨어 장치 안에 저장되나요?

아니요. 블록체인 상태는 자산을 기록합니다. 장치는 거래를 서명할 수 있는 권한을 보호하거나 사용하며, 호환 가능한 복구 자료는 다른 구현에서 그 권한을 재현할 수 있습니다.

니모닉 백업이 서명 장치보다 덜 민감한가요?

아니요. 전체 니모닉과 필요한 암호 문구로 지갑을 재생성할 수 있습니다. 백업은 일반적으로 비활성 상태이지만, 백업이 유출되면 활성 서명 키가 유출되는 것만큼 결정적일 수 있습니다.

멀티시그가 백업과 구성 기록의 필요성을 제거하나요?

아니요. 임계값은 선택된 단일 장애 지점을 줄이지만, 각 키에는 복구 계획이 필요하며 지갑 정책이나 디스크립터는 재현 가능해야 합니다. 살아남은 키가 너무 적거나 구성이 손실되면 여전히 자금을 잠글 수 있습니다.

성공적인 테스트 전송이 콜드 스토리지 시스템의 안전을 증명하나요?

아니요. 그것은 한 번에 제한된 경로만 확인합니다. 그것이 엔트로피 품질, 백업 기밀성, 복원, 미래 거래 해독, 정족수 독립성, 소프트웨어 업데이트, 계약 안전성 또는 사고 복구를 증명하는 것은 아닙니다.

관련 주제

출처

탐색

위키 검색...