Nguyên lý hoạt động của giao thức trao đổi khóa IKE

Một phần của tài liệu Kỹ thuật VPN sử dụng IPSEC (Trang 25)

2.2.1. Pha thứ 1 của IKE.

Pha I của IKE đầu tiên xác thực các gateway, và sau đó thiết lập một kênh bảo mật cho sự trao đổi. Tiếp đó, các bên thông tin thỏa thuận một ISAKMP SA đồng ý lẫn nhau, bao gồm các thuật toán mã hóa, hàm băm, và các phương pháp xác thực có khóa.

Sau khi cơ chế mã hóa và hàm băm đã được đồng ý ở trên, một khóa sẽ bí mật được phát sinh. Theo sau là những thông tin được dùng để phát sinh khóa bí mật:

• Giá trị Diffie-Hellman.

• SPI của ISAKMP SA ở dạng cookies. • Một số ngẫu nhiên.

• Có thể có thêm các định danh của các bên khi sử dụng xác thực bằng khoá công khai.

Sau khi trao đổi các thông tin cần thiết, cả hai bên phát sinh những khóa riêng của chính mình và sử dụng chúng để chia sẽ bí mật. Theo cách này, những khóa mã hóa được phát sinh mà không cần thực sự trao đổi bất kỳ khóa nào thông qua mạng.

Pha I của IKE có thể được thực hiện bằng một trong 2 chế độ: Main mode và Aggressive mode. Mỗi phương pháp tạo ra một mầm khóa được xác thực từ trao đổi Diffie – Hellman.

• Main mode cho phép bảo vệ định danh và là bắt buộc, được hỗ trợ trong FreeS/WAN.

• Aggressive mode nhanh hơn nhưng độ bảo mật kém hơn, hiện tại không được hỗ trợ trong FreeS/WAN.

• Thuật toán mã hóa để mã hóa các thông tin của pha II: ví dụ OAKLEY_IDEA_CBC.

• Thuật toán hàm băm: OAKLEY_SHA. • Phương pháp xác thực: OAKLEY_RSA_SIG. • Mô tả nhóm: OAKLEY_GROUP_MODP1024

Trong quá trình thỏa thuận liên kết an toàn, các bên khởi tạo gửi các bên đáp ứng các đề nghị cho các liên kết an toàn khác nhau. Các bên đáp ứng phải không được sửa đổi các thuộc tính của bất kỳ một đề nghị nào. Nếu bên khởi tạo của một trao đổi thông báo rằng các giá trị thuộc tính đã thay đổi hoặc thêm vào hay xóa đi khỏi đề nghị đã đưa ra, thì đáp ứng đó phải được loại bỏ.

Trong pha I của IKE có thể sử dụng bốn phương pháp xác thực sau: • Xác thực bằng chữ ký số.

• Hai dạng xác thực bằng mã hóa khóa công phai. • Xác thực bằng khóa chia sẻ trước.

Giá trị SKEYID được tính riêng rẽ cho từng phương pháp xác thực: Đối với chữ ký số: SKEYID=prf(Ni_b|Nr_b,g^xy).

Đối với mã hóa khóa công khai: SKEYID=prf(hash(Ni_b|Nr_b),CKY-I|CKY-R). Đối với khóa chia sẻ trước: SKEYID=prf(pre-shared-key,Ni_b|Nr_b).

Ở đây hàm pfr chính là hàm sinh giá trị giả ngẫu nhiên (pseudo-random function). Đối với từng phương pháp xác thực SKEYID sẽ là giá trị của hàm prf tùy thuộc vào các tham số đưa vào.

Kết quả ta có 3 nhóm mầm khóa được xác thực:

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

Các giá trị 0,1, 2 ở trên là các octet đơn. Khóa được sử dụng để mã hóa được sinh ra từ SKEYID_e.

Để xác thực quá trình trao đổi, bên khởi tạo của giao thức tạo ra HASH_I và bên đáp ứng tạo ra HASH_R, trong đó:

HASH_R=prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b)

