Download as pdf or txt
Download as pdf or txt
You are on page 1of 78

ÐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ÐẠI HỌC BÁCH KHOA


KHOA ÐIỆN – ÐIỆN TỬ
BỘ MÔN VIỄN THÔNG

LUẬN VĂN TỐT NGHIỆP:

BẢO MẬT GET VPN TRÊN VPN-MPLS

GVHD: TS. NGUYỄN MINH HOÀNG


SVTH: NGUYỄN VĂN GẤM 40700596
LÊ THANH PHONG 40701789

TP.HCM, Tháng 1/2012

i
ĐẠI HỌC QUỐC GIA TP.HCM CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
TRƯỜNG ĐH BÁCH KHOA Độc Lập – Tự Do – Hạnh Phúc
 
Số:______/BKĐT

Khoa: Điện – Điện tử NHIỆM VỤ LUẬN VĂN TỐT NGHIỆP


Bộ Môn: Viễn Thông

Họ và tên SV: Nguyễn Văn Gấm MSSV: 40700596


Lê Thanh Phong MSSV: 40701789
Ngành: Điện Tử-Viễn Thông
1. Đầu đề luận văn:
___________________________________________________________________________
___________________________________________________________________________
2. Nhiệm vụ ( yêu cầu về nội dung và số liệu ban đầu):
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
3. Ngày giao nhiệm vụ luận văn: ________________________________________________
4. Ngày hoàn thành nhiệm vụ: ________________________________________________
5. Họ và tên người hướng dẫn: Phần hướng dẫn
1/ __________________________ ____________________________
2/ __________________________ ____________________________

Nội dung và yêu cầu LVTN đã được thông qua Bộ Môn.


Ngày tháng 1 năm 2012
CHỦ NHIỆM BỘ MÔN NGƯỜI HƯỚNG DẪN
(Ký và ghi rõ họ tên) (Ký và ghi rõ họ tên)

PHẦN DÀNH CHO KHOA, BỘ MÔN:


Người duyệt (chấm sơ bộ): ______________________
Đơn vị: ______________________________________
Ngày bảo vệ: __________________________________
Điểm tổng kết: ________________________________
Nơi lưu trữ luận văn: ___________________________

ii
TRƯỜNG ĐẠI HỌC BÁCH KHOA CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM

KHOA ĐIỆN – ĐIỆN TỬ Độc Lập - Tự Do - Hạnh Phúc


---------------------------
Ngày tháng 1 năm 2012
PHIẾU CHẤM BẢO VỆ LVTN
(Dành cho người hướng dẫn/phản biện)

1. Họ và tên SV: Nguyễn Văn Gấm MSSV: 40700596


Lê Thanh Phong MSSV: 40701789
Ngành: Điện Tử-Viễn Thông
2. Đề tài: _____________________________________________________________________
3. Họ tên người hướng dẫn/phản biện: ______________________________________________
4. Tổng quát về thuyết minh:
Số trang ________ Số chương _________
Số bảng số liệu ________ Số hình vẽ _________
Số tài liệu tham khảo ________ Phần mềm tính toán _________
Hiện vật (sản phẩm) ________
5. Tổng quát về các bản vẽ:
- Số bản vẽ: bản A1: bản A2: khổ khác:
- Số bản vẽ vẽ tay: Số bản vẽ trên máy tính:
6. Những ưu điểm chính của LVTN: _______________________________________________
___________________________________________________________________________
___________________________________________________________________________
7. Những thiếu sót chính của LVTN: _______________________________________________
___________________________________________________________________________
___________________________________________________________________________
8. Đề nghị: Được bảo vệ  Bổ sung để bảo vệ  Không được bảo vệ 
9. 3 câu hỏi SV phải trả lời trước hội đồng:
a. _______________________________________________________________________
_______________________________________________________________________
b. _______________________________________________________________________
_______________________________________________________________________
c. _______________________________________________________________________
_______________________________________________________________________

10. Đánh giá chung (bằng chữ: giỏi, khá, TB): Điểm _____ /10
Ký tên (ghi rõ họ tên)

iii
TRƯỜNG ĐẠI HỌC BÁCH KHOA CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM

KHOA ĐIỆN – ĐIỆN TỬ Độc Lập - Tự Do - Hạnh Phúc


---------------------------
Ngày tháng 1 năm 2012
PHIẾU CHẤM BẢO VỆ LVTN
(Dành cho người hướng dẫn/phản biện)

1. Họ và tên SV: Nguyễn Văn Gấm MSSV: 40700596


Lê Thanh Phong MSSV: 40701789
Ngành: Điện Tử-Viễn Thông
2. Đề tài: _____________________________________________________________________
3. Họ tên người hướng dẫn/phản biện: ______________________________________________
4. Tổng quát về thuyết minh:
Số trang ________ Số chương _________
Số bảng số liệu ________ Số hình vẽ _________
Số tài liệu tham khảo ________ Phần mềm tính toán _________
Hiện vật (sản phẩm) ________
5. Tổng quát về các bản vẽ:
- Số bản vẽ: bản A1: bản A2: khổ khác:
- Số bản vẽ vẽ tay: Số bản vẽ trên máy tính:
6. Những ưu điểm chính của LVTN: _______________________________________________
___________________________________________________________________________
___________________________________________________________________________
7. Những thiếu sót chính của LVTN: _______________________________________________
___________________________________________________________________________
___________________________________________________________________________
8. Đề nghị: Được bảo vệ  Bổ sung để bảo vệ  Không được bảo vệ 
9. 3 câu hỏi SV phải trả lời trước hội đồng:
a. _______________________________________________________________________
_______________________________________________________________________
b. _______________________________________________________________________
_______________________________________________________________________
c. _______________________________________________________________________
_______________________________________________________________________
10. Đánh giá chung (bằng chữ: giỏi, khá, TB): Điểm _____ /10
Ký tên (ghi rõ họ tên)

iv
LỜI CẢM ƠN

Chúng em xin gửi đến Thầy Nguyễn Minh Hoàng lời cảm ơn chân thành với sự
trân trọng và lòng biết ơn sâu sắc. Thầy đã hướng dẫn, truyền đạt kinh nghiệm, kiến thức,
cách tư duy và làm việc khoa học trong suốt thời gian thực tập tốt nghiệp và luận văn tốt
nghiệp.

Chúng em xin chân thành cảm ơn các Thầy các Cô trường Đại học Bách khoa
Tp.Hồ Chí Minh, đặc biệt là các Thầy Cô khoa Điện – Điện tử và các Thầy Cô trong bộ
môn Viễn Thông đã hết lòng dạy dỗ và truyền đạt những kiến thức quý báu, giúp chúng
em có một nền tảng kiến thức vững chắc. Ngoài ra em còn được rèn luyện một tinh thần
học tập và làm việc. Đây là những yếu tố cơ bản giúp em nhanh chóng hoà nhập với môi
trường làm việc sau khi ra trường.

Xin cảm ơn Ba Mẹ và cả gia đình đã tạo mọi điều kiện tốt nhất trong cuộc sống và
trong quá trình học tập của con.

Xin cảm ơn tất cả Bạn bè đã luôn chia sẻ, động viên trong những năm tháng của
quãng đời sinh viên.

Tp. Hồ Chí Minh, ngày tháng năm

Sinh viên thực hiện

Nguyễn Văn Gấm

Lê Thanh Phong

v
TÓM TẮT ĐỀ TÀI LUẬN VĂN

Ngày này, network cần phải hỗ trợ tất cả các hình thức truyền thông bao gồm data,
voice, video để nâng cao giao tiếp và trao đổi thông tin với chi phí điều hành thấp hơn.
Trong khi rủi ro an ninh ngày càng tăng.

Group Encrypted Transport (GET) VPN là phương pháp mới cho việc mã hóa, đơn
giản việc cung cấp và quản lý an toàn của VPN.

Mục tiêu chính của đề tài luận văn là ứng dụng bảo mật GET VPN trên VPN-
MPLS kết nối tất cả các chi nhánh và trụ sở của doanh nghiệp đảm bảo tính bảo mật cao,
đặc biệt là các giao dịch yêu cầu tính an toàn như giao dịch thương mại.

Đề tài gồm các chương sau:

Chương 1: Giới thiệu đề tài

Chương 2: Tìm hiểu về VPN-MPLS.

Chương 3: Các phương pháp mã hóa và cấu trúc PKI

Chương 4: Giải pháp GET VPN

Chương 5: Cấu hình GET VPN.

Chương 6: Tổng kết và đánh giá kết quả.

vi
MỤC LỤC

LỜI CẢM ƠN ........................................................................................................... v


TÓM TẮT ĐỀ TÀI LUẬN VĂN ........................................................................... vi
MỤC LỤC ............................................................................................................... vii
CÁC THUẬT NGỮ VIẾT TẮT .............................................................................. x
DANH MỤC HÌNH ...............................................................................................xiii
Chƣơng 1: Giới thiệu đề tài ..................................................................................... 1
1.1Giới thiệu về VPN. ....................................................................................................... 1
1.2 Giới thiệu ưu điểm VPN-MPLS. ................................................................................ 2
1.3 Giới thiệu GET VPN ................................................................................................... 3
Chƣơng 2: Tìm hiểu VPN-MPLS ........................................................................... 4
2.1 Cấu trúc VPN-MPLS. ................................................................................................. 4
2.1.1 Cấu trúc bảng định tuyến trên PE ......................................................................... 5
2.1.2 VRF (Virtual Routing and Forwarding Table) ..................................................... 6
2.1.3 RD (Route Distinguisher) ..................................................................................... 6
2.1.4 RT (Route Target)................................................................................................. 8
2.2 Định tuyến trong VPN-MPLS..................................................................................... 9
2.3 Chuyển tiếp gói tin trong VPN-MPLS ...................................................................... 10
2.4 Phần mềm hổ trợ và kết quả mô phỏng VPN-MPLS ................................................ 11
2.4.1Chương trình mô phỏng GNS3 ............................................................................ 11
2.4.2 Wireshark ............................................................................................................ 12
2.4.3 Kết quả mô phỏng ............................................................................................... 13
Chƣơng 3: Các phƣơng pháp mã hóa và Cấu trúc PKI ..................................... 16
3.1 Các giải thuật mã hóa. ............................................................................................... 16
3.1.1 Giải thuật mã hóa đối xứng. ............................................................................... 16
3.1.2 Mã hóa bất đối xứng. .......................................................................................... 17
3.1.3 Giải thuật Hash ................................................................................................... 19

vii
3.2 Cấu trúc PKI .............................................................................................................. 20
3.2.1 Thành phần cơ bản của PKI ................................................................................ 20
3.2.1.1 Chứng thực ................................................................................................... 20
3.2.1.2 Trung tâm chứng thực CA (Certification Authority) ................................... 21
3.2.1.3 Trung tâm chứng thực phụ Sub-CA (Subordinate CA) ............................... 22
3.2.1.4 Các user và thiết bị cuối. .............................................................................. 22
3.2.2 Quá trình đăng ký PKI. ....................................................................................... 23
3.2.2.1 Enrollment. ................................................................................................... 23
3.2.2.2 Hết hạn và cấp mới chứng thực .................................................................... 26
3.2.2.3 Việc kiểm tra chứng thực. ............................................................................ 26
3.2.3 Kiến trúc hệ thống CA phân cấp......................................................................... 28
3.2.4 Mô phỏng hệ thống CA. ..................................................................................... 31
Chƣơng 4: Giải pháp GET VPN ........................................................................... 34
4.1 Ưu điểm GET VPN ................................................................................................... 34
4.2 Tổng quan về GET VPN ........................................................................................... 34
4.2.1 GDOI (RFC 3547) .............................................................................................. 35
4.2.2 Key Server (KS) ................................................................................................. 36
4.2.3 COOP Key Server............................................................................................... 37
4.2.4 Group Member (GM) ......................................................................................... 38
4.2.5 IP Tunnel Header Preservation ........................................................................... 39
4.2.6 Group security association .................................................................................. 41
4.2.7 Quá trình Rekey .................................................................................................. 41
4.2.8 Time-based anti-replay ....................................................................................... 42
4.3 Hoạt động của GET VPN.......................................................................................... 44
4.3.1 Hoạt động IKE và đóng gói ESP ........................................................................ 44
4.3.2 Quá trình hoạt động của GET VPN .................................................................... 48
Chƣơng 5: Cấu hình GET VPN ............................................................................ 51
5.1 Phương pháp chứng thực. ......................................................................................... 51

