Tiểu luận ứng dụng truyền thông và an toàn thông tin TRIỂN KHAI IPSEC & VPN

IPSec được định nghĩa là một giao thức trong tầng mạng cung cấp các dịch vụ bảo mật, xác thực, toàn vẹn dữ liệu và điều khiển truy cập.. • Cả AH và ESP là các phương tiện cho điều khiển

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA MẠNG MÁY TÍNH VÀ TRUYỀN THÔNG

ỨNG DỤNG TRUYỀN THÔNG

VÀ AN NINH THÔNG TIN

ĐỀ TÀI TRIỂN KHAI IPSEC VÀ VPN

NGUYỄN HỒNG NGUYÊN KHOA 08520176

TP Hồ Chí Minh, tháng 03, năm 2012

MỤC LỤC

CHƯƠNG 1: GIAO THỨC IPSEC

1.1 Giới thiệu

Như ta đã biết, mạng Internet nguyên thủy được phát triển để truyền thông giữa các máy tính tin cây, vì vậy nó không hỗ trợ các dịch vụ an ninh Cùng với sự phát triển rộng khắp của Internet trên tòan cầu thì vấn đề an ninh là một trong những vấn

đề quan trọng Giao thức IPSec được phát triển để giải quyết vấn đề an ninh này và trong IP-VPN là một trong những ứng dụng của nó

Hình 1.: Sơ đồ tổngquan VPN

Hình 1.:Sơ đồ VPN 2

1.2 Khái niệm về IPSec

IPSec (Internet Protocol Security) là một giao thức được IETF phát triển IPSec được định nghĩa là một giao thức trong tầng mạng cung cấp các dịch vụ bảo mật, xác thực, toàn vẹn dữ liệu và điều khiển truy cập Mục đích chính của việc phát triển IPSec là cung cấp một cơ cấu bảo mật ở tầng 3 (Network layer) của mô hình OSI.1

Hình 1.:Mô hình OSI

IPSec có hai cơ chế cơ bản để đảm bảo an toàn dữ liệu đó là AH (Authentication Header) và ESP (Encapsulating Security Payload), trong đó IPSec phải hỗ trợ ESP và có thể hỗ trợ AH:

• AH cho phép xác thực nguồn gốc dữ liệu, kiểm tra tính toàn vẹn dữ liệu

và dịch vụ tùy chọn chống phát lại của các gói IP truyền giữa hai hệ thống AH không cung cấp tính bảo mật, điều này có nghĩa là nó gửi đi thông tin dưới dạng bản rõ

• ESP là một giao thức cung cấp tính an toàn của các gói tin được truyền

bao gồm: Mật mã dữ liệu, xác thực nguồn gốc dữ liệu, kiểm tra tính toàn vẹn phi kết nối của dữ liệu ESP đảm bảo tính bí mật của thông tin thông qua việc mật mã gói tin

IP Tất cả lưu lương ESP đều được mật mã giữa hai hệ thống Với đặc điểm này thì xu hướng sẽ sử dụng ESP nhiều hơn AH để tăng tính an toàn cho dữ liệu

• Cả AH và ESP là các phương tiện cho điều khiển truy nhập, dựa vào sự phân phối của các khóa mật mã và quản lý các luồng giao thông có liên quan đến những giao thức an toàn này.

Những giao thức này có thể được áp dụng một mình hay kết hợp với nhau để cung cấp tập các giao thức an toàn mong muốn trong IPv4 và IPv6, nhưng cách chúng cung cấp các dịch vụ là khác nhau Đối với cả hai giao thức AH và ESP này, IPSec không định các thuật toán an toàn cụ thể được sử dụng, mà thay vào đó là một khung chuẩn để sử dụng các thuật toán theo tiêu chuẩn công nghiệp IPSec sử dụng các thuật toán:

- Mã xác thực bản tin trên cơ sở băm (HMAC), thuật toán MD5 (Message Digest 5), thuật toán SHA-1 để thực hiện chức năng toàn vẹn bản tin

- Thuật toán DES, 3DES để mật mã dữ liệu

- Thuật toán khóa chia sẻ trước, RSA chữ ký số và RSA mật mã giá trị ngẫu nhiên (Nonces) để xác thực các bên

- Ngoài ra các chuẩn còn định nghĩa việc sử dụng các thuật toán khác như IDEA, Blowfish và RC4

IPSec sử dụng giao thức IKE (Internet Key Exchange) Giúp cho các thiết bị

tham gia VPN trao đổi với nhau về thông tin an ninh như mã hóa thế nào ? Mã hóa bằng thuật toán gì ? Bao lâu mã hóa 1 lần IKE có tác dụng tự động thỏa thuận các chính sách an ninh giữa các thiết bị tham gia VPN Do đó IKE giúp cho Ipsec có thể

Hình 1.: Sơ đồ gói tin IP trong Transport mode

Kiểu Transport có ưu điểm là chỉ thêm vào gói IP ban đầu một số it byte Nhược điểm là kiểu này cho phép các thiết bị trong mạng nhìn thấy địa chỉ nguồn và đích của gói tin và có thể thực hiện một số xử lý (ví dụ như phân tích lưu lượng) dựa trên các thông tin của IP header Tuy nhiên nếu được mật mã bởi ESP thì sẽ không biết được dữ liệu cụ thể bên trong gói IP là gì Theo như IETF thì kiểu Transport chỉ có thể được sử dụng khi hai hệ thống đầu cuối IP-VPN có thực hiện IPSec

1.3.1.2 Kiểu Tunnel

Kiểu này bảo vệ toàn bộ gói IP Gói IP ban đầu (bao gồm cả IP header) được xác thực hoặc mật mã Sau đó, gói IP đã mã hóa được đóng gói vào một IP header mới Địa chỉ IP bên ngoài được sử dụng cho định tuyến gói IP truyền qua Internet

Hình 1.: Sơ đồi gói tin IP trong Tunnel Mode

Trong kiểu Tunnel, toàn bộ gói IP ban đầu được đóng gói và trở thành Payload của gói IP mới Kiểu này cho phép các thiết bị mạng như router thực hiện xử lý IPSec thay cho các trạm cuối (host) Hình 1.4 là ví dụ: Router A xử lý các gói từ host A, gửi chúng vào đường ngầm Router B xử lý các gói nhận được trong đường ngầm, đưa về dạng ban đầu và chuyển hóa chúng tới host B Như vậy, các trạm cuối không cần thay đổi nhưng vẫn có được tính an toàn dữ liệu của IPSec Ngoài ra, nếu sử dụng kiểu Tunnel, các thiết bị trung gian trong mạng sẽ chỉ có thể nhìn thấy được các địa chỉ hai điểm cuối của đường hầm (ở đây là các router A và B) Khi sử dụng kiểu Tunnel, các đầu cuối của IP-VPN không cần phải thay đổi ứng dụng hay hệ điều hành

Hình 1.: Thiết bị mạng thực hiện IPSec kiểu Tunnel

1.3.2 Giao thức xác thực AH

1.1.1.1 Giới thiệu

Giao thức xác thực AH (Authentication Header) được định nghĩa trong RFC

1826 và sau đó là phát triển lại trong RFC 2402 AH cung cấp:

o Xác thực nguồn gốc dữ liệu (data origin authentication)

o Kiểm tra tính toàn vẹn dữ liệu (data integrity)

o Dịch vụ chống phát lại (anti-replay service)

Đến đây, cần phải phân biệt được hai khái niệm toàn vẹn dữ liệu và chống phát lại: toàn vẹn dữ liệu là kiểm tra những thay đổi của từng gói tin IP, không quan tâm đến vị trí các gói trong luồng lưu lượng; còn dịch vụ chống phát lại là kiểm tra sự phát lặp lại một gói tin tới địa chỉ đích nhiều hơn một lần

AH cho phép xác thực các trường của IP header cũng như dữ liệu của các giao thức lớp trên, tuy nhiên do một số trường của IP header thay đổi trong khi truyền và phía phát có thể không dự đoán trước được giá trị của chúng khi tới phía thu, do đó giá trị của các trường này không bảo vệ được bằng AH

Có thể nói AH chỉ bảo vệ một phần của IP header mà thôi AH không cung cấp bất cứ

