Chứng minh rằng một giao thức không thể bị tấn công

Hãy xem xét giao thức sau:

1. $A\rightarrow B: \{N_A,A\}_{pk(B)}$

2. $B\rightarrow A: \{N_B,N_A\}_{pk(A)}$

3. $A\rightarrow B: hàm băm(N_B, A, B)$

nơi dự định rằng khi một trong hai $A$ hoặc $B$ đã hoàn thành vai trò của mình trong giao thức, họ yên tâm rằng người kia đã tham gia vào giao thức với họ và rằng $N_A$ và $N_B$ là các nonce ngẫu nhiên được tạo bởi $A$ và $B$. $\{X\}_{Y}$ có nghĩa là $X$ được mã hóa dưới khóa $Y$.

Tôi biết một thực tế là không có cuộc tấn công nào đối với giao thức này nhưng tôi không chắc về cách chứng minh điều đó.

Không có khả năng của kẻ tấn công được xác định rõ ràng cũng như không đảm bảo an ninh cho các thành phần khác nhau (mã hóa khóa công khai, hàm băm, v.v.). Không dễ để nói liệu giao thức này có "có thể đính kèm" hay không.

Vì chúng ta được "toàn quyền chọn lựa", tôi sẽ trình bày hai cuộc tấn công PITM dựa trên các mô hình tấn công và bảo mật khác nhau.

Mô hình kẻ tấn công chung: Tôi cho rằng kẻ tấn công có toàn quyền kiểm soát mạng, họ có thể chèn, sắp xếp lại, sửa đổi và nếu không thì xóa tin nhắn. Hơn nữa, kẻ tấn công được phép "đăng ký" người dùng mới bất cứ lúc nào.

Cuộc tấn công 1: Liên kết sai danh tính và nhu cầu PKE an toàn hơn CPA

Như đã viết, có vẻ như giao thức phải được bảo mật miễn là sử dụng lược đồ PKE "an toàn". Tuy nhiên, khái niệm cơ bản về bảo mật như trong bảo mật ngữ nghĩa là không đủ. Ở cấp độ cao, khi kết thúc cuộc tấn công, $A$ nghĩ rằng họ đang nói chuyện với $B$, trong khi $B$ nghĩ rằng họ đang nói chuyện với kẻ tấn công nói $E$.

Để làm như vậy, chúng tôi sẽ hiển thị một PKE an toàn CPA mà cuộc tấn công có thể xảy ra. Để cho $\mathcal E$ là sơ đồ PKE "lai" (dựa trên mặt khác) trên chức năng cửa sập. Trường hợp mã hóa tin nhắn $m$ Dưới $pk$, đại khái bao gồm tạo ra một giá trị ngẫu nhiên $s$ sau đó tạo khóa mã hóa đối xứng $k = H(s)$. $k$ sau đó được sử dụng để mã hóa tin nhắn bằng thuật toán giống như mật mã dòng, tạo ra một bản mã $c$. Bản mã cuối cùng từ lược đồ PKE là $$\{m\}_{pk} = (enc_{PKE}(pk, s), c)$$ Cuộc tấn công hoạt động như sau.

1. $ A\rightarrow B: c_1 = \{N_A,A\}_{pk(B)} $
2. Kẻ tấn công chặn tin nhắn này, tạo một người dùng mới $E$, sửa đổi bản mã thành một giá trị $c_1'$ sao cho nó giải mã thành $N_A, E$. Điều này có thể xảy ra vì chúng tôi đang sử dụng mật mã luồng. (Ví dụ: chúng tôi cũng giả định rằng nonce và danh tính có độ dài cố định, v.v....)
3. $B$ giải mã tin nhắn và dường như $E's$ danh tính do đó tin nhắn thứ hai được gửi đến $E$
4. $B \rightarrow E: c_2 = \{N_A. N_B\}_{pk_E}$.
5. $E$ giải mã $c_2$, và nhận được nonces.
6. $E \rightarrow A: c_2' = \{N_A, N_B\}_{pk_A}$
7. $A \rightarrow B: c_3 = H(N_B, A, B)$
8. $E$ xen kẽ giọt $c_3$ và gửi $c_3' = H(N_B, E, B)$