Đối với xác thực bằng chữ ký số, thì HASH_I và HASH_R được ký và được biến đổi còn đối với phương pháp xác thực bằng mã hóa khóa công khai hay bằng khóa chia sẻ trước thì HASH_I và HASH_R trực tiếp xác thực quá trình trao đổi.

Sau đây là các quá trình trao đổi trong pha I với các phương pháp xác thực khác nhau.

2.2.1.1. IKE trong Pha I được xác thực bằng chữ ký số.

Khi sử dụng chữ ký số, thông tin bắt buộc được trao đổi trong chu trình thứ 2 là các nonce; trao đổi được xác thực bằng cách ký 2 hàm HASH.

Bên khởi tạo Bên đáp ứng

HDR,SA   HDR,SA HDR, KE, Ni   HDR, KE, Nr HDR*,IDii,[CERT],SIG_I   HDR*,IDir,[CERT],SIG_R

Ở lần trao đổi đầu tiên, bên khởi tạo gửi đến bên đáp ứng một thông báo gồm một ISAKMP header (HDR) và một SA payload. Trong ISAKMP header chứa cookie của bên khởi tạo và khai báo kiểu trao đổi và các thông tin có liên quan khác. Theo sau header này là một SA payload (là payload thỏa thuận liên kết an toàn) chứa các tình huống, và một số các đề nghị (proposal). Trong mỗi đề nghị lại chứa một số các mẫu trao đổi (transform) mà một số các mẫu này được khai báo trong đề nghị đó. Sau đó bên khởi tạo lần lượt gửi đi các mẫu trao đổi bao gồm các thông tin như transform ID, số thứ tự của mẫu và các thuộc tính như kiểu tồn tại là gì (theo seconds hay theo kilobyte), khoảng thời gian tồn tại liên kết an toàn là bao lâu, thuật toán mã hoá là gì (DES, hay 3 DES, hay IDEA...), hàm thuật toán HASH là gì (SHA hay MD5), phương pháp xác thực là gì (bằng chữ ký số, hay bằng mã hóa khóa công khai, hay bằng khóa chia sẻ trước) và đưa ra các nhóm để thực hiện trao đổi Diffie – Hellman. (adsbygoogle = window.adsbygoogle || []).push({});

Khi nhận được thông báo trên, thì bên đáp ứng đáp lại bằng một thông báo cũng bao gồm một ISAKMP header (HDR) và một SA payload. Trong đó, ISAKMP header bao gồm cookie của bên khởi tạo, một cookie của bên đáp ứng và các thông tin có liên quan như trên. Sau khi đã lựa chọn và chấp nhận một mẫu trao đổi trong đó có thuật toán mã hóa, hàm HASH, phương pháp

xác thực và nhóm để thực hiện Diffie – Hellman, thì bên đáp ứng gửi lại một SA payload chứa DOI, tình huống và một mẫu trao đổi (đã được chấp nhận).

Sau khi đã thỏa thuận được các thuộc tính cần thiết, để trao đổi các giá trị công khai Diffie – Hellman và các thông tin liên quan cần thiết cho quá trình trao đổi, thì bên khởi tạo lại tiếp tục gửi một thông báo bao gồm ISAKMP header, một KE payload (KE) và một nonce payload (Ni). Bây giờ thì trong ISAKMP header có cả cookie của bên đáp ứng. Bên khởi tạo chọn ra một bí mật Diffie – Hellman và tính ra một giá trị công khai Diffie – Hellman để gửi tới bên đáp ứng trong KE payload. Khi nhận được giá trị công khai Diffie – Hellman mà bên khởi tạo gửi tới thì bên đáp ứng tính được giá trị bí mật Diffie – Hellman, và tính ra các giá trị SKEYID, SKEYID_a, SKEYID_e, SKEYID_d. Từ SKEYID_e, bên đáp ứng tính ra được khóa mã sử dụng để mã các thông báo và gửi trả lại bên khởi tạo trong KE payload. Sau khi đã trao đổi được khóa mã, thì bên khởi tạo lại gửi đến bên đáp ứng một thông báo gồm một ISAKMP header và định danh của bên khởi tạo được gửi đi trong IDii payload, payload này được mã bằng khóa đã được trao đổi trong thông báo thứ 2, sau đó là một hàm hash của bên khởi tạo dùng để xác thực bên khởi tạo. Khi nhận được thông báo trên, thì bên đáp ứng giải mã thông báo và gửi lại bên khởi tạo một thông báo cũng bao gồm một ISAKMP header, một định danh của bên đáp ứng (IDir), định danh này được mã bằng khóa trao đổi trên. Và để xác thực bên đáp ứng thì bên đáp ứng cũng gửi tới bên khởi tạo một hàm hash. Trong trường hợp xác thực bằng chữ ký số thì các hàm hash của bên khởi tạo và bên đáp ứng (HASH_I và HASH_R) được ký bằng chữ ký RSA, còn trong trường hợp xác thực bằng mã hóa khóa công khai thì HASH_I và HASH_R trực tiếp xác thực thông báo.

