Tiêu chuẩn IPsec - IP ESP – Bảo mật đóng gói giao thức IP

Tổng quan về IPsec - IP ESP

Tiêu chuẩn IPsec - IP ESP (Internet Protocol Encapsulating Security Payload) –
Bảo mật đóng gói giao thức IP là một giao thức thuộc bộ giao thức An toàn giao thức
Internet (Internet Protocol Security - IP Sec). Trong đó, bộ giao thức IP Sec là một bộ
giao thức của tầng mạng (Network Layer) trong Mô hình tham chiếu liên kết nối các
hệ thống mở (Open Systems Interconnection Reference Model - OSI), thực hiện bảo
mật cho việc truyền thông giao thức Internet (Internet Protocol - IP) bằng cách xác
thực và mã hóa từng gói tin IP của một phiên truyền thông. IPsec bao gồm các giao
thức thiết lập xác thực lẫn nhau giữa các tác nhân bắt đầu phiên giao dịch và thực hiện
đàm phán khóa mật mã được sử dụng trong phiên.
Tiêu chuẩn IPsec - IP ESP được Nhóm chuyên trách kỹ thuật Internet (Internet
Engineering Task Force - IETF) công bố tại RFC4303 vào tháng 12 năm 2005 (RFC -
Request for Comments, là những tài liệu kỹ thuật và tổ chức về Internet, bao gồm
những tài liệu đặc tả kỹ thuật và chính sách được tổ chức IETF phát hành). Nó được
thiết kế để cung cấp tính bảo mật, xác thực nguồn gốc, tính toàn vẹn và cung cấp dịch
vụ chống phát lại (một hình thức toàn vẹn từng phần) của một gói tin.
Định dạng gói tin ESP
ESP có 3 thành phần bao gồm: Tiêu đề (ESP Header), Quảng cáo (ESP Trailer)
và Dữ liệu xác thực ESP (ESP Authentication Data).
ESP Header chứa 2 trường là chỉ số bảo mật (Security Parameter Index – SPI)
và số thứ tự (Sequence Number – SN). Vị trí của nó phụ thuộc vào việc sử dụng ESP
theo chế độ (mode) nào.
ESP Trailer được đặt sau dữ liệu mã hóa. Nó chứa thành phần trung gian
(padding) được sử dụng để sắp xếp các dữ liệu được mã hóa thông qua trường Padding
và Pad Length. Ngoài ra, ESP Trailer cũng chứa các trường Next Header cho ESP.
ESP Authentication Data bao gồm trường Giá trị kiểm tra tính toàn vẹn
(Integrity Check Value – ICV).
Có hai lý do phân chia thành các trường như trên. Lý do thứ nhất là một số
thuật toán mã hóa đòi hỏi các dữ liệu được mã hóa phải có một kích thước khối (block)
nhất định và do đó thành phần trung gian phải xuất hiện sau dữ liệu mã hóa chứ không
phải xuất hiện trước. Đó là lý do tại sao thành phần đệm xuất hiện trong Trailer ESP.
Lý do thứ hai là thành phần Authentication data ESP xuất hiện một cách riêng biệt bởi
vì nó được sử dụng để xác thực các phần còn lại của các gói tin đã được mã hóa. Điều
này có nghĩa là nó không thể xuất hiện trong ESP Header hoặc ESP Trailer.
Hình 1 minh họa các định dạng mức cao của một gói tin ESP. Các gói tin bắt
đầu với 2 trường có độ dài 4 byte là trường chỉ số bảo mật (Security parameter Index –

1
SPI) và số thứ tự (Sequence Number – SN). Tiếp theo các trường này là trường
Payload Data, trong đó có cấu trúc thành phần phụ thuộc vào việc lựa chọn các thuật
toán mã hóa, chế độ hoạt động và việc sử dụng của thành phần trung gian. Sau trường
Payload Data là trường Padding (thành phần trung gian), trường Pad Length và trường
Next Header. Cuối cùng là vị trí của trường Giá trị kiểm tra tính toàn vẹn (Integrity
Check Value – ICV).

