Phân tích bảo mật thỏa thuận Byzantine PBFT: Không phù hợp với chuỗi liên minh hoặc chuỗi công khai

Tác giả: Giáo sư Wang Yongge, một nhà mật mã học nổi tiếng người Trung Quốc, giáo sư chính thức của Khoa Khoa học Máy tính tại Đại học Bắc Carolina ở Charlotte (UNC, Charlotte), và bằng tiến sĩ của Đại học Heidelberg ở Đức.

Việc thiết kế các giao thức đồng thuận luôn là một chủ đề đầy thách thức. Người đoạt giải Turing, Lamport năm 1989 đã sử dụng quy trình xây dựng luật của một nhóm nhà lập pháp nghiệp dư trên đảo Paxos của Hy Lạp cổ đại để mô tả giao thức đồng thuận Paxos mà ông thiết kế cho điện toán phân tán. Lamport đã gửi bài viết của mình tới ACM TOCS. Có lẽ người biên tập tạp chí này đã không đánh giá cao tầm quan trọng của bài báo nên không bao giờ đồng ý đăng nó. Mãi cho đến khi giao thức đồng thuận Paxos được thảo luận rộng rãi trong giới học thuật và được sử dụng rộng rãi trong ngành công nghiệp thì tạp chí này mới xuất bản bài viết này vào năm 1998:

Lamport, Leslie. "Quốc hội bán thời gian." Giao dịch ACM trên hệ thống máy tính (TOCS) 16.2 (1998): 133-169.

Lamport nói đùa rằng đây là lần chờ đợi lâu thứ hai để xuất bản bất kỳ bài báo nào của ông. Cho đến nay, giao thức đồng thuận Paxos được sử dụng trong hầu hết các hệ thống phân tán. Ví dụ: Bigtable của Google sử dụng hệ thống dịch vụ Chubby lock để đảm bảo tính nhất quán của dữ liệu trên mỗi nút. Dịch vụ khóa Chubby dựa trên giao thức Paxos. Ngoài ra, các hệ thống dịch vụ đám mây của Microsoft, IBM và Amazon đều sử dụng giao thức Paxos để mang lại sự nhất quán cho hệ thống. Nói một cách đại khái, giao thức Paxos bao gồm một loạt các VÒNG. ROUND bắt đầu từ 0 cho đến khi đạt được sự đồng thuận. Mỗi VÒNG được chia thành bốn bước sau:

1. Nút chính tạo số thứ tự và truyền phát số đó đến tất cả các nút. Tôi hy vọng mọi người sẽ tham gia vào hoạt động của số sê-ri này
2. Mỗi nút gửi thông tin sau đến nút chính: số sê-ri mà anh ta đã bỏ phiếu và phiếu bầu của anh ấy
3. Sau khi nhận được hầu hết các câu trả lời từ bước thứ hai, nút chính sẽ chọn một giá trị v không vi phạm AN TOÀN. Phát giá trị v này tới tất cả các nút
4. Sau khi nhận được giá trị v từ bước thứ ba của nút chính, mỗi nút sẽ bỏ phiếu cho v Và phát sóng phiếu bầu của anh ấy cho tất cả các nút

Vì giao thức Paxos khó triển khai nên các nhà nghiên cứu của Stanford đã đề xuất một giao thức mô-đun trong giao thức Paxos năm 2014 dễ dàng để thực hiện và đặt tên cho giao thức Raft. Giao thức Paxos/Raft hoạt động trong mô hình mối đe dọa nhẹ hơn. Nói cách khác, giao thức chỉ mạnh mẽ đối với các lỗi không phải của Byzantine trong các mạng không đồng bộ. Trong mô hình mối đe dọa không phải của Byzantine, các nút bị lỗi chỉ có thể mắc lỗi thụ động (chẳng hạn như dừng công việc) nhưng không thể khởi động các cuộc tấn công chủ động. Số nút bị lỗi không phải Byzantine tối đa mà một hệ thống có n nút có thể chịu đựng được là (n-1)/2. Giao thức Paxos/Raft đạt đến số nút có khả năng chịu lỗi tối đa này.

Vì giao thức Paxos/Raft không mạnh đối với các lỗi Byzantine nên chúng không thể được sử dụng trong hệ thống mạng mở (chẳng hạn như chuỗi khối) ). Lỗi Byzantine là các lỗi mang tính hung hãn, chẳng hạn như nói dối, giả mạo tin nhắn, thông đồng để tấn công hoặc phát động một cuộc tấn công DoS có chọn lọc. Chúng tôi đã đề cập trong các bài viết trước rằng hệ thống blockchain phi tập trung dựa trên hệ thống mạng mở, vì vậy chúng tôi phải sử dụng mô hình mối đe dọa Byzantine.

