Giao thức liên mạng máy tính an toàn IPSec và các giao thức trao đổi khoá ứng dụng trong bảo mật thông tin kinh tế xã hội

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG




NGUYỄN ĐỨC THỌ

GIAO THỨC LIÊN MẠNG MÁY TÍNH AN TOÀN IPSEC
VÀ CÁC GIAO THỨC TRAO ĐỔI KHÓA ỨNG DỤNG
TRONG BẢO MẬT THÔNG TIN KINH TẾ XÃ HỘI

Chuyên ngành: Kỹ thuật Điện tử
Mã số: 60.52.70

Hà N
ộ
i
2012



Luận văn được hoàn thành tại:
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG


Người hướng dẫn khoa học: PGS.TS Lê Mỹ Tú

Phản biện 1:
………………………………………………………………………
Phản biện 2:
………………………………………………………………………

Luận văn sẽ được bảo vệ trước Hội đồng chấm luận văn thạc sĩ tại Học
viện Công nghệ Bưu chính Viễn thông
Vào lúc: giờ ngày tháng năm


Có thể tìm hiểu luận văn tại:
- Thư viện của Học viện Công nghệ Bưu chính Viễn thông
1

LỜI NÓI ĐẦU
Những biện pháp đảm bảo an toàn thông tin đưa ra
đều nhằm đáp ứng 4 yêu cầu: bảo mật thông tin, chống quá
trình replay trong các phiên bảo mật, xác thực thông tin và
toàn vẹn thông tin trên đường truyền. Khác với các giao
thức bảo mật khác trên Internet như SSL, TLS, và SSH,
làm việc từ tầng Transport trở lên, còn IPSec lại làm việc ở
lớp 3 Network layer. IPSec là một giao thức được thiết kế
để bảo vệ các gói dữ liệu khi chúng truyền tải trong mạng
bằng cách sử dụng mã hoá khoá chung. Về bản chất, máy
nguồn sẽ gói địa chỉ IP chuẩn bên trong một gói IPSec đã
được mã hoá.Sau đó gói dữ liệu này sẽ được duy trì ở trạng
thái mã hoá cho tới khi nó đến được đích.Ngoài tính năng
kể trên, bên cạnh việc mã hoá, IPSec có thể hoạt động với
một cơ chế giống như tường lửa. Do đó tôi đã tìm hiểu và
nghiên cứu đề tài luận văn Giao thức liên mạng máy tính
an toàn IPSec và các giao thức trao đổi khoá ứng dụng
trong bảo mật thông tin kinh tế xã hội. Luận văn gồm 3
chương: Chương 1 tìm hiểu về giao thức liên mạng máy

tính an toàn IPSec, phân tích cấu trúc, hoạt động của giao
thức này. Chương 2 nghiên cứu sâu về 2 giao thức trao đổi
khoá IKEv1 và IKEv2. Chương 3 đưa ra các ưu điểm nội
trội của giao thức trao đổi khoá IKEv2, từ đó đề xuất ứng
dụng trong bảo mật thông tin kinh tế xã hội.

2


CHƯƠNG 1: GIAO THỨC LIÊN MẠNG MÁY
TÍNH AN TOÀN
1.1. Tổng quan về giao thức bảo mật IPSec.
Thuật ngữ IPSec là một từ viết tắt của thuật Internet
Protocol Security. Giao thức IPSec được phát triển bởi tổ
chức Internet Engineering Task Force (IETF). Mục đích
chính của việc phát triển IPSec là cung cấp một cơ chế bảo
mật ở tầng 3 (Network layer) trong mô hình OSI, hình 1.1:


Hình 1.1. Vị trí IPSec trong OSI
3

1.1.1. Các tổ hợp an toàn IPSec (IPSec Security
Associations – IPSec SAs)
Các tổ hợp an toàn (SAs) là một khái niệm cơ bản
của bộ giao thức IPSec. SA là một tập các thuộc tính bảo
mật duy nhất giữa hai thực thể sử dụng các dịch vụ IPSec:
như các giao thức xác thực, các khóa, và các thuật toán mật
mã, các khóa, thuật toán xác thực, mã hóa, được dùng
bởi các giao thức Authentication Header (AH) hay

