b)
4.2.1.9 IKE module
Module IKE gồm các chức năng thực hiện xử lý của hai bên tham gia trong giao thức:
Bên khởi tạo (Initiator) và bên hồi đáp (Responder) và một số cấu trúc thông số được sử dụng cho IKE module. Mỗi bên có chức năng riêng của mình thực hiện xử lý.
a) Chức năng cơ bản của các module:
ikeInitiator / ikeResponder - chức được gọi khi bắt đầu quá trình IKE ở mỗi phía của đường hầm. Mỗi trong số họ thực hiện các giai đoạn chế độ chính IKE (main mode IKE) bằng cách gọi hàm ( initiatorMainMode / responderMainMode ) và sau đó thực hiện một tuần tự các giai đoạn chế độ nhanh ( trong khi đường hầm tồn tại) một lần sau một khoảng thời gian nhất định cho việc tạo khóa mới . Chế độ nhanh cho mỗi bên được thực hiện bằng 2 hàm initiatorQuickMode / responderQuickMode . Tất cả các thông số cần thiết về SA được tạo ra ( các giao thức và các thuật toán được sử dụng ) được thông qua như một tham số cho hàm
ikeInitiator . Sau khi các chế độ chính được hoàn thành thì SA được tạo ra và thông qua như là một đối số cho chế độ nhanh . Biến này chứa tất cả các thông tin cần thiết cho chế độ nhanh và toàn bộ cho quá trình
Hình 4-38:Tổng quan quá trình trao đổi IKE
initiatorMainMode / responderMainMode - thực hiện trao đổi của chế độ chính theo quy định của giao thức IKE. Mỗi bên gửi 3 gói tin và nhận được 3 gói tin trong một trật tự đối xứng, thực hiện tính toán mật mã (trao đổi Diffie-Hellman, tính toán khóa, tạo Hash và xác thực, xác thực
ISAKMP tiêu đề ) Cuối cùng cả hai chức năng cập nhật các thong số cho SA với các thông tin cần thiết cho quá trình tiến hành chế độ nhanh.
Hình 4-39:Quá trình thực hiện trao đổi pha 1
initiatorQuickMode / responderQuickMode - thực hiện trao đổi của chế độ nhanh theo quy định của giao thức IKE. Các bên trao đổi 3 gói tin (Initiator gửi 2 gói và Responder gửi 1 gói) và thực hiện tính toán khóa mới. Kết quả là các khóa mới được lưu trữ trong SA cho việc trao đổi dữ liệu trong đường hầm.
Hình 4-40:Quá trình trao đổi của pha 2
Chỉ số an ninh SPI của SA Thuật toán AH (ví dụ: MD5)
Thuật toán ESP (ví dụ: DES,3DES)
Tham số cho biết giao thức ESP hay AH được sử dụng Khóa AH của hai bên
Khóa ESP của hai bên.
SA của chế độ chính - chứa tất cả các thông số SA thu được trong chế độ chính và cần thiết cho chế độ nhanh để tạo ra các khóa cho IPSec:
Tất cả các khóa được tạo ra trong chế độ chính gồm : SKEYID_D, SKEYID_A, SKEYID_E .
Diffie Hellman tính khóa chia sẻ trong chế độ chính Cookie của cả hai bên
Nonces của cả hai bên
Message - duy trì tất cả các gói tin trao đổi trong IKE . Cấu trúc Message bao gồm :
Hình 4-41:Cấu trúc khung gói tin ISAKMP
ISAKMP Header - tất cả các gói tin có nó. Header này được thiết kế như là một cấu trúc có chứa tất cả các quy định cho giao thức IKE .
Proposal - cho tất cả các gói tin. Thông số này bao gồm các tên giao thức để trao đổi và SPI ( theo quy định tại IKE ) .
Transform - cho tất cả các gói tin. Bao gồm các thuật toán được sử dụng để xác thực và mã hóa các gói tin trao đổi.
Giá trị công cộng Diffie Hellman - cho các gói tin chế độ chính thứ 3 và 4. Được sử dụng để thực hiện trao đổi các giá trị Diffie Hellman.
Identity - cho chế độ nhanh và hai gói tin cuối cùng của chế độ chính. Mang tên thiết bị của bên gửi gói tin.
Nonce - cho chế độ nhanh và bốn gói tin cuối cùng của chế độ chính. Chứa giá trị nonce được lựa chọn bởi các bên gửi gói tin.
Hash - cho hai gói tin cuối cùng của chế độ chính và tất cả các gói tin chế độ nhanh . Chứa hàm băm gói tin được sử dụng để xác thực gói tin . Initialization Vector - cho tất cả các gói tin có chứa bất kỳ dữ liệu được
4.2.1.10Thực hiện giao thức trao đổi khóa IKE
Giao thức gồm 2 pha trao đổi:
a)
Pha 1- Chế độ chính (Main Mode):
Mục đích chính của pha này là thiết lập các thông số bí mật tổng thể mà từ đó tất cả các khóa mật mã sau đó sẽ được tạo ra để bảo vệ các gói tin ISAKMP cho việc thỏa thuận của pha 2 – chế độ nhanh tiếp theo. Điều quan trọng cần lưu ý là pha 1 là chỉ liên quan với việc thiết lập các thông số bảo vệ cho các thông điệp ISAKMP mình, nó không thiết lập bất kỳ kết hợp an ninh hoặc khóa để bảo vệ dữ liệu.Thông số nhận được từ pha 1 có thể được sử dụng để hỗ trợ cho nhiều pha 2 tiếp theo.
Sáu gói tin để hoàn thành việc trao đổi :
Hình 4-42:Trao đổi thỏa thuận IKE chế độ chính
Gói tin 1 và 2 thỏa thuận các đặc tính của kết hợp an ninh. Hai gói tin này không được xác thực.
Gói tin 3 và 4 trao đổi nonces và cũng thực hiện một trao đổi giá trị Diffie-Hellman công cộng để thiết lập khóa chủ (SKEYID). Nó là cơ sở cho việc tính toán khóa mật mã pha này. Hai gói tin này không được xác thực.
Gói tin 5 và 6 trao đổi chữ ký số với mục đích đôi bên chứng thực danh tính của các bên và trao đổi giá trj công cộng Diffie - Hellman. Một số dữ liệu của gói tin 5 và 6 được bảo vệ bởi các thuật toán mã hóa và khóa được tạo ra từ 4 gói tin trước đó.
Hình 4-45:Lưu đồ giải thuật của bên phản hồi pha 1 – chế độ chính
Gói tin thứ 1:
Thiết bị-A, bên khởi tạo, đề xuất kết hợp an ninh được xem xét bởi Thiết bị-B, bên trả lời. Do đó, các gói tin ISAKMP có chứa các thông số sau:
Header ISAKMP trong gói tin 1 sẽ cho biết loại này là trao đổi chế độ chính, và sẽ chứa ID gói tin là 0. Thiết bị-A sẽ thiết lập trường Responder Cookie là 0, và
sẽ điền vào một giá trị ngẫu nhiên vào trường Initiator Cookie ( biểu thị như Cookie-A ).
Thiết bị-A sẽ chỉ định trường Proposal là giao thức PROTO_ISAKMP và sẽ thiết lập giá trị SPI là 0.
Trường Transform sẽ được chỉ định là giá trị KEY_OAKLEY. Cho việc trao đổi KEY_OAKLEY, Thiết bị -A cũng phải xác định các thuộc tính liên quan: cụ thể là, các phương pháp xác thực được sử dụng, hàm giả ngẫu nhiên được sử dụng, và các thuật toán mã hóa được sử dụng. Trong việc thực hiện của chúng tôi Thiết bị -A sẽ sử dụng: xác thực bằng chữ ký số, hàm giả ngẫu nhiên MD5, và thuật toán mã hóa DES hoặc 3DES.
Gói tin thứ 2 của pha 1 – Chế độ chính:
Trong gói tin này Thiết bị-B hồi đáp lại Thiết bị -A, sau khi nhận được gói tin Tin nhắn có cấu trúc tương tự như gói tin thứ 1.
Trường Proposal và Tranform chứa các đề nghị thỏa thuận của Thiết bị-A được thừa nhận trước đó.
Tiêu đề SAKMP sẽ có các giá trị tương tự trong trường của tiêu đề, ngoại trừ trường Responder Cookie của Thiết bị-B sẽ chọn cookie của riêng mình (ngẫu nhiên) .
Từ thời điểm này kết hợp an ninh ISAKMP mới sẽ được xác định bởi các cặp cookie được lựa chọn bởi cả hai bên.
Gói tin thứ 3 và 4 có một cấu trúc thể hiện trong hình .
Hình 4-46:Gói tin thứ 3-4 của chế độ chính – pha 1
Gói tin thứ 3:
Gói tin thứ 3 của chế độ chính – pha 1 bắt đầu việc trao đổi các thông tin mà từ đó các khóa mật mã được tạo thành. Tất cả các thông tin được trao đổi không mật mã. Không gói tin nào mang khóa mật mã. Thay vào đó,
các gói tin mang các thông số để Thiết bị -A và Thiết bị -B tính toán khóa chia sẻ bí mật.
Tải trọng ISAKMP của gói tin 3 sẽ được sử dụng để trao đổi hai thông tin:
Giá trị công cộng Diffie-Hellman: gx . Số mũ x trong giá trị công cộng gx là giá trị bí mật. Số g là một số nguyên. p là số nguyên tố lớn để tạo khả năng tạo khóa an toàn, bí mật. Cả hai g và p được chọn ở giai đoạn khởi động hệ thống.
Nonce: Ni từ bên khởi tạo. (Nonce là một giá trị được coi là ngẫu nhiên).
Những giá trị này được cho vào trường Key Exchange và Nonce của gói tin thứ 3. Gói tin thứ 4:
Sau khi nhận được một giá trị công cộng Diffie-Hellman và nonce từ Thiết bị-A, Thiết bị-B sẽ trả lời bằng cách gửi cho Thiết bị-A giá trị công cộng Diffie-Hellman của mình (gy được Thiết bị - B tính toán) và nonce của mình (Nr ). Gói tin thứ 4 có cấu trúc tương tự như gói tin thứ 3. Tại thời điểm này, mỗi Thiết bị biết giá trị của hai nonces (Ni và Nr). Mỗi Thiết bị cũng biết giá trị Diffie-Hellman riêng bí mật của mình (x và y) và cũng biết giá trị công cộng Diffie-Hllman của đối tác (gx hoặc gy). Do đó mỗi bên có thể xây dựng giá trị gxy. Dựa vào gxy và p được chọn trước đó. Từ đây mỗi bên sẽ tính ra được chung 1 khóa chia sẻ bí mật dh_shared_key theo công thức:
dh_shared_key = gxy mod p
Và cuối cùng, mỗi bên biết các giá trị của cookie khởi tạo và cookie phản hồi. Với tất cả các thông tin này, mỗi bên có thể tính toán một cách độc lập giá trị giống nhau cho các khóa sau đây:
SKEYID: là khóa mà từ đó các khóa mật mã sẽ được bắt nguồn cho các tiến trình sau. Nó được tính từ biểu thức sau đây:
SKEYID = HMAC-MD5(Ni, Nr, gxy)
Sau khi tính toán giá trị khóa SKEYID, mỗi bên sau đó tiến hành để tạo ra hai khóa mật mã các trường trong gói tin ISAKMP (SKEYID_a và SKEYID_e) và một khóa bổ sung (SKEYID_d):
SKEYID_d là khóa sẽ được sử dụng trong pha 2 để tính toán khóa dùng để mật mã dữ liệu IPsec :
SKEYID_d = HMAC-MD5 (SKEYID, gxy, CookieA, CookieB, 0) CookieA là của Thiết bị-A (Initiator) Cookie và CookieB là của Thiết bị-B (Responder) Cookie.
SKEYID_e là khóa dùng để mã hóa các trường trong gói tin ISAKMP:
SKEYID_e = HMAC-MD5(SKEYID, SKEYID_a, gxy, CookieA, CookieB, 2)
Gói tin thứ 5:
Tại thời điểm này của pha 1, hai thiết bị sẽ trao đổi thông tin nhận dạng với nhau, bằng cách sử dụng chữ ký để xác thực bản thân bằng phương pháp khóa chia sẻ trước. Như thể hiện trong hình 13, gói tin ISAKMP sẽ mang một nhận dạng và chữ ký được mã hóa bằng khóa SKEYID_e.
Thiết bị-A sử gói tin thứ 5 gửi thông tin đến Thiết bị- B để xác thực Thiết bị- A.
Hình 4-47:Gói tin thứ 5 và 6
Trường Identity: Chứa tên của Thiết bị- A.
Trường Signature: Thiết bị-A (bên khởi tạo) sẽ tạo ra hàm băm bằng cách sử dụng thuật toán chữ ký số (sử dụng thuật toán băm một chiều MD5 với khóa chia sẻ trước), và sau đó đưa vào trong trường Signature:
HASH_I = HMAC-MD5(SKEYID, gx, gy, CookieA, CookieB, ID_A)
Giá trị này được ký với các khóa chia sẻ trước của Thiết bị - A và ghi vào trường Signature.
ID_A là thông tin nhận dạng Thiết bị-A được truyền đi trong trường Identity của gói tin này.
Gói tin thứ 6:
Sau khi nhận được tin nhắn thứ 5 từ Thiết bị-A, Thiết bị-B sẽ xác minh danh tính của Thiết bị-A bằng cách xác thực chữ ký số. Nếu chữ ký là hợp lệ, thì Thiết bị-B sẽ gửi gói tin thứ 6 để Thiết bị-A xác minh danh tính của Thiết bị-B.
Cấu trúc của gói tin thứ 6 là giống như của gói tin thứ 5 Trường Identity chứa tên của Thiết bị-B.
Trường Signature được tính toán tương tự Signature của gói tin thứ 5.
HASH_R = HMAC-MD5(SKEYID, gy, gx, CookieB, CookieA, ID_B)
Khi Thiết bị-A nhận được gói tin thứ 6 và xác minh chữ ký số, pha 1 hoàn tất. Cả hai bên đã thỏa thuận các đặc tính kết hợp an ninh ISAKMP và sẽ dùng để tạo khóa ở pha 2 tiếp theo
b )Pha 2 – Chế độ nhanh
Những trao đổi của pha này nhằm xác định kết hợp an ninh SA và các khóa sẽ được sử dụng bảo vệ các gói tin IP trao đổi giữa hai bên thông qua các đường hầm IPSec. Pha 2 được thực hiện thường xuyên (trong khoảng thời gian quy định tại các đường hầm thường khởi tạo) cho việc làm mới các khóa.
Pha 2 gồm 3 gói tin có cấu trúc như sau:
Gói tin thứ 1:
Tiêu đề ISAKMP: sẽ cho biết loại này là trao đổi pha 2 – chế độ nhanh, sẽ bao gồm Message-ID được một khác không được lựa chọn bởi Thiết bị-A, sẽ bao gồm cookie khởi tạo và cookie phản hồi (initiator cookie và responder cookie) được lựa chọn trong pha 1(Cookie-A và Cookie-B ), và cờ mã hóa sẽ được bật lên để cho biết các trường của gói tin ISAKMP được mã hóa bằng các khóa được thỏa thuận trong pha 1 - chế độ chính.
HASH_1: Hàm băm 1 được cho vào trường mes_hash của gói tin.
HASH_1 = HMAC-MD5(SKEYID_a, M-ID, Ni, Nr)
Ni và Nr là giá trị nonces bên khởi tạo và hồi đáp
Trường Proposal và Transform : có cấu trúc tương tự như trong pha 1. Trường Proposal sẽ xác định các giao thức được sử dụng cho bảo vệ gói tin IPSec (ESP, AH hoặc ESP và AH) và sẽ bao gồm một giá trị SPI được chọn ngẫu nhiên bởi Thiết bị-A. Trường Transform sẽ cho biêt các thuật toán ESP và AH.
Gói tin thứ 2:
Sau khi Thiết bị-B nhận được gói tin từ 1 Thiết bị-A và xác nhận thành công bằng cách so sánh HASH_1với hàm băm của nó tính toán , Thiết bị-B gửi gói tin thứ 2 cho Thiết bị - A. Message- ID của gói tin thứ 2 sẽ tương tự với gói tin thứ 1. Hàm băm HASH_2 sẽ được chứa trong trường mes_hash :
HASH_2 = HMAC-MD5(SKEYID_a, M-ID, Nr, Ni)
Tất cả các thông số cần thiết cho việc xây dựng SA cho IPSec bao gồm trong trường Proposal và Transform được chấp nhận bởi Thiết bị - B và gửi gói tin thứ hai để xác nhận sự thỏa thuận.
Cả hai bên có thể tính toán các khóa để sử dụng mã hóa và xác thực các gói tin IPSec.
Đối với dữ liệu được gửi bởi Thiết bị-A và được nhận bởi Thiết bị-B, khóa được tính toán và dùng để tính khóa IPsec:
KEYMAT(ab) = HMAC-MD5(SKEYID_d, DH_shared_key, protocol, SPI, Ni, Nr, 0 )
Đối với dữ liệu được gửi bởi Thiết bị-B và được nhận bởi Thiết bị-A, khóa được tính toán và dùng để tính khóa IPsec:
KEYMAT(ba) = HMAC-MD5(SKEYID_d, DH_shared_key, protocol, SPI, Nr, Ni, 0)
DH_shared_key là chìa khóa chia sẻ tính toán trong pha 1- chế độ chính protocol và SPI được lấy từ trường Proposal.
Mỗi bên tính toán các khóa để mã hóa và xác thực ( các khóa được 2 bên tạo ra một cách đối xứng) :
Khóa xác thực:
KEY_AH(ab) = HMAC-MD5(KEYMAT(ab), SKEYID_d, DH_shared_key, Cookie_A, Cookie_B, 1)
Khóa mã hóa :
KEY_ESP(ab) = HMAC-MD5(KEYMAT(ab), KEY_A(ab), DH_shared_key, Cookie_A, Cookie_B, 2)
Gói tin thứ 3:
Tại thời điểm này, Thiết bị-A và Thiết bị-B đã trao đổi tất cả các thông tin cần thiết. Gói tin thứ 3 trong trao đổi pha 2 - chế độ nhanh được Thiết bị-A gửi đi kết thúc thảo thuận SA, bắt đầu cho việc truyền gói tin IP qua đường hầm IPsec. Gói tin thứ 3 có Message-ID và nonces đã được trao đổi trong 2 gói tin thứ 1 và 2. Ngoài ra, còn chưa hàm băm HASH_3:
HASH_3 = HMAC-MD5(SKEYID_a, 0, M-ID, Ni, Nr)