Điểm:2

Câu hỏi về bảo mật độc hại trong giao thức sử dụng OT

lá cờ cn

Tôi đang nghiên cứu một giao thức sử dụng OT và đột nhiên tôi nhận ra rằng tôi không thể tưởng tượng được làm thế nào một giao thức sử dụng OT có thể an toàn độc hại.

Giả sử chúng ta có một giao thức P sử dụng OT làm giao thức con. Giả sử rằng OT được sử dụng $N$ lần. Mỗi OT có đầu vào $x_{0,i}$, $x_{1,i}$, ở đâu $i$ biểu thị $i-$thứ của Cựu ước, từ 1 đến $N$. Thật hợp lý khi giả sử rằng, đối với mọi thời điểm, người nhận chọn bit $0$ hoặc $1$ theo đầu vào của nó (ví dụ đây là trường hợp của giao thức Yao, trong đó đối với mỗi cổng, người nhận yêu cầu 0 nếu đầu vào của nó là 0 hoặc 1 nếu ngược lại).

Bây giờ giả sử rằng người gửi trong OT là độc hại và quyết định thay đổi $x_{0,N}$ với một cái gì đó khác. Nó có thể là một giá trị ngẫu nhiên, giá trị $x_{1,N}$ hay bất cứ cái gì. Chúng tôi có ba khả năng

  1. Giao thức hủy bỏ. Sau đó, người gửi biết rằng trong OT cuối cùng, người nhận đã yêu cầu 0.
  2. Giao thức không bị hủy bỏ và đầu vào thực sự chính xác. Người gửi hiện biết rằng trong OT cuối cùng, người nhận đã yêu cầu 1.
  3. Giao thức không bị hủy bỏ, đầu vào sai và các bên có thể phát hiện ra nó. Người gửi bây giờ biết rằng trong OT cuối cùng, người nhận đã yêu cầu 0.
  4. Giao thức không hủy bỏ, đầu vào sai nhưng các bên không thể phát hiện ra. Sau đó, người gửi có thể tùy ý tạo giao thức để xuất các giá trị khác với giá trị được chỉ định.

Nếu hành vi là một trong ba hành vi đầu tiên, người gửi có thể thay đổi mọi OT theo cách này và nó có $\frac{1}{2^N}$ xác suất học tất cả các yêu cầu mà không bị phát hiện, vì $N$ là một tham số cố định không phải là không đáng kể (thậm chí còn hơn thế nếu $N$ nhỏ). Trong các trường hợp khác, người nhận biết rằng người gửi là độc hại nhưng điều này không ngăn cản người nhận tìm hiểu điều gì đó.

Nếu đây là hành vi cuối cùng thì tôi không hiểu làm thế nào một giao thức như vậy có thể được coi là "an toàn", vì kẻ tấn công rất dễ thực hiện một cuộc tấn công "DoS", trong đó mọi đầu ra đều vô nghĩa.

Trong trường hợp của giao thức Yao, giả sử rằng người gửi đặt OT cuối cùng $X_{0,N}, X_{0,N}$. Làm thế nào chúng ta có thể ngăn chặn điều đó? Nếu giao thức "gặp sự cố" thì người gửi biết rằng bit cuối cùng của Bob là 0. Nó rất lớn, phải không?

Và tôi không xem xét trường hợp đối xứng: điều gì xảy ra nếu người nhận thay vì hỏi theo quy tắc, lại hỏi một cách ngẫu nhiên? Theo như tôi có thể hiểu thì hành vi này không được xem xét trong quá trình chứng minh bảo mật, tôi có sai không?

Tui bỏ lỡ điều gì vậy? Có phải những cân nhắc này nằm ngoài phạm vi và chúng tôi cho phép loại hành vi này? Có lẽ chúng ta cho rằng người gửi luôn đặt $x_0$$x_1$ đúng cách?

Điểm:1
lá cờ us

Có rất nhiều câu hỏi được gói gọn ở đây -- trả lời đầy đủ tất cả các câu hỏi đó sẽ yêu cầu một hướng dẫn đầy đủ về MPC bảo mật độc hại. Tôi sẽ cố gắng chỉ tập trung vào bức tranh lớn.

Nói chung, nếu có một "giá trị chính xác" mà người gửi OT "được cho là" sử dụng làm đầu vào OT, thì vâng, giao thức phải rất cẩn thận. Thông thường có một "giá trị chính xác" vì bất kỳ giá trị nào khác sẽ khiến người nhận hủy bỏ. Vì vậy, các giá trị "không chính xác" trong OT sẽ khiến việc hủy bỏ xảy ra dựa trên đầu vào OT của người nhận - làm rò rỉ thông tin về các đầu vào OT đó!