Encapsulation Security Payload (ESP) của giao thức IPSec.


Hình 1.2. IPSec SA
Một IPSec SA gồm có 3 trường :
SPI (Security Parameter Index). Đây là một trường
32 bit dùng nhận dạng giao thức bảo mật, được định nghĩa
bởi trường Security protocol, trong bộ IPSec đang dùng.
SPI được xem như là một phần đầu của giao thức bảo mật
và thường được chọn bởi hệ thống đến trong suốt quá trình
thỏa thuận của SA.
Destination IP address. Đây là địa chỉ IP của điểm
đến. Mặc dù nó có thể là địa chỉ broadcast, unicast, hay
multicast, nhưng cơ chế quản lý hiện tại của SA chỉ được
định nghĩa cho hệ thống unicast.
4

Security protocol. Phần này mô tả giao thức bảo mật
IPSec, có thể là AH hoặc ESP.
1.1.2. Chức năng của giao thức IPSec
Giao thức IPSec cung cấp ba chức năng chính:
Tính xác thực và toàn vẹn dữ liệu (Authentication
and data integrity). IPSec cung cấp một cơ chế mạnh để
xác thực người gửi và kiểm chứng bất kỳ sự thay đổi của
nội dung gói dữ liệu bởi người nhận. Các giao thức IPSec
đưa ra khả năng bảo vệ mạnh để chống lại các dạng tấn
công giả mạo, nghe trộm và từ chối dịch vụ.
Tính bí mật (Confidentiality). Các giao thức IPSec
mã hóa dữ liệu bằng cách sử dụng kỹ thuật mật mã, giúp
ngăn chặn việc truy cập dữ liệu trái phép trên đường

truyền. IPSec cũng dùng cơ chế tạo đường hầm để ẩn địa
chỉ IP nguồn (người gửi) và đích (người nhận) từ những kẻ
nghe trộm.
Quản lý khóa (Key management). IPSec dùng một
giao thức thứ ba, Internet Key Exchange (IKE), để thỏa
thuận các khóa trong suốt phiên giao dịch.
1.2. Phân tích chi tiết giao thức IPSec
Như trên đã đề cập giao thức IPSec hoạt động dựa vào các
thành phần chính [1, 2]:
 [AH + ESP]: Bảo vệ truyền thông IP, dựa vào SA
(khóa, địa chỉ, các thuật toán mật mã)
 IKE: Để thiết lập các SA (SA – Security
Association) cho AH hoặc ESP, và duy trì/quản lí
các kết nối.
5

1.2.1. Các chế độ hoạt động [1, 2]
1.2.1.1. Chế độ vận chuyển (transport mode)
1.2.1.2. Chế độ đường hầm (tunnel mode)
1.2.2. Các giao thức AH và ESP.
1.2.2.1. Giao thức ESP [3]
 Giao thức ESP trong chế độ vận chuyển (transport
mode)
Giao thức ESP cung cấp dịch vụ bảo mật, tính toàn
vẹn dữ liệu, xác thực nơi gửi (source authentication) và
chống tấn công lặp lại (replay attack)
Thêm phần header mới nằm sau IP header và trước
phần dữ liệu của gói tin IP.
Thêm phần dữ liệu thêm (trailer) vào phần cuối gói
tin.

 Giao thức ESP trong chế độ đường hầm (tunnel
mode)
Giao thức ESP hoạt động trong chế độ đường hầm
như hình 1.9 sau:
Hình 1.9. Giao thức ESP ở chế độ đường hầm
6

1.2.2.2. Giao thức AH [4, 5]
 AH trong chế độ vận chuyển
Giao thức AH trong chế độ vận chuyển có thể mô tả như
hình 1.10 dưới đây:

Hình 1.10. AH trong chế độ vận chuyển
 AH trong chế độ đường hầm
Trong AH Tunnel mode, phần đầu mới (AH) được
chèn vào giữa phần header mới và phần header nguyên bản,
như hình 1.11 bên dưới.


Hình 1.11. AH trong chế độ đường hầm
7