Từ dòng chảy trên, quan điểm của $A$ giống như khi nó tương tác với $B$, trong khi quan điểm của $B$ như thể nó tương tác với $E$.

Tấn công 2: Phơi bày bí mật dài hạn và Tính toàn vẹn của thỏa hiệp khóa

Ở đây khả năng của kẻ tấn công được củng cố và chúng tôi cho phép thỏa hiệp các khóa bí mật dài hạn. Bây giờ rõ ràng, nếu $sk_A$ bị xâm phạm (và $A$ vẫn chưa biết) kẻ tấn công có thể mạo danh $A$ tuỳ ý; tuy nhiên có vẻ như bình thường để mong đợi rằng nếu $A$ chạy một phiên với một trung thực $B$, $A$ nên có sự đảm bảo về người mà cô ấy đã nói chuyện. Tuy nhiên trong cuộc tấn công này, sự thỏa hiệp của $sk_A$ ngụ ý rằng kẻ tấn công có thể mạo danh bất kỳ ai đối với $A$.

Ý tưởng cơ bản như trên là kẻ tấn công PITM sẽ có thể giải mã thông báo thứ hai $\{N_A, N_B\}_{pk_A}$. Kẻ tấn công bây giờ có thể kết thúc tương tác với $A$ và "cắt dây" về phía B. Kết quả là, $A$ nghĩ rằng họ đang nói chuyện $B$ trong khi thực tế là nói chuyện với B.

Tôi sẽ giả định rất nhiều về giao thức không rõ ràng trong câu hỏi. Tôi nêu một số điều đó trong phần thứ hai của câu trả lời này. Ngoài ra, tôi sẽ không đưa ra các lập luận của mình quá chi tiết.

bảo hiểm mong muốn là

(người tham gia) được đảm bảo rằng người kia đã tham gia vào giao thức với họ

nhưng tôi sẽ loại bỏ với họ, vì điều đó không rõ ràng và tôi không thấy định nghĩa chính xác nào về tiền điện tử có thể đáp ứng được (Người trung gian luôn có thể chuyển tiếp các thông điệp không thay đổi). Tôi sẽ thay thế nó bằng kể từ khi giao thức bắt đầu, không nên nhầm lẫn với mạnh hơn nhiều theo cách mà giao thức thường diễn ra.

Ở bước 1, $N_A$ được chọn ngẫu nhiên bởi $A$ và được mã hóa theo $pk(B)$, như một phần của bản rõ của $\{N_A,A\}_{pk(B)}$. Như vậy chỉ $A$ hoặc một số thực thể có một số mức độ khả năng để giải mã $\{N_A,A\}_{pk(B)}$, đó chỉ là $B$, có thể biết bất cứ điều gì về $N_A$ bên cạnh chiều dài của nó. Do đó, khi kết thúc bước 2, $A$ nhận được một cái gì đó giải mã để $N_A$, và họ biết họ đã không sử dụng $N_A$ cho mục đích khác ngoài việc tạo ra thông báo của bước 1, họ đảm bảo rằng $B$ đã tham gia vào giao thức. Tôi sẽ không đưa ra sự đảm bảo định lượng này, dành điều đó cho hướng khác.

Ở bước 2, $N_B$ được chọn ngẫu nhiên bởi $B$ và được mã hóa theo $pk(A)$, như một phần của bản rõ của $\{N_B,N_A\}_{pk(A)}$. Như vậy chỉ $B$ hoặc một thực thể có một số mức độ khả năng để giải mã $\{N_B,N_A\}_{pk(A)}$, đó chỉ là $A$, có thể biết bất cứ điều gì về $N_B$ bên cạnh chiều dài của nó. Giả định
 (a) hàm băm là một lời tiên tri ngẫu nhiên với chiều rộng đầu ra $k_H$,
(b) $N_B$ được chọn ngẫu nhiên đồng đều và có chiều rộng $k_N$,
 (c) bất kỳ đối thủ nào cũng có lợi thế giới hạn bởi $\epsilon$ chống lại mã hóa,