Hình 1: Định dạng mức cao của một gói tin ESP
Thành phần ESP Trailer (thành phần rõ ràng, được truyền đi) gồm trường
Length Padding, Pad và trường Next Header. Ngoài ra, thành phần dữ liệu ẩn của ESP
Trailer (không được truyền đi) được chứa trong thành phần tính toán toàn vẹn.
Nếu chọn dịch vụ toàn vẹn, việc tính toán toàn vẹn bao gồm các trường SPI,
SN, Payload Data, và ESP trailer (cả thành phần ẩn và thành phần rõ ràng).
Nếu chọn dịch vụ bảo mật, chuỗi mật mã (ciphertext) bao gồm các trường
Payload Data (trừ các dữ liệu đồng bộ hóa mật mã) và ESP trailer (thành phần rõ
ràng).
Như đã nói ở trên, Payload Data có thể có cấu trúc thành phần. Một thuật toán
mã hóa cần một Vecto khởi tạo (Initialization Vector - IV). Một số chế độ thuật toán
kết hợp mã hóa và toàn vẹn thành một hoạt động duy nhất, gọi chung là "các thuật
toán chế độ kết hợp (combined mode algorithms)". Mức độ thích hợp của các thuật
toán chế độ kết hợp này yêu cầu thuật toán mô tả rõ ràng cấu trúc thành phần được sử
dụng để truyền tải dữ liệu toàn vẹn.
Một số thuật toán chế độ kết hợp chỉ cung cấp tính toàn vẹn cho dữ liệu mã hóa,
trong khi một số thuật toán khác có thể cung cấp tính toàn vẹn cho dữ liệu bổ sung có
thể không cần mã hóa khi truyền. Bởi vì các trường SPI và SN yêu cầu tính toàn vẹn
như là một phần của dịch vụ toàn vẹn và chúng không được mã hóa, do đó, cần thiết

2
phải đảm bảo rằng chúng luôn luôn đảm bảo tính toàn vẹn bất cứ khi nào lựa chọn các
dịch vụ, không phụ thuộc vào chế độ thuật toán kết hợp.
Khi triển khai một thuật toán chế độ kết hợp, bản thân thuật toán mong đợi sẽ
trả lại cả bản rõ (decrypted plaintext) và chỉ dẫn thành công hay thất bại của việc kiểm
tra tính toàn vẹn. Đối với thuật toán chế độ kết hợp, có thể bỏ qua trường Giá trị kiểm
tra tính toàn vẹn ICV (bình thường xuất hiện ở phần cuối của gói ESP khi lựa chọn
tính toàn vẹn).
Nếu một thuật toán chế độ kết hợp chỉ cung cấp tính toàn vẹn dữ liệu đã mã
hóa, cần thiết phải lặp lại các trường SPI và SN như là một phần của Payload Data.

H
ình 2: Cấu trúc thành phần của Payload Data
Trường Security parameter Index (SPI)
SPI là một giá trị 32 bít tùy chọn được sử dụng bởi bên nhận để xác định các
tham số bảo mật của một gói tin đến. Trường SPI là trường bắt buộc.
Tập các giá trị của trường SPI nằm trong khoảng từ 1 đến 255 được dự trữ bởi
Tổ chức cấp phát số hiệu Internet (Internet Assigned Numbers Authority – IANA).
Trường Sequence Number (SN)
SN là một giá trị 32 bít dùng để đếm gói tin được gửi. Trường SN là trường bắt
buộc phải có ngay cả khi bên nhận không chọn kích hoạt dịch vụ chống phát lại (anti-
replay). Ngoài ra, để hỗ trợ việc thực hiện an toàn giao thức Internet tốc độ cao, hỗ trợ
thêm trường Số thứ tự mở rộng (Extended Sequance Number) 64 bít.
Trường Payload Data

3
 Payload Data là một trường có độ dài biến thiên chứa dữ liệu (từ gói tin IP ban
đầu) được mô tả bởi trường Next Header. Payload Data là trường bắt buộc và có độ
dài là một số nguyên gồm nhiều byte. Nếu thuật toán được sử dụng để mã hóa các tải
(payload) yêu cầu dữ liệu đồng bộ mật mã thì nó không thể được coi là một trường
riêng biệt trong ESP. Với thuật toán mã hóa đòi hỏi tính rõ ràng như vậy, dữ liệu đồng
bộ theo từng gói tin phải chỉ ra độ dài, cấu trúc cho dữ liệu đó, và dữ liệu này sẽ được
xem là một phần của một RFC đặc tả cách thức sử dụng thuật toán với ESP.
Lưu ý rằng phần bắt đầu của tiêu đề giao thức lớp tiếp theo phải được liên kết
với phần đầu của tiêu đề ESP. Với IPv4, liên kết này là một giá trị bội số của 4 byte,
với IPv6, liên kết là một giá trị bội số của 8 bytes.
Trường Padding (cho mã hóa)
Hai yếu tố chính yêu cầu hoặc khuyến khích sử dụng trường Padding.
Yếu tố thứ nhất, nếu một thuật toán mã hóa được sử dụng mà yêu cầu bản rõ là
một giá trị gồm các byte, ví dụ: kích thước khối của khối mã, trường Padding được sử
dụng để điền vào bản rõ (bao gồm trường Payload Data, Padding, Pad Length và
trường Next Header) với kích thước theo yêu cầu của các thuật toán.
Yếu tố thứ hai, Padding cũng có thể xuất hiện mà không cần phân biệt các yêu
cầu thuật toán mã hóa nhằm đảm bảo rằng kết quả bản mã hóa kết thúc trong 4 byte.
Cụ thể hơn, trường Pad Length và Next Header chính xác phải được sắp xếp trong một
từ 4 byte (như minh họa trong hình 1), để đảm bảo rằng trường ICV (nếu có) được sắp
xếp trong 4 byte.
Ngoài ra, Padding còn được sử dụng để che giấu chiều dài thực tế tải (payload).
Trường Pad Length
Trường Pad Length cho biết số lượng byte pad của trường Padding. Tập các giá
trị hợp lệ là của trường Pad Length là từ 0 đến 255, trong đó giá trị 0 (zero) chỉ ra rằng
trường Padding không chứa byte nào. Trường Pad Length là trường mang tính bắt
buộc.
Trường Next Header
Next Header là một trường bắt buộc gồm 8 bít để xác định kiểu dữ liệu chứa
trong trường Payload Data. Giá trị của trường này được chọn từ tập các số của Giao
thức IP được xác định trên trang web của tổ chức IANA. Ví dụ, giá trị 4 chỉ ra IPv4,
giá trị 41 chỉ ra IPv6 và giá trị 6 chỉ ra giao thức TCP.
Trường Traffic Flow Confidentiality (TFC)
Như đã trình bày ở trên, trường Padding có chiều dài được giới hạn trong 255
byte. Điều này thường sẽ không đủ để che giấu đặc điểm liên quan đến các yêu cầu về