1.3. Vai trò của các giao thức trao đổi khoá trong
các ứng dụng IPSec.
Xác thực người tham gia phiên liên lạc (gồm ba
phương pháp: dùng chữ ký số, dùng mật mã khóa công
khai và dùng khóa bí mật chia sẻ trước).
Thiết lập khóa dùng cho phiên liên lạc (gồm có 07
khóa: hai khóa dùng cho mã hóa các thông điệp trao đổi
khóa, hai khóa dùng cho MAC, hai khóa dùng cho việc xác

thực, và một khóa dùng làm mầm khóa cho việc bảo mật
dữ liệu của phiên liên lạc).
Làm tươi khóa trong cùng một phiên liên lạc (hay còn
gọi là thỏa thuận lại khóa).
CHƯƠNG 2: CÁC PHIÊN BẢN GIAO THỨC
TRAO ĐỔI KHÓA IKEV1 VÀ IKEV2
2.1. Giao thức trao đổi khoá IKEv1 [6].
 ISAKMP ([7]) cung cấp một cơ cấu để xác thực và trao
đổi khóa nhưng không xác định các khóa này. ISAKMP
được thiết kế dùng để trao đổi khóa độc lập do đó có thể
nói nó được thiết kế để hỗ trợ cho nhiều phương pháp
trao đổi khóa khác nhau.
 Oakley ([8]) mô tả một loạt chế độ trong các giao thức
và chi tiết các dịch vụ được cung cấp bởi chính các yếu
tố của nó (chuyển tiếp hoàn hảo các khóa, bảo vệ danh
tính, và xác thực).
8

 SKEME ([9]) mô tả một kỹ thuật trao đôi khóa linh
hoạt giúp cung cấp chức năng ẩn danh, repudiability, và
thảo thuận lại khóa nhanh.
2.1.1. Một số ký hiệu
2.1.2. Giới thiệu
2.1.3. IKE Phase 1 sử dụng chữ ký số
Việc sử dụng chữ ký, thông tin phụ trợ trao đổi
trong quá trình khứ hồi thứ hai là nonces, trao đổi này được
nhận thực bởi hàm băng chữ ký hai bên có thể đạt được.
Mode chính với việc nhận thực chữ ký được mô tả như sau:
Initiator Responder

HDR, SA >
< HDR, SA
HDR, KE, Ni >
< HDR, KE, Nr
HDR*, IDii, [ CERT, ] SIG_I >
< HDR*, IDir, [ CERT, ] SIG_R
Chế độ Aggressive với chữ ký kết hợp với ISAKMP
được mô tả như sau:
Initiator Responder

HDR, SA, KE, Ni, IDii >
< HDR, SA, KE, Nr, IDir,
[ CERT, ] SIG_R
HDR, [ CERT, ] SIG_I >
9

2.1.4. Phase 1 xác thực với mã hóa khóa công khai
Để thực hiện mã hóa công khai, bản tin khởi tạo đã
phải có khóa công khai của bản tin đáp ứng. Trong trường
hợp bản tin đáp ứng có nhiều khóa công khai, một băm xác
nhận bản tin khởi tạo được sử dụng để mã hóa các thông tin
phụ trợ được thông qua như một phần của bản tin thứ ba.
Bằng các này bản tin đáp ứng có thể xác định khóa riêng
tương ứng để sử dụng giải mã các tải tin đã mã hóa và nhận
dạng bảo vệ được giữ lại.
Khi sử dụng mã hóa để nhận thực, mode chính được
quy đinh như sau:
Initiator Responder

HDR, SA >

< HDR, SA
HDR, KE, [ HASH(1), ]
<IDii_b>PubKey_r,
<Ni_b>PubKey_r >
HDR, KE, <IDir_b>PubKey_i,
< <Nr_b>PubKey_i
HDR*, HASH_I >
< HDR*, HASH_R
Aggressive Mode được xác thực với mã hóa mô tả như
sau:
Initiator Responder

HDR, SA, [ HASH(1),] KE,
<IDii_b>Pubkey_r,
<Ni_b>Pubkey_r >
HDR, SA, KE, <IDir_b>PubKey_i,
< <Nr_b>PubKey_i, HASH_R
10

