Đầu năm nay, chúng tôi đã đưa ra một chương trình tiền thưởng lỗi tập trung vào việc tìm kiếm các vấn đề trong đặc tả chuỗi đèn hiệu và / hoặc trong việc triển khai ứng dụng khách (Lighthouse, Nimbus, Teku, Prysm, v.v.). Các kết quả (và các báo cáo về lỗ hổng bảo mật) đã mang lại những bài học kinh nghiệm trong khi vá các vấn đề tiềm ẩn.
Trong loạt bài mới này, chúng tôi mong muốn khám phá và chia sẻ một số thông tin chi tiết mà chúng tôi đã thu được từ công việc bảo mật cho đến nay và khi chúng tôi tiếp tục phát triển.
Bài đăng đầu tiên này sẽ phân tích một số nội dung gửi nhắm mục tiêu cụ thể đến các nguyên thủy BLS.
Tuyên bố từ chối trách nhiệm: Tất cả các lỗi được đề cập trong bài đăng này đã được sửa.
BLS ở khắp mọi nơi
Vài năm trước, Diego F. Aranha đã nói chuyện tại Hội thảo lần thứ 21 về Mật mã đường cong Elliptic với tiêu đề: Các cặp đôi không chết, chỉ đang nghỉ ngơi. Thật là tiên tri.
Chúng ta đang ở đây vào năm 2021 và các cặp là một trong những tác nhân chính đằng sau nhiều nguyên thủy mật mã được sử dụng trong không gian blockchain (và hơn thế nữa): BLS chữ ký tổng hợp, hệ thống ZK-SNARKS, v.v.
Công việc phát triển và tiêu chuẩn hóa liên quan đến chữ ký BLS đã là một dự án đang diễn ra đối với các nhà nghiên cứu EF trong một thời gian, một phần được thúc đẩy bởi Justin Drake và tóm tắt trong một bài đăng gần đây của anh ấy trên reddit.
Mới nhất và tuyệt vời nhất
Trong khi đó, đã có rất nhiều bản cập nhật. BLS12-381 hiện được công nhận rộng rãi là đường cong ghép nối được sử dụng với kiến thức hiện tại của chúng tôi.
Ba dự thảo IRTF khác nhau hiện đang được phát triển:
- Các đường cong thân thiện với cặp đôi
- Chữ ký BLS
- Băm theo đường cong Elliptic
Hơn nữa, đặc điểm kỹ thuật chuỗi beacon đã trưởng thành và đã được triển khai một phần. Như được đề cập ở trên, Chữ ký BLS là một phần quan trọng của câu đố đằng sau bằng chứng cổ phần (PoS) và chuỗi báo hiệu.
Bài học kinh nghiệm gần đây
Sau khi thu thập các nội dung gửi nhắm mục tiêu đến các nguyên thủy BLS được sử dụng trong lớp đồng thuận, chúng tôi có thể chia các lỗi được báo cáo thành ba khu vực:
- Sơ lược về dự thảo IRTF
- Sai lầm khi triển khai
- Vi phạm triển khai dự thảo IRTF
Hãy phóng to từng phần.
Sơ lược về dự thảo IRTF
Một trong những phóng viên, (Nguyễn Thới Minh Quân), nhận thấy sự khác biệt trong Dự thảo IRTFvà xuất bản hai sách trắng với những phát hiện:
Trong khi những mâu thuẫn cụ thể vẫn còn để tranh luậnanh ấy thấy một số điều thú vị thực hiện vấn đề trong khi tiến hành nghiên cứu của mình.
Sai lầm khi triển khai
Guido Vranken đã có thể phát hiện ra một số vấn đề “nhỏ” trong BLST sử dụng sự khác biệt fuzzing. Xem ví dụ về những người dưới đây:
Anh ấy đã đứng đầu điều này với việc phát hiện ra một lỗ hổng vừa phải ảnh hưởng đến Hàm blst_fp_eucl_inverse của BLST.
Vi phạm triển khai dự thảo IRTF
Một loại lỗi thứ ba liên quan đến vi phạm triển khai dự thảo IRTF. Điều đầu tiên ảnh hưởng đến Khách hàng Prysm.
Để mô tả điều này, trước tiên chúng ta cần cung cấp một chút thông tin cơ bản. Các Chữ ký BLS Dự thảo IRTF bao gồm 3 chương trình:
- Sơ đồ cơ bản
- Tăng tin nhắn
- Bằng chứng sở hữu
Các Khách hàng Prysm không có bất kỳ sự phân biệt nào giữa 3 trong API của nó, điều này là duy nhất giữa các triển khai (ví dụ: py_ecc). Một điểm đặc biệt về sơ đồ cơ bản Là trích dẫn nguyên văn: ‘Chức năng này trước tiên đảm bảo rằng tất cả các thông báo là khác biệt’ . Điều này không được đảm bảo trong AggregateVerify hàm số. Prysm đã khắc phục sự khác biệt này bằng cách không dùng nữa của AggregateVerify (không được sử dụng ở bất kỳ đâu trong thông số kỹ thuật chuỗi đèn hiệu).
Sự cố thứ hai bị ảnh hưởng py_ecc. Trong trường hợp này, quá trình tuần tự hóa được mô tả trong Đặc điểm kỹ thuật ZCash BLS12-381 rằng các số nguyên lưu trữ luôn nằm trong phạm vi [0, p – 1]. Các py_ecc việc triển khai đã kiểm tra nhóm G2 của BLS12-381 chỉ cho phần thực nhưng không thực hiện hoạt động mô-đun cho phần tưởng tượng. Sự cố đã được khắc phục với yêu cầu kéo sau: Không đủ xác thực khi giải nén_G2 Deserialization trong py_ecc.
Kết thúc
Hôm nay, chúng tôi đã xem xét các báo cáo liên quan đến BLS mà chúng tôi đã nhận được như một phần của chương trình tiền thưởng lỗinhưng đây chắc chắn không phải là kết thúc của câu chuyện cho công việc bảo mật hoặc cho những cuộc phiêu lưu liên quan đến BLS.
chúng tôi mạnh mẽ khuyến khích bạn để giúp đảm bảo lớp đồng thuận tiếp tục phát triển an toàn hơn theo thời gian. Cùng với đó, chúng tôi mong nhận được phản hồi từ bạn và khuyến khích bạn DIG! Nếu bạn cho rằng mình đã tìm thấy lỗ hổng bảo mật hoặc bất kỳ lỗi nào liên quan đến chuỗi beacon hoặc các ứng dụng khách có liên quan, gửi báo cáo lỗi! 💜🦄