Có một số cách để giải quyết vấn đề này. Dưới đây là những điều dễ hiểu nhất:

  • Giao thức 2PC mạch bị cắt xén cổ điển của Lindell-Pinkas 2007 làm như sau. Giả sử chúng tôi thực sự muốn thực hiện OT để chọn một trong hai nhãn dây $x_0, x_1$ dựa trên đầu vào mạch của máy thu $b$. Giả sử người nhận có thể kiểm tra xem nhãn dây có hợp lệ hay không. Khi người nhận hủy bỏ do nhìn thấy nhãn dây không hợp lệ, nó sẽ làm rò rỉ đầu vào mạch của họ! Lindell & Pinkas giải quyết vấn đề này bằng cách sửa đổi mạch bị cắt xén để người nhận nhập thông tin chia sẻ bí mật $b = b_1 \oplus \cdots \oplus b_\lambda$ của đầu vào thực sự của nó $b$. Mạch bị cắt xén sau đó sẽ XOR những chia sẻ này để phục hồi $b$ và sau đó tiến hành như bình thường. Vì vậy, bây giờ thay vì một OT cho dây đầu vào mạch này, có $\lambda$ OT vì chúng tôi đã tăng số lượng đầu vào mạch một cách giả tạo. Giả sử người gửi OT gian lận trong lần đầu tiên $k < \lambda$ OT. Đầu vào của người nhận cho những đầu tiên này $k$ OT là một tập hợp các chia sẻ bí mật, nhưng ít hơn số lượng chia sẻ ngưỡng, vì vậy chúng được phân phối độc lập với đầu vào riêng $b$! Trong trường hợp này, người nhận sẽ đơn giản hủy bỏ với xác suất $1 - 2^{-k}$, độc lập với đầu vào của họ. Nếu người gửi OT gian lận trong tất cả $\lambda$ OT, sau đó người nhận hủy bỏ với xác suất 1 hoặc $1-2^{-\lambda}$, với xác suất phụ thuộc vào đầu vào riêng tư của họ! -- nhưng vì chúng gần như không đáng kể, nó không thực sự cấu thành sự rò rỉ thông tin.

  • Giao thức ZK của Jawurek, Kerschbaum, Orlando cũng dựa trên các mạch bị cắt xén. Họ thực hiện OT điển hình của nhãn dây, trong đó đầu vào của bộ thu OT là nhân chứng ZK riêng của họ. Họ cẩn thận cấu trúc giao thức để người gửi OT có thể tiết lộ công khai cả hai của các đầu vào OT của nó tại một thời điểm sau đó --- điều này yêu cầu một biến thể của OT được gọi là "OT đã cam kết". Về cơ bản, người xác minh tính toán một số "câu trả lời cuối cùng" về mạch bị cắt xén, làm rò rỉ thông tin về đầu vào riêng tư của họ nếu có bất kỳ gian lận nào trong OT. Vì vậy, thay vì chỉ gửi câu trả lời cuối cùng này, nó cam kết với nó. Sau đó, người gửi OT tiết lộ tất cả các đầu vào OT của mình để chứng minh rằng không có gian lận. Nếu người nhận OT bị thuyết phục, thì họ có thể đưa ra cam kết của riêng mình về "câu trả lời cuối cùng".

  • Đôi khi bạn có thể thiết kế giao thức để không xảy ra trường hợp đầu vào OT không chính xác. Đây là một cách đơn giản để kiểm tra xem hai chuỗi riêng tư $x = x_1 \cdots x_n$$y = y_1 \cdots y_n$ bằng nhau (lấy cảm hứng từ giao thức PSI của Pinkas-Schneider-Zohner). Chạy $n$ OTS của các giá trị ngẫu nhiên, vì vậy $i$OT có đầu vào $r_{i,0}$$r_{i,1}$. Bộ thu OT sử dụng các bit đầu vào của chúng $x$ dưới dạng bit lựa chọn OT và tìm hiểu các giá trị của biểu mẫu $r_{i, x_i}$. Họ có thể tính giá trị $R_x = H(x, r_{1,x_1}, r_{2,x_2}, \ldots, r_{n,x_n} )$, ở đâu $H$ là một lời tiên tri ngẫu nhiên. Người gửi OT có đầu vào riêng của họ $y$, và biết tất cả các $r_{i,b}$ các giá trị. Vì vậy, họ có thể tính toán một giá trị $R_y = H( y, r_{1,y_1}, r_{2,y_2}, \ldots, r_{n,y_n} )$ và gửi nó đến người nhận OT. Nếu $R_x = R_y$ sau đó $x$$y$ bằng nhau; nếu không thì $x$$y$ khác nhau (và $R_y$ trông ngẫu nhiên đối với người nhận). Làm thế nào một người gửi OT bị hỏng có thể gian lận? Họ có thể gửi $H$ của một số khác thứ (tức là, bao gồm một cái gì đó không bằng bất kỳ $r_{i,b}$ làm đầu vào cho $H$). Nhưng điều đó sẽ đơn giản Bảo hành rằng người nhận sẽ kết luận "các chuỗi không khớp" -- không có vấn đề gì $x$ họ nắm giữ. Điều này rất dễ dàng cho trình mô phỏng xử lý.

