Etherveil - Trình duyệt bảo mật Ethereum

Quan trọng: Tài liệu này vẫn đang trong quá trình hoàn thiện và thể hiện đề xuất kiến ​​trúc ở giai đoạn đầu. Nó xác định các giới hạn hệ thống và nguyên tắc thiết kế dự kiến, nhưng không nêu rõ các triển khai cuối cùng hoặc đảm bảo an ninh. Xin lưu ý rằng Etherveil là tên tạm thời. Mục đích của bài đăng này là để thu thập phản hồi từ cộng đồng, vì vậy hãy chia sẻ ý kiến ​​của bạn !

Tầm nhìn

Etherveil là một trình duyệt dựa trên Firefox / Gecko được xây dựng trên bộ bản vá của Tor Browser , với Kohaku được nhúng như một công cụ ví điện tử gốc . Nguyên tắc cốt lõi rất đơn giản: quyền riêng tư nên là thuộc tính của hệ điều hành, chứ không phải là thứ người dùng cấu hình .

Hầu hết các công cụ bảo mật đều đặt gánh nặng lên người dùng, ví dụ: cài đặt tiện ích mở rộng này, định tuyến qua VPN này, nhớ sử dụng Địa chỉ được che giấu của bạn, ETC Etherveil coi đó là một lỗi thiết kế. Trình duyệt thực thi quyền riêng tư theo mặc định trên ba lớp: mạng (địa chỉ IP và siêu dữ liệu lưu lượng), thực thi (các bề mặt dấu vân tay của trình duyệt) và on-chain (địa chỉ, nguồn gốc giao dịch, số dư). Người dùng có thể mở trình duyệt, điều hướng đến một trang web hỗ trợ Ethereum và thực hiện giao dịch mà không tạo ra các tín hiệu ổn định, có thể liên kết và phân biệt được ngoài lớp ẩn danh được chỉ định của họ (và không yêu cầu người dùng phải hiểu các cơ chế cơ bản). Etherveil thay thế các cơ chế bảo mật xác suất bằng việc thực thi ràng buộc xác định trên tất cả các bề mặt thực thi có thể quan sát được.

Bất biến hệ thống

Bất biến: tất cả các API trình duyệt có thể quan sát được phải được quy về một tập hợp hữu hạn các lớp tương đương được chia sẻ giữa những người dùng trong cùng một lớp Hồ sơ Dấu vân tay .

Nói một cách đơn giản: Tất cả mọi người sử dụng cùng một cấu hình quyền riêng tư đều trông giống hệt nhau đối với các trang web, bởi vì trình duyệt buộc tất cả các hành vi có thể quan sát được phải tuân theo một số ít các khuôn mẫu tiêu chuẩn.

Ngành kiến ​​​​trúc

 ┌────────────────────────────────────────────────────┐│ 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 │└────────────────────────────────────────────────────┘ 

Lớp chuẩn hóa dấu vân tay

Trình duyệt Tor đã giải quyết hầu hết các vấn đề khó khăn trong việc nhận dạng dấu vân tay trình duyệt; chúng tôi đang mở rộng nó chứ không phải tạo ra một cái mới hoàn toàn. Điểm bổ sung chính là cái mà chúng tôi gọi là Hồ sơ Dấu vân tay : một lớp tương đương cố định, được tính toán trước trên các thuộc tính quan sát được của trình duyệt, được xây dựng như một bộ dữ liệu thỏa mãn ràng buộc trên các tín hiệu trình duyệt tương quan được suy ra từ các phân phối thực nghiệm, được gán cho mỗi ngữ cảnh duyệt web và không thay đổi trong suốt thời gian tồn tại của một phiên. Điều này đảm bảo tính nhất quán giữa các trường (ví dụ: tính nhất quán giữa múi giờ-vùng miền-ngôn ngữ) và ngăn chặn việc giả mạo thuộc tính độc lập.