xử lý nào về bảo mật dữ liệu của các lớp trên, tất cả đều được truyền dưới dạng văn bản rõ AH nhanh hơn ESP, nên có thể chọn AH trong trường hợp chắc chắn về nguồn gốc và tính toàn vẹn của dữ liệu nhưng tính bảo mật dữ liệu không cần được chắc chắn

Giao thức AH cung cấp chức năng xác thực bằng cách thực hiện một hàm băm một chiều (one-way hash function) đối với dữ liệu của gói để tạo ra một đoạn mã xác

thực (hash hay message digest) Đoạn mã đó được chèn vào thông tin của gói truyền

đi Khi đó, bất cứ thay đổi nào đối với nội dung của gói trong quá trình truyền đi đều được phía thu phát hiện khi nó thực hiện cùng với một hàm băm một chiều đối với gói

dữ liệu thu được và đối chiếu nó với giá trị hash đã truyền đi Hàm băm được thực hiện trên toàn bộ gói dữ liệu, trừ một số trường trong IP header có giá trị bị thay đổi trong quá trình truyền mà phía thu không thể dự đoán trước được (ví dụ trường thời gian sống của gói tin bị các router thay đổi trên đường truyền dẫn)

1.3.2.1 Cấu trúc gói tin AH

Các thiết bị sử dụng AH sẽ chèn một tiêu đề vào giữa lưu lượng cần quan tâm của IP datagram, ở giữa phần IP header và header lớp 4 Bởi vì AH được liên kết với IPSec, IP-VPN có thể định dạng để chọn lưu lượng nào cần được an toàn và lưu lượng nào không cần phải sử dụng giải pháp an toàn giữa các bên Ví dụ như bạn có thể chọn

để xử lý lưu lượng email nhưng không đối với các dịch vụ web Quá trình xử lý chèn

AH header được diễn tả như trong hình 1.5

Hình 1.: Cấu trúc gói tiêu đề AH trong IPSec

Giải thích ý nghĩa các trường trong AH header:

• Next Header (tiêu đề tiếp theo) có độ dài 8 bit để nhận dạng loại dữ liệu

của phần tải tin theo sau AH Giá trị này được chọn lựa từ tập các số giao thức IP đã được định nghĩa trong các RFC gần đây nhất

• Payload length (độ dài tải tin): có độ dài 8 bit và chứa độ dài của tiêu

đề AH được diễn tả trong các từ 32 bit, trừ 2 Ví dụ trong trường hợp của thuật toán toàn vẹn mà mang lại một giá trị xác minh 96 bit (3x32 bit), cộng với 3 từ 32 bit đã

cố định, trường độ dài này có giá trị là 4 Với IPv6, tổng độ dài của tiêu đề phải là bội của các khối 8

• Reserved (dự trữ):Trường 16 bit này dự trữ cho ứng dụng trong tương

lai

• Security Parameters Index (SPI: chỉ dẫn thông số an ninh):Trường này

có độ dài 32 bit, mang tính chất bắt buộc

• Sequence Number (số thứ tự): Đây là trường 32 bit không đánh dấu chứa

một giá trị mà khi mỗi gói được gửi đi thì tăng một lần Trường này có tính bắt buộc Bên gửi luôn luôn bao gồm trường này ngay cả khi bên nhận không sử dụng dịch vụ chống phát lại Bộ đếm bên gửi và nhận được khởi tạo ban đầu là 0, gói đầu tiên có số thứ tự là 1 Nếu dịch vụ chống phát lại được sử dụng, chỉ số này không thể lặp lại, sẽ

có một yêu cầu kết thúc phiên truyền thông và SA sẽ được thiết lập mới trở lại trước khi truyền 232 gói mới

• Authentication Data (dữ liệu xác thực): Còn được gọi là ICV (Integrity

Check Value: giá trị kiểm tra tính toàn vẹn) có độ dài thay đổi, bằng số nguyên lần của

32 bit đối với IPv4 và 64 bit đối với IPv6, và có thể chứa đệm để lấp đầy cho đủ là bội

số các bit như trên ICV được tính toán sử dụng thuật toán xác thực, bao gồm mã xác thực bản tin (Message Authentication Code MACs) MACs đơn giản có thể là thuật toán mã hóa MD5 hoặc SHA-1 Các khóa dùng cho mã hóa AH là các khóa xác thực

bí mật được chia sẻ giữa các phần truyền thông có thể là một số ngẫu nhiên, không phải là một chuỗi có thể đoán trước của bất cứ loại nào Tính toán ICV được thực hiện

sử dụng gói tin mới đưa vào Bất kì trường có thể biến đổi của IP header nào đều được cài đặt bằng 0, dữ liệu lớp trên được giả sử là không thể biến đổi Mỗi bên tại đầu cuối IP-VPN tính toán ICV này độc lập Nếu ICV tính toán được ở phía thu và ICV được phía phát truyền đến khi so sánh với nhau mà không phù hợp thì gói tin bị loại bỏ, bằng cách như vậy sẽ đảm bảo rằng gói tin không bị giả mão

1.3.2.2 Quá trình xử lý AH

Hình 1.: Các bước hoạt động của AH

Hoạt động của AH được thực hiện qua các bước như sau:

Bước 1: Toàn bộ gói IP (bao gồm IP header và data) được thực hiện qua một

hàm băm một chiều

Bước 2: Mã hash thu được dùng để xây dựng một AH header, đưa header này

vào gói dữ liệu ban đầu

Bước 3: Gói dữ liệu sau khi thêm AH header được truyền tới đối tác IPSec.

Bước 4: Bên thu thực hiện hàm băm với IP header và tải tin, kết quả thu được

một mã hash

Bước 5: Bên thu tách mã hash trong AH header.

Bước 6: Bên thu so sánh mã hash mà nó tính được mà mã hash tách ra từ AH

header Hai mã hash này phải hoàn toàn giống nhau Nếu khác nhau chỉ một bit trong quá trình truyền thì 2 mã hash sẽ không giống nhau, bên thu lập tức phát hiện tính không toàn vẹn của dữ liệu

a) Vị trí của AH

AH có hai kiểu hoạt động, đó là kiểu Transport và kiểu Tunnel Kiểu Transport

là kiểu đầu tiên được sử dụng cho kết nối đầu cuối giữa các host hoặc các thiết bị hoạt động như host và kiểu Tunnel được sử dụng cho các ứng dụng còn lại

Ở kiểu Transport cho phép bảo vệ các giao thức lớp trên, cùng với một số trường trong IP header Trong kiểu này, AH được chèn vào sau IP header và trước một giao thức lớp trên (chẳng hạn như TCP, UDP, ICMP…) và trước các IPSec header đã được chen vào Đối với IPv4, AH đặt sau IP header và trước giao thức lớp trên (ví dụ ở đây là TCP)

Hình 1.: Khuôn dạng IPv4 trước và sau khi xử lý AH ở kiểu Transport

Trong kiểu Tunnel, inner IP header mang địa chỉ nguồn và đích cuối cùng, còn outer IP header mang địa chỉ để định tuyến qua Internet Trong kiểu này, AH bảo vệ toàn bộ gói tin IP bên trong, bao gồm cả inner IP header (trong khi AH Transport chỉ bảo vệ một số trường của IP header) So với outer IP header thì vị trí của AH giống như trong kiểu Trasport

Hình 1.: Khuôn dạng gói tin đã xử lý AH ở kiểu Tunnel

b) Các thuật toán xác thực

Thuật toán xác thực sử dụng để tính ICV được xác định bởi kết hợp an ninh SA (Security Association) Đối với truyền thông điểm tới điểm, các thuật toán xác thực thích hợp bao gồm các hàm băm một chiều (MD5, SHA-1) Đây chính là những thuật toán bắt buộc mà một ứng dụng AH phải hỗ trợ

c) Xử lý gói đầu ra

Trong kiểu Transport, phía phát chèn AH header vào sau IP header và trước một header của giao thức lớp trên Trong kiểu Tunnel, có thêm sự xuất hiện của outer IP header Quá trình xử lý gói tin đầu ra như sau:

• Tìm kiếm SA: AH được thực hiện trên gói tin đầu ra chỉ khi quá trình IPSec đã xác định được gói tin đó được liên kết với một SA SA đó sẽ yêu cầu