Sau khi đã thỏa thuận được các tham số kết nối, và xác thực được nhau thì 2 bên thiết lập được một liên kết an toàn.

2.2.1.2. IKE trong pha I được xác thực bằng mã hóa khóa công khai.

Khi sử dụng mã hóa khóa công khai để xác thực trao đổi thì các thông tin bắt buộc được trao đổi là các nonce mã. Khả năng của mỗi bên để xây dựng lại hàm hash (chứng minh rằng bên kia giải mã được nonce đó) xác thực quá trình trao đổi.

Để thực hiện mã hóa khóa công khai, bên khởi tạo phải có trước khóa công khai của bên đáp ứng. Trong trường hợp mà bên đáp ứng có nhiều khóa công khai, thì hàm hash của certificate mà bên khởi tạo sử dụng để mã thông tin bắt buộc được chuyển đi như là một phần của thông báo thứ 3. Theo cách này, bên đáp ứng có thể quyết định khóa riêng tương ứng để giải mã các payload mã và sự bảo vệ định danh vẫn được duy trì. Hơn nữa, định danh (ID) của các bên (IDii và IDir) và các nonce payload cũng được mã bằng khóa công khai của bên kia.

Bên khởi tạo Bên đáp ứng HDR, SA   HDR, SA HDR, KE, [HASH(1)], <IDii_b>pubkey_r, <Ni_b>pubkey_r   HDR, KE, <IDir_b>pubkey_i, <Nr_b>pubkey_i HDR*, HASH_I   HDR*, HASH_R

Bước đầu tiên bên khởi tạo gửi bên đáp ứng một thông báo gồm một ISAKMP header (HDR) và một SA payload. Trong SA payload chứa các DOI, tình huống và một số các đề nghị. Khi nhận được thông báo trên, thì bên đáp ứng cũng gửi lại bên khởi tạo một thông báo gồm một ISAKMP header và một SA payload. Lúc này cả hai bên đã thống nhất được với nhau thuật toán mã hóa, hàm HASH, nhóm để thực hiện Diffie – Hellman.

Tiếp đó bên khởi tạo gửi đến bên đáp ứng một thông báo gồm một ISAKMP header; một KE payload (chứa thông tin công khai Diffie – Hellman của bên khởi tạo); hàm HASH(1) là hàm hash (đã được thỏa thuận) của certificate mà bên khởi tạo dùng để mã nonce và ID; định danh của bên khởi tạo và giá trị nonce được mã hóa bằng khóa công khai của bên đáp ứng. Khi nhận được thông báo, bên đáp ứng tính giá trị bí mật Diffie – Hellman, các giá trị SKEYID, SKEYID_a, SKEYID_e, SKEYID_d, và khóa mã sử dụng để mã các thông báo. Bên đáp ứng gửi lại bên khởi tạo một thông báo gồm ISAKMP header, KE payload (chứa thông tin công khai Diffie - Hellman

của bên đáp ứng và khóa mã đã tính được ở trên), cùng với định danh của bên đáp ứng, giá trị nonce của bên đáp ứng được mã bằng khóa công khai của bên khởi tạo.