HDR, HASH_I >
Lưu ý rằng, không giống như các phương pháp mã
hóa xác thực khác, xác thực với mã hóa khóa công khai cho
phép bảo vệ danh tính với chế độ tích cực Aggressive
Mode
2.1.5. Phase 1 xác thực với chế độ cải tiến sử dụng
mã hóa khóa công khai
Trong chế độ này, các nonce vẫn mã hóa bằng cách
sử dụng các khóa công khai của các bên. Tuy nhiên các đặc
điểm của các bên (và các xác nhận nếu nó được gửi) được
mã hóa bằng cách sử dụng các thuật toán mã hóa thỏa

thuận đối xứng (từ các tải tin SA) với một khóa bắt nguồn
từ nonce.
Các khóa mã hóa đối xứng được bắt nguồn từ các
nonce giải mã như sau. Đầu tiên là giá trị Ne_i và Ne_r
được tính:
Ne_i = prf(Ni_b, CKY-I)
Ne_r = prf(Nr_b, CKY-R)
2.1.6. Phase 1 xác thực với khóa chia sẻ trước
Khi thực hiện xác thực với khóa được chia sẻ trước,
chế độ chính (main mode) được quy định như sau:
Initiator Responder

HDR, SA >
< HDR, SA
HDR, KE, Ni >
< HDR, KE, Nr
HDR*, IDii, HASH_I >
< HDR*, IDir, HASH_R
11

Chế độ tích cực (Aggressive mode) với khóa được
chia sẻ trước được mô tả như sau:
Initiator Responder

HDR, SA, KE, Ni, IDii >
< HDR, SA, KE, Nr, IDir,
HASH_R
HDR, HASH_I >
2.1.7. Phase 2 - Quick Mode
Quick Mode không phải là một trao đổi đầy đủ (trong đó

nó là ràng buộc để trao đổi phase 1), nhưng được sử dụng
như là một phần của quá trình thỏa thuận SA (giai đoạn 2)
để lấy được dữ liệu tạo khóa và thỏa thuận chính sách chia
sẻ không ISAKMP SA
Các thông tin trao đổi cùng với chế độ nhanh (quick
mode) phải được bảo vệ bởi ISAKMP SA, tức là tất cả các
tải tin ngoại trừ tiêu đề ISAKMP được mã hóa. Chế độ
nhanh (quick mode), mộ tải tin HASH ngay lập tức phải
thực hiện theo các tiêu đề ISAKMP và tải tin SA ngay lập
tức phải thực hiện theo các HASH
Chế độ nhanh được định nghĩa như sau:
Initiator Responder

HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] >
< HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) >
12

Các hàm băm để trao đổi ở trên là:
HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ |
IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE]
[ | IDci | IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
Sử dụng Chế độ nhanh, nhiều SA và khóa có thể
được thỏa thuận với một trao đổi như sau:
Initiator Responder

HDR*, HASH(1), SA0, SA1, Ni,
[, KE ] [, IDci, IDcr ] >
< HDR*, HASH(2), SA0, SA1,
Nr,
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) >
Dữ liệu khóa có nguồn gốc giống hệt như trong
trường hợp của một SA duy nhất. Trong trường hợp này
(thỏa thuận của hai tải tin SA) kết quả sẽ là bốn giao tiếp
bảo mật - hai mỗi chiều cho cả hai SA.
2.1.8. New Group Mode
New group mode không phải được sử dụng trước
khi thiết lập một ISAKMP SA. Các mô tả của một nhóm
mới chỉ phải tuân theo thỏa thuận phase 1. (Mặc dù, nó
không phải là một trao đổi phase 2)
Initiator Responder

13

HDR*, HASH(1), SA >
< HDR*, HASH(2), SA
2.2. Giao thức trao đổi khoá IKEv2 [10]
2.2.1. Giới thiệu
IKE thực hiện xác thực 2 chiều và thiết lập một tổ
hợp an toàn IKE (IKE SA) giữa 2 thực thể, sau đó IKE SA
được sử dụng để thiết lập các tổ hợp an toàn cho giao thức
ESP (Encapsulating Security Payload) [3] hoặc AH
(Authentication Header) một cách có hiệu quả.
Mọi truyền thông trong IKE gồm các cặp thông báo:
một thông báo yêu cầu (request) và một thông báo trả lời