AH xử lý gói tin Việc xác định quá trình xử lý IPSec nào cần thực hiện trên lưu lượng đầu ra có thể xem trong RFC 2401

• Tạo SN: bộ đếm phía phát được khởi tạo 0 khi một SA được thiết lập Phía phát tăng SN cho SA này và chèn giá trị SN đó vào trường Sequence Number Nếu dịch vụ anti-replay (chống phát lại) được lựa chọn, phía phát kiểm tra để đảm bảo bộ đếm không bị lặp lại trước khi chèn một giá trị mới Nếu dịch

vụ anti-replay không được lựa chọn thì phía phát không cần giám sát đến, tuy nhiên nó vẫn được tăng cho đến khi quay trở lại 0

• Tính toán ICV: bằng cách sử dụng các thuật toán, phía thu sẽ tính toán lại ICV ở phía thu và so sánh nó với giá trị có trong AH để quyết định tới khả năng tồn tại của gói tin đó

• Chèn dữ liệu: có hai dạng chèn dữ liệu trong AH, đó là chèn dữ liệu xác thực (Authentication Data Padding) và chèn gói ngầm định (Implicit Packet Padding) Đối với chèn dữ liệu xác thực, nếu đầu ra của thuật toán xác thực là bội

số của 96 bit thì không được chèn Tuy nhiên nếu ICV có kích thước khác thì việc chèn thêm dữ liệu là cần thiết Nội dung của phần dữ liệu chèn là tùy ý, cũng

có mặt trong phép tính ICV và được truyền đi Chèn gói ngầm định được sử dụng khi thuật toán xác thực yêu cầu tính ICV là số nguyên của một khối b byte nào đó

và nếu độ dài gói IP không thỏa mãn điều kiện đó thì chèn gói ngầm định được

thực hiện ở phía cuối của gói trước khi tính ICV Các byte chèn này có giá trị là 0

và không được truyền đi cùng với gói

• Phân mảnh: khi cần thiết, phân mảnh sẽ được thực hiện sau khi đã xử

lý AH Vì vậy AH trong kiểu transport chỉ được thực hiện trên toàn bộ gói IP, không thực hiện trên từng mảnh Nếu bản thân gói IP đã qua xử lý AH bị phân mảnh trên đường truyền thì ở phía thu phải được ghép lại trước khi xử lý AH Ở kiểu Tunnel, AH có thể thực hiện trên gói IP mà phần tải tin là một gói IP phân mảnh

d) Xử lý gói đầu vào

Quá trình xử lý gói tin đầu vào ngược với quá trình xử lý gói tin đầu ra:

• Ghép mảnh: được thực hiện trước khi xử lý AH (nếu cần)

• Tìm kiếm SA: khi nhận được gói chứa AH header, phía thu sẽ xác định một SA phù hợp dựa trên địa chỉ IP đích, giao thức an ninh (AH) và SPI Quá trình tìm kiếm có thể xem chi tiết trong RFC 2401 Nếu không có SA nào thích hợp được tìm thấy cho phiên truyền dẫn, phía thu sẽ loại bỏ gói

• Kiểm tra SN: AH luôn hỗ trợ dịch vụ chống phát lại, mặc dù dịch vụ này được sử dụng hay không là hoàn toàn dựa vào tùy chọn phía thu Vì vậy quá trình kiểm tra này có thể được thực hiện hoặc không

1.3.3 Giao thức đóng gói an toàn ESP

1.3.3.1 Giới thiệu

ESP được định nghĩa trong RFC 1827 và sau đó được phát triển thành RFC

2408 Cũng như AH, giao thức này được phát triển hoàn toàn cho IPSec Giao thức này cung cấp tính bí mật dữ liệu bằng việc mật mã hóa các gói tin Thêm vào đó, ESP cũng cung cấp xác thực nguồn gốc dữ liệu, kiểm tra tính toàn vẹn dữ liệu, dịch vụ chống phát lại và một số giới hạn về luồng lưu lượng cần bảo mật Tập các dịch vụ cung cấp bởi ESP phụ thuộc vào các lựa chọn tại thời điểm thiết lập SA, dịch vụ bảo mật được cung cấp độc lập với các dịch vụ khác Tuy nhiên nếu không kết hợp sử dụng với các dịch vụ xác thực vào toàn vẹn dữ liệu thì hiệu quả bí mật sẽ không được đảm bảo Hai dịch vụ xác thực và toàn vẹn dữ liệu luôn đi kèm nhau Dịch vụ chống

phát lại chỉ có thể có nếu xác thực được lựa chọn Giao thức này được sử dụng khi yêu cầu về bí mật của lưu lượng IPSec cần truyền.

1.3.3.2 Cấu trúc gói tin ESP

Hoạt động của ESP khác hơn so với AH Như ngụ ý trong tên gọi, ESP đóng gói tất cả hoặc một phần dữ liệu gốc Do khả năng bảo mật dữ liệu nên xu hướng ESP được sử dụng rộng rãi hơn AH Phần header của giao thức nằm ngay trước ESP header

có giá trị 51 trong trường protocol của nó Hình 1.7 diễn tả quá trình xử lý đóng gói:

Hình 1.: Xử lý đóng gói ESP

Hình 1.: Khuôn dạng gói ESP

Sau đây sẽ định nghĩa các trường trong ESP Lưu ý các trường này có thể là tùy chọn hay bắt buộc Việc lựa chọn một trường tùy chọn được định nghĩa trong quá trình thiết lập kết hợp an ninh Như vây, khuôn dạng ESP đối với SA nào đó là cố định trong khoảng thời gian tồn tại của SA đó Còn các trường bắt buộc luôn có mặt trong tất cả các ESP.

 SPI (chỉ dẫn thông số an ninh): Là một số bất kỳ 32 bit, cùng với địa chỉ IP đích và giao thức an ninh ESP cho phép nhận dạng duy nhất SA cho gói dữ liệu này Các giá trị SPI từ 0÷255 được dành riêng để sử dụng trong tương lai SPI thường được chọn lửa bởi phía thu khi thiết lập SA SPI là trường bắt buộc

 Sequence Number (số thứ tự): Tương tự như trường số thứ tự của AH

 Payload Data (trường dữ liệu tải tin): Đây là trường bắt buộc Nó bao gồm một số lượng biến đổi các byte dữ liệu gốc hoặc một phần dữ liệu yêu cầu bảo mật đã được

mô tả trong trường Next Header Trường này được mã hóa cùng với thuật toán mã hóa

đã chọn lựa trong suốt quá trình thiết lập SA Nếu thuật toán yêu cầu cácvectơ khởi tạo thì nó cũng được bao gồm ở đây Thuật toán được dùng để mã hóa ESP thường là thuật toán DES-CBC Đôi khi các thuật toán khác cũng được hỗ trợ như 3DES hay CDMF trong trường hợp nhà cung cấp dịch vụ IBM

 Padding (0÷255 bytes): Có nhiều nguyên nhân dẫn đến sự có mặt của trường này:

• Nếu thuật toán mật mã được sử dụng yêu cầu bản rõ (plaintext) phải là số nguyên lần khối các byte (ví dụ trường hợp mã khối) thì Padding được sử dụng để điền đầy vào plaintext (bao gồm Payload Data, Pad Length, Next Header và Padding) có kích thước theo yêu cầu

• Padding cũng cần thiết để đảm bảo phần dữ liệu mật mã (ciphertext) sẽ kết thúc ở biên giới 4 byte để phân biết rõ ràng với trường Authentication Data