Sau khi đã trao đổi được khóa mã, bên đáp ứng gửi đến bên khởi tạo một thông báo gồm một ISAKMP header và một hàm HASH_I. Thông báo này được mã hóa bằng khóa mã đã được trao đổi ở trên. Khi nhận được bên đáp ứng sẽ giải mã thông báo và nhận được HASH_I. Bên đáp ứng dựa vào các thông tin nhận được từ bên khởi tạo trước đó sẽ tính được hàm hash và đem so sánh với HASH_I vừa nhận được để xác thực bên khởi tạo. Tiếp đó bên đáp ứng cũng gửi đến bên khởi tạo một thông báo gồm một ISAKMP header và hàm HASH_R. Quá trình xác thực cũng diễn ra tương tự như ở bên đáp ứng.

2.2.1.3. IKE trong pha I được xác thực bằng một dạng khác của mã hóa khóa công khai.

Xác thực bằng mã hóa khóa công khai có ưu điểm hơn so với xác thực bằng chữ ký số. Nhưng nó lại phải tốn 4 quá trình khóa công khai (2 quá trình mã khóa công khai và 2 quá trình giải mã khóa riêng). Phương pháp xác thực này vẫn giữ được các ưu điểm của mã hóa khóa công khai nhưng chỉ tốn 2 quá trình khóa công khai.

Trong phương pháp này, nonce vẫn được mã bằng khóa công khai của bên kia, tuy nhiên ID của các bên (và cả certificate nếu nó được gửi đi) được mã bằng thuật toán mã đối xứng (từ SA payload) bằng khóa được sinh ra từ nonce này. Giải pháp này giảm thiểu độ phức tạp và tiết kiệm được 2 quá trình khóa công khai. Hơn nữa, KE payload cũng được mã bởi cùng một khóa, điều này cung cấp khả năng bảo vệ chống lại những mã thám của trao đổi Diffie – Hellman.

Giống như phương pháp xác thực bằng mã hóa khóa công khai, HASH payload có thể được gửi đi để nhận dạng certificate nếu bên đáp ứng có rất nhiều certificate chứa các khóa có thể sử dụng được. Nếu HASH payload được gửi đi thì nó phải là payload thứ 3 của trao đổi thông báo thứ 2 và phải kèm theo nonce mã. Nếu HASH payload không được gửi đi, thì payload đầu tiên của trao đổi thông báo thứ 2 phải mã nonce mã. Hơn nữa, bên khởi tạo có thể tùy ý gửi đi một certificate để cung cấp cho bên đáp ứng một khóa công khai dùng để đáp lại.

Bên khởi tạo Bên đáp ứng

HDR, SA   HDR, SA HDR, [HASH(1),] <Ni_b>pubkey_r, <KE_b>Ke_i, <IDii_b>Ke_i [,<Cert-I_b>Ke_i] 

 HDR, <Nr_b>pubkey_i, <KE_b>Ke_r, <IDir_b>Ke_r HDR*, HASH_I   HDR*, HASH_R

Trong đó, HASH(1) là hàm hash (đã được thỏa thuận) của certificate mà bên khởi tạo dùng để mã nonce và ID. Ke_i và Ke_r là các khóa đối xứng của thuật toán mã đối xứng được thỏa thuận trong trao đổi SA payload. Chỉ có thân của các payload là được mã (trong cả mã không khai lẫn mã đối xứng), header chung của các payload là để rõ. Độ dài của payload bao gồm cả phần được thêm vào để thực hiện mã.

Các khóa đối xứng được sinh ra từ các nonce (được giải mã) như sau: Đầu tiên các giá trị Ne_i và Ne_r được tính:

Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Nr_b, CKY-R)

