Điểm:2

Kẻ tấn công có thể làm gì với việc sử dụng AES-CFB8 không an toàn này?

lá cờ in

Tôi tin rằng tôi đã nhận thấy việc sử dụng AES-CFB8 không an toàn trong một ứng dụng mà tôi đang làm việc và hy vọng ai đó có thể giải thích cách thức và lý do điều này không an toàn cũng như những gì kẻ tấn công có thể làm chẳng hạn như khôi phục khóa vì đó sẽ là kết quả tồi tệ hơn đối với giao thức này .

Về cơ bản, AES-CFB8 (rõ ràng không có phần đệm) được sử dụng để mã hóa luồng dữ liệu và IV/khóa được sử dụng lại giữa các luồng máy chủ và máy khách và IV giống với khóa. Điều này không an toàn đến mức nào và liệu một cuộc tấn công có thể khôi phục iv/key từ điều này không. Khóa được sử dụng cho AES là một bí mật được chia sẻ có thể xâm phạm nhiều hơn luồng gói ban đầu vì luồng có khả năng sử dụng không an toàn này không nhạy cảm nhưng sẽ là vấn đề lớn hơn nếu khóa được sử dụng bị xâm phạm.

công khai SecretKey tạoSharedSecret() {
   KeyGenerator cuối cùng gen = KeyGenerator.getInstance("AES");
   gen.init(128); // AES-128
   trả về gen.generateKey();
}
// Được quyết định bởi máy khách và được gửi một cách an toàn đến máy chủ thông qua RSA và được xác thực thông qua một nguồn đáng tin cậy.
SecretKey sharedSecret cuối cùng = generateSharedSecret();
 // Điều này được thực hiện trên cả máy chủ và máy khách sau khi máy chủ đã nhận được bí mật được chia sẻ. 
 Mật mã cuối cùng aesCFBEncrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBEncrypt.init(Cipher.ENCRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded()));

 Mật mã cuối cùng aesCFBDecrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBDecrypt.init(Cipher.DECRYPT_MODE, sharedSecret, new IvParameterSpec(sharedSecret.getEncoded()));

 this.enableStreamEncryption(aesCFBEncrypt, aesCFBDecrypt);

Tôi đã xem xét các vấn đề tương tự nhưng không có vấn đề nào tôi thấy phù hợp với tiêu chí mà tôi quan tâm, đó là việc sử dụng mật mã dưới dạng luồng với các phiên bản khác nhau cho RX/TX trên máy khách và máy chủ cũng như việc sử dụng khóa là iv mà không có phiên bản khác khóa cho máy chủ và máy khách.

SAI Peregrinus avatar
lá cờ si
Tại sao lại là CFB? Đó không phải là chế độ phổ biến và không an toàn cho AE, vì vậy câu trả lời là "không" thậm chí bỏ qua các vấn đề khác với chế độ này.
lá cờ in
@sai-peregrinus Tôi không biết tại sao CFB được sử dụng, mã này được viết hơn một thập kỷ trước nhưng một người không phải là tôi. Tôi biết bản thân luồng có thể bị thao túng nhưng giao thức cơ bản có các cơ chế khiến việc này trở nên khó khăn hoặc không thể thực hiện được trong thời gian thực.Giả sử giao thức cơ bản đang sử dụng MAC-then-Encrypt để xác thực. Đây là phân tích mã của một chương trình cũ, không phải là việc sử dụng tiền điện tử không hợp lệ cho một giao thức mới nếu bạn cho rằng điều đó. Nhiều sai lầm và thực hành xấu đã được thực hiện ở đây và có thể chỉ hoạt động do may mắn nhưng tôi tự hỏi về bất kỳ cuộc tấn công thực tế nào.
lá cờ in
@SAIPeregrinus Tôi quan tâm hơn đến việc liệu bí mật được chia sẻ được sử dụng với mật mã hay không và liệu điều đó có thể được khôi phục hay không thì hãy cố gắng thao túng văn bản thuần túy nếu điều đó có ý nghĩa vì đó không phải là vấn đề trừ khi ai đó có toàn quyền kiểm soát và có thể đọc và viết các văn bản thuần túy theo cả hai hướng của luồng. Lý do duy nhất tại sao mã hóa được sử dụng là do các nỗ lực MITM trước đây thông qua kỹ thuật xã hội chưa bao giờ gây ra bất kỳ tác hại thực sự nào.
Điểm:2
lá cờ in

Nếu khóa và IV giống hệt nhau thì giá trị trung gian đầu tiên sau khi mã hóa khối được XOR'ed với byte đầu tiên cũng giống hệt nhau giữa hai thao tác mã hóa.Điều đó có nghĩa là nếu byte đầu tiên của bản rõ giống hệt nhau thì điều này sẽ dẫn đến bản mã giống hệt nhau, làm rò rỉ thông tin cho kẻ tấn công có thể.

Tất nhiên, bản mã này cũng được truyền vào thanh ghi dịch chuyển hiện đang giữ IV. Một byte của IV được dịch chuyển sang trái (MSB), và byte bản mã được đặt ở bên phải (LSB). Vì vậy, bây giờ mã hóa tiếp theo sẽ lại dẫn đến giá trị trung gian giống hệt nhau. Điều này có nghĩa là byte văn bản gốc giống hệt nhau tiếp theo cũng sẽ trực tiếp rò rỉ dữ liệu, v.v. Tất nhiên, nếu bạn có nhiều tin nhắn thì bạn có thể tạo nhiều cặp, vì vậy khả năng rò rỉ dữ liệu sẽ cao hơn.

Chỉ khi các byte văn bản gốc khác nhau giữa các thông điệp thì quá trình lan truyền mới dừng lại. Tuy nhiên, những byte cuối cùng này tự tạo thành một vấn đề. Các bản rõ khác nhau đã được XOR với các giá trị trung gian giống hệt nhau để tạo ra các byte bản mã. Điều đó có nghĩa là XOR của các byte bản mã dẫn đến XOR của các byte bản rõ. Điều này có thể trực tiếp làm rò rỉ dữ liệu và một lần nữa, càng biết nhiều byte bản mã thì càng có thể thực hiện nhiều kết hợp.


Về mặt sáng sủa: IV được lưu trữ trong thanh ghi ca. Vì nó chỉ được sử dụng làm đầu vào cho mật mã khối nên có khả năng giá trị của IV và do đó khóa được bảo vệ tương đối tốt.

Nếu các cuộc tấn công kênh bên cấp thấp có thể xảy ra thì nó có thể có thể xác định một số bit chính trong thao tác thay đổi, nhưng bạn có thể cần nhiều thao tác trước khi có thể trích xuất bất kỳ dữ liệu khóa/IV nào. Vì tôi đã bị bất ngờ bởi các cuộc tấn công kênh bên trước khi tôi nghĩ rằng nó nên được xem xét.


Bạn không chỉ không nên sử dụng dữ liệu khóa làm IV (sử dụng hàm băm trên IV sẽ tốt hơn), mà bạn cũng không nên sử dụng lại khóa cho các mục đích khác.

Tôi sẽ rất nghi ngờ về tính bảo mật của giao thức mà bạn đã mô tả do các thực tiễn xấu về mật mã này - mặc dù việc sử dụng chế độ CFB-8 có lẽ đã đủ cho thấy các nhà thiết kế giao thức không biết họ đang làm gì.

Maarten Bodewes avatar
lá cờ in
Nói cách khác: ?LÀM LẠI TỪ BẮT ĐẦU...
Điểm:-1
lá cờ si

Không, điều này không an toàn. IV được gửi không được mã hóa.Vì IV cũng được sử dụng làm khóa nên điều này về cơ bản giống như gửi dữ liệu không được mã hóa. Nó có thể ngăn chặn một kẻ tấn công bình thường, nhưng nó sẽ không ngăn cản bất kỳ ai quyết tâm.

Có vẻ như bạn có thể đang sử dụng lại cùng một IV cho nhiều thư. Điều đó vô hiệu hóa các tuyên bố bảo mật của CFB, ngay cả khi nó được giữ bí mật. Bạn có thể muốn có chế độ chống lạm dụng như AES-GCM-SIV, nếu bạn không thể đảm bảo IV mới cho mọi thư.

lá cờ in
IV không bao giờ được gửi, IV giống như khóa trừ khi đây là chi tiết triển khai của AES-CFB mà nó bao gồm IV trong văn bản mật mã nhưng tôi nghi ngờ điều đó. "Có vẻ như bạn có thể đang sử dụng lại cùng một IV cho nhiều tin nhắn.Điều đó vô hiệu hóa các tuyên bố bảo mật của CFB, ngay cả khi nó được giữ bí mật." Đây là lời giải thích mà tôi muốn biết thêm và nó bị phá vỡ như thế nào? Tôi quan tâm nhiều hơn đến lý do tại sao nó xấu hơn là nó xấu vì tôi biết việc sử dụng lại IV và IV làm khóa (IV không bao giờ được tạo ngẫu nhiên trên mỗi tin nhắn hoặc được gử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.