• Ngoài ra, Padding còn có thể sử dụng để che dấu độ dài thực của Payload, tuy nhiên mục đích này cần phải được cân nhắc vì nó ảnh hưởng tới băng tần truyền dẫn

 Pad length (độ dài trường đệm): Trường này xác định số byte Padding được thêm vào Các giá trị phù hợp là 0÷255 bytes, Pad length là trường bắt buộc.

 Next Header (tiêu đề tiếp theo): Trường này dài 8 bit, xác định kiểu dữ liệu chứa trong Payload Data, ví dụ một extension header trong IPv6, hoặc nhận dạng của một giao thức lớp trên khác Giá trị của trường này được lựa chọn từ tập các giá trị IP Protocol Number định nghĩa bởi IANA Next Header là trường bắt buộc

 Authentication Data (dữ liệu xác thực): Trường có độ dài biến đổi chứa một giá trị kiểm tra tính toàn vẹn ICV tính trên dữ liệu của toàn bộ gói ESP trừ trường Authentication Data Độ dài của trường này phụ thuộc vào thuật toán xác thực được sử dụng Trường này là tùy chọn, và chỉ được thêm vào nếu dịch vụ xác thực được lựa chọn cho SA đang xét Thuật toán xác thực phải chỉ ra độ dài ICV và các bước xử lý cũng như các luật so sánh cần thực hiện để kiểm tra tính toàn vẹn của gói tin

1.3.3.3 Quá trình xử lý ESP

Hình 1.: Quá trình xử lý ESP

a) Vị trí của ESP header

ESP có hai kiểu hoạt động, đó là kiểu Transport và kiểu Tunnel

Kiểu Transport cho phép bảo vệ các giao thức lớp trên, nhưng không bảo vệ IP header Trong kiểu này, ESP được chèn vào sau một IP header và trước một giao thức lớp trên (chẳng hạn TCP, UDP hay ICMP…) và trước IPSec header đã được chèn vào Đối với IPv4, ESP header đặt sau IP header và trước giao thức lớp trên (ví dụ ở đây là TCP) ESP trailer bao gồm các trường Paddinh, Pad length, và Next Header Đối với

IPv6, ESP được xem như phần tải đầu cuối-tới - đầu cuối, nên sẽ xuất hiện sau phần header mở rộng hop-to-hop, routing và fragmentation Các lựa chọn đích (dest options extention headers) có thể trước hoặc sau ESP header Tuy nhiên, do ESP chỉ bảo vệ các trường phía sau ESP header, nên các lựa chọn đích thường được đặt sau ESP header Chi tiết về IPv6 có thể xem trong RFC 1883.

Hình 1.: Khuôn dạng IPv4 trước và sau khi xử lý ESP ở kiểu Transport

Trong kiểu Tunnel, inner IP header mang địa chỉ nguồn và đích cuối cùng, còn outer IP header mạng địa chỉ để định tuyến qua Internet Trong kiểu này, ESP sẽ bảo

vệ toàn bộ gói tin IP bên trong, bao gồm cả inner IP header So với outer IP header thì

vị trí của ESP giống như kiểu Trasport

Hình 1.: Khuôn dạng gói tin đã xử lý ESP ở kiểu Tunnel

• NULL Authentication algorithm.

• NULL Encryption algorithm

Các thuật toán khác có thể được hỗ trợ Lưu ý là ít nhất một trong hai dịch vụ bảo mật hoặc xác thực phải được thực hiện, nên hai thuật toán xác thực và mật mã không đồng thời bằng NULL

• Các thuật toán mật mã: Thuật toán mật mã được xác định bởi SA ESP làm việc với các thuật toán mật mã đối xứng Vì các gói IP có thể đến không đúng thứ tự, nên mỗi gói phải mang thông tin cần thiết để phía thu có thể thiết lập Đối xứngmật mã (cryptographic synchronization) để giải mã Dữ liệu này có thể được chỉ định trong trường Payload (chẳng hạn dưới dạng cácvectơ khởi tạo IV- Initialization Vector), hoặc thu được từ header của gói Với sự có mặt của trường Padding, các thuật toán mật mã sử dụng với ESP có thể có các đặc tính khối (block) hoặc luồng (stream) Vì dịch vụ bảo mật là tùy chọn nên thuật toán mật

mã có thể là NULL

• Các thuật toãn xác thực: Thuật toán xác thực sử dụng để tính ICV được xác định bởi SA Đối với truyền thông điểm-tới-điểm, các thuật toán xác thực thích hợp bao gồm các hàm băm một chiều (MD5, SHA-1) Vì dịch vụ xác thực là tùy chọn nên thuật toán xác thực có thể là NULL

c) Xử lý gói đầu ra

Trong kiểu Transport, phía phát đóng gói thông tin giao thức lớp trên vào ESP header/ trailer và giữ nguyên IP header (và tất cả IP extension headers đối với IPv6) Trong kiểu Tunnel, có thêm sự xuất hiện của outer IP header Quá trình xử lý gói tin đầu ra như sau:

• Tìm kiếm SA: ESP được thực hiện trên một gói tin đầu ra chỉ khi quá trình IPSec đã xác định được gói tin đó được liên kết với một SA, SA đó sẽ yêu cầu ESP xử lý gói tin Việc xác định quá trình xử lý IPSec nào cần thực hiện trên lưu lượng đầu ra có thể xen trong RFC 2401

• Mật mã gói tin: Đối với kiểu Transport chỉ đóng gói thông tin giao thức lớp cao Đối với kiểu Tunnel, đóng gói toàn bộ gói IP ban đầu: Thêm trường Padding

nếu cần thiết, mật mã các trường sử dụng khóa, thuật toán và kiểu thuật toán được chỉ ra bởi SA và dữ liệu Đối xứngmật mã nếu có.

• Các bước cụ thể để xây dựng outer IP header phụ thuộc vào kiểu sử dụng (Transport hay Tunnel) Nếu dịch vụ xác thực được lựa chọn thì mật mã được thực hiện trước, và quá trình mật mã không bao gồm trường Authentication Data Thứ tự xử lý này cho phép nhanh chóng xác định và loại bỏ các gói lỗi hoặc lặp lại mà không cần phải thực hiện giải mã, qua đó làm ảnh hưởng của các tấn công kiểu từ chối dịch vụ (denial of service attacks), đồng thời cho phép phía thu xử lý song song: giải mã và xác thực tiến hành song song

• Tạo SN: tương tự như tạo SN của AH

• Tính toán ICV: nếu dịch vụ xác thực được lựa chọn cho SA thì phía phát sẽ tính toán giá trị ICV trên dữ liệu gói ESP trừ trường Authentication Data Lưu ý là các trường mật mã được thực hiện trước xác thực Chi tiết về tính toán ICV cũng tương tự như ở AH

• Phân mảnh: Khi cần thiết, phân mảnh được thực hiện sau khi đã xử lý ESP Vì vậy ESP trong kiểu Transport chỉ được thực hiện trên toàn bộ gói IP, không thực hiện trên từng mảnh Nếu bản thân gói IP đã qua xử lý ESP bị phân mảnh bởi các router trên đường truyền thì các mảnh phải được ghép lại trước khi xử lý ESP ở phía thu Trong kiểu Tunnel, ESP có thể thực hiện trên gói IP mà phần Payload là một gói IP phân mảnh

d) Xử lý gói đầu vào

Quá trình xử lý gói đầu vào ngược với quá trình xử lý gói tin đầu ra:

 Ghép mảnh: Ghép mảnh được thực hiện trước khi xử lý ESP

 Tìm kiếm SA: khi nhận được gói đã ghép mảnh chứa ESP header, phía thu sẽ xác định một SA phù hợp dựa trên địa chỉ IP đích, giao thức an ninh ESP và SPI Quá trình tìm kiếm có thể xem chi tiết trong RFC 2401 Thông tin trong SA sẽ cho biết có cần kiểm tra trường Sequence Number hay không, có cần thêm trường Authentication Data hay không và các thuật toán và khóa cần sử dụng để giải mã tính ICV nếu có Nếu không

có SA nào phù hợp được tìm thấy cho phiên truyền dẫn này (ví dụ phía thu không có khóa), phía thu sẽ loại bỏ gói

 Kiểm tra SN: ESP luôn hỗ trợ dịch vụ chống phát lại (anti-repley), mặc dù việc dịch vụ này hoàn toàn do lựa chọn phí thu trên cơ sở từng SA Dịch vụ này không thực hiện được nếu dịch vụ xác thực không được lựa chọn, vì khi này Sequence Number không được bảo vệ tính toàn vẹn.

Nếu phía thu không lựa chọn dịch vụ chống phát lại cho một SA nào đó thì không cần kiển tra trường Sequence Number Tuy nhiên phía phát mặc định là phía thu