Vì vậy, chúng tôi có ba cách tiếp cận cấp cao khác nhau cho vấn đề bạn đã hỏi:

  • Giao thức này sắp xếp để các bit lựa chọn OT của người nhận độc lập hiệu quả với dữ liệu riêng tư của họ --- vì vậy nếu gian lận dẫn đến hủy bỏ, xác suất hủy bỏ đó không phụ thuộc vào đầu vào riêng của người nhận OT.

  • Người nhận OT được cung cấp một cách để phát hiện hành vi gian lận để có thể dừng giao thức trước khi có thể nhìn thấy bất kỳ hậu quả xấu nào của hành vi gian lận.

  • Các phần khác của giao thức không có bất kỳ hậu quả xấu nào nếu người gửi OT chọn hành động không nhất quán với đầu vào OT của họ.

Chắc chắn cũng có những cách tiếp cận thông minh khác, nhưng đây là những cách đầu tiên tôi nghĩ đến.

điều gì xảy ra nếu người nhận thay vì hỏi theo quy tắc, lại hỏi ngẫu nhiên? Theo như tôi có thể hiểu thì hành vi này không được xem xét trong quá trình chứng minh bảo mật, tôi có sai không?

Trong hầu hết các giao thức dựa trên OT, các bit lựa chọn OT của máy thu là mã hóa trực tiếp đầu vào của chúng cho giao thức chính. Đó chắc chắn là trường hợp trong 3 ví dụ trên. Việc sử dụng các bit lựa chọn OT "sai" hoàn toàn tương đương với việc chọn một đầu vào khác cho giao thức chính và đây không được coi là một cuộc tấn công nhằm bảo mật độc hại.

miky avatar
lá cờ cn
Ồ, cảm ơn bạn rất nhiều. Điểm đầu tiên và thứ hai dường như trả lời câu hỏi của tôi. Tuy nhiên, tôi không hiểu điều thứ ba, có vẻ như nó có cùng một vấn đề. Người gửi OT có thể đặt đầu vào OT là ri0=ri1 (hoặc thứ gì đó thông minh hơn). Vì vậy, nó có thể buộc giao thức xuất ra sai, rơi vào điểm thứ tư trong thông báo ban đầu của tôi. Và có vẻ như không có cách nào để cho phép người nhận kiểm tra xem cả hai ri có đúng hay không. Tôi sẽ tìm giải pháp thứ nhất và thứ hai! Cảm ơn rât nhiều
lá cờ us
Trong giao thức kiểm tra đẳng thức, tôi bao gồm chuỗi $y$ trong hàm băm, để ngay cả khi tất cả $r_{i,0} = r_{i,1}$, các $y$ khác nhau vẫn dẫn đến các giá trị $R_y$ khác nhau . Nếu $n$ (độ dài của chuỗi) đủ dài, thì đó không phải là một cuộc tấn công để "buộc giao thức xuất sai" vì bạn cũng có thể đạt được điều đó trong thế giới lý tưởng (bằng cách chọn một đầu vào ngẫu nhiên).
miky avatar
lá cờ cn
Vâng, đó là những gì tôi đã nói. Đối với tôi, có vẻ lạ là trong một giao thức như vậy, nó không được "bao gồm" trong định nghĩa bảo mật mà đối thủ phải sử dụng đầu vào của chính nó chứ không phải thứ gì khác. Tôi đoán nó là không thể, nhưng vẫn lạ. Cảm ơn bạn
lá cờ us
Không có thứ gọi là "đầu vào chính xác" cho một bên độc hại. Trong thế giới lý tưởng, một bên độc hại có thể gửi bất kỳ thứ gì làm đầu vào cho chức năng lý tưởng. Đó chỉ là một phần của định nghĩa MPC tiêu chuẩn cho các đối thủ độc hại.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.