(response). Cặp thông báo này gọi là một “trao đổi -
exchange”. Trong IKEv2 có các kiểu trao đổi là:
IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA và
INFORMATION. Ta gọi các thông báo đầu tiên để thiết
lập một IKE_SA là trao đổi IKE_SA_INIT và IKE_AUTH.
Nhìn chung, sẽ có một trao đổi IKE_SA_INIT và một trao
đổi IKE_AUTH để tạo ra một IKE_SA và CHILD_SA đầu
tiên (tổng là 4 thông báo).
Hai kiểu trao đổi tiếp theo là CREATE_CHILD_SA
(để tạo một CHILD_SA) và INFORMATION (để xóa một
SA, thông báo lỗi, hoặc để duy trì). Một yêu cầu
INFORMATION mà không có nội dung (payload) (khác
với yêu cầu mà có payload rỗng được mã hóa) được sử
dụng để kiểm tra khả năng sống của các bên tham gia
(peer). Các trao đổi tiếp theo không được sử dụng đến khi
các trao đổi khởi đầu được hoàn thành.
14

2.2.2. Phase I: Trao đổi khởi tạo (IKE_SA_INIT và
IKE_AUTH)

2.2.2.1. Trao đổi IKE_SA_INIT
Initiator Responder

HDR, SAi1, KEi, Ni >
< HDR, SAr1, KEr, Nr, [CERTREQ]
2.2.2.2. Trao đổi IKE_AUTH
Khi hoàn thành trao đổi IKE_SA_INIT, mỗi bên có
thể sinh ra SKEYSEED, từ đó tất cả các khóa sẽ được sinh
ra cho IKE_SA. Mọi phần nội dung từ phần đầu của tất cả

các thông báo tiếp theo sẽ được mã hóa và được bảo vệ tính
toàn vẹn.
Xác thực đối với IKE_SA
Khi không sử dụng cơ chế xác thực mở rộng, các
bên tham gia trao đổi khóa xác thực lẫn nhau bằng cách
mỗi bên kí vào một khối dữ liệu (hoặc sử dụng MAC với
khóa chia sẻ trước).
Trường hợp sử dụng chữ kí số:
15

Đối với bên trả lời, sẽ kí lên các byte: từ byte đầu
tiên của trường SPI trong phần đầu (HDR) đến byte cuối
cùng trong phần nội dung của thông báo thứ 2. Nối với các
byte này là số Nonce của bên khởi tạo Ni (chỉ giá trị của số
nonce, không phải toàn bộ phần nội dung chứa tham số
nonce), và giá trị prf(SK_pr, IDr’), trong đó IDr’ là phần
nội dung ID của bên trả lời không bao gồm phần đầu.
2.2.3. Phase II: Trao đổi CREATE_CHILD_SA
Trao đổi này gồm một cặp yêu cầu/trả lời, và nó
được xem là tương ứng với giai đoạn 2 trong giao thức
IKEv1. Trao đổi này có thể được khởi tạo từ cả hai bên khi
IKE_SA hết hiệu lực sau khi các trao đổi khởi tạo được
hoàn thành. Yêu cầu của trao đổi CREATE_CHILD_SA
như sau:
Initiator Responder

HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} >
< HDR, SK {SA, Nr, [KEr], [TSi, TSr]}
2.2.4. Sinh tài liệu khóa

Tài liệu khóa sẽ luôn được lấy từ đầu ra của thuật
toán prf. Do kích thước của tài liệu khóa cần dùng có thể
lớn hơn kích thước đầu ra của thuật toán prf, nên sẽ phải sử
dụng prf lặp lại. Thuật ngữ prf+ dùng để mô tả hàm để tạo
ra một dãy giả ngẫu nhiên dựa trên đầu vào của prf như
sau: (kí hiệu | chỉ ra phép nối).
16

