Etherveil - 이더리움 개인정보 보호 브라우저

중요: 이 문서는 개발 중인 문서 이며 초기 단계의 아키텍처 제안입니다. 의도된 시스템 경계 및 설계 원칙을 정의하지만 최종 구현이나 보안 보장을 명시하지는 않습니다 . Etherveil 은 잠정적인 이름입니다. 이 게시물의 목적은 커뮤니티의 의견을 수렴하는 것이므로 여러분의 의견을 공유해 주세요 !

비전

Etherveil은 Tor Browser 의 패치 세트를 기반으로 구축된 Firefox / Gecko 기반 브라우저이며, Kohaku가 네이티브 지갑 엔진 으로 내장되어 있습니다. 핵심 전제는 간단합니다. 개인 정보 보호는 사용자가 설정하는 사항이 아니라 런타임의 속성이어야 한다는 것입니다 .

대부분의 개인정보 보호 도구는 사용자에게 부담을 줍니다. 예를 들어, 특정 확장 프로그램을 설치하고, 특정 VPN을 통해 연결하고, 쉴드 어드레스 사용해야 하는 이더리움 클래식(ETC) 여러 가지 설정이 필요합니다. 이더베일은 이러한 방식을 설계상의 결함으로 간주합니다. 브라우저는 네트워크(IP 및 트래픽 메타데이터), 실행(브라우저 지문), 온체인(주소, 거래 출처, 잔액)의 세 가지 계층에서 기본적으로 개인정보 보호를 시행합니다. 사용자는 브라우저를 열고 이더리움 지원 사이트로 이동하여 거래할 때, 할당된 익명성 등급 외에는 안정적이고 연결 가능한 식별 신호를 생성하지 않아야 하며, 기본 메커니즘을 이해할 필요도 없어야 합니다. 이더베일은 확률적 개인정보 보호 메커니즘을 모든 관찰 가능한 실행 표면에 걸쳐 결정론적 제약 조건 시행으로 대체합니다.

시스템 불변량

불변 조건: 모든 관찰 가능한 브라우저 API는 동일한 지문 프로필 클래스 내에서 사용자 간에 공유되는 유한한 동등 클래스 집합으로 해석되어야 합니다.

간단히 말해, 동일한 개인정보 보호 프로필을 사용하는 모든 사용자는 웹사이트 입장에서 똑같이 보입니다. 브라우저가 관찰 가능한 모든 행동을 소수의 표준화된 패턴으로 강제하기 때문입니다.

건축학

 ┌────────────────────────────────────────────────────┐│ Etherveil Browser Shell (Firefox/Tor Fork) │├───────────────────────────┬────────────────────────┤│ Execution & Fingerprint │ Kohaku Engine ││ Normalisation Layer │ (Wallet + Tx) ││ (Tor Browser Base) │ │├───────────────────────────┴────────────────────────┤│ Network Privacy & Verification Layer ││ Tor/Optional Mixnet, Helios Light Client ││ ERC-4337 Bundler Relay │└────────────────────────────────────────────────────┘ 

지문 정규화 레이어

Tor 브라우저는 이미 대부분의 까다로운 핑거프린팅 문제를 해결하고 있으며, 저희는 이를 확장하는 것이지 완전히 새로 만드는 것이 아닙니다. 주요 추가 사항은 '핑거프린트 프로필' 이라고 부르는 기능으로, 브라우저 관측값에 대한 고정된 사전 계산된 동등 클래스입니다. 이 프로필은 경험적 분포에서 파생된 상관 관계가 있는 브라우저 신호에 대한 제약 조건을 만족하는 튜플로 구성되며, 브라우징 컨텍스트별로 할당되고 세션 수명 동안 변경되지 않습니다. 이를 통해 필드 간 일관성(예: 시간대-지역-언어 일관성)을 보장하고 독립적인 속성 스푸핑을 방지합니다.

핵심 설계 결정은 사용자별 설정이나 런타임 무작위화를 사용하지 않는다는 것입니다. 무작위화는 오히려 역효과를 낳습니다. 페이지 로드 시 캔버스 노이즈 시드가 변경되면 그 전환이 사용자의 신원을 파악하는 데 악용될 수 있기 때문 입니다 . 대신, 각 프로필은 실제 분포에서 오프라인으로 생성된 일관된 스냅샷 이며, 런타임에 샘플링되는 것이 아니라 해당 프로필이 속한 익명성 집합의 크기를 최대화하도록 선택됩니다. 사이트가 할당된 프로필에서 오류를 발생시키면 전체 브라우징 컨텍스트가 호환 가능한 다른 클래스로 다시 시작됩니다. 세션 도중 변경은 발생하지 않습니다.

Gecko / SpiderMonkey 수준에서 정규화된 표면은 결정론적 API 가로채기 및 재작성을 통해 구현됩니다(콘텐츠 스크립트는 감지 가능하므로 제외).

• navigator.* : UA, 플랫폼, 하드웨어 동시성, 장치 메모리
• Intl / Date : 시간대, 지역, 언어 협상 헤더
• Canvas/WebGL: 프로필별 결정론적 출력; 벤더 및 렌더러 문자열이 클래스 분포에 맞춰 정렬됨
• screen.* , devicePixelRatio
• WebRTC : 인터컨티넨탈 거래소 후보가 억제되거나 표준화됨
• 높은 엔트로피를 갖는 API(오디오, 글꼴, 성능 타이밍): 프로파일 클래스 전체에 걸쳐 양자화됨

