a16z: Ba phương án ưu tiên giải quyết vấn đề cốt lõi của mật mã khóa công khai
Tuyển chọn TechFlowTuyển chọn TechFlow
a16z: Ba phương án ưu tiên giải quyết vấn đề cốt lõi của mật mã khóa công khai
Hiện tại có ba giải pháp: Danh mục khóa công khai, mã hóa dựa trên danh tính (IBE) và mã hóa dựa trên đăng ký (RBE).
Chuyên sâu báo cáo Web3Tác giả: Noemi Glaeser, a16z crypto
Tác giả: Chris, Techub News
Trong mật mã khóa công khai, luôn tồn tại một bài toán khó: làm thế nào để liên kết chính xác khóa mã hóa (như khóa công khai) với một danh tính cụ thể (ví dụ như một cá nhân hoặc tổ chức). Mấu chốt của vấn đề này nằm ở việc cần có một cách thức công khai và nhất quán để thể hiện mối quan hệ giữa danh tính và khóa công khai, nhằm đảm bảo mọi người có thể yên tâm sử dụng các khóa công khai đó để mã hóa thông tin.
Nếu không có mối quan hệ rõ ràng như vậy, người khác sẽ không thể xác định được một khóa công khai cụ thể thuộc về ai, dẫn đến nguy cơ gửi thông tin mã hóa cho người sai, gây rò rỉ thông tin hoặc những hậu quả nghiêm trọng khác. Trong Web3, vấn đề này vẫn tồn tại.
Đối với vấn đề nêu trên, hiện nay có ba giải pháp: Thư mục Khóa Công khai (Public Key Directory), Mã hóa dựa trên Danh tính (IBE), và Mã hóa dựa trên Đăng ký (RBE). Ba phương pháp này mỗi loại đều có ưu điểm riêng về ẩn danh, tương tác và hiệu suất. Ví dụ, IBE yêu cầu nền tảng tin cậy mạnh mẽ, nhưng trong một số trường hợp lại vượt trội hơn về ẩn danh và hiệu suất. Bài viết này nhằm khám phá ứng dụng của ba phương pháp này trên blockchain, đồng thời so sánh ưu nhược điểm của chúng.
Ba phương pháp
Nói chung, phương pháp phổ biến để liên kết khóa mã hóa với thông tin danh tính là sử dụng Hạ tầng khóa công khai (PKI), trong đó phần lõi là một thư mục khóa công khai. Theo phương pháp này, người gửi cần tương tác với bên thứ ba đáng tin cậy (tức là tổ chức duy trì thư mục, thường là cơ quan cấp chứng chỉ) để gửi thông tin mã hóa.
Tuy nhiên, trong môi trường Web2, việc duy trì thư mục khóa công khai đòi hỏi chi phí cao và thao tác phức tạp. Ngoài ra, người dùng còn phải đối mặt với rủi ro cơ quan cấp chứng chỉ có thể lạm dụng quyền lực.
Các nhà mật mã học đã đề xuất một số giải pháp thay thế nhằm khắc phục những vấn đề của PKI. Năm 1984, Adi Shamir đưa ra khái niệm Mã hóa dựa trên Danh tính (IBE), trong đó định danh của một bên (ví dụ như số điện thoại, email hoặc tên miền ENS) có thể trực tiếp được dùng như khóa công khai. Phương pháp này loại bỏ nhu cầu duy trì thư mục khóa công khai, nhưng lại tạo ra một vấn đề mới: phải phụ thuộc vào một bên thứ ba đáng tin cậy (bộ sinh khóa) để tạo ra khóa riêng.
Năm 2001, Dan Boneh và Matthew Franklin đề xuất cấu trúc IBE thực tiễn đầu tiên, nhưng công nghệ này chưa được áp dụng rộng rãi, chủ yếu chỉ được dùng trong một số hệ sinh thái khép kín như doanh nghiệp hay chính phủ. Một trong những lý do khiến IBE chưa được sử dụng phổ biến có lẽ là do nó yêu cầu một giả định tin cậy mạnh – tức là phải tin tưởng bên thứ ba trong việc tạo khóa.
Tuy nhiên, như sẽ thảo luận sau trong bài viết này, vấn đề tin cậy này có thể được giải quyết bằng cách dựa vào một nhóm đáng tin cậy (tức là một nhóm gồm nhiều bên tham gia đạt đủ số lượng tối thiểu), và công nghệ blockchain có thể dễ dàng thực hiện điều này.
Ưu điểm và nhược điểm
Khi so sánh các phương án mã hóa này, cần xem xét nhiều yếu tố khác nhau. Tôi đưa ra hai giả định sau:
Người dùng sẽ không cập nhật hoặc thu hồi khóa của họ: Điều này có nghĩa là trong toàn bộ phân tích, ta giả định rằng khóa của mỗi người dùng là cố định và không thay đổi.
Hợp đồng thông minh không sử dụng bất kỳ dịch vụ sẵn sàng dữ liệu ngoài chuỗi (DAS) hay dữ liệu blob nào: Tức là giả định hợp đồng thông minh hoàn toàn phụ thuộc vào dữ liệu trên chuỗi, không liên quan đến các dịch vụ dữ liệu ngoài chuỗi hay lưu trữ bổ sung.
Thư mục Khóa Công khai (Public Key Directory)
Bất kỳ ai cũng có thể gọi hợp đồng thông minh để thêm một mục ID chưa bị chiếm giữ (id, pk) vào thư mục trên chuỗi.
PKI phi tập trung là việc sử dụng hợp đồng thông minh để duy trì một thư mục ánh xạ giữa danh tính (ID) và khóa công khai tương ứng. Thư mục này là công khai và không phụ thuộc vào bên thứ ba tập trung. Ví dụ, ENS duy trì ánh xạ giữa tên miền (tức là danh tính) và các siêu dữ liệu liên quan, bao gồm địa chỉ mà tên miền trỏ tới (từ các giao dịch của địa chỉ này có thể suy ra khóa công khai). ENS là một hệ thống phức tạp hơn, không chỉ lưu trữ khóa công khai mà còn chứa nhiều siêu dữ liệu khác. PKI phi tập trung đơn giản hơn về chức năng: hợp đồng thông minh chỉ cần duy trì một danh sách ghi lại khóa công khai tương ứng với mỗi danh tính.
Khi người dùng muốn đăng ký danh tính, trước tiên họ cần tạo một cặp khóa (khóa công khai và khóa riêng), hoặc sử dụng cặp khóa đã có, rồi gửi ID danh tính và khóa công khai đến hợp đồng thông minh (có thể kèm theo phí). Hợp đồng thông minh sẽ kiểm tra xem ID này đã được đăng ký bởi người khác hay chưa. Nếu chưa, hợp đồng sẽ thêm ID và khóa công khai vào thư mục. Sau khi đăng ký thành công, bất kỳ ai cũng có thể hỏi hợp đồng thông minh để lấy khóa công khai tương ứng với một ID nhất định, từ đó mã hóa và gửi tin nhắn cho người dùng đó. Nếu người gửi đã từng mã hóa tin nhắn cho người nhận này trước đó và đã có khóa công khai của họ, thì không cần yêu cầu lại từ hợp đồng thông minh. Sau khi có khóa công khai, người gửi có thể sử dụng nó để mã hóa tin nhắn như bình thường, rồi gửi bản mã đến người nhận, người nhận sẽ dùng khóa riêng tương ứng để giải mã và khôi phục văn bản gốc.
Hãy cùng xem xét ưu điểm và nhược điểm của phương pháp này:
Mã hóa dựa trên Danh tính (IBE)
Danh tính của người dùng được biểu thị bằng khóa công khai của họ, tức là khóa công khai không chỉ dùng để mã hóa mà còn đóng vai trò là định danh duy nhất của người dùng. Tuy nhiên, phương pháp này cần dựa vào một hoặc nhiều bên thứ ba đáng tin cậy, chịu trách nhiệm tạo và phát hành khóa. Ngoài ra, các bên này còn phải bảo quản một khóa chính trong suốt vòng đời hoạt động của hệ thống, khóa này trong một số trường hợp có thể được dùng để giải mã hoặc các thao tác quan trọng khác.
Trong hệ thống IBE, người dùng không tự tạo cặp khóa công khai - khóa riêng như trong các hệ mã hóa truyền thống. Thay vào đó, người dùng cần đăng ký thông qua một bộ sinh khóa đáng tin cậy. Bộ sinh khóa sở hữu một cặp khóa chính (gồm khóa riêng chính msk và khóa công khai chính mpk). Khi người dùng cung cấp ID của mình, bộ sinh khóa sẽ dùng khóa riêng chính msk và ID để tính toán ra khóa riêng dành riêng cho người dùng đó. Khóa riêng vừa tạo cần được chuyển đến người dùng qua một kênh an toàn, thường là thông qua giao thức trao đổi khóa để thiết lập kênh bảo mật này.
Đối với người gửi, hệ thống IBE đơn giản hóa quá trình mã hóa. Người gửi chỉ cần tải về khóa công khai chính (mpk) của bộ sinh khóa một lần, sau đó có thể dùng ID để mã hóa tin nhắn. Đối với người nhận, việc giải mã cũng rất đơn giản. Người dùng đã đăng ký có thể dùng khóa riêng do bộ sinh khóa cấp để giải mã bản mã nhận được.
Khóa riêng chính (msk) của bộ sinh khóa phải được lưu giữ lâu dài, vì trong suốt thời gian hệ thống hoạt động, nó cần liên tục tạo khóa riêng cho người dùng mới. Điều này khác với một số hệ thống SNARK, nơi khóa được tạo ra trong quá trình thiết lập đáng tin cậy, nhưng có thể bị hủy sau khi thiết lập xong. Trong hệ thống IBE, khóa riêng chính không thể bị xóa sau khởi tạo như trong SNARK.
Ngay cả khi khóa riêng chính (msk) được bảo quản tốt, mỗi người dùng đăng ký vẫn phải tin rằng bộ sinh khóa sẽ không đọc tin nhắn của họ. Bởi vì bộ sinh khóa có thể lúc nào cũng lưu một bản sao khóa riêng của người dùng, hoặc dùng khóa riêng chính để tính lại khóa riêng của người dùng.
Bộ sinh khóa thậm chí có thể cấp cho người dùng một khóa riêng có vấn đề hoặc bị hạn chế, loại khóa này có thể giải mã phần lớn tin nhắn nhưng không thể giải mã một số tin nhắn cụ thể do bộ sinh khóa quy định. Điều này có nghĩa là bộ sinh khóa có khả năng kiểm soát năng lực giải mã của người dùng, từ đó có thể kiểm soát hoặc hạn chế giao tiếp của người dùng ở mức độ nào đó.
Mã hóa dựa trên Đăng ký (RBE)
Giống như IBE, trong hệ thống này, danh tính của người dùng (ví dụ như địa chỉ email hoặc số điện thoại) trực tiếp đóng vai trò là khóa công khai của họ. Nhưng khác với IBE, hệ thống này không còn phụ thuộc vào một bên thứ ba đáng tin cậy hay một nhóm quorum để quản lý khóa. Thay vào đó, bên thứ ba đáng tin cậy này được thay thế bằng một "người quản lý khóa" (key curator).
Tôi sẽ thảo luận về một cách xây dựng RBE hiệu quả trong phần này, vì theo tôi biết, đây là phương pháp có lợi thế nổi bật so với các cấu trúc RBE thực tiễn khác: nó có thể triển khai trên blockchain do sử dụng phép ghép cặp (pairing-based), chứ không phải dựa trên lưới (lattice-based).
Trong hệ thống RBE, mỗi người dùng tự tạo một cặp khóa (gồm khóa công khai và khóa riêng). Người dùng cũng cần dựa trên khóa riêng và một chuỗi tham chiếu công khai (CRS) để tính toán một số giá trị cập nhật (trong hình được đánh dấu là a). Các giá trị cập nhật này dùng cho các thao tác tiếp theo trong hệ thống. Sự tồn tại của chuỗi tham chiếu công khai (CRS) có nghĩa là thiết lập hệ thống không hoàn toàn không cần tin cậy. Tuy nhiên, CRS có thể được tạo ra thông qua một phương pháp gọi là "lũy thừa của tau", có thể thực hiện trên chuỗi thông qua sự hợp tác tính toán của nhiều bên tham gia. Miễn là có ít nhất một bên trung thực, CRS này sẽ an toàn.
Hợp đồng thông minh được thiết lập cho một số lượng người dùng dự kiến N, những người này được chia nhóm vào các bucket khác nhau. Khi người dùng đăng ký vào hệ thống, họ cần gửi ID danh tính, khóa công khai và các giá trị cập nhật đến hợp đồng thông minh. Hợp đồng thông minh duy trì một tập tham số công khai pp, khác với chuỗi tham chiếu công khai (CRS) đã nêu. Có thể hiểu pp là bản tóm tắt ngắn gọn của tất cả các khóa công khai của người dùng đã đăng ký trong hệ thống. Khi nhận được yêu cầu đăng ký, hợp đồng thông minh sẽ kiểm tra các giá trị cập nhật để xác minh tính đúng đắn. Sau khi xác minh thành công, hợp đồng sẽ nhân khóa công khai của người dùng vào bucket tương ứng trong pp. Bước này tương đương với việc đưa khóa công khai của người dùng mới vào tập tham số công cộng của hệ thống để sử dụng cho các thao tác sau này.
Trong hệ thống Mã hóa dựa trên Đăng ký (RBE), người dùng cần lưu trữ cục bộ một số thông tin hỗ trợ việc giải mã. Khi có người dùng mới đăng ký vào cùng nhóm với họ, thông tin này cần được cập nhật. Người dùng có thể tự giám sát blockchain để cập nhật thủ công, hoặc hợp đồng thông minh có thể cung cấp thông tin về người dùng mới đăng ký gần đây, và người dùng có thể định kỳ lấy thông tin này để giữ cho dữ liệu giải mã luôn cập nhật.
Trong hệ thống này, người gửi chỉ cần làm hai việc:
Tải về chuỗi tham chiếu công khai (CRS): Việc này chỉ cần thực hiện một lần, sau đó không cần cập nhật nữa.
Tải về tham số công khai: Người gửi cần định kỳ tải về phiên bản mới nhất của tham số công khai. Điều quan trọng là tham số công khai phải chứa khóa công khai của người nhận; tuy nhiên, người gửi không cần tải phiên bản mới nhất mỗi lần, miễn là tìm thấy khóa công khai của người nhận là được.
Sau đó, người gửi sử dụng CRS đã tải, tham số công khai và ID danh tính của người nhận để mã hóa tin nhắn và gửi cho người nhận. Điều này có nghĩa là người gửi không cần cập nhật dữ liệu thường xuyên, chỉ cần đảm bảo tham số công khai có chứa khóa công khai của người nhận.
Khi người dùng nhận được một tin nhắn đã mã hóa, họ trước tiên sẽ kiểm tra thông tin hỗ trợ được lưu trữ cục bộ, xem có giá trị nào thỏa mãn điều kiện nhất định (ví dụ như vượt qua một kiểm tra xác thực nào đó) hay không. Nếu không tìm thấy giá trị phù hợp, điều đó có nghĩa là họ cần lấy thông tin cập nhật mới nhất từ hợp đồng thông minh. Khi tìm được giá trị hỗ trợ phù hợp, họ có thể dùng giá trị đó cùng với khóa riêng của mình để giải mã bản mã và khôi phục tin nhắn gốc.
Rõ ràng, phương án này phức tạp hơn hai phương án kia. Tuy nhiên, nó yêu cầu dung lượng lưu trữ trên chuỗi ít hơn so với thư mục khóa công khai, đồng thời tránh được giả định tin cậy mạnh của IBE.
Tham số gọn nhẹ:
Kích thước tham số được lưu trên chuỗi tăng dưới tuyến tính theo số lượng người dùng, nhỏ hơn nhiều so với lưu trữ tuyến tính của thư mục khóa công khai, mặc dù vẫn không phải hằng số, do đó vẫn kém hơn hệ thống IBE về mặt này.
Mã hóa có một mức độ tương tác nhất định:
Khi gửi tin nhắn, người gửi cần một bản sao tham số công khai chứa khóa của người nhận mục tiêu. Điều này có nghĩa là người gửi cần cập nhật tham số này tại một thời điểm nào đó sau khi người nhận đăng ký, nhưng không cần cập nhật riêng cho từng người nhận, vì một lần cập nhật có thể chứa khóa của nhiều người nhận. Nhìn chung, mức độ tương tác khi gửi tin nhắn cao hơn IBE nhưng thấp hơn so với dùng thư mục khóa công khai.
Giải mã có một mức độ tương tác nhất định:
Giống như mã hóa, người nhận cần một thông tin hỗ trợ khớp với phiên bản tham số công khai được dùng khi mã hóa. Khi có người dùng mới đăng ký vào cùng một nhóm, tham số công khai và thông tin hỗ trợ sẽ được cập nhật; giá trị có thể giải mã bản mã tương ứng với phiên bản tham số công khai được dùng khi mã hóa. Người dùng có thể chọn lấy cập nhật thông tin hỗ trợ định kỳ thay vì cập nhật ngay lập tức mỗi lần, trừ khi việc giải mã thất bại. Khác với cập nhật tham số công khai, việc lấy cập nhật thông tin hỗ trợ thường xuyên hơn sẽ không làm rò rỉ thông tin riêng tư.
Người gửi ẩn danh:
Giống như trường hợp thư mục khóa công khai, người gửi có thể mã hóa độc lập (miễn là có tham số mới nhất), mà không cần truy vấn thông tin cụ thể liên quan đến người nhận. Khi người gửi cần đọc thông tin từ chuỗi, những thông tin này không liên quan đến người nhận mục tiêu (trừ khi người gửi chỉ yêu cầu một nhóm tham số cụ thể, điều này có thể tiết lộ một phần thông tin).
Minh bạch:
Mặc dù hệ thống cần một thiết lập đáng tin cậy (có thể phân tán hoặc quản lý bên ngoài) để tạo ra CRS (chuỗi tham chiếu công khai) đã được hiệu chỉnh, nhưng một khi thiết lập xong, nó không còn phụ thuộc vào bất kỳ bên thứ ba đáng tin cậy hay nhóm trọng tài nào. Dù phụ thuộc vào một bên thứ ba phối hợp (hợp đồng thông minh), hệ thống hoàn toàn minh bạch: bất kỳ ai cũng có thể đóng vai trò phối hợp hoặc kiểm tra tính trung thực của hệ thống thông qua xác minh chuyển đổi trạng thái (đây cũng là lý do nó có thể được triển khai dưới dạng hợp đồng thông minh). Ngoài ra, người dùng có thể yêu cầu một bằng chứng gọn nhẹ về (không) thành viên để kiểm tra xem họ hoặc người khác đã đăng ký vào hệ thống hay chưa. Điều này khác với hệ thống IBE, nơi rất khó để yêu cầu bên thứ ba đáng tin cậy chứng minh rằng họ không bí mật tiết lộ khóa giải mã (ví dụ như lưu bản sao bí mật hoặc tiết lộ cho người khác). Trong khi đó, thư mục khóa công khai là hoàn toàn minh bạch.
Tập hợp ID bị giới hạn:
Phiên bản RBE mô tả ở đây là dạng cơ bản. Để xác định minh bạch nhóm nào mà một ID thuộc về, ID phải có thứ tự công khai và xác định. Số điện thoại có thể được sắp xếp đơn giản, nhưng việc sắp xếp chuỗi ký tự tùy ý có thể rất phức tạp hoặc thậm chí không thể, do số lượng nhóm có thể rất lớn hoặc vô hạn. Điều này có thể được giảm nhẹ bằng cách cung cấp một hợp đồng riêng biệt để tính ánh xạ này, hoặc áp dụng phương pháp cuckoo-hashing được đề xuất trong các nghiên cứu sau.
Người nhận ẩn danh:
Phương pháp này cho phép bản mã không tiết lộ danh tính người nhận.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
a16z