2.2.4.1. Sinh tài liệu khóa cho IKE_SA
2.2.4.2. Sinh tài liệu khóa cho CHILD_SAs
2.2.4.3. Thay đổi khóa của IKE_SAs bằng một trao
đổi CREATE_CHILD_SA
2.3. Một số so sánh về hai giao thức trao đổi khoá
IKEv1 và IKEv2
CHƯƠNG 3: ĐỀ XUẤT ỨNG DỤNG IKEv2
TRONG BẢO MẬT THÔNG TIN KINH TẾ XÃ
HỘI
3.1. Một số tính năng an toàn của giao thức trao đổi
khoá IKEv2 so với các giao thức trao đổi khoá
khác.
Cơ sở mật mã cho giao thức Trao đổi khóa IKE2 là
giao thức SIGMA được đưa ra trong [11]. Chính xác hơn,
SIGMA là cơ sở cho việc trao đổi khóa có xác thực dựa
trên chữ ký trong IKE nói chung – kiểu xác thực khóa công
khai thường được sử dụng nhất trong IKE, và là cơ sở cho
kiểu xác thực khóa công khai duy nhất trong IKEv2.
Đặc tính quan trong nhất của giao thức IKEv2 so với
các phiên bản giao thức trao đổi khóa khác là việc bảo vệ
định danh của các thực thể tham gia trong một phiên liên
lạc. Để thấy rõ điều này chúng ta xem xét việc so sánh giữa

giao thức này với các giao thức khác trong các phần tiếp
theo dưới đây.
17

3.1.1. Vấn đề bảo vệ định danh
Các giao thức trao đổi khóa đòi hỏi sự xác thực lẫn
nhau mạnh và do đó chúng phải được thiết kế đẻ truyền
định danh của mỗi người tham gia trong giao thức tới đối
tác phiên của nó. Điều này kéo theo các định danh phải
được truyền như là một phần của giao thức.
3.1.2. Các giao thức STS
3.1.2.1. BADH và tấn công thiếu sự ràng buộc định
danh: Một ví dụ về sự thúc đẩy
Giao thức này cung cấp một cách tự nhiên nhất để
xác thực việc trao đổi DH nhờ sử dụng các chữ ký số. Mỗi
người tham gia gửi giá trị DH đã được ký với khóa ký bí
mật của mình. Việc bao gồm cả giá trị DH của đối tác vào
dưới chữ ký được yêu cầu để chứng minh tính tươi mới của
chữ ký để tránh các tấn công lặp lại.
3.1.2.2. Giao thức STS cơ bản
Sau khi đã phát hiện ra tấn công gắn nhầm trên giao
thức DH được xác thực “tự nhiên” BADH, Diffie cùng các
cộng sự [12] đã thiết kế giao thức STS với ý định giải quyết
vấn đề này. Giao thức STS cơ bản là:
3.1.2.3. Hai biến thể của STS: Các chữ ký đã MAC và
Photuris
Cụ thể, trong biến thể STS này mỗi người tham gia
giao thức áp dụng chữ ký của họ trên các giá trị DH thêm
vào việc nối chữ ký đó với giá trị MAC áp dụng trên chữ
ký sử dụng khóa

s
K
.
A
B
x
g





, , ,SIG
s
y x y
B
K
g B g g





, ,SIG
s
y x
A
K
A g g
18

Từ các ví dụ trên ta thấy rằng thất bại trước tấn công
gắn nhầm về bản chất liên quan đến việc thiếu sự liên kết
khóa DH với các chữ ký. Một sự liên kết như vậy (ví dụ,
qua một giá trị MAC được tính trên chữ ký) cung cấp bằng
chứng là ai đó biết khóa phiên, nhưng không chứng thực
người đó là ai. Như chúng ta sẽ thấy ở phần sau, sự liên kết
thiết yếu cần đến ở đây được thực hiện giữa chữ ký và định
danh của người nhận (giao thức ISO), hoặc giữa khóa DH
và định danh của người gửi (giao thức IKEv2).
Giống như các biến thể đã trình bày trước, biến thể
này cũng là một sự minh họa về những điểm tinh vi trong
việc thiết kế một giao thức KE tốt. Biến thể này không cần
đến việc sử dụng hàm mã hóa hoặc hàm MAC; thay vào đó
nó cố gắng liên kết khóa DH với các chữ ký bằng việc bao
gồm khóa DH
xy
g
dưới chữ ký.
3.1.3. Giao thức ISO
Hạn chế của giao thức ISO trong việc cung cấp sự
bảo vệ định danh nảy sinh từ thực tế là trong giao thức mỗi
người tham gia cần biết định danh của đối tác trước khi đưa
ra chữ ký của mình. Điều này có nghĩa là không có người
tham gia giao thức nào (kể cả A hoặc B) có thể xác thực
người tham gia kia trước khi tiết lộ tên của chính họ cho
người tham gia đó biết. Điều này khiến cho cả hai định
danh đều mở đối với các tấn công chủ động.
3.1.4. Kết luận
Trong giao thức IKEv2 đã được trình bày trong

