ĐẠI HỌC KHOA HỌC TỰ NHIÊN TP HỒ CHÍ MINH KHOA ĐIỆN TỬ VIỄN THÔNG BỘ MÔN VIỄN THÔNG VÀ MẠNG oOo BÁO CÁO ĐỀ TÀI IPSEC over TCPUDP GVHD Trần Thị Thảo Nguyên Nhóm trình bày Nhóm phản biện Hoàng Đức Phú 0920090 Nguyễn Hoài Nhân 0920078 Nguyễn Hùng Cường 0920010 Đặng Ngàn Nhất Phương 0920092 Hồ Minh Tâm 0920219 Trần Thị Như Thắm 0920223 Nguyễn Thanh Hùng 0920181 Võ Quốc Anh 0920149 Phan Thị Xuân Lan 0920054 MỤC LỤC I GIỚI THIỆU 3 II KẾT NỐI IP SEC 8 III ISAKMPIKE GIAI ĐOẠN 1 TẠO KẾT NỐI QUẢN LÝ 9 A.
GIỚI THIỆU
1 Nhu cầu sử dụng IP Sec hiện nay:
Giao thức TCP/IP đóng vai trò quan trọng trong các hệ thống mạng hiện nay, là lựa chọn chủ yếu do được sử dụng làm giao thức nền tảng cho Internet Mặc dù có nhiều tùy chọn khác như TPX/SPX, NetBEUI và AppleTalk, nhưng TCP/IP vẫn là sự lựa chọn gần như bắt buộc cho việc triển khai các hệ thống mạng.
Vào thời điểm thiết kế giao thức TCP/IP, vấn đề bảo mật thông tin chưa được chú trọng, dẫn đến việc các giao thức trong bộ này hầu như không có cơ chế bảo vệ Cấu trúc gói dữ liệu như IP, TCP, UDP và các giao thức ứng dụng được công khai, khiến cho bất kỳ ai cũng có thể phân tích gói IP trên mạng để đọc dữ liệu bên trong Hiện nay, các công cụ bắt và phân tích gói ngày càng mạnh mẽ và phổ biến Do đó, việc bổ sung các cơ chế bảo mật vào mô hình TCP/IP, đặc biệt là giao thức IP, trở thành nhu cầu cấp bách IPSec, một giao thức được chuẩn hóa bởi IETF từ năm 1998, nhằm nâng cấp các cơ chế mã hóa và xác thực thông tin cho dữ liệu truyền qua mạng IP Nói cách khác, IPSec là tập hợp các tiêu chuẩn mở được thiết lập để đảm bảo tính bảo mật, toàn vẹn và chứng thực dữ liệu giữa các thiết bị mạng, cung cấp cơ cấu bảo mật ở tầng 3 của mô hình OSI.
IPSec là một phần mở rộng của giao thức IP, hoạt động trên cả IPv4 và IPv6 Trong khi IPSec được áp dụng tùy chọn cho IPv4, nó lại trở thành yêu cầu bắt buộc trong IPv6.
IPSec (Internet Protocol Security) là giao thức do IETF phát triển, hoạt động ở tầng mạng để cung cấp các dịch vụ bảo mật, nhận thực, toàn vẹn dữ liệu và điều khiển truy cập Nó bao gồm một tập hợp các tiêu chuẩn mở, cho phép các thiết bị làm việc cùng nhau một cách hiệu quả.
IPSec là một giải pháp bảo mật cho phép thiết lập đường ngầm giữa hai mạng riêng, đồng thời xác thực hai đầu của đường ngầm Đường ngầm này có thể được hình thành giữa các thiết bị như host, router, firewall hoặc VPN concentrator Nó hoạt động như một kênh truyền an toàn cho các gói dữ liệu, đảm bảo thông tin được truyền tải một cách bảo mật Ngoài ra, IPSec còn hỗ trợ việc đóng gói dữ liệu để thiết lập, duy trì và hủy bỏ kênh truyền khi không cần thiết Các gói tin trong đường ngầm giữ cấu trúc tương tự như gói tin thông thường, không ảnh hưởng đến các thiết bị, kiến trúc và ứng dụng hiện có, giúp giảm chi phí triển khai và quản lý mạng.
IPSec employs essential mechanisms to ensure data security, including Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange (IKE), and Internet Security Association and Key Management Protocol (ISAKMP) While IPSec must support ESP, it also has the capability to support AH.
AH cho phép xác thực nguồn gốc dữ liệu và kiểm tra tính toàn vẹn của dữ liệu, đồng thời cung cấp dịch vụ chống phát lại cho các gói IP giữa hai hệ thống Tuy nhiên, AH không đảm bảo tính bảo mật, vì thông tin được gửi đi dưới dạng bản rõ.
ESP là một giao thức bảo mật cung cấp tính an toàn cho các gói tin truyền tải, bao gồm mã hóa dữ liệu, xác thực nguồn gốc và kiểm tra tính toàn vẹn Giao thức này đảm bảo tính bí mật thông tin thông qua việc mã hóa gói tin IP, với tất cả lưu lượng ESP được mã hóa giữa hai hệ thống Do đó, xu hướng sử dụng ESP ngày càng gia tăng hơn so với AH để nâng cao mức độ an toàn cho dữ liệu.
AH và ESP là hai phương tiện quan trọng trong việc kiểm soát truy cập, dựa trên việc phân phối các khóa mật mã và quản lý luồng giao thông liên quan đến các giao thức an toàn.
IKE (Internet Key Exchange) là giao thức dùng để trao đổi khóa và thỏa thuận các thông số bảo mật giữa các thiết bị, bao gồm cách mã hóa, thuật toán sử dụng và tần suất trao đổi khóa Sau khi quá trình này hoàn tất, một thương lượng được thực hiện giữa hai đầu cuối, tạo ra một liên kết bảo mật gọi là IPsec SA (Security Association) SA này có thể được xem như một nhóm các thành phần và thông số bảo mật đã được đồng thuận giữa hai thiết bị, cho phép một thiết bị sử dụng SA để giao tiếp an toàn với thiết bị khác.
ISAKMP (Internet Security Association and Key Management Protocol) is a protocol designed for establishing, negotiating, and managing security policy associations (SA) It is commonly used in conjunction with the IKE (Internet Key Exchange) protocol, hence it is often referred to as ISAKMP/IKE.
Các giao thức IPSec có thể được sử dụng độc lập hoặc kết hợp để cung cấp các giải pháp an toàn cho IPv4 và IPv6, mặc dù cách thức cung cấp dịch vụ của chúng khác nhau Cả hai giao thức AH và ESP đều không xác định các thuật toán an toàn cụ thể, mà thay vào đó, IPSec cung cấp một khung chuẩn cho việc áp 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 như Mã nhận thực bản tin trên cơ sở băm (HMAC), MD5 (Message Digest 5) và SHA-1 để đảm bảo tính bảo mật.
Để đảm bảo tính toàn vẹn của bản tin, các thuật toán như DES, 3DES, RSA và các thuật toán khác như IDEA, Blowfish và RC4 được sử dụng cho việc mã hóa dữ liệu và xác thực các bên Giao thức IPSec có thể áp dụng IKE (Internet Key Exchange) để xác thực và thương lượng các chính sách bảo mật, đồng thời xác định thuật toán thiết lập kênh truyền và trao đổi khóa cho mỗi phiên kết nối Mạng sử dụng IPSec có khả năng tự động kiểm tra tính xác thực của thiết bị thông qua chứng nhận số của người dùng Quá trình thương lượng này dẫn đến việc thiết lập kết hợp an ninh (SAS) giữa các cặp bảo mật, với thông tin kết hợp an ninh được lưu trữ trong cơ sở dữ liệu liên kết an ninh.
SA thiết lập các tham số an ninh trong bảng mục lục, đảm bảo rằng mỗi địa chỉ đích kết hợp với giao thức an ninh (ESP hoặc AH) sẽ chỉ có một kết quả duy nhất.
3 Lịch sử phát triển của IP Sec:
Kể từ khi công nghệ IPsec ra đời, nó đã vượt ra ngoài vai trò của một chuẩn internet đơn thuần, và hiện nay đã được định nghĩa trong các tiêu chuẩn RFC, như được trình bày trong bảng dưới đây.
RFC Tiêu đề Chủ đề Thời gian
1825 Security Architure for the Internet
(kiến trúc bảo mật cho giao thức Internet)
(Nhận thực tiêu đề IP)
(đóng gói an toàn tải IP)
1828 IP Authentication Using Keyed MD5
(Nhận thực IP sử dụng khoá MD5)
1829 The ESP DES-CBC Transform
(sự biến đổi ESP nhờ DES-CBC)
2104 HMAC: Keyed-Hashing for Message
(HMAC: Khoá băm cho nhận thực bản
2202 Test Cases for HMAC-MD5 and HMAC-
(các trường hợp kiểm tra cho HMAC-
2401 Security Architure for Internet Protocol IPSec 10/1998
2403 The Use of HMAC-MD5-96 within ESP and AH (sử dụng HMAC-MD5-96 cùng với ESP)
2404 The Use of HMAC-SHA-1-96 within ESP and AH (sử dụng HMAC-SHA-1-96 cùng với ESP và AH)
2405 The ESP DES-CBC Cipher Algorithm
(Thuật toán mã hoá ESP DES-CBC cùng
2406 IP Encapsulating Security Payload ESP 10/1998
2407 The Internet IP Security Domain of
Interpretation for ISAKMP (bảo mật gói tin IP trong phạm vi làm sáng tỏ
2408 Internet Security Association and Key
(giao thức quản lý kết hợp an ninh
(phương thức trao đổi khoá internet)
2410 The NULL Encryption Algorithm and Its
(vô hiệu thuật toán bảo mật và sử dụng nó với IPSec)
2451 The ESP CBC-Mode Cipher Algorithms
(thuật toán mật mã kiểu CBC cho ESP)
KẾT NỐI IP SEC
Quá trình tạo kết nối bảo mật để chia sẻ dữ liệu giữa hai thiết bị IPsec bao gồm năm bước cơ bản.
Kết nối IPsec được khởi động khi có yêu cầu từ một thiết bị cần thiết lập kết nối bảo mật với thiết bị đích Quá trình này có thể được bắt đầu bởi quản trị viên hoặc bất kỳ người dùng nào từ thiết bị của họ.
Nếu chưa có kết nối VPN, IPsec sẽ sử dụng ISAKMP/IKE Phase 1 để thiết lập một kết nối quản lý bảo mật Kết nối này rất quan trọng vì nó đảm bảo an toàn cho việc liên lạc giữa hai thiết bị, từ đó cho phép xây dựng một kết nối dữ liệu bảo mật.
Thông qua kết nối quản lý bảo mật, hai thiết bị sẽ thương lượng và thống nhất các thông số bảo mật cần thiết để thiết lập một kết nối dữ liệu an toàn Kết nối này cho phép truyền tải các dữ liệu như tệp tin một cách hiệu quả.
Khi kết nối dữ liệu được thiết lập, các thiết bị IPsec có khả năng truyền tải dữ liệu một cách an toàn Thiết bị nguồn sử dụng hàm HMAC để tạo chữ ký số, trong khi thiết bị đích kiểm tra các chữ ký này nhằm xác định tính toàn vẹn và xác thực thông tin Nếu dữ liệu được mã hóa tại nguồn, nó sẽ được giải mã tại thiết bị đích.
Cả kết nối quản lý và kết nối dữ liệu đều có thời gian tồn tại xác định để đảm bảo các khóa bảo mật được tạo lại và khác biệt, giúp ngăn chặn việc phá khóa bảo mật Khi hết thời hạn này, kết nối sẽ tự động đóng và được tạo lại nếu cần gửi dữ liệu tiếp Bài viết sẽ tiếp tục trình bày các giai đoạn hoạt động của giao thức IPsec thông qua ISAKMP/IKE.
ISAKMP/IKE GIAI ĐOẠN 1: TẠO KẾT NỐI QUẢN LÝ
Trong phần này chúng ta sẽ làm rõ hơn các bước để thiết lập một kết nối quản lý IPsec
ISAKMP và IKE phối hợp để thiết lập kết nối bảo mật giữa hai thiết bị Trong khi ISAKMP định nghĩa các thông số gói tin và thực hiện quá trình đàm phán, IKE đảm nhiệm việc tạo, chia sẻ và quản lý khóa bảo mật Bài viết này sẽ giải thích chi tiết cách ISAKMP/IKE thiết lập kết nối quản lý.
+ Giao thức trao đổi Key: Diffie-Hellman
Kết nối quản lý
Kết nối được thiết lập trong giai đoạn 1 thông qua giao thức UDP trên cổng 500, cho phép thiết lập một kết nối 2 chiều giữa hai peers, từ đó họ có thể chia sẻ các thông điệp IPsec một cách hiệu quả.
Lưu ý rằng các kết nối ISAKMP/IKE sử dụng giao thức UDP với port nguồn và đích là 500 Tuy nhiên, một số nhà cung cấp có thể sử dụng các port ngẫu nhiên lớn hơn 1023 thay vì port 500.
Dù là một kết nối site-to-site hay là kết nối từ xa, có 3 điều sau đây sẽ xảy ra trong quá trình ISAKMP/IKE giai đoạn 1:
1 Các peers sẽ đàm phán với nhau về việc kết nối quản lý sẽ được bảo vệ như thế nào
2 Các peers sẽ dùng thuật toán Diffie-Hellman để chia sẻ thông tin về Key để bảo vệ việc quản lý kết nối
3 Các peers sẽ định danh, xác nhận với nhau trước khi quá trình ISAKMP/IKE giai đoạn 2 diễn ra
ISAKMP/IKE giai đoạn 1 chịu trách nhiệm cho việc thiết lập kết nối quản lý an toàn Tuy nhiên ta lại có 2 chế độ để thực hiện 3 bước trên:
+ Aggressive (chế độ linh hoạt)
Chế độ chính thực hiện ba trao đổi hai chiều, tổng cộng là sáu gói tin Ba bước trao đổi bao gồm: đàm phán chính sách bảo mật để quản lý kết nối, sử dụng Diffie-Hellman để mã hóa khóa cho thuật toán mã hóa và hàm HMAC đã được thỏa thuận ở bước đầu tiên, và xác thực thiết bị thông qua một trong ba phương pháp: khóa chia sẻ trước, nonces được mã hóa RSA hoặc chữ ký RSA (chứng thực số).
Chế độ chính có lợi thế là quá trình xác thực thiết bị diễn ra liền mạch trong suốt kết nối quản lý, nhờ vào việc xây dựng kết nối trong hai bước đầu tiên trước khi chứng thực thiết bị Do đó, mọi thông tin nhận dạng giữa hai bên đều được bảo vệ an toàn khỏi các cuộc nghe lén.
Main Mode là mode mặc định của Cisco cho kết nối site-to-site và kết nối từ xa
Trong chế độ này, có hai quá trình trao đổi chính Quá trình đầu tiên bao gồm danh sách các chính sách bảo mật cho kết nối quản lý, cùng với public key được tạo ra từ cặp khóa “public/private key” của thuật toán DH, cùng các thông tin nhận dạng và xác minh như chữ ký Tất cả thông tin này được gói gọn trong một gói tin Quá trình trao đổi thứ hai là phản hồi (ACK) cho gói tin vừa nhận, đồng thời chia sẻ key đã mã hóa bằng thuật toán DH và xác nhận xem kết nối quản lý đã được thiết lập thành công hay chưa.
Chế độ Aggressive Mode có ưu điểm là thiết lập kết nối quản lý nhanh hơn so với Main Mode, nhưng nhược điểm lớn là thông tin nhận dạng được gửi đi dưới dạng clear text Điều này có nghĩa là nếu có ai đó nghe trộm trên đường truyền, họ có thể dễ dàng nhận diện thông tin để xác thực thiết bị Do đó, nếu bạn lo ngại về việc thông tin nhận dạng thiết bị có thể bị xem trộm, nên lựa chọn sử dụng Main Mode.
Trong quá trình ISAKMP/IKE giai đoạn 1, hai peers cần thực hiện đàm phán về cách bảo vệ kết nối quản lý Việc này được thực hiện thông qua việc xác định các transforms, tức là danh sách các biện pháp an ninh cần áp dụng để bảo vệ kết nối Đối với giai đoạn 1 của ISAKMP/IKE, transforms thường được gọi là chính sách IKE hoặc ISAKMP.
Các thông tin bao gồm trong một Transform Giai đoạn 1 là:
Thuật toán mã hóa: DES, 3DES hoặc AES
Các hàm HMAC sử dụng: MD5 hay SHA-1
Kiểu xác thực thiết bị: pre-shared keys, RSA encrypted nonces, or RSA signatures (certificates)
Nhóm khóa Diffie-Hellman: Cisco chỉ cung cấp 1, 2, 5, 7 Với 7 thì chỉ cung cấp trên Cisco 3000 concentrators và PIX và ASA những ứng dụng bảo mật đang chạy phiên bản 7.0
Thời gian tồn tại của một kết nối quản lý
Tất cả các mục này được xem như một bộ biến đổi (transform set), và thiết bị IPsec của bạn có thể yêu cầu nhiều bộ transform khác nhau để hoạt động hiệu quả.
Khi thiết bị của bạn cần kết nối IPsec đến hai peers với các kiểu mã hóa khác nhau như DES và 3DES, việc sử dụng các transform riêng biệt là cần thiết Điều này cho phép bạn tận dụng lợi thế của việc sử dụng 3DES cho một peer và DES cho peer còn lại.
Để thiết lập kết nối an toàn, thiết bị của bạn cần gửi toàn bộ danh sách ISAKMP/IKE transforms đến remote peer Thứ tự của các transforms trong danh sách rất quan trọng, vì những transforms khớp với remote peer trước sẽ được sử dụng ngay Khi thiết bị của bạn khởi tạo kết nối và gửi danh sách transforms, remote peer sẽ so sánh danh sách này với danh sách của nó để tìm các transforms tương ứng Quá trình so sánh bắt đầu từ transform đầu tiên; nếu không khớp, nó sẽ tiếp tục với transform thứ hai cho đến khi tìm thấy sự trùng khớp hoặc hết danh sách.
Ví dụ về quá trình diễn ra sự thương lượng (Nguồn: The Complete Cisco VPN
Nếu quá trình thiết lập kết nối không tìm thấy sự khớp nhau giữa hai peers, kết nối quản lý sẽ không được thiết lập và IPsec sẽ thất bại Tuy nhiên, thời gian tồn tại của mỗi peer không nhất thiết phải khớp; nếu không khớp, giá trị nhỏ hơn sẽ được chọn Một số nhà cung cấp có thể không tuân theo quy tắc mặc định của IPsec, do đó bạn cần đảm bảo rằng hai giá trị thời gian sống trên hai peers phải khớp với nhau.
Giao thức trao đổi key: Diffie-Hellman (DH)
Sau khi các peers hoàn tất đàm phán các chính sách bảo vệ cho kết nối quản lý trong Giai đoạn 1, thuật toán DH được sử dụng để tạo ra một khóa bí mật Hai giao thức ISAKMP và IKE không được thiết kế để chia sẻ dữ liệu tạo khóa trên mạng không an toàn, mà nhiệm vụ này được thực hiện bởi chính thuật toán DH.
Ta định nghĩa sơ lược về DH như sau: cả 2 peers đều tạo ta một kết hợp
Trong giao thức mã hóa, các bên sử dụng cặp khóa công khai (public key) và khóa riêng (private key) để bảo mật thông tin Mỗi bên chia sẻ khóa công khai với nhau, trong khi giữ lại khóa riêng cho bản thân Từ hai khóa này, thông qua một hàm tính toán, họ tạo ra một khóa bí mật (secret key) giống nhau, được sử dụng để mã hóa thông tin quan trọng Nếu một kẻ tấn công muốn nghe lén thông tin, họ cần có một trong hai khóa riêng của các bên, vì chỉ khi đó mới có thể tính toán ra khóa bí mật Tuy nhiên, khóa riêng không bao giờ được chia sẻ với bất kỳ ai.
Nhóm DH key là những nhóm dùng độ dài khác nhau để mã hóa key Có nhiều nhóm DH key được sử dụng, Cisco cung cấp ba nhóm sau:
Nhóm 1: 768 bit Nhóm 2: 1024 bit Nhóm 5: 1536 bit
Ngoài ra Cisco còn cung cấp nhóm 7 cho một vài thiết bị khác.
Chứng thực thiết bị
ISAKMP/IKE GIAI ĐOẠN 2: TẠO KẾT NỐI DỮ LIỆU
Phần này chúng ta sẽ thảo luận làm thế nào để bảo vệ các kết nối dữ liệu người dùng dựa vào những điều sau đây:
Những thành phần trong ISAKMP/IKE giai đoạn 2
Các giao thức bảo mật trong ISAKMP/IKE giai đoạn 2
Các phương thức kết nối trong ISAKMP/IKE giai đoạn 2
Những thành phần trong ISAKMP/IKE giai đoạn 2
ISAKMP/IKE giai đoạn 2 chỉ có một chế độ gọi là Quick mode, có nhiệm vụ bảo vệ các kết nối dữ liệu giữa hai IPsec peers Quick mode thực hiện hai chức năng chính.
Thương lượng các thông số bảo mật để bảo vệ các kết nối dữ liệu
Luôn đổi mới các thông tin một cách định kỳ (tức là xây dựng lại kết nối)
Giai đoạn 2 của ISAKMP/IKE có đặc điểm nổi bật là thiết lập hai luồng kết nối dữ liệu đơn hướng giữa hai thiết bị ngang hàng Cụ thể, thiết bị A tạo một kết nối đến thiết bị B, trong khi thiết bị B có kết nối riêng đến thiết bị A Vì hai kết nối này tách biệt, các thông số bảo mật có thể khác nhau giữa hai thiết bị, chẳng hạn như kết nối A-B sử dụng 3DES cho mã hóa, trong khi kết nối B-A có thể sử dụng DES Tuy nhiên, thực tế cho thấy các thông số bảo mật thường giống nhau.
Để thiết lập các kết nối ISAKMP/IKE giai đoạn 2 hiệu quả, cần xác định các chính sách cấu hình thiết bị phù hợp với yêu cầu.
Luồng dữ liệu nào mới thực sự cần được bảo vệ?
Cần sử dụng giao thức bảo mật nào? AH hay ESP
Dựa vào việc lựa chọn các giao thức bảo mật, các luồng dữ liệu sẽ được bảo vệ bằng cách nào? Dùng hàm băm hay hàm mã hóa
Dùng tunnel hay transport mode?
Khi xây dựng lại kết nối, ISAKMP/IKE giai đoạn 1 có nên tạo lại và chia sẻ các khóa mới hay không thay vì giữ nguyên khóa cũ
Thời gian sống của các kết nối dữ liệu là bao nhiêu?
Các giao thức bảo mật giai đoạn 2
IPsec sử dụng một hoặc hai giao thức bảo mật để bảo vệ dữ liệu trong các kết nối được thiết lập trong giai đoạn 2 của ISAKMP/IKE.
Bảng dưới đây so sánh 2 giao thức này Đặc điểm bảo mật AH ESP
Số hiệu giao thức lớp 3 51 50
Hỗ trợ tính toàn vẹn dữ liệu Yes Yes
Hỗ trợ chứng thực dữ liệu Yes Yes
Hỗ trợ mã hóa dữ liệu No Yes
Bảo vệ dữ liệu trước tấn công replay
Hoạt động với NAT No Yes
Hoạt động với PAT No No
Bảo vệ cho gói tin IP Yes No
Chỉ bảo vệ cho dữ liệu No Yes
1 Giao thức Authentication Header (AH):
AH cung cấp các dịch vụ xác thực nguồn gốc dữ liệu, kiểm tra tính toàn vẹn dữ liệu và chống phát lại Cần phân biệt giữa toàn vẹn dữ liệu, liên quan đến việc kiểm tra sự thay đổi của từng gói tin IP mà không quan tâm đến vị trí của chúng trong luồng lưu lượng, và dịch vụ chống phát lại, kiểm tra sự lặp lại của một gói tin tới địa chỉ đích nhiều 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, nhưng một số trường của IP header có thể thay đổi trong quá trình truyền, dẫn đến việc không thể bảo vệ các giá trị này bằng AH Do đó, AH chỉ bảo vệ một phần của IP header.
AH không cung cấp xử lý bảo mật dữ liệu cho các lớp trên, mà chỉ truyền tải thông tin dưới dạng văn bản rõ Mặc dù AH nhanh hơn ESP, nhưng chỉ nên được chọn khi bạn hoàn toàn tin tưởng vào nguồn gốc và tính toàn vẹn của dữ liệu, trong khi yêu cầu về bảo mật dữ liệu không phải là ưu tiên hàng đầu.
Giao thức AH cung cấp chức năng xác thực thông qua việc sử dụng hàm băm một chiều để tạo ra đoạn mã xác thực cho dữ liệu gói Đoạn mã này được chèn vào thông tin gói truyền đi, giúp phát hiện bất kỳ thay đổi nào đối với nội dung gói trong quá trình truyền Khi gói dữ liệu được nhận, hàm băm một chiều sẽ được thực hiện trên toàn bộ gói, ngoại trừ một số trường trong IP header có thể thay đổi mà phía thu không thể dự đoán, như trường thời gian sống của gói tin.
Tiêu đề tiếp theo có độ dài 8 bit, giúp nhận diện loại dữ liệu trong phần tải tin theo sau AH Giá trị này được lựa chọn từ các số giao thức IP đã được xác định trong các RFC mới nhất.
Độ dài tải tin (payload length) là 8 bit, chứa thông tin về độ dài của tiêu đề AH được biểu diễn bằng các từ 32 bit, trừ 2 Ví dụ, đối với thuật toán toàn vẹn tạo ra giá trị xác minh 96 bit (tương đương 3 từ 32 bit), cộng thêm 3 từ 32 bit cố định, thì giá trị độ dài này là 4 Đối với IPv6, tổng độ dài tiêu đề phải là bội số của 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
Số thứ tự (sequence number) là trường 32 bit không đánh dấu, có giá trị tăng lên mỗi khi một gói tin được gửi đi Trường này là bắt buộc và luôn được bên gửi bao gồm, ngay cả khi bên nhận không sử dụng dịch vụ chống phát lại Bộ đếm của bên gửi và bên nhận được khởi tạo với giá trị 0, với 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, số thứ tự này không được lặp lại và sẽ yêu cầu kết thúc phiên truyền thông, sau đó thiết lập lại SA trước khi truyền 232 gói mới.
Dữ liệu nhận thực, hay còn gọi là ICV (Integrity Check Value), có độ dài thay đổi, là bội số của 32 bit đối với IPv4 và 64 bit đối với IPv6, và có thể chứa đệm để đạt đủ kích thước ICV được tính toán bằng thuật toán nhận thực, bao gồm mã nhận thực bản tin (Message Authentication Code - MACs), thường sử dụng các thuật toán mã hóa như MD5 hoặc SHA-1 Các khóa dùng cho mã hóa AH là những khóa xác thực bí mật, không phải là chuỗi có thể đoán trước Quá trình tính toán ICV diễn ra với gói tin mới, trong đó bất kỳ trường nào có thể biến đổi trong IP header đều được cài đặt bằng 0, và dữ liệu lớp trên được giả định là không biến đổi Mỗi bên trong IP-VPN tính toán ICV độc lập; nếu ICV thu được không khớp với ICV gửi đi, gói tin sẽ bị loại bỏ, giúp đảm bảo tính toàn vẹn và ngăn chặn giả mạo.
1.3 Quá trình xử lý 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à tải tin) đượ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 là giai đoạn quan trọng trong quá trình xác thực dữ liệu, nơi bên thu so sánh mã hash mà họ tính toán được với mã hash tách ra từ tiêu đề AH Hai mã hash này cần phải hoàn toàn giống nhau; nếu có sự khác biệt dù chỉ một bit trong quá trình truyền tải, bên thu sẽ ngay lập tức phát hiện ra tính không toàn vẹn của dữ liệu Vị trí của tiêu đề cũng đóng vai trò quan trọng trong việc đảm bảo tính chính xác của quá trình này.
AH có hai kiểu hoạt động chính: kiểu Transport và kiểu Tunnel Kiểu Transport được sử dụng để kết nối đầu cuối giữa các host hoặc thiết bị hoạt động như host, trong khi kiểu Tunnel phục vụ cho các ứng dụng khác Trong kiểu Transport, AH bảo vệ các giao thức lớp trên và một số trường trong IP header, được chèn vào sau IP header và trước giao thức lớp trên như TCP, UDP, hoặc ICMP Đối với IPv4, AH nằm sau IP header và trước giao thức lớp trên, trong khi với IPv6, AH xuất hiện sau các phần header mở rộng như hop-to-hop, routing và fragmentation, với các lựa chọn đích có thể nằm trước hoặc sau AH.
Khuôn dạng IPv4 trước và sau khi xử lý AH ở kiểu Transport
Khuôn dạng IPv6 trước và sau khi xử lý AH ở kiểu Traport
Trong kiểu Tunnel, header IP bên trong chứa địa chỉ nguồn và đích cuối cùng, trong khi header IP bên ngoài đảm nhận vai trò định tuyến qua Internet Kiểu này sử dụng AH để bảo vệ toàn bộ gói tin IP bên trong, bao gồm cả header IP bên trong, khác với AH Transport chỉ bảo vệ một số trường của header IP Vị trí của AH trong kiểu Tunnel tương tự như trong kiểu Transport so với header IP bên ngoài.
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 được sử dụng để tính ICV được xác định bởi sự kết hợp của 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 phù hợp bao gồm các hàm băm một chiều như MD5 và SHA-1, đây là những thuật toán bắt buộc mà ứng dụng AH phải hỗ trợ.
Trong kiểu Transport, AH header được chèn vào sau IP header và trước header của giao thức lớp trên Ngược lại, trong kiểu Tunnel, có sự xuất hiện của outer IP header Quá trình xử lý gói tin đầu ra diễn 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 yêu cầu AH xử lý gói tin, và việc xác định quá trình xử lý IPSec cần thực hiện trên lưu lượng đầu ra được hướng dẫn trong RFC 2401.
Khi một SA được thiết lập, bộ đếm Sequence Number (SN) phía phát được khởi tạo về 0 Phía phát sẽ tăng giá trị SN cho SA này và chèn vào trường Sequence Number Nếu dịch vụ chống phát lại (anti-replay) được chọn, phía phát sẽ kiểm tra để đảm bảo rằng giá trị SN không bị lặp lại trước khi chèn giá trị mới Ngược lại, nếu dịch vụ này không được lựa chọn, phía phát không cần giám sát mà vẫn tiếp tục tăng SN 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 đó
Phương thức kết nối trong Phase 2
Như đã đề cập trong các phần trên, có hai cách mà AH và ESP có thể sử dụng để truyền thông tin bảo mật đến đích:
Chế độ vận chuyển (Transport mode) được áp dụng giữa hai thiết bị nguồn và đích cuối thực sự, tạo ra một kết nối end-to-end Trong chế độ này, chính các thiết bị này sẽ đảm nhận trách nhiệm bảo vệ dữ liệu trong quá trình truyền tải.
Transport mode bảo vệ IP Payload, bao gồm TCP/UDP Header và dữ liệu, thông qua việc sử dụng AH hoặc ESP Trong chế độ này, IP Header ban đầu không thay đổi, chỉ có trường protocol được cập nhật từ số 50 (ESP).
Chế độ 51 (AH) thường được áp dụng để bảo vệ các giao thức đường hầm khác, ví dụ như GRE Trong quá trình này, GRE sẽ đóng gói các gói tin IP, sau đó IPsec sẽ đảm bảo an toàn cho gói tin GRE đó.
Gói tin với giao thức ESP được chỉ ra trong hình sau:
Gói tin ESP trong Transport Mode (Nguồn: http://www.firewall.cx/networking-topics/protocols/870-IPsec- modes.html )
IP Header ở phía trước là gói IP ban đầu, cho thấy rằng Transport Mode không cung cấp sự bảo vệ hoặc mã hóa cho dữ liệu.
Gói tin với giao thức AH được chỉ ra trong hình sau:
AH có khả năng hoạt động độc lập hoặc kết hợp với ESP khi IPsec được triển khai trong chế độ Transport Mode Chức năng chính của AH là bảo vệ toàn bộ gói tin, tuy nhiên, trong chế độ này, IPsec không tạo ra một IP Header mới mà chỉ sao chép nguyên IP Header gốc ra bên ngoài, với sự thay đổi duy nhất là thay đổi protocol ID thành 51.
Tóm lại, trong IPsec transport mode, đối với cả ESP và AH, IP Header đều bị lộ
Chế độ Tunnel là chế độ mặc định của VPN, trong đó toàn bộ gói tin IP ban đầu được bảo vệ IPsec sẽ mã hóa gói tin này và thêm một gói tin mới, đảm bảo an toàn cho dữ liệu truyền tải.
IP Header mới và gửi nó tới đầu kia của “tunnel”
Chế độ Tunnel thường được sử dụng giữa các gateway như router Cisco và firewall ASA, hoạt động như một proxy cho các thiết bị phía sau Trong chế độ này, các thiết bị nguồn và đích không thực hiện bảo mật cho dữ liệu người dùng, mà nhiệm vụ này được đảm nhận bởi các thiết bị trung gian.
Cách này được sử dụng cho kết nối site-to-site và kết nối truy cập từ xa Gói
Trong chế độ Tunnel, thông tin về địa chỉ đầu cuối thực sự được bảo vệ và ẩn trong thông tin của AH/ESP, trong khi một tiêu đề IP khác được thêm vào để chứa địa chỉ của các thiết bị trung gian Điều này đảm bảo rằng thông tin đầu cuối hoàn toàn được bảo mật mà không ảnh hưởng đến việc định tuyến gói tin Một trong những lợi ích chính của chế độ Tunnel so với chế độ Transport là khả năng cung cấp dịch vụ bảo mật tập trung cho một số lượng thiết bị nhỏ hơn, chủ yếu là các thiết bị trung gian, từ đó giúp đơn giản hóa việc cấu hình và quản lý.
Trong chế độ tunnel, tiêu đề IPsec (AH hoặc ESP) được chèn giữa tiêu đề IP và phần giao thức lớp trên Trong hai loại tiêu đề này, ESP thường được ưa chuộng hơn trong cấu hình VPN IPsec.
Cấu trúc gói tin dùng giao thức ESP trong IPsec tunnel mode như hình sau:
Cấu trúc gói tin dùng giao thức AH trong IPsec tunnel mode như hình sau:
Kết luận, chế độ transport chỉ phù hợp cho các kết nối yêu cầu bảo vệ dữ liệu, như khi sử dụng giao thức TFTP để tải file cấu hình hoặc khi các máy nội bộ upload file log lên server Để bảo vệ cả phần IP Header chứa thông tin đầu cuối của thiết bị, chế độ tunnel là cần thiết Trong chế độ tunnel, giao thức ESP được ưa chuộng hơn nhờ tính tương thích với dịch vụ NAT.
Phase 2 Transforms
Dạng biến đổi dữ liệu (Data Transform) xác định cách bảo vệ kết nối dữ liệu trong ISAKMP/IKE phase 2, tương tự như kết nối quản lý ở Phase 1 Việc định nghĩa dạng biến đổi này là cần thiết để đảm bảo an toàn cho dữ liệu người dùng Dạng biến đổi dữ liệu bao gồm các thông tin quan trọng liên quan đến việc bảo vệ dữ liệu hiệu quả.
Giao thức bảo mật: AH và ESP
Loại kết nối cho giao thức bảo mật: Tunnel hoặc Transport Mode
Thông tin mã hóa (chỉ riêng với ESP): DES, 3DES, AES-128.AES-192, AES-256 hoặc không dùng thuật toán mã hóa nào
Các hàm HMAC để chứng thực: MD5 hoặc SHA-1 (ESP có thể dùng hoặc không).
Kết nối dữ liệu
Vấn đề chuyển đổi địa chỉ trong IP Sec
Phần này nghiên cứu về vấn đề chuyển đổi địa chỉ trong IPsec
Vấn đề chuyển đổi địa chỉ là một trong hai vấn đề quan trọng cần phải được giải quyết trong đường truyền IPsec bên cạnh vấn đề Firewall
Trong IPsec, có hai loại kết nối chính: kết nối quản lý và kết nối dữ liệu Kết nối quản lý không bị ảnh hưởng bởi việc chuyển đổi địa chỉ, trong khi kết nối dữ liệu lại gặp phải vấn đề này Trước đây, một số thiết bị sử dụng PAT yêu cầu tất cả kết nối quản lý phải dùng giao thức UDP với port 500 cho cả nguồn và đích, gây khó khăn khi sử dụng nhiều kết nối song song Tuy nhiên, nhờ vào sự cải tiến công nghệ, các thiết bị hiện nay đã khắc phục được vấn đề này Bài viết sẽ phân tích ảnh hưởng của việc chuyển đổi địa chỉ đến kết nối dữ liệu trong IPsec.
Như đã đề cập trong phần “ISAKMP/IKE giai đoạn 2”, AH hoàn toàn không hoạt động khi việc chuyển đổi địa chỉ được thực hiện trên một gói tin
Cả PAT và NAT đều không hỗ trợ truyền gói tin chứa AH, vì NAT thực hiện việc chuyển đổi địa chỉ IP của nguồn và đích, trong khi gói tin AH chứa các giá trị hàm băm của hầu hết các trường trong gói tin IP ban đầu để bảo mật và chứng thực Đối với PAT, AH là giao thức lớp 3 nên không thêm phần TCP/UDP Header.
PAT cần nên AH không thể tương thích với PAT Sau đây ta sẽ chứng minh rõ hơn phần này dựa vào hình vẽ
Chúng tôi sử dụng chế độ tunnel vì đây là chế độ mặc định và nó phù hợp với việc các thiết bị trung gian, như thiết bị thực hiện NAT, tham gia vào quá trình này.
PAT Đối với giao thức AH Gói tin của nó sẽ có cấu trúc như sau:
Tất cả các phần của gói tin IP ban đầu và phần IP Header mới đều được "signed by AH", nghĩa là AH Header chứa mã được sinh ra từ một hàm băm để chứng thực dữ liệu tại thiết bị nhận Mã băm này được tạo ra từ các thành phần của gói IP ban đầu và IP Header mới, giúp đảm bảo tính toàn vẹn và xác thực của thông tin Hình ảnh minh họa sẽ giúp chúng ta hiểu rõ hơn về cơ chế này.
Quá trình tạo AH Header bao gồm việc sử dụng gói IP ban đầu cùng với IP Header mới và một khóa bí mật đã được chia sẻ trước đó thông qua kết nối quản lý.
Vào đầu thu, thiết bị đích sẽ tạo ra một mã băm từ các thông tin tương tự như mã băm ở đầu thu Sau đó, nó so sánh mã băm này với mã băm nhận được trong AH Header (ICV) Nếu hai mã băm khớp nhau, dữ liệu được xác nhận là toàn vẹn; ngược lại, dữ liệu sẽ bị coi là không toàn vẹn.
Khi sử dụng dịch vụ NAT, các công đoạn mặc định của giao thức AH sẽ bị ảnh hưởng Điều này dẫn đến những thay đổi quan trọng trong cách thức xử lý địa chỉ IP.
Trong quá trình tính toán AH Header, một header mới được thêm vào Tiếp theo, NAT thực hiện trên gói tin, thay đổi địa chỉ IP đầu và cuối trong IP Header mới, trong khi AH Header vẫn giữ nguyên Khi gói tin được thiết bị thu nhận, mã băm sẽ được tạo ra và so sánh với mã băm trong AH Header Nếu hai mã băm không khớp, gói tin sẽ bị coi là giả mạo và sẽ bị loại bỏ ngay lập tức.
Trong quá trình thực hiện PAT, việc thay đổi số port trên TCP/UDP Header của gói tin là cần thiết Tuy nhiên, do AH là một giao thức lớp 3, phần TCP/UDP Header ở lớp 4 được xem như dữ liệu người dùng, dẫn đến việc gói tin không còn TCP/UDP Header, khiến PAT không thể thực hiện chức năng của mình Đối với giao thức ESP, cấu trúc gói tin của nó có những đặc điểm riêng biệt.
Quá trình chứng thực diễn ra tương tự như giao thức AH, nhưng phần IP Header mới không được ký bởi ESP Auth Trailer và không được tính vào ICV Chỉ có ESP Header, ESP Trailer (nếu có) và dữ liệu người dùng (gói IP ban đầu) được tính trong ICV, điều này giúp ESP hoàn toàn tương thích với NAT.
Tuy nhiên, cũng với một lý do giống như AH, ESP cũng không tương thích với PAT.
Giải quyết vấn đề chuyển đổi địa chỉ trong IP Sec
Để giải quyết vấn đề chuyển đổi địa chỉ trong IPsec, nhiều giải pháp đã được đề xuất, trong đó phương pháp phổ biến nhất là sử dụng giao thức đóng gói ESP thay vì AH Mặc dù ESP hoạt động hiệu quả với NAT, nhưng lại không tương thích với PAT Do đó, thách thức đặt ra là làm thế nào để ESP có thể hoạt động với các thiết bị thực hiện PAT.
NAT-T là một giải pháp phổ biến trong việc cấu hình VPN, theo tài liệu "The Complete Cisco VPN Configuration Guide" của Richard Deal Giải pháp này thực hiện bằng cách chèn một phần Header TCP hoặc UDP giữa phần IP Header bên ngoài và phần ESP, như hình minh họa.
Giải quyết vấn đề chuyển đổi địa chỉ trong IPsec (Nguồn: The Complete Cisco
VPN Configuration Guide – Richard Deal)
Do phần TCP/UDP Header thuộc phần Header bên ngoài, nó không được tính vào quá trình tạo mã băm cho chữ ký số Trong trường hợp IPsec over UDP, một UDP Header chuẩn luôn được chèn giữa phần IP Header bên ngoài và phần ESP Header, giúp ESP giải quyết vấn đề với PAT Tuy nhiên, việc chèn này có nhược điểm là thiết bị luôn thực hiện thao tác này ngay cả khi không có thiết bị chuyển đổi địa chỉ giữa hai đầu cuối, khiến phần UDP Header trở nên dư thừa.
(Nguồn: wikipedia) Đối với IPsec over TCP, một Header TCP sẽ được chèn vào giữa phần
IP Header bên ngoài và phần ESP Header Tuy nhiên, nhược điểm của loại này so với IPsec over UDP là phần TCP Header chứa nhiều bytes hơn UDP
Header Cũng vì nhược điểm đó nên TCP header thường được ít sử dụng hơn so với UDP header
Để xác định sự tồn tại của NAT giữa hai thiết bị trong một mạng, IPsec sử dụng cơ chế gửi thông tin địa chỉ IP giữa các thiết bị.
Khi hai thiết bị trao đổi thông tin về địa chỉ nguồn, địa chỉ đích và số port kèm theo mã băm, nếu cả hai tính toán mã băm và nhận được kết quả giống nhau, điều đó cho thấy không có NAT giữa chúng Ngược lại, nếu mã băm khác nhau, tức là có sự thay đổi về địa chỉ IP hoặc số port, hai thiết bị sẽ cần thực hiện việc đóng gói gói tin trong UDP hoặc TCP.
Header để có thể sử dụng được IPsec
Sau khi thêm phần Header TCP/UDP vào gói tin, một số thông tin trong gói tin có thể bị thay đổi Do đó, quá trình đóng gói hoàn chỉnh của IPsec trở nên cần thiết để đảm bảo tính toàn vẹn và bảo mật dữ liệu.
