2.3.1.1. Vấn đề chứng thực
Có hai vấn đề cần phải quan tâm khi nói đến WEP, đầu tiên là chứng thực và thứ hai là mã hóa.
Với IEEE 802.11 WEP [7], trong giai đoạn chứng thực một thiết bị mới phải chứng minh rằng nó đúng là thành viên của nhóm, vậy nó chứng minh bằng cách nào? Về phía AP mà nói, nếu một thiết bị có thể chứng tỏ nó đúng là đáng tin cậy thì có thể tin địa chỉ MAC của nó không phải là địa chỉ giả mạo và nó cho phép thiết bị mới này kết nối vào mạng. Tuy nhiên thật không may là chẳng có dấu hiệu đảm bảo nào được sử dụng trong quá trình chứng thực vì thế mà chẳng có cơ sở để biết liệu gói tin đến từ thiết bị đáng tin cậy hay là không. Kiểu chứng thực này thực sự không đảm bảo tin cậy và do đó nó đã bị loại bỏ khỏi tính năng của WLAN, cho dù là nó nằm trong chuẩn IEEE 802.11.
Dù yếu nhưng một số hệ thống vẫn sử dụng kiểu chứng thực của chuẩn IEEE 802.11 ban đầu. Chúng ta đã biết rằng IEEE 802.11 sử dụng 3 kiểu gói tin là gói tin điều khiển, gói tin quản lý và gói tin dữ liệu. Giai đoạn chứng thực sử dụng gói tin quản lý, để chứng thực trong trường hợp không có bảo mật STA gửi một gói tin yêu cầu chứng thực và AP gửi trả lại gói tin báo chứng thực thành công. Đối với chứng thực dựa trên WEP có 4 gói tin được trao đổi. Đầu tiên STA gửi yêu cầu chứng thực, sau đó AP gửi trả lại một gói tin challenge. STA đáp lại gói tin challenge đó để chứng tỏ rằng nó biết khóa bảo mật và nếu được chấp nhận AP sẽ gửi lại gói tin báo chứng thực thành công.
Hình 2.8: Quá trình chứng thực diễn ra trong WEP
Về mặt nguyên tắc, nếu một AP hoạt động ở chế độ không có bảo mật nó luôn luôn chấp nhận các yêu cầu chứng thực và đáp lại với một gói tin báo chứng thực thành công. Tuy nhiên, trong thực tế nhiều hệ thống cung cấp các phương pháp riêng của mình, phổ biến nhất là sử dụng danh sách địa chỉ MAC. AP có một danh sách các địa chỉ MAC mà nó cho phép truy nhập vào mạng. Danh sách này do người quản trị tạo ra và lưu lại trên AP. Quá trình chứng thực dựa vào danh sách này, tức là nếu STA có địa chỉ MAC nằm trong danh sách thì nó được phép truy cập vào mạng, nếu không, nó sẽ bị từ chối. Đương nhiên là không thể ngăn chặn được những địa chỉ MAC giả, nhưng dù sao thì nó cũng có tác dụng nhất định nhằm tránh việc vô tình truy cập nhầm mạng.
Chứng thực WEP với mục đích là chứng minh với AP rằng STA biết khóa bảo mật. Khi một STA yêu cầu chứng thực, AP gửi tới nó một số ngẫu nhiên được gọi là challenge text. Đây là một số 128 bit bất kỳ (giả ngẫu nhiên). STA sau đó mã hóa số này bằng khóa bảo mật và gửi trả lại cho AP. Do AP đã lưu lại số ngẫu nhiên mà nó đã gửi đi, đồng thời nó cũng có khóa
bảo mật mà STA có từ đó nó có thể giải mã số mà STA gửi đến, so sánh hai kết quả nếu hai kết quả trùng nhau thì STA đó là thiết bị biết khóa mật mã và đáng tin cậy. Ở đây có một vấn đề là STA chẳng có cách nào biết được liệu AP có biết khóa bảo mật hay không. Nếu một kẻ nào đó đang theo dõi, thì vô tình ta đã cho hắn ta một cơ hội bẻ khóa vì hắn đã có thể có trong tay cả số ngẫu nhiên và số đã được mã hóa bằng khóa bảo mật, dựa vào đó có thể tìm ra khóa. Đó cũng là lý do tại sao hiệp hội Wifi Alliance loại bỏ kiểu trao đổi này.
Dưới đây là định dạng của gói tin chứng thực, cho dù nhiều gói tin được trao đổi nhưng nó có chung một dạng:
Algorithm Num Transaction Seq Status Code Challenge Text Hình 2.9: Định dạng của gói tin chứng thực
Algorithm Num: chỉ kiểu chứng thực được sử dụng: 0 – Không có bảo mật.
1 – Có sử dụng khóa bảo mật (WEP).
Transaction Seq: chỉ ra ta đang ở phần nào của quá trình chứng thực. Gói tin thứ nhất ứng với giá trị 1, gói tin thứ hai ứng với giá trị 2 và gói tin thứ 3 (chỉ dùng với WEP) có giá trị là 3.
Status Code: được gửi cuối cùng để thông báo yêu cầu chứng thực có thành công hay không.
Challenge Text: là số ngẫu nhiên như đã được nói ở trên. 2.3.1.2. Vấn đề mã hóa
Ngoài việc chứng thực, mã hóa là một phần không thể thiếu được khi nói đến WEP. Để bảo vệ những thông tin cần thiết, tránh nguy cơ bị lộ thông tin thì mã hóa chính là giải pháp được tính đến.
Khi WEP được kích hoạt, dữ liệu được truyền đi dưới dạng mã hóa nên những kẻ tấn công có lấy được gói tin cũng không giải mã được. Để giải mã
gói tin chúng ta phải biết khóa. Chuẩn IEEE 802.11 ban đầu đã đưa ra 2 quá trình: trước hết là phải chứng thực sau đó mới mã hóa. Như đã nói ở phần trước, phương pháp chứng thực ở đây gần như không có ý nghĩa, nó đôi khi còn nguy hơn là không sử dụng. Vì thế, hầu hết các hệ thống WLAN bỏ qua giai đoạn chứng thực và chuyển luôn sang mã hóa sau khi đã tạo được kết nối. Các hệ thống bảo mật có thể dựa vào việc mã hóa theo chuỗi hoặc mã hóa khối. WEP sử dụng thuật toán mã hóa chuỗi gọi là RC4 để mã hóa các gói dữ liệu. RC4 là tên viết tắt của Rivest Cipher 4 do Ron Rivest thiết kế vào năm 1987. Ở mức độ cao nhất, RC4 giống như là một hộp đen, nó lấy một byte từ chuỗi dữ liệu và tạo một byte khác tương ứng ở đầu ra. Việc giải mã là quá trình ngược lại và vẫn sử dụng khóa như quá trình mã hóa.
Hình 2.10: Mã hóa chuỗi
Một trong những ưu điểm của RC4 là nó dễ thực hiện và không sử dụng bất kỳ các phép toán phức tạp hay tốn thời gian tính toán nào giống như phép nhân. Nói chung đây cũng là một thách thức đối với những nhà thiết kế thuật toán, làm sao để thỏa mãn vừa đảm bảo tính bảo mật lại vừa dễ thực hiện. Có 2 giai đoạn chính trong việc dùng thuật toán RC4. Giai đoạn đầu là khởi tạo: một số bảng dữ liệu được tạo nên dựa trên khóa đã cho, giai đoạn hai: dữ liệu được đưa qua dây truyền mã. Trong trường hợp đối với WEP, cả giai đoạn khởi tạo và giai đoạn mã hóa xảy ra đối với từng gói. Mỗi gói được coi như là một chuỗi dữ liệu, điều này đảm bảo rằng nếu một gói bị mất thì gói tin tiếp theo vẫn có thể giải mã được. Có một vấn đề trong việc sử dụng giá trị khóa cố định. Cho dù khóa đó có được thay đổi đi chăng nữa, nó vẫn gặp phải vấn đề đối với các gói tin khi đi qua hệ thống mã hóa đó là tất
cả các gói tin được mã hóa với cùng một khóa. Giả sử ta dùng thuật toán RC4 với khóa đã cho và với dữ liệu là “asfecewa” và giả sử ta thu được đoạn mã “&(#cheiv”. Nó trông có vẻ ngẫu nhiên, tuy nhiên, do khóa không thay đổi nên cứ lần nào ta cho dữ liệu vào là “asfecewa” thì cũng được kết quả tương tự như trên. Một mặt nào đó nó có thể chấp nhận được nhưng mặt khác nó lại là một mối nguy hiểm, tạo điều kiện cho kẻ khác cơ hội giải mã. Nếu như biết được các đoạn dữ liệu mã hóa giống nhau tại những vị trí cho trước có thể đoán được là dữ liệu ban đầu có sự lặp lại. Để giải quyết tình huống này vector khởi tạo IV được sử dụng, nó là một khái niệm khá đơn giản. Thay vì chỉ sử dụng khóa cố định để mã hóa ta có thể kết hợp khóa này với 24 bit để làm sao cho mỗi gói tin mã hóa sẽ khác nhau cho dù nội dung của chúng có giống nhau. Số 24 bit này chính là vector khởi tạo IV, nó biến khóa 104 bit thành khóa 128 bit. Gọi là mã hóa 128 bit nghe có vẻ không được đúng cho lắm vì IV được gửi đi cùng với gói tin được mã hóa nhưng chính nó lại không được mã.
Hình 2.11: Sự kết hợp của IV với khóa
Do giá trị của IV luôn thay đổi nên khi kết hợp với khóa để mã hóa đã tạo ra các gói tin được mã hoàn toàn khác nhau cho dù dữ liệu được mã giống nhau. Để đảm bảo an toàn, không bao giờ được sử dụng 2 lần cùng một IV với cùng một khóa. Do IV không được mã hóa và dễ dàng đọc được từ gói tin gửi đi nên việc lưu lại để so sánh với các giá trị sau là việc đơn giản.
Một điều không may là IV trong IEEE 802.11 WEP chỉ có 24 bit mà thôi. Giá trị này có vẻ khá lớn nhưng tính toán một lúc ta sẽ thấy nó quả
thực không phải như vậy. Một số 24 bit sẽ có giá trị từ 0 đến 16777216, tức là vào khoảng gần 17 triệu giá trị IV khác nhau. Nếu một AP hoạt động liên tục với tốc độ 11 Mbps có thể truyền và nhận 700 gói có kích thước trung bình trong một giây. Nếu mỗi gói ứng với một IV khác nhau thì không đầy 7 tiếng sau nó đã cạn kiệt. Do rất ít người thay đổi khóa mỗi ngày nên việc sử dụng lại IV chắc chắn sẽ xảy ra.
Những vấn đề với IV chỉ ra rằng thực sự là khó thiết kế các giao thức bảo mật dựa trên việc mã hóa chuỗi bởi vì trạng thái của quá trình mã hóa không được khởi động lại trong toàn bộ chuỗi đó. Một phiên bản khác của WEP là TKIP cũng dựa trên RC4 nhưng khắc phục được việc tái sử dụng IV sẽ được đề cập đến ở phần sau.
2.3.1.3. Cơ chế hoạt động của WEP
Nếu trong một mạng có kết nối WLAN thì dữ liệu bao giờ cũng phải đi qua tầng dịch vụ mạng IEEE 802.11 MAC. Hay nói một cách khác, gói dữ liệu tới WLAN cùng với những thông tin cần thiết để gửi gói tin đến đích, gói dữ liệu này được gọi là một MSDU. Nếu không gặp lỗi nào, MSDU này sẽ được gửi đến tầng dịch vụ MAC của thiết bị đích và sẽ được hệ điều hành hay trình điều khiển đưa đến đúng ứng dụng đang chạy. Tuy nhiên, trước khi được chuyển thành dạng sóng điện từ, MSDU có thể được chia thành những phần nhỏ hơn, gọi là các phân mảnh (fragment). Mỗi một fragment được mã hóa bởi WEP. Một MAC header được gắn vào phần đầu và từ kiểm tra được gắn vào phần cuối. Như vậy, từ một MSDU ban đầu sẽ được phân chia ra thành các phần dữ liệu nhỏ hơn (fragment), đồng thời các byte thông tin khác cũng được thêm vào chứ không chỉ có mỗi phần dữ liệu được mã hóa. Mỗi phần nhỏ đó được gọi là một MPDU. Quá trình này coi dữ liệu như một khối gồm các byte, độ lớn tùy theo MSDU ban đầu cũng như việc chọn lựa độ lớn của fragment, nó thường có giá trị từ 10 đến 1500 byte.
Bước đầu tiên trong quá trình mã hóa là thêm giá trị kiểm tra tính toàn vẹn ICV.
Mục đích của việc sử dụng ICV là để phát hiện sự thay đổi nội dung gói tin trong quá trình nó được truyền đi. Đối với cả các gói tin được mã và không được mã, cần có một số kiểm tra nhằm phát hiện bit sai lệch trong quá trình truyền tin. CRC là một số 4 byte được thêm vào cuối của khung ngay trước khi xử lý để truyền. Nếu có một bit bị sai, bên thu sẽ phát hiện ra ngay dựa vào giá trị CRC và hủy gói tin đó. Có nhiều khi không phát hiện được sự thay đổi này do kẻ gian đã tính toán lại giá trị CRC và thay nó vào gói tin.
ICV cũng tương tự như CRC, chỉ có điều nó được tính toán và thêm vào trước khi mã hóa, còn CRC thì về nguyên tắc vẫn được thêm vào sau khi mã hóa. Về mặt lý thuyết do ICV được mã hóa nên không có kẻ nào có thể tính toán lại nhằm thay đổi nội dung, nhưng thực tế lại là chuyện khác. (adsbygoogle = window.adsbygoogle || []).push({});
Hình 2.12: Thêm ICV
Sau khi ICV được thêm vào, khung này đã sẵn sàng để mã hóa. Trước tiên, hệ thống phải lựa chọn một IV và kết hợp nó với khóa, thực hiện việc mã hóa bằng thuật toán RC4, từng byte dữ liệu và khối ICV lần lượt được mã hóa. Ứng với một byte đầu vào thì tương ứng có một byte được mã hóa ở đầu ra, quá trình này diễn ra liên tục cho đến khi toàn bộ dữ liệu được mã, đây chính là kiểu mã hóa chuỗi.
Để bên thu có thể giải mã được, cả KeyID và IV cũng phải được thêm vào, nó chiếm tổng cộng 4 byte: 3 byte đối với IV (24 bit) và 1 byte với KeyID (0, 1, 2 hoặc 3).
Hình 2.13: Thêm IV và KeyID
Cuối cùng, MAC header và CRC được thêm vào lần lượt vào đầu và cuối, trong phần MAC có một bit thông báo cho bên thu biết gói tin được mã hóa WEP, nhờ đó nó biết cách để xử lý.
Sau khi nhận được gói tin mà bên phát gửi đến, bên thu sẽ thực hiện quy trình như sau: nhờ vào một bit ở phần MAC header để biết gói dữ liệu nhận được có mã hóa hay không, nếu có, nó đọc và lưu lại giá trị IV, tiếp đến là đọc KeyID và chọn khóa giải mã, khởi tạo chương trình mã RC4 và thực hiện quá trình giải mã. Nếu ta thực hiện việc giải mã hai lần thì dữ liệu lại trở lại trạng thái mã hóa như ban đầu, do đặc điểm của thuật toán mã hóa mà việc mã hóa và giải mã là như nhau, tức là vẫn thuật toán ấy, nếu đầu vào là bản rõ thì đầu ra là bản mã và nếu đầu vào vẫn bản mã ấy thì đầu ra lại trở lại bản rõ ban đầu. Sau khi thu được bản rõ ban đầu, bước cuối cùng là tính ICV và đảm bảo rằng không có sự thay đổi nào đối với dữ liệu gốc. Nếu mọi việc hoàn thành, chỉ riêng phần dữ liệu mới được xử lý ở những công đoạn sau mà thôi, tất cả những phần thông tin thêm vào đến thời điểm này không còn cần thiết nữa.