Tổng quan

Trước đó, một lỗ hổng chi tiêu gấp đôi trong hợp đồng xác minh bằng chứng không có kiến thức trên Semaphore đã được phát hiện bởi nhà phát triển người Nga, Poma. Vì tò mò, ý định ban đầu của tôi là sao chép PoC của lỗ hổng. Tuy nhiên, do mã lỗ hổng đã cũ và dự án tương đối phức tạp, tôi đã chọn tạo một PoC đơn giản để tái tạo lỗ hổng.

Giới thiệu

Nền tảng của công nghệ Zero Knowledge Proof (ZKP) nằm trong một thuật toán được gọi là “hệ thống bằng chứng”. Bằng cách thực hiện một loạt các tính toán trên tin nhắn, thuật toán tạo ra bằng chứng để chứng minh tính xác thực của tin nhắn. Người nhận có thể xác nhận tính xác thực của tin nhắn bằng cách chỉ xác minh bằng chứng mà không yêu cầu thêm thông tin.

Có nhiều sơ đồ triển khai khác nhau cho công nghệ ZKP mà chúng ta đã thảo luận trong bài viết trước “Tính năng kỹ thuật của các sơ đồ triển khai chính của ZKP”. Trong thử nghiệm này, nền tảng Circcom được sử dụng, sử dụng Groth16 và PlonK làm hệ thống bằng chứng. Trong quá trình phát triển, các nhà phát triển có thể chọn một trong hai hệ thống. Khung phát triển tự động tạo các tham số bằng chứng và hợp đồng xác minh mà không cần sửa đổi mạch.

Nói một cách đơn giản hơn, Circcom tạo dữ liệu nhân chứng và dữ liệu chứng thực ở phía khách hàng và gửi chúng vào hợp đồng. Hợp đồng verifier.sol xác minh dữ liệu đã gửi để xác nhận xem bằng chứng có tuân thủ các quy tắc đã chỉ định hay không. Cách tiếp cận này cho phép xác minh nhanh chóng, hiệu quả và an toàn đồng thời bảo vệ nội dung và quyền riêng tư của thư.

Phân tích lỗ hổng

1. Không có nhiều điều để thảo luận, vì vậy hãy chuyển thẳng sang phần mã có vấn đề. Vui lòng tham khảo chức năng “verifyHash” trong hình bên dưới. Mã được đặt trong hộp màu đỏ cho biết liệu dữ liệu nhân chứng cụ thể đã được sử dụng hay chưa. Phương pháp này thường được sử dụng để ngăn chặn chi tiêu gấp đôi. Tuy nhiên, lỗ hổng đã phát sinh trong dữ liệu nhân chứng “hash1”. Thông thường, một bộ dữ liệu bằng chứng cụ thể chỉ nên tương ứng với một bộ giá trị “hash1” cho mục đích xác minh.

2. Hàm “xác minh” trong hợp đồng “verifier.sol” thực hiện xác minh tính toán đường cong elip trên giá trị đầu vào thông qua hàm “scalar_mul()”. Hàm này tiến hành tính toán trên các đường cong elip sử dụng các tham số đầu vào và so khớp giá trị kết quả với giá trị được chỉ định trong bằng chứng được cung cấp. Do đó, chức năng xác nhận xem giá trị đầu vào có hợp lệ hay không.

3. Trong hợp đồng thông minh Solidity, việc mã hóa Fq bắt buộc phải sử dụng loại uint256. Tuy nhiên, vì giá trị tối đa của uint256 lớn hơn giá trị q, nên một số số nguyên riêng biệt có thể tương ứng với cùng một giá trị Fq sau phép toán modulo. Ví dụ: “s” và “s+q” chỉ cùng một điểm, cụ thể là điểm “sth”. Tương tự, “s+2q”, v.v. cũng là bí danh của điểm “s”. Hiện tượng này được gọi là "Bí danh đầu vào", theo đó các số nguyên này đóng vai trò là bút danh của nhau.

Giá trị “q” được đề cập ở đây liên quan đến thứ tự của nhóm tuần hoàn, biểu thị số lượng giá trị trong cùng một Fq có thể được nhập với nhiều số nguyên lớn. Về bản chất, ngay cả khi giá trị q được thêm vào hàm băm, nó vẫn có thể đáp ứng tiêu chí xác minh. Trong phạm vi của loại uint256, tối đa uint256_max/q số nguyên riêng biệt có thể biểu thị cùng một điểm. Điều này có nghĩa là một bộ bằng chứng có thể có tối đa 5 giá trị hash1 khớp và có thể vượt qua quá trình xác minh của hợp đồng.

Lỗ hổng tái phát

1. Phát triển một mạch cơ bản để nhập hai bộ dữ liệu và tạo dữ liệu nhân chứng, tức là "hash1", được sử dụng trong hợp đồng.

2. Biên dịch mạch để tạo “circuit_final.zkey”, “circuit.wasm” và “verifier.sol”. Sau đó, tạo một tập hợp các bằng chứng, hàm băm tiêu chuẩn và hàm băm bị hỏng.

3. Sau đó, triển khai hợp đồng và sử dụng “checkHash” được tạo trước đó để tiến hành quy trình xác minh. Quá trình xác minh thành công.

4. Tiếp theo, áp dụng dữ liệu nhân chứng giống hệt nhau và “attackHash” đã tạo trước đó. Phát hiện ra thì xác minh cũng thành công. Điều này chứng tỏ rằng một bộ bằng chứng có thể có một số giá trị băm phù hợp đáp ứng các tiêu chí xác minh của hợp đồng. Do đó, lỗ hổng bút danh đầu vào của hợp đồng xác minh Circo đã được sao chép một cách hiệu quả.

Giải pháp cho các lỗ hổng

Lỗ hổng phát sinh từ một bộ bằng chứng có thể có tối đa 5 giá trị băm phù hợp và đáp ứng các yêu cầu xác minh của hợp đồng. Do đó, cách sửa lỗi rất đơn giản: hạn chế tất cả các giá trị băm đầu vào ở một giá trị nhỏ hơn “q”.

Bản tóm tắt

Lỗ hổng bút danh đầu vào là một lỗ hổng thường xuyên gặp phải trong quá trình triển khai mật mã và bằng chứng không kiến thức. Nguyên nhân cơ bản của nó nằm ở chỗ giá trị tương đương với phần dư trong trường hữu hạn. Do đó, các nhà phát triển phải tập trung vào thứ tự của nhóm xác minh khi tạo mật mã.

Nhận tin tức mới nhất tại đây: Kênh Cointime — https://t.me/cointime_en