sử dụng dịch vụ này Vì vậy, để phía phát không phải thực hiện giám sát SN cũng như thiết lập lại SA một cách không cần thiết, trong quá trình thiết lập SA phía thu sẽ thông báo cho phía phát việc không sử dụng dịch vụ chống phát lại (trong trường hợp một giao thức thết lập SA như IKE được sử dụng)

Nếu phía thu có lựa chọn dịch vụ chống phát lại cho một SA thì bộ đếm gói thu cho SA đó phải được khởi tạo 0 khi thiết lập SA Với mỗi gói thu được, phía thu phải kiểm tra rằng gói đó có chứa số SN không lặp của bất kỳ một gói nào trong thời gian tồn tại của SA đó Sau khi một gói đã được xác định là tương ứng với một SA nào đó thì phép kiểm tra này là cần được thực hiện đầu tiên để có thể nhanh chóng quyết định khả năng tồn tại của gói đó

Các gói bị loại bỏ thông qua sử dụng một cửa sổ thu trượt Giá trị cửa sổ tối thiểu là 32 và mặc định là 64, phía thu cũng có thể sử dụng các cửa sổ có kích thước lớn hơn Bên phải của cửa sổ đại diện cho SN hợp lệ lớn nhất đã thu được trong SA này Các gói có SN nhỏ hơn bên trái của cửa sổ sẽ bị loại bỏ Các gói có SN nằm trong khoảng giữa hai bên của cửa sổ sẽ được kiểm tra với một danh sách các gói đã thu được trong cửa sổ Nếu gói thu được nằm trong vùng cửa sổ và là mới, hoặc gói đã tới bên phải của cửa sổ thì phía thu sẽ tiến hành xử lý tiếp ICV Nếu việc kiểm tra ICV sai thì phía thu phải loại bỏ gói IP vì không hợp lệ Cửa sổ thu chỉ được cập nhật sau khi việc kiểm tra ICV thành công

 Kiểm tra ICV: nếu dịch vụ xác thực được lựa chọn, phía thu sẽ tính ICV dựa trên dữ liệu của gói ESP ngoại trừ trường Authentication Data, sử dụng thuật toán xác thực xác định trong SA và so sánh với giá trị ICV trong trường Authentication của gói Nếu hai giá trị ICV hoàn toàn trùng khớp thì gói tin là hợp lệ và được chấp nhận Ngược lại, phía thu sẽ loại bỏ gói tin

Việc kiểm tra tiến hành như sau: trước hết giá trị ICV nằm trong trường Authentication Data được tách ra khỏi gói ESP và được lưu trữ Tiếp theo kiểm tra độ dìa của gói ESP (ngoại trừ trườn Authentication Data) Nếu Padding ngầm định được yêu cầu bởi thuật toán xác thực thì các byte 0 được thêm vào cuối gói ESP, ngay sau trường Next Header Tiếp theo thực hiện tính toán ICV và so sánh với giá trị đã lưu sử dụng các luật so sánh được định nghĩa bởi thuật toán.

e) Giải mã gói

Nếu ESP sử dụng mật mã thì sẽ phải thực hiện quá trình giải mã gói Nếu dịch

vụ bảo mật không được sử dụng, tại phía thu không có quá trình giải mã gói này Quá trình giải mã gói diễn ra như sau:

- Giải mã ESP (bao gồm trường Payload Data, Padding, Pad Length, Next Header) sử

dụng khóa Thuật toán mật mã và kiểu thuật toán được xác định bởi SA

- Xử lý phần Padding theo đặc tả của thuật toán Phía thu cần tìm và loại bỏ phần

Padding trước khi chuyển dữ liệu đã giải mã lên lớp trên

- Xây dựng lại cấu trúc gói IP ban đầu từ IP header ban đầu và thông tin giao thức lớp

cao trong tải tin của ESP (ở kiểu Transport), hoặc outer IP header và toàn bộ gói IP ban đầu trong tải tin của ESP (ở kiểu Tunnel)

Nếu dịch vụ xác thực cũng được lựa chọn thì quá trình kiểm tra ICV và mật mã

có thể tiến hành nối tiếp hoặc song song Nếu tiến hành nối tiếp thì kiểm tra ICV phải được thực hiện trước Nếu tiến hành song song thì kiểm tra ICV phải hoàn thành trước khi gói đã giải mã được chuyển tới bước xử lý tiếp theo Trình tự này giúp loại bỏ nhanh chóng các gói không hợp lệ

Có một số lý do như sau dẫn đến quá trình giải mã không thành công:

- SA được lựa chọn không đúng: SA có thể sai do các thông số SPI, địa chỉ đích, trương

Protocol type sai

- Độ dài phần Padding hoặc giá trị của nó bị sai

- Gói ESP mật mã bị lỗi (có thể được lựa chọn nếu dịch vụ xác thực được lựa chọn cho

SA)

1.4 Kết hợp an ninh SA và giao thức trao đổi khóa IKE

1.4.1 Kết hợp an ninh SA

1.4.1.1 Định nghĩa và mục tiêu

IPSec cung cấp nhiều lựa chọn để thực hiện các giải pháp mật mã và xác thực ở lớp mạng Phần này sẽ định nghĩa các thủ tục quản lý SA cho cả IPv4 và IPv6 để thực thi AH hoặc ESP hoặc cả hai, phụ thuộc vào lựa chọn của người sử dụng Khi thiết lập kết nối IPSec, hai phía phải xác định chính xác các thuật toán nào sẽ được sử dụng, loại dịch vụ nào cần đảm bảo an toàn Sau đó bắt đầu xử lý thương lượng để chọn một tập các tham số và các giải thuật toán học áp dụng cho mã hóa bảo mật hay xác thực Theo IETF thì dịch vụ bảo mật quan hệ giữa hai hoặc nhiều thực thể để thỏa thuận truyền thông an toàn được gọi là SA (Security Association)

Một SA là một kết nối đơn công, nghĩa là với mỗi cặp truyền thông với nhau,

có ít nhất 2 SA (một từ A tới B và một từ B tới A) Khi lưu lượng cần truyền trực tiếp 2 chiều qua VPN, giao thức trao đổi khóaIKE (Internet Key Exchange) thiết lập một cặp

SA trực tiếp và sau đó có thể thiết lập thêm nhiều SA khác Mỗi SA có một thời gian sống riêng SA được nhận dạng duy nhất bởi bộ 3 gồm có: chỉ dẫn thông số an ninh (SPI), địa chỉ IP đích và một nhận dạng giao thức an toàn (AH hay ESP) Tập các giá trị SPI trong dãy từ 1 đến 255 được để dành bởi IANA để sử dụng cho tương lai Theo nguyên lý, địa chỉ IP đích có thể là một địa chỉ đơn nhất (unicast), một địa chỉ quảng

bá (broadcast) hay một địa chỉ nhóm (multicast) Tuy nhiên, cơ chế quản lý SA IPSec hiện nay được định nghĩa chỉ cho những SA đơn nhất (unicast)

Một lên kết an ninh có thể là một trong hai kiểu: Transport và Tunnel, phụ thuộc vào kiểu của giao thức sử dụng SA Một SA kiểu Transport là một liên kết an toàn giữa hai host, hoặc liên kết an toàn được yêu cầu giữa hai hệ thống trung gian dọc trên đường truyền Trong trường hợp khác, kiểu Transport cũng có thể được sử dụng

để hỗ trợ IP-in-IP hay đường ngầm GRE qua các SA kiểu Transport SA kiểu Tunnel là một SA cơ bản được ứng dụng tới một đường ngầm IP Một SA giữa 2 cổng an toàn là một SA kiểu Tunnel điển hình giống như một SA giữa một host và một cổng an toàn Tuy nhiên, trong những trường hợp mà lưu lượng đã được định hình từ trước như những lệnh SNMP, cổng an toàn làm nhiệm vụ như host và kiểu Transport được cho phép

SA cung cấp nhiều lựa chọn cho các dịch vụ IPSec, nó phụ thuộc vào giao thức

an toàn được lựa chọn (AH hay ESP), kiểu SA, điểm kết thúc của SA đó và một sự tuyển chọn của các dịch vụ tùy ý các bên trong giao thức đó Ví dụ như khi sử dụng

