주소 체크섬은 주소 데이터에서 계산한 검증 정보를 함께 넣어 일부 입력·복사 오류를 탐지합니다. Base58Check, Bech32, EIP-55는 방식이 다르지만 손상된 문자열을 거부하는 데 도움을 줍니다. 그러나 공격자가 제공한 유효한 주소, 잘못 선택한 네트워크, 같은 앞뒤 문자를 가진 주소는 체크섬을 통과하므로 수취인 확인을 대신하지 못합니다.
체크섬은 주소 문자열이 손상됐는지 검사한다
암호화폐 주소는 긴 문자와 숫자로 구성되어 사람이 직접 읽기 어렵습니다. 체크섬은 주소의 핵심 데이터에서 계산한 추가 정보를 문자열에 반영해, 문자를 잘못 타이핑하거나 일부가 바뀌었을 때 지갑이 불일치를 찾도록 돕습니다. 유효성 검사를 통과하지 못한 주소는 거래 생성 전에 거부할 수 있습니다.
체크섬이 맞다는 것은 입력 문자열이 해당 형식의 계산 규칙과 일치한다는 뜻입니다. 그 주소를 누가 만들었는지, 수취인이 실제로 통제하는지, 거래 목적이 맞는지는 증명하지 않습니다. 공격자가 자신의 주소를 정상적으로 생성하면 완벽히 유효한 체크섬을 가집니다. 형식 검증과 상대 인증을 분리해야 합니다.
| 형식 | 체크섬 표현 | 주요 점검 |
|---|---|---|
| Bitcoin Base58Check | 끝에 체크섬 바이트 포함 | 버전·데이터 손상 탐지 |
| Bitcoin Bech32/Bech32m | 다항식 체크섬 문자 | 접두부·witness 버전과 함께 검증 |
| Ethereum EIP-55 | 16진 문자의 대소문자 혼합 | 대소문자 패턴 검증 |
| 소문자 이더리움 주소 | 체크섬 정보 없음 | 형식 길이만으로 소유자 확인 불가 |
비트코인 Base58Check는 버전과 해시에 체크섬을 붙인다
Bitcoin Developer Reference는 P2PKH나 P2SH 해시 앞에 네트워크·형식을 나타내는 버전 바이트를 붙이고, 이중 SHA-256 결과의 앞부분을 체크섬으로 더한 뒤 Base58로 인코딩하는 절차를 설명합니다. 디코더는 체크섬을 다시 계산해 전달 중 손상 여부를 확인합니다.
버전 바이트도 계산 대상에 포함되므로 메인넷과 테스트넷 형식을 구분하는 데 도움이 됩니다. 하지만 지갑이 다른 체인의 비슷한 형식을 지원하거나, 사용자가 거래소에서 잘못된 출금 네트워크를 선택하면 주소 체크섬만으로 자산 회수 가능성을 판단할 수 없습니다. 출금 시스템의 네트워크 이름과 주소 형식을 함께 봐야 합니다.
체크섬은 주소의 무결성을 검사하지만 수취인의 신원을 인증하지 않는다.
JOBCOIN 해설
Bech32와 Bech32m은 witness 버전까지 맞춰야 한다
BIP 173의 Bech32는 사람이 읽을 수 있는 접두부, 데이터, 체크섬을 결합합니다. 비트코인 메인넷의 bc와 테스트넷 계열 접두부를 구분하고 여러 종류의 문자 오류를 탐지하도록 설계됐습니다. BIP 350은 witness v1 이상에서 Bech32m 체크섬을 사용하도록 규칙을 바꿨습니다.
따라서 bc1로 시작한다고 모두 같은 검증식을 쓰는 것은 아닙니다. bc1q의 witness v0과 bc1p의 Taproot 주소는 버전에 맞는 체크섬 상수를 사용해야 합니다. 구형 앱이 새 형식을 거부할 때 주소 문자를 수정해서 통과시키면 안 되고, 앱의 지원 버전을 확인하거나 수취인에게 지원되는 새 주소를 요청합니다.
- 붙여넣기 뒤 지갑의 형식 오류 경고를 확인한다.
- 주소의 처음과 끝뿐 아니라 전체 값 대조 수단을 사용한다.
- 선택한 네트워크와 주소 접두부를 함께 확인한다.
- 큰 금액은 신뢰한 별도 채널 또는 소액 시험으로 수취인을 확인한다.
EIP-55는 대소문자 패턴에 검증 정보를 넣는다
이더리움 주소의 기본 데이터는 20바이트를 40자리 16진수로 표현합니다. EIP-55는 소문자 주소의 Keccak 해시를 이용해 특정 알파벳 문자를 대문자로 표시합니다. 지갑은 이 패턴을 다시 계산해 혼합 대소문자 주소의 일부 오타를 찾을 수 있습니다.
모든 소문자 또는 모든 대문자 표현은 기존 호환성을 위해 사용될 수 있어 EIP-55 검증 정보가 없는 상태일 수 있습니다. 또한 EIP-55는 네트워크 ID를 기본 주소 문자열에 넣지 않습니다. 같은 0x 주소가 여러 EVM 네트워크에 존재할 수 있으므로 체인 선택은 별도로 확인해야 합니다.
주소 오염과 클립보드 변조는 유효한 체크섬을 사용한다
주소 오염 공격자는 피해자가 자주 쓰는 주소와 앞뒤가 비슷한 자신의 유효한 주소를 만들어 거래 이력에 노출할 수 있습니다. 사용자가 몇 글자만 보고 복사하면 체크섬 검사는 공격자 주소가 정상 형식이므로 통과합니다. 클립보드 악성 코드가 붙여넣는 주소도 공격자가 정상 생성한 값이면 마찬가지입니다.
해결책은 체크섬을 무시하는 것이 아니라 검증 층을 추가하는 것입니다. 연락처·주소록의 신뢰한 항목을 사용하고, 하드웨어 지갑 화면에서 전체 주소를 단계적으로 대조하며, 수취인에게 별도 채널로 확인합니다. 최근 거래 내역은 편리한 주소록으로 간주하지 않습니다.
경고가 없다는 사실보다 확인 절차를 기록한다
송금 앱이 주소를 허용했다는 것은 형식과 체크섬 검사를 통과했다는 제한된 신호입니다. 수취인의 청구서, 네트워크, 계약 또는 지갑 주소, 메모·태그 필요 여부를 별도로 확인합니다. 거래소 입금은 주소가 유효해도 memo가 빠지면 자동 반영되지 않을 수 있습니다.
업무 송금에서는 누가 주소를 제공했고 어떤 채널에서 재확인했는지 기록합니다. 주소 변경 요청이 들어오면 기존 대화만 믿지 말고 알려진 연락처로 확인합니다. 체크섬은 실수를 줄이는 훌륭한 도구지만, 최종 승인 판단은 수취인과 네트워크를 포함한 전체 맥락에서 내려야 합니다.
자주 묻는 질문
체크섬이 맞으면 안전한 주소인가요?
형식상 유효하다는 뜻일 뿐입니다. 공격자의 주소도 유효한 체크섬을 가지므로 수취인과 네트워크를 별도로 확인해야 합니다.
이더리움 주소를 소문자로 바꿔도 되나요?
원시 20바이트 값은 같을 수 있지만 EIP-55의 오류 검출 정보를 잃습니다. 지갑이 제공한 체크섬 표기를 보존하는 편이 좋습니다.
주소 한 글자가 틀리면 항상 탐지되나요?
체크섬 형식은 많은 오류를 탐지하지만 모든 가능한 변형에 대한 절대 보장은 아닙니다. 전체 주소 대조가 여전히 필요합니다.
