Bạn nghĩ rằng việc triển khai nonces là đơn giản? Nghĩ lại đi. Dù bạn đang xây dựng các giao thức onchain hay cơ sở hạ tầng offchain, việc triển khai nonce đúng cách là một trong những phần khó khăn nhất của bảo mật mật mã. Hãy cùng tìm hiểu tại sao việc bảo vệ chống phát lại lại khó hơn những gì bạn nghĩ 👇

2/ Đầu tiên, hãy hiểu về chữ ký số. Trong mã hóa khóa công khai (như BLS), bạn có một khóa riêng để ký các tin nhắn và một khóa công khai để xác minh chúng. Trong Ethereum: địa chỉ = băm khóa công khai tin nhắn = băm giao dịch chữ ký = 64 byte bằng chứng mật mã

3/ Vấn đề là: toán học trong hầu hết các giao thức crypto khóa công khai không giới hạn số lần một chữ ký có thể được xác minh với cùng một thông điệp. Khi bạn có một chữ ký hợp lệ, bạn có thể phát lại nó vô hạn. Điều này mở ra cánh cửa cho các cuộc tấn công phát lại.

4/ Nhập nonce: một "số chỉ sử dụng một lần" giúp ngăn chặn các cuộc tấn công phát lại. Khi một người tiêu dùng nhận được một tin nhắn có nonce, họ sẽ kiểm tra xem nonce đó đã được sử dụng trước đó chưa. Nếu có → từ chối. Các giao dịch Ethereum sử dụng mẫu này.

5/ Nhưng việc triển khai nonce thì phức tạp một cách đáng ngạc nhiên. Các yêu cầu chính: - Nonces phải KHÔNG BAO GIỜ được sử dụng lại (trên chuỗi này hoặc các chuỗi khác) - Phải ngăn chặn các cuộc tấn công replay một cách vĩnh viễn - Cần có cơ chế để xử lý sự gia tăng lưu trữ - Phải chống lại các cuộc tấn công front-running

6/ Giải pháp ngây thơ: lưu trữ tất cả các nonce trong cơ sở dữ liệu mãi mãi. Điều này có hai vấn đề lớn: a) Tăng trưởng lưu trữ không giới hạn (đặc biệt là với các cuộc tấn công spam) b) Dễ bị tấn công front-running Vấn đề (a) dễ giải quyết hơn (b). Hãy giải quyết vấn đề lưu trữ trước...

7/ Nonces dựa trên dấu thời gian giải quyết vấn đề tăng trưởng lưu trữ! Sử dụng dấu thời gian + thời gian hết hạn. Nonces cũ hơn 5 phút sẽ bị xóa khỏi cơ sở dữ liệu. Nhưng còn những tin nhắn đồng thời từ cùng một tài khoản thì sao? Chúng chia sẻ một dấu thời gian. Giải pháp: dấu thời gian + random_bytes để có tính duy nhất chi tiết.

8/ Front-running là phần khó khăn. Các tác nhân độc hại có thể chặn các chữ ký hợp lệ, thực hiện front-run chúng để đánh dấu các nonce là đã sử dụng, sau đó cuộc gọi của người dùng hợp pháp bị từ chối. Điều này gây ra vấn đề trên chuỗi với các thao tác gộp nếu một chữ ký xấu từ chối toàn bộ gói. Đối với ngoài chuỗi: hãy sử dụng mã hóa TLS! Đừng để bất kỳ tác nhân độc hại nào thấy nonce hoặc chữ ký.

9/ Đừng quên sự kiên trì! Nếu bộ nhớ cache nonce của bạn chỉ nằm trong bộ nhớ, kẻ tấn công có thể phát lại các nonce cũ sau khi hệ thống khởi động lại. Luôn luôn lưu trữ trạng thái nonce vào bộ nhớ bền và tải lại khi khởi động. Bộ nhớ chỉ = cửa sổ dễ bị tấn công phát lại.

10/ Số nonce duy nhất cho mỗi người tiêu dùng! Khi phát sóng đến nhiều người dùng, mỗi người nên nhận được một thông điệp/chữ ký khác nhau. Nếu không, bạn sẽ dễ bị tấn công Man-in-the-Middle, nơi một người nhận chuyển tiếp thông điệp, giả mạo người gửi gốc.

11/ Nonce gia tăng (như Ethereum, nonce = nonce trước đó + 1) có vị trí của nó, nhưng hãy cẩn thận! Chúng tạo ra những thách thức lớn cho hạ tầng offchain: tin nhắn không theo thứ tự, vấn đề đồng bộ, và các kịch bản phục hồi phức tạp. Chỉ sử dụng nếu bạn tự tin rằng các tin nhắn sẽ (hoặc phải) đến theo thứ tự.

Tóm tắt - Danh sách kiểm tra triển khai Nonce: ✅ Sử dụng nonces để ngăn chặn các cuộc tấn công phát lại ✅ Lưu trữ trạng thái nonce qua các lần khởi động lại ✅ Triển khai cơ chế hết hạn (dấu thời gian + dọn dẹp) ✅ Làm cho nonces trở nên duy nhất cho mỗi người nhận ✅ Bảo vệ chống lại việc chạy trước với các kênh mã hóa ✅ Tránh nonces gia tăng trừ khi thứ tự được đảm bảo An ninh nằm trong chi tiết! 🛡️