viii
5.2 Cấu hình trên KS. ...................................................................................................... 53
5.2.1Cấu hình IKE phase 1. ......................................................................................... 53
5.2.2 Cấu hình các thông số IPsec ............................................................................... 54
5.2.3 Cấu hình GDOI Group........................................................................................ 55
5.2.4 Cấu hình Access List Policies............................................................................. 56
5.3 Cấu hình trên GM...................................................................................................... 56
5.3.1 Cấu hình IKE Phase 1. ........................................................................................ 56
5.3.2 Cấu hình GDOI Group........................................................................................ 56
5.3.3 Cấu hình Crypto Map. ........................................................................................ 57
5.3.4 Kích hoạt GET VPN. .......................................................................................... 57
5.4 Cấu hình COOP KS .................................................................................................. 57
5.4.1 Exporting and Importing RSA Keys .................................................................. 57
5.4.2 Cấu hình Redundancy ......................................................................................... 58
5.5 Cấu hình CA Server .................................................................................................. 58
5.6 Kết quả triển khai ..................................................................................................... 59
Chƣơng 6: Tổng kết và đánh giá kết quả............................................................. 62
6.1 Đánh giá về bảo mật GET VPN. ............................................................................... 62
6.2 Hướng phát triển luận văn. ........................................................................................ 62
TÀI LIỆU THAM KHẢO. .................................................................................... 63

ix
CÁC THUẬT NGỮ VIẾT TẮT

AAA Authentication, Authorization, and Accouting

ACK Acknowledgement

ACL Access Control List

AES Advanced Encryption Standard

BGP Border Gateway Protocol

C Customer

CA Certification Authority

CE Customer Edge

CRL Certificate Revocation List

DES Data Encryption Standard

3DES Triple Data Encryption Standard

DSA Digital Signature Algorithm

eBGP external Border Gateway Protocol

EIGRP Enhanced Interior Gateway Routing Protocol

ESP Encapsulation Security Payload

GDOI Group Domain of Interpretation

GET Group Encrypted Transport

GM Group Member

IGP Interior Gateway Protocol

IKE Internet Key Exchange

IP Internet Protocol

IPv4 Internet Protocol version 4

x
IPSec Internet Protocol Security

ISAKMP Internet Security-Association and


Key Management Protocol

KEK Key Encryption Key

KS Key Server

MD Message Digest

MP-BGP Multiprotocol-Border Gateway Protocol

MPLS Multiprotocol Label Switching

NTP Network Time Protocol

OCSP Certificate Status Protocol

OSPF Open Shortest Path First

PCKS Public-key Crytography Standards

P Provider

PE Provider Edge

PKI Public Key Infrastructure

PSKs Pre-shared Keys

RD Route Distinguisher

RIPv2 Routing Information Protocol version 2

RSA Rivest, Shamir, Adleman

RT Route Target

SA Security Association

SCEP Simple Certificate Enrollment Protocol

SHA Secure Hash

SP Service Provider

xi
TBAR Time Based Anti-Replay

TEK Traffic Encryption Key

VPN Virtual Private Network

VPNv4 Virtual Private Network version 4

VRF Virtual Routing and Forwarding table

xii
DANH MỤC HÌNH
Trang

Hình 1.1 Mô hình hệ thống VPN......................................................................................... 1

Hình 1.2 Mô hình VPN-MPLS ............................................................................................ 2

Hình 1.3 Mô hình GET VPN [6] ......................................................................................... 3

Hình 2.1 Mô hình VPN-MPLS [2] ...................................................................................... 4

Hình 2.2 Cấu trúc bảng định tuyến router PE [2]. ............................................................... 5

Hình 2.3 Chức năng của VRF [2] ........................................................................................ 6

Hình 2.4 Ví dụ về RD [2]. ................................................................................................... 7

Hình 2.5 Ví dụ về RT [2]..................................................................................................... 8

Hình 2.6 Mô hình định tuyến trong VPN-MPLS [2]. ......................................................... 9

Hình 2.7 Chuyển tiếp gói tin trong MPLS VPN [2]. ......................................................... 10

Hình 2.8 Giao diện chương trình GNS3. ........................................................................... 11

Hình 2.9 Giao diện phần mêm Wireshark. ........................................................................ 12

Hình 2.10 Mô hình cơ bản VPN-MPLS. ........................................................................... 13

Hình 2.11 Kết quả kết nối giữa 2 router. ........................................................................... 15

Hình 3.1 Mã hóa key đối xứng [4]. ................................................................................... 16

Hình 3.2 Xác thực sử dụng Key bất đối xứng [3]. ............................................................ 17

Hình 3.3 Mã hóa sử dụng Key đối xứng [3]...................................................................... 18

Hình 3.4 Giải thuật Hash [4]. ............................................................................................ 19

Hình 3.5 Cấu trúc chứng thực X.509 [3]. .......................................................................... 21

Hình 3.6 Quá trình đăng kí chứng thực [5]. ...................................................................... 24

Hình 3.7 Cấu trúc hệ thống CA phẳng [3]......................................................................... 28

Hình 3.8 Cấu trúc hệ thống CA phân cấp [3]. ................................................................... 29

xiii
Hình 3.9 Mô hình mô phỏng CA hai cấp. ......................................................................... 32

Hình 3.10 Server chứng thực trên sub-ca. ......................................................................... 32

Hình 3.11 Nội dung chứng thực trên Client. ..................................................................... 33

Hình 4.1 Mô hình GET VPN [6]. ...................................................................................... 34

Hình 4.2 Hoạt động giao thức GDOI [6]. .......................................................................... 35

Hình 4.3 Group keys trong GET VPN [6]. ........................................................................ 36

Hình 4.4 Mô hình phân phối keys của Key Server [6]. ..................................................... 37

Hình 4.5 Mô hình COOP Server [6]. ................................................................................. 38

Hình 4.6 Mô hình hoạt động Group Keys trên GMs [6]. .................................................. 39

Hình 4.7 Tunnel header preservation [1]. .......................................................................... 40

Hình 4.8 So sánh tunnel header IPsec với GET [7]. ......................................................... 40

Hình 4.9 Thời gian re-register ........................................................................................... 41

Hình 4.10 Time-based anti-replay [1]. .............................................................................. 43

Hình 4.11 Đóng gói không sử dụng Time-Based Anti-Replay [6]. .................................. 43

Hình 4.12 Đóng gói sử dụng Time-Based Anti-Replay [6]. ............................................. 43

Hình 4.13 Trao đổi IKE Main mode [3]. ........................................................................... 44

Hình 4.14 Phase 1 sử dụng PSKs [3]. ............................................................................... 45

Hình 4.15 Phase 1 sử dụng PKI [3]. .................................................................................. 46

Hình 4.16 Thỏa thuận IKE Quick mode [3]. ..................................................................... 47

Hình 4.17 Đóng gói ESP trong GET VPN [6]. ................................................................. 47

Hình 4.18 GMs đăng kí với KS [6]. .................................................................................. 48

Hình 4.19 Trao đổi dữ liệu [6]........................................................................................... 48

Hình 4.20 Giải mã thông tin nhận được trên GM [6]. ....................................................... 49

xiv
Hình 4.21 Rekey [6]. ......................................................................................................... 50

Hình 5.1 Mô hình GETVPN sử dụng PSKs. ..................................................................... 51

Hình 5.2 Mô hình GETVPN sử dụng PKI. ....................................................................... 52

Hình 5.3 Gói tin đăng kí của GMs với KS. ....................................................................... 59

Hình 5.4 Gói tin được mã hóa. .......................................................................................... 59

Hình 5.5 Chi tiết gói tin qua mạng core. ........................................................................... 60

Hình 5.6 Thông tin về Group và chính sách SA. .............................................................. 60

Hình 5.7 Thông tin về GDOI Group khi KS xảy ra sự cố. ................................................ 61

xv
Chương 1: Giới thiệu đề tài

Chƣơng 1: Giới thiệu đề tài

1.1Giới thiệu về VPN.


VPN là mạng riêng ảo cung cấp một phương thức giao tiếp an toàn giữa các mạng
riêng dựa trên hạng tầng mạng công cộng (thường là Internet), thường được dùng để kết
nối các văn phòng chi nhánh hoặc nguời dùng từ xa với trụ sở chính. Thay vì phải dùng
kết nối phức tạp như đường dây thuê bao số hoặc thuê đường truyền kênh riêng (leased
line).

Hình 1.1 Mô hình hệ thống VPN

Có 2 loại phổ biến hiện này là: VPN truy cập từ xa (Remote Access VPN) và VPN
điểm-nối-điểm (site-to-site). VPN đáp ứng nhu cầu về kết nối an toàn, tin cậy và nhanh
chóng.

Lịch sử phát triển của VPN: Cuối những năm 1990 máy tính nối mạng kết nối
mạng thông qua đường đường dây thuê (leased line) phức tạp và tốn nhiều chi phí. VPN
ra đời và giải quyết được vấn đề đó. Ngoài ra đáp ứng được yêu cầu về an toàn, tin cậy và
nhanh chóng dựa trên hạ tầng mạng công cộng nên VPN không ngừng cải tiến và phát
triển. Trong đó có VPN-MPLS là công nghệ được khai thác rộng rãi.

1
Chương 1: Giới thiệu đề tài

1.2 Giới thiệu ƣu điểm VPN-MPLS.


Không giống như các mạng VPN truyền thống, các mạng VPN-MPLS không sử
dụng hoạt động đóng gói và mã hóa gói tin để đạt được mức độ bảo mật cao. VPN-MPLS
sử dụng bảng chuyển tiếp và các nhãn “tags” để tạo nên tính bảo mật cho mạng VPN.
Kiến trúc mạng loại này sử dụng các tuyến mạng xác định để phân phối các dịch vụ VPN,
và các cơ chế xử lý thông minh của VPN-MPLS lúc này nằm hoàn toàn trong phần lõi
của mạng.

Hình 1.2 Mô hình VPN-MPLS

Một trong những ưu điểm lớn nhất của các VPN-MPLS là không đòi hỏi các thiết
bị CE thông minh bởi vì toàn bộ các chức năng VPN được thực hiện ở phía trong mạng
lõi của nhà cung cấp dịch vụ và hoàn toàn “trong suốt” đối với các CE. Các CE không đòi
hỏi chức năng VPN và hỗ trợ IPSec. điều này có nghĩa là khách hàng không phải chi phí
quá cao cho các thiết bị CE.

Trễ trong mạng được giữ ở mức thấp nhất vì các gói tin lưu chuyển trong mạng
không phải thông qua các hoạt động như đóng gói và mã hóa. Sở dĩ không cần chức năng
mã hóa là vì MPLS VPN tạo nên một mạng riêng. Phương pháp bảo mật này gần giống
như bảo mật trong mạng Frame Relay. Thậm chí trễ trong VPN-MPLS còn thấp hơn là
trong mạng MPLS IP sử dụng chuyển mạch nhãn.

Hoạt động khai thác và bảo dưỡng cũng đơn giản hơn trong mạng VPN-MPLS.
Hoạt động này chỉ cần thực hiện tại các thiết bị bên trong mạng core mà không cần phải
tiếp xúc đến các CE. Một khi một site đã được cấu hình xong, ta không cần đụng chạm
đến nó nữa cho dù nếu muốn thêm một site mới vào mạng vì những thay đổi về cấu hình
lúc này chỉ cần thực hiện tại PE mà nó nối tới.

