Làm thế nào bạn có thể buộc một bên phải trung thực (tuân theo các quy tắc giao thức)?
Tôi đã thấy một số cơ chế như cam kết, bằng chứng, v.v., nhưng đơn giản là chúng dường như không giải quyết được toàn bộ vấn đề. Dường như với tôi rằng cấu trúc của thiết kế giao thức và các cơ chế như vậy phải thực hiện công việc. Có ai có một phân loại tốt về điều đó.
Chỉnh sửa
Khi thiết kế các giao thức bảo mật, nếu bạn buộc một bên phải trung thực, thiết kế sẽ dễ dàng hơn nhiều mặc dù việc thực thi này có phần thưởng riêng. Tôi đã thấy khi thiết kế các giao thức bảo mật, các nhà thiết kế giả định một cái gì đó không thực tế đối với tôi, ví dụ như giả sử tất cả các bên trung thực trong trường hợp xấu nhất hoặc giả sử sự trung thực của máy chủ duy trì dữ liệu người dùng. Nhưng khi nhìn vào thiết kế các giao thức trong các mô hình chặt chẽ hơn, bạn hiếm khi thấy các giả định như vậy (ít nhất là tôi chưa thấy nó - tôi chủ yếu nghiên cứu các giao thức quaKhung UC của Canetti mà tôi nghĩ nó chưa hoàn toàn chính thức). Tôi đã tự hỏi, có sự phân loại tốt nào về những cách mà bạn có thể buộc một bên phải trung thực hay có trình biên dịch nào có thể chuyển đổi giao thức đầu vào thành một bên với các bên trung thực không?
Bây giờ tôi sẽ giải thích lý do tại sao tôi nghĩ rằng điều này chỉ không làm công việc mặc dù nó có vẻ không liên quan. Khi thiết kế các giao thức trong khung UC, được hưởng lợi từ mô hình lý tưởng / thực tế, mọi liên kết giao tiếp trong mô hình lý tưởng đều được xác thực, điều này không đúng trong mô hình thực. Vì vậy, các nhà thiết kế giao thức tìm kiếm các phương pháp thay thế để thực hiện kênh này thông qua giả định PKI hoặc CRS (Chuỗi tham chiếu chung). Nhưng khi thiết kế các giao thức xác thực, giả sử các kênh xác thực là sai. Giả sử rằng chúng ta đang thiết kế một giao thức xác thực trong khung UC, có một cuộc tấn công trong đó đối thủ giả mạo danh tính của một bên, nhưng do giả định các liên kết được xác thực trong mô hình lý tưởng mà cuộc tấn công này không được giả định trong khung này! Bạn có thể tham khảoMô hình hóa các cuộc tấn công nội bộ trên các giao thức trao đổi khóa nhóm . Bạn có thể nhận thấy rằng Canetti trong công việc bán kết của mình Các khái niệm có thể kết hợp toàn diện về trao đổi khóa và các kênh bảo mật đề cập đến một khái niệm bảo mật trước đây gọi là SK-Security, đơn giản là đủ để đảm bảo an toàn cho các giao thức xác thực. Ông bằng cách nào đó thú nhận (bằng cách nói rằng đây là vấn đề kỹ thuật) rằng định nghĩa của UC trong bối cảnh này quá hạn chế và cung cấp một biến thể thoải mái được gọi là nhà tiên tri phi thông tin (khiến tôi bối rối, vì tôi chưa thấy mô hình bảo mật này ở đâu , Tôi không thể kết hợp mẫu bảo mật này với bất kỳ mẫu bảo mật nào khác, có thể là sự thiếu hiểu biết của tôi: D).
[Là một lưu ý phụ, Bạn gần như có thể có bất kỳ giao thức Sk-safe nào được chuyển đổi thành giao thức bảo mật UC bất kể thời gian giả lập. Chẳng hạn, bạn chỉ có thể xóa các bản hợp đồng của tin nhắn và giả lập mô phỏng toàn bộ các tương tác theo cách giả. Xem bằng chứng trao đổi khóa nhóm đóng góp toàn cầu để chứng minh! Bây giờ giả sử đây là một giao thức trao đổi khóa nhóm với nhiều bên, thì hiệu quả của trình giả lập là gì ?? Đây là nguồn gốc của câu hỏi khác của tôi trong diễn đàn này .]
Dù sao, do thiếu sự cam kết trong mô hình đơn giản (trên UC), tôi đã tìm kiếm các phương tiện khác để làm cho giao thức được an toàn bằng cách bỏ qua nhu cầu thư giãn đó. Ý tưởng này rất cơ bản trong đầu tôi và đã nảy ra trong đầu tôi khi chỉ nghiên cứu sơ đồ cam kết mới nhất của canetti trong mô hình đơn giản: Độ cứng thích ứng và Bảo mật có thể kết hợp trong Mô hình Đồng bằng từ Giả định Chuẩn .
BTW, tôi không tìm kiếm bằng chứng không có kiến thức vì lý do mà tôi không biết, bất cứ khi nào ai đó sử dụng một trong số chúng trong giao thức đồng thời (trên khung UC), những người khác đã đề cập đến giao thức là không hiệu quả (có thể là do tua lại của trình giả lập).