Đầu tiên khi SS muốn gia nhập mạng nó phải gửi một thông điệp yêu cầu Ranging (RNG-REQ). Thông điệp này thông báo cho BS về sự hiện diện của SS và yêu cầu các thông số như thời điểm truyền phát, công suất, tần số và các thông tin trong burst profile, thông điệp này được SS gửi đi theo chu kỳ. BS đáp lại bằng một thông điệp RNG-RSP. Trong các phiên bản cũ của 802.16 SS gửi thông điệp này theo chu kỳ. Nếu SS không hoàn thành quá trình ranging theo chu
kỳ nó sẽ bị loại khỏi mạng và phải thực hiện quá trình gia nhập mạng ban đầu. Tuy nhiên phiên bản 802.16a không yêu cầu SS phải gửi thông điệp này theo định kỳ, thay vào đó SS có thể nhận bất cứ thông điệp nào từ phía BS và sử dụng nó để điều chỉnh ranging. Và BS gửi thông điệp RNG-RSP để thông báo cho SS về sự thay đổi các kênh hướng lên, hướng xuống, mức công suất phát và cũng có thể sử dụng thông diệp này để hủy bỏ sự truyền dẫn của SS và bắt SS khởi đầu lại.
Loại thông điệp quản lý M∙ nhận dạng kênh hướng lên ( 8 bit)
Nội dung thông điệp
5= RNG-RSP ID của kênh hướng lên
mà BS nhận được RNG- REQ
Nội dung được chỉ ra ở bảng 3.2
Bảng 3.1: Dạng thông điệp RNG-RSP
Lý do chính khiến thông điệp này trở thành điểm yếu là ví nó không hề được bảo mật. Và khi SS nhận được thông điệp này nó sẽ hoạt động theo sự chỉ dẫn trong thông điệp.
Có một số cách để sử dụngthông điệp này trong quá trình tấn công như sau:
ã Cách 1:kẻ tấn công sử dụng thông điệp này với trường trạng thái ranging bằng 2 (Ranging Status) tức là hủy bỏ sự truyền dẫn hiện tại của SS.
ã Cách 2: dịch nạn nhân lên một kênh khác. Nếu kẻ tấn công sử dụng một BS giả mạo ở một kênh riêng thì SS sẽ bị buộc phải giao tiếp với BS giả mạo này. Nếu không có một BS nào trên kênh đã chỉ ra SS sẽ lại trở lại kênh ban đầu.
Sẵn sàng hoạt động Timeout 4 Timeout 3 Duy trỡ băng thụng hướng lờn RSGưRSP Reset T4 Mó ranging cú vượt quỏ phạm vi? Đặt mó ranging vào khe ranging Reset T4 Xúa T3 Mó trạng thỏi ranging ? Lỗi: khởi tạo lại MAC Điều chỉnh thụng số trong RNGư RSP Điều chỉnh thành cụng? Mó ranging ? Gửi RNGư REQ sau khi chỉnh sửa Gửi RNGưREQ Reset T3 ( nếu khụng hoạt động) Gửi dữ liệu hướng lờn Lỗi: Khởi tạo lại MAC Sẵn sàng hoạt động TẤN CễNG THÀNH CễNG GỬI THễNG ĐIỆP RNGưREQ VỚI MÃ = 2 N Y Từ chối Thành cụng N Y Tiếp tục
Tên Loại (1 byte) Chiều dài (byte) Giá trị Điều chỉnh định thời (Timing Adjust) 1 4 Điều chỉnh lệch định thời (gồm 32 bit). Chỉ ra thời điểm để SS gửi tin để gói tin đến được BS đúng thời điểm
Điều chỉnh mức công suất
Power Level Adjust
2 1
Điều chỉnh lệch công suất phát (gồm 8 bit, đơn vị sử dụng là 0,25 dB ). Chỉ ra sự thay đổi về công suất phát sao cho SS có thể truyền tới BS với mức công suất phù hợp Điều chỉnh lêch tần số (Offset Frequency Adjust) 3 4 Điều chỉnh lệch tần số (gồm 32 bit, đơn vị tính bằng Hz). Chỉ ra sự thay đổi tần số để phù hợp với BS hơn. Sự thay đổi này chỉ xảy ra trong một kênh.
Trạng thái ranging
(Ranging Status) 4 1
Dùng để chỉ ra liệu các thông điệp hướng lên có được BS chấp nhận hay không.
1=tiếp tục, 2= hủy bỏ, 3= thành công, 4= ranging lại Downlink frequency
override 5 4
Tần số trung tâm, của kênh mới mà SS sẽ dùng để khởi đầu lại. Đơn vị tính bằng kHz. Uplink channel ID
override 6 1
Mã nhận dạng kênh hướng lên mà SS sẽ sử dụng để khởi đầu lại
Downlink Operational
Burst Profile 7 1
Thông số này được sử dụng để đáp lại thông điệp RNG- REQ.
SS MAC Adress 8 6 Địa chỉ MAC của SS gồm 48
bit
Basic CID 9 2
CID cơ bản được gán bởi BS trong quá trình truy nhập ban đầu.
Primary Management
CID 11 2
CID quản lý chính được gán bởi BS trong quá trình truy nhập ban đầu
PHY Specific Values 12-16 Được thêm vào để cung cấp
hỗ trợ OFDMA và AAS
Bảng 3.2: Các m∙ trong thông điệp RNG-RSP
3.2.3.3.2 Cuộc tấn công vào thông điệp thông báo quyền không hợp lệ
Ta biết rằng máy trạng thái trao quyền là một phần của giao thức PKM. Như thường lệ nó sử dụng hai thông điệp quản lý PKM-REQ và PKM- RSP. SS gửi PKM- REQ tới BS. BS đáp lại bằng PKM-RSP.
Loại thông điệp quản lý M∙ thông điệp ( 8 bit) Nhận dạng PKM Thuộc tính PKM 9= PKM- RSP 10= PKM- REQ Nhận dạng loại thông điệp PKM Số serial của thông điệp Khác nhau tùy thông điệp Bảng 3.3: Dạng thông điệp PKM
Mã thông điệp là một trường 8 bit để chỉ ra chính xác loại thông điệp PKM. Nếu thông điệp có mã không hợp lý thì sẽ bị loại bỏ.
M∙ Loại thông điệp PKM
0-2 Chưa sử dụng
3 Security Association Add
4 Auth Request 5 Auth Reply 6 Auth Reject 7 Key Request 8 Key Reply 9 Key Reject 10 Auth Invalid 11 TEK In valid 12 Authentication Info 13 - 255 Chưa sử dụng Bảng 3.4: M∙ thông điệp PKM
Phần nhận dạng PKM là một trường 8 bit được dùng như số serial. Mỗi lần PKM- REQ gửi bởi SS phần nhận dạng PKM-REQ sẽ tăng lên một giá trị. Khi BS đáp lại bằng thông điệp PKM -RSP sẽ gồm một phần nhận dạng tương ứng với thông điệp nó nhận được. Nếu SS nhận được bất kỳ thông điệp nào có phần nhận khác yêu cầu được gửi đi SS sẽ từ chối.
Trường thuộc tính PKM rất khác nhau tùy theo loại thông điệp PKM. Trường này thường chứa thông tin về mã sửa lỗi, thời gian sống của khóa, chuỗi hiện thị.
Theo bảng trên ta tháy có 4 thông điệp có thể được sử dụng để tấn công là:
ã Auth Reject
ã Key Reject
ã Auth Invalid
Đây là những thông điệp có khả năng phủ nhận quá trình trao quyền của SS. Sử dụng những thông điệp này sẽ tạo ra những cuôc tấn công giống dạng Deauthentication. Tuy nhiên trong các thông điệp trên có 3 thông điệp Auth Reject, Key Reject và TEK Invalid không được sử dụng. Vì những thông điệp này yêu cầu số HMAC để xác thực thông điệp. Như ta đã biết rất khó để tạo ra một HMAC chính xác. Chỉ có một cách là phá vỡ sơ đồ bảo mật. Hơn nữa những thông điệp này chỉ có thể nhận được trong một khoảng thời gian rất ngắn.
Thông điệp cuối cùng còn lại là thông điệp Auth Invalid. Thông điệp này không yêu cầu xác thực bằng HMAC, không bao gồm nhận dạng PKM. Nó cũng không cần một trạng thái nào để được xem là hợp pháp. Thông điệp này là một thông điệp không trạng thái, SS có thể nhận nó tại mọi thời điểm. Những lý do này khiến kẻ tấn công có thể sử dụng nó dễ dàng hơn.
Thuộc tính Chức năng
Mã lỗi (Error Code) Chỉ ra lý do cho sự trao quyền bất hợp
pháp Chuỗi hiện thị
(Display String) (tùy chọn)
Chuỗi hiện thị mô tả điều kiện lỗi
Bảng 3.5: Thuộc tính thông điệp Auth Invalid
Mặt khác trong phần mã lỗi có giá trị bằng 0 không đưa ra một lý do nào về sự không hợp lệ của thông điệp sẽ tạo điều kiện tấn công.
M∙ lỗi Thông điệp Mô tả
0 Dành cho tất cả Không đữ ra thông tin gì
1 Auth Reject, Auth Invalid SS không được trao quyền
2 Auth Reject, Key Reject SAID không được trao quyền
4 Auth Invalid, TEK Invalid Số thứ tự của khóa không hợp lệ
5 Auth Invalid Lỗi trong xác thực thông điệp
6 Auth Reject Lỗi trao quyền cố hữu
Bảng 3.6: Giá trị m∙ lỗi trong thông điệp xác thực
Khi SS nhận được thông điệp Auth Invalid sẽ chuyển từ trạng thái được trao quyền sang trạng thái đợi trao quyền lại. Như vậy SS sẽ đợi cho đến khi nó nhận được tin phản hồi từ BS. Nếu thời gian đợi trao quyền lại chấm dứt trước khi SS nhận được tin từ BS, SS sẽ gửi 1 thông điệp xin trao quyền lại (Reauth Request) để cố gắng gia nhập mạng. Và trong khi đang đợi trao quyền lại SS có thể sẽ nhận được thông điệp loại bỏ trao quyền lại (Reauth Reject). Đây là trường hợp “lỗi trao quyền cố hữu”. Rơi vào trường hợp này SS sẽ trở về trạng thái yên lặng, không gửi bất kỳ một tin nào và luôn sẵn sàng đáp lại bất kỳ một thông điệp quản lý nào được gửi từ BS. Với cơ chế như trên kẻ tấn công có thể tạo ra một máy trạng thái trao quyền nguy hiểm.
3.3 Những cải tiến mới về an ninh trong mạng WiMAX 3.3.1 Giao thức PKM v2 3.3.1 Giao thức PKM v2
Phiên bản PKM v1 hoàn toàn tương tự như lớp con bảo mật tuy nhiên nó hỗ trợ phương pháp bảo mật mới như 3 DES-ECB và AES-ECB để bảo vệ bí mật vật chất khóa và dùng AES-CCM cho MPDU. Bên cạnh đó sử dụng HMAC- SHA-1 để bảo vệ toàn vẹn thông điệp. Phiên bản PKM v2 có nhiều thuộc tính hơn bao gồm xác thực hai chiều sử dụng hai giao thức xác thực dựa trên RSA và dựa trên EAP, ngoài ra còn có thuật toán toàn vẹn thông điệp và giao thức quản lý khóa.
PKM v2 là một phần của chỉ tiêu kỹ thuật hỗ trợ khả năng di dộng cho chuẩn 802.16. Khi SS di động nó sẽ cần được xác thực trước với BS mà nó định tham gia liên kết để giảm khả năng ngắt quãng dịch vụ.
Xác thực và điều khiển truy nhập trong PKM v2
PKMv2 sẽ sửa chữa hầu như toàn bộ các điểm yếu của giao thức PKMv1. đặc biệt là khả năng mã hóa bảo mật MPDU bằng AES-CCM. CCM gồm counter mode để mã hóa thông điệp và dùng CBC-MAC để bảo vệ toàn vẹn thông điệp.
Giao thức xác thực và thiết lập khóa có một vài thay đổi giúp bảo vệ chống lại các cuộc tấn công khác nhau.
Trước tiên đó là quá trình khởi đầu dựa trên RSA cho phép xác thực và trao quyền. Bên cạnh đó có giao thức xác thực dựa trên EAP cho những người sử dụng cơ sở hạ tầng xác thực phụ trợ (back end) như AAA hay RADIUS. Quá trình trao đổi khóa xác thực cũng chứa nonce để chứng minh về sự tồn tại của thông điệp, giúp bảo vệ khỏi các cuôc tấn công lặp lại. Sau đó là sự phân cấp khóa giúp giảm chi phí trong quá trình xác thực và trao quyền ban đầu. Cuối cùng là khả năng lưu trữ dùng cho quá trình chuyển giao nhanh (fast handoff).
3.3.1.1 Xác thực hai chiều dựa trên public- key
Xác thực và trao quyền dựa trên public key gồm 3 thông điệp trong đó có một thông điêp tùy chọn từ SS gửi đến BS.
Thông điệp 1:
SS → BS: Cert (Manufacturer(SS))
Thông điệp 2:
SS → BS: SS-Random | Cert(SS) | Capabilities |SAID
Thông điệp 3:
BS → SS: SS-Random | BS-Random |
RSA- Encryption (PubKey(SS), pre- AK | Lifetime | SeqNo | SAIDList | Cert(BS) | Sig (BS)
3.3.1.1.1 Thông điệp yêu cầu trao quyền (thông điệp 2)
SS bắt đầu quá trình trao quyền lẫn nhau dựa trên RSA bằng cách gửi đi thông điệp xin trao quyền. Thông điệp này chứa một số ngẫu nhiên SS-
RANDOM 64 bít, chứng nhận số X509 của SS, danh sách thuật toán bảo mật (thuật toán toàn vẹn và mã hóa bảo mật) mà SS có thể sử dụng.
3.3.1.1.2 Thông điệp đáp lại trao quyền (thông điệp 3)
BS gửi thông điệp đáp lại trao quyền tới SS. Trong thông điệp này BS chỉ ra số ngẫu nhiên 64 bít mà nó nhận được, số ngẫu nhiên 64 bít của nó (BS_RANDOM), PAK 256 bít bảo mật bằng RSA ( bảo mật bằng khóa công khai của MS), thuộc tính của PAK ( thời gian sống, số thứ tự, một hoặc nhiều SAID), BS sẽ gộp cả chứng nhận số của nó và ký nhận toàn bộ thông điệp.
SS có thể nhanh chóng chứng nhận rằng BS là hợp pháp khi nó có sự ký nhận thông điệp. Tuy nhiên gia đoạn này quá trình trao quyền không đảm bảo rằng truy nhập mạng an toàn là sẵn có cho SS.
Sau khi chứng minh về chữ ký của BS nó sẽ kiểm tra sự sống bằng cách kiểm tra SS_RANDOM mà nó gửi đi và SS_RANDOM mà nó nhận được trong thông điệp. Sau đó nó sẽ rút ra các thông tin PAK, thuộc tính PAK và cuối cùng là SAID. Chú ý rằng chỉ có những SS được trao quyền mới có thể rút ra được PAK và nhờ đó SS chứng minh được về sự sở hữu PAK. SAID là tùy chọn trong thông điệp này nếu sau quá trình này xảy ra quá trình xác thực dựa trên EAP.
3.3.1.1.3 Thông điệp xác nhận trao quyền.
BS không thể chứng minh sự sống của thông điệp và cũng không quyết định được liệu một SS hợp pháp có thực sự đang yêu cầu truy nhập mạng thay không. Thông điệp xác nhận trao quyền cung cấp sự đảm bảo này. Trong thông điệp này SS gửi đi cả số nó nhận được trong thông điệp đáp lại trao quyền từ BS ( BS_RANDOM) và địa chỉ MAC và phương pháp kiểm tra thông điệp xác nhận. Thuât toán toàn vẹn được dùng là OMAC với AES và khóa OMAC được lấy ra từ PAK. Kết thúc quá trình trao quyền RSA BS sẽ được xác thực tới SS và SS được xác thực với BS.
3.3.1.2 Trao quyền lẫn nhau dựa trên EAP trong PKM v2
Trao quyền lẫn nhau dựa trên EAP trong PKM v2 tự nó có thể hỗ trợ xác thực hai chiều (xác thực không trực tiếp) thông qua sự chứng minh về sự sở hữu khóa nếu một AS phụ trợ liên quan. Tuy nhiên sự kết hợp trao quyền RSA và sau đó là xác thực EAP có thể được sử dụng cho truy nhập mạng WMAN. Trong trường hợp này trao quyền RSA được xem như là cung cấp sự xác thực lẫn nhau giữa các thiết bị, trái lại EAP được dùng để xác thực người sử dụng.
Xác thực dựa trên EAP trong PKM v2 tương tự như trong chuẩn 802.11i STA. Trong đó MS xác thực với AS thông qua một bộ xác thực (authenticator). BS trong mạng 802.16 có thể xem như một authenticator mặc dù trong một vài kiến trúc chức năng của BS và bộ xác thực là tách biệt nhau.
3.3.1.2.1 Quá trình xác thực dựa trên EAP
ã Bộ xác thực BS sẽ khởi đầu quá trình xác thực EAP. (Chú ý trong giao
thức dựa trên RSA SS là bên yêu cầu xác thực. BS gửi thông điệpyêu cầu EAP tới SS. ở đây một yêu cầu nhận dạng EAP được bọc trong PDU quản lý lớp MAC ( ví dụ như kênh quản lý thứ cấp mang thông điệp EAP)
ã SS đáp lại yêu cầu này bằng một thông điệp đáp lại EAP. Bộ xác thực
và MS tiếp tục trao đổi các thông điệp cho đến khi server xác thực quyết định rằng quá trình trao đổi này bị hủy bỏ hay thành công. Số lượng chính xác các thông điệp tùy thuộc vào phương pháp được sử dụng.
ã Một thông báo EAP thành công hay EAP bị lỗi sẽ chấm dứt quá trình
xác thực EAP.
Nếu EAP được thực hiện sau quá trình trao quyền RSA thông điệp EAP sẽ được bảo vệ sử dụng khóa toàn vẹn EAP là EIK (EAP integrity key) coi như là kết quả thành công của quá trình trao quyền RSA. Thông điệp EAP chứa số thứ tự của AK (AK và EIK được lấy từ quá trình trao quyền RSA) để bảo vệ chống
lại cuộc tấn công lặp lại và OMAC được tính toán bằng EIK dùng để bảo vệ toàn vẹn thông điệp.
3.3.1.2.2 Quá trình trao đổi 3 bước giữa SS và BS
SS và BS lấy được PMK từ khóa AAA (kết quả của quá trình EAP bằng cách lấy ra 20 byte theo thứ tự thấp nhất của khóa AAA. Quá trình trao đổi 3 bước được dùng với mục đích là chứng minh sự sở hữu giữa SS và BS. Mục đích cuối cùng của quá trình trao quyền là thiết lập khóa TEK và KEK để SS có thể truy nhập vào các dịch vụ của mạng. Quá trình trao đổi 3 bước như sau:
ã BS bắt đầu quá trình bằng cách gửi đi thông điệp yêu cầu khóa thiết lập EAP tới SS. Thông điệp này chứa nonce 64 bít, AKID của AK và cuối cùng là kiểm tra toàn vẹn thông điệp. Sự kiểm tra này được tính toán sử dụng khóa toàn vẹn lấy từ PKM. Nonce dùng để chứng minh sự tồn tại của hai bên đồng thời dùng để bảo vệ chống lại các cuộc tấn công lặp lại.
ã SS đáp lại bằng thông điệp trả lời. SS tạo ra 64 bit nonce được gọi là Random_SS chứa cả Random_BS trong thông điệp trước. Ngoài ra nó