Sau đó, Ke_i và Ke_r được lấy ra từ Ne_i và Ne_r, nếu độ dài của hàm prf được thỏa thuận lơn hơn hoặc bằng độ dài khóa yêu cầu đối với bản mã, thì Ke_i và Ke_r được sinh ra từ các bit quan trọng nhất của Ne_i và Ne_r. Nếu đầu ra này có độ dài nhỏ hơn độ dài khóa mong muốn, thì ta sẽ lấy ra số bit cần thiết bằng cách đưa liên tiếp các kết quả của hàm prf trở lại chính nó và kết hợp kết quả cho đến khi nhận được số bit cần thiết. Ví dụ nếu thuật toán mã hóa (đã được thỏa thuận) yêu cầu 320 bit khóa mà đầu ra của hàm prf chỉ là 128 bit, thì Ke_i là 320 bit quan trọng nhất của K. Trong đó:

K=K1|K2|K3

Và K1=prf(Ne_i, 0). K2=prf(Ne_i, K1). K3=prf(Ne_i, K2).

Ke_r cũng được sinh ra tương tự như trên. Độ dài của giá trị 0 trong biểu thức tính K1 là một octet đơn. Chú ý rằng Ne_i, Ne_r, Ke_i và Ke_r là tức thời và phải bị loại bỏ sau khi sử dụng.

Ngoài yêu cầu về bố trí HASH payload tùy chọn và nonce payload bắt buộc thì không còn bất cứ một yêu cầu nào khác. Tất cả các payload (trong bất kỳ vị trí nào) theo sau các nonce mã đều phải được mã bằng khóa Ke_i hoặc Ke_r (tùy thuộc vào hướng liên lạc).

Nếu chế độ CBC được sử dụng cho mã đối xứng thì các vectơ khởi tạo IV (Initialization Vector) được thiết lập như sau. IV để mã payload thứ nhất sau nonce được đặt là 0. IV cho các payload tiếp theo được mã bằng khóa mã đối xứng (Ke_i) là khối mã cuối cùng của payload trước đó. Các payload mã được chèn thêm cho bằng cỡ của block gần nhất.

2.2.1.4. IKE trong pha I được xác thực bằng khóa chia sẻ trước.

Một khóa được sinh ra bằng một cơ chế ngoài cũng được sử dụng để xác thực trao đổi. (adsbygoogle = window.adsbygoogle || []).push({});

Bên khởi tạo Bên đáp ứng

HDR, SA   HDR, SA HDR, KE, Ni   HDR, KE, Nr HDR*, IDii, HASH_I  HDR*, IDir, HASH_R

Ban đầu bên khởi tạo gửi bên đáp ứng một thông báo gồm một ISAKMP header và một SA payload. Trong ISAKMP header chứa cookie của bên khởi tạo, kiểu trao đổi và các thông tin có liên quan khác. Trong SA payload chứa các DOI, tình huống, một số các đề nghị. Trong mỗi đề nghị lại chứa một mẫu dùng để thỏa thuận về thuật toán mã hóa, hàm HASH, thời gian tồn tại liên kết an toàn, nhóm để thực hiện trao đổi Diffie – Hellman. Khi nhận được thông báo của bên khởi tạo, bên đáp ứng gửi lại bên khởi tạo một thông báo cũng gồm một ISAKMP header và một SA payload. Trong ISAKMP header chứa cả cookie của bên khởi tạo và bên đáp ứng. Trong SA payload chứa DOI, tình huống và một mẫu đã được chấp nhận.

Sau khi đã thỏa thuận được các thuộc tính cần thiết, bên khởi tạo gửi cho bên đáp ứng một thông báo gồm một ISAKMP header, một KE payload chứa thông tin công khai của trao đổi Diffie – Hellman và một giá trị nonce của bên khởi tạo. Tiếp đó bên đáp ứng cũng gửi lại bên khởi tạo một thông báo gồm một ISAKMP header, một KE payload chứa thông tin công khai của trao đổi Diffie – Hellman của bên đáp ứng, một giá trị nonce của bên đáp ứng.

Khi nhận được thông báo bên khởi tạo tiếp tục gửi bên đáp ứng một thông báo gồm một ISAKMP header, định danh của bên khởi tạo và HASH_I; thông báo này được mã hóa bằng khóa chia sẻ trước. Khi nhận được thông báo bên đáp ứng sẽ giải mã thông báo để nhận được định

Một phần của tài liệu Kỹ thuật VPN sử dụng IPSEC (Trang 25)