sau đó nói đối thủ là xác suất giới hạn trên bởi $2^{-k_H}+2^{-k_N}+\epsilon$ để tìm chính xác giá trị của hàm băm của bước 3. Do đó, khi kết thúc bước 3, $B$ tìm thấy giá trị như vậy cho hàm băm mà họ tính toán lại và họ biết rằng họ đã không sử dụng $N_B$ cho mục đích khác ngoài việc tạo thông báo của bước 2, họ đảm bảo rằng $A$ đã tham gia vào giao thức.

Nếu lý do này là chính xác, bước 3 có thể được đơn giản hóa thành $A\rightarrow B:\ hash(N_B)$. Nếu không, tôi muốn biết tại sao! Điều này không được hiểu là một gợi ý để thực hiện việc đơn giản hóa này: bao gồm các danh tính trong những gì được băm chỉ có thể hữu ích và tôi mơ hồ thấy rằng nó có thể chặn một số thay đổi có chủ ý của giao thức, chỉ không thuộc loại phá vỡ sự đảm bảo an ninh như tôi đã trình bày lại nó.

Danh sách một phần các giả định không được nêu trong câu hỏi

• Bổ sung muộn: Khóa công khai được biết và tin cậy trước khi giao thức bắt đầu.
• Bổ sung muộn: Mật mã được bảo mật để IND-CCA2. Sine, tôi không chắc liệu chúng ta có thể lấy đi một tài sản nhỏ hơn hay không, tôi muốn an toàn hơn.
• Như thường không được công bố trong phân tích giao thức, người nhận tin nhắn
  • thử giải mã và hủy bỏ nếu không thành công (như việc giải mã nhiều mật mã IND-CCA2 đã làm)
  • phân tích cú pháp các thông báo đã giải mã theo quy ước được vạch ra để tạo ra chúng và hủy bỏ nếu điều đó không thành công
  • kiểm tra các giá trị nhận được so với giá trị dự kiến ​​của chúng nếu đã biết từ bước trước hoặc có thể tính toán được (như xảy ra đối với hàm băm của bước 3 trên $B$ side) và hủy bỏ không khớp. Có vẻ như không cần thiết phải so sánh như vậy theo thời gian cố định.
  • hoặc/và sử dụng lại giá trị đã nói cho các biến có cùng tên trong các bước sắp tới.
• Trong bản rõ của các thông báo được mã hóa, dấu phẩy tượng trưng cho một hình thức nối với điều kiện là từ kết quả vẫn có thể tách ra tại điểm xảy ra nối, ví dụ: bởi vì một trong hai tin nhắn được nối có kích thước cố định. Điều đó dường như không cần thiết đối với dấu phẩy được sử dụng trong thông báo được băm ở bước 3.
• Trong tin nhắn, $A$ và $B$ là danh tính của những người tham gia cùng tên.
• Các thực thể chỉ sử dụng khóa riêng của họ cho mục đích giải mã các tin nhắn mà họ nhận được.
• Sau bước 1, $B$ quyết định khóa công khai nào họ sử dụng để mã hóa ở bước 2 và hướng tới người nhận sẽ gửi ở bước đó, trên cơ sở của phần thứ hai $A$ của thông báo được giải mã ở bước 1 và hủy bỏ nếu họ không biết khóa công khai tương ứng. Không cần thiết cho tính bảo mật của giao thức như đã nêu rằng họ kiểm tra phần thứ hai này không phải là danh tính của chính họ.
• Nếu những người tham gia cố gắng thực hiện nhiều kết nối đồng thời, như các máy chủ thường làm, thì giả định rằng họ giữ các biến riêng biệt cho từng phiên bản giao thức. Tôi không thấy lý do tại sao sẽ không ổn nếu nhiều nỗ lực kết nối mà một thực thể tham gia lại theo các hướng có khả năng khác nhau.
• Tôi bỏ qua các kênh phụ chưa được thảo luận, các cuộc tấn công lỗi và lỗi triển khai.