Khám phá các mã kiểm tra viết hoa/viết thường động để giảm thiểu hiện tượng đầu độc địa chỉ

Tóm lại

Tấn công giả mạo địa chỉ hoạt động vì con người chỉ xác minh phần tiền tố/hậu tố của địa chỉ. Bài viết này đề xuất một cơ chế chỉ dành cho ví/giao diện người dùng: người nhận chia sẻ một mã người nhận có thời hạn ngắn, và ví của người gửi sử dụng Keccak256(address || code) để tạo ra dấu vân tay phân biệt chữ hoa chữ thường của mã kiểm tra động . Nếu người gửi vô tình dán một địa chỉ giả mạo trông giống hệt địa chỉ thật, quá trình xác minh sẽ thất bại vì kẻ tấn công không biết mã đó.

Động lực: những hành vi đầu độc thói quen phổ biến

Trên thực tế, rất ít người dùng kiểm tra toàn bộ 40 ký tự thập lục phân. Quy trình làm việc phổ biến nhất—đặc biệt là khi sao chép từ hoạt động gần đây—là:

• Kiểm tra 4-6 ký tự đầu tiên.
• Kiểm tra 4-6 ký tự cuối cùng.
• giả sử phần giữa ổn

Các cuộc tấn công bằng chất độc nhắm trực tiếp vào điều này:

1. Kẻ tấn công tạo ra một địa chỉ có tiền tố/hậu tố giống với địa chỉ người nhận thường dùng.
2. Kẻ tấn công gửi một giao dịch có giá trị 0/không đáng kể để giao dịch tương tự xuất hiện trong lịch sử "gần đây".
3. Người dùng sao chép nhầm mục nhập, tiền tố/hậu tố trùng khớp, tiền được chuyển cho kẻ tấn công.

Đây chủ yếu là lỗi giao diện người dùng/xác minh của người dùng, chứ không phải lỗi giao thức.

Trực giác: Giao dịch Ethereum thiếu "xác nhận lần thứ hai".

Trong nhiều quy trình thanh toán truyền thống, bạn thực chất xác nhận hai điều:

• Mã định danh điểm đến (số tài khoản)
• một tín hiệu xác nhận độc lập (tên người nhận tiền / lời nhắc xác nhận)

Ethereum có một định danh đích đến mạnh mẽ (địa chỉ), nhưng thường thiếu bước xác nhận thứ hai khi người dùng chuyển tiền đến người nhận có địa chỉ 0x… thô. Mục tiêu ở đây là thêm một yếu tố xác thực thứ hai đơn giản, đó là:

• Ngoài chuỗi (chỉ dành cho ví)
• giá rẻ (không có thêm bước nào on-chain )
• Thật khó để kẻ đầu độc có thể đoán trước được khoản thanh toán cụ thể.

Bối cảnh: Mã kiểm tra (checksum) viết hoa là gì và tại sao nó không đủ.

Ví điện tử thường hiển thị địa chỉ đã được "kiểm tra tổng" với cả chữ hoa và chữ thường. Ý tưởng chung là:

• Tính toán Hash từ địa chỉ
• Sử dụng Bits của Hash đó để quyết định chữ cái thập lục phân a–f nào là chữ hoa/chữ thường.
• Nếu địa chỉ thay đổi, kiểu chữ hoa/chữ thường có thể không còn hợp lệ, giúp phát hiện lỗi chính tả.

Quy ước Ethereum được sử dụng rộng rãi ở đây là kiểu viết hoa mã kiểm tra Đề xuất cải tiến Ethereum (EIP)-55 .

Hạn chế của việc làm giả mạo: kiểu dữ liệu này là cố định cho mỗi địa chỉ và có thể tính toán công khai, do đó một địa chỉ giả mạo có vẻ ngoài độc hại cũng có thể được hiển thị dưới dạng "đã kiểm tra tổng hợp hợp lệ".

Đề xuất: làm cho việc phân biệt chữ hoa chữ thường của mã kiểm tra phụ thuộc vào mã do bên nhận cung cấp (dấu vân tay động)

Đầu vào

• addr : địa chỉ người nhận (20 byte)
• code : mã nhận Short (chuỗi ký tự; khuyến nghị sử dụng một lần hoặc trong thời gian ngắn)

Hash

Chúng tôi tính toán:

trong đó addr_bytes là địa chỉ 20 byte và code_utf8 là mã hóa UTF-8 của mã nhận. Việc sử dụng địa chỉ 20 byte giúp cho ranh giới nối chuỗi được rõ ràng.

Quy tắc viết hoa

Hiển thị địa chỉ dưới dạng thập lục phân (như thường lệ). Đối với mỗi ký tự:

• các chữ số 0–9 không thay đổi
• Các chữ cái a–f được viết hoa/viết thường theo thứ tự Bits của H
  (Cùng tinh thần với Đề xuất cải tiến Ethereum (EIP)-55, nhưng sử dụng H ở trên)

Kết quả: cùng một địa chỉ cơ bản giờ đây có dấu vân tay viết hoa/viết thường riêng biệt theo mã .

Chảy

Người nhận (Alice)

1. Alice tạo ra một mã nhận (khuyến nghị sử dụng mã do ví tạo), ví dụ: lamp-snow-47 .
2. Ví hiển thị địa chỉ với kiểu chữ viết hoa được tạo từ H
3. Alice chia sẻ (địa chỉ, mã số) với người gửi.

Người gửi (Bob)

1. Bob dán địa chỉ.
2. Bob nhập mã số người nhận.
3. Ví điện tử tính toán lại và xác minh dấu vân tay của vỏ thiết bị:
   • phù hợp → đã xác minh
   • Không khớp → cảnh báo/ Block (mã sai, địa chỉ sai hoặc có thể bị nhiễm mã độc)

Mục đích là để người dùng dựa vào trạng thái đã được xác minh/chưa được xác minh rõ ràng thay vì kiểm tra vỏ máy bằng mắt thường.

Vì sao điều này giúp giảm thiểu nguy cơ nhiễm độc (trong kịch bản mục tiêu)

Tấn công chiếm quyền điều khiển trang web thành công khi người dùng vô tình chọn một tiền tố/hậu tố giống hệt từ lịch sử. Với mã nhận:

• Kẻ tấn công vẫn có thể tạo ra các địa chỉ giả mạo và đưa chúng vào lịch sử duyệt web của người dùng.
• nhưng kẻ tấn công không thể khiến địa chỉ bị nhiễm độc đó hợp lệ theo mã của người nhận.
• Vì vậy, lỗi "sao chép sai địa chỉ từ lịch sử" trở thành một lỗi xác thực có tính chất xác định thay vì một thành công thầm lặng.

Tôi rất mong nhận được ý kiến ​​đóng góp của bạn—đặc biệt là về những đánh đổi trong trải nghiệm người dùng và bất kỳ cạm bẫy tiềm ẩn nào trong mô hình mối đe dọa hoặc quá trình triển khai mà tôi có thể đã bỏ qua. Cảm ơn trước những phản hồi của bạn!