AH để xác minh nguồn gốc dữ liệu, tính toàn vẹn phi kết nối cho gói IP, có thể sử dụng dịch vụ chống phát lại hoặc không tùy thuộc vào các bên

Khi một bên IP-VPN muốn gửi lưu lượng IPSec tới đầu bên kia, nó kiểm tra để biết nếu có một đã tồn tại một SA trong cơ sở dữ liệu hay chưa để hai bên có thể sử dụng dịch vụ an ninh theo yêu cầu Nếu nó tìm được một SA tồn tại, nó để SPI của SA này trong tiêu đề IPSec, thực hiện các thuật toán mã hóa và gửi gói tin đi Bên thu sẽ lấy SPI, địa chỉ đích và giao thức IPSec (AH hay ESP) và tìm SA trong cơ sở dữ liệu phù hợp để xử lý gói tin đó Lưu ý rằng một đầu cuối IP-VPN có thể đồng thời tồn tại nhiều kết nối IPSec, vì vậy cũng có nghĩa là tồn tại nhiều SA

1.4.1.2 Kết hợp các SA

Các gói IP truyền qua một SA riêng biệt được cung cấp sự bảo vệ một cách chính xác bởi giao thức an ninh có thể là AH hoặc ESP nhưng không phải là cả hai Đôi khi một chính sách an toàn có thể được gọi cho một sự kết hợp của các dịch vụ cho một luồng giao thông đặc biệt mà không thể thực hiện được với một SA đơn lẻ Trong trường hợp đó cần thiết để giao cho nhiều SA thực hiện chính sách an toàn được yêu cầu Thuật ngữ cụm SA được sử dụng để một chuỗi các SA xuyên qua lưu lượng cần được xử lý để thỏa mãn một tập chính sách an toàn

Đối với kiểu Tunnel, có 3 trường hợp cơ bản của kết hợp an ninh như sau:

• Cả hai điểm cuối SA đều trùng nhau: mỗi đường ngầm bên trong hay bên ngoài là AH hay ESP, mặc dù host 1 có thể định rõ cả hai đường ngầm là như nhau, tức là AH bên trong AH và ESP bên trong ESP

Host 1SecurityGwy 1SecurityGwy 2Host 2InternetSecurity Association 1 (Tunnel)Security Association 2 (Tunnel)

Hình 1.13: Kết hợp SA kiểu Tunnel khi 2 điểm cuối trùng nhau

• Một điểm cuối SA trùng nhau: đường hầm bên trong hay bên ngoài có thể là AH hay ESP

Host 1SecurityGwy 1SecurityGwy 2Host 2InternetSecurity Association 1 (Tunnel)Security Association 2 (Tunnel)

Hình 1.14: Kết hợp SA kiểu Tunnel khi một điểm cuối trùng nhau

• Không có điểm cuối nào trùng nhau: Mỗi đường hầm bên trong và bên ngoài là AH hay ESP

Host 1SecurityGwy 1SecurityGwy 2Host 2Internet

SA 1 (Tunnel)

Security Association 2 (Tunnel)

Hình 1.15: Kết hợp SA kiểu Tunnel khi không có điểm cuối trùng nhau

Chi tiết về kết hợp các SA có được trình bày trong RFC 2401

 SAD: chứa thông số về mỗi SA, giống như các tính toán và khóa AH hay ESP, số trình tự, kiểu giao thức và thời gian sống SA Cho xử lý đi ra, một lối vào SPD trỏ tới một lối vào trong SAD SAD quyết định SA nào được sử dụng cho một gói đã cho Cho xử lý đi về, SAD được tham khảo để quyết định gói được xử lý như thế nào

1.4.2 Giao thức trao đổi khóa IKE

1.4.2.1 IKE mode:

4 chế độ IKE phổ biến thường được triển khai:2

• Chế độ chính (Main mode)

• Chế độ linh hoạt (Aggressive mode)

• Chế độ nhanh (Quick mode)

• Chế độ nhóm mới (New Group mode)

1.4.2.1.1 Main Mode

Main mode xác nhận và bảo vệ tính đồng nhất của các bên có liên quan trong qua trình giao dịch Trong chế độ này, 6 thông điệp được trao đổi giữa các điểm:

• 2 thông điệp đầu tiên dùng để thỏa thuận chính sách bảo mật cho sự thay đổi

• 2 thông điệp kế tiếp phục vụ để thay đổi các khóa Diffie-Hellman và nonces Những khóa sau này thực hiện một vai tro quan trọng trong cơ chế mã hóa

• Hai thông điệp cuối cùng của chế độ này dùng để xác nhận các bên giao dịch với sự giúp đỡ của chữ ký, các hàm băm, và tuỳ chọn với chứng nhận

Hình 1.: Main mode

1.4.2.1.2 Aggressive Mode

Aggressive mode về bản chất giống Main mode Chỉ khác nhau thay vì main mode có

6 thông điệp thì chết độ này chỉ có 3 thông điệp được trao đổi Do đó, Aggressive mode nhanh hơn mai mode Các thông điệp đó bao gồm:

Thông điệp đầu tiên dùng để đưa ra chính sách bảo mật, pass data cho khóa chính, và trao đổi nonces cho việc ký và xác minh tiếp theo

Thông điệp kế tiếp hồi đáp lại cho thông tin đầu tiên Nó xác thực người nhận và hoàn thành chính sách bảo mật bằng các khóa

Thông điệp cuối cùng dùng để xác nhận người gửi (hoặc bộ khởi tạo của phiên làm việc).

Hình 1.: Quick mode

1.4.2.1.4 New Group Mode

New Group mode được dùng để thỏa thuận một private group mới nhằm tạo điều kiện trao đổi Diffie-Hellman key được dễ dàng Hình 6-18 mô tả New Group mode Mặc dù chế độ này được thực hiện sau giai đoạn I, nhưng nó không thuộc giai đoạn II

Hình 1.: New group mode

Ngoài 4 chế độ IKE phổ biến trên, còn có thêm Informational mode Chế độ này kết hợp với quá trình thay đổ của giai đoạn II và SAs Chế độ này cung cấp cho các bên có liên quan một số thông tin thêm, xuất phát từ những thất bại trong quá trình thỏa thuận Ví dụ, nếu việc giải mã thất bại tại người nhận hoặc chữ ký không được xác minh thành công, Informational mode được dùng để thông báo cho các bên khác biết

1.4.2.1.5 Các bước thiết lập.

Kết nối IPSec chỉ được hình thành khi SA đã được thiết lập Tuy nhiên bản thân IPSec không có cơ chế để thiết lập SA Chính vì vậy, IETF đã chọn phương án chia quá trình

ra làm hai phần:

1 IPSec cung cấp việc xử lý ở mức gói

2 IKMP (Internet Key Management Protocol) chịu trách nhiệm thỏa thuận các kết hợp an ninh

Sau khi cân nhắc các phương án, trong đó có SKIP (Simple Key Internet Protocol), và Photuis, IETF đã quyết định chọn IKE (Internet Key Exchange) là chuẩn

để cấu hình SA cho IPSec

Một đường ngầm IPSec IP-VPN được thiết lập giữa hai bên qua các bước như sau:

Bước 1: Quan tâm đến lưu lượng được nhận hoặc sinh ra từ các bên IPSec

IP-VPN tại một giao diện nào đó yêu cầu thiết lập phiên thông tin IPSec cho lưu lượng đó

Bước 2: Thương lượng chế độ chính (Main Mode) hoặc chế độ tấn công

(Aggressive Mode) sử dụng IKE cho kết quả là tạo ra liên kết an ninh IKE (IKE SA) giữa các bên IPSec

Bước 3: Thương lượng chế độ nhanh (Quick Mode)sử dụng IKE cho kết quả là

tạo ra 2 IPSec SA giữa hai bên IPSec

Bước 4: Dữ liệu bắt đầu truyền qua đường ngầm mã hóa sử dụng kỹ thuật đóng

gói ESP hoặc AH (hoặc cả hai)

Bước 5: Kết thúc đường ngầm IPSec VPN Nguyên nhân có thể là do IPSec SA

kết thúc hoặc hết hạn hoặc bị xóa

