Luận văn Nghiên cứu giải pháp bảo mật mạng không dây

a có thể ngăn chặn việc gửi lại gói tin bằng cách hủy tất cả những gói 47 tin nào có TSC đã nhận. Quy tắc này khiến cho việc gửi lại gói tin cũ không thực hiện được. Cách đơn giản nhất để ngăn chặn kiểu dùng lại gói tin là hủy bất cứ gói tin nào có TSC không lớn hơn TSC của gói tin vừa nhận được 1 đơn vị. Tuy nhiên có rất nhiều lý do giải thích tại sao cách đơn giản như vậy lại không áp dụng được vào thực tế. Trước hết là do khả năng các gói tin bị thất lạc trong quá trình truyền bởi nhiễu. Ví dụ, nếu thu được một khung có số TSC là 1234 và khung tiếp theo (1235) bị mất, nhưng vẫn thu được khung kế tiếp có TSC là 1236, nó lớn hơn 1234 là 2 đơn vị. Bởi vì khung 1235 bị thất lạc nên tất cả các khung sau đó bị hủy bởi vì TSC có giá trị tăng lên không phải là 1. Với quy tắc: hủy bất cứ gói tin nào có TSC nhỏ hơn hoặc bằng TSC của gói tin trước đó, nhưng khi phải truyền lại thì làm thế nào? Theo chuẩn, các gói tin phải được bên thu xác nhận bằng gói tin ACK. Nếu không nhận được sự xác nhận từ phía bên kia, gói tin đó cần được truyền lại với một bit được thiết lập để chỉ rằng nó là gói tin được gửi lại. Bởi là gói tin gửi lại nên nó có TSC trùng với gói tin trước. Thực tế thì nó vẫn được chấp nhận bởi chỉ có một bản copy duy nhất mà bên thu cần. Do có khả năng phải truyền lại nên các gói tin có TSC giống nhau không phải lúc nào cũng được coi là do kẻ gian gửi đến. Có một vấn đề nan giải hơn liên quan đến khái niệm burst-ack. Trong chuẩn IEEE 802.11, mỗi gói dữ liệu được gửi đi phải có một gói tin xác nhận riêng. Như vậy dường như không hiệu quả cho lắm vì bên phát phải dừng và đợi cho đến khi nhận được xác nhận do bên thu gửi thì mới được truyền tiếp. Ý tưởng của burst-ack là gửi 16 gói tin liên tiếp rồi mới gửi trả lại xác nhận cho 16 gói tin đó. Nếu có một số gói tin không nhận được, bên thu sẽ 48 báo lại chính xác gói tin nào cần truyền lại. Burst-ack chưa được đưa vào chuẩn nhưng nó chắc chắn sẽ được đưa vào trong tương lai. Với burst-ack, thì vấn đề đối với TSC là quá rõ ràng. Giả sử 16 gói tin đã được gửi đi, mỗi gói lại có TSC lớn hơn gói trước và bên thu không nhận được gói đầu tiên. Nó yêu cầu gửi lại gói đầu tiên đó, điều gì sẽ xảy ra với số TSC ban đầu. Nó nhỏ hơn 15 đơn vị so với gói tin nó nhận được cuối cùng và sẽ bị hủy nếu tuân theo quy tắc TSC phải lớn hơn. Để khắc phục, TKIP sử dụng một khái niệm gọi là cửa sổ truyền lại. Bên thu theo dõi TSC cao nhất nhận được và 16 TSC sau cùng. Nếu nhận được một gói mới, nó phân loại gói đó ra thành một trong 3 dạng:  Chấp nhận (accept): nếu TSC lớn hơn số lớn nhất mà nó đã biết.  Hủy (reject): nếu TSC nhỏ hơn số lớn nhất trừ đi 16.  Cửa sổ (window): nếu TSC nhỏ hơn số lớn nhất và lớn hơn số lớn nhất trừ đi 16. Đối với dạng cửa sổ, nó kiểm tra xem liệu có gói tin nào mà có TSC đã được nhận trước đó, nếu đã có rồi thì nó hủy luôn. Bên thu phải lưu lại 16 giá trị TSC và kiểm tra từng cái khi nó nhận được. Quy tắc này phức tạp hơn quy tắc ban đầu, nhưng nó ngăn chặn một cách có hiệu quả các gói tin do kẻ gian truyền lại trong khi vẫn đảm bảo giao thức hoạt động tốt. 2.3.2.2. Những quá trình diễn ra trong TKIP Phần này mô tả chi tiết cách hoạt động của thuật toán TKIP. Trước hết, ta coi các khóa chính đã được đưa đến các thiết bị và các khóa phiên được tạo ra từ khóa chính đã được tạo ra. Khóa chính được cung cấp thông qua các lớp trên theo phương pháp EAP, hoặc sử dụng khóa chính được thiết lập từ trước. Có 3 loại khóa được tạo ra đối với TKIP : 49  Khóa được dùng để mã gói tin trao đổi EAPOL-Key.  Khóa được dùng để mã các gói tin unicast (Pairwise key).  Nhóm khóa dùng để mã các gói tin broadcast (Group key). Pairwise key này lại bao gồm các khóa:  Khóa tạm thời (128bit): được dùng như là một khóa đầu vào cho giai đoạn tạo khóa hỗn hợp trước khi đi qua RC4.  Khóa MIC TX chứng thực tạm thời: được dùng để tạo ra MIC (bằng phương pháp chứng thực Michael) cho các khung do AP gửi đi.  Khóa MIC RX chứng thực tạm thời: dùng trong thuật toán Michael để tạo ra MIC trong các khung do STA gửi đi. Đối với các khóa nhóm (khóa dùng để mã các gói tin multicast hoặc broadcast), chỉ cần có 2 kiểu đầu tiên bởi vì chỉ có AP gửi broadcast và multicast, STA không bao giờ gửi những gói tin này. Nhiệm vụ của TKIP là cung cấp dịch vụ bảo mật để xác nhận tính hợp lệ của gói tin nhận được và làm giảm lượng thông tin cần thiết để xác thực. Để làm được điều này, TKIP sử dụng các công cụ sau:  Tạo ra IV và kiểm tra.  Tạo ra MIC và kiểm tra.  Mã hóa và giải mã. Đứng từ phía phát, vị trí của những thành phần trên liên quan tới những hoạt động khác trong MAC như mô tả trong hình 2.16. Bốn quá trình xử lý trong TKIP được mô tả dưới đây:  Michael  Tạo khóa phái sinh.  IV/TSC  RC4 50 Hình 2.16: Quá trình xử lý ở bên phát Lưu ý rằng, giá trị kiểm tra tính toàn vẹn MIC được tính đầu tiên và được gắn vào MSDU trước khi nó được chia nhỏ. Vì thế mà các byte kiểm tra này sẽ nằm ở MPDU cuối cùng và nằm trong phần dữ liệu được mã hóa. ICV của WEP vẫn được tính toán và thêm vào cho mỗi MPDU cho dù nó không nằm trong phần kiểm tra tính toàn vẹn của TKIP. Bởi MIC được tính toán ở mức MSDU, không bảo vệ được IV, khiến cho kẻ tấn công ngăn chặn STA bằng cách gửi các gói tin cũ với một IV mới. Vấn đề này gia tăng bởi IV có giá trị 48 bit, bằng TSC, giá trị dùng để tránh bị tấn công theo kiểu gửi lại gói tin cũ. Những gói tin giả mạo này đương nhiên sẽ không được giải mã và bị hủy, chúng không tác động đến tính toàn vẹn của giao thức. Tuy nhiên, nó khiến cho các gói tin hợp lệ sau đó giống như một kiểu tấn công gửi lại gói tin. Khi một gói tin hợp lệ tới, nó 51 có thể bị từ chối bởi TSC của nó đã bị STA của tin tặc dùng. Đây là một kiểu tấn công DOS. Trong môi trường mạng không dây, có rất nhiều cách đơn giản để thực hiện kiểu tấn công này, không thể nào ngăn chặn được nó và hiện đang là mối nguy hại khó tránh khỏi. Phần mã hóa trong hình 2.16 giống quá trình mã hóa RC4 trong WEP. Hầu hết các nhà sản xuất đã thực hiện quá trình mã hóa này theo cách mà không thể nâng cấp được bằng firmware. Các thiết bị dùng WEP thường có RC4 S-box tạo bởi phần cứng, không thể thay đổi đổi được, chính nó là vấn đề khó giải quyết nhất khi thiết kế TKIP. Quá trình xử lý diễn ra tại phía đầu thu được mô tả như trong hình 2.17: Hình 2.17: Quá trình xử lý ở bên thu Quá trình xử lý diễn ra ở đây không hoàn toàn ngược lại với bên phát. Có một điều, việc giải mã không phải được thực hiện trước tiên, mà là kiểm tra TSC nhằm ngăn chặn khả năng bị tấn công kiểu gửi lại gói tin. ICV 52 cũng được dùng để kiểm tra nhằm loại những gói tin không hợp lệ. Nó không phải là một kỹ thuật kiểm tra tính toàn vẹn, nhưng nó là một cách để tìm câu trả lời cho câu hỏi liệu việc giải mã có thành công hay không, vì giải mã một gói tin không đúng khóa hay không đúng IV thường chắc chắn tạo ra một ICV sai. MIC được kiểm tra sau khi toàn bộ các fragment đã nhận đủ và được ghép lại thành một MSDU. Nếu MIC sai, MSDU đó sẽ bị hủy. Cho dù là có khả năng xảy ra nhưng gần như chắc chắn là khó có khả năng các lỗi ngẫu nhiên trong quá trình truyền có thể qua được quá trình kiểm tra CRC và giải mã thành công ra ICV hợp lệ. Nếu nhận sai MIC, ta có thể tin chắc rằng đó là do sự can thiệp có chủ ý và không phải do nhiễu hay lỗi đường truyền. 2.3.3. Phương pháp bảo mật dựa trên AES-CCMP 2.3.3.1. Giới thiệu về AES-CCMP AES-CCMP có độ an toàn cao nhất trong chuẩn IEEE 802.11i. Các hệ thống bảo mật sử dụng thuật toán AES cùng với một mode hoạt động nào đó, một số mode đơn giản và phổ biến nhất sẽ được nói đến ở đây. Sau đó chúng ta sẽ tìm hiểu CCMP, giao thức được sử dụng trong IEEE 802.11 và tìm hiểu cách thức hoạt động của giao thức này. Phần này cũng cho thấy làm thế nào mà CCMP lại phù hợp với IEEE 802.11 framework và cung cấp chế độ bảo mật hợp lý mà thỏa mãn hầu hết nhu cầu của người sử dụng.Phần trước đã tìm hiểu về TKIP, một trong những phương pháp dùng để mã hóa và chứng thực gói tin nằm trong RSN. TKIP là phần không thể thiếu được trong WPA, nó được sử dụng khá rộng rãi để đảm bảo an toàn trong quá trình sử dụng mạng không dây dựa trên những thiết bị chạy trên nền tảng của WEP. Tuy nhiên, nó lại không phải là mode mặc định đối với IEEE 802.11i mà là mode dựa trên chuẩn mã hóa AES. Việc mã hóa dựa trên AES mạnh hơn so với TKIP. Vấn đề tại sao nó lại được chọn lựa và vì lí do gì? Khi nói đến 53 RSN dựa trên AES thì AES không phải là một giao thức bảo mật,nó chỉ là thuật toán mã khối. Trong RSN, giao thức bảo mật có sử dụng thuật toán AES được gọi là giao thức Counter Mode-CBC MAC hay CCMP. CCMP bao gồm một loạt các quy tắc trong đó có sử dụng thuật toán mã hóa khối AES để bảo vệ các khung dữ liệu IEEE 802.11. AES chỉ là thuật toán dùng trong CCMP giống như RC4 là thuật toán dùng trong TKIP.Một lý do mà CCMP được cho là mạnh hơn TKIP bởi nó được xây dựng từ đầu, tức là nó được tạo ra hoàn toàn mới với những kỹ thuật tốt nhất. Khác hoàn toàn với TKIP, bởi TKIP là một giải pháp tình thế được tạo ra nhằm khắc phục những điểm yếu của WEP. 2.3.3.2. Thuật toán AES và các mode mã hóa AES là thuật toán mã hóa khối, nó sử dụng các phép toán thông thường, các phép toán logic và khóa để biến một khối dữ liệu rõ 128 bit thành một khối dữ liệu mã. AES dựa trên thuật toán Rijdael do Joan Daeman và Vincent Rijmen tìm ra. Thuật toán này được chứng minh bằng tài liệu rất rõ ràng, bao gồm cả phần thuật toán và cách sử dụng rất chi tiết và đầy đủ (Daeman and Rijmen, 2000, 2001).Thuật toán Rijdael cho phép chọn các kích thước của khối và khóa khác nhau,có thể chọn 128, 192 hay 256 bit. Khi NIST quyết định chọn Rijdael cho AES thì ban đầu chỉ với độ lớn của khối là 128 bit nhưng vẫn cho phép chọn lựa 3 độ dài khóa khác nhau. IEEE 802.11i tiếp tục hạn chế thêm tức là chỉ chọn kích thước khóa và khối có độ dài 128 bit, điều này làm đơn giản hóa việc triển khai và tránh gây rắc rối cho người sử dụng phải chọn lựa khi cài đặt. Có thể dùng AES để mã hóa và giải mã một khối dữ liệu riêng biệt có độ dài cố định tuy nhiên dữ liệu thực tế lại không phải như vậy. Ví dụ, dữ liệu của WLAN được truyền đi với các khung có độ dài khác nhau, từ 512 đến 12000 bit. Vì thế, để sử dụng thuật toán mã hóa khối như AES chẳng hạn, chúng ta cần phải tìm cách tách ghép 54 dữ liệu sao cho nó có thể tạo thành được các khối có độ dài cố định trước khi mã, cũng như làm sao tái tạo lại khung dữ liệu như ban đầu sau khi giải mã. Phương pháp dùng để biến đổi dữ liệu thành các khối và ngược lại gọi là mode mã hóa. Việc chọn lựa một mode nào đó là rất quan trọng bởi nó liên quan đến cả độ phức tạp trong quá trình triển khai cũng như đối với vấn đề bảo mật. Các mode không hợp lý có thể tạo ra những lỗ hổng ngay cả khi được mã bởi AES. Để hiểu được các mode hoạt động, chúng ta sẽ tìm hiểu một trong những mode đơn giản và dễ hiểu nhất: ECB (Electronic Code Book). Mode này khi được sử dụng cùng với thuật toán AES có tên gọi là AES/ECB. a. Electronic Code Book (ECB) Mode này đơn giản chỉ việc chia dữ liệu ban đầu ra thành các khối, sau đó thực hiện việc mã hóa đối với từng khối riêng biệt nhưng với cùng một khóa cho đến khi khối cuối cùng được mã hóa hết. Hình dưới đây mô tả quá trình thực hiện theo cả phương pháp nối tiếp và song song. Hình 2.18: Quá trình hoạt động của ECB Mode 55 Cách này thực hiện rất đơn giản nhưng lại gặp phải một số vấn đề. Trước hết đó là do dữ liệu đầu vào không phải lúc nào cũng vừa đủ chia thành cách khối, vì thế phải thêm các bit và phải nhớ độ dài thực sự của dữ liệu ban đầu. Tiếp đến là vấn đề về bảo mật: nếu hai khối có nội dung như nhau thì sau khi mã sẽ có bản mã tương tự nhau do cùng khóa. Ví dụ xét một chuỗi có 64 ký tự giống nhau “AAAAAA…”, nếu kích thước của khối AES là 128 bit (hay 16 byte) thì khi dùng ECB chuỗi đó sẽ được chia ra thành 4 khối, mỗi khối gồm 16 chữ A. Sau khi mã hóa, 4 khối này sẽ cho ra 4 khối bản mã giống hệt nhau, từ bản mã đó dưới con mắt của người ngoài sẽ dễ dàng nhận ra là 4 khối đó có dữ liệu ban đầu giống nhau. Do đặc điểm này và một số đặc điểm khác nữa của ECB nên trong thực tế nó không được sử dụng. Ngay cả NIST cũng khuyến cáo không nên dùng mode này, ngay cả khi nó được bảo vệ bằng thuật toán mạnh nhất. b. Counter Mode Counter mode phức tạp hơn ECB và nó hoạt động theo cách hoàn toàn khác, nó không trực tiếp sử dụng khối mã AES, thay vào đó, nó mã giá trị của số đếm tương ứng rồi sau đó XOR kết quả mã với khối dữ liệu để được khối mã. Các số đếm này được tăng lên một đơn vị ứng với mỗi khối được mã. Quá trình này được mô tả trên hình sau: Hình 2.19: Ví dụ về Counter Mode Trên hình vẽ ta thấy, dữ liệu được chia thành các khối, mỗi khối được XOR với kết quả mã của số đếm. Ở đây, giá trị của bộ đếm tăng từ 1 đến 11 56 ứng với 11 khối dữ liệu. Thực tế, bộ đếm có thể bắt đầu từ một số bất kỳ và tăng theo một quy luật khác. Điều quan trọng là bên thu nếu muốn mã hóa được dữ liệu thì phải biết giá trị ban đầu của bộ đếm cũng như quy luật tăng của nó. Do bộ đếm thay đổi giá trị khác nhau ứng với mỗi khối nên vấn đề về các khối mã giống nhau mà ECB gặp phải đã được giải quyết. Ngay cả với hai khối dữ liệu đầu vào giống hệt nhau thì kết quả sau của bản mã thu được vẫn khác nhau nhờ vào bộ đếm. Tuy nhiên, có trường hợp phương pháp này vẫn mã hóa hai khối giống hệt nhau, tách biệt hẳn nhau nhưng vẫn cho giá trị mã giống nhau, điều này giải thích tại sao bộ đếm không bắt đầu từ một mà nó thường bắt đầu từ một giá trị bất kỳ rồi thay đổi ứng với mỗi khối.Counter mode có một số đặc điểm khá thú vị. Việc giải mã được thực hiện y hệt như quá trình mã bởi vì XOR cùng một giá trị 2 lần sẽ trả lại kết quả như ban đầu. Điều đó có nghĩa là khi thực hiện chỉ cần mỗi khối mã hóa AES mà không cần đến khối giải mã. Một đặc điểm khác là quá trình mã hóa có thể được thực hiện song song, do tất cả các giá trị của bộ đếm được biết trước nên giá trị mã hóa AES của các bộ đếm có thể được tính toán trước, nhờ đó có thể mã hóa toàn bộ dữ liệu cùng một lúc. Không phải mode nào cũng thực hiện được giống như vậy. Và một đặc điểm nữa là dữ liệu không phải chia chính xác đúng độ dài của một khối. Đơn giản chỉ cần lấy một khối (ví dụ chỉ là 100 bit chứ không phải là 128 bit) và XOR nó với giá trị mã của số đếm rồi lấy đúng số bit mà ta cần (lấy 100 bit chứ không phải là 128 bit, bỏ 28 bit). Do vậy mà độ dài của bản mã bằng đúng độ dài của bản rõ. Do việc mã hóa mỗi khối phụ thuộc vào giá trị của khối trước đó nên counter mode cần cho mã hóa chuỗi.Counter mode đã được sử dụng trên 20 năm và khá phổ biến cũng như được cộng đồng những nhà mật mã tin cậy. Tính đơn giản và chín muồi của nó là một lựa chọn hấp dẫn đối với 57 RSN. Tuy nhiên, mode này không cung cấp khả năng chứng thực, vì thế mà RSN đã phải đưa thêm tính năng mới này vào. c. Counter Mode + CBC MAC (CCM) CCM mode được tạo ra dành riêng cho IEEE 802.11i RSN, nhưng nó cũng có thể được áp dụng cho các hệ thống khác và là mode chính sử dụng với AES. Nó cũng được đệ trình lên IETF để dùng cho bảo mật IP. CCM được 3 nhà mật mã học trong nhóm IEEE 802.11i tìm ra, đó là: Doug Whiting, Russ Housley và Niels Ferguson. Nó được tạo ra dựa trên counter mode.CCM sử dụng counter mode cùng với một phương pháp chứng thực dữ liệu gọi là CBC (Cipher Block Chaining). CBC được dùng để tạo ra MIC. MIC được gọi là mã chứng thực gói tin, vì thế mà có tên là CBC-MAC.CBC- MAC là một kỹ thuật khác cũng được dùng trong rất nhiều năm và được chuẩn hóa trên toàn thế giới. Nó được thực hiện như sau: 1. Lấy một khối dữ liệu đầu tiên và mã hóa nó bằng AES (hay bằng phương pháp mã khối nào đó). 2. XOR kết quả với khối thứ 2 và lại mã tiếp. 3. Lại tiếp tục XOR kết quả trước với khối tiếp theo và mã kết quả vừa XOR, cứ lặp lại quá trình như vậy cho đến khi toàn bộ dữ liệu được mã hết. Kết quả cuối cùng là một khối (trong trường hợp này là 128 bit) là sự kết hợp của tất cả dữ liệu. Nếu chỉ cần một hay một số bit bị thay đổi, kết quả thu được sẽ hoàn toàn khác (xác suất trùng nhau chỉ là 2-128). CBC-MAC rất đơn giản nhưng lại không thực hiện được theo kiểu song song, việc mã hóa phải thực hiện tuần tự. Thêm vào đó, nó chỉ có thể sử dụng đối với dữ liệu có số khối chính xác. CCMP cung cấp một giải pháp là thêm bit (pading) nhưng nó lại khiến cho một số nhà mật mã học lo lắng.CCM mode dùng cả hai kỹ thuật nổi tiếng, đó là counter mode và CBC-MAC. Nó thêm vào 58 những đặc điểm rất hữu ích cho các ứng dụng như là đối với RSN. Các đặc điểm đó là:  Tạo ra số nonce nên các dữ liệu là hoàn toàn khác nhau.  Việc mã hóa và chứng thực chỉ sử dụng một khóa.  Mở rộng việc chứng thực đối với dữ liệu không được mã hóa. Đặc điểm cuối cùng cần phải tìm hiểu kỹ và khá quan trọng đối với RSN. Trong hầu hết các phương pháp đang được sử dụng để thực hiện mã hóa và chứng thực, thường giả định rằng toàn bộ dữ liệu sẽ được mã hóa. Tuy nhiên, trong IEEE 802.11 chỉ có một phần dữ liệu là được mã. Phần header của khung IEEE 802.11 có chứa địa chỉ MAC để chuyển gói tin đến đích cũng như các thông tin về hoạt động của WLAN cần phải được ở dạng rõ, tức là không mã hóa. Vì thế mà chỉ có phần dữ liệu là được mã mà thôi. Tuy nhiên, dù phần header không được mã thì bên thu vẫn muốn đảm bảo nó không bị thay đổi. Ví dụ, ta không muốn một kẻ nào đó thay đổi địa chỉ nguồn, vì nếu xảy ra như vậy, ta sẽ gửi trả lại dữ liệu cho kẻ gian thay vì gửi cho chính người ta muốn gửi. Để làm được điều này, người ta sử dụng CCM, nó cho phép việc mã hóa được thực hiện ở một phần của gói tin được chứng thực bởi CBC-MAC. Nhìn chung việc sử dụng cùng một khóa để thực hiện hai chức năng mã hóa là không hay cho lắm. Ở đây chính là việc dùng một khóa để mã hóa và chứng thực. Tuy dùng chung một khóa nhưng trong mỗi trường hợp lại dùng cùng với IV. Cấu trúc của IV là khác nhau đối với các phần counter mode và CBC-MAC, vì thế dẫn đến hai khóa tách riêng biệt. 2.3.3.3. Sử dụng CCMP trong quá trình mã hóa và giải mã Phần này mô tả cách mà các gói WLAN được mã hóa và giải mã sử dụng CCMP. Điều quan trọng đầu tiên là CCMP mã hóa dữ liệu ở cấp MPDU chứ không phải là ở MSDU. Mỗi một MPDU ứng với một khung 59 truyền và nó là một phần của MSDU do MSDU được chia ra thành các MPDU. a. Các bước mã hóa tổng quát Dữ liệu đầu MSDU được chia ra thành các fragment. Mỗi fragment tạo nên một MPDU và có phần header IEEE 802.11 bao gồm địa chỉ nguồn, địa chỉ đích và các thông số khác. Mỗi MPDU được xử lý bằng thuật toán CCMP để tạo ra một MPDU mã. Chỉ có phần dữ liệu là được mã, còn phần header thì không. Tuy nhiên, CCMP thực hiện nhiều việc khác chứ không chỉ mã hóa các phần của MPDU. Nó còn thêm vào các trường, khiến cho độ dài của MPDU sau khi mã lớn hơn MPDU trước 16 byte. Hình 2.20 mô tả quá trình của dữ liệu từ MSDU đến MPDU và truyền dữ liệu đi. Hình 2.20: Quá trình xử lý gói tin trong CCMP 60 Trình tự xử lý với một MPDU được thể hiện như trong hình 2.21 và được mô tả như sau: 1. Ban đầu là với MPDU chưa được mã, có đầy đủ phần IEEE 802.11 MAC header. Phần header này bao gồm cả địa chỉ nguồn, địa chỉ đích, một số trường được gán giá trị sau nên tại thời điểm này nó có giá trị 0.Thông tin chứa trong header được trích ra và được sử dụng trong quá trình tạo ra số MIC 8 byte. Trong giai đoạn này phần CCMP header 8byte được tạo ra để sau đó ghép vào MPDU. 3. MIC đã được tính toán nhằm bảo vệ CCMP header, dữ liệu và các phần khác của IEEE 802.11 header. Những giá trị của trạng thái hiện tại được đưa vào trong số nonce. MIC sau đó được ghép với dữ liệu. 4. Cả phần dữ liệu và MIC đều được mã hóa. Sau khi mã hóa, phần CCMP header được gắn vào. 5. Cuối cùng, phần MAC header được phục hồi và gắn vào phần đầu của MPDU vừa mã ở trên, đến thời điểm này, nó đã sẵn sàng trong hàng đợi để truyền đi. Trong quá trình truyền, chỉ có phần MAC header được quan tâm và cập nhật, không có thay đổi gì đối với CCMP header. 61 Hình 2.21: Trình tự xử lý một MPDU Các MPDU được mã được đưa đến hàng đợi trước khi truyền. Có thể có một vài hàng đợi khác nhau và thứ tự của các hàng đợi dựa trên một số chính sách ưu tiên. Điều này cho phép mở rộng về sau đối với các lớp dữ liệu khác nhau trong IEEE 802.11e. Ngay trước khi truyền, một số trường của IEEE 802.11 header được thay đổi để phù hợp với quy tắc truyền. Các trường bị thay đổi được gọi là các trường có thể biến đổi và chúng không được dùng để tính lại số MIC nữa. Ở đây ta tìm hiểu một chút về CCMP header. Nó được tạo ra và được gắn vào dữ liệu sau khi mã và được truyền đi dưới dạng không mã hóa. CCMP header được sử dụng với hai mục đích, trước hết, nó cung cấp một số thứ tự gói (PN-Packet Number) 48 bit để ngăn chặn việc sử dụng lại gói tin và cho phép bên thu tạo ra được số nonce dùng trong việc mã hóa. Thứ hai, trong trường hợp multicast, nó sẽ thông báo cho bên thu biết sử dụng khóa nhóm nào. Định dạng của CCMP header giống như định dạng của TKIP header, điều này nhằm mục đích đơn giản hóa cho AP vì nó nhận cả TKIP và CCMP từ các STA. Định dạng này được mô tả trong hình 2.22. Hình 2.22: Phần đầu CCMP 62 Trong số 8 byte thì 6 byte là dành cho số PN (48 bit), 1 byte dự phòng, byte còn lại có các bit của KeyID. Lưu ý rằng bit bên cạnh KeyID được thiết lập giá trị 1 ứng với bit IV mở rộng trong TKIP. Nó cũng chỉ ra rằng đó là khung định dạng của RSN chứ không phải của WEP. b. Quá trình thực hiện Quá trình làm việc của khối CCMP có thể được xem như là một quá trình xử lý với các đầu vào và đầu ra như hình 2.23 đã thể hiện: Hình 2.23: Mã hóa và giải mã Quá trình giải mã có các đầu vào giống như quá trình mã, chỉ khác mỗi MPDU mã chứ không phải là MPDU rõ. Ta có thể tách được các thông tin đầu vào giống như bên phát vì phần header chứa đầy đủ các thông tin cần thiết, bao gồm cả CCMP header. Việc thực hiện CCMP phải luôn đúng thứ tự của gói bởi nó luôn có giá trị khác nhau đối với mỗi gói. Điều này nhằm ngăn không cho kẻ gian sử dụng lại gói tin đã được gửi trước đó. Số PN này có độ dài là 48 bit, đủ lớn để đảm bảo rằng nó không bị cạn kiệt trong khoảng thời gian dài, không bao giờ có hai gói tin có cùng số này. Đương nhiên nếu ta tắt nguồn và khởi động lại thiết bị, PN cũng sẽ được gán giá trị lại từ đầu, nhưng với giá trị khóa hoàn toàn khác nên cũng không đáng ngại. Những gì diễn ra trong khối mã CCMP được mô tả trong hình 2.24. 63 Hình 2.24: Bên trong khối mã hóa CCMP Có hai giai đoạn tính toán: đầu tiên là tính ra số MIC để gắn vào MPDU, sau đó cả MPDU bao gồm cả MIC được mã hóa. Một MPDU đã được mã lại có thêm hai trường nữa, đó là CCMP header và MIC. Trường MIC (64 bit) và chỉ bằng một nửa kích thước của khối AES nhưng cũng đủ lớn để giảm khả năng giả số MIC xuống còn 10 19. Thứ tự của các trường trong MPDU mã được mô tả trong hình 2.25. Hình 2.25: MPDU sau quá trình mã (CH=CCMP Header) Các bước mã hóa một MPDU: 64 Trước khi bắt đầu việc mã hóa, cần phải chuẩn bị tất cả những gì cần thiết của MPDU để nó thực hiện đúng thứ tự. Bắt đầu với 3 phần: MAC header, CCMP header và dữ liệu rõ. Các trường có thể thay đổi của MAC header được thiết lập toàn 0. CCMP header được gán các giá trị PN và các bit KeyID. Lưu ý một điều là PN tăng đối với mỗi MPDU. Phần dữ liệu là phần chứa dữ liệu chưa mã. Phần MAC header và CCMP header sẽ không được mã nhưng lại cần trong quá trình tạo ra số MIC. Hai header này được nhóm lại tạo ra dữ liệu chứng thực. Việc đầu tiên sau khi ghép nối các phần lại với nhau là tính toán MIC. Việc tính ra số MIC được thực hiện bằng cách sử dụng CBC-MAC, nó mã khối đầu tiên, XOR kết quả đó với khối tiếp theo và lại mã, quá trình được lặp lại cho đến hết. Kết quả cuối cùng là số MIC 128 bit, nhưng chỉ cần có 64 bit đối với CCMP nên 64 bit thấp bị loại bỏ. Đối với CCMP khối đầu tiên trong quá trình tính CBC-MAC không phải lấy từ MPDU mà là chính số nonce. Định dạng của khối đầu tiên này (hình 2.26) bao gồm số nonce và hai trường: Flag và Dlen. Hình 2.26: Định dạng của khối đầu tiên để đưa vào CBC-MAC Số nonce luôn ứng với các trạng thái hiện thời và đảm bảo rằng dữ liệu mã hóa không bao giờ giống nhau sau khi mã. Ta có thể cho rằng chỉ cần sử dụng số PN là đủ vì mỗi gói có một giá trị PN khác nhau, tuy nhiên, cần nhớ rằng khóa được dùng cho ít nhất là bên thu và bên phát (có thể nhiều hơn đối với khóa nhóm), các bên này vào một thời điểm nào đó, sử dụng số PN đã 65 được dùng ở nơi khác, như vậy là vi phạm quy tắc mỗi khóa chỉ dùng một lần. Để tránh vấn đề này, số nonce được tạo ra bởi sự kết hợp giữa PN với địa chỉ MAC của bên gửi. Không chỉ có vậy, trường thứ 3 trong nonce là trường Priority (trường ưu tiên). Trường này được dự trữ dùng sau này khi có nhiều luồng dữ liệu khác nhau cần độ ưu tiên khác nhau (ví dụ: audio, video …). Trong trường hợp đó, nên tách PN ứng với mỗi loại dữ liệu khác nhau sẽ hiệu quả hơn. Cả 3 trường kết hợp lại tạo ra số nonce 104 bit (hình 2.27). Hình 2.27: Thành phần của khối đầu tiên để đưa vào CBC-MAC Hai trường còn lại là Flag và Dlen cùng với số nonce tạo nên khối đầu tiên để tính CBC-MAC. Trường flag có giá trị cố định là 01011001 và chỉ ra rằng số MIC là 64 bit. Trong các ứng dụng CCM khác không phải là RSN thì flag này có giá trị khác và không được đề cập đến ở đây. Trường cuối cùng, Dlen chỉ độ dài của dữ liệu chưa mã. Khi khối đầu tiên đã sẵn sàng, số MIC được tính dựa trên dữ liệu chứng thực và dữ liệu cần mã. Một đặc điểm của CBC-MAC là nó chỉ làm việc với đúng kích thước khối quy định. Nếu dữ liệu chia không đủ một khối thì phải thêm các bit cho đủ. Đối với IEEE 802.11, chắc chắn rằng cả dữ liệu chứng thực và dữ liệu chưa mã sẽ không vừa đủ các khối và như vậy các bit 0 được thêm vào. Vì thế nhiều lúc số MIC được tính bao gồm cả khối đầu tiên, dữ liệu chứng thực, dữ liệu ban đầu và cả các byte toàn 0. Các byte thêm vào này chỉ dùng để tính ra số MIC chứ không được thêm vào MPDU. 66 Ngay khi MIC được tính và gắn vào dữ liệu rõ thì quá trình mã có thể bắt đầu được thực hiện. Việc mã hóa sử dụng counter mode và bắt đầu ngay với dữ liệu theo sau CCMP header. Nhớ rằng do phải chèn thêm bit trong quá trình tính MIC, các khối được mã sẽ tương ứng với các khối trong quá trình tính MIC. Phần dữ liệu được mã sẽ thay thế toàn bộ dữ liệu ban đầu và số MIC, tạo ra một MPDU hoàn chỉnh sẵn sàng đợi để truyền đi. Không phải thêm bit trong quá trình mã vì counter mode cho phép loại bỏ các bit thừa trong khối cuối cùng. Một bước quan trọng trong counter mode là thiết lập giá trị đếm theo cách không bao giờ tạo ra hai số giống nhau. Vì thế mà bộ đếm được tạo nên từ một số nonce theo một cách gần giống với việc tạo ra số MIC, bao gồm số thứ tự, địa chỉ MAC nguồn và các trường ưu tiên. Sau đó nó kết hợp với hai trường Flag và Counter (“Ctr”) (hình 2.28). Hình 2.28: Kết hợp số đếm Ctr trong CCMP AES Counter Mode Ctr bắt đầu từ 1 và tăng dần lên, do số nonce là giá trị duy nhất và trường ctr có độ lớn 16 bit nên ta đảm bảo chắc chắn rằng các giá trị bộ đếm là duy nhất đối với tất cả các gói tin dưới 65536 khối. Điều này dễ dàng xác định được số MPDU lớn nhất trong IEEE 802.11. Như vậy quá trình mã hóa đã gần hoàn tất. Ta cần phải đặt lại tất cả các trường trong MAC header vào vị trí của nó. Cho dù các trường này không dùng cho MIC nhưng chúng vẫn quan trọng. 67 Khi bộ đếm được thiết lập, quá trình mã hóa được thực hiện như đã nói trong phần counter mode ở phần trước. Mỗi giá trị của counter được mã hóa bằng khóa rồi sau đó được XOR với dữ liệu để tạo ra dữ liệu được mã. Giải mã các MPDU: Khi các MPDU mã được đưa tới bên thu, công việc đầu tiên là chọn đúng khóa để giải mã. Khóa dùng để giải mã được chọn dựa vào địa chỉ MAC nguồn trong MAC header. Bên thu phải thực hiện một loạt các bước để có được dữ liệu ban đầu và kiểm tra sự hợp lệ của dữ liệu đó. Số PN được gắn vào phần CCMP header nên không được mã hóa. Khi nhận được một gói tin, việc đầu tiên bên thu kiểm tra chính là số PN và so sánh nó với khung nhận được trước đó, nếu nó nhỏ hơn hoặc bằng thì khung đó sẽ bị hủy và bên thu sẽ tạm dừng xử lý với MPDU. Giả sử rằng số PN là hợp lệ, bước tiếp theo sẽ là quá trình giải mã AES/counter mode. Yêu cầu đặt ra là giá trị của bộ đếm phải trùng khớp với giá trị của nó sau khi giải mã. Tất cả thông tin cần thiết giờ đã nhận được đầy đủ. Số thứ tự được kết hợp với địa chỉ MAC nguồn và giá trị ưu tiên tạo nên số nonce. Sau đó giá trị của flag và ctr được thêm vào để tạo số ban đầu cho bộ đếm. Lưu ý rằng chẳng có tý bảo mật nào ở đây cả, bất kỳ ai cũng có thể tính ra được giá trị này. Tuy nhiên, nó chẳng có nghĩa lý gì nếu không biết khóa. Quá trình giải mã cũng được dùng giống như quá trình mã. Các giá trị đúng của bộ đếm được giải mã và XOR với MPDU nhận được, kết quả thu được là MPDU rõ cùng với số MIC. Bước tiếp theo là kiểm tra lại xem liệu số MIC có đúng hay không. MIC được tính lại với cùng dữ liệu vừa giải mã (bao gồm cả phần padding) giống như ở bên gửi. Các trường có thể thay đổi được trong phần header không được tính đến và việc tính toán được thực hiện đối với toàn bộ MPDU, đương nhiên là không tính phần MIC. Nếu dữ liệu không có sự 68 khác biệt so với lúc gửi đi, cộng với khóa chính xác, ta sẽ thu lại được kết quả như mong muốn. Giá trị MIC sẽ được so sánh, nếu trùng khớp, kết quả thu được là hợp lệ. Nếu không, gói tin có thể bị cho là của kẻ tấn công và sẽ bị hủy. Khi MPDU đã được giải mã, số MIC và CCMP header được loại bỏ, phần dữ liệu còn lại cùng với các phần dữ liệu giải mã ở các MPDU khác sau đó sẽ được kết hợp lại, tái tạo lại thành MSDU. Như vậy quá trình thực hiện với CCMP cho thấy độ an toàn rất cao, chống lại các kiểu tấn công như giả mạo, nghe lén hay dùng lại gói tin. 2.3.4. Nghiên cứu thuật toán mã hóa đối xứng RSA Ở phần trên chúng ta đã nghiên cứu về các phương pháp mã hóa đối xứng. Ứng dụng trong luận văn này, khi phối hợp sử dụng token key, em áp dụng thuật toán mã hóa RSA, mã hóa từng gói tin với khóa công khai và khóa bí mật nằm trong token của mỗi Client. 2.3.4.1. Mô tả sơ lược Thuật toán RSA có hai khóa: khóa công khai (hay khóa công cộng) và khóa bí mật (hay khóa cá nhân). Mỗi khóa là những số cố định sử dụng trong quá trình mã hóa và giải mã. Khóa công khai được công bố rộng rãi cho mọi người và được dùng để mã hóa. Những thông tin được mã hóa bằng khóa công khai chỉ có thể được giải mã bằng khóa bí mật tương ứng. Nói cách khác, mọi người đều có thể mã hóa nhưng chỉ có người biết khóa cá nhân (bí mật) mới có thể giải mã được. Ta có thể mô phỏng trực quan một hệ mật mã khoá công khai như sau: Bob muốn gửi cho Alice một thông tin mật mà Bob muốn duy nhất Alice có thể đọc được. Để làm được điều này, Alice gửi cho Bob một chiếc hộp có khóa đã mở sẵn và giữ lại chìa khóa. Bob nhận chiếc hộp, cho vào đó một tờ giấy viết thư bình thường và khóa lại (như loại khoá thông thường chỉ cần sập 69 chốt lại, sau khi sập chốt khóa ngay cả Bob cũng không thể mở lại được không đọc lại hay sửa thông tin trong thư được nữa). Sau đó Bob gửi chiếc hộp lại cho Alice. Alice mở hộp với chìa khóa của mình và đọc thông tin trong thư. Trong ví dụ này, chiếc hộp với khóa mở đóng vai trò khóa công khai, chiếc chìa khóa chính là khóa bí mật. 2.3.4.2. Nguyên tắc thuật toán Tạo khóa Hình 2.29. RSA – Tạo khóa Mã hóa Hình 2.30. RSA – Mã hóa 70 Giải mã Hình 2.31. RSA – Giải mã Ví dụ Sau đây là một ví dụ với những số cụ thể. Ở đây chúng ta sử dụng những số nhỏ để tiện tính toán còn trong thực tế phải dùng các số có giá trị đủ lớn. Lấy: p = 61 — số nguyên tố thứ nhất (giữ bí mật hoặc hủy sau khi tạo khóa) q = 53 — số nguyên tố thứ hai (giữ bí mật hoặc hủy sau khi tạo khóa) n = p*q = 3233— môđun (công bố công khai) e = 17 — số mũ công khai d = 2753— số mũ bí mật Khóa công khai là cặp (e, n). Khóa bí mật là d. Hàm mã hóa là: encrypt(m) = m^e mod n = m^17 mod 3233 với m là văn bản rõ. Hàm giải mã là: decrypt(c) = c^d mod n = c^2753 mod 3233 với c là văn bản mã. Để mã hóa văn bản có giá trị 123, ta thực hiện phép tính: encrypt(123) = 12317 mod 3233 = 855 71 Để giải mã văn bản có giá trị 855, ta thực hiện phép tính: decrypt(855) = 8552753 mod 3233 = 123 Cả hai phép tính trên đều có thể được thực hiện hiệu quả nhờ thuật toán bình phương và nhân. 2.4. Kết chương Chương này đã trình bày thực trạng mất an ninh an toàn của mạng không dây, các kỹ thuật mật mã ứng dụng để bảo mật mạng không dây và một số giải pháp cho việc đảm bảo an ninh an toàn cho mạng không dây mà cụ thể là mạng WLAN. Giải thích hoạt động của WEP và lý do tại sao không nên sử dụng nó. Khi chuẩn IEEE 802.11 được công bố ra công chúng thì đi kèm với nó là WEP, một biện pháp bảo mật mạng không dây đầu tiên. Phần này cũng cho ta thấy những điểm yếu của WEP, những lỗ hổng mà khi thiết kế đã không được những nhà chuyên gia bảo mật quan tâm đến. Tuy nhiên, cũng qua đó, ta càng hiểu thêm được tại sao những phương pháp bảo mật sau này lại đảm bảo an toàn hơn. Các nhà thiết kế đã tìm cách khắc phục những hạn chế của WEP và tạo ra một giao thức bảo mật mới phù hợp với nó. TKIP là một biện pháp quan trọng cung cấp chế độ bảo mật thực sự mà WEP không thể có được. Mọi điểm yếu cơ bản của WEP đã được khắc phục, bao gồm cả tấn công vào khóa yếu, nghe lén, gửi lại gói tin cũng như các điểm yếu khác. Thêm vào đó, TKIP được thiết kế bởi những chuyên gia cao cấp trong lĩnh vực bảo mật và đảm bảo được tính toàn vẹn dữ liệu cho người sử dụng. Một lượng lớn các hệ thống WLAN trên thế giới đã được triển khai với thức bảo mật dựa trên thuật toán RC4. Các hệ thống này sử dụng WEP hoặc TKIP. Tuy nhiên, khi ủy bản về IEEE 802.11 tìm kiếm một giải pháp bảo mật mới và muốn xây dựng nó từ đầu thì họ đã lựa chọn AES. AES là một thuật 72 toán mã hóa được dùng theo nhiều cách khác nhau để tạo ra các giao thức bảo mật. Phần tiếp theo sẽ nghiên cứu, xây dựng một mô hình, đề xuất giải pháp, phát triển thử nghiệm một ứng dụng nhằm đảm bảo an ninh an toàn cho mạng WLAN. 73 Chương 3 XÂY DỰNG PHẦN MỀM BẢO MẬT MẠNG KHÔNG DÂY WLAN SỬ DỤNG USB ETOKEN 3.1. Phân tích yêu cầu, đề xuất giải pháp 3.1.1. Bài toán đặt ra Với người dùng hiện nay, mạng Wifi đang trở nên rất phổ biến và dần dần thay thế mạng không dây. Ở những nơi mạng LAN khó triển khai như bệnh viện, trường học, quán cafe, các công ty… thì mạng WLAN như một cứu cánh tuyệt vời, giảm thiểu tối đa các thiết bị cứng như đường dây, switch… Song hành với lợi ích mang lại là những hiểm họa như lộ thông tin, xâm nhập trái phép… Do mạng không dây là vô tuyến, ai bắt được mạng thì cũng “có thể” xâm nhập vào mạng. Với những công ty thì điều này là rất nguy hiểm, hoàn toàn có thể bị đánh cắp, gây rò rỉ thông tin. Các phương thức bảo mật được áp dụng hiện nay thường thấy là đặt pass wifi bằng WPA hoặc WPA2, nhưng trên mạng internet ta dễ dàng tìm thấy những video, các tut chia sẻ cách “hack WPA2” sử dụng linux. Bài toán đặt ra ở đây là làm cách nào, thông tin chia sẻ trong mạng WLAN được bảo vệ, mã hóa, quản lý được số người truy cập mạng LAN một cách cẩn thận tới từng đơn vị sử dụng mà vẫn có sự linh động khi di chuyển. Để giải quyết yêu cầu trên, em đã xây dựng phần mềm bảo mật mạng không dây WLAN sử dụng USB eToken để quản lý đăng nhập và mã hóa gói tin khi di chuyển trong WLAN. Mục đích đặt ra: muốn sử dụng phần mềm phải có eToken, mỗi gói tin khi các client giao tiếp với nhau đều được mã hóa đảm bảo dù có bị nghe trộm hay bắt gói tin, nếu không có eToken thì không thể giải mã được những gói tin đã nhận. Nâng cao bảo mật an toàn, phù hợp với các công ty có nhu cầu bảo mật, hạn chế số người sử dụng phần mềm bằng cách phát cho nhân viên USB eToken. 74 3.1.2. Sơ đồ ứng dụng 3.1.2.1. Đăng kí Hình 3.1 Sơ đồ đăng kí token đăng kí tài khoản Người dùng muốn đăng kí phải cầm token lên Server để đăng kí, Database do Server quản lý sẽ lưu trữ tên đăng nhập, mật khẩu và khóa công khai của từng token. Sau khi đăng kí thành công, người dùng mới có thể mang token về client của mình và sử dụng phần mềm. Điều này hướng tới mục đích đăng kí token một cách tập trung tại một phòng nào đó trong công ty, chuyển quản lý token (tức quản lý người dùng, tránh người dùng tự đăng kí tại client). 3.1.2.2. Đăng nhập 75 Hình 3.2. Đăng nhập 3.1.2.3.Trao đổi giữa Client và Client Hình 3.3. Trao đổi giữa Client A và Client B Ở đây ta xét trường hợp tin tổng quát. Chat hay gửi file giữa các Client với nhau qua socket đều quy thành các “gói”. Server quản lý tất cả Public Key của các Client đang online. Client A lấy khóa công khai của Client B và 76 mã hóa gói tin cần gửi. Client B khi nhận gói tin, lấy khóa bí mật của mình để giải mã gói tin. Như vậy ai cũng có thể mã hóa gói tin nhưng muốn giải mã thì chỉ có thể giải mã bằng khóa bí mật, nằm trong token của người nhận 3.1.2.4. Trao đổi giữa Server – Client Hình 3.4. Trao đổi giữa Server – Client Về vấn đề trao đổi file giữa Server và Client có đôi chút khác biệt khi trao đổi file giữa Client và Client. Ở đây khi trao đổi file, ta không mã hóa bằng token vì hai lý do sau: - Do Server bật liên tục và là duy nhất, không cần phải sử dụng eToken - Muốn tự viết phần mã hóa RSA như đã trình bày ở trên. Với những lý do đó, khi trao đổi giữa Server và Client, em sử dụng một file key.dat có lưu trữ 3 giá trị e, p, q để phục vụ cho thuật toán RSA tự viết. Việc sử dụng key.dat hay token là tương đương nhau. Tùy theo nhu cầu của công ty mà ta có thể chuyển giữa việc dùng token hay dùng key.dat. 3.1.3. Môi trường hệ thống 3.1.3.1. Các tác nhân của hệ thống 77 - Quản trị Server: Là người được quản lý server, khởi động, tắt Server. Quản lý thêm sửa xóa các tài khoản người sử dụng. Có thể chat và gửi file đồng thời tới mọi Client đang online. - Người dùng: Mỗi người dùng là một client, tham gia sử dụng phần mềm, họ phải đăng nhập bằng token để sử dụng phần mềm. Có thể chat, gửi file tới Server hoặc Client khác đang online. 3.1.3.2. Đặc tả các Usecase: Các chức năng cho người quản trị Server Hình 3.5. Usecase chức năng người quản trị Server Usecase Quản lý thông tin tài khoản 78 Hình 3.6. Usecase Quản lý thông tin tài khoản Usecase Giao tiếp với mọi Client Hình 3.7. Usecase giao tiếp với mọi Client Các chức năng cho người dùng Client Hình 3.8. Chức năng người dùng Client Usecase giao tiếp với Server 79 Hình 3.9. Usecase Client giao tiếp với Server 3.1.4. Thiết kế cơ sở dữ liệu Với mục đích sử dụng cho các công ty là chính, cơ sở dữ liệu của chương trình khá đơn giản, lưu trữ tài khoản, mật khẩu, tên nhân viên, khóa công khai của nhân viên và có thể thêm thắt các thông tin khác tùy ý. Ở đây hướng chính của phần mềm là demo luận văn, em chỉ thêm một trường là ngày tháng, không có ý nghĩa gì với chương trình, chỉ mang tính demo. Bảng cơ sở dữ liệu trên là bảng của các Client. Server chỉ có một nên không có đăng nhập và quản lý bằng cơ sở dữ liệu. 3.1.5. USB Token 3.1.5.1. Đôi nét về USB Token Hình 3.10. USB Token của Viettel 80 eToken Pro USB là một sản phẩm thuộc dòng sản phẩm eTokenTM của Aladdin Knowledge Systems Ltd., Israel. eToken Pro USB là một thiết bị bảo mật cao, giao tiếp với máy tính qua cổng USB, sử dụng tiện lợi, an toàn, dễ mở rộng. eToken Pro USB hỗ trợ tất cả hạ tầng khóa công khai eToken PKI như xác thực người dùng, quản lý mật khẩu, bảo mật chữ ký số và bảo mật dữ liệu... Ngoài ra, do eToken Pro USB hỗ trợ các giao diện và hệ thống bảo mật theo tiêu chuẩn công nghiệp, nên eToken Pro USB còn đảm bảo việc tích hợp dễ dàng với hạ tầng và các chính sách bảo mật. Đặc tính kỹ thuật của eToken Pro USB được thể hiện trong bảng dưới đây: 81 Hình 3.11. Đặc tính kĩ thuật của USB eToken Dựa trên các tiêu chí đánh giá, eToken có tính năng nổi trội về khả năng hỗ trợ hệ điều hành, hỗ trợ các ứng dụng PKI, hỗ trợ các chuẩn bảo mật và khả năng tích hợp. 3.2. Xây dựng ứng dụng 3.2.1. Giới thiệu chung về ứng dụng Ứng dụng là một hệ thống Server – Client chạy trong mạng LAN nội bộ, có thể là mạng có dây hoặc không dây. Do hướng của luận văn là bảo mật mạng không dây, phần mềm được thiết kế để có thể mã hóa các gói tin, hạn chế người dùng…chống lại các cuộc tấn công nghe trộm, bắt gói tin, đảm bảo một mức độ bảo mật của các công ty. Hệ thống sử dụng ngôn ngữ lập trình Java và quản trị cơ sở dữ liệu SQL Server. Các chức năng chính của chương trình là chat và gửi file giữa các người dùng trong mạng. Các gói tin đều được mã hóa trước khi gửi đi và giải mã khi nhận về. Sau đây là sơ đồ ứng dụng: Hình 3.12. Mô hình ứng dụng 3.2.2. Server Server của hệ thống là nơi khởi tạo kết nối. Các chức năng của Server: 82 1. Khởi tạo kết nối, làm điểm truy nhập của các Client 2. Lưu giữ các PublicKey của các Client đang kết nối 3. Đăng kí mới, sửa, xóa các eToken đã đăng kí tài khoản 4. Chat với mọi Client 5. Gửi file cho mọi Client Trước tiên, người dùng vào màn hình chính của chương trình. Do mỗi lần sử ở một mạng WLAN khác nhau, máy làm Server sẽ được cấp một địa chỉ IP khác nhau. Trên thực tế nếu dự án được triển khai thực sự. Server sẽ nằm cố định ở một máy và kết nối với một mạng WLAN cũng cố định, ta sẽ không cần quan tâm tới giải IP của Server nữa. Để vào mục quản lý tài khoản, ta ấn nút Account Manager, để bắt đầu Server. Ta ấn nút Start. Các Client sau khi kết nối tới Server này sẽ hiển thị ở ô bên trái màu vàng. Hình 3.13. Màn hình chính của Server Dưới đây là màn hình quản lý tài khoản, cũng chính là cơ sở dữ liệu của hệ thống. Lưu trữ lại các thông tin cùng với khóa công khai. 83 Hình 3.14. Màn hình quản lý tài khoản Với mục tiêu hạn chế và quản lý người dùng. Những ai muốn sử dụng phần mềm phải có token và phải mang token đó để cho Server để đăng kí sử dụng. Hình 3.15. Màn hình thêm tài khoản 84 Sau khi thêm tài khoản, người quản trị Server có thể sửa đổi thông tin của tài khoản đó, trừ tên đăng nhập. 3.2.3. Client Client của hệ thống là những người sử dụng mạng nội bộ. Họ bắt buộc phải có token, ở đây đóng vai trò như chìa khóa để sử dụng phần mềm này. Nếu trong quá trình sử dụng, rút token, Client sẽ kết thúc. Các chức năng của Client: 1. Chat với Server, Client 2. Gửi file tới Server, Client 3. Hiển thị danh sách các Client đang sử dụng phần mềm Trước tiên, người dùng cần cắm token vào máy tính chạy Client, sau đó chạy phần mềm để đăng nhập: Hình 3.16. Màn hình đăng nhập Nếu đăng nhập thành công, ta sẽ vào được giao diện chính của Client. Đây là màn hình có thể xem danh sách Client đang online và cũng nơi giao tiếp trực tiếp với Server. 85 Hình 3.17. Màn hình chính của Client Với giao diện trên ta có thể chat và gửi file tới Server hoặc Client khác. Do kết nối socket không ổn định và mã hóa RSA làm giảm tốc độ nên bạn không được gửi file quá lớn. Để đảm bảo tính ổn định của chương trình, bạn nên gửi những file được cung cấp trong thư mục “test” có trong thư mục chương trình. Hình 3.18. Màn hình chọn file 86 Khi nhận được file, sẽ có thông báo nhận file Hình 3.19. Màn hình lưu file Tất cả các Client đều phải cắm token khi sử dụng, trong quá trình sử dụng, vì bất kì lý do gì không tìm thấy token, chương trình lập tức hiện ra cảnh báo và thoát khỏi chương trình ngay lập tức Hình 3.20. Màn hình cảnh báo không thấy token Ứng dụng hướng đến đối tượng sử dụng là các công ty hoặc các trường học, rất cần sự trao đổi thông tin nội bộ, bảo mật và kiểm soát người dùng. USB eToken là chìa khóa để sử dụng phần mềm nội bộ này. Mạng WLAN vẫn bật, mọi người có thể truy cập vào mạng, nhưng để trao đổi với nhau thì phải có token. Tin tặc có thể bắt được gói tin nhưng nếu không có USB eToken, hắn sẽ không thể giải mã gói tin vì không có PrivateKey. Đây là hình ảnh file đã mã hóa, cũng chính là file mà tin tặc bắt được nhưng không thể giải mã: 87 Hình 3.21. So sánh 2 file mã hóa và gốc Phần mềm đã giải quyết được các vấn đề: 1. Quản lý người dùng bằng cách cấp phát token. 2. Quản lý tài khoản token để quyết định có cho phép truy cập hay không, kể cả khi có token. 3. Người dùng có thể chat và trao đổi file. 4. Mã hóa và giải mã các gói tin trao đổi trong mạng nội bộ. Những điều phần mềm chưa giải quyết được: 5. Chưa có chứng thực gói tin (kí và kiểm tra chữ kí). 6. Do sử dụng thuật toán để mã hóa và đường truyền bằng socket không ổn định nên chưa thể gửi được file có dung lượng lớn. 88 KẾT LUẬN Với sự phổ biến của mạng WLAN như hiện nay, vừa mang lại lợi ích cũng như các hiểm họa. Với mạng không dây, bạn có thể giảm bớt gánh nặng khi thiết kế các mạng WLAN, không còn phải thấy các đường dây mạng chằng chịt. Đồng nghĩa với việc thông tin “trôi nổi” trong không khí thì ai cũng có thể “tóm” được gói tin của bạn. Các kĩ thuật tấn công ngày càng tinh vi, thực hiện trên diện rộng và nhiều cách khác nhau. Kết hợp với những phương thức bảo mật sẵn có của mạng WLAN như WPA, WPA2…việc mã hóa gói tin là hướng giải quyết tốt nhất. Thỏa mãn được hai vấn đề: bảo mật đường truyền và bảo mật mức độ gói tin. Luận văn lần này đã đóng góp được các vấn đề chính sau đây: 1. Trình bày tổng quan sự phát triển của mạng không dây, các công nghệ ứng dụng trong mạng không dây. Tìm hiểu một cách khái quát cơ chế hoạt động của mạng WLAN, ưu điểm, nhược điểm cũng như các mô hình hoạt động của mạng WLAN. Tìm hiểu chuẩn 802.11 cho mạng WLAN, nắm được những gì diễn ra trong quá trình thiết lập kết nối với một hệ thống WLAN đơn giản 2. Trình bày thực trạng mất an ninh an toàn của mạng không dây, các kiểu tấn công trong mạng không dây, các kỹ thuật mật mã ứng dụng để bảo mật mạng không dây và một số giải pháp cho việc đảm bảo an ninh an toàn cho mạng không dây mà cụ thể là mạng WLAN như: phương pháp mã hóa đối xứng, mã hóa công khai, bảo mật đường truyền WEP, WPA, WPA2… 3. Nghiên cứu đề xuất giải pháp mã hóa gói tin kết hợp mã hóa đường truyền sẵn có để xây dựng phần mềm ứng dụng eToken, bảo mật mạng WLAN nội bộ. Một ứng dụng hoàn toàn mới và thiết thực cho các công ty, trường học, quân sự… Đóng góp của phần mềm: 89 1. Đã tích hợp được thiết bị eToken trong việc sử dụng toàn bộ hệ thống,thiết bị lưu trữ khóa bí mật, đảm bảo người dùng đã đăng kí mới có khả năng truy cập vào hệ thống. 2. Áp dụng được việc sự dụng mật mã khóa đối xứng trong việc mã hóa gói tin. 3. Chống được các cuộc tấn công sniffing, passive…Việc trao đổi thông tin trong mạng nội bộ được quy thành các “gói tin”. Mỗi gói tin sẽ được mã hóa trước khi gửi đi và giải mã trước khi nhận về. Kết hợp với các phương pháp bảo mật đường truyền có sẵn như WEP, WPA, WPA2… sẽ là một thách thức không nhỏ với tin tặc. Dù có tóm được gói tin cũng không thể giải mã được. Hạn chế của ứng dụng: 1. Ứng dụng hoạt động là Windows Application, muốn sử dụng phải cài phần mềm vào máy. 2. Mã hóa và truyền gói tin còn chậm, không truyền được file lớn. 3. Chưa tích hợp khả năng kí để xác thực gói tin. 4. Giao diện có sơ sài, chưa bắt mắt. 5. Do tích hợp eToken nên việc nhập mã PIN sai quá 3 lần sẽ khóa eToken lại, gây phiên phức cho người dùng vì nó mang tính bảo mật cao, yêu cầu phải thực hiện đúng Hướng phát triển tiếp theo: 1. Chuyển phần mềm thành ứng dụng webbase. Có thể sử dụng không cần cài đặt, có thể sử dụng trên các thiết bị di động. 2. Cải tiến khả năng truyền tải file giữa các người dùng với nhau. 3. Tích hợp khả năng kí xác thực. 4. Cải tiến giao diện, tích hợp vào cổng thông tin điện tử. 90 TÀI LIỆU THAM KHẢO Tiếng Việt [1]. Phạm Huy Điển, Hà Huy Khoái, (2003), Mã hóa thông tin cơ sở toán học và ứng dụng, Nhà xuất bản Đại học Quốc gia Hà Nội. [2]. Phan Đình Diệu, (1999), Lý thuyết mật mã và an toàn thông tin, Đại học Quốc Gia Hà Nội, Hà Nội. [3]. Trịnh Nhật Tiến, (2004), Bài giảng: “Một số vấn đề về an toàn dữ liệu”. [4]. Nguyễn Thúy Vân, (1999), Lý thuyết mã, Nhà xuất bản Khoa học và kỹ thuật. Tiếng Anh [5]. Aaron E. Earle, (2006), Wireless Security Handbook, Auerbach Publications Taylor & Francis Group, New York. [6]. Cyrus Peikari, Seth Fogie, (2002), Maximum Wireless Security, Sams Publishing, USA. [7]. Jahanzeb Khan, Anis Khwaja, (2003), Building Secure Wireless Networks with 802.11, Wiley Publishing, Indianapolis, Indiana. [8]. Jon Edney, William A. Arbaugh, (2003), Real 802.11 Security: Wi-Fi Protected Access and 802.11i, Addison Wesley, Boston. [9]. Lee Barken, (2003), How Secure Is Your Wireless Network? Safeguarding Your Wi-Fi LAN, Prentice Hall PTR, New Jersey. [10]. William Stallings (2005), Cryptography and Network Security Principles and Practices, Fourth Edition, Prentice Hall. 91 LÝ LỊCH TRÍCH NGANG Họ và tên: Phan Thành Vinh Ngày tháng năm sinh: 21/10/1981 Nơi sinh: Thanh Hoá Địa chỉ liên lạc: Thôn Cầu - Bãi Trành – Như Xuân – Thanh Hóa Quá trình đào tạo: - 2000 - 2005: Học CNTT tại Đại Học Vinh. - 2012 - 2014: Học Cao học CNTT tại Học viện Kỹ thuật Quân sự. Quá trình công tác: - 2006 - 2012: Giáo viên Trường THPT Như Xuân 2. - 2012 - 2014: Giảng Viên Trường Đại Học Kinh Doanh Và Công Nghệ Hà Nội. XÁC NHẬN QUYỂN LUẬN VĂN ĐỦ ĐIỀU KIỆN NỘP LƯU CHUYỂN CHỦ NHIỆM KHOA (BỘ MÔN) CÁN BỘ HƯỚNG DẪN QUẢN LÝ CHUYÊN NGÀNH (Ký và ghi rõ họ tên) (Ký và ghi rõ họ tên)