19

chương trước,
B
giữ chậm việc gửi định danh của mình và
thông tin xác thực đến thông báo thứ tư sau khi nó kiểm tra
định danh của
A
và kiểm tra xác thực trong thông báo thứ
ba, do đó IKEv2 có tính năng bảo vệ định danh đối với
người phúc đáp (thực thể B) trong phiên liên lạc, tính năng
này không hề có trong các giao thức vừa được trình bày ở
trên.
3.2. Một số ứng dụng IPSec dùng IKEv2
Dự án FreeS/WAN là dự án đầu tiên hoàn thành việc
thực hiện IPsec trong mã nguồn mở cụ thể là Linux. Nó bao
gồm một thành phần IPsec (KLIPS), kết hợp với trình quản
lý key chạy độc lập và rất nhiều shell scripts khác. Dự án
FreeS/WAN được bắt đầu vào tháng 3 năm 2004.
Openswan và strongSwan đã tiếp tục bước phát tiển
tiếp theo của dự án FreeS/WAN.
Dự án KAME cũng hoàn thành việc triển khai sử
dụng IPsec cho NetBSB, FreeBSB. Trình quản lý các khoá
được gọi là racoon. OpenBSB được tạo ra ISAKMP/IKE,
với tên đơn giản là isakmpd (nó cũng được triển khai trên
nhiều hệ thống, bao gồm cả hệ thống Linux).
3.3. Đề xuất sử dụng trong bảo mật thông tin kinh
tế xã hội.
Qua việc phân tích đặc tính ưu việt của giao thức
IKEv2 so với các giao thức trao đổi khóa trước nó, luân

văn đề xuất sử dụng giao thức trên cho các ứng dụng IPSec
20

sử dụng cho việc bảo mật thông tin trên mạng máy tính
trong lĩnh vực kinh tế xã hội. Tuy nhiên từng thành tố mật
mã (hay còn gọi là các nguyên thủy mật mã) cụ thể được sử
dụng để xây dựng nên giao thức cũng cần được đưa ra một
cách cụ thể mới có thể mô tả ở mức khả dụng đối với giao
thức.
Dưới đây luận văn xin đề xuất một số nguyên thủy
mật mã sử dụng cho giao thức IKEv2 như sau:
Chữ ký số được sử dụng trong bước 3 và bước 4 của
giao thức (SIG
i
và SIG
r
) chúng ta sử dụng lược đồ chữ ký
RSA-PSS đã được chuẩn hóa trong Tiêu chuẩn TCVN
7635 năm 2007 [19].
Hàm mã hóa trong bước thứ 3 và thứ 4 của giao thức
(sử dụng các khóa SK
_ei
và SK
_er
) là thuật toán mã hóa dữ
liệu AES với khóa 256 bít đã được chuẩn hóa trong tiêu
chuẩn TCVN 7635 năm 2007.
Hàm sinh mã xác thực thông báo trong các bước 3
và bước 4 sử dụng hàm sinh mã xác thực thông báo HMAC
dựa trên hàm băm SHA256.

Với các đề xuất trên chúng ta có thể mô tả lại lược
đồ trao đổi khóa IKEv2 như sau:




Msg1= (SPI
i
, g
x
, N
i
)
R I
Msg2= (SPI
i
, SPI
r
, g
y
, N
r
)