Giao thức Byzantine được sử dụng phổ biến nhất trong các chuỗi khối hiện có trên thị trường được thiết kế bởi Barbara Liskov, người đoạt giải Turing và học trò của cô, Castro Thực hành Byzantine Fault Hệ thống dung sai PBFT (BFT thực tế). PBFT được sử dụng rộng rãi trong các chuỗi liên minh (chẳng hạn như Hyperledger răng cưa và Hyperchain của Qulian Technology) và nhiều chuỗi công khai. PBFT có thể được xem là phiên bản Byzantine của giao thức Paxos. Sự khác biệt chính là PBFT thêm một bước xác minh vào giao thức Paxos để ngăn lỗi Byzantine. Trước khi phân tích tính bảo mật của nó, trước tiên chúng tôi đưa ra mô tả chính thức về giao thức của nó.

Trong giao thức PBFT, chúng tôi giả sử rằng có n=3t+1 nút P1, …, Pn. Hầu hết t nút được kiểm soát bởi kẻ tấn công. PBFT yêu cầu tất cả các nút phải cùng nhau duy trì trạng thái và thực hiện các hành động nhất quán. Giao thức PBFT được thực hiện thông qua một loạt các khung nhìn. Trong mỗi chế độ xem, có một nút được gọi là nút dẫn đầu. Hệ thống PBFT trước tiên bắt đầu với chế độ xem (v=0) và sau đó chuyển sang chế độ xem v=1, v=2, …, v.v. thông qua giao thức thay thế chế độ xem. Chỉ khi hệ thống tin rằng nút chính không hoạt động bình thường thì giao thức thay thế chế độ xem mới được bắt đầu để vào chế độ xem tiếp theo. Chúng tôi giả định rằng tất cả các nút đều biết nút chính của mỗi chế độ xem là ai. Bất cứ khi nào khách hàng gửi tác vụ đến nút chính của chế độ xem hiện tại, giao thức PBFT sẽ thực hiện ba giai đoạn giao tiếp: phân bổ số thứ tự (chuẩn bị trước), tương tác lẫn nhau (chuẩn bị) và xác nhận số thứ tự (cam kết). Giai đoạn phân bổ số thứ tự (chuẩn bị trước) chỉ định một số thứ tự cho mỗi nhiệm vụ và các giai đoạn tương tác lẫn nhau (chuẩn bị) và xác nhận số thứ tự (cam kết) cung cấp thứ tự chung cho tất cả các nhiệm vụ. Giả sử chúng ta hiện đang ở chế độ xem v và nút chính là Pi. Sau đó, quy trình của toàn bộ giao thức như sau:

1. Máy khách gửi một yêu cầu tác vụ m để kích hoạt hoạt động dịch vụ của nút chủ.
2. Khi nút chính Pi nhận được yêu cầu tác vụ m, nó sẽ khởi động giao thức ba pha:
a. Giai đoạn phân bổ số thứ tự (chuẩn bị trước): nút chính chọn một số thứ tự duy nhất cho yêu cầu nhiệm vụ m. Sau đó, nút chính sẽ phát thông báo sau tới tất cả các nút
m,<PRE-PREPARE, v, seq, H(m)>, SIGNATURE
Trong đó H là hàm băm. Nút Pj chấp nhận thông báo trên nếu đáp ứng các điều kiện sau
i. Chữ ký số SIGNATURE hợp lệ
ii. Pj chưa chấp nhận một yêu cầu nhiệm vụ khác có cùng v, seq
iii. Sequence seq nằm trong phạm vi hợp lý

b. Giai đoạn tương tác (chuẩn bị) lẫn nhau: Nếu nút Pj chấp nhận tin nhắn quảng bá của nút chính, sau đó Pj bước vào giai đoạn tương tác (chuẩn bị) lẫn nhau và phát thông báo sau tới tất cả các nút

<PREPARE, v, seq, H (m), Pj>, SIGNATURE

c. Giai đoạn xác nhận (cam kết) số sê-ri: Đối với nút Pj, một mảng< m, v, seq, Pj> sẵn sàng khi và chỉ khi Pj đã nhận được ít nhất 2t tin nhắn hợp lệ <PREPARE, v, seq, H(m), P>. Khi mảng <m, v, seq, Pj> sẵn sàng cho Pj, Pj sẽ phát thông báo xác nhận sau tới tất cả các nút:

<COMMIT, v, seq, H(m), Pj>, SIGNATURE