2
Chương 1: Giới thiệu đề tài

Vấn đề bảo mật thậm chí còn đơn giản hơn nhiều khi triển khai trong các mạng
VPN-MPLS vì một VPN khép kín bản thân nó đã đạt được sự an toàn thông tin do không
có kết nối với mạng Internet công cộng. Nếu có nhu cầu truy nhập Internet, một tuyến sẽ
được thiết lập để cung cấp khả năng truy nhập. Lúc này, một firewall sẽ được sử dụng
trên tuyến này để đảm bảo một kết nối bảo mật cho toàn bộ mạng VPN.

1.3 Giới thiệu GET VPN


Với công nghệ VPN-MPLS đã có thể tách ròi mạng của doanh nghiệp ra khỏi
mạng internet công cộng, tuy nhiên những ứng dụng đòi hỏi tính bảo mật cao như trong
giao dịch thương mại thì phải đảm bảo sự an toàn và tin cậy.

Tuy nhiên việc thiết lập một kênh truyền riêng cho một doanh nghiệp có số lượng chi
nhánh lớn thì IPSecVPN chưa đáp ứng được vì chỉ hỗ trợ kết nối điểm-điểm.

Với IPSec VPN thì khi trao đổi dữ liệu với một điểm cần thiết lập một đường hầm bảo
mật. Trong mô hình hoàn chỉnh có N điểm kết nối thì số kết nối cần thiết là N(N+1)/2,
gây khó khăn trong việc quản lý và mở rộng.

GET VPN ra đời để đáp ứng nhu cầu trên.

Hình 1.3 Mô hình GET VPN [6]

3
Chương 2: Tìm hiểu về VPN-MPLS

Chƣơng 2: Tìm hiểu VPN-MPLS

2.1 Cấu trúc VPN-MPLS.


Một mô hình MPLS VPN gồm hai phần riêng biệt. Một phần khách hàng quản lý
và phần điều khiển của nhà cung cấp (SP). Mạng khách hàng quản lý gồm các router C và
CE, mạng của nhà cung cấp gồm các router P và PE.

Hình 2.1 Mô hình VPN-MPLS [2]

CE là bộ định tuyến được kết nối trực tiếp với PE tại lớp 3, bộ định tuyến của
khách hàng C không kết nối trực tiếp với PE. Bộ định tuyến CE không cần thiết phải chạy
MPLS bởi vì cả CE và PE đều tương tác ở lớp 3, giữa chúng phải có một giao thức định
tuyến (hoặc định tuyến tĩnh).

Bộ định tuyến PE là bộ định tuyến biên của nhà cung cấp, bộ PE kết nối trực tiếp
với bộ định tuyến biên CE của khách hàng tại lớp 3. Bộ định tuyến P là bộ định tuyến
không kết nối trực tiếp với bộ định tuyến của khách hàng. Trong khi thực hiện, cả hai bộ
định tuyến P và PE đều chạy MPLS. Điều này có nghĩa là chúng phải có khả năng phân
phối nhãn giữa chúng và chuyển tiếp gói được gán nhãn.

4
Chương 2: Tìm hiểu về VPN-MPLS

2.1.1 Cấu trúc bảng định tuyến trên PE

Trong mô hình VPN-MPLS, router PE phân biệt các khách hàng bằng VRF. Tuy
nhiên, thông tin này cần được mang theo giữa các router PE để cho phép truyền dữ liệu
giữa các site khách hàng qua MPLS VPN backbone.

Bảng định tuyến trên router PE gồm 2 phần:


 Bảng VRF cho từng khách hàng: nhận thông tin định tuyến của từng khách hàng,
sau đó đổi thành địa chỉ VPNv4 riêng biệt cho mỗi khách hàng.
 Bảng định tuyến chung (Global IP): cập nhật và quảng bá định tuyến đến các
router P trong mạng SP.

Hình 2.2 Cấu trúc bảng định tuyến router PE [2].

5
Chương 2: Tìm hiểu về VPN-MPLS

2.1.2 VRF (Virtual Routing and Forwarding Table).


VRF là bảng định tuyến và chuyển tiếp ảo. Cấu trúc dữ liệu kết nối với VRF như
bảng định tuyến IP, bảng chuyển tiếp CEF, chính sách và giao thức định tuyến, một số
cổng vật lý hay cổng giao tiếp sử dụng VRF, RD và chính sách xuất nhập định tuyến đích
(Export/Import RT).
Khi router PE nhận định tuyến IPv4 từ router CE, bảng VRF trên router PE sẽ
chuyển định tuyến IPv4 thành định tuyến VPNv4 bằng cách thêm một số thuộc tính như
RD, RT,...

Hình 2.3 Chức năng của VRF [2]

Hiện tại Cisco IOS hỗ trợ RIPv2, EIGRP, BGPv4 và OSPFv2 được dùng cho VRF
để trao đổi thông tin định tuyến giữa CE và PE.

2.1.3 RD (Route Distinguisher).


Là một định danh 64bits duy nhất, thêm vào trước 32bits địa chỉ tuyến của khách
hàng (IPv4) từ router CE tạo thành địa chỉ 96bits duy nhất (VPNv4) có thể được chuyển
vận giữa các router PE trong miền MPLS. Nhiệm vụ của RD là đảm bảo mỗi khách hàng
trên router CE có một địa chỉ VPNv4 duy nhất.

Địa chỉ VPNv4 trao đổi giữa các router PE trong mạng nhà cung cấp. RD có thể có
hai định dạng: dạng địa chỉ IP hoặc chỉ số AS. RD được sử dụng để tránh trường hợp
tuyến IPv4 của một khách hàng trùng với tuyến của một khách hàng khác. Nếu tiền tố
IPv4 10.1.1.0/24 và RD 1:1, tiền tố VPNv4 sẽ là 1:1:10.1.1.0/24.

6
Chương 2: Tìm hiểu về VPN-MPLS

Quá trình hình thành và sử dụng RD trên router PE.

 Router CE cập nhật định tuyến IPv4 đến router PE.


 PE thêm 64bits vào trước địa chỉ IPv4 thành địa chỉ VPNv4.
 Thông qua các phiên MP-BGP với các router PE khác, địa chỉ VPNv4 được gửi đi
trong bản tin cập nhật MP-BGP.

Quá trình nhận và gỡ bỏ RD.

 Router PE sau khi nhận địa chỉ VPNv4 sẽ gỡ bỏ RD.


 Địa chỉ IPv4 ở trên được chuyển tiếp đến các router CE khác trong bảng định
tuyến.

Hình 2.4 Ví dụ về RD [2].

7
Chương 2: Tìm hiểu về VPN-MPLS

2.1.4 RT (Route Target)


Trong ví dụ về RD, để đảm bảo Customer A site 1 và site 2 trao đổi với nhau qua
router PE mà không có sự nhầm lẫn giữa Customer A và Customer B thì Cisco đã đưa ra
khái niệm RT để giải quyết. RT được dùng để phân biệt và xác định các khách hàng cùng
nhóm hay khác nhóm VPN, nếu cùng nhóm thì có chung RT.

Hoạt động RT:

 Khi VRF chuyển định tuyến khách hàng thành định tuyến VPNv4, RT được thêm
vào cuối định tuyến VPNv4.
 RT kể trên được gọi là import RT, xác định mối quan hệ của các khách hàng.
 Khi định tuyến VPNv4 được chuyển đến router PE khác. Router PE này dựa vào
import RT để chọn ra export RT phù hợp.
 Trên router PE có thể có nhiều VRF, mỗi VRF sẽ có một export/import RT khác
nhau.

Hình 2.5 Ví dụ về RT [2].

8
Chương 2: Tìm hiểu về VPN-MPLS

2.2 Định tuyến trong VPN-MPLS.


Ưu thế của mô hình VPN-MPLS so với các công nghệ VPN khác là tối ưu về mặt
định tuyến. Do đó khi thiết kê mô hình VPN-MPLS chúng ta cần đảm bảo một số yêu cầu
về định tuyến:
 Router CE không cần biết về MPLS VPN như VPNv4, RD, RT.
 Router PE vận chuyển thông tin định tuyến VPNv4 của khách hàng đến các router
PE khác trong mạng SP.
 Router P có nhiệm vụ mở rộng mô hình mạng lõi MPLS VPN nên không vận
chuyển định tuyến VPNv4.

Hình 2.6 Mô hình định tuyến trong VPN-MPLS [2].

Để giải quyết yêu cầu về sử dụng giao thức định tuyến trong MPLS VPN, chúng ta lựa
chọn một số giao thức định tuyến thích hợp:

 Router CE: sử dụng một số giao thức định tuyến như OSPF, IGP, RIPv2, eBGP
hay định tuyến tĩnh để trao đổi thông tin với router PE thông qua bảng định tuyến
VRF.
 Router PE: sử dụng một số giao thức định tuyến nội như OSPF, RIPv2,..để kết nối
với các router P trong mạng nhà cung cấp. Sử dụng MP-BGP để trao đổi thông tin
trực tiếp với các router PE.
 Router P: sử dụng định tuyến nội như OSPF, EIGRP, RIPv2 để kết nối các router P
trong mạng. Phải cấu hình các router P sử dụng MPLS.

9
Chương 2: Tìm hiểu về VPN-MPLS

2.3 Chuyển tiếp gói tin trong VPN-MPLS

Router PE nhận cập nhật định tuyến IPv4 từ router CE qua giao thức cổng trong (IGP)
hoặc eBGP (external BGP), sau đó thông tin định tuyến IPv4 được đặt vào bảng định tuyến VRF.

Định tuyến này (IPv4) được nối với RD được chỉ định bởi VRF, chúng trở thành định
tuyến VPNv4 và thêm vào RTs. Sau đó router PE xuất định tuyến này từ bảng VRF vào MP-BGP
và chuyển đến các router PE với nhãn MPLS và RTs.

Trên router PE: RTs chỉ ra VRF nào cùng nhóm VPN, những định tuyến VPNv4 được
tách RD và đưa vào bảng định tuyến VRF như định tuyến IPv4.. Định tuyến IPv4 đưa tới bộ định
tuyến CE qua giao thức IGP hoặc eBGP từ bảng VRF trên router PE.

Hình 2.7 Chuyển tiếp gói tin trong MPLS VPN [2].

10
Chương 2: Tìm hiểu về VPN-MPLS

2.4 Phần mềm hổ trợ và kết quả mô phỏng VPN-MPLS.

2.4.1Chƣơng trình mô phỏng GNS3.

Là một chương trình giả lập mạng có giao diện đồ họa (graphical network
simulator) cho phép dễ dàng thiết kế các mô hình mạng và sau đó chạy giả lập trên chúng.
GNS3 dựa trên Dynamips và một phần Dynagen. Dynamips là một chương trình mô
phỏng router Cisco sử dụng các IOS image. Dynagen là một giao diện hỗ trợ Dynamips
cho việc cấu hình.
GNS3 hỗ trợ cho Windows, Linux, Mac OSX...

Hình 2.8 Giao diện chương trình GNS3.

11
Chương 2: Tìm hiểu về VPN-MPLS

2.4.2 Wireshark.

Là phần mềm quan trọng cho việc phân tích các các giao thức mạng, hỗ trợ việc
bắt gói và phân tích gói tin hiệu quả, phát triển mạnh nhờ sự đóng góp của các chuyên gia
mạng trên toàn cầu. Wireshark hỗ trợ nhiều hàng trăm giao thức khác nhau và được phát
triển trên mã nguồn mở, là công cụ hỗ trợ cho việc giám sát hệ thống.

Hình 2.9 Giao diện phần mêm Wireshark.

12
Chương 2: Tìm hiểu về VPN-MPLS

2.4.3 Kết quả mô phỏng

