Điểm:2

Trao đổi khóa RSA được bảo vệ chống giả mạo như thế nào?

lá cờ ec

Khóa công khai được xác định bởi (N, e) ở đâu N là tích của hai số nguyên tố lớn và e được chọn sao cho e.d = 1 (mod phi(N)) ở đâu phi(N) là hàm totient của Euler. e là số mũ mã hóa và đ là số mũ giải mã.

Giả sử x là khóa đối xứng được mã hóa thành c = x^e mod(N). Làm thế nào là giả mạo với bản mã này c ngăn chặn?

kelalaka avatar
lá cờ in
Đây là sách giáo khoa RSA chúng tôi không sử dụng nó. Chúng tôi có các phần đệm như PKCS#5v.1.5 và OAEP để mã hóa và phần đệm PSS cho chữ ký. Hãy để tôi tìm cho bạn một dupe. **Chính xác ý bạn là gì khi giả mạo?** [RSA OAEP là bảo mật Ind-CPA](https://crypto.stackexchange.com/q/35171/18298) nếu bạn đang nói về tính toàn vẹn thì bạn cần MAC. Và [ít nhất những cuộc tấn công này có thể xảy ra trên RSA sách giáo khoa](https://crypto.stackexchange.com/q/20085/18298) mà phần đệm ngăn chặn, mặc dù phần đệm không bao gồm các cuộc tấn công kênh bên.
Abhisek Dash avatar
lá cờ ec
Ý tôi là sự chính trực. MAC được triển khai cùng với RSA như thế nào? Tôi biết cách triển khai MAC trong trường hợp mã hóa đối xứng nhưng không thể hình dung MAC sẽ được thực hiện như thế nào trong bối cảnh RSA và mã hóa bất đối xứng nói chung.
kelalaka avatar
lá cờ in
Mã hóa-Sau đó-MAC.Câu hỏi của bạn về cơ bản là trùng lặp với câu hỏi này [Chúng ta nên mã hóa MAC-then-encrypt hay mã hóa-then-MAC?](https://crypto.stackexchange.com/q/202/18298) và chúng tôi thậm chí không sử dụng RSA để mã hóa mặc dù chúng có thể an toàn với lớp đệm thích hợp. Chúng tôi sử dụng mã hóa Kết hợp... **Bạn đang cố gắng đạt được điều gì?**
kelalaka avatar
lá cờ in
Và, nếu không có phần đệm phù hợp, bạn không thể ngăn RSA trong sách giáo khoa chống lại các cuộc tấn công.
Abhisek Dash avatar
lá cờ ec
Trong mã hóa đối xứng, tính toàn vẹn của tin nhắn được bảo vệ bởi các sơ đồ bạn đã mô tả trong nhận xét trước đó của mình. Vì vậy, giả sử rằng tôi không sử dụng RSA trong sách giáo khoa và tôi sử dụng sơ đồ đệm thích hợp, điều gì ngăn cản kẻ tấn công thay đổi bản mã đệm. Có điều gì đó trong sơ đồ đệm ngăn chặn việc giả mạo bản mã không?
kelalaka avatar
lá cờ in
Xem [PKCS 1.5 giải quyết vấn đề không an toàn của RSA trong Sách giáo khoa như thế nào?](https://crypto.stackexchange.com/q/66722/18298)
Abhisek Dash avatar
lá cờ ec
Liên kết mô tả các phương pháp được sử dụng để tấn công RSA như cuộc tấn công của Bleichenbacher. Giả sử kẻ tấn công không muốn lấy khóa đối xứng. Tất cả những gì họ muốn làm là làm gián đoạn giao tiếp. Vì vậy, kẻ tấn công có thể thay đổi bản mã đệm. Sau khi giải mã và xóa phần đệm, điểm cuối khác sẽ nhận được thông báo/khóa không chính xác do bản mã đã bị giả mạo. Làm thế nào người nhận biết rằng bản mã đã bị giả mạo? Trong trường hợp mã hóa đối xứng, điều này có thể được xử lý bằng cách mã hóa hàm băm của tin nhắn bằng khóa đối xứng. Cơ chế ở đây là gì?
kelalaka avatar
lá cờ in
không rõ ràng rằng cấu trúc đệm sẽ bị lỗi tương tự như lỗi MAC?
Điểm:2
lá cờ in

Như đã chỉ ra trong các nhận xét bên dưới câu hỏi, RSA thường không được sử dụng làm phép lũy thừa mô-đun của khóa đối xứng. Thay vào đó, khóa được mã hóa bằng phần đệm PKCS#1 v1.5 hoặc - tốt nhất là - OAEP hoặc bí mật được chia sẻ với giá trị ngẫu nhiên trong phạm vi $\big[0, N\big)$ được sử dụng cho lũy thừa mô-đun. Trong trường hợp sau, một khóa thực tế được lấy bằng KDF (hàm dẫn xuất khóa), đôi khi còn được gọi đơn giản là "PRF" (xem ví dụ: TLS 1.2). Điều này được gọi là RSA-KEM.

Về cơ bản, có hai cách để tránh giả mạo khóa thông qua cuộc tấn công trung gian (MitM):

  1. thiết lập niềm tin vào khóa công khai RSA;
  2. xác minh bí mật được chia sẻ và/hoặc khóa dẫn xuất.

Nếu bạn chia sẻ trước và tin cậy khóa công khai của cặp khóa tĩnh thì bạn sẽ có một trao đổi khóa tĩnh, tức là khóa chung được tin cậy, nhưng bạn sẽ không cung cấp bảo mật chuyển tiếp. Điều đó có nghĩa là mọi khóa đối xứng tiếp theo đều có thể được tính toán nếu kẻ thù biết được khóa riêng.

Độ tin cậy của khóa công khai có thể được thiết lập theo nhiều cách khác nhau. Đối với cặp khóa tĩnh, khóa chung có thể được tin cậy bằng PKI. Nếu bạn cần tin tưởng một khóa công khai tạm thời, người nhận có thể ký nó bằng một khóa riêng là một phần của cặp khóa đáng tin cậy.


Một cách khác là xác minh khóa phiên đã thiết lập sau đó. Điều đó có thể được thực hiện một cách rõ ràng hoặc ngầm.

Khi xác minh rõ ràng bí mật được chia sẻ, bên giải mã khóa sẽ sử dụng nó để tạo MAC trên dữ liệu tĩnh được cả hai bên biết và gửi MAC. Bên đó bây giờ có thể chắc chắn rằng khóa đối xứng phù hợp đã được thiết lập.

Trong xác minh ẩn, khóa được sử dụng đơn giản để gửi đi gửi lại các tin nhắn đã được xác thực. Việc xác minh xác thực của các gói này chỉ ra rằng khóa phù hợp đã được thiết lập.


Tất nhiên, chỉ bên có khóa công khai được tin cậy mới được xác thực. Tương tự, nếu bất kỳ MAC nào được xác minh, thì điều đó chỉ cho thấy rằng bên giữ khóa riêng đã có thể giải mã. Vì vậy, nếu bạn cần xác thực của bên còn lại thì điều đó cần được xử lý riêng.

Trong TLS, điều này được thực hiện bằng cách yêu cầu bên kia tạo một chữ ký có thể được xác minh. Điều này cũng yêu cầu khóa công khai của cặp khóa đó phải được tin cậy trước; cuối cùng, bạn cần luôn thiết lập niềm tin vào một thứ gì đó trước khi có thể xác thực bên đó.

Xác thực ứng dụng khách TLS hầu như không được sử dụng. Thay vào đó, nó được thay thế bằng các khung xác thực hoặc xác thực dựa trên mật khẩu. Hoặc danh tính của khách hàng hoàn toàn không được thiết lập - cho đến khi việc mua hàng được thực hiện.


Lưu ý rằng việc xác thực các khóa được thiết lập bằng cách sử dụng thiết lập khóa RSA không khác với xác thực các khóa bằng Diffie-Hellman chẳng hạn - mặc dù với cái sau có hai cặp khóa cần xem xét. Cuối cùng, các loại kỹ thuật tương tự có thể được sử dụng.

Abhisek Dash avatar
lá cờ ec
Hãy tưởng tượng kịch bản sau đây. Máy chủ gửi khóa công khai của nó cho máy khách. Máy khách xác minh tính xác thực của nó bằng PKI. Máy khách mã hóa khóa đối xứng bằng khóa chung bằng PKCS v1.5. Một người đàn ông ở giữa sẽ chặn gói này và mã hóa khóa đối xứng của chính nó bằng khóa chung của máy chủ. Điều này sẽ gây ra bất kỳ vấn đề?
Maarten Bodewes avatar
lá cờ in
Vâng, bình luận tốt. Trên thực tế, đây là điều có thể xảy ra trên ví dụ: các trình duyệt web cũng vậy. Vấn đề là ứng dụng khách thường không được xác thực (xác thực ứng dụng khách TLS không phổ biến). Đây thường không phải là vấn đề nếu phía bên kia là ví dụ. cửa hàng trực tuyến: khách hàng xác thực bằng tên người dùng/mật khẩu nếu họ có tài khoản (qua kết nối được bảo mật khác) và/hoặc họ chỉ cung cấp thông tin của mình trong quá trình thanh toán. Tôi sẽ điều chỉnh câu trả lời sau để chỉ ra rằng niềm tin cần được thiết lập cho một trong hai bên - nhưng tất nhiên ít nhất là đối với bên chia sẻ khóa chung.
Abhisek Dash avatar
lá cờ ec
Tôi nghĩ rằng tôi đã nhận nó. Mối quan tâm của tôi là điều gì sẽ xảy ra nếu một người đàn ông ở giữa can thiệp vào bản mã PKCS v1.5 có chứa khóa đối xứng. Nhưng sau khi giải mã, bản rõ có thể không tuân thủ PKCS v1.5. Giả sử rằng khó có thể can thiệp vào bản mã theo cách sao cho nó tuân thủ PKCS v1.5 sau khi giải mã, PKCS v1.5 cung cấp một loại mã xác thực thông báo cho khóa đối xứng được mã hóa. Tôi có đúng không khi giả định điều này?
Maarten Bodewes avatar
lá cờ in
Không, vì kẻ tấn công có thể chỉ cần mã hóa thứ khác bằng khóa chung. Vì vậy, ngay cả khi có khả năng chống giả mạo đó - và nó có - không thành vấn đề, kẻ tấn công chỉ có thể thay thế toàn bộ bản mã. Chỉ có thể *tin tưởng một bên khác* nếu họ thực hiện một số loại quy trình xác thực. Đó có thể là thao tác khóa riêng tư hoặc cung cấp cụm mật khẩu đã thiết lập trước đó.

Đă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.