Khi một nút nhận được xác nhận Sau 2t+1 tin nhắn, nút sẽ thực thi các tác vụ có trong yêu cầu tác vụ m và gửi kết quả trực tiếp đến máy khách.
3. Máy khách chờ phản hồi từ các nút khác nhau. Nếu t+1 phản hồi giống nhau thì phản hồi đó là kết quả của thao tác.

Gần đây chúng tôi đã phân tích tính bảo mật của PBFT trong bài viết sau:

Yongge Wang. Dung sai lỗi Byzantine trong mạng không đồng bộ được kết nối một phần

Kết luận phân tích của bài viết này Đó là giao thức đồng thuận PBFT không an toàn trong các mạng không đồng bộ. Trong bài viết này, chúng tôi giới thiệu ngắn gọn phương pháp tấn công mà chúng tôi đã thiết kế trên giao thức PBFT trong các mạng không đồng bộ. Để đơn giản hóa mô tả của chúng tôi, chúng tôi giả sử rằng hệ thống có n=3+1=4 nút P1, P2, P3, P4. Trong số đó, nút P1 do kẻ tấn công kiểm soát. Ngoài ra, chúng tôi giả định rằng nút chính của khung nhìn v là P1. Cuộc tấn công của chúng tôi được phát động trong chế độ xem v:

1. Trong giai đoạn phân bổ số thứ tự (chuẩn bị trước) của chế độ xem v, chủ nhân nút P1 Thông báo quảng bá "m, <PRE-PREPARE, v, seq, H(m) >, SIGNATURE" được gửi đến P1, P2 và P3. Nhưng không được cấp cho P4.

2. Trong giai đoạn tương tác (chuẩn bị) lẫn nhau, P1 phát đi thông báo "<PREPARE, v, seq, H(m), P1> , SIGNATURE" được gửi tới P1, P2, P3. Nhưng không được cấp cho P4. Trong giai đoạn tương tác (chuẩn bị) lẫn nhau, các nút P2 và P3 sẽ phát các thông báo "<PREPARE, v, seq, H(m), P2>, SIGNATURE" và "<PREPARE, v, seq, H(m), P3>, SIGNATURE" được gửi tới tất cả các nút. Tất nhiên, nếu có thể, kẻ tấn công có thể khởi động một cuộc tấn công DoS để nút P4 không nhận được các tin nhắn quảng bá của các nút P2 và P3 (cuộc tấn công DoS này không quan trọng lắm đối với cuộc tấn công của chúng ta). Tại thời điểm này, mảng <m, v, seq, Pj> đã sẵn sàng cho các nút P1, P2, P3. Vì P4 đã nhận được tối đa hai tin nhắn tương tác lẫn nhau và chúng ta cần ít nhất 2+1=3 tin nhắn để chuẩn bị một mảng, vì vậy đối với P4, mảng đó chưa sẵn sàng.

3. Trong giai đoạn xác nhận số thứ tự (cam kết), P1 gửi tin nhắn quảng bá "<COMMIT, v , seq, H(m), P1>, SIGNATURE" được gửi tới P1 và P2. Nhưng không được cấp cho P4. Trong giai đoạn xác nhận số thứ tự (cam kết), các nút P2 và P3 sẽ phát các thông báo "<COMMIT, v, seq, H(m), P2>, SIGNATURE" và "<PREPARE, v, seq, H(m) , P3>, SIGNATURE" được gửi tới tất cả các nút. Tất nhiên, nếu có thể, kẻ tấn công có thể khởi động một cuộc tấn công DoS để nút P4 không nhận được các tin nhắn quảng bá của các nút P2 và P3 (cuộc tấn công DoS này không quan trọng lắm đối với cuộc tấn công của chúng ta). Đến thời điểm này, nút P1 và P2 đã nhận được 3 tin nhắn xác nhận cho nhiệm vụ m. Nút P3 và P4 nhận được tối đa 2 thông báo xác nhận cho nhiệm vụ m. Vì vậy nút P2 sẽ thực thi các tác vụ có trong yêu cầu tác vụ m và gửi kết quả trực tiếp đến máy khách. Nhưng P1, P3, P4 sẽ không thực hiện nhiệm vụ này. Vì vậy, khách hàng không nhận được đủ phản hồi.

Sau khi thực hiện cuộc tấn công trên, nút P1 sẽ không còn trả lời bất kỳ tin nhắn nào từ bất kỳ chế độ xem nào v. Vì vậy hệ thống sẽ khởi tạo giao thức thay đổi chế độ xem để vào chế độ xem tiếp theo v +1. Sau khi vào chế độ xem v +1, trạng thái dữ liệu bên trong của P2, P3 và P4 của các nút trung thực sẽ khác nhau. Vì vậy hệ thống đi vào trạng thái không phối hợp.

