Chúng tôi đề xuất một giải pháp cho phép người dùng Internet chứng minh quyền kiểm soát các tài khoản web thực (như Uber hoặc GitHub) bằng MPC-TLS mà không tiết lộ bất kỳ dữ liệu cá nhân nào. Bằng cách chuyển đổi các thông tin đăng nhập này thành các bằng chứng nhóm zero-knowledge không thể liên kết, chúng tôi có thể mở khóa Airdrop kháng Sybil, quản trị và kiểm soát truy cập mà không ảnh hưởng đến quyền riêng tư của người dùng.
Tổng quan Giao thức:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐│ Trình duyệt │ │ TLS Notary │ │ Dịch vụ Web ││ Tiện ích mở rộng │ │ │ │ (ví dụ: Uber) │└─────────────────┘ └─────────────────┘ └─────────────────┘│ │ ││←──── Giao thức MPC ───→│ ││ │ ││←──────── Phiên MPC-TLS─────────────────────→││ (máy khách chung) ││ │ ││──── Mã hóa TLS ───→│ ││ bản ghi │ ││ │ ││←─── Chứng nhận ─────┤ ││ (mạch rào) │ ││ │ │▼┌─────────────────┐│ Semaphore ││ Nhóm ││ Cam kết │└─────────────────┘Giao thức hoạt động như sau (được đơn giản hóa để rõ ràng):
Giai đoạn 1: Xác minh Thông tin Đăng nhập Riêng tư
- Tiện ích mở rộng trình duyệt của người dùng và TLS Notary thiết lập phiên MPC-TLS với dịch vụ web
- Notary xác nhận tính toàn vẹn của văn bản mã hóa bằng mạch rào, ký chứng nhận trên các trường đã cam kết
- Notary chỉ thấy dữ liệu được mã hóa - không bao giờ thông tin tài khoản dạng văn bản thuần
- Người dùng nhận bằng chứng mật mã về thông tin đăng nhập mà không tiết lộ chi tiết tài khoản
Giai đoạn 2: Tạo Cam kết Không thể Liên kết
cam kết = Hash(khóa_chính || id_nhóm_thông_tin_đăng_nhập || hash_id_tài_khoản)- Người dùng tạo cam kết danh tính không thể liên kết bằng Khóa Chính riêng
- Cam kết được công bố tới nhóm Semaphore tương ứng (thông tin đăng nhập GitHub → nhóm GitHub, v.v.)
- Mỗi loại thông tin đăng nhập ánh xạ tới nhóm riêng, cho phép nhắm mục tiêu bằng chứng chi tiết
Giai đoạn 3: Cung cấp Bằng chứng Nhóm Zero-Knowledge
- Để xác minh, người dùng tạo các bằng chứng ZK về tư cách thành viên nhóm Semaphore
- Các bằng chứng xác nhận việc sở hữu thông tin đăng nhập mà không tiết lộ các tài khoản cụ thể
- Các bên xác minh có thể kết hợp nhiều bằng chứng nhóm để tạo điểm tin cậy có thể ghép
Bảo đảm Quyền riêng tư:
- Không thể liên kết: Không thể kết nối các tài khoản web khác nhau với cùng một người dùng
- Ẩn danh theo nhóm: Các xác minh cá nhân không tiết lộ thành viên cụ thể nào trong nhóm thông tin đăng nhập đang tạo bằng chứng
- Không thể truy vết: Không thể theo dõi người dùng trên các ứng dụng khác nhau
- Có thể ghép: Có thể chứng minh tư cách thành viên trong nhiều nhóm đồng thời
Triển khai
Chúng tôi đang xây dựng BringID để xác thực các kỹ thuật mật mã này trong thực tế. Việc triển khai tận dụng cơ sở hạ tầng hiện có (TLSN cho MPC-TLS, Semaphore cho các bằng chứng nhóm ZK) để giảm thiểu các giả định mật mã mới.
Thiết kế hiện tại giả định một TLS Notary đáng tin cậy để xác minh chứng nhận. Chúng tôi đang khám phá các cách tiếp cận phi tập trung khác nhau để giảm thiểu yêu cầu tin cậy này trong tương lai, bao gồm cơ sở hạ tầng được hỗ trợ bởi TEE và các mạng xác thực phân tán.
Mô hình An ninh Kinh tế
Phương pháp của chúng tôi không ngăn chặn về mặt mật mã các Sybil - nó khiến chúng trở nên không khả thi về mặt kinh tế. Giả định an ninh là:
Giá trị phần thưởng trên mỗi tài khoản được xác minh < Chi phí tạo ra một danh tính Sybil
Các tài khoản web yêu cầu hoạt động trong thế giới thực (chuyến đi Uber, commit GitHub, lưu trú Airbnb), đầu tư thời gian (tuổi tài khoản, xây dựng uy tín) và thường có chi phí tiền tệ (phí sử dụng dịch vụ). Các ứng dụng có thể kết hợp nhiều nhóm thông tin đăng nhập và áp dụng xác minh có giới hạn thời gian để tăng thêm chi phí giả mạo.
Thông số kỹ thuật: Sách trắng dự thảo
Công trình Liên quan: TLSN | Semaphore
