3.3.1. Chuẩn xác thực thông điệp trong Mobile IP
Khi MN thực hiện quá trình trao đổi thông tin, MN cần tiến hành đồng thời quá trình xác thực thông tin. Do các liên kết ởđây là các liên kết vô tuyến, trạm di
động không kết nối trực tiếp với mạng cho nên rất dễ xảy ra tình trạng giả mạo thông tin khi các nút khác muốn truy cập mạng. Hơn nữa, kết quả quá trình đăng ký của Mobile IP sẽđưa đến kết quả là các luồng dữ liệu sẽđược định hướng lại tới địa chỉ COA của MN. Việc định hướng lại gói tin này là một ngưy cơ an ninh trên Internet nếu như không được xác thực.[2]
Vì vậy, cần thực hiên cơ chế xác thực thông tin. Trong Mobile IP, cơ chế
xác thực thông tin được sử dụng thuật toán mặc định là MD5 với kích thước khoá 128 bit hoặc lớn hơn cùng với cơ chế phân phối khóa thủ công. Thuật toán MD5 theo dạng “tiền tố - hậu tố” để bảo vệ dữ liệu với một “khóa bí mật” được xem là “dễ bị tổn thương” trong cộng đồng mã hóa. Do đó, tuy việc đảm bảo tính tương thích với phiên bản Mobile IP hiện tại là cần thiết nhưng những cài đặt mới nên sử
dụng thuật toán xác thực MD5 khóa (Keyed MD5) làm một thuật toán dự phòng khi tạo và kiểm tra các dữ liệu xác thực trong các thông điệp đăng ký của Mobile IP.
Mobile IP sử dụng các cấu trúc mở rộng trong các thông điệp điều khiển (sử
dụng cổng UDP 434) cho các quá trình xác thực giữa MN và HA, giữa MN và FA, giữa FA và HA.
a) Tính toán các giá trị xác thực
Các giá trị xác thực được tính toán để sử dụng cho mở rộng xác thực phải có khả năng bảo vệ các trường dữ liệu sau trong các thông điệp đăng ký:
- Tải dữ liệu UDP (UDP payload): đó là các dữ liệu yêu cầu đăng ký và trả lời đăng ký.
- Các phần mở rộng khác của thông điệp đăng ký
- Các trường kiểu, độ dài và chỉ mục tham số bảo mật SPI
Thuật toán xác thực ngầm định sử dụng thuật toán HMAC-MD5 (Hashed- based Message Authentication Code – Message Digest Algorithm 5) để tính toán giá trị 128 bit “message digest” của thông điệp. Các dữ liệu mà thuật toán HMAC tính toán bao gồm:
- Tải dữ liệu UDP (UDP payload): đó là các dữ liệu yêu cầu đăng ký và trả lời đăng ký.
- Các phần mở rộng khác của thông điệp đăng ký
Lưu ý rằng, trường giá trị xác thực và phần tiêu đề UDP không được bao gồm trong tính toán giá trị xác thực.
Chỉ số tham số bảo mật (SPI) trong các mở rộng xác thực định nghĩa ngữ
cảnh được sử dụng để tính toán giá trị xác thực và phải được sử dụng bởi bên nhận
để kiểm tra giá trịđó. Cụ thể hơn, giá trị SPI chỉ ra thuật toán xác thực, “mode” xác thực, và khóa bí mật (có thể là một khóa được chia sẻ, hay một cặp khóa bí mật/khóa công khai thích hợp).. Để đảm bảo tính tương thích giữa những cài đặt của Mobile IP, một cài đặt phải có khả năng gán một giá trị SPI bất kỳ với một thuật toán xác thực và mode bất kỳ thuật toán đó cài đặt.
b) Xác thực giữa MN và HA
Đểđảm bảo an toàn, tất cả các yêu cầu đăng ký và tất cả các trả lời đăng ký của HA phải có một mở rộng xác thực. Mở rộng xác thực giữa MN và HA sẽ loại bỏ các vấn đề có nguy cơ an toàn do sự lan truyền của các định hướng lại trên Internet. Ví dụ, một nút nguy hiểm có thể khiến HA thay đổi bảng định tuyến với một địa chỉ COA sai có chủ ý, khi đó các gói tin sẽ không tới MN.
Hình 29: Khuôn dạng thông điệp mở rộng xác thực MN và HA
c) Xác thực giữa MN và FA
Mở rộng này có thểđược đưa vào trong các yêu cầu đăng ký và trả lời đăng ký trong trường hợp có một liên kết bảo mật giữa MN và FA.
Hình 30: Khuôn dạng thông điệp mở rộng xác thực MN và FA
d) Xác thực FA và HA
Mở rộng này có thểđược sử dụng trong các yêu cầu đăng ký và trả lời đăng ký trong trường hợp có một liên kết bảo mật giữa FA và HA.
Hình 31: Khuôn dạng thông điệp mở rộng xác thực MA và FA
3.3.2. Xác thực theo cơ chế yêu cầu/đáp ứng
Mobile IP định nghĩa cơ chế xác thực cho phép các MN có thể tự xác thực với một FA thông qua một thông điệp mở rộng (mục 3.3.1). Tuy nhiên, cơ chế xác thực này không đủ mạnh để chống lại tấn công replay, đồng thời không cho phép sử (adsbygoogle = window.adsbygoogle || []).push({});
dụng các kỹ thuật xác thực hiện có (như CHAP).
Các đặc tả trong [5] định nghĩa các mở rộng cho các thông điệp quảng bá Agent và yêu cầu đăng ký Mobile IPv4. Các đặc tả này định nghĩa một cơ chế yêu cầu/đáp ứng (challenge/response) cho phép xác thực MN. Cơ chế này là giải pháp cho xác thực và cấp quyền truy nhập. Chuỗi yêu cầu là một giá trị ngẫu nhiên 128 bit và được dùng cho thủ tục xác thực. Một liên kết tin cậy giữa một FA và một HA
được hình thành sử dụng cơ chế của một hạ tầng kiểm tra (verification infrastructure - Hình 32).
Hình 32 Hạ tầng kiểm tra
Sau khi FA nhận được đáp ứng từ MN, FA chuyển xuống hạ tầng quản lý khóa và kiểm tra (Verification and key management Infrustructure) và chờ một trả
lời đăng ký. FA chấp nhận đăng ký từ hạ tầng đó chỉ khi trả lời là đồng ý. Nếu trả
lời là từ chối, FA sẽ xem như chuỗi yêu cầu không thỏa mãn sự kiểm tra.
a) Quảng bá trạm với mở rộng yêu cầu/đáp ứng
Để gửi đi trên mạng một challenge cho các MN đang cần xác thực, FA sử
dụng một mở rộng của giao thức phát hiện định tuyến (Router Discovery Protocol):
Hình 33 Mở rộng challenge
Trong đó:
- Type: nhận giá trị 24
- Length: độ dài giá trị challenge tính theo byte
- Challenge: một giá trị ngãu nhiên, nên có độ lớn tối thiểu 32 bit.
b) Cơ chế MN xử lý các yêu cầu đăng ký
Khi các quảng bá của các Agent chứa mở rộng Challenge, và nếu MN không có một thiết lập bảo mật với FA, MN sẽ phải đưa giá trị Challenge vào trong thông điệp yêu cầu đăng ký. Ngược lại, nếu MN đã có một thiết lập bảo mật với FA, nó không nhất thiết nhưng nên đưa giá trị challenge vào thông điệp yêu cầu đăng ký.
Trong trường hợp MN đã có một thiết lập bảo mật với FA, Và MN sẽ phải gửi cả phần mở rộng xác thực MN-FA trong thông điệp yêu cầu đăng ký. Khi yêu cầu đăng ký chứa mở rộng Challenge MN-FA, quá trình xác thực MN-FA phải tiếp sau mở rộng Challenge trong yêu cầu đăng ký.
c) Cơ chế FA xử lý các yêu cầu đăng ký
Khi nhận được yêu cầu đăng ký, nếu FA đã gửi đi một Challenge trong thông điệp quảng bá Agent; FA cũng chưa có một thiết lập bảo mật với MN, FA sẽ
phải kiểm tra để đảm bảo rằng mở rộng Challenge MN-FA tồn tại, và giá trị
Challenge đó chưa được dùng bởi MN. Nguyên tắc này để tránh MN sử dụng replay với một thông điệp quảng bá và xác thực trước đó.
d) Cơ chế FA xử lý các trả lời đăng ký
FA có thể gửi một Challenge mới trong các trả lời đăng ký, cho dù đăng ký
đã thành công hoặc chưa. Nếu FA gửi mở rộng Challenge trong trả lời đăng ký thành công, mở rộng Challenge nên được đặt trước mở rộng xác thực MN-FA.
Nếu trả lời đăng ký có chứa một mở rộng Challenge từ HA, và FA cũng muốn gửi một mở rộng Challenge cùng với trả lời đăng ký cho MN. Trong trường hợp này, FA phải xóa mở rộng Challenge từ HA trong trả lời đăng ký, cùng với mọi mở rộng xác thực giữa FA-HA trước khi FA thêm vào các mở rộng Challenge mới.
e) Cơ chế xử lý mở rộng Challenge của HA
Nếu HA nhận được một yêu cầu đăng ký với mở rộng Challenge MN-FA, HA phải gửi một mở rộng Challenge trong trả lời đăng ký. Mở rộng Challenge của HA phải đặt sau mở rộng xác thực MN-HA.
f) Cấu trúc mở rộng Challenge MN-FA
Mở rộng Challenge đưa vào thông điệp yêu cầu đăng ký được dùng để chỉ (adsbygoogle = window.adsbygoogle || []).push({});
Hình 34 Mở rộng Challenge MN-FA
Trong đó:
- Type: nhận giá trị 132
- Length: độ dài giá trị Challenge
- Challenge: giá trị Challenge được copy từ trường Challenge của thông
điệp quảng bá Agent.
3.3.3. Xác thực theo cơ chế khóa công khai PKA
Theo cơ chế xác thực dựa trên khóa công khai PKA Mobile IP (Public Key Authenticated Mobile IP) [14] , một mở rộng được bổ sung vào giao thức Mobile IP cơ bản. Cơ chế này định nghĩa cách thức các MN và Agents sử dụng xác thực bằng khóa công khai hay khóa bí mật qua chữ ký số (digital signature). Việc mở rộng đó giải quyết thỏa mãn yêu cầu về xác thực và phân phối khóa mã.
Phương pháp tiếp cận SSA (secure scalable authentication) được áp dụng trong mở rộng này. Phương pháp tận dụng các trường để dành trong các định nghĩa thông điệp của Mobile IP. Các chức năng được thêm vào của SSA cho phép thay
đổi mở rộng xác thực được dùng trong giao thức Mobile IP nhằm đảm bảo các kiểu và kích thước khác nhau của chủ thể xác thực (authenticator).
PKA tăng cường thêm đáng kể khả năng xác thực của Mobile IP. PKA cũng không gây ảnh hưởng tới chức năng hoạt động vốn có của Mobile IP. PKA chỉ thay
đổi các chủ thể tạo và kiểm tra các thông điệp cũng như các cấu trúc dữ liệu hỗ trợ
các chủ thể chữ ký số.
a) Mở rộng quảng bá Agent
Mobile IP PKA Mobile IP
Hình 35 Mở rộng quảng bá Agent
b) Thông điệp yêu cầu đăng ký nhận bởi FA
Mobile IP PKA Mobile IP
c) Thông điệp yêu cầu đăng ký gửi tới HA
Mobile IP PKA Mobile IP
Hình 37 Thông điệp yêu cầu đăng ký gửi tới HA
d) Thông điệp trả lời đăng ký từ FA
Mobile IP PKA Mobile IP
e) Thông điệp trả lời đăng ký MN nhận được
Hình 39 Thông điệp trả lời đăng ký MN nhận được
3.3.4. Xác thực với khóa công khai tối thiểu
Giao thức Mobile IP dựa trên sử dụng các khóa bí mật và phân phối khóa thủ công để xác thực các thông điệp điều khiển. Tiếp cận này không phù hợp với nhiều ứng dụng vì nó chắc chắn sẽ dẫn tới các vấn đề về quản lý khóa. Hơn nữa, thậm chí các thông điệp đã được mã hóa và cơ chế bảo vệ chống replay đã được triển khai, các giao thức đang ký hiện tại vẫn có khả năng bị tấn công replay. Giải pháp khóa công khai (mục 3.3.3) được đề nghịđể có thể cung cấp một giải pháp xác thực dựa trên mã hóa khóa công khai. Tuy nhiên, nhược điểm là yêu cầu đặt lên MN nhằm thực hiện các tính toán mã hóa khóa công khai.
Giao thức xác thực với khóa tối thiểu cho Mobile IP [22] chỉ sử dụng một cách tối thiểu việc mã hóa với khóa công khai. Các nguyên tắc thiết kế và giả thiết trong giao thức này bao gồm:
- Tối thiểu hóa các yêu cầu vể khả năng tính toán cũng như chi phí quản lý đăt lên MN. Giải pháp này đạt được tính mềm dẻo mà vẫn giữ các hoạt động trên khóa công khai ở mức tối thiểu.
- Không cần bổ sung các thông điệp trừ khi các thông điệp điểu khiển Mobile IP ban đầu. Do vậy, MN sẽ có khả năng linh hoạt để chọn phương thức xác thực. (adsbygoogle = window.adsbygoogle || []).push({});
Theo [22] , ngoài vai trò là một Agent, HA cũng đóng vai trò làm một agent xác thực khóa công khai cho MN. Nghĩa là HA sẽ giống như một server đối với MN
để cung cấp dịch vụ xác thực.
Do vậy, giao thức xác thực với khóa công khai tối thiểu có các ưu điểm so với phương thức xác thực của Jacobs [14] :
- MN thực hiện các công việc mã hóa của nó sử dụng khóa bí mật tương tự như xác thực dựa trên khóa chung bí mật.
- MN được giải phóng khỏi công việc như kiểm tra chứng chỉ số
- Sau khi MN nhận được thông báo đăng ký thành công từ HA, MN có thểđảm bảo rằng chứng chỉ bởi FA là còn hiệu lực.
Ngoài việc cung cấp dịch vụ xác thực, HA cũng có thể đóng vai trò trung tâm phân phối khóa (Key Distribution Center – KDC) để phân phối các khóa phiên (session key). Các khóa phiên này sau đó có thể được dùng tạo thiết lập bảo mật (security association) giữa MN và FA. .
3.4. Giải pháp với kiến trúc AAA
3.4.1. Xác thực, kiểm soát và tính phí với AAA
Trong mạng Internet cốđịnh (wired), có một số chuẩn cho việc xác thực và cấp phép truy nhập cho các máy tính quay số. Giao thức AAA được biết tới và triển khai nhiều nhất là RADIUS (Remote Dialing User Service). Một giao thức AAA mới được coi là thế hệ tiếp theo của RADIUS là DIAMETER.
Mô hình AAA cơ bản triển khai cho Mobile IP được đề xuất trong [6] , [20] Các định nghĩa mở rộng cho thông điệp đăng ký để sử dụng các thiết lập bảo mật giữa MN và máy chủ AAA cho HA, FA được định nghĩa trong [7]
Khi một “khách” (client) thuộc một vùng (domain) quản lý khác có nhu cầu sử dụng các tài nguyên tại một vùng khác, cần có các chứng nhận từ khách đó. Theo mô hình cơ bản được đề xuất (Hình 40), một cơ chế kiểm soát cục bộ (AAAF – Foreign Authority) tại vùng mới tới của khách sẽ thông qua một agent (còn gọi là
phục vụ - attendant) yêu cầu và kiểm tra các chứng thực từ “khách”, đảm bảo tính hợp lệ trước khi “khách” có thể truy cập các tài nguyên.
Hình 40: Mô hình Mobile IP/AAA cơ bản
Thường thì AAAF không có khả năng xác thực cho khách. Tuy nhiên, AAAF có .khả năng thương lượng việc xác thực khách với một cơ chế xác thưc bên ngoài, đó là server AAA tại vùng thường trú của khách (AAAH - Home Authority). AAAF và AAAH sẽ có các thiết lập bảo mật với nhau và có khả năng thương lượng và cấp truy nhập cho các “người dùng” của nhau.
Hình 41: Các thiết lập bảo mật trong mô hình Mobile IP/AAA
Mô hình Mobile IP/AAA có một vài thiết lập bảo mật cụ thể như được minh họa trong Hình 41.Đây là sự khác nhau cơ bản giữa mô hình này và mô hình bảo mật của giao thức Mobile IP chuẩn. Khác với giao thức Mobile IP chuẩn, mô hình AAA giả sử rằng MN có một thiết lập bảo mật SA1 với AAAH; còn trong giao thức Mobile IP chuẩn, MN có một thiết lập bảo mật với HA.
Mô hình AAA này có các yêu cầu cơ bản [20] :
- Giữa mỗi phục vụ và AAA server (AAAF) phải có một thiết lập bảo mật bắt buộc.
- Giữa hai miền (thường trú và tạm trú) phải có các thiết lập bảo mật để
có thể xác thực các chứng thực của “khách”.
- Trong khi miền tạm trú liên lạc với miền thường trú để trao đổi, phục vụ
phải lưu giữ trạng thái cho các yêu cầu đang chờ xử lý.
- MN phải có khả năng cung cấp các chứng thực tin cậy mà không bắt bưộc trước đó phải tương tác trực tiếp với miền của nó.
Khi đó máy chủ AAA có các nhiệm vụ bổ sung đối với Mobile IP:
- Máy chủ AAA cấp phép để MN có thể sử dụng Mobile IP và các dịch vụ cụ thể khác.
- Máy chủ AAA phải khởi tạo và cho phép xác thực các thông điệp đăng ký.
- Máy chủ AAA phải phân phối khóa tới các MN, HA, FA.
Mỗi sự lặp lại của tiến trình phân phối khóa có thể gây ra các sự trễ kéo dài giữa các lần đăng ký. Do đó, tất cả các thiết lập bảo mật được phân phối bởi máy chủ AAA cần có thời gian sống thích hợp để tránh những sự trễđó. Nếu sự trễ trong
(adsbygoogle = window.adsbygoogle || []).push({});