Lược đồ chữ ký nhóm với truy xuất nguồn gốc phân tán (hoặc cách mở chữ ký một cách công bằng)

Hình ảnh của Anne-Laure Delva

Trong bài đăng này, tôi muốn thảo luận về các lược đồ chữ ký nhóm, và cụ thể là chữ ký nhóm với khả năng truy nguyên nguồn gốc phân tán và chỉ ra lý do tại sao đây là một công cụ mã hóa thú vị cho các hệ thống phân tán, sử dụng giao thức đồng thuận Helix làm ví dụ cho cách sử dụng các chữ ký này.

Chữ ký của nhóm, được giới thiệu bởi Chaum và Van Heyst, cho phép một thành viên của nhóm ký tên nặc danh thay mặt nhóm, đồng thời cung cấp khả năng truy tìm danh tính của người ký trong các trường hợp đặc biệt. Nghĩa là, những người tham gia nhóm có thể kiểm tra, sử dụng các khóa xác minh, rằng chữ ký thực sự được tạo bởi ai đó trong nhóm nhưng họ không thể biết ai là ai. Trong trường hợp tranh chấp hoặc hành vi sai trái, cơ quan theo dõi sử dụng khóa truy tìm của mình để truy tìm người ký tên.

Đối với một số trường hợp sử dụng có một cơ quan theo dõi duy nhất hoạt động. Tuy nhiên, trong nhiều trường hợp khác, không có một cơ quan nào mà mọi người đều tin tưởng vào việc thu hồi danh tính và do đó, việc phân chia trách nhiệm giữa một số cơ quan có ý nghĩa hơn. Cái nhìn sâu sắc này dẫn đến Stewumea et al. để thiết kế chữ ký nhiều nhóm có thể truy tìm được Trong kế hoạch của họ, việc mở chữ ký là có thể nếu nhiều cơ quan công bằng hợp tác. Các cơ quan công bằng cũng có thể hợp tác để tiết lộ khóa truy tìm của người dùng đang bị nghi ngờ. Khóa này có thể được sử dụng để kiểm tra xem một tin nhắn đã được ký bởi một người dùng nào đó mà không thu hồi ẩn danh của những người dùng khác.

Cho đến ngày nay, có một số lược đồ chữ ký với khả năng truy tìm nguồn gốc phân tán khác nhau đôi chút về chức năng mà họ cung cấp, chẳng hạn như Chữ ký của Tập đoàn Dân chủ với Ngưỡng truy xuất nguồn gốc của Trịnh và cộng sự, và Chữ ký của nhóm Short với Truy tìm nguồn gốc phân tán của Blomer et al., trên đó tôi sẽ giải thích thêm.

Chữ ký nhóm với khả năng truy xuất nguồn gốc phân tán trong Helix

Tại Orbs, chúng tôi đang phát triển Helix, giao thức đồng thuận ban đầu được thiết kế đặc biệt để đảm bảo các giao dịch được sắp xếp một cách công bằng. Khái niệm chính trong Helix là các nút mạng không thể thao tác các giao dịch nào được bao gồm trong một khối mới hoặc thứ tự của chúng. Cụ thể, họ không thể kiểm duyệt các nút hoặc người dùng cụ thể và không thể ưu tiên các giao dịch của riêng họ một cách đáng kể. Bạn có thể đọc thêm về Helix trong bài đăng trên blog này.

Một đóng góp chính cho sự công bằng trong Helix là người dùng mã hóa các giao dịch của họ và sau đó giải mã các giao dịch ban đầu chỉ sau khi chúng được gắn vào blockchain. Mã hóa các giao dịch có giá, đặc biệt, nó làm tăng nhu cầu trừng phạt người dùng và các nút đang gửi rác đến mạng thay vì các giao dịch hợp lệ. Vì lý do này, chúng tôi cần một cơ chế tiết lộ các nút mạng nào chịu trách nhiệm cho các giao dịch có vấn đề nhằm làm giảm danh tiếng của họ.

Chúng tôi có thể thực hiện việc này bằng cách sử dụng chữ ký nhóm với khả năng truy nguyên nguồn gốc phân tán, bằng cách mỗi nút mạng đóng vai trò là cơ quan công bằng và yêu cầu một số lượng chính quyền để mở và theo dõi chữ ký.