Hình 2.10 Mô hình cơ bản VPN-MPLS.

 Cấu hình trên router CE1


interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface Serial1/0
ip address 192.168.12.1 255.255.255.0
router ospf 2
network 1.1.1.1 0.0.0.0 area 2
network 192.168.12.0 0.0.0.255 area 2

 Cấu hình trên router PE1


ip vrf A
rd 1:100
route-target export 1:100
route-target import 1:100
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface Serial1/0
ip vrf forwarding A
ip address 192.168.12.2 255.255.255.0
interface Serial1/1
ip address 192.168.25.2 255.255.255.0
mpls ip

13
Chương 2: Tìm hiểu về VPN-MPLS

router ospf 2 vrf A


router-id 192.168.12.2
redistribute bgp 1 subnets
network 192.168.12.0 0.0.0.255 area 2
router ospf 1
network 2.2.2.2 0.0.0.0 area 1
network 192.168.25.0 0.0.0.255 area 1
router bgp 1
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
address-family ipv4 vrf A
redistribute connected
redistribute ospf 2 vrf A match internal external 1 external 2
exit-address-family
mpls ldp router-id Loopback0

 Cấu hình trên router P1


interface Loopback0
ip address 5.5.5.5 255.255.255.255
interface Serial1/0
ip address 192.168.25.5 255.255.255.0
mpls ip
interface Serial1/1
ip address 192.168.56.5 255.255.255.0
mpls ip
interface Serial1/2
ip address 192.168.57.5 255.255.255.0
mpls ip
router ospf 1
network 5.5.5.5 0.0.0.0 area 1
network 192.168.25.0 0.0.0.255 area 1
network 192.168.56.0 0.0.0.255 area 1
network 192.168.57.0 0.0.0.255 area 1

14
Chương 2: Tìm hiểu về VPN-MPLS

mpls ldp router-id Loopback0

Lưu ý: Cấu hình router CE2 tương tự như CE1, PE2 tương tự PE1 và P2, P3 tương tự P1

 Kiểm tra kết nối giữa 2 router CE1, CE2:


Dùng lệnh ping gửi gói tin ICMP kiểm tra kết nối giữa 2 router.
Lệnh tracer xác định lộ trình truyến đi qua mạng.

Hình 2.11 Kết quả kết nối giữa 2 router.

Kết quả cho thấy quá trình định tuyến và trao đổi dữ liệu thành công, và quá trình
chuyển tiếp gói tin trong đó có sử dụng nhãn MPLS chuyển tiếp qua mạng core.

15
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Chƣơng 3: Các phƣơng pháp mã hóa và Cấu trúc PKI

3.1 Các giải thuật mã hóa.

3.1.1 Giải thuật mã hóa đối xứng.

Là phương pháp sử dụng một khóa để bảo mật dữ liệu, khóa này dùng để mã hóa
và giải mã dữ liệu. Vì vậy khóa này phải được chuyển một cách an toàn giữa các bên giao
tiếp. Thuật toán mã hóa đối xứng nhìn chung thực hiện nhanh nhưng an toàn chưa cao vì
có thể bị lộ khóa. Nên thuật toán này được dùng để mã hóa dữ liệu.

Hình 3.1 Mã hóa key đối xứng [4].

16
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Ngày nay có 3 thuật toán mã hóa được sử dụng nhiều: DES, 3DES và AES.

 DES (Data Encryption Standard): Được phát triển bởi Tiêu chuẩn xử lý thông tin Hoa
Kỳ (National Institute of Standard and Technology –NIST). DES mã hóa dữ liệu theo
từng block 64 bits với một khóa 56 bits. Vì độ dài khóa ngắn nên DES là một thuật
toán mã hóa yếu dễ bị bẻ khóa.
 3DES (Triple Data Encryption Standard): Bổ sung thêm một số tính năng cao cấp, nó
thực hiện mã hóa dữ liệu thông qua việc xử lý mỗi block 3 lần với một khóa khác
nhau. Nghĩa là 3DES sử dụng một khóa 168 bits nên an toàn hơn.
 AES (Advanced Encryption Standard): được tạo ra để thay thế DES, không chỉ nhanh
hơn mà còn mã hóa an toàn hơn nên ngày nay được sử dụng rất nhiều. AES cũng thực
hiện mã hóa theo từng block 128 bits, có khả năng hỗ trợ block 128/192/256 bits.

3.1.2 Mã hóa bất đối xứng.


Là phương pháp sử dụng cặp khóa: Public key và private key. Trong đó public key
được trao đổi cho tất cả các thiết bị khác, còn private key thì giữ bí mật cho riêng mỗi
thiết bị.

Dựa vào mục đích của việc truyền phát, giữa public key và private key sẽ được sử
để mã hóa dữ liệu, bên nhận sẽ sử dụng key ngược lại để giải mã dữ liệu.

Thuật toán mã hóa này rất an toàn nhưng xử lý chậm nên được dùng để chứng
nhận và quản lý khóa.

Có hai ứng dụng của việc mã hóa bất đối xứng là:

 Ứng dụng xác thực: là ứng dụng chủ yếu trong giải pháp PKI, dùng để xác nhận bên gửi.
Bên gửi sẽ mã hóa giữa liệu bằng private key và bên nhận dùng public của bên gửi để giải
mã nó. Vì private key là thông tin bí mật ở mỗi thiết bị và bên nhận giải mã thành công
dữ liệu thì thông điệp đó chắc chắn phải được gửi bởi bên gửi.

Hình 3.2 Xác thực sử dụng Key bất đối xứng [3].

17
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

 Ứng dụng mã hóa: Bên gửi nhận được public key của bên nhận. Sau đó, bên gửi sẽ mã
hóa các thông điệp với public key của bên nhận. Vì thế chỉ có bên nhận có private key của
nó và giải mã thành công thông điệp.

Hình 3.3 Mã hóa sử dụng Key đối xứng [3].

Một số giải thuật mã hóa bất đối xứng phổ biến sử dụng cho việc trao đổi key và chữ ký
số:

 RSA (Rivest, Shamir, Adleman):

Giải thuật RSA là một trong những giải thuật nổi tiếng và được sử dụng rộng rãi trong
việc trao đổi key, chữ ký số và mã hóa thông điệp.