Trong giao thức PBFT, để giải quyết vấn đề một số nút có thể không nhận được một số tin nhắn nhất định (chẳng hạn như kịch bản tấn công ở trên của chúng tôi) , giao thức PBFT Đã thiết kế quy trình cập nhật trạng thái CHECKPOINT. Đặc biệt, cứ sau 100 tác vụ, mỗi nút Pj sẽ phát thông báo trạng thái hiện tại của mình tới tất cả các nút:

<ĐIỂM KIỂM TRA, seq, H(state), Pj>, CHỮ KÝ

Nếu nút Pi nhận được thông báo cập nhật trạng thái 2t+1 như trên và trạng thái của nó là trạng thái thì nút Pi sẽ thay thế trạng thái hiện tại của nó bằng trạng thái trong thông báo trên. Trong cuộc tấn công trên của chúng tôi, nếu nút không trung thực P1 không xuất bản thông báo cập nhật trạng thái thì thông báo cập nhật trạng thái do P2 xuất bản sẽ khác với thông báo cập nhật trạng thái do P3 và P4 xuất bản. Bởi vì chúng ta cần ít nhất 2+1=3 thông báo cập nhật trạng thái giống hệt nhau để cập nhật trạng thái của một nút, nên trạng thái của P2 không thể được cập nhật lên trạng thái của P3 và P4. Vì vậy hệ thống sẽ luôn ở trạng thái bất hòa.

Trong tương lai, nút không trung thực P1 có thể hợp tác với các nút trung thực P3 và P4 để cùng thực hiện một nhiệm vụ khác của khách hàng. Do đó, trạng thái của mỗi nút sẽ chuyển sang trạng thái không phối hợp không thể phục hồi.

Trong bài viết trước, chúng tôi đã đề cập rằng các cuộc tấn công DoS rất phổ biến trong công nghệ chuỗi khối dựa trên Internet. Dễ dàng phát hiện. Vì Internet là mạng không đồng bộ nên chúng tôi sử dụng mô hình sau để mô tả giao tiếp mạng của nó:

· Có Thời gian Ổn định Toàn cầu ( GST), trước GST, mọi tin nhắn đều có thể bị mất (chẳng hạn như tấn công DoS) hoặc bị sắp xếp lại. Sau GST, mạng trở thành mạng đồng bộ. Nhưng khi nào thuế GST sẽ bắt đầu thì không ai biết.

Vì vậy, cuộc tấn công trên của chúng tôi có thể được triển khai trước thuế GST trên các mạng không đồng bộ. Vậy nếu một hệ thống blockchain sử dụng PBFT làm giao thức đồng thuận thì kết quả của cuộc tấn công trên của chúng ta là gì? Nói chung, sau khi khởi động cuộc tấn công trên, hệ thống blockchain trước tiên sẽ phân nhánh và sau đó chuyển sang trạng thái chết (nghĩa là blockchain sẽ không có bất kỳ khối mới nào để tạo). Cụ thể, blockchain mà mọi người đã đạt được sự đồng thuận trước khi phát động cuộc tấn công mà chúng tôi mô tả ở trên là: A→B→C→D. Kẻ tấn công sử dụng kế hoạch tấn công trên để trước tiên để P2 quyết định khối tiếp theo là E. Nghĩa là, trong bản ghi của P2, chuỗi khối hiện tại là: A→B→C→D→E. Nhưng blockchain hiện tại được P3 và P4 ghi lại vẫn là A→B→C→D. Sau đó, kẻ tấn công P1 cho phép các nút P3 và P4 quyết định rằng nút tiếp theo là F. Theo cách này, trong bản ghi của P3 và P4, chuỗi khối hiện tại là: A→B→C→D→F. Vì khối E khác với khối F. Chuỗi khối đã phân nhánh. Bởi vì khối tiếp theo phải mở rộng từ blockchain hiện tại. Nếu nút không tham gia vào bất kỳ hoạt động nào kể từ bây giờ thì hệ thống chưa cấp số phiếu bầu tối thiểu 2+1=3. Vì vậy không có khối mới nào có thể được tạo ra. Tổng hợp lại, phân tích của chúng tôi trong bài viết này kết luận rằng giao thức đồng thuận PBFT không thể đảm bảo các yêu cầu về an toàn và tồn tại của hệ thống blockchain. Do đó, chúng tôi khuyến nghị rằng cho dù đó là chuỗi liên kết hay chuỗi công khai, không nên sử dụng PBFT làm giao thức đồng thuận.

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia