Khi bạn nghe thấy từ “mật mã”, một số người nhớ mật khẩu WiFi của họ, ổ khóa màu xanh lá cây bên cạnh địa chỉ trang web yêu thích của họ và việc truy cập email của người khác khó đến mức nào. Những người khác nhớ lại một loạt lỗ hổng trong những năm gần đây với các chữ viết tắt (DROWN, FREAK, POODLE...), logo đầy phong cách và cảnh báo khẩn cấp cập nhật trình duyệt của bạn.
Mật mã bao gồm tất cả, nhưng bản chất của trong một cái khác. Vấn đề là có một ranh giới mong manh giữa đơn giản và phức tạp. Có những việc thì dễ làm nhưng lại khó gắn kết lại, như đập một quả trứng. Những việc khác thì dễ làm nhưng lại khó lấy lại khi thiếu một phần nhỏ, quan trọng, cốt yếu: ví dụ như mở một cánh cửa đã khóa khi “phần quan trọng” chính là chìa khóa. Mật mã học nghiên cứu những tình huống này và cách chúng có thể được sử dụng trong thực tế.
Trong những năm gần đây, bộ sưu tập các cuộc tấn công bằng mật mã đã biến thành một vườn thú với những logo hào nhoáng, chứa đầy các công thức từ các bài báo khoa học và làm nảy sinh cảm giác u ám chung rằng mọi thứ đều đã hỏng. Nhưng trên thực tế, nhiều cuộc tấn công đều dựa trên một số nguyên tắc chung và vô số trang công thức thường được cô đọng lại thành những ý tưởng dễ hiểu.
Trong loạt bài viết này, chúng ta sẽ xem xét các loại tấn công mật mã khác nhau, nhấn mạnh vào các nguyên tắc cơ bản. Nói chung và không chính xác theo thứ tự này, nhưng chúng tôi sẽ đề cập đến những điều sau:
- Các chiến lược cơ bản: lực lượng vũ phu, phân tích tần số, nội suy, hạ cấp và giao thức chéo.
- Các lỗ hổng được gắn thương hiệu: FREAK, TỘI PHẠM, POODLE, DROWN, Logjam.
- Chiến lược nâng cao: các cuộc tấn công oracle (tấn công Vodenet, tấn công Kelsey); phương pháp gặp nhau, tấn công sinh nhật, sai lệch thống kê (phân tích mật mã vi phân, phân tích mật mã tích phân, v.v.).
- Tấn công kênh bên và người thân của họ, kỹ thuật phân tích thất bại.
- Tấn công vào mật mã khóa công khai: căn bậc ba, phát sóng, thông điệp liên quan, tấn công Coppersmith, thuật toán Pohlig-Hellman, sàng số, tấn công Wiener, tấn công Bleichenbacher.
Bài viết cụ thể này bao gồm các tài liệu trên cho đến cuộc tấn công của Kelsey.
Chiến lược cơ bản
Các cuộc tấn công sau đây đơn giản theo nghĩa là chúng có thể được giải thích gần như hoàn toàn mà không cần nhiều chi tiết kỹ thuật. Hãy giải thích từng loại tấn công bằng những thuật ngữ đơn giản nhất mà không đi sâu vào các ví dụ phức tạp hoặc các trường hợp sử dụng nâng cao.
Một số cuộc tấn công này phần lớn đã trở nên lỗi thời và không được sử dụng trong nhiều năm. Những người khác là những người kỳ cựu vẫn thường xuyên theo dõi các nhà phát triển hệ thống mật mã trong thế kỷ 21. Kỷ nguyên của mật mã hiện đại có thể coi là đã bắt đầu với sự ra đời của IBM DES, mật mã đầu tiên chống chọi lại mọi cuộc tấn công trong danh sách này.
Lực lượng vũ phu đơn giản
Sơ đồ mã hóa bao gồm hai phần: 1) chức năng mã hóa, lấy một tin nhắn (bản rõ) kết hợp với một khóa, sau đó tạo một tin nhắn được mã hóa - ciphertext; 2) hàm giải mã lấy bản mã và khóa rồi tạo ra bản rõ. Cả việc mã hóa và giải mã đều phải dễ dàng tính toán bằng khóa—và khó tính toán nếu không có khóa đó.
Giả sử chúng ta nhìn thấy văn bản mã hóa và cố gắng giải mã nó mà không có bất kỳ thông tin bổ sung nào (đây được gọi là cuộc tấn công chỉ dựa vào văn bản mã hóa). Nếu bằng cách nào đó chúng ta tìm được khóa chính xác một cách kỳ diệu, chúng ta có thể dễ dàng xác minh rằng nó thực sự đúng nếu kết quả là một thông báo hợp lý.
Lưu ý rằng có hai giả định ngầm ở đây. Đầu tiên, chúng ta biết cách thực hiện giải mã, tức là cách hệ thống mật mã hoạt động. Đây là một giả định tiêu chuẩn khi thảo luận về mật mã. Việc che giấu chi tiết triển khai của mật mã khỏi kẻ tấn công có vẻ giống như một biện pháp bảo mật bổ sung, nhưng một khi kẻ tấn công tìm ra những chi tiết này, bảo mật bổ sung này sẽ bị mất một cách âm thầm và không thể đảo ngược. Như thế đấy : Hệ thống rơi vào tay kẻ thù sẽ không gây bất tiện.
Thứ hai, chúng tôi giả định rằng khóa chính xác là khóa duy nhất dẫn đến việc giải mã hợp lý. Đây cũng là một giả định hợp lý; sẽ hài lòng nếu bản mã dài hơn nhiều so với khóa và có thể đọc được. Đây thường là những gì xảy ra trong thế giới thực, ngoại trừ hoặc (nếu bạn không thích thì chúng tôi đã bỏ qua phần giải thích, xem Định lý 3.8 ).
Với những điều trên, một chiến lược nảy sinh: kiểm tra mọi khóa có thể. Điều này được gọi là lực lượng vũ phu và một cuộc tấn công như vậy được đảm bảo có tác dụng chống lại tất cả các mật mã thực tế - cuối cùng. Ví dụ, vũ phu là đủ để hack , một mật mã cổ xưa trong đó khóa là một chữ cái trong bảng chữ cái, ngụ ý chỉ có hơn 20 khóa có thể.
Thật không may cho các nhà phân tích mật mã, việc tăng kích thước khóa là một biện pháp phòng vệ tốt trước sức mạnh vũ phu. Khi kích thước khóa tăng lên, số lượng khóa có thể tăng theo cấp số nhân. Với kích thước khóa hiện đại, lực lượng vũ phu đơn giản là hoàn toàn không thực tế. Để hiểu ý của chúng tôi, hãy xem siêu máy tính nhanh nhất được biết đến vào giữa năm 2019: của IBM, với hiệu suất cao nhất khoảng 1017 thao tác mỗi giây. Ngày nay, độ dài khóa thông thường là 128 bit, nghĩa là có thể có 2128 tổ hợp. Để tìm kiếm tất cả các chìa khóa, siêu máy tính Summit sẽ cần thời gian gấp khoảng 7800 lần tuổi của Vũ trụ.
Liệu vũ lực có nên được coi là một sự tò mò lịch sử? Hoàn toàn không: nó là một thành phần cần thiết trong sách hướng dẫn giải mã. Hiếm khi mật mã nào yếu đến mức chỉ có thể bị phá vỡ bằng một cuộc tấn công khéo léo, không cần dùng đến vũ lực ở mức độ này hay mức độ khác. Nhiều vụ hack thành công sử dụng phương pháp thuật toán để làm suy yếu mật mã mục tiêu trước tiên, sau đó thực hiện một cuộc tấn công vũ phu.
Phân tích tần số
Hầu hết các văn bản không phải là vô nghĩa. Ví dụ, trong văn bản tiếng Anh có nhiều chữ cái 'e' và mạo từ 'the'; trong các tệp nhị phân, có nhiều byte XNUMX làm phần đệm giữa các phần thông tin. Phân tích tần suất là bất kỳ cuộc tấn công nào lợi dụng thực tế này.
Ví dụ điển hình về mật mã dễ bị tấn công này là mật mã thay thế đơn giản. Trong mật mã này, khóa là một bảng có tất cả các chữ cái được thay thế. Ví dụ: 'g' được thay bằng 'h', 'o' bằng j, do đó từ 'go' trở thành 'hj'. Mật mã này rất khó để sử dụng một cách thô bạo vì có rất nhiều bảng tra cứu có thể có. Nếu bạn quan tâm đến toán học, độ dài khóa hiệu dụng là khoảng 88 bit: đó là
. Nhưng phân tích tần số thường hoàn thành công việc một cách nhanh chóng.
Hãy xem xét bản mã sau được xử lý bằng mật mã thay thế đơn giản:
XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO
Kể từ khi Y xuất hiện thường xuyên, kể cả ở cuối nhiều từ, chúng ta có thể tạm cho rằng đây là chữ cái e:
XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO
Couple XD lặp lại ở đầu một số từ. Đặc biệt, tổ hợp XDeLe gợi ý rõ ràng từ these hoặc there, vậy chúng ta hãy tiếp tục:
theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG hơn ALe FLeAUt GR WN OGQL ZDWBGEGZDO
Chúng ta hãy giả sử thêm rằng L phù hợp với r, A - a và như thế. Có thể sẽ mất một vài lần thử, nhưng so với một cuộc tấn công vũ phu hoàn toàn, cuộc tấn công này sẽ khôi phục văn bản gốc ngay lập tức:
có nhiều điều trên trời và dưới đất hơn những gì bạn mơ ước trong triết lý của mình
Đối với một số người, việc giải những “mật mã” như vậy là một sở thích thú vị.
Ý tưởng phân tích tần số cơ bản hơn so với cái nhìn đầu tiên. Và nó áp dụng cho các mật mã phức tạp hơn nhiều. Trong suốt lịch sử, nhiều thiết kế mật mã khác nhau đã cố gắng chống lại cuộc tấn công như vậy bằng cách sử dụng "sự thay thế đa bảng chữ cái". Ở đây, trong quá trình mã hóa, bảng thay thế chữ cái được sửa đổi theo những cách phức tạp nhưng có thể dự đoán được tùy thuộc vào khóa. Tất cả những mật mã này được coi là khó giải mã cùng một lúc; nhưng phân tích tần số khiêm tốn cuối cùng đã đánh bại tất cả.
Mật mã đa bảng chữ cái đầy tham vọng nhất trong lịch sử và có lẽ nổi tiếng nhất là mật mã Enigma của Thế chiến thứ hai. Nó tương đối phức tạp so với những phiên bản tiền nhiệm, nhưng sau nhiều nỗ lực, các nhà giải mã người Anh đã giải mã được nó bằng cách sử dụng phân tích tần số. Tất nhiên, họ không thể phát triển một đòn tấn công tao nhã như đòn trên; họ phải so sánh các cặp văn bản gốc và văn bản mã hóa đã biết ("cuộc tấn công bằng văn bản gốc"), thậm chí còn kích động người dùng Enigma mã hóa một số tin nhắn nhất định và phân tích kết quả ("cuộc tấn công bằng văn bản gốc được chọn"). Nhưng điều này không làm cho số phận của quân địch bị đánh bại và tàu ngầm bị đánh chìm trở nên dễ dàng hơn chút nào.
Sau chiến thắng này, phân tích tần số đã biến mất khỏi lịch sử giải mã. Mật mã trong thời đại kỹ thuật số hiện đại được thiết kế để hoạt động với bit chứ không phải chữ cái. Quan trọng hơn, những mật mã này được thiết kế với sự hiểu biết đen tối về cái mà sau này được gọi là : Bất kỳ ai cũng có thể tạo ra một thuật toán mã hóa mà bản thân họ không thể phá vỡ được. Nó không đủ cho hệ thống mã hóa dường như khó khăn: để chứng minh giá trị của nó, nó phải trải qua quá trình xem xét bảo mật tàn nhẫn bởi nhiều nhà giải mã, những người sẽ cố gắng hết sức để bẻ khóa mật mã.
Tính toán sơ bộ
Lấy thành phố giả định Precom Heights, dân số 200 người. Mỗi ngôi nhà trong thành phố chứa đựng những đồ vật có giá trị trung bình $000, nhưng không quá $30. Thị trường an ninh ở Precom được độc quyền bởi ACME Industries, công ty sản xuất khóa cửa đẳng cấp Coyote™ huyền thoại. Theo phân tích của chuyên gia, khóa lớp Coyote chỉ có thể bị phá bằng một chiếc máy giả định rất phức tạp, việc tạo ra chiếc khóa này cần khoảng 000 năm và vốn đầu tư 50 USD. Thành phố có an toàn không?
Rất có thể là không. Cuối cùng, một tên tội phạm khá tham vọng sẽ xuất hiện. Anh ta sẽ lý luận như thế này: “Đúng, tôi sẽ phải chịu những chi phí trả trước lớn. 50 năm kiên nhẫn chờ đợi và 000 đô la. Nhưng khi tôi hoàn thành, tôi sẽ có quyền truy cập vào tất cả sự giàu có của thành phố này. Nếu tôi chơi bài đúng cách, khoản đầu tư này sẽ tự sinh lãi gấp nhiều lần ”.
Điều này cũng đúng trong mật mã. Các cuộc tấn công chống lại một mật mã cụ thể phải được phân tích chi phí-lợi ích một cách tàn nhẫn. Nếu tỷ lệ thuận lợi thì cuộc tấn công sẽ không xảy ra. Nhưng các cuộc tấn công nhằm vào nhiều nạn nhân tiềm năng cùng một lúc hầu như luôn mang lại kết quả, trong trường hợp đó, phương pháp thiết kế tốt nhất là giả định rằng chúng đã bắt đầu ngay từ ngày đầu tiên. Về cơ bản, chúng tôi có một phiên bản mật mã của Định luật Murphy: "Bất cứ thứ gì thực sự có thể phá vỡ hệ thống sẽ phá vỡ hệ thống."
Ví dụ đơn giản nhất về hệ thống mật mã dễ bị tấn công trước khi tính toán là mật mã không khóa cố định. Đây là trường hợp với , chỉ đơn giản là dịch chuyển mỗi chữ cái trong bảng chữ cái về phía trước ba chữ cái (bảng được lặp lại, vì vậy chữ cái cuối cùng trong bảng chữ cái được mã hóa thứ ba). Ở đây một lần nữa nguyên tắc Kerchhoffs lại phát huy tác dụng: một khi hệ thống bị tấn công, nó sẽ bị tấn công vĩnh viễn.
Khái niệm này rất đơn giản. Ngay cả một nhà phát triển hệ thống mật mã mới vào nghề cũng có thể nhận ra mối đe dọa và chuẩn bị cho phù hợp. Nhìn vào sự phát triển của mật mã, những cuộc tấn công như vậy không phù hợp với hầu hết các mật mã, từ những phiên bản cải tiến đầu tiên của mật mã Caesar cho đến sự suy tàn của mật mã đa bảng chữ cái. Những cuộc tấn công như vậy chỉ quay trở lại khi kỷ nguyên mật mã hiện đại ra đời.
Sự trở lại này là do hai yếu tố. Đầu tiên, các hệ thống mật mã đủ phức tạp cuối cùng đã xuất hiện, trong đó khả năng khai thác sau khi hack là không rõ ràng. Thứ hai, mật mã trở nên phổ biến đến mức hàng triệu người dân đưa ra quyết định mỗi ngày về việc sử dụng lại phần nào và ở đâu của mật mã. Phải mất một thời gian các chuyên gia mới nhận ra rủi ro và đưa ra cảnh báo.
Hãy nhớ cuộc tấn công tính toán trước: ở cuối bài viết, chúng ta sẽ xem xét hai ví dụ về mật mã thực tế trong đó nó đóng một vai trò quan trọng.
Phép nội suy
Đây là thám tử nổi tiếng Sherlock Holmes, người đang thực hiện một cuộc tấn công nội suy vào bác sĩ Watson xui xẻo:
Tôi đoán ngay rằng bạn đến từ Afghanistan... Dòng suy nghĩ của tôi như sau: “Người đàn ông này thuộc loại bác sĩ, nhưng anh ta có quân hàm. Vì vậy, một bác sĩ quân đội. Anh ấy vừa mới từ vùng nhiệt đới đến - khuôn mặt anh ấy ngăm đen, nhưng đây không phải là màu da tự nhiên của anh ấy, vì cổ tay của anh ấy trắng hơn nhiều. Sắc mặt hốc hác - hiển nhiên hắn đã phải chịu đựng rất nhiều, chịu đựng bệnh tật. Anh ấy bị thương ở tay trái - anh ấy giữ nó bất động và hơi mất tự nhiên. Ở vùng nhiệt đới nào một bác sĩ quân y người Anh có thể chịu đựng gian khổ và bị thương? Tất nhiên là ở Afghanistan." Toàn bộ dòng suy nghĩ không mất đến một giây. Và vì vậy tôi đã nói rằng bạn đến từ Afghanistan, và bạn rất ngạc nhiên.
Holmes có thể trích xuất rất ít thông tin từ từng bằng chứng riêng lẻ. Anh ấy chỉ có thể đi đến kết luận của mình bằng cách xem xét tất cả chúng cùng nhau. Một cuộc tấn công nội suy hoạt động tương tự bằng cách kiểm tra các cặp bản rõ và bản mã đã biết do cùng một khóa. Từ mỗi cặp, các quan sát riêng lẻ được rút ra cho phép rút ra kết luận chung về khóa được rút ra. Tất cả những suy luận này đều mơ hồ và dường như vô ích cho đến khi chúng đột nhiên đạt đến khối lượng tới hạn và dẫn đến kết luận duy nhất có thể xảy ra: dù nó có khó tin đến đâu thì nó vẫn phải là sự thật. Sau đó, khóa sẽ được tiết lộ hoặc quá trình giải mã trở nên tinh tế đến mức có thể sao chép được.
Hãy minh họa bằng một ví dụ đơn giản về cách hoạt động của phép nội suy. Giả sử chúng ta muốn đọc nhật ký cá nhân của kẻ thù của chúng ta, Bob. Anh ấy mã hóa mọi con số trong nhật ký của mình bằng cách sử dụng một hệ thống mật mã đơn giản mà anh ấy đã học được từ một quảng cáo trên tạp chí "A Mock of Cryptology". Hệ thống hoạt động như sau: Bob chọn hai số mà anh ấy thích: и . Từ bây giờ, để mã hóa bất kỳ số nào , nó tính toán . Ví dụ: nếu Bob chọn и , thì số sẽ được mã hóa dưới dạng .
Giả sử vào ngày 28 tháng XNUMX, chúng tôi nhận thấy Bob đang viết gì đó trong nhật ký của mình. Khi anh ấy viết xong, chúng ta sẽ lặng lẽ nhặt nó lên và xem mục cuối cùng:
Дата:
235/520Nhật ký thân yêu,
Ngày hôm nay là một ngày tốt lành. Bởi vì
64hôm nay tôi có hẹn với Alisa, cô ấy sống trong một căn hộ843. Tôi thực sự nghĩ rằng cô ấy có thể26!
Vì chúng tôi rất nghiêm túc trong việc theo dõi cuộc hẹn hò của Bob (cả hai chúng tôi đều 15 tuổi trong kịch bản này), điều quan trọng là phải biết ngày cũng như địa chỉ của Alice. May mắn thay, chúng tôi nhận thấy rằng hệ thống mật mã của Bob rất dễ bị tấn công nội suy. Chúng ta có thể không biết и , nhưng chúng ta biết ngày hôm nay nên chúng ta có hai cặp bản rõ-bản mã. Cụ thể là chúng ta biết rằng được mã hóa trong Và - tại . Đây là những gì chúng tôi sẽ viết ra:
Khi mới 15 tuổi, chúng ta đã biết về hệ hai phương trình với hai ẩn số, trong tình huống này là đủ để tìm и mà không có bất kỳ vấn đề. Mỗi cặp bản rõ-bản mã đặt ra một ràng buộc đối với khóa của Bob và hai ràng buộc đó kết hợp với nhau là đủ để khôi phục hoàn toàn khóa. Trong ví dụ của chúng tôi, câu trả lời là и (tại , vì thế 26 trong nhật ký tương ứng với từ 'cái một', tức là "cái giống nhau" - khoảng. làn đường).
Tất nhiên, các cuộc tấn công nội suy không chỉ giới hạn ở những ví dụ đơn giản như vậy. Mọi hệ thống mật mã rút gọn thành một đối tượng toán học được hiểu rõ và một danh sách các tham số đều có nguy cơ bị tấn công nội suy—đối tượng càng dễ hiểu thì rủi ro càng cao.
Những người mới đến thường phàn nàn rằng mật mã là “nghệ thuật thiết kế những thứ xấu nhất có thể”. Các cuộc tấn công nội suy có lẽ phần lớn là đáng trách. Bob có thể sử dụng một thiết kế toán học tao nhã hoặc giữ cuộc hẹn của anh ấy với Alice ở chế độ riêng tư - nhưng than ôi, bạn thường không thể có được cả hai cách. Điều này sẽ trở nên rõ ràng hơn khi cuối cùng chúng ta chuyển sang chủ đề về mật mã khóa công khai.
Giao thức chéo/hạ cấp
Trong Now You See Me (2013), một nhóm ảo tưởng cố gắng lừa lấy toàn bộ tài sản của ông trùm bảo hiểm tham nhũng Arthur Tressler. Để có quyền truy cập vào tài khoản ngân hàng của Arthur, những kẻ ảo thuật phải cung cấp tên người dùng và mật khẩu của anh ta hoặc buộc anh ta phải đích thân đến ngân hàng và tham gia vào kế hoạch.
Cả hai lựa chọn đều rất khó khăn; Các chàng trai đã quen với việc biểu diễn trên sân khấu và không tham gia vào các hoạt động tình báo. Vì vậy, họ chọn phương án thứ ba: đồng phạm của họ gọi đến ngân hàng và giả làm Arthur. Ngân hàng đặt một số câu hỏi để xác minh danh tính, chẳng hạn như tên của người chú và tên của con vật cưng đầu tiên; anh hùng của chúng tôi trước . Kể từ thời điểm này, việc bảo mật mật khẩu tuyệt vời không còn quan trọng nữa.
(Theo một truyền thuyết đô thị mà chúng tôi đã đích thân xác minh và xác minh, nhà mật mã Eli Beaham đã từng gặp một nhân viên giao dịch ngân hàng khăng khăng yêu cầu đặt câu hỏi bảo mật. Khi nhân viên giao dịch hỏi tên bà ngoại của mình, Beaham bắt đầu đọc: “Vốn X, y nhỏ, ba…”).
Trong mật mã cũng vậy, nếu hai giao thức mật mã được sử dụng song song để bảo vệ cùng một tài sản và một giao thức này yếu hơn nhiều so với giao thức kia. Hệ thống kết quả trở nên dễ bị tấn công bởi một cuộc tấn công đa giao thức, trong đó giao thức yếu hơn bị tấn công để giành được giải thưởng mà không chạm vào giao thức mạnh hơn.
Trong một số trường hợp phức tạp, việc liên hệ với máy chủ bằng giao thức yếu hơn là chưa đủ mà còn cần có sự tham gia không tự nguyện của một khách hàng hợp pháp. Điều này có thể được tổ chức bằng cách sử dụng cái gọi là tấn công hạ cấp. Để hiểu cuộc tấn công này, hãy giả sử rằng những người ảo thuật của chúng ta có một nhiệm vụ khó khăn hơn trong phim. Giả sử một nhân viên ngân hàng (thu ngân) và Arthur gặp phải một số tình huống không lường trước được, dẫn đến đoạn hội thoại sau:
Tên trộm: Xin chào? Đây là Arthur Tressler. Tôi muốn đặt lại mật khẩu của mình.
Thu ngân: Tuyệt vời. Vui lòng xem sổ mã bí mật cá nhân của bạn, trang 28, từ 3. Tất cả các tin nhắn sau sẽ được mã hóa bằng từ cụ thể này làm khóa. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Tên trộm: Này, này, chờ đã, chờ đã. Điều này có thực sự cần thiết không? Chúng ta không thể nói chuyện như người bình thường được sao?
Thu ngân: Tôi không khuyên bạn nên làm điều này.
Tên trộm: Tôi chỉ... nhìn này, tôi đã có một ngày tồi tệ, được chứ? Tôi là khách hàng VIP và tôi không có tâm trạng tìm hiểu kỹ những cuốn sách mã ngu ngốc này.
Thu ngân: Khỏe. Nếu ông muốn, ông Tressler. Bạn muốn gì?
Tên trộm: Làm ơn, tôi muốn quyên góp toàn bộ số tiền của mình cho Quỹ Nạn nhân Quốc gia Arthur Tressler.
(Tạm ngừng).
Thu ngân: Bây giờ thì rõ ràng rồi. Vui lòng cung cấp mã PIN của bạn cho các giao dịch lớn.
Tên trộm: Cái gì của tôi?
Thu ngân: Theo yêu cầu cá nhân của bạn, các giao dịch có quy mô này yêu cầu mã PIN cho các giao dịch lớn. Mã này được cấp cho bạn khi bạn mở tài khoản.
Tên trộm:... Tôi mất nó rồi. Điều này có thực sự cần thiết không? Bạn không thể phê duyệt thỏa thuận sao?
Thu ngân: KHÔNG. Tôi xin lỗi, ông Tressler. Một lần nữa, đây là biện pháp bảo mật mà bạn yêu cầu. Nếu bạn muốn, chúng tôi có thể gửi mã PIN mới đến hộp thư của bạn.
Các anh hùng của chúng tôi hoãn hoạt động. Họ nghe lén một số giao dịch lớn của Tressler, hy vọng nghe được mã PIN; nhưng lần nào cuộc trò chuyện cũng trở nên vô nghĩa được mã hóa trước khi có điều gì thú vị được nói ra. Cuối cùng, vào một ngày đẹp trời, kế hoạch được thực hiện. Họ kiên nhẫn chờ đợi khoảnh khắc Tressler phải thực hiện một giao dịch lớn qua điện thoại, anh ta bắt máy và sau đó...
Tressler: Xin chào. Tôi muốn hoàn tất một giao dịch từ xa.
Thu ngân: Tuyệt vời. Xin hãy xem sổ mật mã bí mật cá nhân của bạn, trang...
(Tên trộm nhấn nút; giọng nhân viên thu ngân trở nên ồn ào khó hiểu).
Thu ngân: - #@$#@$#*@$$@#* sẽ được mã hóa bằng từ này làm khóa. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Xin lỗi, tôi chưa hiểu rõ lắm. Lại? Trên trang nào? Từ nào?
Thu ngân: Đây là trang @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Những gì?
Thu ngân: Từ số hai mươi @$#@$#%#$.
Tressler: Nghiêm túc! Đã đủ! Bạn và giao thức bảo mật của bạn giống như một rạp xiếc. Tôi biết rằng bạn có thể nói chuyện với tôi bình thường.
Thu ngân: Tôi không khuyến khích…
Tressler: Và tôi không khuyên bạn lãng phí thời gian của tôi. Tôi không muốn nghe thêm bất kỳ điều gì về điều này cho đến khi bạn khắc phục được sự cố đường dây điện thoại của mình. Chúng ta có thể hoàn tất thỏa thuận này hay không?
Thu ngân:… Đúng. Khỏe. Bạn muốn gì?
Tressler: Tôi muốn chuyển 20 USD tới Lord Business Investments, số tài khoản...
Thu ngân: Làm ơn cho tôi một phút. Đây là một vấn đề lớn. Vui lòng cung cấp mã PIN của bạn cho các giao dịch lớn.
Tressler: Cái gì? Ồ, chính xác. 1234.
Đây là một cuộc tấn công đi xuống. Giao thức yếu hơn "chỉ nói trực tiếp" được hình dung là Lựa chọn trong trường hợp khẩn cấp. Tuy nhiên, ở đây chúng tôi đang có.
Bạn có thể tự hỏi ai có đầu óc tỉnh táo sẽ thiết kế một hệ thống "an toàn cho đến khi được yêu cầu khác" thực sự giống như hệ thống được mô tả ở trên. Nhưng cũng giống như một ngân hàng hư cấu chấp nhận rủi ro để giữ chân những khách hàng không thích mật mã, các hệ thống nói chung thường hướng tới những yêu cầu thờ ơ hoặc thậm chí hoàn toàn thù địch với vấn đề bảo mật.
Đây chính xác là những gì đã xảy ra với giao thức SSLv2 vào năm 1995. Chính phủ Hoa Kỳ từ lâu đã bắt đầu coi mật mã là vũ khí tốt nhất nên tránh xa các kẻ thù trong và ngoài nước. Các đoạn mã đã được phê duyệt riêng lẻ để xuất khẩu từ Hoa Kỳ, thường với điều kiện là thuật toán bị cố tình làm yếu đi. Netscape, nhà phát triển trình duyệt phổ biến nhất, Netscape Navigator, chỉ được cấp quyền cho SSLv2 với khóa RSA 512-bit vốn dễ bị tổn thương (và 40-bit cho RC4).
Vào cuối thiên niên kỷ, các quy tắc đã được nới lỏng và khả năng tiếp cận mã hóa hiện đại trở nên phổ biến rộng rãi. Tuy nhiên, máy khách và máy chủ đã hỗ trợ mật mã "xuất khẩu" yếu trong nhiều năm do quán tính tương tự duy trì sự hỗ trợ cho bất kỳ hệ thống cũ nào. Khách hàng tin rằng họ có thể gặp phải một máy chủ không hỗ trợ bất kỳ thứ gì khác. Các máy chủ cũng làm như vậy. Tất nhiên, giao thức SSL quy định rằng máy khách và máy chủ không bao giờ được sử dụng giao thức yếu khi có sẵn giao thức tốt hơn. Nhưng tiền đề tương tự cũng được áp dụng cho Tressler và ngân hàng của ông ta.
Giả thuyết này đã tìm được đường vào hai cuộc tấn công cấp cao làm rung chuyển tính bảo mật của giao thức SSL vào năm 2015, cả hai đều được phát hiện bởi các nhà nghiên cứu của Microsoft và . Đầu tiên, chi tiết về cuộc tấn công FREAK được tiết lộ vào tháng XNUMX, sau đó ba tháng là một cuộc tấn công tương tự khác có tên Logjam, chúng ta sẽ thảo luận chi tiết hơn khi chuyển sang các cuộc tấn công vào mật mã khóa công khai.
Tính dễ bị tổn thương (còn được gọi là "Smack TLS") được phát hiện khi các nhà nghiên cứu phân tích việc triển khai máy khách/máy chủ TLS và phát hiện ra một lỗi gây tò mò. Trong các triển khai này, nếu máy khách thậm chí không yêu cầu sử dụng mật mã xuất yếu nhưng máy chủ vẫn phản hồi bằng các khóa như vậy thì máy khách sẽ nói “Ồ thôi” và chuyển sang bộ mật mã yếu.
Vào thời điểm đó, mật mã xuất khẩu được nhiều người coi là lỗi thời và nằm ngoài giới hạn, vì vậy cuộc tấn công xảy ra như một cú sốc hoàn toàn và ảnh hưởng đến nhiều lĩnh vực quan trọng, bao gồm các trang web của Nhà Trắng, IRS và NSA. Tệ hơn nữa, hóa ra nhiều máy chủ dễ bị tấn công đã tối ưu hóa hiệu suất bằng cách sử dụng lại các khóa giống nhau thay vì tạo khóa mới cho mỗi phiên. Điều này khiến sau khi hạ cấp giao thức, có thể thực hiện một cuộc tấn công trước khi tính toán: việc bẻ khóa một khóa vẫn tương đối tốn kém ($100 và 12 giờ tại thời điểm xuất bản), nhưng chi phí thực tế của việc tấn công kết nối đã giảm đáng kể. Chỉ cần chọn khóa máy chủ một lần và bẻ khóa mã hóa cho tất cả các kết nối tiếp theo kể từ thời điểm đó là đủ.
Và trước khi chúng ta tiếp tục, có một cuộc tấn công nâng cao cần được đề cập...
Cuộc tấn công của Oracle
được biết đến nhiều nhất với tư cách là cha đẻ của ứng dụng nhắn tin tiền điện tử đa nền tảng Signal; nhưng cá nhân chúng tôi thích một trong những phát minh ít được biết đến của anh ấy - (Nguyên tắc diệt vong mật mã). Diễn giải một chút, chúng ta có thể nói thế này: “Nếu giao thức thực hiện bất kì thực hiện một thao tác mã hóa trên một tin nhắn từ một nguồn có khả năng độc hại và hoạt động khác nhau tùy thuộc vào kết quả, nó sẽ bị tiêu diệt." Hoặc ở dạng sắc nét hơn: “Không được lấy thông tin của đối phương để xử lý, và nếu phải làm vậy thì ít nhất cũng không hiển thị kết quả”.
Hãy bỏ qua vấn đề tràn bộ đệm, chèn lệnh và những thứ tương tự; chúng nằm ngoài phạm vi của cuộc thảo luận này. Vi phạm "nguyên tắc diệt vong" dẫn đến các vụ hack mật mã nghiêm trọng do giao thức hoạt động chính xác như mong đợi.
Ví dụ: hãy lấy một thiết kế hư cấu với mật mã thay thế dễ bị tấn công và sau đó chứng minh một cuộc tấn công có thể xảy ra. Mặc dù chúng ta đã thấy một cuộc tấn công vào mật mã thay thế bằng cách sử dụng phân tích tần số, nhưng đó không chỉ là “một cách khác để phá vỡ cùng một mật mã”. Ngược lại, các cuộc tấn công của oracle là một phát minh hiện đại hơn nhiều, có thể áp dụng cho nhiều tình huống mà việc phân tích tần suất không thành công và chúng ta sẽ xem minh họa điều này trong phần tiếp theo. Ở đây mật mã đơn giản được chọn chỉ để làm cho ví dụ rõ ràng hơn.
Vì vậy, Alice và Bob giao tiếp bằng cách sử dụng một mật mã thay thế đơn giản bằng một khóa mà chỉ họ biết. Họ rất nghiêm ngặt về độ dài của tin nhắn: chúng dài đúng 20 ký tự. Vì vậy, họ đồng ý rằng nếu ai đó muốn gửi một tin nhắn ngắn hơn, họ nên thêm một số văn bản giả vào cuối tin nhắn để nó có đúng 20 ký tự. Sau một hồi thảo luận, họ quyết định rằng họ sẽ chỉ chấp nhận những văn bản giả sau: a, bb, ccc, dddd v.v. Do đó, một văn bản giả có độ dài yêu cầu bất kỳ đều được biết đến.
Khi Alice hoặc Bob nhận được tin nhắn, trước tiên họ phải kiểm tra xem tin nhắn đó có độ dài chính xác (20 ký tự) và hậu tố có phải là văn bản giả chính xác hay không. Nếu không đúng như vậy thì họ sẽ phản hồi bằng một thông báo lỗi thích hợp. Nếu độ dài văn bản và văn bản giả đều ổn thì người nhận sẽ tự đọc tin nhắn và gửi phản hồi được mã hóa.
Trong cuộc tấn công, kẻ tấn công mạo danh Bob và gửi tin nhắn giả cho Alice. Các tin nhắn hoàn toàn vô nghĩa - kẻ tấn công không có khóa và do đó không thể giả mạo một tin nhắn có ý nghĩa. Nhưng vì giao thức vi phạm nguyên tắc diệt vong nên kẻ tấn công vẫn có thể gài bẫy Alice để tiết lộ thông tin quan trọng, như minh họa bên dưới.
Tên trộm:
PREWF ZHJKL MMMN. LAAlice: Văn bản giả không hợp lệ.
Tên trộm:
PREWF ZHJKL MMMN. LBAlice: Văn bản giả không hợp lệ.
Tên trộm:
PREWF ZHJKL MMMN. LCAlice:
ILCT? TLCT RUWO PUT KCAW CPS OWPOW!
Tên trộm không biết Alice vừa nói gì nhưng lưu ý rằng biểu tượng C phải phù hợp với a, vì Alice đã chấp nhận văn bản giả.
Tên trộm:
REWF ZHJKL MMMN. LAAAlice: Văn bản giả không hợp lệ.
Tên trộm:
REWF ZHJKL MMMN. LBBAlice: Văn bản giả không hợp lệ.
Sau nhiều lần thử...
Tên trộm:
REWF ZHJKL MMMN. LGGAlice: Văn bản giả không hợp lệ.
Tên trộm:
REWF ZHJKL MMMN. LHHAlice:
TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.
Một lần nữa, kẻ tấn công không biết Alice vừa nói gì, nhưng lưu ý rằng H phải khớp với b vì Alice đã chấp nhận văn bản giả.
Và cứ như vậy cho đến khi kẻ tấn công biết được ý nghĩa của từng ký tự.
Thoạt nhìn, phương pháp này giống như một cuộc tấn công bằng văn bản gốc đã chọn. Cuối cùng, kẻ tấn công chọn các bản mã và máy chủ sẽ ngoan ngoãn xử lý chúng. Sự khác biệt chính khiến các cuộc tấn công này có thể thực hiện được trong thế giới thực là kẻ tấn công không cần quyền truy cập vào bản ghi thực tế—một phản hồi của máy chủ, ngay cả một phản hồi vô thưởng vô phạt như “Văn bản giả không hợp lệ” là đủ.
Mặc dù cuộc tấn công cụ thể này mang tính hướng dẫn nhưng đừng quá tập trung vào các chi tiết cụ thể của sơ đồ "văn bản giả", hệ thống mật mã cụ thể được sử dụng hoặc chuỗi tin nhắn chính xác do kẻ tấn công gửi. Ý tưởng cơ bản là cách Alice phản ứng khác nhau dựa trên các thuộc tính của bản rõ và làm như vậy mà không cần xác minh rằng bản mã tương ứng có thực sự đến từ một bên đáng tin cậy hay không. Do đó, Alice cho phép kẻ tấn công lấy thông tin bí mật ra khỏi câu trả lời của cô.
Có rất nhiều điều có thể thay đổi trong kịch bản này. Những biểu tượng mà Alice phản ứng lại, hoặc sự khác biệt trong hành vi của cô ấy, hoặc thậm chí cả hệ thống mật mã được sử dụng. Nhưng nguyên tắc sẽ vẫn như cũ và cuộc tấn công nói chung sẽ vẫn khả thi ở hình thức này hay hình thức khác. Việc triển khai cơ bản cuộc tấn công này đã giúp phát hiện ra một số lỗi bảo mật mà chúng tôi sẽ xem xét ngay sau đây; nhưng trước tiên có một số bài học lý thuyết cần phải học. Làm cách nào để sử dụng "kịch bản Alice" hư cấu này trong một cuộc tấn công có thể hoạt động trên một mật mã hiện đại thực sự? Điều này thậm chí có thể thực hiện được, ngay cả trên lý thuyết?
Năm 1998, nhà mật mã học người Thụy Sĩ Daniel Bleichenbacher đã trả lời câu hỏi này một cách khẳng định. Anh ta đã trình diễn một cuộc tấn công oracle vào hệ thống mật mã khóa công khai RSA được sử dụng rộng rãi bằng cách sử dụng một sơ đồ thông báo cụ thể. Trong một số triển khai RSA, máy chủ phản hồi bằng các thông báo lỗi khác nhau tùy thuộc vào việc bản rõ có khớp với sơ đồ hay không; điều này là đủ để thực hiện cuộc tấn công.
Bốn năm sau, vào năm 2002, nhà mật mã người Pháp Serge Vaudenay đã trình diễn một cuộc tấn công tiên tri gần giống với cuộc tấn công được mô tả trong kịch bản Alice ở trên - ngoại trừ việc thay vì một mật mã hư cấu, ông đã phá vỡ toàn bộ một loại mật mã hiện đại đáng nể mà con người thực sự sử dụng. Đặc biệt, cuộc tấn công của Vaudenay nhắm vào các mật mã có kích thước đầu vào cố định ("mật mã khối") khi chúng được sử dụng trong cái gọi là "chế độ mã hóa CBC" và với một sơ đồ đệm phổ biến nhất định, về cơ bản tương đương với sơ đồ trong kịch bản Alice.
Cũng trong năm 2002, nhà mật mã người Mỹ John Kelsey - đồng tác giả — đề xuất các cuộc tấn công oracle khác nhau vào các hệ thống nén tin nhắn và sau đó mã hóa chúng. Đáng chú ý nhất trong số này là một cuộc tấn công lợi dụng thực tế là thường có thể suy ra độ dài ban đầu của bản rõ từ độ dài của bản mã. Về lý thuyết, điều này cho phép thực hiện một cuộc tấn công tiên tri nhằm khôi phục các phần của bản rõ gốc.
Dưới đây chúng tôi cung cấp mô tả chi tiết hơn về các cuộc tấn công Vaudenay và Kelsey (chúng tôi sẽ mô tả chi tiết hơn về cuộc tấn công Bleichenbacher khi chúng tôi chuyển sang các cuộc tấn công vào mật mã khóa công khai). Bất chấp những nỗ lực hết mình của chúng tôi, văn bản vẫn có phần mang tính kỹ thuật; vì vậy nếu những điều trên là đủ đối với bạn, hãy bỏ qua hai phần tiếp theo.
Cuộc tấn công của Vodene
Để hiểu cuộc tấn công Vaudenay, trước tiên chúng ta cần nói thêm một chút về mật mã khối và chế độ mã hóa. Như đã đề cập, "mật mã khối" là mật mã lấy khóa và đầu vào có độ dài cố định nhất định ("độ dài khối") và tạo ra một khối được mã hóa có cùng độ dài. Mật mã khối được sử dụng rộng rãi và được coi là tương đối an toàn. DES hiện đã ngừng hoạt động, được coi là mật mã hiện đại đầu tiên, là mật mã khối. Như đã đề cập ở trên, điều này cũng đúng với AES, được sử dụng rộng rãi ngày nay.
Thật không may, mật mã khối có một điểm yếu rõ ràng. Kích thước khối thông thường là 128 bit hoặc 16 ký tự. Rõ ràng, mật mã hiện đại đòi hỏi phải làm việc với dữ liệu đầu vào lớn hơn và đây là lúc các chế độ mã hóa phát huy tác dụng. Chế độ mã hóa về cơ bản là một cách hack: đó là một cách bằng cách nào đó áp dụng mật mã khối chỉ chấp nhận đầu vào có kích thước nhất định cho đầu vào có độ dài tùy ý.
Cuộc tấn công của Vodene tập trung vào phương thức hoạt động phổ biến của CBC (Chuỗi khối mật mã). Cuộc tấn công coi mật mã khối cơ bản như một hộp đen ma thuật, bất khả xâm phạm và hoàn toàn vượt qua tính bảo mật của nó.
Đây là sơ đồ cho thấy chế độ CBC hoạt động như thế nào:
Dấu cộng được khoanh tròn biểu thị thao tác XOR (OR độc quyền). Ví dụ: khối văn bản mã hóa thứ hai được nhận:
- Bằng cách thực hiện thao tác XOR trên khối văn bản gốc thứ hai với khối văn bản mã hóa đầu tiên.
- Mã hóa khối kết quả bằng mật mã khối bằng khóa.
Vì CBC sử dụng rất nhiều phép toán XOR nhị phân nên chúng ta hãy dành chút thời gian để nhớ lại một số thuộc tính của nó:
- sự bình thường:
- Tính giao hoán:
- Tính kết hợp:
- Tự đảo ngược:
- Kích thước byte: byte n của = (byte n của ) (byte n của )
Thông thường, các thuộc tính này ngụ ý rằng nếu chúng ta có một phương trình bao gồm các phép toán XOR và một phép tính chưa biết thì nó có thể được giải. Ví dụ, nếu chúng ta biết rằng với những điều chưa biết và nổi tiếng и , thì ta có thể dựa vào tính chất nêu trên để giải phương trình . Bằng cách áp dụng XOR cho cả hai vế của phương trình với , chúng tôi nhận được . Tất cả điều này sẽ trở nên rất có liên quan trong một thời điểm.
Có hai điểm khác biệt nhỏ và một điểm khác biệt lớn giữa kịch bản Alice của chúng ta và cuộc tấn công của Vaudenay. Hai cái nhỏ:
- Trong kịch bản, Alice mong đợi bản rõ sẽ kết thúc bằng các ký tự
a,bb,cccvà như thế. Trong cuộc tấn công Wodene, thay vào đó, nạn nhân mong đợi các bản rõ kết thúc N lần bằng N byte (nghĩa là hệ thập lục phân 01 hoặc 02 02 hoặc 03 03 03, v.v.). Đây hoàn toàn là một sự khác biệt về mặt thẩm mỹ. - Trong kịch bản Alice, thật dễ dàng để biết liệu Alice có chấp nhận tin nhắn hay không bằng phản hồi "Văn bản giả không chính xác". Trong cuộc tấn công của Vodene, cần phải phân tích nhiều hơn và việc thực hiện chính xác từ phía nạn nhân là điều quan trọng; nhưng để cho ngắn gọn, hãy coi như việc phân tích này vẫn có thể thực hiện được.
Sự khác biệt chính:
- Vì chúng ta không sử dụng cùng một hệ thống mật mã nên mối quan hệ giữa các byte bản mã do kẻ tấn công kiểm soát và các bí mật (khóa và bản rõ) rõ ràng sẽ khác nhau. Do đó, kẻ tấn công sẽ phải sử dụng một chiến lược khác khi tạo bản mã và giải thích các phản hồi của máy chủ.
Sự khác biệt chính này là mảnh ghép cuối cùng để hiểu cuộc tấn công Vaudenay, vì vậy hãy dành một chút thời gian để suy nghĩ về lý do và cách thức một cuộc tấn công tiên tri vào CBC có thể được thực hiện ngay từ đầu.
Giả sử chúng ta được cấp một bản mã CBC gồm 247 khối và chúng ta muốn giải mã nó. Chúng ta có thể gửi tin nhắn giả đến máy chủ, giống như trước đây chúng ta có thể gửi tin nhắn giả cho Alice. Máy chủ sẽ giải mã tin nhắn cho chúng tôi, nhưng sẽ không hiển thị phần giải mã - thay vào đó, một lần nữa, như với Alice, máy chủ sẽ chỉ báo cáo một bit thông tin: liệu bản rõ có phần đệm hợp lệ hay không.
Hãy xem xét rằng trong kịch bản của Alice, chúng ta có những mối quan hệ sau:
$$display$$text{SIMPLE_SUBSTITUTION}(văn bản{ciphertext},text{key}) = văn bản{plaintext}$$display$$
Hãy gọi đây là "phương trình Alice." Chúng tôi đã kiểm soát bản mã; máy chủ (Alice) đã rò rỉ thông tin mơ hồ về bản rõ nhận được; và điều này cho phép chúng tôi suy ra thông tin về yếu tố cuối cùng - chìa khóa. Bằng cách tương tự, nếu chúng ta có thể tìm thấy mối liên hệ như vậy với tập lệnh CBC, chúng ta cũng có thể trích xuất được một số thông tin bí mật ở đó.
May mắn thay, thực sự có những mối quan hệ ngoài kia mà chúng ta có thể sử dụng. Xem xét đầu ra của lệnh gọi cuối cùng để giải mã mật mã khối và biểu thị đầu ra này là . Chúng ta cũng biểu thị các khối bản rõ và khối bản mã . Hãy nhìn lại sơ đồ CBC và chú ý điều gì sẽ xảy ra:
Hãy gọi đây là “phương trình CBC”.
Trong kịch bản của Alice, bằng cách theo dõi bản mã và theo dõi sự rò rỉ văn bản gốc tương ứng, chúng tôi có thể tiến hành một cuộc tấn công nhằm khôi phục số hạng thứ ba trong phương trình—khóa. Trong kịch bản CBC, chúng ta cũng giám sát bản mã và quan sát sự rò rỉ thông tin trên bản rõ tương ứng. Nếu sự tương tự xảy ra, chúng ta có thể thu được thông tin về .
Giả sử chúng ta thực sự đã khôi phục , sau đó thì sao? Chà, sau đó chúng ta có thể in ra toàn bộ khối văn bản gốc cuối cùng cùng một lúc (), chỉ cần nhập (mà chúng tôi có) và
nhận vào phương trình CBC.
Bây giờ chúng ta đã lạc quan về kế hoạch tấn công tổng thể, đã đến lúc vạch ra các chi tiết. Hãy chú ý đến chính xác thông tin văn bản gốc bị rò rỉ trên máy chủ như thế nào. Trong tập lệnh của Alice, rò rỉ xảy ra do Alice sẽ chỉ phản hồi bằng thông báo chính xác nếu $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ kết thúc bằng dòng a (hoặc bb, v.v., nhưng khả năng những tình trạng này xảy ra do tình cờ là rất nhỏ). Tương tự như CBC, máy chủ chấp nhận phần đệm khi và chỉ khi kết thúc bằng thập lục phân 01. Vì vậy, hãy thử thủ thuật tương tự: gửi bản mã giả với các giá trị giả của chính chúng ta cho đến khi máy chủ chấp nhận điền.
Khi máy chủ chấp nhận phần đệm cho một trong các tin nhắn giả mạo của chúng tôi, điều đó có nghĩa là:
Bây giờ chúng tôi sử dụng thuộc tính XOR byte-byte:
Chúng ta biết điều khoản thứ nhất và thứ ba. Và chúng ta đã thấy rằng điều này cho phép chúng ta khôi phục số hạng còn lại - byte cuối cùng từ :
Điều này cũng cung cấp cho chúng ta byte cuối cùng của khối văn bản gốc cuối cùng thông qua phương trình CBC và thuộc tính từng byte.
Chúng ta có thể để nó ở đó và hài lòng rằng chúng ta đã thực hiện một cuộc tấn công vào một mật mã mạnh về mặt lý thuyết. Nhưng trên thực tế, chúng ta có thể làm được nhiều hơn thế: chúng ta thực sự có thể khôi phục tất cả văn bản. Điều này đòi hỏi một thủ thuật không có trong kịch bản gốc của Alice và không cần thiết cho cuộc tấn công tiên tri, nhưng nó vẫn đáng để học hỏi.
Để hiểu điều đó, trước tiên hãy lưu ý rằng kết quả của việc xuất ra giá trị đúng của byte cuối cùng là chúng ta có một khả năng mới Bây giờ, khi giả mạo bản mã, chúng ta có thể thao tác byte cuối cùng của bản rõ tương ứng. Một lần nữa, điều này liên quan đến phương trình CBC và thuộc tính từng byte:
Vì bây giờ chúng ta đã biết số hạng thứ hai nên chúng ta có thể sử dụng quyền kiểm soát của mình đối với số hạng thứ nhất để kiểm soát số hạng thứ ba. Chúng ta chỉ cần tính toán:
Trước đây chúng tôi không thể làm điều này vì chúng tôi chưa có byte cuối cùng .
Điều này sẽ giúp chúng ta như thế nào? Giả sử bây giờ chúng ta tạo ra tất cả các bản mã sao cho trong bản rõ tương ứng byte cuối cùng bằng 02. Máy chủ bây giờ chỉ chấp nhận phần đệm nếu bản rõ kết thúc bằng 02 02. Vì chúng tôi đã sửa byte cuối cùng nên điều này sẽ chỉ xảy ra nếu byte áp chót của văn bản gốc cũng là 02. Chúng tôi tiếp tục gửi các khối văn bản mã hóa giả, thay đổi byte áp chót cho đến khi máy chủ chấp nhận phần đệm cho một trong số chúng. Tại thời điểm này, chúng tôi nhận được:
Và chúng tôi khôi phục byte áp chót giống như cái cuối cùng đã được khôi phục. Chúng ta tiếp tục với tinh thần tương tự: chúng ta sửa hai byte cuối cùng của bản rõ thành 03 03, chúng tôi lặp lại cuộc tấn công này cho byte thứ ba tính từ cuối, v.v., cuối cùng khôi phục hoàn toàn .
Còn phần còn lại của văn bản thì sao? Xin lưu ý rằng giá trị thực ra là $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Thay vào đó chúng ta có thể đặt bất kỳ khối nào khác , và cuộc tấn công vẫn sẽ thành công. Trên thực tế, chúng tôi có thể yêu cầu máy chủ thực hiện $inline$text{BLOCK_DECRYPT}$inline$ cho bất kỳ dữ liệu nào. Tại thời điểm này, trò chơi kết thúc - chúng ta có thể giải mã bất kỳ bản mã nào (hãy xem lại sơ đồ giải mã CBC để thấy điều này; và lưu ý rằng IV là công khai).
Phương pháp đặc biệt này đóng một vai trò quan trọng trong cuộc tấn công tiên tri mà chúng ta sẽ gặp sau này.
Cuộc tấn công của Kelsey
John Kelsey đồng tình của chúng tôi đã đặt ra các nguyên tắc cơ bản cho nhiều cuộc tấn công có thể xảy ra, không chỉ là chi tiết về một cuộc tấn công cụ thể vào một mật mã cụ thể. Của anh ấy là một nghiên cứu về các cuộc tấn công có thể xảy ra đối với dữ liệu nén được mã hóa. Bạn có nghĩ rằng thông tin dữ liệu được nén trước khi mã hóa không đủ để thực hiện một cuộc tấn công? Hóa ra thế là đủ.
Kết quả đáng ngạc nhiên này là do hai nguyên tắc. Đầu tiên, có mối tương quan chặt chẽ giữa độ dài của bản rõ và độ dài của bản mã; đối với nhiều mật mã có sự bình đẳng chính xác. Thứ hai, khi thực hiện nén, cũng có mối tương quan chặt chẽ giữa độ dài của tin nhắn được nén và mức độ "nhiễu" của bản rõ, tức là tỷ lệ các ký tự không lặp lại (thuật ngữ kỹ thuật là "entropy cao" ).
Để xem nguyên tắc hoạt động, hãy xem xét hai bản rõ:
Bản rõ 1:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABản rõ 2:
ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ
Giả sử cả hai bản rõ đều được nén và sau đó được mã hóa. Bạn nhận được hai bản mã thu được và phải đoán xem bản mã nào khớp với bản rõ nào:
Bản mã 1:
PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTABản mã 2:
DWKJZXYU
Câu trả lời là rõ ràng. Trong số các bản rõ, chỉ có bản rõ 1 có thể được nén thành độ dài ít ỏi của bản mã thứ hai. Chúng tôi đã tìm ra điều này mà không biết gì về thuật toán nén, khóa mã hóa hay thậm chí là bản thân mật mã. So với hệ thống phân cấp của các cuộc tấn công mật mã có thể xảy ra, điều này thật điên rồ.
Kelsey còn chỉ ra thêm rằng trong một số trường hợp bất thường nhất định, nguyên tắc này cũng có thể được sử dụng để thực hiện một cuộc tấn công tiên tri. Cụ thể, nó mô tả cách kẻ tấn công có thể khôi phục bản rõ bí mật nếu hắn có thể buộc máy chủ mã hóa dữ liệu biểu mẫu (bản rõ theo sau là trong khi anh ấy đang kiểm soát và bằng cách nào đó có thể kiểm tra độ dài của kết quả được mã hóa.
Một lần nữa, giống như các cuộc tấn công oracle khác, chúng ta có mối quan hệ:
Một lần nữa, chúng tôi kiểm soát một thuật ngữ (), chúng tôi thấy một rò rỉ nhỏ thông tin về một thành viên khác (bản mã) và cố gắng khôi phục thông tin cuối cùng (bản rõ). Mặc dù có sự tương tự nhưng đây là một tình huống hơi bất thường so với các cuộc tấn công tiên tri khác mà chúng tôi đã thấy.
Để minh họa cách thức hoạt động của một cuộc tấn công như vậy, hãy sử dụng sơ đồ nén giả định mà chúng tôi vừa nghĩ ra: TOYZIP. Nó tìm kiếm các dòng văn bản đã xuất hiện trước đó trong văn bản và thay thế chúng bằng ba byte giữ chỗ cho biết nơi tìm thấy phiên bản trước đó của dòng và số lần nó xuất hiện ở đó. Ví dụ, dòng helloworldhello có thể được nén vào helloworld[00][00][05] Dài 13 byte so với 15 byte ban đầu.
Giả sử kẻ tấn công cố gắng khôi phục bản rõ của một biểu mẫu password=..., trong đó mật khẩu không được biết. Theo mô hình tấn công của Kelsey, kẻ tấn công có thể yêu cầu máy chủ nén và sau đó mã hóa các thông điệp biểu mẫu (bản rõ theo sau là ), Ở đâu - văn bản miễn phí. Khi máy chủ làm việc xong sẽ báo độ dài của kết quả. Cuộc tấn công diễn ra như thế này:
Tên trộm: Vui lòng nén và mã hóa bản rõ mà không có bất kỳ phần đệm nào.
Máy chủ: Độ dài kết quả 14.
Tên trộm: Vui lòng nén và mã hóa bản rõ được thêm vào
password=a.Máy chủ: Độ dài kết quả 18.
Cracker ghi chú: [bản gốc 14] + [ba byte được thay thế password=] + a
Tên trộm: Vui lòng nén và mã hóa bản rõ được thêm vào
password=b.Máy chủ: Độ dài kết quả 18.
Tên trộm: Vui lòng nén và mã hóa bản rõ được thêm vào
password=с.Máy chủ: Độ dài kết quả 17.
Cracker ghi chú: [bản gốc 14] + [ba byte được thay thế password=c]. Điều này giả định rằng bản rõ gốc chứa chuỗi password=c. Tức là mật khẩu bắt đầu bằng một chữ cái c
Tên trộm: Vui lòng nén và mã hóa bản rõ được thêm vào
password=сa.Máy chủ: Độ dài kết quả 18.
Cracker ghi chú: [bản gốc 14] + [ba byte được thay thế password=с] + a
Tên trộm: Vui lòng nén và mã hóa bản rõ được thêm vào
password=сb.Máy chủ: Độ dài kết quả 18.
(…Một lúc sau…)
Tên trộm: Vui lòng nén và mã hóa bản rõ được thêm vào
password=со.Máy chủ: Độ dài kết quả 17.
Cracker ghi chú: [bản gốc 14] + [ba byte được thay thế password=co]. Sử dụng logic tương tự, kẻ tấn công kết luận rằng mật khẩu bắt đầu bằng các chữ cái co
Và cứ như vậy cho đến khi toàn bộ mật khẩu được khôi phục.
Người đọc sẽ được tha thứ nếu nghĩ rằng đây chỉ là một bài tập thuần túy mang tính học thuật và một kịch bản tấn công như vậy sẽ không bao giờ xảy ra trong thế giới thực. Than ôi, như chúng ta sẽ sớm thấy, tốt hơn hết là đừng từ bỏ mật mã.
Lỗ hổng thương hiệu: TỘI PHẠM, POODLE, DROWN
Cuối cùng, sau khi nghiên cứu lý thuyết một cách chi tiết, chúng ta có thể thấy những kỹ thuật này được áp dụng như thế nào trong các cuộc tấn công mật mã trong đời thực.
TỘI ÁC
Nếu cuộc tấn công nhằm vào trình duyệt và mạng của nạn nhân, một số sẽ dễ dàng hơn và một số sẽ khó khăn hơn. Ví dụ: rất dễ dàng để xem tình hình giao thông của nạn nhân: chỉ cần ngồi với anh ta trong cùng một quán cà phê có WiFi. Vì lý do này, các nạn nhân tiềm năng (tức là mọi người) thường được khuyên nên sử dụng kết nối được mã hóa. Sẽ khó khăn hơn nhưng vẫn có thể thực hiện các yêu cầu HTTP thay mặt nạn nhân đến một số trang web của bên thứ ba (ví dụ: Google). Kẻ tấn công phải dụ nạn nhân đến một trang web độc hại bằng đoạn mã thực hiện yêu cầu. Trình duyệt web sẽ tự động cung cấp cookie phiên thích hợp.
Điều này có vẻ tuyệt vời. Nếu Bob đi đến evil.com, tập lệnh trên trang web này có thể yêu cầu Google gửi mật khẩu của Bob qua email tới [email protected]? Vâng, trên lý thuyết thì có, nhưng thực tế thì không. Kịch bản này được gọi là cuộc tấn công giả mạo yêu cầu chéo trang (, CSRF) và nó phổ biến vào khoảng giữa những năm 90. Hôm nay nếu evil.com thử thủ thuật này, Google (hoặc bất kỳ trang web có lòng tự trọng nào) thường sẽ phản hồi bằng "Tuyệt vời, nhưng mã thông báo CSRF của bạn cho giao dịch này sẽ... ừm... три триллиона и семь. Hãy nhắc lại con số này." Các trình duyệt hiện đại có một thứ gọi là "chính sách cùng nguồn gốc", theo đó các tập lệnh trên trang A không có quyền truy cập vào thông tin được gửi bởi trang web B. Vì vậy, tập lệnh trên evil.com có thể gửi yêu cầu đến google.com, nhưng không thể đọc phản hồi hoặc thực sự hoàn tất giao dịch.
Chúng tôi phải nhấn mạnh rằng trừ khi Bob sử dụng kết nối được mã hóa, tất cả các biện pháp bảo vệ này đều vô nghĩa. Kẻ tấn công có thể chỉ cần đọc lưu lượng truy cập của Bob và khôi phục cookie phiên của Google. Với cookie này, anh ta sẽ chỉ cần mở một tab Google mới mà không cần rời khỏi trình duyệt của riêng mình và mạo danh Bob mà không gặp phải các chính sách cùng nguồn gốc phiền toái. Nhưng thật không may cho một tên trộm, điều này ngày càng trở nên ít phổ biến hơn. Internet nói chung từ lâu đã tuyên chiến với các kết nối không được mã hóa và lưu lượng truy cập đi của Bob có thể đã được mã hóa, cho dù anh ấy có muốn hay không. Ngoài ra, ngay từ khi bắt đầu triển khai giao thức, lưu lượng truy cập cũng co lại trước khi mã hóa; đây là cách làm phổ biến để giảm độ trễ.
Đây là nơi nó phát huy tác dụng (Tỷ lệ nén Infoleak Made Easy, rò rỉ đơn giản thông qua tỷ lệ nén). Lỗ hổng này được tiết lộ vào tháng 2012 năm XNUMX bởi các nhà nghiên cứu bảo mật Juliano Rizzo và Thái Dương. Chúng tôi đã xem xét toàn bộ cơ sở lý thuyết, điều này cho phép chúng tôi hiểu họ đã làm gì và làm như thế nào. Kẻ tấn công có thể buộc trình duyệt của Bob gửi yêu cầu tới Google, sau đó lắng nghe phản hồi trên mạng cục bộ ở dạng nén, mã hóa. Vì vậy chúng tôi có:
Ở đây kẻ tấn công kiểm soát yêu cầu và có quyền truy cập vào trình thu thập lưu lượng, bao gồm cả kích thước gói. Kịch bản hư cấu của Kelsey trở nên sống động.
Hiểu lý thuyết, các tác giả của CRIME đã tạo ra một cách khai thác có thể đánh cắp cookie phiên cho nhiều loại trang web, bao gồm Gmail, Twitter, Dropbox và Github. Lỗ hổng này ảnh hưởng đến hầu hết các trình duyệt web hiện đại, dẫn đến các bản vá được phát hành đã âm thầm chôn vùi tính năng nén trong SSL để nó hoàn toàn không được sử dụng. Người duy nhất được bảo vệ khỏi lỗ hổng bảo mật là Internet Explorer đáng kính, vốn không bao giờ sử dụng tính năng nén SSL.
MÓN
Vào tháng 2014 năm XNUMX, nhóm bảo mật của Google đã tạo nên làn sóng trong cộng đồng bảo mật. Họ đã có thể khai thác lỗ hổng trong giao thức SSL đã được vá hơn mười năm trước.
Hóa ra là trong khi các máy chủ đang chạy TLSv1.2 mới, nhiều máy chủ đã để lại hỗ trợ cho SSLv3 cũ để tương thích ngược với Internet Explorer 6. Chúng ta đã nói về các cuộc tấn công hạ cấp, vì vậy bạn có thể tưởng tượng điều gì đang diễn ra. Một vụ phá hoại được dàn dựng khéo léo đối với giao thức bắt tay và các máy chủ đã sẵn sàng quay trở lại SSLv3 cũ, về cơ bản là hủy hoại 15 năm nghiên cứu bảo mật vừa qua.
Đối với bối cảnh lịch sử, :
Transport Layer Security (TLS) là giao thức bảo mật quan trọng nhất trên Internet. [..] hầu hết mọi giao dịch bạn thực hiện trên Internet đều phụ thuộc vào TLS. [..] Nhưng TLS không phải lúc nào cũng là TLS. Giao thức bắt đầu tồn tại vào năm được gọi là "Lớp cổng bảo mật" hoặc SSL. Có tin đồn rằng phiên bản đầu tiên của SSL khủng khiếp đến mức các nhà phát triển đã thu thập tất cả các bản in của mã và chôn chúng tại một bãi rác bí mật ở New Mexico. Kết quả là, phiên bản SSL công khai đầu tiên thực ra là . Nó khá đáng sợ, và [..] nó là sản phẩm của giữa những năm 90, được các nhà mật mã hiện đại coi là "" Nhiều cuộc tấn công mật mã khủng khiếp nhất mà chúng ta biết ngày nay vẫn chưa được phát hiện. Kết quả là, các nhà phát triển giao thức SSLv2 về cơ bản đã phải mò mẫm tìm đường trong bóng tối và họ phải đối mặt với - trước sự thất vọng của họ và lợi ích của chúng tôi, vì các cuộc tấn công vào SSLv2 đã để lại những bài học vô giá cho thế hệ giao thức tiếp theo.
Sau những sự kiện này, vào năm 1996, Netscape thất vọng đã thiết kế lại giao thức SSL từ đầu. Kết quả là SSL phiên bản 3, .
May mắn thay cho những tên trộm, “một vài” không có nghĩa là “tất cả”. Nhìn chung, SSLv3 đã cung cấp tất cả các khối xây dựng cần thiết để khởi động một cuộc tấn công Vodene. Giao thức đã sử dụng mật mã khối chế độ CBC và sơ đồ đệm không an toàn (điều này đã được sửa trong TLS; do đó cần phải thực hiện một cuộc tấn công hạ cấp). Nếu bạn còn nhớ sơ đồ đệm trong mô tả ban đầu của chúng tôi về cuộc tấn công Vaudenay thì sơ đồ SSLv3 rất giống nhau.
Nhưng thật không may cho những tên trộm, “tương tự” không có nghĩa là “giống hệt nhau”. Sơ đồ đệm SSLv3 là "N byte ngẫu nhiên theo sau là số N". Trong những điều kiện này, hãy thử chọn một khối văn bản mã hóa ảo và thực hiện tất cả các bước trong sơ đồ ban đầu của Vaudene: bạn sẽ thấy rằng cuộc tấn công đã trích xuất thành công byte cuối cùng từ khối văn bản gốc tương ứng, nhưng không đi xa hơn. Giải mã từng byte thứ 16 của bản mã là một thủ thuật hay nhưng đó không phải là một chiến thắng.
Đối mặt với thất bại, nhóm Google đã dùng đến biện pháp cuối cùng: họ chuyển sang mô hình mối đe dọa mạnh mẽ hơn - mô hình được sử dụng trong TỘI PHẠM. Giả sử kẻ tấn công là một tập lệnh chạy trong tab trình duyệt của nạn nhân và có thể trích xuất cookie phiên, cuộc tấn công vẫn rất ấn tượng. Mặc dù mô hình mối đe dọa rộng hơn kém thực tế hơn, nhưng trong phần trước chúng ta đã thấy rằng mô hình cụ thể này là khả thi.
Với những khả năng tấn công mạnh mẽ hơn này, cuộc tấn công giờ đây có thể tiếp tục. Lưu ý rằng kẻ tấn công biết cookie phiên được mã hóa xuất hiện ở đâu trong tiêu đề và kiểm soát độ dài của yêu cầu HTTP trước nó. Do đó, nó có thể điều khiển yêu cầu HTTP để byte cuối cùng của cookie được căn chỉnh ở cuối khối. Bây giờ byte này phù hợp để giải mã. Bạn có thể chỉ cần thêm một ký tự vào yêu cầu và byte áp chót của cookie sẽ vẫn ở cùng một vị trí và phù hợp để lựa chọn bằng cùng một phương pháp. Cuộc tấn công tiếp tục theo cách này cho đến khi tệp cookie được khôi phục hoàn toàn. Nó được gọi là POODLE: Đệm Oracle về Mã hóa kế thừa bị hạ cấp.
CHẾT CHÌM
Như chúng tôi đã đề cập, SSLv3 có những sai sót, nhưng về cơ bản nó khác với phiên bản trước, vì SSLv2 bị rò rỉ là sản phẩm của một thời đại khác. Ở đó bạn có thể làm gián đoạn tin nhắn ở giữa: соглашусь на это только через мой труп đã trở thành соглашусь на это; máy khách và máy chủ có thể gặp nhau trực tuyến, thiết lập lòng tin và trao đổi bí mật trước mặt kẻ tấn công, kẻ sau đó có thể dễ dàng mạo danh cả hai. Ngoài ra còn có vấn đề với mật mã xuất khẩu mà chúng tôi đã đề cập khi xem xét FREAK. Đây là mật mã Sodom và Gomorrah.
Vào tháng 2016 năm 2, một nhóm các nhà nghiên cứu từ các lĩnh vực kỹ thuật khác nhau đã cùng nhau hợp tác và đưa ra một khám phá đáng kinh ngạc: SSLv2 vẫn được sử dụng trong các hệ thống bảo mật. Có, những kẻ tấn công không thể hạ cấp phiên TLS hiện đại xuống SSLv2 nữa vì lỗ hổng đó đã bị đóng sau FREAK và POODLE, nhưng chúng vẫn có thể kết nối với máy chủ và tự khởi tạo phiên SSLvXNUMX.
Bạn có thể hỏi, tại sao chúng ta quan tâm đến những gì họ làm ở đó? Họ có một phiên dễ bị tấn công nhưng nó sẽ không ảnh hưởng đến các phiên khác hoặc tính bảo mật của máy chủ - phải không? Vâng, không hẳn. Vâng, về mặt lý thuyết thì nó phải như vậy. Nhưng không - vì việc tạo chứng chỉ SSL đặt ra một gánh nặng nhất định, dẫn đến nhiều máy chủ sử dụng cùng một chứng chỉ và do đó, có cùng khóa RSA cho các kết nối TLS và SSLv2. Tệ hơn nữa, do lỗi OpenSSL, tùy chọn "Tắt SSLv2" trong triển khai SSL phổ biến này đã không thực sự hoạt động.
Điều này có thể tạo ra một cuộc tấn công đa giao thức vào TLS, được gọi là (Giải mã RSA bằng mã hóa lỗi thời và yếu đi, giải mã RSA bằng mã hóa lỗi thời và yếu đi). Hãy nhớ lại rằng đây không giống như một cuộc tấn công ngắn; kẻ tấn công không cần phải đóng vai trò là "người ở giữa" và không cần lôi kéo khách hàng tham gia vào một phiên không an toàn. Những kẻ tấn công chỉ cần bắt đầu một phiên SSLv2 không an toàn với chính máy chủ, tấn công giao thức yếu và khôi phục khóa riêng RSA của máy chủ. Khóa này cũng hợp lệ đối với các kết nối TLS và kể từ thời điểm này trở đi, không có mức độ bảo mật TLS nào có thể ngăn chặn nó bị xâm phạm.
Nhưng để bẻ khóa nó, bạn cần có một cuộc tấn công hiệu quả chống lại SSLv2, nó cho phép bạn khôi phục không chỉ lưu lượng truy cập cụ thể mà còn cả khóa máy chủ RSA bí mật. Mặc dù đây là một thiết lập phức tạp nhưng các nhà nghiên cứu có thể chọn bất kỳ lỗ hổng nào đã được đóng hoàn toàn sau SSLv2. Cuối cùng họ đã tìm ra một lựa chọn phù hợp: cuộc tấn công Bleichenbacher, mà chúng tôi đã đề cập trước đó và chúng tôi sẽ giải thích chi tiết trong bài viết tiếp theo. SSL và TLS được bảo vệ khỏi cuộc tấn công này, nhưng một số tính năng ngẫu nhiên của SSL, kết hợp với các khóa ngắn trong mật mã cấp xuất khẩu, đã khiến điều đó trở nên khả thi. .
Tại thời điểm xuất bản, 25% các trang web hàng đầu trên Internet bị ảnh hưởng bởi lỗ hổng DROWN và cuộc tấn công có thể được thực hiện với nguồn lực khiêm tốn dành cho ngay cả những tin tặc đơn độc tinh quái. Việc truy xuất khóa RSA của máy chủ cần 440 giờ tính toán và tốn 2 USD, đồng thời SSLvXNUMX từ lỗi thời trở thành có tính phóng xạ.
Đợi đã, còn Heartbleed thì sao?
Đây không phải là một cuộc tấn công mật mã theo nghĩa được mô tả ở trên; Đây là lỗi tràn bộ đệm.
Chúng ta hãy nghỉ ngơi
Chúng tôi bắt đầu với một số kỹ thuật cơ bản: vũ lực, nội suy, hạ cấp, giao thức chéo và tính toán trước. Sau đó, chúng tôi xem xét một kỹ thuật tiên tiến, có lẽ là thành phần chính của các cuộc tấn công mật mã hiện đại: cuộc tấn công oracle. Chúng tôi đã dành khá nhiều thời gian để tìm hiểu - và không chỉ hiểu nguyên tắc cơ bản mà còn hiểu chi tiết kỹ thuật của hai cách triển khai cụ thể: cuộc tấn công Vaudenay vào chế độ mã hóa CBC và cuộc tấn công Kelsey vào các giao thức mã hóa nén trước.
Khi xem xét các cuộc tấn công hạ cấp và tính toán trước, chúng tôi đã phác thảo ngắn gọn về cuộc tấn công FREAK, sử dụng cả hai phương pháp bằng cách hạ cấp các trang web mục tiêu xuống các khóa yếu và sau đó sử dụng lại các khóa tương tự. Đối với bài viết tiếp theo, chúng tôi sẽ lưu lại cuộc tấn công Logjam (rất giống), nhắm vào các thuật toán khóa công khai.
Sau đó chúng tôi xem xét thêm ba ví dụ khác về việc áp dụng những nguyên tắc này. Đầu tiên, CRIME và POODLE: hai cuộc tấn công dựa vào khả năng của kẻ tấn công để chèn văn bản gốc tùy ý bên cạnh văn bản gốc đích, sau đó kiểm tra phản hồi của máy chủ và sau đó,sử dụng phương pháp tấn công oracle, khai thác thông tin thưa thớt này để khôi phục một phần bản rõ. CRIME đã đi theo con đường tấn công của Kelsey vào tính năng nén SSL, trong khi POODLE thay vào đó sử dụng một biến thể tấn công của Vaudenay vào CBC với tác dụng tương tự.
Sau đó, chúng tôi chuyển sự chú ý sang cuộc tấn công DROWN đa giao thức, cuộc tấn công này thiết lập kết nối với máy chủ bằng giao thức SSLv2 cũ và sau đó khôi phục các khóa bí mật của máy chủ bằng cuộc tấn công Bleichenbacher. Hiện tại chúng tôi đã bỏ qua các chi tiết kỹ thuật của cuộc tấn công này; giống như Logjam, nó sẽ phải đợi cho đến khi chúng ta hiểu rõ về hệ thống mật mã khóa công khai và các lỗ hổng của chúng.
Trong bài viết tiếp theo, chúng ta sẽ nói về các cuộc tấn công nâng cao như tấn công gặp nhau, phân tích mật mã vi sai và tấn công sinh nhật. Chúng ta hãy nhanh chóng thâm nhập vào các cuộc tấn công kênh bên, sau đó chuyển sang phần thú vị: hệ thống mật mã khóa công khai.
Nguồn: www.habr.com