주소 오염 공격을 완화하기 위한 동적 대소문자 체크섬 탐구

요약

주소 변조 공격은 사람이 주소의 접두사/접미사 만 확인하는 방식을 악용합니다. 이 글에서는 지갑/UI만으로 작동하는 메커니즘을 제안합니다. 수신자는 수명이 짧은 수신자 코드를 공유하고, 발신자의 지갑은 Keccak256(address || code) 사용하여 동적 체크섬 대소문자 변환 지문을 생성합니다. 발신자가 실수로 변조된 유사 주소를 붙여넣으면 공격자는 코드를 알 수 없으므로 검증에 실패합니다.

동기: 흔한 습관 중독의 악용 사례

실제로 40개의 16진수 문자를 처음부터 끝까지 검증하는 사용자는 거의 없습니다. 특히 최근 활동에서 복사할 때 가장 일반적인 워크플로는 다음과 같습니다.

• 처음 4~6자를 확인하세요
• 마지막 4~6자를 확인하세요
• 중간이 괜찮다고 가정해 봅시다.

독극물 공격은 바로 이것을 직접적으로 겨냥합니다:

1. 공격자는 일반적으로 사용되는 수신자와 동일한 접두사/접미사를 가진 주소를 생성합니다.
2. 공격자는 0 값의/무의미한 전송을 보내 유사 항목이 "최근" 기록에 나타나도록 합니다.
3. 사용자가 잘못된 항목을 복사하여 접두사/접미사가 일치하면 자금이 공격자에게 전송됩니다.

이는 프로토콜 버그가 아니라 주로 UI/인간 검증 오류입니다.

직관적으로 생각해보면, 이더리움 전송에는 "두 번째 확인"이 없는 것 같다.

기존의 많은 결제 과정에서는 사실상 두 가지를 확인하게 됩니다.

• 목적지 식별자(계좌 번호)
• 독립적인 확인 신호(수취인 이름/확인 메시지)

이더리움은 강력한 수신자 식별자(주소)를 가지고 있지만, 사용자가 0x… 와 같은 임의의 수신자에게 전송할 때 두 번째 확인 절차가 누락되는 경우가 많습니다. 본 연구의 목표는 다음과 같은 경량화된 두 번째 확인 요소를 추가하는 것입니다.

• 오프체인(지갑 전용)
• 저렴함 (추가적인 온체인 단계 없음)
• 독살범이 특정 대가를 예상하기란 어렵다

배경: 체크섬 대소문자 구분이란 무엇이며, 왜 그것만으로는 불충분한가

지갑에는 대소문자가 혼합된 "체크섬" 주소가 표시되는 경우가 많습니다. 기본적인 개념은 다음과 같습니다.

• 주소로부터 해시 계산합니다.
• 해당 해시 의 비츠(Bits) 사용하여 a–f 16진수 문자 중 어떤 것이 대문자이고 어떤 것이 소문자인지 결정합니다.
• 주소가 변경되면 대소문자 패턴이 더 이상 유효하지 않을 가능성이 높으므로 오타를 잡아내는 데 도움이 됩니다.

이더리움에서 널리 사용되는 규칙은 이더리움 개선 제안(EIP)-55 체크섬 대소문자 표기법입니다.

악성 코드 변조의 한계: 이 대문자 표기는 주소별로 고정되어 있으며 공개적으로 계산 가능하므로, 변조된 유사 주소도 "유효한 체크섬이 있는" 형태로 표시될 수 있습니다.

제안: 체크섬 대소문자 구분을 수신자가 제공하는 코드(동적 지문)에 따라 결정하도록 합니다.

입력값

• addr : 수신자 주소 (20바이트)
• code : 숏 수신자 코드(문자열, 일회용 또는 단기 사용 권장)

해시

우리는 다음을 계산합니다:

여기서 addr_bytes 는 20바이트 주소이고 code_utf8 수신자 코드의 UTF-8 인코딩입니다. 20바이트 주소를 사용하면 연결 경계가 모호하지 않게 유지됩니다.

케이싱 규칙

주소를 16진수로 변환합니다(평소와 같이). 각 문자에 대해:

• 0–9 숫자는 변경되지 않았습니다.
• 문자 a–f 는 H 의 연속적인 비츠(Bits) 에 따라 대문자 또는 소문자로 변환됩니다.
  ( 이더리움 개선 제안(EIP)-55와 같은 취지이지만, 위의 H 사용함)

결과: 이제 동일한 기본 주소에 코드별 대소문자 구분 특징이 생겼습니다.

흐름

수신자(앨리스)

1. 앨리스는 수신자 코드를 생성합니다(지갑에서 생성한 코드를 사용하는 것이 좋습니다). 예: lamp-snow-47 .
2. 지갑은 H 에서 파생된 대소문자로 주소를 표시합니다.
3. 앨리스는 발신자에게 (주소, 우편번호) 를 알려줍니다.

보낸 사람 (밥)

1. 밥은 주소를 붙여넣습니다.
2. 밥은 수신기 코드를 입력합니다.
3. 지갑이 케이스 지문을 다시 계산하고 확인합니다.
   • 일치 → 확인됨
   • 불일치 → 경고/ 블록 (잘못된 코드, 잘못된 주소 또는 악성 코드 감염 가능성)

사용자가 케이스를 시각적으로 검사하는 대신, 검증됨/검증되지 않음이라는 명확한 상태에 의존하도록 하는 것이 목적입니다.

이것이 (목표 시나리오에서) 중독 위험을 완화하는 이유는 무엇일까요?

사용자가 실수로 검색 기록에서 유사한 접두사/접미사를 선택하면 악성 코드가 생성됩니다. 수신자 코드는 다음과 같습니다.

• 공격자는 여전히 유사한 주소를 만들어 사용자의 인터넷 사용 기록에 삽입할 수 있습니다.
• 하지만 공격자는 수신자의 코드에 따라 해당 악성 주소가 유효한 것으로 만들 수 없습니다.
• 따라서 "이력에서 잘못된 주소를 복사함"은 조용한 성공이 아니라 확정적인 검증 실패로 이어집니다.

여러분의 의견, 특히 사용자 경험(UX) 측면에서의 장단점이나 제가 간과했을지도 모르는 위협 모델 또는 구현상의 잠재적 문제점에 대한 생각을 기다리겠습니다. 피드백 주셔서 미리 감사드립니다!