4
bảo mật lưu lượng luồng. Do đó, bổ sung thêm trường TFC để giải quyết các yêu cầu
liên quan đến bảo mật lưu lượng luồng.
Trường Integrity Check Value (ICV)
ICV là một trường có độ dài biến thiên được tính toán trên cơ sở tiêu đề ESP,
Payload và ESP Trailer. Các trường của ESP Trailer rõ ràng được chứa trong phần tính
toán ICV. Trường ICV là tùy chọn và chỉ xuất hiện nếu các dịch vụ toàn vẹn được
chọn và được cung cấp bởi một thuật toán toàn vẹn riêng biệt hoặc một thuật toán kết
hợp có sử dụng ICV. Chiều dài của trường IVC được quy định bởi các thuật toán toàn
vẹn được lựa chọn và liên quan đến các chỉ số bảo mật. Đặc tả thuật toán toàn vẹn phải
xác định độ dài của trường ICV, các quy tắc so sánh và các bước xử lý khi kiểm tra.
Chế độ hoạt động của ESP
ESP có thể được triển khai theo hai chế độ: chế độ chuyển vận (transport mode)
và chế độ đường hầm (tunnel mode).
Trong chế độ chuyển vận, ESP được chèn sau phần tiêu đề IP và trước một giao
thức lớp tiếp theo, ví dụ, TCP, UDP, ICMP,... Với IPv4, vị trí của ESP được chèn sau
tiêu đề IP và trước các giao thức lớp tiếp theo. Với IPv6, ESP được xem như là một tải
điểm-điểm (end-to-end) và do đó nó sẽ xuất hiện sau phần định tuyến và các tiêu đề
mở rộng thành phần. Tiêu đề mở rộng tùy chọn đích có thể xuất hiện trước, sau hoặc
cả trước và sau tiêu đề ESP tùy thuộc vào ngữ nghĩa mong muốn. Tuy nhiên, vì ESP
chỉ bảo vệ các trường đứng sau tiêu đề ESP nên vị trí của tiêu đề tùy chọn đích thường
đặt sau tiêu đề ESP.
Trong chế độ đường hầm, phần tiêu đề IP bên trong (inner) chứa nhiều địa chỉ
IP nguồn và đích trong khi phần tiêu đề IP bên ngoài (outer) chứa các địa chỉ của các
điểm ngang hàng (peer) IPsec. Trong chế độ đường hầm, ESP bảo vệ toàn bộ gói IP
bên trong, bao gồm toàn bộ phần tiêu đề IP bên trong. Vị trí của ESP trong chế độ
đường hầm liên quan đến tiêu đề IP bên ngoài, giống như đối với ESP trong chế độ
chuyển vận.
Ứng dụng
IPsec - IP ESP có thể được sử dụng một mình hoặc kết hợp với giao thức IP Sec
AH để đảm bảo tính xác thực, tính toàn vẹn, tính bảo mật cho gói tin được truyền giữa
một cặp máy chủ (host-to-host), giữa một cặp cổng gateway (network-to-network)
hoặc giữa một cổng gateway với một máy chủ (network-to-host). Trong Thông tư số
22/2013/TT-BTTTT ngày 23 tháng 12 năm 2013 của Bộ trưởng Bộ Thông tin và
Truyền thông Ban hành Danh mục tiêu chuẩn kỹ thuật về ứng dụng công nghệ thông
tin trong cơ quan nhà nước quy định Bắt buộc áp dụng IPsec - IP ESP và được xếp
vào nhóm Tiêu chuẩn về an toàn thông tin.
Đặng Thị Thu Hương – Cục Tin học hóa