Chuẩn IEEE 802.11i cung cấp có hiệu quả một số dịch vụ an ninh; tuy nhiên, có một số lỗ hổng bảo mật được phát hiện ra trong một vài năm gần đây. Ta sẽ thảo luận về các lỗ hổng, các tấn công lợi dụng những lỗ hổng này, và những cơ chế ngăn chặn.
Sinh ra AAD Sinh ra Nonce Mã hoá CCM Sinh ra CCMP header Tăng PN || Plaintext MPDU Key PN KeyID Dữ liệu
A2 Priority Dữ liệu đã mã hoá, MIC MAC header
2.3.2.1. Lỗ hổng của IEEE 802.1X [9]
IEEE 802.1X sử dụng chuẩn IEEE802.11i để phân phối và xác thực khoá. Ba thực thể: thiết bị nhận yêu cầu xác thực (Authenticator), người cần xác thực (Supplicant) và máy chủ xác thực (Authenticator server) tham gia cùng một tiến trình. Giả định cơ bản là giao thức xác thực luôn luôn đáng tin cậy. Do đó, supplicant không xác minh thông báo nhận được từ authenticator và đáp ứng vô điều kiện đối với thông báo này. Tuy nhiên, trong thực tế đối thủ cũng có thể thực hiện xác thực, điều này làm cho giao thức dữ bị tổn thương dẫn đến tấn công cướp quyền và tấn công người ở giữa (man-in-the-midle). Hình 2.11 chỉ ra cách đối thủ có thể khai thác lỗ hổng đã đề cập ở trên để tấn công cướp quyền điều khiển. Đối thủ có thể chờ đến khi authenticator và supplicant hoàn thành quá trình xác thực và authenticator gửi thông báo EAP success đến supplicant. Theo đó, đối thủ gửi một thông báo phân tách (disassociate message) đến supplicant với IP giả của authenticator. Supplicant cho rằng phiên làm việc đã bị ngắt bởi authenticator là thông báo không xác thực tính toàn vẹn. Đối thủ giành được quyền truy cập vào mạng bằng cách giả mạo địa chỉ MAC của supplicant và truy cập với một thủ tục xác thực lẫn nhau sử dụng phương pháp bắt tay bốn bước.
Hình 2.11: Tấn công cướp quyền điều khiển trong cơ chế xác thực 802.1X
Hình 2.12 cho thấy một tấn công người ở giữa được đối thủ thực hiện khi khai thác vào IEEE 802.1X. Sau khi thiết lập trao đổi thông báo EAP request và response giữa supplicant và authenticator, đối thủ gửi thông báo EAP success đến supplicant sử dụng địa chỉ MAC của chính nó. Vì giao thức IEEE 802.1X thừa nhận quá trình chuyển đổi vô điều kiện dựa trên việc nhận thông báo EAP success của supplicant, suplicant cho rằng đây là xác thực của authenticator và thay đổi trạng thái. Khi authenticator gửi thông báo EAP success, supplicant đã qua trạng thái này và đang đợi thông báo thành công, do đó nó không phản ứng với thông báo này. Supplicant cho rằng đổi thủ là authenticator hợp pháp trong khi đối thủ có thể dễ dàng giả mạo địa chỉ MAC của supplicant để giao tiếp với authenticator. Do đó, đối thủ sẽ trở thành trung gian giữa supplicant và authenticator. Giải pháp đề xuất để ngăn chặn tấn công nay là đề nghị kiểm tra xác thực và toàn vẹn thông báo EAP giữa authenticator và supplicant. Giải pháp cũng đề xuất sự chấp thuận
Authenticator Supplicant Địch thủ EAP request EAP response … … EAP success Supplicant đã xác thực Ngắt kết nối 802.11 MAC
Lưu lượng mạng Chiếm kết nối mạng
Giả mạo địa chỉ MAC của authenticator
của mô hình chứng thực dựa trên mạng ngang hàng (peer - to - peer) khi authenticator và supplicant hoạt động giống như các peer và supplicant kiểm tra thông báo từ authenticator trong quá trình thiết lập tin cậy. Mô hình peer to peer được cho là thích hợp cho mạng không dây mesh khi cả authenticator và supplicant đều là WMN router.
Hình 2.12: Tấn công man-in-the-midle trong cơ chế xác thực 802.1X
2.3.2.2. Những lỗ hổng của quá trình bắt tay bốn bước [7]
Quá trình bắt tay bốn bước là cơ chế sử dụng sự xác thực lẫn nhau của supplicant và authenticator trong IEEE 802.11i. Quá trình bắt tay bắt đầu sau khi cặp khoá chủ thông minh (PMK) được phân phối đến supplicant và authenticator. Supplicant đợi một khoảng thời gian nhất định cho thông báo 1 của quá trình bắt tay từ authenticator. Nếu không nhận được thông báo, supplicant tách nó ra khỏi authenticator. Lưu ý rằng thời gian chỉ được supplicant sử dụng. Nếu supplicant nhận được thông báo 1, supplicant phải trả lời tất cả các thông báo từ authenticator và chờ đến khi nhận được hồi đáp. Mặt khác, authenticator sẽ time-out mọi thông báo nếu không nhận được hồi đáp nó chờ đợi sau một khoảng thời gian cụ thể. Thêm vào đó, supplicant sẽ không được xác thực nếu hồi đáp không được nhận sau một vài lần thử. Lưu ý rằng cả authenticator và supplicant đều tự bỏ thông báo nếu mã toàn vẹn thông báo (MIC) của thông báo không xác minh được. Cơ chế này của quá trình bắt tay bốn bước có nhược điểm là dễ bị tấn công từ chối dịch vụ. Theo Hình 2.13, authenticator gửi thông báo 1 cho supplicant. Lưu ý rằng thông báo 1 không mã hoá. Supplicant sinh ra SNonce mới và sau đó sử dụng ANonce, SNonce và một số trường khác sinh ra PTK và trả lời bằng thông báo 2, thông báo này được mã hoá bằng PTK. Tại thời điểm này, đối thủ gửi tin nhắn độc hại 1 với địa chỉ MAC giả của authenticator. Supplicant chắc chắn sẽ trả lời thông báo này. Giả sử rằng thông báo 2 đó được gửi đến authenticator bị mất và authenticator truyền lại thông báo 1. Vì thế, PTK* được tính toán lại (khác với PTK cũ và ghi đè lên PTK cũ) dựa trên ANonce đã được đối thủ gửi và gửi thông báo 2 một lần nữa sử dụng mã hoá PTK*. Trong khi đó, authenticator trả lời thông báo 2 đầu tiên của supplicant bằng thông báo 3 sử dụng PTK. Kiểm tra toàn vẹn thông báo 3 trên supplicant sẽ báo lỗi vì supplicant bây giờ sử dụng PTK* trong khi authenticator sử dụng PTK để mã hoá. Kết quả là quá trình bắt tay bốn
Authenticator Địch thủ Supplicant EAP request EAP response EAP success Supplicant đã xác thực No action Lưu lượng mạng EAP success Supplicant chuyển trạng thái
bước bị khoá cho đến khi authenticator không xác thực supplicant sau vài lần thử, và từ chối dịch vụ đối với supplicant.
Lưu ý rằng bất cứ lúc nào supplicant nhận được thông báo 1, nó sẽ sinh ra một SNonce mới ràng buộc với ANonce (được truyền ở thông báo 1 của authenticator) và một số thông tin khác để sinh ra PTK. Giải pháp hiệu quả nhất được đề xuất để ngăn chặn tấn công nói trên là supplicant nên lưu lại SNonce được tạo ra trong quá trình trả lời thông báo 1 nhận được từ authenticator. Một SNonce như vậy cũng nên được sử dụng cho các thông báo 1 tiếp theo cho đến khi supplicant nhận được thông báo 3 từ authenticator. Khi nhận được thông báo 3, supplicant nên sử dụng ANonce của thông báo 3 và SNonce đã lưu để sinh ra PTK một lần nữa, PTK này sẽ được dùng để mã hoá thông báo 3. Việc sử dụng cùng một SNonce và ANonce sẽ sinh ra cùng một PTK nếu các thông tin khác vẫn không thay đổi. Do đó, supplicant sẽ có thể trả lời được thông báo 3 hợp lên thậm chí nó nhận được nhiều thông báo 1 từ đối thủ. Lưu ý rằng đổi thủ không thể gửi thông báo 3 độc hại được bởi vì thông báo 3 dùng PTK để mã hoá, điều này phụ thuộc vào PMK (chỉ có supplicant và authenticator biết).
Hình 2.13: Tấn công từ chối dịch vụ trong quá trình bắt tay bốn bước 2.3.2.3. Những lỗ hổng trong mã hoá CCMP [17]
Mặc dù CCMP (được sử dụng bởi IEEE 802.11i) sử dụng mã hoá CCM, sức mạnh trong đó là thời gian thử nghiệm, giao thức vẫn có thể bị tấn công bằng tấn công từng phần và tấn công tính toán trước. Trường địa chỉ A2, trường priority của tiêu đề MAC và trường PN trong tiêu đề CCMP được truyền phát bằng bản gốc trên các header và cũng được ở dạng mã hoá như là một phần của mã xác thực thông báo. Điều này dẫn đến việc tấn công kết hợp từng phần và các nhà nghiên cứu đã chỉ ra rằng độ mạnh của mã hoá 128-bit được sử dụng trong CCMP sẽ bị suy giảm. Sự suy giảm độ mạnh của khoá làm lộ ra các tấn công giao thức có tính toán trước, kết quả dẫn đến việc làm tổn thương các dữ liệu
Authenticator Kẻ tấn công Supplicant
Msg1: ANonce Tạo ra PTK Msg1: Snonce, MICPTK Msg1: Anonce* Tạo ra GTK Tạo ra PTK* Msg3: GTK, MICPTK (PTK bị ghi đè) PTK và PTK* khác nhau nên MIC không được kiểm
tra, giao thức bị khoá
(Kẻ tấn công gửi thông báo với địa chỉ MAC giả của authenticator)
bảo mật và dữ liệu toàn vẹn. Hơn nữa, quá trình mã hoá CCM được chia làm hai giai đoạn. Trong giai đoạn đầu, mã toàn vẹn thông báo sẽ được tính toán, việc mã hoá diễn ra ở giai đoạn hai. Tương tự như vậy, việc giải mã cũng được diễn ra trong hai giai đoạn. Ở đó, đầu tiên thông báo toàn vẹn được xác nhận bởi mã toàn vẹn thông báo và sau đó quá trình giải mã diễn ra. Hai giai đoạn này thực hiện tại mỗi liên kết không dây có thể dẫn đến việc chậm trễ đáng kể trong trường hợp các mạng không dây đa hop như mạng không dây mesh khi mà dữ liệu đi qua một số hop trung gian trước khi đến được nút Internet có dây. Sự trì hoãn được đưa ra bởi các dịch vụ bảo mật sẽ dẫn đến việc không thể thực hiện được giao thức CCMP cho các mạng không dây lớn có nhiều nút trung gian.