Quyết định thiết kế quan trọng là đây không phải là cấu hình cho từng người dùng hoặc ngẫu nhiên hóa trong thời gian chạy. Việc ngẫu nhiên hóa thực chất lại phản tác dụng: nếu hạt giống nhiễu canvas của bạn thay đổi giữa các lần tải trang, sự chuyển đổi đó sẽ là dấu vân tay. Thay vào đó, mỗi cấu hình là một Snapshot nhanh nhất quán được tạo ra ngoại tuyến từ các phân bố thực tế, nhưng không được lấy mẫu trong thời gian chạy, được chọn để tối đa hóa kích thước của tập hợp ẩn danh mà nó thuộc về. Nếu một trang web bị lỗi dưới một cấu hình được chỉ định, toàn bộ ngữ cảnh duyệt web sẽ khởi động lại dưới một lớp tương thích khác. Không có sự thay đổi nào giữa phiên.

Các bề mặt được chuẩn hóa ở cấp độ Gecko / SpiderMonkey thông qua việc chặn và ghi lại API có tính xác định (không phải các tập lệnh nội dung, vì chúng có thể bị phát hiện):

• navigator.* : UA, nền tảng, khả năng xử lý đồng thời phần cứng, bộ nhớ thiết bị
• Intl / Date : tiêu đề đàm phán múi giờ, vùng miền, ngôn ngữ
• Canvas/WebGL: đầu ra xác định cho từng cấu hình; chuỗi nhà cung cấp và trình kết xuất được căn chỉnh theo phân phối lớp.
• screen.* , devicePixelRatio
• WebRTC : Các ứng viên Intercontinental Exchange (ICE) bị loại bỏ hoặc tiêu chuẩn hóa
• API có độ nhiễu cao (âm thanh, phông chữ, thời gian thực hiện): được lượng tử hóa trên toàn bộ lớp cấu hình

Tất cả các API có độ nhiễu cao đều được lượng tử hóa, hợp nhất hoặc ánh xạ vào các lớp tương đương giới hạn bởi cấu hình.

Cách ly lưu trữ và tương tác

Bộ nhớ ( IndexedDB , localStorage , cookie, cache) được phân vùng theo nguồn gốc và hồ sơ người dùng mà không có sự rò rỉ dữ liệu giữa các hồ sơ. Ngoài bộ nhớ, các tín hiệu tương tác - thời gian cuộn trang, chuyển động con trỏ, nhịp điệu gõ phím - được làm mịn và lượng tử hóa trong các mô hình ngẫu nhiên có giới hạn. Mục tiêu là giảm thiểu sự hỗn loạn hành vi đủ để đánh bại việc nhận dạng lại bằng sinh trắc học mà không làm cho trình duyệt trở nên khó sử dụng. Ranh giới giữa khả năng sử dụng và sự hỗn loạn là một tham số thiết kế mở cốt lõi của hệ thống.

Công cụ ví Kohaku

Ví điện tử là một hệ thống con gốc của trình duyệt , chứ không phải là một tiện ích mở rộng. Trình duyệt chỉ cung cấp một API giao dịch duy nhất cho Các ứng dụng phi tập trung (DAPPS) và cố tình không hiển thị liệu một giao dịch cụ thể đang được thực hiện riêng tư hay công khai. Sự khác biệt đó là chi tiết triển khai của công cụ, chứ không phải là điều mà Các ứng dụng phi tập trung (DAPPS) cần biết.

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

Tất cả các tài khoản mới mặc định đều là tài khoản thông minh pq-account . Các giao dịch được định tuyến qua Tornado Cash (hoặc nói chung hơn, một lớp bảo vệ zk trừu tượng) trừ khi người dùng chọn tham gia vào luồng công khai một cách rõ ràng. Các UserOperation được gửi qua các bộ gom nhóm Yêu cầu bình luận Ethereum (ERC)-4337 được định tuyến qua Tor, do đó địa chỉ IP của người dùng không bao giờ được liên kết với giao dịch trong mempool công khai.

Lớp bảo mật mạng