Bây giờ tôi chuyển sang mô tả dòng chảy mà giao dịch thực hiện trong Helix và cách sử dụng chữ ký nhóm với truy xuất nguồn gốc phân tán. Nếu bạn ít quan tâm đến luồng đặc biệt này, bạn có thể bỏ qua và đọc về sơ đồ chữ ký ứng viên. Luồng bắt đầu khi người dùng tạo một giao dịch, mã hóa nó và gửi nó đến một nút mạng mà nó được liên kết. Nút mạng sau đó ký giao dịch bằng cách sử dụng sơ đồ chữ ký nhóm có thể theo dõi công bằng và chuyển tiếp giao dịch vào mạng. Trước khi bao gồm giao dịch trong một khối, người tạo khối kiểm tra giao dịch có chữ ký nhóm hợp lệ. Sau khi khối được gắn vào blockchain, chúng tôi bắt đầu một quy trình (yêu cầu số lượng nút ngưỡng) để giải mã các giao dịch trong khối. Nếu cần (ví dụ: giao dịch được giải mã hóa ra không hợp lệ) một số ngưỡng nút hợp tác và mở chữ ký để tiết lộ nút nào đã ký giao dịch này.

Một tùy chọn có thể khác cho luồng là mở các chữ ký theo mặc định song song với quá trình giải mã. Ưu điểm của việc mở chữ ký theo mặc định là theo cách này chúng ta không cần phải khởi tạo một giao thức đặc biệt cho các giao dịch bị lỗi và thay vào đó, quy trình này được thực thi như một phần của luồng thông thường. Một tùy chọn khác là kết hợp quá trình tiết lộ khóa theo dõi (được sử dụng để theo dõi một nút làm sai cụ thể). Chúng tôi cũng lưu ý rằng một số lược đồ chữ ký nhóm cũng có chức năng khiếu nại, trong đó người ký có thể yêu cầu chữ ký thuộc về họ, mà chúng tôi không sử dụng trong luồng trên.

Từ luồng của chúng tôi, chúng tôi suy ra các yêu cầu bảo mật mà chúng tôi tìm kiếm:

  • Tính ẩn danh: Chữ ký nhóm không tiết lộ danh tính của thành viên đã tạo ra nó, trừ khi có nhiều hơn một số lượng các cơ quan công bằng hợp tác.
  • Truy nguyên nguồn gốc duy trì tính ẩn danh: Nếu một nút tuyên bố đó là người khởi tạo chữ ký hoặc danh tính của nó được tiết lộ như một phần của thuật toán truy tìm, thì điều này không bao gồm quyền riêng tư của các chữ ký nhóm trong quá khứ hoặc tương lai còn lại mà nó phát hành.
  • Không liên kết: Không thể liên kết hai hoặc nhiều chữ ký được sản xuất bởi cùng một người ký mà không có sự hợp tác của một số nhà chức trách.
  • Không dễ bị tổn thương: Ngay cả khi nhóm và người quản lý truy tìm thông đồng với phần còn lại của nhóm, họ không thể đóng khung một thành viên nhóm trung thực. Người dùng có thể bị đóng khung theo hai cách khác nhau: chính quyền và người dùng khác có thể tạo chữ ký mở hoặc dấu vết cho người dùng vô tội (yêu cầu này còn được gọi là tính linh hoạt mạnh) hoặc họ có thể yêu cầu chữ ký do người dùng tạo ra của riêng họ.

Các yêu cầu quan trọng khác là: hỗ trợ thay đổi năng động của người ký và bộ theo dõi, và không yêu cầu thiết lập đáng tin cậy.

Đề án chữ ký ứng viên

Một trong những lược đồ chữ ký hiệu quả nhất hiện được biết đến là của Boneh, Boyen và Shacham (BBS), họ đã giới thiệu trong chữ ký của nhóm Viết ngắn của họ. Đề án chữ ký của họ thiếu một vài thuộc tính cần thiết cho việc sử dụng của chúng tôi. Thứ nhất, sơ đồ chữ ký nhóm của họ không cung cấp truy xuất nguồn gốc phân tán mà chỉ yêu cầu cơ quan truy tìm tập trung. Ngoài ra, chương trình của họ không đáp ứng khả năng truy nguyên nguồn gốc duy trì tính chất ẩn danh (vì nó không cung cấp ẩn danh CCA, được giải thích sau), điều này rất quan trọng trong cài đặt của chúng tôi. Hơn nữa, quá trình tạo khóa đòi hỏi một đại lý đáng tin cậy. May mắn thay, có những bài báo tiếp theo chăm sóc hai vấn đề đầu tiên. Các ý tưởng có thể được kết hợp để đạt được sơ đồ chữ ký ẩn danh CCA cung cấp khả năng truy nguyên nguồn gốc phân tán. Loại bỏ các đại lý đáng tin cậy là một vấn đề cần được giải quyết nếu chúng ta chọn chương trình này.