, , , ( 1|| || ( _ , '))
r i i r i
i
SPI SPI ID SIG Msg N prf SK pi ID

, , , ( 2 || || ( _ , '))

r r r i r
r
SPI SPI ID SIG Msg N prf SK pr ID
21



3.4. Thuật toán mã hoá dữ liệu AES256
Thuật toán mã hoá dữ liệu AES với các đặc trưng:
 Độ dài khối dữ liệu đầu vào, khối dữ liệu đầu ra là
128 bít.
 Độ dài khoá: 128/192/256 bít
 Số vòng phụ thuộc và độ dài khoá, độ dài khoá là
128 bít số vòng sẽ là 10, độ dài khoá 192 bít số vòng sẽ là
12, độ dài khoá là 256 bít số vòng sẽ là 14.
3.4.1. Các phép biến đổi, ký hiệu
3.4.2. Mở rộng khoá
3.4.3. Thuật toán mã hoá
Khi bắt đầu qui trình mã hoá, dữ liệu đầu vào được
copy vào State. Sau khi khởi tạo bổ sung Round Key, mảng
State được biến đổi theo các hàm gồm 10, 12 hoặc 14 vòng
(phụ thuộc vào độ dài khoá mã), trong đó vòng cuối cùng
có sự khác biệt với Nr – 1 vòng đầu tiên. Giá trị State cuối
cùng sẽ được copy vào chuỗi đầu ra.
3.4.4. Thuật toán giải mã
Qui trình mã hoá được trình bày trong mục trước có
thể được cài đặt theo thứ tự ngược lại để có qui trình giải
mã cho thuật toán AES. Các phép biến đổi được sử dụng
22

trong phép giải mã như InvShiftRows(), InvSubBytes(),
InvMixColumns() và AddRoundKey()
3.5. Lược đồ chữ ký RSA-PSS
3.5.1. Các nguyên thuỷ chuyển đổi dữ liệu
3.5.2. Các nguyên thuỷ mật mã
3.5.3. Lược đồ ký RSASSA-PSS (RSA Signature
Scheme with Appendix PSS)
3.5.3. Lược đồ ký RSASSA-PSS (RSA Signature
Scheme with Appendix PSS)
3.6. Hàm sinh mã xác thực thông báo
3.6.1. Một số ký hiệu, chữ viết tắt
3.6.2. Hàm HMAC
Thuật toán HMAC yêu cầu áp dụng hai lần hàm băm để
tính giá trị MAC. Hàm băm chúng tôi sử dụng ở đây là hàm
SHA256 đã được lựa chọn trong chương 3, bởi vậy yêu cầu
1
512
L  và là số nguyên dương bội của 8, L
2
= 256. Độ dài
k của khoá không nhỏ hơn 256 và nhỏ hơn hoặc bằng 512.
Thuật toán HMAC được thực hiện thông qua 4 bước: Mở
rộng khoá, thực thi băm, biến đổi đầu ra và chặt cụt.


23



KẾT LUẬN

IPSec cung cấp một cơ chế mạnh để xác thực và
toàn vẹn dữ liệu nhưng đảm bảo tính bí mật thông qua mã
hoá AH hoặc ESP. Bằng việc sử dụng các giao thức trao
đổi khoá IKEv1 và IKEv2 có thể xác thực người dùng và
thiết lập được các phiên liên lạc an toàn, tin cậy và bảo mật.
Phiên bản IKEv1 hoạt động dựa trên ba thành phần chính là
ISAKMP, Oakley và SKEME được chia làm hai giai đoạn
(sáu thông báo trong phase 1 và ba thông báo ở phase 2).
Trong khi đó IKEv2 được thiết kế ngay từ đầu theo
RFC4309 với cơ sở mật mã trao đổi khoá là giao thức
SIGMA. Chính xác hơn, SIGMA là cơ sở cho việc trao đổi
khóa có xác thực dựa trên chữ ký trong IKE nói chung –
kiểu xác thực khóa công khai thường được sử dụng nhất
trong IKE, và là cơ sở cho kiểu xác thực khóa công khai
duy nhất trong IKEv2. Đặc tính quan trong nhất của giao
thức IKEv2 so với các phiên bản giao thức trao đổi khóa
khác là việc bảo vệ định danh của các thực thể tham gia
trong một phiên liên lạc.

Bằng việc giữ chậm việc gửi định
danh của mình và thông tin xác thực đến thông báo thứ tư
sau khi nó kiểm tra định danh của bên khởi tạo và kiểm tra
xác thực trong thông báo thứ ba, do đó IKEv2 có tính năng
bảo vệ định danh đối với người phúc đáp trong phiên liên
lạc, tính năng này không hề có trong các giao thức trao đổi