모든 고엔트로피 API는 양자화되거나, 통합되거나, 프로필 경계가 있는 동등 클래스로 매핑됩니다.

저장 및 상호 작용 격리

저장소( IndexedDB , localStorage , 쿠키, 캐시)는 출처 및 프로필별로 분할되어 프로필 간 데이터 유출이 없습니다. 저장소 외에도 스크롤 타이밍, 포인터 이동, 키 입력 속도와 같은 상호 작용 신호는 제한된 확률 모델 내에서 평활화 및 양자화됩니다. 목표는 생체 인식 재식별을 방지할 만큼 행동 엔트로피를 충분히 줄이면서도 브라우저 사용에 불편함이 없도록 하는 것입니다. 사용성과 엔트로피 간의 균형점은 시스템의 핵심적인 개방형 설계 매개변수입니다.

코하쿠 월렛 엔진

지갑은 확장 프로그램이 아니라 브라우저의 기본 하위 시스템 입니다. 브라우저는 디앱(DApp) 에 단일 거래 API를 제공하며, 특정 거래가 비공개로 실행되는지 공개적으로 실행되는지는 의도적으로 표시하지 않습니다. 이는 엔진 구현의 세부 사항일 뿐, 디앱(DApp) 알 필요가 없는 정보입니다.

 dApp -> Wallet API -> Kohaku Engine -> Privacy Relay -> Chain

모든 신규 계정은 기본적으로 pq-account 스마트 계정입니다. 사용자가 명시적으로 공개 흐름을 선택하지 않는 한 거래는 Tornado Cash(또는 더 일반적으로는 추상적인 zk 보호 계층)를 통해 처리됩니다. UserOperation 은 Tor 라우팅 이더리움 요청 사항(ERC)-4337 번들러를 통해 제출되므로 사용자의 IP 주소는 공개 메모리 풀의 거래와 연결되지 않습니다.

네트워크 개인 정보 보호 계층

네트워크 스택은 Tor 브라우저에서 상속받아 확장되었습니다.

• Tor(기본값): 출발지별 회로 격리; 모든 트래픽 및 DNS가 완전히 라우팅됨
• Mixnet(선택 사항): 지연 시간 증가를 감수하더라도 타이밍 상관관계 공격에 대한 메타데이터 저항력이 강화됩니다. 이 기능을 선택 사항으로 할지 기본값으로 설정할지는 추후 결정될 예정입니다.
• Helios 라이트 클라이언트: 동기화 위원회 증명을 통한 로컬 이더리움 상태 검증으로 중앙 집중식 RPC 제공업체에 대한 의존성을 제거합니다. 이더리움 네임서비스(ENS) 해상도는 Helios만을 통해 처리됩니다.
• 트래픽 셰이핑: 타이밍 상관관계를 줄이기 위한 확정적 지연 시간 패딩 및 요청 일괄 처리

위협 모델

브라우저는 다음과 같은 공격으로부터 보호하도록 설계되었습니다.

• ISP 및 종료 노드 트래픽 분석
• 캔버스, WebGL 및 기타 고엔트로피 API를 통한 사이트 간 지문 인식
• RPC 엔드포인트 감시 (Infura/Alchemy 이더리움 클래식(ETC) 대한 주소 질의)
• 온체인 주소 클러스터링 및 거래 그래프 분석
• 행동 생체 인식 재식별(제한적 완화)

이 솔루션은 네트워크에 대한 완전한 가시성을 가진 전 세계적인 수동적 공격자, 운영 체제 또는 하드웨어 수준의 사이드 채널, 또는 사용자 운영 보안 실패로 인한 공격을 완전히 해결하지 못하며, 해결한다고 주장하지도 않습니다.

비목표

디자인의 일관성을 유지하기 위해 명시적으로 제외된 몇 가지 사항은 다음과 같습니다.

• 확장 기능 호환성: 웹 확장 API는 지문 모델을 약화시킬 수 있는 신원 확인 표면을 다시 도입합니다.
• 사용자 제어 지문 조정: 익명성 보장은 개별 맞춤 설정이 아니라 사용자들이 서로 구별되지 않는다는 점에 달려 있습니다.
• 선택적 동의 또는 "최선의 노력" 개인정보 보호 모드: 이 모델은 일관되게 시행될 때만 효과가 있습니다.
• 디앱(DApp) 에 실행 모드(비공개 vs 공개) 노출

설계 연기 관련 질문

실행에 앞서 결정해야 할 몇 가지 사항이 있지만, 아직 명확한 정답이 없는 것들입니다.

• 프로필 Persistence: 동일한 프로필을 세션 간에 특정 오리진에 할당해야 할까요, 아니면 세션별로 순환시켜야 할까요? 오리진별 일관성은 사용 편의성에 유리하고, 순환은 연결 해제 가능성에 유리합니다.
• Mixnet 기본 설정: Tor만 기본으로 하고 Mixnet은 선택 사항으로 제공하는 방식, 아니면 기본적으로 활성화하고 지연 시간에 민감한 상황에서만 Mixnet을 사용할 수 있도록 하는 방식?
• 상호작용 강화: 행동적 엔트로피 억제와 사용성 사이의 허용 가능한 균형점은 어디에 있는가?
• 웹 호환성: 일부 사이트는 엄격한 지문 분류 체계에서 제대로 작동하지 않을 수 있습니다. 호환되는 고빈도 프로필 분류 체계 중 어느 것도 사이트를 올바르게 렌더링하지 못할 경우, 문제 해결을 위한 상위 조치는 무엇입니까?