Giải thuật RSA có nhiều tiêu chuẩn khác n`hau như: RC1, RC2, RC3, RC4, RC5,
RC6. Tất cả đều sử dụng chiều dài key và chiều dài kích thước khối thay đổi.

 Diffe-Hellman (DH):

DH là một hệ thống phân phối public key (hay một giao thức trao đổi key), sử cơ chế
mã hóa key bất đối xứng. DH cho phép hai user, không thông tin lẫn nhau, thiết lập một
key bí mật chia sẽ qua một kênh thông tin không đảm bảo.

Giải thuật DH thì không được sử dụng cho xác thực hoặc chữ ký số, chỉ sử dụng cho
trao đổi key bí mật.

Ngoài ra, còn một một giải thuật phổ biến khác như: Digital Signature Algorithm
(DSA), Public-key Crytography Standards (PCKS)

18
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

3.1.3 Giải thuật Hash


Giải thuật hash sử dụng một công thức toán học để tính toán một giá trị hash với
chiều dài cố định dựa trên nội dung ban đầu. Hàm hash thường nhanh hơn cơ chế mã hóa.

Giải thuật hash thường được sử dụng để cung cấp một vân tay số của bất kỳ dữ liệu
nào, để đảm bảo rằng thông tin không bị thay đổi trong quá trình truyền. Vì vậy, nó cung
cấp sự toàn vẹn của thông tin.

Giá trị hash là một số duy nhất được tạo ra từ văn bản gốc từ một công thức toán học

Hình 3.4 Giải thuật Hash [4].

19
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Một số giải thuật hash phổ biến được sử dụng rộng rãi trong việc toàn vẹn thông tin,
chứng thực và chữ ký số:

 Giải thuật Message Digest (MD):

Giải thuật MD là một chuỗi hàm hash mã hóa định hướng byte, giá trị hash của nó có
chiều dài cố định là 128-bit.

Một số phiên bản của giải thuật MD như: MD2 (RFC 1319), MD4 (RFC 1320), MD5
(RFC 1321). MD5 là phiên bản tốt nhất và được sử dụng rộng rãi cho nhiều ứng dụng.
Giải thuật MD5 bao gồm bốn vòng riêng biệt, với một chút khác biệt so với MD4.

 Giải thuật secure hash (SHA):

SHA là một chuỗi giải thuật hash mã hóa nổi tiếng khác, tạo một ngõ ra với 160-bit. SHA
thì tính toán phức tạp hơn MD5 nhưng bảo mật hơn.

SHA-1 (RFC 3174) là giải thuật được sử dụng phổ biến trong các phiên bản SHA. Nó
được sử dụng rộng rãi trong cái ứng dụng và các giao thức như: Transport Layer Security
(TLS), Secure Sockets Layer (SSL) , Secure Shell (SSH), IPSec, …

3.2 Cấu trúc PKI.

3.2.1 Thành phần cơ bản của PKI.

3.2.1.1 Chứng thực.


Chứng thực được dùng để thiết lập một liên kết giữa một thiết bị và tài liệu điện tử
tương ứng. Trong đó, tài liệu là thông tin mã hóa, thường được biết đến như các key mã
hóa. Một chứng thực số là một tập hợp các thông tin số độc lập, được kết hợp và ký nhận
bởi trung tâm ủy quyền.

Chứng thực có những thông tin chính sau:

 Đặc điểm nhận dạng (tên hoặc chứng nhận)


 Các thuộc tính kèm theo đặc điểm nhận dạng hoặc chứng thực ủy quyền sử dụng.
 Một public key thực hiện một tập hợp các hoạt động mã hóa định sẵn. nó không
được bảo mật.
 Một chữ ký từ một trung tâm ủy quyền chứng thực (CA – Certification Authority),
nó bao phủ toàn bộ các trường thông tin phía trên.

20
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Hình 3.5 Cấu trúc chứng thực X.509 [3].

Các chuẩn định dạng của chứng thực:

 X.509v3 là tiêu chuẩn cho PKI internet. Nó dựa vào một mô hình mang tính hệ
thống và được trình bày trong RFC-5280.
 Mã hóa PEM (Privacy Enhanced Mail) thì thường tượng trưng cho chứng thực
trong định dạng text.

3.2.1.2 Trung tâm chứng thực CA (Certification Authority).

 Vai trò và chức năng.

Vai trò chính của CA xây dựng mối quan hệ tin cậy giữa thiết bị và tài liệu điện tử
(ví dụ như cặp key). CA thì chịu trách nhiệm xác nhận sự xác thực của các yêu cầu
chứng thực. Để đảm bảo thì chứng thực bao gồm một số thông tin như thông tin thiết bị
yêu cầu hoặc các đặc điểm của nó.

21
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

CA là một liên kết quan trọng trong hệ thống PKI (Public Key Infrastructure ). Nếu
CA bị hư hỏng thì toàn bộ việc thực thi PKI không còn tin cậy.

 Private CA và Public CA.

Phụ thuộc vào mục tiêu tổng quan và phạm vi của việc triển khai PKI, có thể phân
biệt thành hai loại CA: private và public.

Các Private CA được tạo ra, khai thác và duy trì bởi một tổ chức cá nhân. Các dịch
vụ của nó chỉ cung cấpvới chức năng bên trong công ty. Các thành phần bên ngoài sẽ
không biết đến hoặc không tin cậy một private CA. Nội dung và cấu trúc của chúng thực
không bị ràng buộc. Các chứng thực được cấp miễn phí.

Các Public CA được biết đến và được tin cậy trên phạm vi rông lớn (như cấp độ
Internet). Chúng được khai thác và duy trì bởi các công ty chuyên môn (ví dụ như:
Verisign, Entrust, GlobalSign, Thawte). Để sử dụng dịch vụ, một chi phí phải được trả
cho các công ty. Nội dung của các chứng thực thường có nhiều ràng buộc.

3.2.1.3 Trung tâm chứng thực phụ Sub-CA (Subordinate CA).


Khi số lượng các thành phần đăng ký tăng lên đáng kể, nó sẽ ảnh hưởng đến khả
năng quản lý của CA. Vì vậy, các CA phải được xây dựng như một hệ thống. Vai trò và
chức năng của CA được phân phối đến nhiều sub-CA.
Vai trò và chức năng của một sub-CA cũng giống như một CA:

 Hoạt động như một trung tâm ủy quyền tin cậy.


 Xác minh đặc điểm của chủ thể yêu cầu đăng ký.
 Ban hành chứng thực.

Một sự khác biệt giữa CA và sub-CA, một CA có thể xem như một vùng tự trị, một
thành phần PKI, một sub-CA luôn là con của một CA. Cấu hình một sub-CA sẽ trình bày
trong phần sau.

3.2.1.4 Các user và thiết bị cuối.


Vai trò và chức năng:

Là điểm cuối cây hệ thống PKI nên chúng không thể ban hành các chứng
thực.Chúng sử dụng chứng thực cho các hoạt động mã hóa liên quan trực tiếp đến chúng,
phổ biến như việc xác thực đến các hệ thống thông tin như VPN, web server…, chữ ký
số đối với các email, mã hóa nội dung.

22
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Chức năng bảo mật:

Một chứng thực số là sự nhận dạng số của một điểm cuối. Một điều quan trọng là
phải bảo vệ chúng. Bản thân chứng thực là các thông tin chung; tuy nhiên, cặp key liên
kết (cụ thể là key riêng) là một thông tin bí mật vì nó được sử dụng để tạo nội dung mã
hóa liên kết đến chứng thực.

Một thiết bị lưu trữ được dùng để lưu một bản sao chứng thực luôn sẵn sàng để sử
dụng và việc bảo vệ các cặp key. Các nơi lưu trữ thường gặp như: Microsoft Windows
Certificate Storage, Linux, MAC OS, Cisco IOS, Cisco ASA, Smart Card…

3.2.2 Quá trình đăng ký PKI.


Một vài quá trình xảy ra trong mạng PKI như:

 Enrollment.
 Hết hạn và đổi cấp chứng thực.
 Xác minh chứng thực và phục hồi PKI.

3.2.2.1 Enrollment.
Enrollment là quá trình để đạt được chứng thực. Có hai cách thực hiện quá trình
enrollment:

 Manual enrollment
 Network SCEP-based enrollment

Cả hai quá trình giống nhau về nguyên lý nhưng cách thực hiện khác nhau. Bao gồm các
sự kiện chung như sau

 Các host tạo một cặp key RSA.


 Một chứng thực yêu cầu chứa public key của host được đưa đến CA.
 CA ký nhận yêu cầu với private key của CA và tạo một chứng thực cho host
 Chứng thực được mang trở lại cho host.

23
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Hình 3.6 Quá trình đăng kí chứng thực [5].

Để tạo một cặp RSA key, ở mode config dùng lệnh:

Router(config)#cry pto key generate rsa label pki-client module 1024 exportable

Để cấu hình quá trình enrollment, phải tạo một trustpoint trùng tên với trustpoint trên CA
cho thiết bị:

Router(config)#crypto pki trustpoint name-trustpoint

 Manual Enrollment.

Trong vài trường hợp, kết nối mạng không đảm bảo giữa khách hàng và server
chứng thực. Trong trường hợp này, người quản trị mạng phải copy và paste bằng tay
chứng thực vào router.

Manual enrollment gồm các bước sau:

1. Cấu hình spoke sử dụng terminal để enrollment:

Router(config)#crypto pki trustpoint name-trustpoint

Router(ca-trustpoint)#enrollment ternimal

2. Trên CA, xuất chứng thực của nó ra terminal và copy chứng thực.

Router(config)#crypto pki export name-trustpoint pem terminal

3. Thiết bị spoke xác thực chứng thực của CA và xác nhận fingerprint.

Router(config)#crypto pki authenticate name-trustpoint

24
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Sau đó, paste chứng thực CA đã copy ở bước 2 vào spoke.

4. Spoke tạo một yêu cầu đăng ký và copy lại yêu cầu này.

Router(config)#crypto pki enroll name-trustpoint

Trên CA, paste yêu cầu chứng thực của spoke vào.

5. CA cấp chứng thực cho yêu cầu.

Router(config)#crypto pki server name-server grant number-cert

6. Trên spoke, paste chứng thực được CA cấp ở trên vào terminal.

Router(config)#crypto pki import name-trustpoint certificate

 Network SCEP-based enrollment.

Khi các kết nối mạng sẵn sàng giữa các khách hàng và server chứng thực, một
cách thực hiện dựa trện mạng thì mang lại nhiều tiện lợi hơn. SCEP (Simple Certificate
Enrollment Protocol) enrollment là một giải pháp thích hợp. Nó chỉ yêu cầu cấu hình đơn
giản trên router và thích hợp cho mạng quy mô lớn, cải thiện tính mở rộng của hệ thống.

SCEP cho phép các thiết bị tham gia yêu cầu chứng thực hoặc các chức năng liên
quan chứng thực (kiểm tra, hủy bỏ) từ xa. SCEP sử dụng kết nối TCP, mặc định chạy trên
port 80, nhưng cũng có thể cấu hình sử dụng port khác (phải đồng bộ trên server và
endpoint).

Khi một thiết bị có một cặp key RSA, nó tạo môt yêu cầu đến CA sử dụng SCEP.
Chứng thực bao gồm public key của nó. CA cấp một chứng thực mới được mã hóa bằng
public key của thiết bị. Vì vậy, chỉ có thiết bị yêu cầu mới giải mã được chứng thực.

Cấu hình router sử dụng SCEP-based enrollment:

Router(config)#crypto pki trustpoint name-trustpoint

Router(ca-trustpoint)#enrollment url http://địa_chỉ_IP_của_server:80

Sau đó, spoke phải xác thực với CA và yêu cầu đăng ký:

Router(config)#crypto pki authenticate name-truspoint

Router(config)#crypto pki enroll name-truspoint

25
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

3.2.2.2 Hết hạn và cấp mới chứng thực.


Chứng thực có thời hạn nhất định. Cả chứng thực CA và chứng thực spoke đều hết
hạn. Khi đó, các xác thực giữa các thành viên sử dụng chứng thực sẽ bị lỗi; vì vậy, các kết
nối không được thiết lập. Để ngăn chặn đều này, hai cơ chế được triển khai cho việc cấp
mới chứng thực: auto enrollment, sử dụng cho spoke và rollover, sử dụng cho sever
chứng thực.

 Auto enrollment

Khi các chứng thực hết hạn, auto enrollment cho phép thiết bị đạt được một chứng
thực mới mà không có gián đoạn. Các host có thể yêu cầu một chứng thực tại khoảng thời
gian xác định trước khi chứng thực hết hạn, được sử dụng với SCEP.

Để cấu hình auto enrollment, vào mode phụ ca-trustpoint và dùng lệnh (giả sử yêu
cầu cấp mới vào thời điểm 80% thời gian sống của chứng thực):

Router(ca-trustpoint)#auto-enroll 80

 Rollover

Khi chứng thực trên CA server hết hạn, rollover cho phép CA đạt được một chứng
thực một chứng thực mới mà không có sự gián đoạn. Bằng việc cấu hình rollover, CA có
thể tạo một chứng thực mới tại thời điểm đã xác định trước khi chứng thực hết hạn.
Chứng thực mới gọi là một ảnh của chứng thực, sẽ kích hoạt tại thời điểm mà chứng thực
hiện tại hết hạn.

Để cấu hình rollover, vào mode phụ cs-server và dùng lệnh:

Router(cs-server)#auto-rollover 3 3 30

Trong đó, ba thông số trên lần lượt là ngày giờ phút, thời điểm mà cấp chứng thực mới
trước khi chứng thực hiện tại hết hạn.

3.2.2.3 Việc kiểm tra chứng thực.


Trong các trường hợp, các chứng không được sử dụng nữa thì cần có một phương
pháp thu hồi lại chứng thực thay vì đợi đến cho chứng thực hết hạn. Có ba phương pháp
thực hiện quan trọng là:

26
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

 Sử dụng certificate revocation list (CRL), nó được tải xuống router định kỳ.
 Sử dụng online certificate status protocol (OCSP), cung cấp update thời gian thực
và tạo một yêu cầu cho mọi chứng thực xuất hiện.
 Sử dụng authentication, authorization, and accouting (AAA) server kết hợp với
chứng thực, liên quan đến các user thực hiện việc xác thực.

So sánh ưu khuyết điểm các phương pháp:

Ưu điểm Khuyết điểm


CRL Yêu cầu chi phí mạng thấp, được Không đáp ứng thời gian thực nếu
hỗ trợ trong IOS. chứng thực bi thu hồi khi chưa đến
thời hạn update.
Nếu danh sách CRL dài, thì thời gian
xử lý update chậm.
OCSP Đáp ứng thời gian thực. Không hỗ trợ trong IOS.
IOS CA thì không hỗ trợ OCSP, chỉ
có sự kiểm tra của khách hàng được
hỗ trợ.
AAA Thi hành việc cấp phép thời gian Các thông tin chứng thực cụ thể phải
thực được nhập vào AAA server. Phụ
thuộc vào các tiêu chí lựa chọn, nó có
thể làm mất nhiều thời gian cho người
quản lý.

Trong phần này, chỉ trình bày về phương pháp sử dụng CRL cho việc kiểm tra chứng
thực.

Certificate Revocation Lists

Certificate revocation list (CRL) cho phép các thiết bị xác định việc một chứng
thực bị thu hồi trước thời hạn. Một CRL thì bao gồm số serial của chứng thực (ban hành
bởi CA) và ngày thu hồi chứng thực. Để cho phép tính năng CRL hoạt động trên thiết bị
ta dùng lệnh:

Router(ca-trustpoint)#revocation-check crl

Mặc định, CRL được lưu trên CA, nhưng nó được đề nghị lưu trên sever bên ngoài
(ví dụ như tftp server) nếu có sự cố xảy ra (mất điện hoặc router bị hư) thì hệ thống PKI
có thể phục hồi được. Để lưu CRL trên server bên ngoài, trong mode phụ cs-server ta
dùng lệnh:

27
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Router(cs-server)#database url crl tftp://100.1.1.1

CRL cũng có thời gian sống. Khi khoảng thời gian này kết thúc, CRL sẽ được update lại
thông tin. Để chỉnh thời gian sống của chứng thực, trong mode phụ cs-server dùng lệnh:

Router(cs-server)#lifetime crl ngày giờ

Để thu hồi một chứng thực, trong mode priviledge dùng lệnh:

Router#crypto pki server name-server revoke số serial

Chứng thực sẽ bị thu hồi, nhưng thông tin này sẽ không được CRL update cho đến khi nó
hết hạn.

3.2.3 Kiến trúc hệ thống CA phân cấp.


Hệ thống CA theo kiến trúc phẳng cơ bản thì chỉ sử dụng cho hệ thống nhỏ, các
spoke sẽ đăng ký trực tiếp đến root CA.

Hình 3.7 Cấu trúc hệ thống CA phẳng [3].

Một PKI cho một mạng có hàng trăm hoặc nhiều hơn các spoke thì kiến trúc phẳng sẽ
xuất hiện các vấn đề như: xử lý chậm, khó khăn trong việc quản lý và độ mở rộng. Để đáp
ứng trường hợp này, một hệ thống CA có kiến trúc phân cấp sẽ được triển khai.

28
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Hình 3.8 Cấu trúc hệ thống CA phân cấp [3].

Thiết kế hệ thống phân cấp có hai biến thể chính. Biến thể đầu tiên, nội dung chuỗi chứng
thực được sử dụng cho phép một mức độ hợp lệ từ dưới lên trên. Cái còn lại, chuỗi chứng
thực thì không cho phép sự hợp lệ đó.

Cấu hình root CA:

Đầu tiên, cần phải cấu hình một root CA cho hệ thống. Để cấu hình root-CA, thực hiện
các bước sau:

1.Tạo một cặp RSA key dùng cho việc xác thực.
2.Cấu hình certificate server:
 Tạo một cs-sever cho root CA.
 Xác định định dạng tên cho chứng thực của server: có hai dạng là FQND (mặc
định) và X500
 Xác định nơi trữ các file dữ liệu của CA
 Cấu hình cấp độ lưu trữ thông tin của cơ sở dữ liệu, có cấp độ là: nimimum, name,
complete.

29
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Router(config)#crypto pki server root-CA


Router(cs-server)#issuer-name CN=root-CA, OU=GETVPN, O=BachKhoa,
C=VietNam
Router(cs-server)#database url nvram:
Router(cs-server)#database level name

3. Cấu hình các chính sách ban hành cho CA:


 Xác định thuật toán hash sử dụng cho quá trình ký nhận chứng thực, có hai cách là
MD5 (mặc định) và SHA-1.
 Xác định thời gian sống cho các chứng thực được ban hành (thường là 2 hoặc 3
năm), thời gian sống cho chứng thực của CA (mặc định là 5 năm).
 Cấu hình phương pháp cấp chứng thực cho router, có 2 phương pháp: tự động và
bằng tay.
o Tự động: trong mode phụ trustpoint dùng lệnh grant auto cho chứng thực
của spoke, lệnh grant auto rollover ca-cert
o Bằng tay: ở mode priviledge, dùng lệnh crypto pki server root-CA
{grant|reject} req-id

Router(config)#crypto pki server root-CA


Router(cs-server)# hash sha1
Router(cs-server)# lifetime certificate 730
Router(cs-server)# lifetime ca-certificate 3650
Router(cs-server)# grant auto

4. Cấu hình chính sách thu hồi chứng thực:

Để điều chỉnh thời gian sống cho crl, trong modecs-server dùng lệnh lifetime crl giờ (từ
0-366 giờ).

5. Cấu hình SCEP interface (nếu dùng SCEP enrollment)

Trong mode config, dùng lệnh ip http server

6. Cho phép CS server hoạt động.

Dùng lệnh no shutdown trong mode phụ cs-server. Sau khi server được bật lên, nó
không cho phép thay đổi cấu hình, nếu muốn thay đổi ta phải tắt sever.

30
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Cấu hình một sub-CA:

Để có hệ thống trên, cần phải cấu hình chính xác một sub-CA mới. Sub-CA phải
đăng ký đến root CA và đại diện cho root CA cấp chứng thực cho các spoke. Để cài đặt
sub-CA, cần thực hiện các bước sau:

1. Cấu hình server cho sub-CA: tương tự như cấu hình root CA. Để nó hoạt động
như sub-CA, cần thêm vào câu lệnh:

Router(config)#crypto pki server sub-CA-1

Router(cs-server)#mode sub-cs

2. Thiết lập một trustpoint cho sub-CA:

Router(config)#crypto pki trustpoint sub-CA-1

Router(ca-trustpoint)#enrollment url http://địa-chỉ-IP-root-CA:80

Router(ca-trustpoint)#rsakeypair subca-key

Router(ca-trustpoint)#revocation crl none

3. Vào no shutdown cho server và chấp nhận chứng thực của root CA.
4. Trên root CA, phải cấp bằng tay cho yêu cầu đăng ký của sub CA bằng câu lệnh:

Router#crypto pki server root-CA grant all

5. Trên sub CA, dùng các câu lệnh show để xác nhận đã nhận chứng thực.

Router#show crypto pki server

Router#sh crypto pki certificate

3.2.4 Mô phỏng hệ thống CA.


 Hoạt cảnh mô phỏng.

Mô hình mô phỏng là một hệ thống CA hai cấp, các client (spoke) sẽ đăng ký
chứng thực với root-CA thông qua các sub-CA.

31
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Hình 3.9 Mô hình mô phỏng CA hai cấp.

 Kết quả mô phỏng:

Hình 3.10 Server chứng thực trên sub-ca.

32
Chương 3: Các phương pháp mã hóa và Cấu trúc PKI

Hình 3.11 Nội dung chứng thực trên Client.

Nhận xét:

 Trên sub-ca nhận chứng thực từ root-ca và đại diện cho root-ca cấp chứng thực cho
clients khi đăng kí với sub-ca.
 Clients đăng kí với sub-ca nhưng vẫn được root-ca chứng thực. Vì thế, mặc dù các
clients đăng kí với các sub-ca khác nhau nhưng cùng root-ca thì sẽ xác thực được
lẫn nhau

33
Chương 4: Giải pháp GET VPN

Chƣơng 4: Giải pháp GET VPN

4.1 Ƣu điểm GET VPN.


GET VPN mang lại những lợi ích chính sau:

 Cung cấp kết nối quy mô rộng any-to-any sử dụng mô hình bảo mật IPSec.
 Tận dụng lợi thế cơ bản của cơ sở hạ tầng định tuyến IP VPN và không yêu cầu
một sự quản lý của mặt phẳng điều khiển định tuyến.
 Tích hợp với cơ sở hạ tầng multicast.
 Bảo vệ địa chỉ IP nguồn và đích trong suốt quá trình mã hóa và đóng gói IPSec.
Bởi thế GET VPN tích hợp tốt với các tính năng như là chất lượng dịch vụ QoS và
kỹ thuật lưu lượng.

4.2 Tổng quan về GET VPN.

Hình 4.1 Mô hình GET VPN [6].

34
Chương 4: Giải pháp GET VPN

GET VPN là một kỹ thật mã hóa nhóm tin cậy được Cisco giới thiệu để thay thế
mã hóa đường hầm điểm-điểm. GMs chia sẻ một Security Association (SA) cho phép giải
mã lưu lượng đã được mã hóa bởi GM khác. GET VPN được xây dựng dựa trên các giao
thức IKE, GDOI và kỹ thuật Multicast. Trong đó GDOI là thành phần chính của GET
VPN.

4.2.1 GDOI (RFC 3547).


Giao thức quản lý nhóm mã hóa nhóm được dùng để cung cấp key mã hóa và
chính sách cho một nhóm thiết bị. Trong mạng GET VPN, GDOI được sử dụng để phân
phối keys cho một nhóm VPN gateway thực hiện một cách an toàn. Các keys được làm
mới sau một khoảng thời gian và được cập nhật trên tất cả các VPN gatewat sử dụng tiến
trình rekey.

Hình 4.2 Hoạt động giao thức GDOI [6].

35
Chương 4: Giải pháp GET VPN

Giao thức GDOI được bảo vệ bởi Phase 1 của IKE SA. Tất cả các VPN gateway
tham gia phải xác thực với thiết bị cung cấp keys sử dụng IKE. Phương thức xác thực
IKE gồm: pre-shared keys (PSKs) và public key infrastructure (PKI) . Sau khi các VPN
gateway xác thực và được cung cấp keys bảo mật thích hợp thông qua IKE SA, IKE SA
hết hạn và GDOI được sử dụng để cập nhật GMs một cách hiệu quả và khả năng mở rộng.

GDOI sử dụng 2 key khác nhau cho việc mã hóa. Một key để bảo vệ mặt phẳng
điều khiển gọi là Key Encryption Key (KEK), key còn lại để bảo vệ dữ liệu lưu thông gọi
là Traffic Encryption Key (TEK).

Hình 4.3 Group keys trong GET VPN [6].

4.2.2 Key Server (KS).


Là một thiết bị IOS chịu trách nhiệm về việc tạo ra và duy trì mặt phẳng điều khiển
GET VPN. Tất cả các chính sách mã hóa như là lưu lượng truy cập, giao thức mã hóa,
chính sách an ninh, bộ đếm rekey...được xác định trên KS và được đưa xuống GMs tại
thời điểm đăng kí.

GMs xác thực với KS sử dụng IKE Phase 1 (pre-shared keys hoặc PKI) và tải
xuống chính sách mã hóa cũng như keys cần thiết cho hoạt động của GET VPN. KS chịu
trách nhiệm làm mới và phân phối keys.

36
Chương 4: Giải pháp GET VPN

Hình 4.4 Mô hình phân phối keys của Key Server [6].

Hoạt động phân phối keys của KS:

 Key Server giám sát thời gian hết hạn của TEK1.
 Key Server tạo TEK2 thay thế TEK1 trước khi hết hạn.
 Key Server cung cấp TEK2 cho tất cả Group Member qua tiến trình unicast rekey
hoặc multicast rekey.

Không giống như IPSec truyền thống, lưu lượng truy cập được định nghĩa trên KS sử
dụng access control list (ACL) và được tải xuống mỗi GM.

Lưu ý: Một thiết bị hoạt động như KS thì không thể cấu hình GM

4.2.3 COOP Key Server


KS là thực thể quan trọng nhất trong mạng GET VPN vì KS duy trì mặt phẳng điều
khiển, một KS duy nhất gặp sự cố thì mạng GET VPN ngừng hoạt động.

Vì vậy dự phòng rất quan trọng cho KS, GET VPN hỗ trợ nhiều KS. Các KS dự
phòng gọi là COOP KS, đảm bảo phục hồi nếu một KS bị lỗi.

Một GM có thể cấu hình đăng kí cho bất kì KS có sẵn từ danh sách COOP KSs.
Khi COOP KSs khởi động thì các KS này ở trạng thái secondary và tiến hành bầu chọn.

37
Chương 4: Giải pháp GET VPN

Một KS có số ưu tiên (Priority) cao nhất sẽ là Primary KS và các KS còn lại ở


trạng thái secondary.

Hình 4.5 Mô hình COOP Server [6].

Primary KS chịu trách nhiệm tạo ra và phân phối chính sách nhóm tới tất cả GM
và định kỳ đồng bộ các COOP KS. Một GM có thể đăng kí với bất kì KS có sẵn nhưng
chỉ có primary KS gửi thông điệp rekey.

4.2.4 Group Member (GM).


Là một router IOS chịu trách nhiệm cho việc mã hóa và giải mã, tức là thiết bị chịu
trách nhiệm xử lý mặt phẳng dữ liệu của GET VPN. Một GM chỉ cấu hình với thông số
IKE phase 1 và thông tin về KS hoặc nhóm GM đăng kí.

Các chính sách mã hóa được xác định trên KS và tải xuống GM ngay lúc đăng kí.
Dựa trên những chính sách tải xuống, GM quyết định lưu lượng nào cần mã hóa hoặc giải
mà và key nào được sử dụng.

38
Chương 4: Giải pháp GET VPN

Hình 4.6 Mô hình hoạt động Group Keys trên GMs [6].

Hoạt động Group Keys trên GMs:

 GMs nhận TEK1 từ KS dùng cho mã hóa lưu lượng giữa các GMs.
 Trước khi TKE1 hết hạn thì GMs nhận TEK2.
 GMs đồng bộ quá trình chuyển dữ liệu khi sử dụng TEK2.
 GMs tiếp tục sử dụng TEK1 cho việc giải mã dữ liệu nào đã được mã hóa với
TEK1 và sau đó chỉ sử dụng TEK2.

Trong một mạng GET VPN, chính sách cho GMs được xác định bởi KS. Nhưng trong
một số trường hợp thì GMs có thể được cấu hình thêm chính sách riêng có thể thay đổi
một số chính sách từ KS. Bất cứ chính sách chung định nghĩa trên KS đều ảnh hưởng tất
cả thành viên trong nhóm, tuy nhiên có thể khai báo thêm chính sách trên GMs để nhận
hay không chính sách từ KS.

4.2.5 IP Tunnel Header Preservation


Trong IPsec, địa chỉ đầu cuối của tunnel header được sử dụng nhự địa chỉ nguồn và
đích mới của gói tin. Gói tin sau đó được chuyển qua mạng IP sử dụng mã hóa địa chỉ
nguồn của gateway và giải mã địa chỉ đích của gateway.

39
Chương 4: Giải pháp GET VPN

Trong trường hợp GET VPN thì IPsec bảo vệ các gói tin dữ liệu bằng cách đóng
gói dữ liệu bằng địa chỉ nguồn và đích của gói tin ban đầu gọi là giữ lại IP header.

Hình 4.7 Tunnel header preservation [1].

Ưu điểm lớn nhất của tunnel header preservation là khả năng định tuyến để mã hóa
các gói tin sử dụng hạ tầng định tuyến sẵn có. Mạng IP, VPLS hoặc VPN-MPLS được
tích hợp hoàn toàn với giải pháp GET VPN.

Hình 4.8 So sánh tunnel header IPsec với GET [7].

Sử dụng tunnel header preservation giống như transport mode của IPsec. Tuy
nhiên, phương thức hoạt động cơ bản là tunnel mode. Việc sử dụng lại orginal IP header
trong chỉ tốn thêm ít dung lượng cho gói tin, IPsec transport mode không hỗ trợ phân chia
gói và nối lại gói tin trong khi truyền trong khi việc mã hóa và xóa gói yêu cầu việc phân
chia gói tin.

40
Chương 4: Giải pháp GET VPN

4.2.6 Group security association


Không giống như giải pháp mã hóa IPsec, GET VPN sử dụng khái niệm về nhóm
chính sách an ninh (Group SA). Tất cả thành viên trong nhóm GET VPN có thể giao tiếp
với nhau bằng cách sử dụng một chính sách mã hóa thông dụng và chia sẻ SA. Với chính
sách mã trên thì không cần thỏa thuận IPsec giữa các GM, điều này sẽ giảm tài nguyên sử
dụng trên bộ định tuyến IPsec.

Lưu ý: Trong nhóm GET VPN lên đến 100 ACL cho phép xác định lưu lượng cho việc
mã hóa và với mỗi kết nối cho phép không quá 200 IPsec SA.

4.2.7 Quá trình Rekey


Như đã đề cập ở trên, KS không chỉ chịu trách nhiệm cho việc tạo ra chính sách
mã hóa và keys mà còn làm mới keys và phân phối tới GMs. Quá trình gửi keys mới khi
key hiện tại sắp hết hạn gọi là tiến trình rekey. GET VPN hỗ trợ 2 loại thông điệp rekey:
unicast mà multicast.

Nếu một GM không nhận được thông tin rekey từ KS (KS hoặc đường truyền xảy
ra sự cố) thì GM cố gắng đăng kí lại (re-register) để thiết lập kết nối với KSs 60 giây
trước khi IPsec SA hết hạn (expire). Nếu đăng kí lại thành công, GM nhận chính sách
SAs mới là một phần của quá trình đăng kí lại và lưu lượng trong mặt phẳng dữ liệu
không bị gián đoạn. Nếu đăng kí lại không thành công thì GM thử lại 3 lần nữa, mỗi lần
cách nhau 10 giây để thiết lập kết nối với KS. Nếu không liên lạc được KS thì GM cố
gắng kết nối với COOP KS trong danh sách 20 giây trước khi IPsec SA hết hạn.

Hình 4.9 Thời gian re-register.

41
Chương 4: Giải pháp GET VPN

 Unicast rekey

KS tạo ra một thông điệp rekey và gửi tối mỗi GM. Khi nhận được thông điệp
rekey, GM gửi thông điệp ACK tới KS. Cơ chế ACK này không chỉ đảm bảo rằng
danh sách GMs hoạt động trên KS hiện tại mà còn đảm bảo thông điệp rekey được
gửi tới GMs hoạt động. Một KS có thể cấu hình truyền lại (retransmit) một gói tin
rekey để khắc phục lỗi tạm thời trong mạng. Nếu một GM không nhận 3 rekey liên
tiếp thì KS loại bỏ GM từ cơ sở GM đang hoạt động và ngừng gửi thông điệp
rekey đến GM.
Lưu ý: Unicast rekey truyền lại khi GM không thông báo ACK.

 Multicast rekey

Khác với Unicast rekey, khi nhận được thông điệp rekey từ KS nhưng Multicast
rekey không có cơ chế ACK. KS không duy trì một danh sách hoạt động GMs.
Ngoài ra, KS có thể cấu hình truyền lại một gói tin multicast rekey để khác phục
lỗi giống như Unicast rekey.
Lưu ý: Multicast phải được kích hoạt trên mạng core cho multicast rekey để hoạt
động trên mặt phẳng điều khiển GET VPN.

4.2.8 Time-based anti-replay


Trong IPsec, anti-replay ngăn chặn khả năng một bên thứ 3 bắt gói tin IPsec và
chuyển tiếp sau một khoảng thời gian để khởi động tấn chông từ chối dịch vụ đối với thiết
bị đầu cuối. Giải pháp để chống lại kiểu tấn công trên là sử dụng một bộ đếm dựa trên
giao thức cửa sổ trượt: Người gửi sẽ gửi một gói tin với một số thứ tự và người nhận sử
dụng cửa sổ trược xác định gói tin có thể được chấp nhận hay không.

Bởi vì GET VPN sử dụng nhóm chính sách SA nên bộ đếm chống anti-replay
không hiệu quả. Một phương pháp mới để bảo vệ chống tấn công anti-replay là bắt buộc.
GET VPN sử dụng Time-based anti-replay (TBAR), nó dựa trên việc sử dụng một chiếc
đồng hồ giả (pseudo-time clock) được duy trì trên KS. Lợi thế của việc sử dụng pseudo-
time cho TBAR là nó không cần phải đồng bộ thời gian trên tất cả thiết bị GET VPN sử
dụng NTP.

42
Chương 4: Giải pháp GET VPN

Hình 4.10 Time-based anti-replay [1].

KS chính chịu trách nhiệm cho thiết lập và duy trì psudo-time cho nhóm. KS chính
cũng phải giữ pseudo-time đồng bộ trên tất cả GMs qua việc cập nhật rekey. Sau khi VPN
gateway nhận được gói tin thì so sánh Time stamp trong gói tin nhận được với đồng hồ
pseudo-time GM. Nếu các gói tin đến quá muộn thì bị loại bỏ.

Hình 4.11 Đóng gói không sử dụng Time-Based Anti-Replay [6].

Hình 4.12 Đóng gói sử dụng Time-Based Anti-Replay [6].

43
Chương 4: Giải pháp GET VPN

4.3 Hoạt động của GET VPN

4.3.1 Hoạt động IKE và đóng gói ESP


Internet Key Exchange (IKE) là một phương pháp trao đổi keys với mục đích thiết
lập một mối quan hệ giữa các bên tham gia. Mối quan hệ này cho phép xác thực và trao
đổi an toàn dữ liệu đã mã hóa. IKE chia thành hai phase riêng biệt.

IKE phase 1: Thiết lập một cách an toàn kênh truyền xác thực. Mặc định router
Cisco thực hiện phase này trong chế độ Main mode. Ngoài ra còn có chế độ Aggressive
mode kém an toàn hơn nhưng thiết lập nhanh hơn cho chứng thực IKE. Cấu hình IKE
phase 1 dùng ISAKMP là giao thức thực hiện việc thiết lập, thỏa thuận và quản lý chính
sách bảo mật SA.

Hình 4.13 Trao đổi IKE Main mode [3].

Trong Phase 1 có sáu gói tin trao đổi, nội dung của gói tin khác nhau nếu sử dụng
phương pháp xác thực Pre-shared Keys (PSKs) hoặc Public Key Infrastucture (PKI). Sử
dụng PKI khi thỏa thuận thành công thì cả bên gửi và bên nhận sẽ nhận được một chứng
nhận từ CA (certificate authority), cả hai có một bản sao của public key của CA. Còn sử
dụng PSKs thì hai bên trao đổi cho nhau một secret key.

44
Chương 4: Giải pháp GET VPN

Hai gói tin đầu tiên thỏa thuận chính sách an ninh (SA) IKE, hai gói tin tiếp theo
thiết lập kênh an toàn và hai gói tin cuối cùng xác thực bên tham gia.

Hình 4.14 Phase 1 sử dụng PSKs [3].

Khi sử dụng PKI trong phần trao đổi hai gói tin cuối cùng xác thực thì bên gửi sẽ
gửi giấy chứng nhận của họ. Thông điệp này được ký với Private key của bên gửi và xác
nhận với Public key của bên nhận. Chứng nhận của bên gửi được xác thực bằng cách sử
dụng Public key của CA.

45
Chương 4: Giải pháp GET VPN

Hình 4.15 Phase 1 sử dụng PKI [3].

IKE phase 2: Thỏa thuận các chính sách an ninh (SA) của mặt phẳng dữ liệu, thỏa
thuận về thông số IPsec và được bảo vệ bởi kênh truyền được thiết lập trong Phase 1.
Phase 2 sử dụng chế độ Quick mode và định kỳ thay đổi SAs tăng cường an ninh.

Phase 2 trao đổi ba gói tin, hai gói tin đầu trao đổi thông tin về SA, gói tin thứ ba
xác nhận và giữ cho thông điệp sống. Mỗi gói tin được bảo vệ bởi kênh an toàn IKE. Các
thông số thỏa thuận trong Phase 2 bao gồm: giao thức đóng gói ESP, mode hoạt động,
thời gian sống của SAs, trao đổi keys, chứng thực gói tin, chính sách mã hóa nhóm keys,
thời gian sống keys.

46
Chương 4: Giải pháp GET VPN

Hình 4.16 Thỏa thuận IKE Quick mode [3].

Encapsulation Security Payload (ESP): là giao thức bảo mật dùng để mã hóa, xác
thực và bảo đảm tính toàn ven dữ liệu. Sau khi đóng gói xong bằng ESP thì mọi thông tin
mã hóa và giải mã nằm trong ESP header.

Hình 4.17 Đóng gói ESP trong GET VPN [6].

47
Chương 4: Giải pháp GET VPN

4.3.2 Quá trình hoạt động của GET VPN


 Bước 1: Group Members (GMs) đăng kí với Key Server (KS) thông qua GDOI
(IKE).
KS xác thực và cho phép GMs hoạt động, sau đó cung cấp IPsec SAs và KEK key,
TEK key cho GMs sử dụng.

Hình 4.18 GMs đăng kí với KS [6].

 Bước 2: Mã hóa mặt phẳng dữ liệu

GMs trao đổi dữ liệu mã hóa sử dụng nhóm keys nhận từ KS, trao đổi dữ liệu sử
dụng IPsec tunnel mode với IP tunnel header preservation.

Hình 4.19 Trao đổi dữ liệu [6].

48
Chương 4: Giải pháp GET VPN

Hình 4.20 Giải mã thông tin nhận được trên GM [6].

GM sau khi nhận gói tin thì dùng TEK giải mã và so sánh với Time Stamp
để loại bỏ gói tin quá sớm hoặc muộn để chống tân công kiểu Anti-replay. Sau khi
gói tin được chấp nhận thì tiếp tục so sánh original header của gói tin với header
Payload để nhận dữ liệu.

49
Chương 4: Giải pháp GET VPN

 Bước 3: Định kì Rekey

KS cung cấp keys thay thế keys hiện tại trước khi chính sách SA hết hạn. Gọi là
rekey

Hình 4.21 Rekey [6].

50
Chương 5: Cấu hình GET VPN

Chƣơng 5: Cấu hình GET VPN

5.1 Phƣơng pháp chứng thực.


GET VPN có 2 phương pháp chứng thực:

 Pre-Shared Keys (PKSs)


 Public Key Infrastructure (PKI).

PKSs sử dụng “secret key” được trao đổi giữa các bên tham gia thông qua một số kênh
truyền an toàn.

 Ưu điểm: Cấu hình đơn giản.


 Khuyết điểm: Cấu hình bằng tay cho mỗi kết nối VPN, các Clients không xác thực
được lẫn nhau và không có khả năng mở rộng.

Hình 5.1 Mô hình GETVPN sử dụng PSKs.

51
Chương 5: Cấu hình GET VPN

PKI yêu cầu phải có một CA (Certificate Authority) cung cấp chứng chỉ
(Certificate) cho các bên tham gia đăng kí chứng thực và các bên tham gia xác thực lẫn
nhau thông qua chứng chỉ do CA server cấp.

 Ưu điểm: Các Clients xác thực được lẫn nhau, có khả năng mở rộng và bảo mật tốt
hơn.
 Khuyết điểm: Cấu hình phức tạp hơn PKSs.

Hình 5.2 Mô hình GETVPN sử dụng PKI.

52
Chương 5: Cấu hình GET VPN

5.2 Cấu hình trên KS.

5.2.1Cấu hình IKE phase 1.


Thực hiện việc trao chứng thực và thỏa thuận các thông số bảo mật nhằm cung cấp
một kênh truyền bảo mật giữa hai đầu cuối. Các thông số sau khi thỏa thuận giữa 2 bên
gọi là chính sách bảo mật SA (Security Association).

Cấu hình gồm 2 phần: ISAKMP và Authentication method.

IKE phase 1 (ISAKMP policy):

crypto isakmp policy 10

encr aes

group 2

Authentication method: PKSs và PKI

 PKSs:
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 192.168.15.1
crypto isakmp key cisco address 192.168.26.2
 PKI:
crypto isakmp policy 10
authentication rsa-sig
Generating RSA keys:
KeyServer(config)# crypto key generate rsa general-keys label pki_KS
modulus 1024
The name for the keys will be: pki_KS
% The key modulus size is 1024 bits
% Generating 1024 bits RSA keys, key will be non-exportable...[OK]
Configuring the Router for the CA:
crypto pki trustpoint GETVPN
enrollment url http://192.168.89.9:80
subject-name OU=GETVPN
revocation-check none
rsakeypair pki_KS

53
Chương 5: Cấu hình GET VPN

Authenticating to the CA Server: Thực hiện xác thực với CA Server để nhận
chứng nhận từ CA.
KeyServer(config)# crypto pki authenticate GETVPN
Certificate has the following attributes:
% Do you accept this certificate? [yes / no]: y
Trustpoint CA certificate accept.

Enrolling to the CA Server: Yêu cầu một chứng nhận cho router từ CA Server.
KeyServer(config)# crypto pki enroll GETVPN
% Start certificate enrollment...
% Create a challenge password. You will need to verbally provide this
password to the CA Adminnistrator in order to revoke your certificate.For
security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will include: OU=GETVPN
% The subject name in the certificate will include: KeyServer
% In clude the router serial number in the subject name? [yes / no] : n
% Include an IP address in the subject name? [no] : n
Request certificate from CA? [yes / no] : y
% Certificate request sent to Certificate Authority
% The show crypto ca certificate GETVPN verbose’ command will show
the fingerprint.

5.2.2 Cấu hình các thông số IPsec


Khởi tạo chính sách mã hóa và thời gian sống của key TEK:

crypto ipsec transform-set mygdoi-trans esp-aes esp-sha-hmac

crypto ipsec profile gdoi-profile-getvpn

set security-association lifetime seconds 7200

set transform-set mygdoi-trans

54
Chương 5: Cấu hình GET VPN

5.2.3 Cấu hình GDOI Group.


Trước khi cấu hình GDOI Group, tạo RSA keys để sử dụng trong suốt quá trình rekey:

KeyServer(config)# crypto key generate rsa general-keys label KEY_KS modulus


1024 exportable

Cấu hình GDOI Group:

crypto gdoi group getvpn identity number 1234

! Xác định key server

server local

! Thời gian sống của chính sách Rekey là 24 giờ

rekey lifetime seconds 86400

rekey retransmit 40 number 2

! RSA key

rekey authentication mypubkey rsa KEY_KS

! Phương thức rekey unicast

rekey transport unicast

sa ipsec 1

! Transform-set for group members

profile gdoi-profile-getvpn

! Policies defining traffic to be encrypted

match address ipv4 199

! Chống tấn công anti-replay là 5 giây

replay time window-size 5

! Địa chỉ nguồn của rekey packet

address ipv4 192.168.38.3

55
Chương 5: Cấu hình GET VPN

5.2.4 Cấu hình Access List Policies.


Access control list (ACL) xác định các chính sách để cung cấp cho GMs, chỉ cho
GMs cấu hình trong phạm vi địa chỉ 10.1.0.0/16 sử dụng GET VPN. ACL được ánh xạ
trong cấu hình GET VPN trong phần cấu hình Unicast Rekeys, quy định gói tin nào được
lưu thông.

access-list 199 remark ACL policies pushed to authenticated group members

access-list 199 permit ip 10.1.0.0 0.0.255.255

10.1.0.0 0.0.255.255

5.3 Cấu hình trên GM.

5.3.1 Cấu hình IKE Phase 1.


Các thông số về chính sách mã hóa không yêu cầu cấu hình trên GMs mà được tải
về từ KS khi đăng kí GDOI và chứng thực thành công. Chỉ cấu hình ISAKMP để GM và
KS xác thực lẫn nhau.

 PSKs:
crypto isakmp policy 10
encr aes
lifetime 1200
authentication pre-share
group 2
crypto isakmp key cisco address 192.168.38.3
 PKI:
crypto isakmp policy 10
encr aes
group 2
authentication rsa-sig

5.3.2 Cấu hình GDOI Group.


Một GM được cấu hình sử dụng nhận dạng cùng một nhóm được xác định trên KS
và địa chỉ của KS.

crypto gdoi group getvpn

identity number 1234

! Đăng kí với Key Server chính

56
Chương 5: Cấu hình GET VPN

server address ipv4 10.1.3.3

! Nếu Key Server chính không hoạt động, đăng kí với KS phụ trong nhóm

server address ipv4 10.1.4.4

5.3.3 Cấu hình Crypto Map.


Crypto map dùng để kết nối với GDOI Group và thiết lập IPsec SA.

crypto map getvpn-map 10 gdoi

set group getvpn

5.3.4 Kích hoạt GET VPN.


interface serial 1/0

! crypto map enable on WAN interface

crypto map getvpn-map

5.4 Cấu hình COOP KS.


Gồm các bước sau:

 Tạo RSA keys cho KS chính và export cả private và public keys tới tất cả COOP
KSs. Đây là yêu cầu trong trường hợp KS xảy ra sự cố.
 Bầu chọn giữa các KS dựa trên ưu tiên trong phần cấu hình chọn KS chính .
 Định kỳ ISAKMP keepalive phải được cấu hình trên COOP KSs để các KS chính
có thể theo dõi trạng thái các KS phụ.
 Cấu hình rekey, chính sách và anti-replay phải được cấu hình giống nhau trên tất
cả KSs

5.4.1 Exporting and Importing RSA Keys.


Export RSA Keys to the terminal:

KeyServer(config)# crypto key export rsa KEY_KS pem terminal 3des passphrase

Import RSA Keys vào COO_KeySer:

COO_KeySer(config)# crypto key import rsa KEY_KS pem exportabel terminal


passphrase

57
Chương 5: Cấu hình GET VPN

5.4.2 Cấu hình Redundancy.


 KeyServer:
! enabling ISAKMP keepalives (DPD)
crypto isakmp keepalive 15 periodic
!
crypto gdoi group getvpn
server local
! Kích hoạt chức năng cooperative server
redundancy
! priority quyết định KeyServer chính
local priority 100
! Tất cả các Server khác phải được cấu hình
peer address ipv4 192.168.46.4

 COO_KeySer
!
crypto isakmp keepalive 15 periodic
!
crypto gdoi group getvpn
server local
redundancy
local priority 75
peer address ipv4 192.168.38.3

5.5 Cấu hình CA Server.


!
ip http server
!
crypto key generate rsa general-keys label GETVPN modulus 1024 exportable
!
crypto pki server GETVPN
database url nvram:
database level minimum
grant auto
no shutdown

58
Chương 5: Cấu hình GET VPN

5.6 Kết quả triển khai.

Kiểm tra kết nối GDOI giữa GMs với KS.

Hình 5.3 Gói tin đăng kí của GMs với KS.

Kiểm tra trao đổi dữ liệu giữa các GM.

Hình 5.4 Gói tin được mã hóa.

59
Chương 5: Cấu hình GET VPN

Kết quả phân tích gói tin trong mạng core: Nội dung gói tin qua mạng core được
mã hóa.

Hình 5.5 Chi tiết gói tin qua mạng core.

Thông tin về GDOI Group

Hình 5.6 Thông tin về Group và chính sách SA.

60
Chương 5: Cấu hình GET VPN

Khi xảy ra sự cố trên KeyServer thì GMs kết nối và đăng kí GDOI Group với
COO_KeySer. Sau đó đắng kí thành công thì GMs tải về các chính sách mã hóa và keys
dùng trong quá trình trao đổi và mã hóa.

Hình 5.7 Thông tin về GDOI Group khi KS xảy ra sự cố.

61
Chương 6: Tổng kết và đánh giá kết quả

Chƣơng 6: Tổng kết và đánh giá kết quả

6.1 Đánh giá về bảo mật GET VPN.


Sau khi triển khai hệ thống GET VPN trên VPN-MPLS dữ liệu được mã hóa an
toàn khi truyền qua mạng lõi của nhà cung cấp dịch vụ.

So với mô hình IPsec thì GET VPN tạo ra mô hình kết nối full-mesh mà không sử
dụng đường hầm. Khả năng quản lý tập trung các hoạt động trên Key Server, do đó giảm
bớt quá trình xử lý cho các node.

Khả năng mở rộng tốt khi có một node mới tham gia thì cấu hình đơn giản, không
phải thay đổi nhiều trên hệ thống.

Tuy nhiên GET VPN phải hoạt động trên các thiết bị hỗ trợ giao thức GDOI
(Cisco). Đồng thời khó triển khai hệ thống trên Internet vì đòi hỏi các địa chỉ tham gia
phải định tuyến được.

6.2 Hƣớng phát triển luận văn.


Kết hợp với kỹ thuật lưu lương (Traffic Enginering) và chất lượng dịch vụ (QoS)
tạo hệ thống mạng hoàn chỉnh cho doanh nghiệp.

Đồng thời kết hợp xây dựng hệ thống CA(Certification Authority) hoàn chỉnh dễ
dàng quản lý và mở rộng hệ thống PKI (Public Key Infrastruture).

62
TÀI LIỆU THAM KHẢO.

[1] Haseeb Niazi, Nipul Shah, Biao Zhou, Varun Sethi. Group Encrypted Transport VPN
(GET VPN) Design and Implementation Guide. (2010) Cisco Press.

[2] Luc De Ghein. MPLS Fundamentals. (2006) Cisco Press. ISBN: 1-58705-197-4

[3] Andre Karamanian, Srinivas Tenneti, Francois Dessart. PKI Uncovered, Certificate-
Based Security Solutions for Next-Generation Networks. (2011) Cisco Press. ISBN: 1-
58705-916-9.

[4] Yusuf Bhaiji. CCIE Professional Development Series Network Security Technologies
and Solutions. (2008). Cisco Press. ISBN: 1-58705-246-6.

[5] Sean Wilkins, Franklin H. Smith III. CCNP Security SECURE 642-637 Official Cert
Guide. (2011) Cisco Press. ISBN: 1-58714-280-5

[6] Scott Wainner. Lecture Advanced Site-to-Site with GET VPN. (2008)

[7] www.cisco.com

[8] www.gns3.net

[9] www.wikipedia.com

63

You might also like