Tuy là chia thành 4 bước, nhưng cơ bản là bước thứ 2 và bước thứ 3, hai bước này định ra một cách rõ ràng rằng IKE có tất cả 2 pha Pha thứ nhất sử dụng chế độ chính hoặc chế độ tấn công để trao đổi giữa các bên, và pha thứ hai được hoàn thành nhờ sử dụng trao đổi chế độ nhanh

Hình 1.: Các chế độ chính, chế độ nhanh của IKE

Sau đây chúng ta sẽ đi xem xét cụ thể các bước và mục đích của các pha IKE

Bước thứ nhất

Việc quyết định lưu lượng nào cần bảo vệ là một phần trong chính sách an ninh của mạng VPN Chính sách được sử dụng để quyết định cần bảo vệ lưu lượng nào (những lưu lượng khác không cần bảo vệ sẽ được gửi dưới dạng văn bản rõ)

Chính sách an ninh sẽ được phản chiếu trong một danh sách truy nhập Các bên phải chứa danh sách giống nhau, và có thể có đa danh sách truy nhập cho những mục đích khác nhau giữa các bên Những danh sách này được gọi là các danh sách điều khiển truy nhập (ACLs- Acess Control List) Nó đơn giản là danh sách truy nhập IP

mở rộng của các routers được sử dụng để biết lưu lượng nào cần mật mã ACLs làm việc khác nhau dựa vào mục đích các câu lệnh permit (cho phép) và denny (phủ nhận)

là khác nhau Hình 1.25 trình bày kết quả của các trạng thái khi thực hiện lệnh permit

và deny của nguồn và đích:

Clear-Text PacketIPSec

Crypto ACL

AH or ESP Packet

AH or ESP or Clear-Text Packet

Clear-TextPacketIPSecCrypto ACL

AH or ESP Packet

Source Peer Destination Peer

PermitPermitDenyDeny

Hình 1.17: Danh sách bí mật ACL

Từ khóa permit và deny có ý nghĩa khác nhau giữa thiết bị nguồn và đích:

• Permit tại bên nguồn: cho qua lưu lượng tới IPSec để xác thực, mật mã hóa hoặc

cả hai IPSec thay đổi gói tin bằng cách chèn tiêu đề AH hoặc ESP và có thể mật

mã một phần hoặc tất cả gói tin nguồn và truyền chúng tới bên đích

• Deny tại bên nguồn: cho đi vòng lưu lượng và đưa các gói tin bản rõ tới bên nhận

• Permit tại bên đích: cho qua lưu lượng tới IPSec để xác thực, giải mã, hoặc cả hai ACL sử dụng thông tin trong header để quyết định Trong logic của ACL, nếu như header chứa nguồn, đích, giao thức đúng thì gói tin đã được xử lý bởi IPSec tại phía gửi và bây giờ phải được xử lý ở phía thu.

• Deny tại bên đích: cho đi vòng qua IPSec và giả sử rằng lưu lượng đã được gửi ở dạng văn bản rõ

Khi những từ khóa permit và deny được kết hợp sử dụng một cách chính xác,

dữ liệu được bảo vệ thành công và được truyền Khi chúng không kết hợp chính xác,

dữ liệu bị loại bỏ Bảng dưới trình bày kết hợp các lệnh permit và deny và kết quả thực hiện cho các kết hợp:

Bảng 1.2: Kết quả khi kết hợp lệnh permit và deny

Permit Permit Đúng Permit Deny Sai Deny Permit Sai Deny Deny Đúng

Bước thứ hai

Bước thư hai này chính là IKE pha thứ nhất Mục đích của IKE pha thứ nhất:

- Đồng ý một tập các tham số được sử dụng để xác thực hai bên và mật mã một phần

chế độ chính và toàn bộ trao đổi thực hiện trong chế độ nhanh Không có bản tin nào ở chế độ tấn công được mật mã nếu chế độ tấn công được sử dụng để thương lượng

- Hai bên tham gia IP-VPN xác thực với nhau

- Tạo khóa để sử dụng làm tác nhân sinh ra khóa mã hóa mã hóa dữ liệu ngay sau khi

thương lượng kết thúc

Tất cả thông tin thương lượng trong chế độ chính hay chế độ tấn công, bao gồm khóa sau đó sử dụng để tạo khóa cho quá trình mật mã dữ liệu, được lưu với tên gọi là IKE SA hay ISAKMP SA (liên kết an ninh IKE hay ISAKMP) Bất kỳ bên nào trong hai bên cũng chỉ có một ISAKMP liên kết an ninh giữa chúng

Hình 1.: IKE pha thứ nhất sử dụng chế độ chính (Main Mode)

Chế độ chính có trao đổi 6 bản tin (tức là có 3 trao đổi 2 chiều) giữa hai bên khởi tạo và biên nhận:

- Trao đổi thứ nhất: Các thuật toán mật mã và xác thực (sử dụng để bảo vệ các trao đổi

IKE) sẽ được thỏa thuận giữa các đối tác

- Trao đổi thứ hai: Sử dụng trao đổi Diffie-Hellman để tạo khóa bí mật chia sẻ (shared

secret keys), trao đổi các số ngẫu nhiên (nonces) để khẳng định nhận dạng của mỗi đối tác Khóa bí mật chia sẻ được sử dụng để tạo ra tất cả các khóa bí mật và xác thực khác

- Trao đổi thứ ba: xác minh nhận dạng các bên (xác thực đối tác) Kết quả chính của chế

độ chính là một đường truyền thông an toàn cho các trao đổi tiếp theo của hai đối tác

Chế độ nhanh thực hiện trao đổi 3 bản tin Hầu hết các trao đổi đều được thực hiện trong trao đổi thứ nhất: thỏa thuận các tập chính sách IKE, tạo khóa công cộng Diffie-Hellman, và một gói nhận dạng có thể sử dụng để xác định nhận dạng thông qua một bên thứ ba Bên nhận gửi trở lại mọi thứ cần thiết để hoàn thành việc trao đổi Cuối cùng bên khởi tạo khẳng định việc trao đổi

a) Các tập chính sách IKE

Khi thiết lập một kết nối IP-VPN an toàn giữa hai host A và host B thông qua Internet, một đường ngầm an toàn được thiết lập giưa router A và router B Thông qua đường hầm, các giao thức mật mã, xác thực và các giao thức khác được thỏa thuận Thay vì phải thỏa thuận từng giao thức một, các giao thức được nhóm thành các tập và

được gọi là tập chính sách IKE (IKE policy set) Các tập chính sách IKE được trao đổi trong IKE pha thứ nhất, trao đổi thứ nhất Nếu một chính sách thống nhất được tìm thấy ở hai phía thì trao đổi được tiếp tục Nếu không tìm thấy chính sách thống nhất nào, đường ngầm sẽ bị loại bỏ Ví dụ Router A gửi các tập chính sách IKE policy 10

và IKE plicy 20 tới router B Router B so sánh với tập chính sách của nó, IKE policy

15, với các tập chính sách nhận được từ router A Trong trường hợp này, một chính sách thống nhất được tìm thấy: IKE policy 10 của router A và IKE policy 15 của router

B là tương đương Trong ứng dụng điểm - tới - điểm, mỗi bên chỉ cần định nghĩa một tập chính sách IKE Tuy nhiên ở mạng trung tâm có thể phải định nghĩa nhiều chính sách IKE để đáp ứng nhu cầu của tất cả các đối tác từ xa

b) Trao đổi khóa Diffie-Hellman

Trao đổi khóa Diffie-Hellman là một phương pháp mật mã khóa công khai cho phép hai bên thiết lập một khóa bí mật chung qua một môi trường truyền thông không

an toàn (xem chi tiết trong chương 4) Có 7 thuật toán hay nhóm Diffie-Hellman được định nghĩa: DH 1÷7 Trong IKE pha thứ nhất, các bên phải thỏa thuận nhóm Diffie-Hellman được sử dụng Khi đã hoàn tất việc thỏa thuận nhóm, khóa bí mật chung sẽ được tính

c) Xác thực đối tác

Xác thực đối tác là kiểm tra xem ai đang ở phía bên kia của đường ngâm VPN Các thiết bị ở hai đầu đường ngầm IP-VPN phải được xác thực trước khi đường truyền thông được coi là an toàn Trao đổi cuối cùng của IKE pha thứ nhất có mục đích như xác thực đối tác