Trong một bài báo của Blomer et. al, Mười Chữ ký nhóm ngắn với truy xuất nguồn gốc phân tán, Chương trình BBS được mở rộng để hỗ trợ truy xuất nguồn gốc phân tán. Điều này đạt được theo cách sau. Trong sơ đồ BBS, một phần của chữ ký là một mã hóa của (một phần) khóa bí mật và mở số tiền để giải mã bản mã này. Trong bài báo của Blomer họ thay đổi mã hóa thành mã hóa ngưỡng. Mở chữ ký bao gồm hai quy trình, quy trình đầu tiên là tạo ra một chia sẻ mở từ chữ ký và thứ hai là kết hợp một số lượng cổ phần để giải mã lại khóa ký tên. Một sửa đổi khác mà họ thực hiện là thêm một yếu tố bổ sung vào khóa bí mật mà người dùng chỉ biết và không biết đến các cơ quan công bằng. Điều này đảm bảo rằng các cơ quan công bằng không thể ký thay mặt cho các thành viên khác.

Lược đồ của BBS cung cấp ẩn danh CPA. Roughly, điều này có nghĩa là chữ ký là ẩn danh với điều kiện là đối thủ không được truy vấn giao thức chữ ký theo dõi. Tuy nhiên, giả định này không được chứng minh trong cài đặt của chúng tôi vì một kẻ thù có thể tạo ra các thông điệp đã ký và gửi chúng đến blockchain, và sau đó chúng sẽ được theo dõi như một phần của dòng chảy thông thường của chúng tôi. Do đó, chúng tôi yêu cầu lược đồ chữ ký là ẩn danh CCA, điều đó có nghĩa là ngay cả một đối thủ đã truy cập vào giao thức truy tìm mở, cũng không thể theo dõi chữ ký mà không hợp tác với một số ngưỡng của các cơ quan công bằng. Trong bài viết của mình, Truyền thông - chứng minh kiến ​​thức không tương tác hiệu quả với các trình trích xuất trực tuyến, TIẾNG Fischlin giới thiệu một phương pháp để chuyển đổi sơ đồ chữ ký của BBS để bảo mật CCA. Điều này hoạt động bằng cách thêm thành phần vào chữ ký đang tạo ra bằng chứng kiến ​​thức không tương tác về kiến ​​thức cho các giá trị ngẫu nhiên được sử dụng khi mã hóa. Một cách không chính thức, điều này đảm bảo rằng đối thủ không thu được nhiều từ việc tương tác với giao thức truy tìm vì để ký một tin nhắn hợp lệ, cô phải biết các giá trị ngẫu nhiên được sử dụng để tạo mã hóa ở vị trí đầu tiên.

Kích thước chữ ký

Độ dài của sơ đồ chữ ký nhóm BBS theo các tham số được đề xuất bởi các tác giả là 1,533 bit. Điều này tương đương với kích thước của chữ ký RSA, dài 1.024 hoặc 2.048 bit cho các chữ ký có bảo mật tương tự. Thêm truy xuất nguồn gốc phân tán không làm cho chữ ký dài hơn, nhưng phức tạp hơn, nó đòi hỏi phải tính toán nội suy đa thức trễ để kết hợp các cổ phần.

Đối với bằng chứng kiến ​​thức không có bằng chứng về kiến ​​thức, đây là kích thước tương đối lớn và tốn kém để tính toán. Đối với các tham số được đề xuất trong bài báo, độ dài là 3,520 bit, tương đương với tổng chiều dài chữ ký là 5.053 bit.

Kích thước của cổ phiếu chữ ký là 340 bit trên mỗi cổ phiếu.

Tôi muốn cảm ơn Steven Goldfeder vì các cuộc thảo luận hữu ích về chủ đề này.

* Đọc các trang trắng của Orbs: https://www.orbs.com/white- con

Tham gia cộng đồng Orbs:

  • Điện thoại: https://t.me/orbs_network
  • Twitter: https://twitter.com/orbs_network
  • Reddit: https://www.reddit.com/r/ORBS_Network/
  • GitHub: https://github.com/orbs-network