Ngăn xếp mạng được kế thừa từ Tor Browser và được mở rộng:

• Tor (mặc định): cách ly mạch theo nguồn gốc; tất cả lưu lượng truy cập và DNS được định tuyến hoàn toàn.
• Mixnet (tùy chọn): khả năng chống lại các cuộc tấn công tương quan thời gian bằng siêu dữ liệu mạnh mẽ hơn, nhưng đổi lại là độ trễ; việc nên chọn bật hay mặc định tính năng này sẽ được xem xét sau.
• Ứng dụng khách Helios light: xác minh trạng thái Ethereum cục bộ thông qua bằng chứng của ủy ban đồng bộ hóa, loại bỏ sự phụ thuộc vào các nhà cung cấp RPC tập trung; quá trình phân giải ENS chỉ diễn ra thông qua Helios.
• Điều chỉnh lưu lượng: đệm độ trễ xác định và nhóm yêu cầu để giảm tương quan thời gian.

Mô hình mối đe dọa

Trình duyệt được thiết kế để chống lại:

• Phân tích lưu lượng truy cập ISP và nút thoát
• Nhận dạng dấu vân tay đa trang web thông qua canvas, WebGL và các API có độ nhiễu cao khác.
• Giám sát điểm cuối RPC (truy vấn địa chỉ tới Infura/Alchemy, ETC)
• Phân cụm địa chỉ on-chain và phân tích đồ thị giao dịch
• Nhận dạng lại sinh trắc học hành vi (giảm thiểu có giới hạn)

Nó không giải quyết triệt để (và không tuyên bố giải quyết triệt để) các cuộc tấn công từ các đối thủ thụ động toàn cầu với khả năng giám sát mạng hoàn chỉnh, các kênh phụ ở cấp độ hệ điều hành hoặc phần cứng, hoặc các lỗi bảo mật vận hành của người dùng.

Những mục tiêu không chính thức

Một vài nội dung nằm ngoài phạm vi thiết kế để đảm bảo tính nhất quán:

• Khả năng tương thích mở rộng: API WebExtension tái tạo lại bề mặt nhận dạng có thể làm suy yếu mô hình dấu vân tay.
• Tùy chỉnh dấu vân tay do người dùng kiểm soát: sự đảm bảo tính ẩn danh phụ thuộc vào việc người dùng không thể phân biệt được với nhau, chứ không phải vào việc tùy chỉnh riêng lẻ.
• Chế độ bảo mật tự nguyện hoặc "nỗ lực tối đa": mô hình này chỉ hoạt động hiệu quả nếu được thực thi một cách đồng nhất.
• Hiển thị chế độ thực thi (riêng tư so với công khai) cho Các ứng dụng phi tập trung (DAPPS)

Câu hỏi thiết kế trì hoãn

Một vài quyết định cần được đưa ra trước khi triển khai nhưng hiện chưa có câu trả lời đúng rõ ràng:

• Persistence quán hồ sơ: Liệu cùng một hồ sơ có nên được gán cho một nguồn gốc nhất định trong suốt các phiên hay nên được xoay vòng theo từng phiên? Tính nhất quán theo từng nguồn gốc tốt hơn cho khả năng sử dụng; việc xoay vòng giúp giảm thiểu nguy cơ mất liên kết.
• Cài đặt mặc định Mixnet: Chỉ sử dụng Tor làm cơ sở ban đầu với Mixnet là tùy chọn, hay bật mặc định với một tùy chọn dự phòng cho các trường hợp nhạy cảm về độ trễ?
• Sự cứng nhắc trong tương tác: Đâu là sự đánh đổi chấp nhận được giữa việc giảm thiểu sự hỗn loạn hành vi và tính khả dụng?
• Khả năng tương thích web: một số trang web sẽ gặp lỗi khi sử dụng các lớp nhận dạng vân tay nghiêm ngặt. Vậy giải pháp là gì khi không có lớp nhận dạng vân tay có số lượng người dùng cao nào tương thích và hiển thị trang web chính xác?