Có hai phương thức xác thực nguồn gốc dữ liệu chủ yếu là đối tác: Khóa chia sẻ trước (Pre-shared keys) và chữ ký số (RSA signatures) Chi tiết về các thuật toán xác thực được đề cập trong chương 4

Bước thứ ba

Bước thứ 3 này chính là IKE pha 2 Mục đích của IKE pha 2 là để thỏa thuận các thông số an ninh IPSec sử dụng để bảo vệ đường ngầm IPSec Chỉ có một chế độ nhanh được sử dụng cho IKE pha 2 IKE pha 2 thực hiện các chức năng sau:

- Thỏa thuận các thông số anh ninh IPSec (IPSec Security parameters), các tập chuyển

đổi IPSec (IPSec transform sets)

- Thiết lập các kết hợp an ninh IPSec (IPSec Security Associations)

- Định kỳ thỏa thuận lại IPSec SA để đảm bảo tính an toàn của đường ngầm

- Thực hiện một trao đổi Diffie-Hellman bổ sung (khi đó các SA và các khóa mới được

tạo ra, làm tăng tính an toàn cho đường ngầm)

Chế độ nhanh cũng được sử dụng để thỏa thuận lại một kết hợp an ninh mới khi kết hợp an ninh cũ đã hết hạn Khi đó các bên có thể không cần quay trở lại bước thứ 2 nữa mà vẫn đảm bảo thiết lập một SA cho phiên truyền thông mới

d) Các tập chuyển đổi IPSec

Hình 1.: Các tập chuyển đổi IPSec

Mục đích cuối cùng của IKE pha 2 là thiết lập một phiên IPSec an toàn giữa hai điểm cuối VPN Trước khi thực hiện được điều đó, mỗi cặp điểm cuối lần lượt thỏa thuận mức độ an toàn cần thiết (ví dụ các thuật toán xác thực và mật mã dùng trong phiên đó) Thay vì phải thỏa thuận riêng từng giao thức đơn lẻ, các giao thức được

nhóm thành các tập, chính là các tập chuyển đổi IPSec Các tập chuyển đổi này được trao đổi giữa hai phía trong chế độ nhanh Nếu tìm thấy một tập chuyển đổi tương đương ở hai phía thì quá trình thiết lập phiên tiếp tục, ngược lại thì phiên đó sẽ bị loại

bỏ Ví dụ router A gửi tập chuyển đổi 30 và 40 tới router B, router B kiểm tra thấy tập chuyển đổi 50 phù hợp với tập chuyển đổi 30 của router A, các thuật toán xác thực va mật mã trong các tập chuyển đổi này hình thành một kết hợp an ninh

e) Thiết lập kết hợp an ninh

Khi một tập chuyển đổi đã được thống nhất giữa hai bên, mỗi thiết bị IP-VPN

sẽ đưa thông tin này vào một cơ sở dữ liệu Thông tin này được biết đên như là một kết hơp an ninh Thiết bị IP-VPN sau đó sẽ đanh số mỗi SA bằng một chỉ số SPI Khi có yêu cầu gửi gói tin giữa hai đầu VPN, các thiết bị sẽ dựa vào địa chỉ đối tác, các chỉ số SPI, thuật toán IPSec được dùng để xử lý gói tin trước khi truyền trong đường ngầm

f) Thời gian sống của một kêt hợp an ninh

Thời gian sống của một kết hợp an ninh càng lớn thì càng có nhiều khả năng mất an toàn Để đảm an toàn cho phiên truyền thông thì các khóa và các SA phải được thay đổi thường xuyên Có hai cách tính thời gian sống của SA: tính theo số lượng dữ liệu được truyền đi và tính theo giây Các khóa và SA có hiệu lực cho đến khi hết thời gian tồn tại của SA hoặc đến khi đường ngầm bị ngắt, khi đó SA bị xóa bỏ

1.4.2.1.6 Bước thứ tư

Sau khi đã hoàn thành IKE pha 2 và chế độ nhanh đã được thiết lập các kết hợp

an ninh IPSec SA, lưu lượng có thể được trao đổi giữa các bên IP-VPN thông qua một đường ngầm an toàn Quá trình xử lý gói tin (mã hóa, mật mã, đóng gói) phụ thuộc vào các thông số được thiết lập của SA

1.4.2.1.7 Kết thúc đường ngầm

Các kết hợp an ninh IPSec SA kết thúc khi bị xóa bỏ hoặc hết thời gian tồn tại Khi đó các bên IP-VPN không sử dụng các SA này nữa và bắt đầu giải phóng cơ sở dữ liệu của SA Các khóa cũng bị loại bỏ Nếu ở thời điểm này các bên IP-VPN vẫn còn muốn thông tin với nhau thì một IKE pha 2 mới sẽ thực hiện Trong trường hợp cần

thiết thì cũng có thể thực hiện lại từ IKE pha 1 Thông thường, để đảm bảo tính liên tục của thông tin thì các SA mới được thiết lập trước khi các SA cũ hết hạn.

1.5 Ví dụ về hoạt động của một IP-VPN sử dụng IPSec

Để tóm tắt toàn bộ quá trình hoạt động của IPSec, ta đưa ra một ví dụ về kết nối IP-VPN như hình 1.20

Chú ý rằng trước khi thiết lập kết nối IPSec, cần phải chắc chắn rằng các thiết

bị đang sử dụng dọc theo đường dẫn của IP-VPN đảm bảo: có hỗ trợ IPSec (bao gồm các giao thức, thuật toán), không có kết nối IPSec nào trước đó hoặc nếu có thì các tham số trong SA đang tồn tại không xung đột với các tham số chuẩn bị thiết lập, có thể thực hiện lệnh “ping” để chắc chắn về kết nối đã sẵn sàng

Hình 1.: Ví dụ về hoạt động của IP-VPN sử dụng IPSec

Trong ví dụ này, người dùng muốn truyền thông an toàn với mạng trụ sở chính Khi gói dữ liệu tới router người dùng(router này đóng vai trò là một cổng an ninh), router này sẽ kiểm tra chính sách an ninh và nhận ra gói dữ liệu cần truyền thông này

là một ứng dụng của IP-VPN, cần được bảo vệ Chính sách an ninh cấu hình trước

cũng cho biết router mạng trụ sở chính sẽ là phía bên kia của đường ngầm IPSec, chính là trạm trụ sở chính của IP-VPN.

Router người dùng kiểm tra xem đã có IPSec SA nào được thiết lập cho phiên truyền thông này hay chưa Nếu hoàn toàn không có một IPSec SA nào thì bắt đầu quá trình thương lượng IKE Certificate Authority có chức năng giúp trụ sở chính xác thực người sử dụng có được phép thực hiện phiên thông tin này hay không, chứng thực này

là chữ ký số và được ký bởi một đối tác có quyền ký mà hai bên đều tin tưởng Ngay sau khi hai router đã thỏa thuận được một IKE SA thì IPSec SA tức thời được tạo ra Nếu hai bên không thỏa thuận được một IKE SA nào thì nó tiếp tục quá trình thỏa thuận hoặc ngừng kết nối phiên thông tin

Việc tạo ra các IPSec SA chính là quá trình thỏa thuận giữa các bên về các chính sách an ninh, thuật toán mã hóa được sử dụng (chẳng hạn là DES), thuật toán xác thực (chẳng hạn MD5), và một khóa chia sẻ Dữ liệu về SA được lưu trong cơ sở

dữ liệu cho mỗi bên

Tới đây, router người sử dụng sẽ đóng gói dữ liệu theo các yêu cầu đã thương lượng trong IPSec SA (thuật toán mật mã, xác thực, giao thức đóng gói là AH hay ESP…), thêm các thông tin thích hợp để đưa gói tin được mã hóa này về dạng IP datagram ban đầu và chuyển tới router mạng trung tâm Khi nhận được gói tin từ router người dùng gửi đến, router mạng trung tâm tìm kiếm IPSec SA, xử lý gói theo yêu cầu, đưa về dạng gói tin ban đầu và chuyển nó tới mạng trung tâm