Tác giả: BitMEX Research
Nguồn: BitMEX
Tóm tắt : Các giao dịch Bitcoin 64 byte có thể bị nhầm lẫn với các đối tượng băm của Merkle trees của một khối, vì cây Merkle cũng dài 64 byte. Chúng tôi đã điều tra cách lỗ hổng này có thể được sử dụng để đánh lừa máy trạm Xác minh Thanh toán Đơn giản (SPV) cho rằng họ đã nhận được một giao dịch trong khi thực tế là không, và các vấn đề khác mà điểm yếu này có thể gây ra. Mặc dù việc thực hiện một cuộc tấn công như vậy rất phức tạp và lỗ hổng này không nghiêm trọng, nhưng có một cách khắc phục tương đối đơn giản: trong một soft fork, hãy vô hiệu hóa tất cả các giao dịch 64 byte sau khi loại bỏ dữ liệu chứng thực.
Tổng quan
Bài viết này là một phần trong sê-ri thảo luận về bốn lỗ hổng bảo mật mà bản cập nhật soft fork dọn dẹp cơ chế đồng thuận BIP 54 sẽ khắc phục. Chúng ta đã đề cập đến hai trong số lỗ hổng bảo mật trong đó :
- Cuộc tấn công xuyên thời gian ( Bản dịch tiếng Trung )
- Giao dịch chồng chéo ( Bản dịch tiếng Trung )
Trong bài viết này, chúng ta sẽ tập trung vào vấn đề được gọi là "giao dịch 64 byte". Điểm trong đó là đối tượng băm của nút trung gian trong Merkle trees được sử dụng để tạo ra khối Bitcoin cũng dài 64 byte.
Mã băm của một giao dịch Bitcoin , hay "TXID," dài 32 byte. Dòng áp chót của Merkle trees trong khối Bitcoin là sự kết hợp của hai mã băm TXID—tổng cộng 64 byte. Lỗ hổng bảo mật nằm ở chỗ dữ liệu 64 byte này (sự kết hợp của hai mã băm) có thể bị nhầm lẫn với một giao dịch 64 byte. Ví dụ, kẻ tấn công có thể tạo ra một giao dịch Bitcoin dài chính xác 64 byte để đánh lừa hoặc lừa một light node) xác nhận khoản thanh toán đến. Chúng ta sẽ tìm hiểu một số bước liên quan đến cuộc tấn công này ở phần dưới đây.
Sơ đồ Merkle trees trong Bitcoin .
Bản đồ của Sergio Lerner : Vị trí giao dịch giả tạo
Nhìn chung, chúng tôi cho rằng rủi ro liên quan đến lỗ hổng này ở mức trung bình đến thấp do độ phức tạp của cuộc tấn công; điều này trái ngược với "cuộc tấn công bẻ cong thời gian", mà chúng tôi cho rằng nghiêm trọng hơn. Tuy nhiên, đây vẫn là một lỗ hổng đáng quan tâm và cần được khắc phục.
Ẩn ID của một giao dịch bên trong một giao dịch khác.
Cuộc tấn công nghiêm trọng nhất được biết đến khai thác lỗ hổng này liên quan đến việc lừa người dùng sử dụng ứng dụng Xác minh Thanh toán Đơn giản (SPV) xác nhận một giao dịch đến không hợp lệ. Chúng tôi đã cung cấp sơ đồ bên dưới tóm tắt cuộc tấn công này. Các bước tấn công như sau:
- Kẻ tấn công đã tạo ra một giao dịch Bitcoin hợp lệ, có độ dài chính xác là 64 byte. Con số này không bao gồm bất kỳ dữ liệu chứng thực riêng biệt nào.
- Kẻ tấn công sau đó tạo ra một giao dịch Bitcoin giả mạo, không hợp lệ, gửi (ví dụ) 1000 BTC cho nạn nhân. Ví dụ, 1000.002 BTC trong giao dịch này đến từ một dữ liệu đầu vào giả mạo không tồn tại trong tập hợp UTXO.
- Kẻ tấn công gán một địa chỉ thay đổi cho giao dịch giả tạo này, sau đó sử dụng phương pháp tìm kiếm vét cạn, liên tục thay đổi địa chỉ thay đổi, cho đến khi TXID (dài 32 byte) của giao dịch giả tạo hoàn toàn giống với 32 byte cuối cùng của giao dịch hợp lệ thực sự (dài 64 byte).
- Một khi cặp giao dịch như vậy được xác định, kẻ tấn công có thể gửi bằng chứng SPV đến máy trạm nhẹ của nạn nhân, trong đó một đường dẫn hợp lệ từ gốc Merkle trees của Block Header chính xác đến giao dịch giả tạo. Nạn nhân sẽ nhầm tưởng rằng lớp dưới cùng của Merkle trees là lớp áp chót, với một giao dịch khác bên dưới nó. Sau đó, nạn nhân sẽ cho rằng họ đã nhận được 1000 BTC — Bằng chứng công việc từ thợ đào mà kẻ tấn công đang sử dụng để lừa dối nạn nhân. Tất nhiên, nút đầy đủ sẽ không bị đánh lừa theo cách này (trong đó nhiều lý do), nhưng nút SPV thì có.
Hai giao dịch được sử dụng trong cuộc tấn công được minh họa.
- Lưu ý: Cuộc tấn công này đã được giải thích trong bài viết của Peter Todd đăng ngày 7 tháng 6 năm 2018 và bài viết của Sergio Lerner đăng ngày 9 tháng 6 năm 2018 .
Cuộc tấn công được mô tả ở trên dường như không khả thi về mặt tính toán vì nó dường như yêu cầu tìm ra trường hợp xung đột SHA256 hoàn chỉnh gồm 32 byte. Chúng ta đã biết điều này là không khả thi về mặt tính toán, và rõ ràng là dễ dàng hơn để đánh lừa máy máy trạm SPV bằng cách khai thác một khối giả (điều này sẽ yêu cầu 2^ lần lượt tìm kiếm hiện nay) hơn là tìm ra xung đột băm với 2^256 lần. Tuy nhiên, điểm mấu chốt ở đây là các giao dịch 64 byte có thể điều chỉnh được, vì vậy bạn không cần phải khớp 32 byte bằng phương pháp vét cạn thuần túy.
32 byte cuối cùng của một giao dịch 64 byte
| sự vật | mô tả | chiều dài | Độ dài cần thiết cho tìm kiếm vét cạn |
|---|---|---|---|
| Nhập TXID | Mã băm của một giao dịch Bitcoin trước đó. Do đó, nó là ngẫu nhiên và không thể bị thao túng. Cần phải sử dụng phương pháp tìm kiếm vét cạn. | 5 byte (ở nửa sau của trường này) | 5 byte |
| Chỉ mục đầu vào | Một cách tiếp cận là tạo ra một giao dịch khởi đầu (như một giao dịch trước đó) với hàng nghìn đầu ra. Điều này cho phép thao tác các chỉ số đầu vào để xung đột với (ở một mức độ nào đó) giao dịch giả tạo. Tuy nhiên, điều này có thể tốn kém và khó thực hiện. Trên thực tế, một số phương pháp tìm kiếm vét cạn cũng có thể cần thiết ở đây. | 4 byte | 0 |
| Độ dài đầu vào | Việc thao túng rất khó khăn vì có những ràng buộc khác đối với các giao dịch. Do đó, cần phải sử dụng phương pháp tìm kiếm vét cạn. | 1 byte | 1 byte |
| Số lượng đầu ra | Một giao dịch chỉ có thể có chính xác một đầu ra; nếu không, nó khó có thể có kích thước chính xác là 64 byte. | 1 byte | 1 byte |
| Giá trị đầu ra | Kẻ tấn công có thể gửi bao nhiêu Bitcoin tùy thích, miễn là họ có đủ tiền và sẵn sàng từ bỏ số tiền đó. Nếu đầu vào của giao dịch này trị giá 1 BTC, thì có 100 triệu giá trị đầu ra khả dĩ (100 triệu satoshi bằng 1 BTC). Do đó, lĩnh vực này (ở một mức độ nào đó) có thể bị thao túng. Tuy nhiên, có thể cần phải đốt tới 21 triệu BTC để thao túng hoàn toàn lĩnh vực này. | 8 byte | 0 |
| Độ dài tập lệnh đầu ra | Việc thao túng rất khó khăn vì có những ràng buộc khác đối với các giao dịch. Do đó, cần phải sử dụng phương pháp tìm kiếm vét cạn. | 1 byte | 1 byte |
| Khóa công khai của tập lệnh đầu ra | Vì số tiền được rót vào giao dịch này không thể thu hồi lại, nên lĩnh vực này có thể dễ dàng bị thao túng. | 8 byte | 0 |
| Thời gian khóa | Thời gian khóa có thể được điều chỉnh, ví dụ, được biểu thị bằng Block Height, với giá trị tối đa là 500 triệu. Do đó, ở đây có lượng lớn. | 4 byte | 0 |
| tổng cộng | 8 byte |
Do đó, dựa trên bảng trên, trong điều kiện thuận lợi nhất cho kẻ tấn công (sử dụng tất cả các trường có thể thao tác), kẻ tấn công chỉ cần tìm thấy 8 byte xung đột. 8 byte, hay 2^64 lần, không yêu cầu nhiều tài nguyên tính toán; một máy tính xách tay thông thường có thể hoàn thành việc này một cách nhanh chóng. Trên thực tế, nó có thể cần nhiều hơn 2^64 lần một chút vì không có trường nào được đề cập ở trên bị thao tác hoàn toàn.
Tuy nhiên, cuộc tấn công này không nghiêm trọng như vẻ ngoài của nó. Việc tạo ra lập nó cực kỳ phức tạp, có thể yêu cầu một giao dịch khởi tạo với hàng nghìn đầu ra và tiêu tốn hàng nghìn đô la, tất cả chỉ để thao túng một vài byte entropy. Hơn nữa, ví SPV hiện nay không còn phổ biến. Những người mong muốn nhận được các khoản thanh toán giá trị cao đều biết rằng họ cần một nút đầy đủ để xác minh các khoản thanh toán đến. Tuy nhiên, cuộc tấn công này vẫn khả thi, đặc biệt là với các công cụ sẵn có, khiến nó đáng được chú ý và thúc đẩy chúng ta tìm hiểu rủi ro giảm thiểu.
va chạm băm Merklegen
Một lỗ hổng bảo mật liên quan khác Bitcoin đã được phát hiện và khắc phục vào năm 2012. Lỗ hổng này liên quan đến hai khối Bitcoin khác nhau, một khối hợp lệ và một khối không hợp lệ, có thể có cùng mã băm gốc Merkle. Có nhiều nguyên nhân gây ra điều này, một trong đó là nhầm lẫn bước băm trung gian 64 byte với giao dịch 64 byte.
Vấn đề cốt lõi là nút Bitcoin lưu trữ mã băm của các khối không hợp lệ để tránh phải xác minh lại chúng (lãng phí tài nguyên). Tuy nhiên, nếu hai khối có cùng mã băm, một khối hợp lệ và một khối không hợp lệ, một nút Bitcoin (sau khi đã xác minh khối không hợp lệ trước, không thể xác minh khối hợp lệ nữa) có thể bị đánh lừa mà bỏ qua Chuỗi có nhiều Bằng chứng công việc nhất và theo dõi một Chuỗi đối thủ có ít Bằng chứng công việc hơn. Vấn đề này đã được khắc phục vào năm 2012 phương pháp yêu cầu nút thực hiện thêm một bước kiểm tra trước khi lưu trữ mã băm của các khối không hợp lệ.
Một lỗ hổng liên quan đã xuất hiện trở lại vào năm 2019 khi nhà phát triển Bitcoin Suhas Daftuar nhận thấy rằng một lỗi tương tự đã vô tình được đưa trở lại trong Bitcoin Core 0.13.0 (phát hành vào tháng 11 năm 2016) và sau đó đã được sửa chữa vào tháng 2 năm 2017. Các lỗ hổng khác cũng liên quan đến vấn đề được thảo luận trong bài viết này; cũng có thể có các lỗ hổng chưa được phát hiện.
Giải pháp đề xuất
Khắc phục sự cố này không cần đến soft fork, ít nhất là đối với các lỗ hổng giả mạo SPV. Phương pháp được ví SPV sử dụng có thể nâng cấp, ví dụ, bằng cách luôn kiểm tra các giao dịch ở cùng cấp độ Merkle trees với các giao dịch với Coinbase. Tuy nhiên, vấn đề là ví SPV chưa thực hiện điều này, và sự hiểu biết về vấn đề này còn hạn chế. Do đó, người dùng vẫn dễ bị tổn thương.
Hiện tại, giải pháp soft fork được đề xuất là BIP 54, phương pháp hoàn toàn các giao dịch có độ dài 64 byte sau khi dữ liệu chứng thực đã bị loại bỏ. Điều này nghe có vẻ là một giải pháp rất đơn giản và dễ dàng. Xét cho cùng, dường như không có lý do gì để tạo ra một giao dịch có độ dài chính xác 64 byte. Ví dụ, trong ví dụ trên, chính việc đổ tiền vào một "lỗ đen" đã tạo ra giao dịch 64 byte. Suhas Daftuar đã lưu ý trong một email năm 2019 rằng ông đã quét toàn bộ blockchain Bitcoin và không tìm thấy bất kỳ giao dịch nào có độ dài chính xác 64 byte. Điều này sẽ giúp soft fork diễn ra suôn sẻ hơn và dễ đạt được sự đồng thuận hơn vì nó cấm một điều chưa từng xảy ra trước đây, do đó ít rủi ro và ít gây tranh cãi hơn. Tuy nhiên, hiện nay, vẫn có thể có một số giao dịch 64 byte.
BIP54 sẽ đưa ra một quy tắc mới khá đặc biệt cho Bitcoin: các giao dịch có kích thước 63 byte và 65 byte sẽ hợp lệ; chỉ các giao dịch có kích thước 64 byte mới không hợp lệ. Tuy nhiên, sẽ tốt hơn nếu áp đặt càng ít hạn chế đối với các giao dịch càng tốt.
