BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

ThS.LÊ QUANG TÙNG, KS.NGUYỄN THỊ HỒNG HÀ

GIÁO TRÌNH

CHỨNG THỰC ĐIỆN TỬ

HÀ NỘI, 2013
 BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

ThS.LÊ QUANG TÙNG, KS.NGUYỄN THỊ HỒNG HÀ

GIÁO TRÌNH

CHỨNG THỰC ĐIỆN TỬ

HÀ NỘI, 2013
 MỤC LỤC

MỤC LỤC.................................................................................................................3

DANH MỤC HÌNH VẼ............................................................................................9

DANH MỤC CHỮ VIẾT TẮT...............................................................................12

DANH MỤC BẢNG BIỂU.....................................................................................13

LỜI NÓI ĐẦU.........................................................................................................14

Chương 1. CÁC KHÁI NIỆM CƠ BẢN.............................................................16

1.1. AN TOÀN THÔNG TIN.........................................................................16

1.1.1. Khái niệm về an toàn thông tin..........................................................16

1.1.2. Khái niệm về đảm bảo an toàn thông tin...........................................16

1.1.3. Khái niệm về đánh giá an toàn thông tin...........................................17

1.1.4. Những đặc tính cơ bản của thông tin cần được đảm bảo..................18

1.1.5. Mô hình tổng quát về các biện pháp đảm bảo an toàn thông tin.......19

1.1.6. Nhu cầu về đánh giá an toàn thông tin và các tiêu chí đánh giá chung
20

1.2. GIAO DỊCH ĐIỆN TỬ...........................................................................21

1.3. CHÍNH PHỦ ĐIỆN TỬ...........................................................................22

1.3.1. Một số khái niệm chính phủ điện tử..................................................22

1.3.2. Các chức năng của Chính phủ điện tử...............................................23

1.3.3. Mục tiêu của Chính phủ điện tử........................................................23

1.3.4. Các giao dịch điện tử cơ bản trong chính phủ điện tử:......................23

1.3.5. Ưu nhược điểm của Chính phủ điện tử.............................................24

1.4. MẬT MÃ TRONG AN TOÀN THÔNG TIN.........................................24

 1.4.1. Mật mã khóa đối xứng.......................................................................27

1.4.2. Mật mã khóa công khai.....................................................................29

Chương 2. CÁC LÝ THUYẾT CƠ BẢN VỀ HỆ THỐNG PKI........................32

2.1. GIỚI THIỆU CHUNG.............................................................................32

2.1.1. Tại sao cần có cơ sở hạ tầng khóa công khai PKI.............................33

2.1.2. Tổng quan về PKI..............................................................................34

2.1.3. Các chuẩn và đặc tả PKI....................................................................43

2.2. CÁC DỊCH VỤ CỦA PKI.......................................................................45

2.2.1. Dịch vụ đảm bảo tính bí mật.............................................................46

2.2.2. Dịch vụ đảm bảo tính toàn vẹn..........................................................47

2.2.3. Dịch vụ xác thực................................................................................50

2.2.4. Dịch vụ dấu thời gian........................................................................54

2.3. CHỮ KÝ SỐ VÀ CHỨNG THƯ SỐ......................................................56

2.3.1. Chữ ký số...........................................................................................57

2.3.2. Chứng thư số.....................................................................................59

2.3.3. Giới thiệu về các chứng thư khoá công khai.....................................60

2.4. CÁC MÔ HÌNH KIẾN TRÚC TIN CẬY...............................................63

2.4.1. Giới thiệu về kiến trúc hệ thống PKI.................................................63

2.4.2. Mô hình tổng thể hệ thống PKI.........................................................65

2.4.3. Hệ thống kiến trúc đơn......................................................................67

2.4.4. Hệ thống kiến trúc cho doanh nghiệp (thương mại)..........................68

2.4.5. Đường dẫn chứng thực......................................................................79

Chương 3. QUY TRÌNH HOẠT ĐỘNG CỦA HỆ THỐNG PKI......................82

 3.1. CHỨC NĂNG CỦA CÁC THÀNH PHẦN TRONG HỆ THỐNG PKI 82

3.1.1. Thành phần CA (Certification Authority).........................................83

3.1.2. Thành phần RA (Registration Authority)..........................................84

3.1.3. Thành phần VA (Varidation Authority)............................................86

3.1.4. Người sử dụng/thực thể đầu cuối (End Entities – EE)......................86

3.1.5. Chức năng của các hệ thống dịch vụ chứng thực chữ ký số..............87

3.2. QUY TRÌNH QUẢN LÝ VÒNG ĐỜI CHỨNG THƯ SỐ.....................88

3.2.1. Hoạt động đăng ký chứng thư số và cơ quan đăng ký.......................89

3.2.2. Quản lý, duy trì khóa và chứng thư số..............................................92

3.2.3. Công bố chứng thư số........................................................................97

3.2.4. Các phương pháp hủy bỏ chứng thư số...........................................100

3.3. BÀI THỰC HÀNH SỐ 1.......................................................................112

Chương 4. MỘT SỐ GIAO THỨC QUẢN LÝ PKI VÀ CÁC CHUẨN LIÊN

QUAN 113

4.1. CÁC GIAO THỨC QUẢN LÝ PKI......................................................113

4.1.1. Các chuẩn PKCS.............................................................................113

4.1.2. Giao thức quản lý chứng thư số (CMP)..........................................123

4.1.3. Giao thức đăng ký chứng thư số đơn giản(SCEP)..........................126

4.2. NHÓM CHUẨN VỀ KHUÔN DẠNG CHỨNG THƯ SỐ VÀ CRL...129

4.2.1. Chứng thư số X.509 version 3.........................................................129

4.2.2. Danh sách chứng thư số bị thu hồi (CRL) và hồ sơ các trường mở
rộng của CRL................................................................................................142

4.2.3. Các trường CRL mở rộng................................................................147

4.3. NHÓM CHUẨN VỀ GIAO THỨC HOẠT ĐỘNG..............................151

4.3.1. RFC 2585 – Internet X.509 Public Key Infrastructure Operational

Protocols: FTP and HTTP.............................................................................151

4.3.2. Quy ước FTP...................................................................................154

4.3.3. Quy ước HTTP................................................................................155

4.3.4. Đăng ký MIME................................................................................155

4.4. NHÓM CHUẨN VỀ GIAO THỨC QUẢN LÝ....................................158

4.4.1. Giới thiệu Internet X.509 Public Key Infrastructure Certificate

Request Message Format (CRMF)................................................................158

4.4.2. Tổng quan........................................................................................158

4.4.3. Cấu trúc CertReqMessage...............................................................159

4.4.4. Chứng minh tính sở hữu (Proof of Possesion – POP).....................159

4.4.5. Cú pháp CertReq.............................................................................160

4.4.6. Cú pháp thuộc tính kiểm soát (Controls syntax).............................161

4.4.7. Kiểm soát RegInfo (RegInfo Controls)...........................................164

4.4.8. Object Identifiers.............................................................................165

4.5. NHÓM CHUẨN VỀ CHÍNH SÁCH....................................................166

4.5.1. Chính sách chứng thư......................................................................167

4.5.2. Quy chế chứng thực.........................................................................169

4.5.3. Mối quan hệ giữa chính sách chứng thư và quy chế chứng thực....170

4.6. NHÓM CHUẨN VỀ DẤU THỜI GIAN VÀ CHỨNG THỰC DỮ LIỆU

170

4.6.1. Giới thiệu.........................................................................................171

4.6.2. Khái niệm chung..............................................................................172

 4.6.3. Các chính sách gắn nhãn thời gian..................................................174

4.6.4. Nghĩa vụ và trách nhiệm..................................................................175

4.6.5. Những yêu cầu về nghiệp vụ TSA..................................................176

4.6.6. Những xem xét đến an ninh.............................................................183

4.7. BÀI THỰC HÀNH SỐ 2.......................................................................184

Chương 5. MỘT SỐ HỆ THỐNG PKI ĐIỂN HÌNH VÀ CÁC ỨNG DỤNG

CỦA PKI 185

5.1. CÁC HỆ THỐNG PKI ĐIỂN HÌNH.....................................................185

5.1.1. Hệ thống mã đóng...........................................................................185

5.1.2. Giải pháp của Entrust......................................................................198

5.1.3. Hệ thống mã mở..............................................................................206

5.2. CÁC ỨNG DỤNG PKI.........................................................................216

5.2.1. Ứng dụng của PKI trong bảo mật thư điện tử S/MIME..................216

5.2.2. Ứng dụng của PKI trong hệ thống mạng riêng ảo VPN..................217

5.2.3. Ứng dụng của PKI trong việc bảo mật kênh SSL...........................218

5.2.4. Ứng dụng của PKI trong hệ thống Single Sign On.........................223

5.3. CÁC THIẾT BỊ PHẦN CỨNG AN TOÀN (HSM, USB TOKEN)......224

5.3.1. Vai trò của các thiết bị phần cứng an toàn trong hệ thống PKI.......224

5.3.2. Thiết bị an toàn cá nhân USB Token...............................................231

5.3.3. Thiết bị an toàn cho hệ thống PKI HSM.........................................231

5.4. BÀI THỰC HÀNH SỐ 3.......................................................................232

5.4.1. Sử dụng các chứng thư số để ký số mã hóa các tài liệu điện tử dạng
PDF, Word, thư điện tử,…............................................................................232
Chương 6. HÀNH LANG PHÁP LÝ PKI Ở VIỆT NAM VÀ XU HƯỚNG
PHÁT TRIỂN PKI................................................................................................233

6.1. MÔ HÌNH PKI TẠI VIỆT NAM..........................................................233

6.2. HÀNH LANG PHÁP LÝ......................................................................234

6.2.1. Luật giao dịch điện tử số 51/2005/QH11........................................235

6.2.2. Nghị định 26/2007/NĐ-CP..............................................................242

6.3. XU HƯỚNG PHÁT TRIỂN..................................................................243

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

 DANH MỤC HÌNH VẼ

Hình 1-1: Cơ sở cho một mô hình tổng quát...........................................................18

Hình 1-2: Mô hình mã hóa thông thường................................................................25

Hình 1−3: Secret key cryptography.........................................................................26

Hình 1−4: Mật mã khóa công khai..........................................................................28

Hình 2-1: Mô hình tổng thể của PKI.......................................................................33

Hình 2-2: Tổ chức liên lạc bí mật............................................................................44

Hình 2.3- Sử dụng mã khối đối xứng DES-CBC-MAC..........................................46

Hình 2.4- sử dụng hàm băm mật mã HMAC-SHA-1..............................................46

Hình 2-6: Chữ ký số xác định tính xác thực và chống chối bỏ...............................48

Hình 2-7: Bob xác thực với Alice, sử dụng xác thực từ xa dựa trên khoá công khai
.................................................................................................................................51

Hình 2-8: Dịch vụ dấu thời gian..............................................................................53

Hình 2-9: Mô hình tạo dấu thời gian an toàn..........................................................54

Hình 2-10 : Kiểm tra tính hợp lệ của dấu thời gian an toàn....................................54

Hình 2-11: Hàm băm...............................................................................................55

Hình 2-12: Cách tạo chữ ký số................................................................................56

Hình 2-13: Kiểm tra chữ ký số................................................................................57

Hình 2-14: Chứng thư khóa công khai đơn giản.....................................................60

Hình 2-15: Đường dẫn chứng thực..........................................................................63

Hình 2-16: Mô hình kiến trúc CA đơn....................................................................66

Hình 2-17: Kiến trúc phân cấp...............................................................................68

Hình 2-18: Thêm CA mới làm CA gốc...................................................................69

Hình 2-19: Kiến trúc mạng lưới..............................................................................72

Hình 2-20: Hệ thống lai...........................................................................................73

Hình 2-21: Kiến trúc danh sách tin cậy mở rộng....................................................74

Hình 2-22: Kiến trúc chứng thực chéo....................................................................75

Hình 2-23: Kiến trúc CA cầu nối............................................................................77

Hình 2-24: Đường dẫn chứng thực..........................................................................79

Hình 3-1: Các thành phần của một hạ tầng khoá công khai...................................82

Hình 3-2: Quá trình đăng ký...................................................................................90

Hình 3-3: Định dạng CRL phiên bản 2.................................................................102

Hình 3-4: Thông tin chứng thư số bị thu hồi.........................................................103

Hình 3-5:Xác minh bằng CRL chuyển hướng.......................................................108

Hình 3-6: OCSP.....................................................................................................109

Hình 4-1: Khuôn dạng chứng thư trong phiên bản 1 và 2 của X.509...................130

Hình 4-2 : Tên phân biệt........................................................................................132

Hình 4-3: Mối quan hệ giữa các chính sách..........................................................165

Hình 4-4: Quản lý dịch vụ gán nhãn thời gian......................................................182

Hình 5-1: Kiến trúc giải pháp RSA Certificate Manager Solution.......................184

Hình 5-2: Các thành phần giải pháp RSA Certificate Manager............................191

Hình 5-3: Các ứng dụng tương thích với Entrust PKI...........................................197

Hình 5-4: Kiến trúc tổng thể hệ thống Entrus PKI................................................197

Hình 5-5: Security Manager Administration.........................................................199

Hình 5-6: Entrust Authority Administration Service............................................200

Hình 5-7: Kiến trúc PKI phân tán..........................................................................206

Hình 5-8: Kiến trúc nền tảng của OpenCA...........................................................207

Hình 5-9 Các giao diện nút của OpenCA.............................................................208

Hình 5-10: Vòng đời của các đối tượng................................................................210

Hình 5-11: Kiến trúc của EJBCA..........................................................................213

Hình 5-12: Quá trình bắt tay của giao thức SSL...................................................219

Hình 5-13: Mô hình kết nối sử dụng SSL.............................................................220

Hình 5-14: Đăng nhập tới nhiều ứng dụng ở xa....................................................221

Hình 6-1: Mô hình PKI ở Việt Nam......................................................................231

 DANH MỤC CHỮ VIẾT TẮT

SSL Secure Socket Layer

PKI Public Key Infrastructure

CNTT Công nghệ thông tin

CPĐT Chính phủ điện tử

G2C Government to Customer

G2B Government to Business

G2G Government to Government

 DANH MỤC BẢNG BIỂU

Bảng 3.1: LDAPv2 và LDAPv3.............................................................................97

Bảng 5.1: Bảng thông số kỹ thuật của hệ thống Entrust.......................................203

Bảng 5.2: Các chuẩn hỗ trợ trong Entrust PKI......................................................204

Bảng 5.3: Các loại thuật toán sử dụng...................................................................204

 LỜI NÓI ĐẦU

Trong những năm trở lại đây, hạ tầng CNTT ngày càng mở rộng và phát triển
mạnh mẽ khi các tổ chức, người dùng sử dụng nền tảng CNTT để trao đổi và liên
lạc với nhau. Các thông tin nhạy cảm, bí mật và quan trọng cũng được lưu trữ và
trao đổi dưới hình thức điện tử để đảm bảo việc truyền nhận một cách nhanh
chóng, tiện lợi. Sự sang trang từ truyền thống đến điện tử của hoạt động truyền
thông đã mở ra nhiều cơ hội cho các doanh nghiệp, tổ chức, nhưng cũng gặp nhiều
các thách thức không nhỏ với sự can thiệp, tấn công phá hoại hoặc ý thức người
dùng với các thông tin nhạy cảm và quan trọng. Trước vấn đề được đặt ra, cơ sở hạ
tầng khóa công khai (PKI – Public Key Infrastructure) đang được coi là một giải
pháp mang tính tổng hợp để giúp giải quyết các vấn đề bảo đảm an toàn dữ liệu
nhạy cảm.

Trên thế giới PKI đang được hoàn thiện, đầu tư và xây dựng để dần hiện thực hóa,
với nhiều chuẩn bảo mật trên mạng internet như SSL/TLS, VPN hay các thiết bị
phần cứng HSM, USB Token thì PKI đang ứng dụng rộng rãi trong mọi hoạt động
cuộc sống như giao dịch điện tử, chứng minh thư điện tử, hộ chiếu điện tử,… Và
tầm quan trọng của chứng thư số và chữ ký số luôn là vấn đề mang tính thời sự
trong mọi thời điểm.

Giáo trình được thực hiện với mục đích tìm hiểu và nghiên cứu về PKI bao gồm
các vấn đề cơ bản về mật mã, chứng thư số, khái niệm tổng của PKI, chức năng và
các thành phần của PKI cũng như mô hình tin cậy, các dịch vụ, giao thức, bộ tiêu
chuẩn PKCS. Nhóm tác giả cũng giới thiệu các mô hình hệ thống PKI đóng và mở
được sử dụng phổ biến hiện nay như EntrustPKI, OpenCA, EJBCA đồng thời trình
bày sơ lược các ứng dụng PKI trong VPN, SSL, S/MIME,… và các thiết bị phần
cứng an toàn.

Với giới hạn những vấn đề tìm hiểu và nghiên cứu, giáo trình gồm 06 chương cụ
thể như sau:
- Chương 1: Các khái niệm cơ bản
Nhắc lại một số kiến thức về mật mã và an toàn thông tin trong lĩnh vực hoạt động
điện tử
- Chương 2: Các lý thuyết cơ bản về hệ thống PKI
Nêu tổng quan và các khái niệm của PKI. Giới thiệu các dịch vụ, kiến trúc tin cậy
của PKI. Đồng thời giới thiệu về chứng thư số và chữ ký số
- Chương 3: Quy trình hoạt động của hệ thống PKI
Giới thiệu các chức năng thành phần tham gia vào hệ thống PKI, và vấn đề quản lý
vòng đời chứng thư số như: đăng ký chứng thư số, quản lý duy trì khóa, công bố và
hủy bỏ chứng thư số.
- Chương 4: Một số giao thức quản lý PKI và các chuẩn liên quan
Giới thiệu các giao thức quản lý PKI, các nhóm chuẩn về khuôn dạng chứng thư
số, CRL, các nhóm chuẩn về giao thức hoạt động, quản lý, chính sách và dấu thời
gian
- Chương 5: Một số hệ thống PKI điển hình và các ứng dụng của PKI
Giới thiệu 1 số các hệ thống PKI điển hình như Entrust, Verisign, OpenCA,…
Nêu lên ứng dụng của PKI trong việc bảo mật thư điện tử, VPN, kênh truyền…
đồng thời giới thiệu các thiết bị phần cứng an toàn chuyên dùng cho PKI
- Chương 6: Hành lang pháp lý PKI ở Việt Nam và xu hướng phát triển PKI.

Các kiến thức trên nhằm giúp cho người đọc có thể khái quát hơn về hệ thống PKI
để giúp vận dụng xây dựng một hệ thống cung cấp chứng thư số có khả năng ứng
dụng an toàn cho cơ quan, tổ chức theo các nhu cầu được đặt ra. Tuy nhiên, các
thiếu sót là điều không thể tránh khỏi trong giáo trình, nhóm tác giả rất mong nhận
được những góp ý chân thành của đồng nghiệp và bạn đọc để giúp hoàn thiện giáo
trình một cách tốt nhất.

Hà nội, tháng 09 năm 2013

Nhóm tác giả

 Chương 1. CÁC KHÁI NIỆM CƠ BẢN
1.1. AN TOÀN THÔNG TIN

1.1.1. Khái niệm về an toàn thông tin

Thông tin được lưu trữ bởi các sản phẩm và hệ thống CNTT là một tài nguyên
quan trọng cho sự thành công của tổ chức đó, là tài sản của một cá nhân hay tổ
chức. Các thông tin cá nhân lưu trữ trong hệ thống thông tin cần được giữ bí mật,
bảo vệ và không bị thay đổi khi không được phép. Trong khi các sản phẩm và hệ
thống CNTT thực hiện các chức năng của chúng, các thông tin cần được kiểm soát
để đảm bảo chúng được bảo vệ chống lại các nguy cơ, ví dụ như việc phổ biến và
thay đổi thông tin không mong muốn và trái phép, nguy cơ mất mát thông tin.
An toàn thông tin là an toàn kỹ thuật cho các hoạt động của các cơ sở hạ tầng
thông tin, trong đó bao gồm an toàn phần cứng và phần mềm theo các tiêu chuẩn
kỹ thuật do nhà nước ban hành; duy trì các tính chất bí mật, toàn vẹn, chính xác,
sẵn sàng phục vụ của thông tin trong lưu trữ, xử lý và truyền tải trên mạng (theo
định nghĩa trong Nghị định 64-2007/NĐ-CP).
Thuật ngữ an toàn CNTT thường sử dụng để chỉ việc ngăn chặn và làm giảm
nhẹ các mối nguy hại tương tự đối với các sản phẩm và hệ thống CNTT.

1.1.2. Khái niệm về đảm bảo an toàn thông tin

Mục tiêu hướng tới của người dùng là bảo vệ các tài sản nói trên. Tuy nhiên,
các sản phẩm và hệ thống thường luôn tồn tại những điểm yếu dẫn đến những rủi
ro có thể xảy ra, làm tổn hại đến giá trị tài sản thông tin. Các đối tượng tấn công
(tin tặc) có chủ tâm đánh cắp, lợi dụng hoặc phá hoại tài sản của các chủ sở hữu,
tìm cách khai thác các điểm yếu để tấn công, tạo ra các nguy cơ và các rủi ro cho
các hệ thống.
Với các biện pháp an toàn thông tin người dùng có được công cụ trong tay để
nhận thức được các điểm yếu, giảm thiểu các điểm yếu, ngăn chặn các nguy cơ tấn
công, làm giảm các yếu tố rủi ro. Như vậy, các biện pháp và kỹ thuật đảm bảo an
toàn thông tin chính là mang lại sự tin cậy cho các sản phẩm và hệ thống.
Đảm bảo an toàn thông tin là đảm bảo an toàn kỹ thuật cho hoạt động của các
cơ sở hạ tầng thông tin, trong đó bao gồm đảm bảo an toàn cho cả phần cứng và
phần mềm hoạt động theo các tiêu chuẩn kỹ thuật do nhà nước ban hành; ngăn
ngừa khả năng lợi dụng mạng và các cơ sở hạ tầng thông tin để thực hiện các hành
vi trái phép gây hại cho cộng đồng, phạm pháp hay khủng bố; đảm bảo các tính
chất bí mật, toàn vẹn, chính xác, sẵn sàng phục vụ của thông tin trong lưu trữ, xử
lý và truyền tải trên mạng.
Như vậy khái niệm đảm bảo an toàn thông tin bao hàm đảm bảo an toàn cho cả
phần cứng và phần mềm. An toàn phần cứng là bảo đảm hoạt động cho cơ sở hạ
tầng thông tin. An toàn phần mềm gồm các hoạt động quản lý, kỹ thuật nhằm bảo
vệ hệ thống thông tin, đảm bảo đảm cho các hệ thống thực hiện đúng chức năng,
phục vụ đúng đối tượng một cách sẵn sàng, chính xác, tin cậy. An toàn công nghệ
thông tin là đảm bảo an toàn kỹ thuật cho các sản phẩm, dịch vụ và hệ thống công
nghệ thông tin.

1.1.3. Khái niệm về đánh giá an toàn thông tin

Một nhu cầu thực tế đặt ra là làm thế nào để biết các sản phẩm và hệ thống có
tin cậy hay không, có áp dụng các biện pháp và kỹ thuật an toàn phù hợp hay
không, mức độ an toàn như thế nào? Đánh giá an toàn thông tin chính là để đáp
ứng nhu cầu đó, nhằm cung cấp bằng chứng về việc đảm bảo an toàn cho các sản
phẩm và hệ thống.
Mặt khác, nhiều người tiêu dùng CNTT không có đủ kiến thức, chuyên môn và
tài nguyên cần thiết để phán xét về sự an toàn của các sản phẩm và hệ thống CNTT
có phù hợp hay không, và cũng không thể chỉ dựa vào cam kết của các nhà phát
triển. Bởi vậy, người tiêu dùng có thể nâng cao tin cậy trong các biện pháp an toàn
của một sản phẩm hoặc hệ thống CNTT bằng cách đặt hàng phân tích về an toàn
cho chúng, nghĩa là đánh giá an toàn.
 1.1.4. Những đặc tính cơ bản của thông tin cần được đảm bảo

An toàn thông tin yêu cầu nhằm đảm bảo 3 đặc điểm quan trọng nhất của thông
tin, đó là: tính bí mật, tính toàn vẹn và tính sẵn sàng. Các đặc điểm này bao trùm
toàn bộ phạm trù an toàn các hệ thông thông tin. Các đặc điểm này cũng đúng với
mọi tổ chức, không lệ thuộc vào việc chúng chia sẻ thông tin như thế nào.

Tính bí mật
Tính bí mật là tâm điểm chính của mọi giải pháp an toàn cho một sản phẩm/hệ
thống CNTT. Một giải pháp an toàn là tập hợp các quy tắc xác định quyền được
truy cập đến với thông tin đang tìm kiếm, đối với một số lượng người sử dụng
thông tin nhất định và một số lượng thông tin là tài sản nhất định. Trong trường
hợp kiểm soát truy cập cục bộ, nhóm người truy cập sẽ được kiểm soát xem là họ
đã truy cập những số liệu nào. Tính bí mật là sự đảm bảo rằng các chức năng kiểm
soát truy cập có hiệu lực.
Đảm bảo tính bí mật là nhằm loại bỏ những sự truy cập không đựợc phép vào
các khu vực là độc quyền của các cá nhân, tổ chức.

Tính toàn vẹn

Tính toàn vẹn, không bị sửa đổi là đặc tính phức hợp nhất và dễ bị hiểu lầm của
thông tin. Một định nghĩa khái quát hơn được sử dung ở trong tài liệu này là vấn đề
cấp độ là chất lượng của số liệu (thông tin), chứ không phải là con người được/
hoặc không được phép truy cập. Đặc tính toàn vẹn được hiểu là chất lượng của
thông tin được xác định căn cứ vào độ xác thực khi phản ánh thực tế. Số liệu càng
gần với thực tế bao nhiêu thì chất lượng thông tin càng chuẩn bấy nhiêu.
Để đảm bảo tính toàn vẹn của thông tin là môt loạt các các biện pháp đồng bộ
nhằm hỗ trợ và đảm bảo tính thời sự kịp thời và sự đầy đủ trọn vẹn, cũng như sự
bảo mật hợp lý cho thông tin.

Tính sẵn sàng

Tính sẵn sàng của thông tin cũng là một đặc tính quan trọng, không khác gì các
đặc tính đã đề cập đến ở. Đó là khía cạnh sống còn của an toàn thông tin, đảm bảo
cho thông tin đến đúng địa chỉ (người được phép sử dụng) khi có nhu cầu, hoặc
được yêu cầu.
 Tính sẵn sàng đảm bảo độ ổn định đáng tin cậy của thông tin, cũng như đảm
nhiệm chức năng là thước đo, xác định phạm vi tới hạn của an toàn một hệ thống
thông tin.

1.1.5. Mô hình tổng quát về các biện pháp đảm bảo an toàn thông tin

Bộ ba các đặc tính then chốt của thông tin đề cập đến ở trên bao trùm toàn bộ
các mặt của việc đảm bảo an toàn thông tin. Một ma trận được tạo nên bởi 3 yếu tố
là 3 trạng thái của thông tin (truyền dẫn, lưu giữ, xử lí) được minh họa ở trục
hoành; cùng với 3 đăc tính then chốt của thông tin (độ tin cậy, tính toàn vẹn, tính
sẵn sàng) được minh họa trên trục tung có thể được sử dụng làm nền tảng cho mô
hình thể hiện các biện pháp an toàn thông tin được trình bày trong phạm vi tài liệu
này (xem hình 1-1).

Hình 1-1: Cơ sở cho một mô hình tổng quát

Các biện pháp an toàn hệ thông thông tin được phân loại thành 3 lớp như sau,
tạo thành chiều thứ 3 của không gian ma trận:
 Các biện pháp công nghệ: bao hàm tất cả các biện pháp thiết bị phần cứng,
các phần mềm, phần sụn (firmware) cũng như các kỹ thuật công nghệ liên quan
được áp dụng nhằm đảm các yêu cầu an toàn của thông tin trong các trạng thái
của nó như đã kể trên.
 Các biện pháp về tổ chức: đưa ra các chính sách, quy định, phương thức thực
thi. Thực tế cho thấy, an toàn thông tin không chỉ đơn thuần là vấn đề thuộc
phạm trù công nghệ, kỹ thuật. Hệ thống chính sách và kiến trúc tổ chức đóng
một vai trò hữu hiệu trong việc đảm bảo an toàn thông tin.
 Các biện pháp về đào tạo, tập huấn, nâng cao nhận thức: Các biện pháp
công nghệ hay các biện pháp về tổ chức thích hợp phải dựa trên các biện pháp
đào tạo, tập huấn và tăng cường nhận thức để có thể triển khai đảm bảo an toàn
thông tin từ nhiều hướng khác nhau. Các nhà nghiên cứu và các kỹ sư cũng cần
phải hiểu rõ các nguyên lý an toàn hệ thống thông tin, thì mới mong các sản
phẩm và hệ thống do họ làm ra đáp ứng được các nhu cầu về an toàn thông tin
của cuộc sống hiện tại đặt ra.
Mô hình ma trận không gian 3 chiều kể trên có thể áp dụng làm cơ sở cho đánh
giá an toàn thông tin một cách khái quát nhất. Ví dụ, người đánh giá an toàn thông
tin cho một sản phẩm là một hệ thống thông tin sẽ phải xác định các trạng thái
thông tin trong hệ thống cần được đánh giá. Mô hình tổng quát này sẽ cho phép
xác định các trạng thái thông tin không bị lên thuộc vào bất kỳ công nghệ cụ thể
nào đang được áp dụng.

1.1.6. Nhu cầu về đánh giá an toàn thông tin và các tiêu chí đánh giá
chung

Đánh giá an toàn thông tin là một nhu cầu thực tế, giúp người dùng xác định
xem sản phẩm hoặc hệ thống CNTT có đủ an toàn và tin cậy chưa khi đưa vào sử
dụng, các rủi ro an toàn tiềm ẩn khi sử dụng có chấp nhận được hay không, hoặc
các sản phẩm và hệ thống có áp dụng các biện pháp và kỹ thuật an toàn phù hợp
hay không, mức độ an toàn như thế nào. Ngoài ra, việc đánh giá an toàn thông tin
còn giúp các doanh nghiệp trong việc phát triển các sản phẩm và hệ thống CNTT
đảm bảo các yêu cầu về an toàn thông tin.
Thực tế cho thấy, một mô hình tổng thể cho đánh giá an toàn thông tin hết sức
cần thiết. Mô hình này không những đáp ứng nhu cầu đảm bảo an toàn các hệ
thống thông tin, mà đồng thời còn là một phương tiện hữu hiệu để khảo sát qui
hoạch, phát triển hệ thống và đánh giá kết quả.
Mô hình tổng thể cần có khả năng vận hành không phụ thuộc vào tình trạng
phát triển của công nghệ. Các phương pháp nêu ra trong mô hình phải là cơ sở
chung cho mọi đối tượng và không bị hạn chế bởi những khác biệt về mô hình tổ
chức. Ngay cả khi chúng ta chỉ đề cập đến những khía cạnh ít liên quan đến kỹ
thuật của an toàn cho các hệ thống thông tin, như là các vấn đề về chính sách, mô
hình tổ chức, và nhân sự liên quan đến an toàn,… mô hình tổng thể cũng hữu ích
cho việc đánh giá an toàn thông tin về những khía cạnh này.
 Để đạt được sự so sánh hiệu quả giữa các kết quả đánh giá, các đánh giá cần
được thực hiện theo một khung của mô hình chính thức trong đó các tiêu chí đánh
giá chung (Common Criteria), các thành phần giám sát chất lượng của quá trình
đánh giá và các tổ chức có thẩm quyền đánh giá tương thích với nhau trong cùng
một ngữ cảnh đánh giá.
Sử dụng phương pháp đánh giá chung làm tăng thêm tính chính xác và
khách quan của kết quả đánh giá, song chỉ sử dụng phương pháp đánh giá chung
vẫn chưa đủ. Cần có những tiêu chí đánh giá chung và lược đồ đánh giá. Nhiều
tiêu chí đánh giá đòi hỏi có các kinh nghiệm chuyên gia và kiến thức cơ bản, nhằm
đạt được sự nhất quán và khách quan trong các kết quả đánh giá.

Để tăng cường sự nhất quán và khách quan cho các kết quả đánh giá, cần có
một quy trình công nhận/phê chuẩn. Quy trình này xem xét kỹ càng một cách độc
lập các kết quả đánh giá để đưa ra chứng nhận/ phê chuẩn về mức độ an toàn cho
các sản phẩm/ hệ thống CNTT khi vào sử dụng.

1.2. GIAO DỊCH ĐIỆN TỬ

Định nghĩa về giao dịch: một chuỗi các hoạt động trao đổi thông tin và các
công việc có liên quan nhằm thực hiện một mục tiêu xác định, có bắt đầu và kết
thúc, thực hiện giữa hai hay nhiều bên.

Công nghệ thông tin và truyền thông cùng Internet đã giúp cho con người
một phương thức giao dịch mới trong quan hệ xã hội, đó là giao dịch, quan hệ với
nhau qua phương tiện điện tử, nhất là qua mạng. Giao dịch điện tử được định
nghĩa là  giao dịch được thực hiện bằng phương tiện điện tử (Theo định nghĩa tại
Luật giao dịch điện tử số 51/2005/QH11). Cũng như quy định trong giao dịch dân
sự, giao dịch điện tử có thể là đơn phương, ví dụ: các doanh nghiệp đưa lên mạng
các bảng chào hàng, cá nhân tổ chức thiết lập các báo cáo tài chính, báo cáo công
tác để lưu,v.v.. có thể là có các bên giao dịch như: Trao đổi thư điện tử, giao kết
hợp đồng trên mạng, thảo luận, họp trên mạng... Hình thức thể hiện của giao dịch
điện tử là thông điệp dữ liệu có gắn kèm hoặc không gắn kèm chữ ký điện tử.

Nếu như trong cuộc sống hiện nay giao dịch được thể hiện qua lời nói, văn bản thì
giao dịch điện tử được thể hiện qua thư điện tử, văn bản điện tử, chứng từ điện
tử, dữ liệu điện tử... mà nhiều tài liệu quốc tế kiến nghị dùng một từ chung là
Thông điệp dữ liệu. Thực chất Thông điệp dữ liệu là một hình thức thể hiện độc
lập mới trong giao dịch, bên cạnh lời nói, văn bản viết.

1.3. CHÍNH PHỦ ĐIỆN TỬ

Vào những năm 1995-2000 chính phủ điện tử đã được các nước tiếp thu và
ứng dụng rộng rãi, thúc đẩy phát triển và ngày càng được các nước coi như một
giải pháp hữu hiệu để tăng hiệu quả làm việc của các cơ quan chính phủ, phục vụ
người dân và doanh nghiệp tốt hơn. Cho đến nay chính phủ điện tử vẫn tiếp tục
được các nước thúc đẩy phát triển mạnh mẽ, ngày càng sâu rộng hơn, các nước đã
coi phát triển chính phủ điện tử là bắt buộc.
Ngày nay, với sự bùng nổ của các phương tiện di động, băng rộng, công
nghệ, … nên nhiều nước đã đẩy mạnh phát triển chính phủ điện tử đa dạng hơn,
liên thông hơn dưới khái niệm chính phủ di động, chính phủ ở mọi lúc, mọi nơi và
trên mọi phương tiện.
Đã có rất nhiều tổ chức và chính phủ đưa ra định nghĩa “Chính phủ điện tử”. Tuy
nhiên, hiện không có một định nghĩa thống nhất về chính phủ điện tử, hay nói cách
khác, hiện không có một hình thức chính phủ điện tử được áp dụng giống nhau cho
các nước. Các tổ chức khác nhau đưa ra những định nghĩa về Chính phủ điện tử
của riêng mình.

1.3.1. Một số khái niệm chính phủ điện tử

Khái niệm phổ biến nhất: Chính phủ điện tử là chính phủ ứng dụng công nghệ
thông tin và truyền thông nhằm tăng hiệu quả hoạt động của các cơ quan chính
phủ, phục vụ người dân và doanh nghiệp tốt hơn.
Hoặc chi tiết hơn:
Chính phủ điện tử là việc các cơ quan chính phủ sử dụng công nghệ thông tin
(như máy tính, các mạng diện rộng, Internet, và sử dụng công nghệ di động) có khả
năng biến đổi những quan hệ với người dân, các doanh nghiệp, và các tổ chức khác
của Chính phủ (làm việc và trao đổi qua mạng không cần đến trực tiếp công sở).
Những công nghệ đó có thể phục vụ những mục đích khác nhau: cung cấp dịch vụ
chính phủ đến người dân tốt hơn, cải thiện những tương tác giữa chính phủ với
doanh nghiệp, tăng quyền cho người dân thông qua truy nhập đến thông tin, hoặc
quản lý của chính phủ hiệu quả hơn.
 1.3.2. Các chức năng của Chính phủ điện tử

- Thứ nhất, CPĐT đã đưa chính phủ tới gần dân và đưa dân tới gần chính
phủ.
- Thứ hai, CPĐT làm minh bạch hóa hoạt động của chính phủ, chống tham
nhũng, quan liêu, độc quyền
- Thứ ba, CPĐT giúp chính phủ hoạt động có hiệu quả trong quản lý và
phục vụ dân (cải cách hành chính và nâng cao chất lượng dịch vụ công)

1.3.3. Mục tiêu của Chính phủ điện tử

- Tạo môi trường kinh doanh tốt hơn;

- Khách hàng trực tuyến, không phải xếp hàng;
- Tăng cường sự điều hành có hiệu quả của chính phủ và sự tham gia rộng
rãi của người dân;
- Nâng cao năng suất và tính hiệu quả của các cơ quan chính phủ;
- Nâng cao chất lượng cuộc sống cho các cộng đồng vùng sâu vùng xa.

1.3.4. Các giao dịch điện tử cơ bản trong chính phủ điện tử:

Việc cung cấp thông tin, dịch vụ trực tuyến, các quan hệ tương tác của chính
phủ điện tử được xác định trong mô hình chính phủ điện tử dựa trên các quan hệ
giữa các cơ quan chính phủ, người dân, doanh nghiệp, các cán bộ, công chức, viên
chức, bao gồm các quan hệ sau:
- Chính phủ và người dân (G2C);
- Chính phủ và các doanh nghiệp (G2B);
- Giữa các cơ quan chính phủ các cấp với nhau và trong các cơ quan chính
phủ (G2G);
- Giữa các cơ quan chính quyền với các cán bộ, công chức, viên chức
(G2E).
Đôi khi người ta cũng xác định rõ cả chiều của quan hệ tương tác, như trong
quan hệ giữa chính phủ và người dân, thì có quan hệ chính phủ với người dân
(G2C) và quan hệ giữa người dân và chính phủ (C2G). Tương tự như vậy có quan
hệ giữa chính phủ và doanh nghiệp (G2B) và giữa doanh nghiệp với chính phủ
(B2G).

1.3.5. Ưu nhược điểm của Chính phủ điện tử

Lợi ích của chính phủ điện tử là đáp ứng mọi nhu cầu của công dân bằng
việc nâng cao chất lượng hoạt động của bộ máy chính quyền từ trung ương tới cơ
sở như quản lý nhân sự, quy trình tác nghiệp, v.v... Chính phủ Điện tử đem lại sự
thuận tiện, cung cấp các dịch vụ một cách hiệu quả và kịp thời cho người dân,
doanh nghiệp, các cơ quan và nhân viên chính phủ. Đối với người dân và doanh
nghiệp, chính phủ điện tử là sự đơn giản hóa các thủ tục và tăng tính hiệu quả của
quá trình xử lý công việc. Đối với chính phủ, chính phủ điện tử hỗ trợ quan hệ giữa
các cơ quan của chính quyền nhằm đảm bảo đưa ra các quyết định một cách chính
xác và kịp thời.
Tuy nhiên, việc tin học hóa hành chính cũng có thể đem lại nhiều bất lợi.
Một bất lợi cho các cơ quan có thẩm quyền sẽ là phải tăng chi phí an ninh. Để bảo
vệ sự riêng tư và thông tin mật của dữ liệu sẽ phải có các biện pháp bảo mật (để
chống các sự tấn công, xâm nhập, ăn cắp dữ liệu từ bên ngoài, hay của các hacker),
mà sẽ đòi hỏi chi phí bổ sung. Đôi khi chính quyền phải thuê mướn một cơ quan tư
nhân độc lập, khách quan để giám sát, bảo đảm sự quản lý thông tin cá nhân không
bị nhà nước lạm dụng trái hiến pháp và bảo vệ người dân cũng như cung cấp thông
tin cho người dân. Một bất lợi nữa là chức năng của hệ thống được sử dụng phải
cập nhật và nâng cấp liên tục, để thích ứng với hiện tình công nghệ mới. Các hệ
thống cũng có thể không tương thích với nhau hoặc không tương thích với hệ điều
hành hoặc không thể hoạt động độc lập (ngoại tuyến) mà không cần liên kết hay
phụ thuộc với những thiết bị khác.
Đối với người dân, việc tập hợp và lưu trữ những thông tin cá nhân của họ
có thể đưa đến việc bị kiểm soát đời sống riêng tư, bị các cơ quan nhà nước lạm
dụng; chưa kể đến việc thông tin cá nhân có thể bị rò rĩ, ăn cắp dữ liệu, lưu truyền
trái phép hay dùng cho mục đích thương mại hoặc là họ không có phương tiện hay
cơ sở pháp lý để biết (và để xin xóa) những thông tin cá nhân nào của mình đang bị
lưu trữ cũng như giám sát mức độ chính xác của thông tin

1.4. MẬT MÃ TRONG AN TOÀN THÔNG TIN

 Trong kỷ nguyên của loài người, xã hội kết nối cao mà chúng ta đang sống đã
trở thành một phần không thể thiếu. những thứ bắt đầu từ việc giao tiếp đơn giản
bằng ký tự từ nhiều thế kỷ trước đã phát triển thành nhiều dạng liên lạc khác nhau,
internet là một ví dụ điển hình cho sự phát triển này.

Các phương thức liên lạc ngày nay bao gồm:

 Liên lạc vô tuyến

 Liên lạc thoại

 Liên lạc mạng

 Thông tin di động

Các phương thức và phương tiện của liên lạc đóng vai trò quan trọng trong cuộc
sống, nhưng trong mấy năm trở lại đây, liên lạc mạng lưới, đặc biệt là qua internet,
đã nổi lên như một trong những phương tiện liên lạc mạnh mẽ nhất với sự ảnh
hưởng rất lớn đến đời sống.

Sự tiến bộ nhanh chóng trong công nghệ truyền thông cũng làm gia tăng các hiểm
họa an toàn an ninh cho cá nhân và tổ chức. Trong vòng vài năm gần đây, hàng
loại các phương pháp và dịch vụ khác nhau đã được phát triển để chống lại các
hiểm họa trên Internet.

Từ việc bảo vệ thông tin nhạy cảm quốc phòng tới việc bảo đảm thông tin cá nhân,
người ta tạo ra các vỏ bọc hay mặt nạ để bảo vệ thông tin. Một trong các phương
thức quan trọng góp phần đảm bảo an toàn cho thông tin trong quá trình truyền là
mật mã.

Mật mã giúp vượt qua các vấn đề an ninh được miêu tả ở phía trên, bao gồm cả
việc truyền, phân phát các thông điệp qua bất kỳ kênh truyền nào.

Những vấn đề cơ bản của mật mã

Mật mã là một khoa học bảo vệ dữ liệu, cung cấp cách thức và phương tiện chuyển
đổi dữ liệu sang dạng không dễ dàng đọc được, do vậy:

 Người dùng bất hợp pháp không thể truy cập dữ liệu
  Nội dung của cấu trúc dữ liệu bị ẩn

 Tính chất xác thực của dữ liệu có thể được chứng minh

 Ngăn chặn được việc sửa đổi dữ liệu trái phép

 Người khởi tạo thông điệp không thể từ chối được trách nhiệm của mình với
dữ liệu

Mật mã là một trong những phương tiện kỹ thuật dùng để cung cấp an toàn an ninh
cho dữ liệu được truyền trên hệ thống truyền thông thông tin. Mật mã cũng là một
công cụ hữu ích trong dữ liệu tài chính và cá nhân, kể cả thực tế dữ liệu được
truyền qua một môi trường trung gian hoặc được lưu trữ trên các thiết bị lưu trữ.
Mật mã cung cấp phương tiện đủ mạnh cho việc thẩm tra tính xác thực của dữ liệu
và định danh của nghi phạm khi tính toàn vẹn và bí mật của dữ liệu bị xâm phạm.
Do sự phát triển của thương mại điện tử, kỹ thuật mật mã là vô cùng quan trọng
đối với sự phát triển hệ thống thông tin quốc phòng và mạng lưới thông tin liên lạc.

Dưới đây là mô hình miêu tả các bước liên quan trong mô hình mã hóa thông
thường:

Người gửi muốn gửi thông điệp Hello tới một người nhận:

1. Bản rõ (thông điệp rõ) sẽ được biến đổi thành các bít ngẫu nhiên thông qua
việc sử dụng khóa và thuật toán để thành bản mã. Thuật toán này có thể sinh
ra giá trị đầu ra khác nhau với mỗi thời điểm sử dụng chúng , dựa trên giá trị
của khóa.

2. Bản mã được truyền trên các kênh trung gian

3. Tại nơi nhận, người nhận sử dụng thuật toán và khóa tương tự dùng trong
việc mã hóa thông điệp để giải mã bản mã thành bản rõ

4. Quá trình trên được trình bày ở hình 1-2

 Hình 1-2: Mô hình mã hóa thông thường

Tùy vào mục đích sử dụng, các kỹ thuật được phân loại dựa vào số lượng khóa
được dùng. Có 2 loại kỹ thuật chính:

 Mật mã khóa bí mật: là kỹ thuật mật mã dựa trên một khóa đơn, còn có thể
hiểu là mật mã khóa đối xứng

 Mật mã khóa công khai: là kỹ thuật mật mã dựa trên việc kết hợp 2 khóa,
khóa bí mật và khóa công khai. Kỹ thuật này còn gọi là mật mã bất đối xứng

1.4.1. Mật mã khóa đối xứng

Quá trình mã hóa và giải mã thông tin bằng cách sử dụng một khóa đơn, quá trình
này còn gọi là mật mã khóa bí mật. Trong mật mã khóa đối xứng, một khóa được
sử dụng để cùng mã hóa và giải mã dữ liệu. vấn đề chính trong thuật toán khóa đối
xứng là người gửi và người nhận phải thỏa thuật khóa chung. Một kênh truyền an
toàn phải được thiết lập để người gửi và người nhận trao đổi khóa bí mật.

Ví dụ dưới đây mô tả quá trình của mật mã khóa đối xứng. Alice muốn gửi thông
điệp “For your eyes” cho Bod và muốn đảm bảo rằng chỉ có Bob mới có thể đọc
được thông điệp đó. Để đảm bảo cho việc truyền thông điệp, Alice sinh ra một
khóa bí mật, dùng khóa bí mật này để mã hóa thông điệp của mình và gửi thông
điệp được mã hóa cho Bob. Hình 1-3 mô tả quá trình này
 Hình 1−3: Secret key cryptography

Bây giờ, để có thể đọc được thông điệp được mã hóa, Bob cần có khóa bí mật được
sinh ra bởi Alice. Alice có thể trực tiếp gửi khóa bí mật cho Bob, hoặc gửi qua bất
kỳ một phương tiện trung gian nào (email, tin nhắn). Nếu Alice gửi trực tiếp khóa
cho Bob, thì việc đó có thể làm mất nhiều thời gian do phụ thuộc vào khoảng cách
vật lý giữa 2 bên hoặc có thể do các hoàn cảnh khác. Sau khi Bob nhận được khóa
bí mật, Bob có thể giải mã thông điệp để đọc được thông điệp ban đầu. Quá trình
này có thể có khả năng bị người thứ ba xem trộm chìa khóa và có thể giải mã được
thông điệp Alice mã hóa gửi cho Bob.

Mã hóa đối xứng có thể phân thành hai nhóm phụ:

- Block ciphers: thuật toán khối – trong đó từng khối dữ liệu trong văn bản ban
đầu được thay thế bằng một khối dữ liệu khác có cùng độ dài. Độ dài mỗi khối gọi
là block size, thường được tính bằng đơn vị bit. Ví dụ thuật toán 3-Way có kích
thước khối bằng 96 bit. Một số thuật toán khối thông dụng là: DES, 3DES, RC5,
RC6, 3-Way, CAST, Camelia, Blowfish, MARS, Serpent, Twofish, GOST...

- Stream ciphers: thuật toán dòng – trong đó dữ liệu đầu vào được mã hóa từng
bit một. Các thuật toán dòng có tốc độ nhanh hơn các thuật toán khối, được dùng
khi khối lượng dữ liệu cần mã hóa chưa được biết trước, ví dụ trong kết nối không
dây. Có thể coi thuật toán dòng là thuật toán khối với kích thước mỗi khối là 1 bit.
Một số thuật toán dòng thông dụng: RC4, A5/1, A5/2, Chameleon

Các vấn đề trong mật mã đối xứng

Vấn đề chính của mật mã đối xứng là quá trình phân phối, trao đổi khóa tới
người nhận tiềm ẩn nhiều nguy cơ mất an toàn. Việc truyền khóa bí mật trên
Internet, hay trong thư điện tử, hoặc qua các dịch vụ khác đều là không an toàn.
Việc trao đổi khóa qua đường điện thoại cũng có thể bị nghe trộm, nghe lén.
Tương tự thì truyền qua email có thể bị chặn bắt.

Những điểm yếu an toàn liên quan đến mật mã khóa bí mật được khắc phục
trong một phương pháp khác của mật mã gọi là mật mã khóa công khai. Mật mã
khóa công khai sử dụng 1 cặp khóa gồm 1 khóa công khai và 1 khóa riêng (khóa bí
mật), trong đó khóa bí mật được lưu giữ an toàn bởi người tạo ra khóa, không được
trao đổi tới bất kỳ ai. Do vậy mật mã khóa công khai loại bỏ được việc phải trao
đổi khóa bí mật.

Một ví dụ đơn giản: Alice muốn gửi một thông điệp mã hóa tới Bob. Nếu
Alice sử dụng mã hóa khóa bí mật, thì cả Alice và Bob phải thiết lập khóa bí mật,
và chỉ khi hoàn tất việc tạo khóa thì 2 bên mới bắt đầu liên lạc, trao đổi với nhau.
Tuy nhiên, nếu Alice sử dụng mã hóa khóa công khai, Alice vẫn có thể gửi thông
điệp mã hóa tới Bob mà không cần thực hiện việc trao đổi khóa bí mật.

Điều này không chỉ giải quyết vấn đề phân phối khóa mà còn giúp quá trình
quản lý khóa đơn giản hơn. Thêm vào đó, mật mã khóa công khai cũng đảm bảo
tính toàn vẹn dữ liệu, xác thực và chống chối bỏ. Mã hóa khóa công khai cũng
được sử dụng để tạo chữ ký số dùng để xác thực người dùng.

1.4.2. Mật mã khóa công khai

Một phương pháp gọi là mật mã bất đối xứng được phát triển để khắc phục các vấn
đề của mật mã đối xứng. Ở phương pháp này, người ta sử dụng một cặp khóa gồm
hai khóa thay cho một khóa đơn để giải quyết các vấn đề của mật mã khóa bí mật.
trong đó, một khóa được sử dụng để mã hóa và khóa còn lại dùng để giải mã, cả
hai khóa này đều được yêu cầu để hoàn tất quá trình. Trong mật mã bất đối xứng,
một trong hai khóa này được phân phối tự do trên mạng và sử dụng cho việc mã
hóa thông điệp, gọi là khóa công khai. Chính vì thế phương pháp mã hóa này còn
có tên gọi khác là mật mã khóa công khai. Khóa thứ hai của cặp khóa là khóa riêng
hay khóa bí mật, khóa này chỉ dùng cho việc giải mã, không được phân phối công
khai và hoàn toàn bí mật với tất cả các thực thế liên lạc. trong mật mã khóa công
khai, dữ liệu được mã hóa với khóa công khai và chỉ có thể được giải mã với khóa
riêng tương ứng. và ngược lại, nếu dữ liệu được mã hóa bằng khóa riêng thì chỉ có
thể giải mã bằng khóa công khai phù hợp. chính vì sự bất đối xứng này mà mật mã
khóa công khai được gọi là mật mã bất đối xứng.
 Hoạt động của mật mã khóa công khai

Giả sử, Alice muốn gửi một tệp tin được mã hóa cho Bob, trong trường hợp này,
Bob có một cặp khóa, Bob sẽ phân phối khóa công khai và giữ lại khóa bí mật. vì
vậy Alice có một bản sao khóa công khai của Bob và sẽ dùng khóa đó để mã hóa
tệp tin, sau đó sẽ gửi tệp tin này cho Bob. Nếu một ai đó thực hiện tấn công chặn
bắt có được tệp tin mã hóa đó, thì họ cũng không có khả năng giải mã được tệp tin
này, bởi vì chỉ duy nhất khóa công khai của Bob mới có thể thực hiện giải mã.
Hình 1-4 giải thích quá trình hoạt động của mật mã khóa công khai.

Ngày nay, các thuật toán đối xứng được sử dụng để xử lý dữ liệu trong các giao
thức trong khi các thuật toán bất đối xứng lại được quan tâm đến tốc độ trao đổi
khóa. Điều này giúp có sự cân bằng giữa tốc độ và bảo mật.

Hình 1−4: Mật mã khóa công khai

Trong phương pháp này, dữ liệu mà bạn gửi cho người dùng khác chỉ được mã hóa
bằng khóa công khai, và việc giải mã được thực hiện duy nhất khi có khóa riêng
của người nhận . do đó dữ liệu trong khi truyền rất ít khả năng bị xem trộm và làm
giả.

Vì vậy, thông điệp sẽ được trao đổi một cách an toàn. Người gửi và người nhận
không cần phải trao đổi khóa như trong mật mã khóa đối xứng. tất cả các liên lạc
chỉ liên quan đến khóa công khai và không có bất kỳ khóa bí mật nào được chia sẻ
và trao đổi.
Quan điểm được rút ra ở kỹ thuật trên là mỗi người nhận có một khóa duy nhất
dùng để giải mã dữ liệu đã được mãi hóa bởi khóa công khai của người gửi. quá
trình trao đổi mật mã khóa công khai lần đầu tiên được Diffie và Helman xem xét
và thảo luận. một trong những ứng dụng triển khai phổ biến của mật mã khóa công
khai là thuật toán RSA

Điểm yếu và hạn chế của mật mã khóa công khai

Tồn tại khả năng một người nào đó có thể tìm ra được khóa bí mật. Không giống
với hệ thống mật mã sử dụng một lần (one-time pad) hoặc tương đương, chưa có
thuật toán mã hóa khóa công k hai nào được chứng minh là an toàn trước các tấn
công dựa trên bản chất toán học của thuật toán. Khả năng một mối quan hệ nào đó
giữa 2 k hóa hay điểm yếu của thuật toán dẫn tới cho phép giải mã không cần tới
khóa hay chỉ cần khóa mã hóa vẫn chưa được loại trừ. An toàn của thuật toán này
đều dựa trên các ước lượng về khối lượng tính toán để giải các bài toán gắn với
chúng. Các ước lượng này lại luôn thay đổi tùy thuộc và khả năng của máy tính và
các phát hiện toán học mới. mặc dù vậy, độ an toàn của các thuật toán mã hóa khóa
công khai cũng tương đối đảm bảo. Nếu thời gian để phá một mã (bằng phương
pháp vét cạn) được ước lượng là 1000 năm thì thuật toán này hoàn toàn có thể
dùng để mã hóa các thông tin về thẻ tính dụng vì thời gian phá mã lớn hơn nhiều
thời gian tồn tại vài năm của thẻ.
 Chương 2. CÁC LÝ THUYẾT CƠ BẢN VỀ HỆ THỐNG PKI
2.1. GIỚI THIỆU CHUNG

Việc Diffie, Hellman, Rivest, Shamir, và Adleman công bố công trình

nghiên cứu về trao đổi khóa an toàn và thuật toán mật mã hóa khóa công khai vào
năm 1976 đã làm thay đổi hoàn toàn cách thức trao đổi thông tin mật. Cùng với sự
phát triển của các hệ thống truyền thông điện tử tốc độ cao (Internet và các hệ
thống trước nó), nhu cầu về trao đổi thông tin bí mật trở nên cấp thiết. Thêm vào
đó một yêu cầu nữa phát sinh là việc xác định định dạng của những người tham gia
vào quá trình thông tin. Vì vậy ý tưởng về việc gắn định dạng người dùng với
chứng thực được bảo vệ bằng các kỹ thuật mật mã đã được phát triển một cách
mạnh mẽ.
Nhiều giao thức sử dụng các kỹ thuật mật mã mới đã được phát triển và
phân tích. Cùng với sự ra đời và phổ biến của World Wide Web, những nhu cầu về
thông tin an toàn và xác thực người sử dụng càng trở nên cấp thiết. Chỉ tính riêng
các nhu cầu ứng dụng cho thương mại (như giao dịch điện tử hay truy cập những
cơ sở dữ liệu bằng trình duyệt web) cũng đã đủ hấp dẫn các nhà phát triển lĩnh vực
này. Taher ElGamal và các cộng sự tại Netscape đã phát triển giao thức SSL trong
đó bao gồm thiết lập khóa, xác thực máy chủ. Sau đó, các thiết chế PKI được tạo ra
để phục vụ nhu cầu truyền thông an toàn.
Các nhà doanh nghiệp kỳ vọng vào một thị trường hứa hẹn mới đã thành lập
những công ty hoặc dự án mới về PKI và bắt đầu vận động các chính phủ để hình
thành nên khung pháp lý về lĩnh vực này. Một dự án của American Bar
Association đã xuất bản một nghiên cứu tổng quát về những vấn đề pháp lý có thể
nảy sinh khi vận hành PKI .Không lâu sau đó, một vài tiểu bang của Hoa kỳ mà đi
đầu là Utah (năm 1995) đã thông qua những dự luật và quy định đầu tiên. Các
nhóm bảo vệ quyền lợi người tiêu dùng thì đặt ra các vấn đề về bảo vệ quyền riêng
tư và các trách nhiệm pháp lý.
Tuy nhiên, các luật và quy định đã được thông qua lại không thống nhất trên
thế giới. Thêm vào đó là những khó khăn về kỹ thuật và vận hành khiến cho việc
thực hiện PKI khó khăn hơn rất nhiều so với kỳ vọng ban đầu.
Tại thời điểm đầu thế kỷ 21, người ta nhận ra rằng các kỹ thuật mật mã cũng
như các quy trình/giao thức rất khó được thực hiện chính xác và các tiêu chuẩn
hiện tại chưa đáp ứng được các yêu cầu đề ra.
Thị trường PKI thực sự đã tồn tại và phát triển nhưng không phải với quy
mô đã được kỳ vọng từ những năm giữa của thập kỷ 1990. PKI chưa giải quyết
được một số vấn đề mà nó được kỳ vọng. Những PKI thành công nhất tới nay là
các phiên bản do các chính phủ thực hiện
Tới nay, những nỗ lực hoàn thiện PKI vẫn đang được đầu tư và thúc đẩy. Và
để hiện thực hoá ý tưởng tuyệt vời này, các tiêu chuẩn cần phải được nghiên cứu
phát triển ở các mức độ khác nhau bao gồm: mã hoá, truyền thông và liên kết, xác
thực, cấp phép và quản lý. Tuy nhiên, hầu hết các công nghệ hình thành từ ý tưởng
này đã trở nên chín muồi và một số đã bước vào giai đoạn "lão hoá". Nhiều chuẩn
bảo mật trên mạng Internet, chẳng hạn Secure Sockets Layer/Transport Layer
Security (SSL/TLS) và Virtual Private Network (VPN), chính là kết quả của sáng
kiến PKI.

Quá trình nghiên cứu và phát triển PKI là một quá trình lâu dài và cùng với nó,
mức độ chấp nhận của người dùng cũng tăng lên một cách khá chậm chạp. Cũng
giống như với nhiều tiêu chuẩn công cộng khác, tỷ lệ người dùng chấp nhận sẽ
tăng lên chỉ khi các chuẩn đó trở nên hoàn thiện, chứng minh được khả năng thực
sự của nó, và khả năng ứng dụng và hiện thực hoá của nó là khả thi (cả về khía
cạnh chi phí lẫn thực hiện).

2.1.1. Tại sao cần có cơ sở hạ tầng khóa công khai PKI

 Như đã trình bày trong chương 1 để đảm bảo an toàn thông tin cần phải đảm
bảo các đặc tính quan trọng đó là: bí mật, toàn vẹn, sẵn sàng của thông tin ngoài ra
để thông tin được an toàn xác thực thì các tính chất về xác thực thông tin, chống
chối bỏ nguồn gốc của thông tin cũng rất quan trọng.

Thông tin là mục tiêu chính của các giao dịch điện tử hay các hoạt động của Chính
phủ Điện tử. Vấn đề đảm bảo an ninh an toàn thông tin trong các giao dịch điện tử
hay trong hoạt động điều hành tác nghiệp của Chính phủ điện tử là rất cần thiết và
cấp bách. Hiện nay trên thế giới có rất nhiều kỹ thuật đã được nghiên cứu triển
khai áp dụng, tuy nhiên giải pháp toàn diện nhất đó là triển khai Cơ sở hạ tầng
khóa công khai (PKI) để đảm bảo an toàn, an ninh thông tin.

2.1.2. Tổng quan về PKI

2.1.2.1 Khái niệm

Cơ sở hạ tầng khóa công khai (PKI) được phát triển dựa trên kỹ thuật mật
mã khóa công khai nhằm đảm bảo các mục tiêu: bí mật, toàn vẹn, xác thực, chống
chối bỏ. Các mục tiêu này sẽ được phân tích chi tiết trong các phần sau của giáo
trình.

Theo định nghĩa của Bách khoa toàn thư mở Wikipedia thì Cơ sở hạ tầng
khóa công khai (PKI) là một hệ thống tập hợp bao gồm phần cứng, phần mềm, con
người, chính sách và các thủ tục cần thiết để tạo, quản lý, phân phối, sử dụng, lưu
trữ và thu hồi các chứng thư số (chứng thư điện tử).

Một số định nghĩa khác:

PKI là cơ sở của một hạ tầng an ninh rộng khắp, các dịch vụ của PKI được
cài đặt và thực hiện bằng cách sử dụng các khái niệm và kỹ thuật của mật mã khoá
công khai (Understanding PKI).

Trong mật mã khoá công khai, cơ sở hạ tầng khóa công khai là một cơ chế
để cho một bên thứ 3 (CA) cung cấp và xác thực định danh các bên tham gia vào
quá trình trao đổi thông tin. Cơ chế này cũng cho phép gán cho mỗi người sử dụng
trong hệ thống một cặp khóa công khai/khóa riêng. Các quá trình này thường được
thực hiện bởi một phần mềm đặt tại trung tâm và các phần mềm phối hợp khác tại
các địa điểm của người dùng. Khóa công khai thường được pân phối trong chứng
chỉ khoá công khai.

Khái niệm hạ tầng khóa công khai thường được dùng để chỉ toàn bộ hệ
thống bao gồm thẩm quyền chứng thực cùng các cơ chế liên quan đồng thời với
toàn bộ việc sử dụng các thuật toán mật mã hóa khóa công khai trong trao đổi
thông tin.

2.1.2.2 Mô hình tổng thể của một hệ thống PKI

Hình 2-1: Mô hình tổng thể của PKI

Thẩm quyền chứng thực (CA)

Tiền đề nền tảng trong phát biểu ban đầu của mật mã khoá công khai là 2
người lạ (không biết nhau trước đó) có thể liên lạc an toàn. Ví dụ, khi George
muốn gửi một thông báo bí mật cho Lisa, người mà anh ta chưa gặp trước đó,
anh ta sẽ bằng một cách nào đó có thể liên kết một khoá công khai với Lisa sao
cho anh ta có thể mã thông báo cho cô ấy. Với một số lượng người sử dụng
tiềm năng gồm nhiều trăm, nhiều nghìn hoặc nhiều triệu các thực thể, cách
thực tế nhất để đạt được điều này là bổ nhiệm một số tương đối nhỏ những
người có thẩm quyền. Những người có thẩm quyền này được tin tưởng bởi một
bộ phận lớn các dân cư, hoặc có thể, toàn bộ dân số để thực hiện nhiệm vụ gắn
một cặp khoá công khai với một nhân dạng đã cho. Các nhà thẩm quyền như
vậy được gọi là những thẩm quyền chứng thực (Certification Authorities- CA)
trong thuật ngữ PKI; họ chứng nhận (certify) việc gắn kết cặp khoá/nhân dạng
bằng cách ký số một cấu trúc dữ liệu mà chứa một biểu diễn nào đó của nhân
dạng và khoá công khai tương ứng. Cấu trúc dữ liệu đó được gọi là chứng thư
khoá công khai (public-key certificate) (hoặc đơn giản hơn, là chứng thư) và sẽ
được bàn tới chi tiết hơn ở các chương sau.
Mặc dù một CA không phải là một phần tử nhất thiết của mỗi PKI có thể
tưởng tượng được (đặc biệt những PKI mà rất hạn chế về kích thước hoặc
những PKI thao tác trong những môi trường tương đối đóng, ở đó những người
sử dụng có thể đóng vai một cách hiệu quả như những nhà thẩm quyền cho
chính mình), nó là một thành phần quan trọng của nhiều PKI có quy mô lớn.
CA tạo nên một phần được mở rộng của định nghĩa PKI.

Kho chứng thư số

Một CA chỉ giải quyết một phần của bài toán đã được nhắc tới trong mục
trước (đó là, George cần liên kết một khoá công khai với Lisa để mã dữ liệu
cho cô ta). Chứng thư được phát hành bởi CA liên kết một khoá công khai với
nhân dạng của Lisa; trừ khi George có thể định vị chứng thư này một cách dễ
dàng, nếu không, anh ta sẽ không có hiệu quả gì hơn so với việc chứng thư này
chưa được tạo ra.
Một dạng nào đó của hệ thống kho chứa mềm dẻo, quy mô lớn và trực
tuyến cần phải được sắp đặt cho George để định vị các chứng thư mà anh ta
cần cho việc liên lạc mật. Vì thế, kho chứng thư (certificate repository) tạo nên
một phần của định nghĩa PKI mở rộng; một PKI lớn sẽ vô dụng nếu không có
nó. Việc bàn luận về các công nghệ kho lưu trữ khác nhau và các lựa chọn (bao
gồm X.500, LDAP, các máy chủ Web, các máy chủ FTP, DNS, các cơ sở dữ
liệu liên hiệp công ty, ...) sẽ được đề cập ở sau này.
Huỷ bỏ chứng thư

CA ký một chứng thư gắn một cặp khoá công khai với nhân dạng của
người sử dụng. Trong các môi trường thế giới thực, tuy nhiên, các sự kiện sẽ
cần đến việc phá bỏ gắn kết đó. Các ví dụ thường được trích dẫn bao gồm việc
thay đổi của nhân dạng, giống như việc chuyển từ tên con gái sang tên đã lấy
chồng hoặc việc phát hiện ra khoá bí mật bởi hacker. Cần phải có một cách để
cảnh báo cho phần còn lại của cộng đồng người sử dụng rằng không tiếp tục
chấp nhận nữa việc sử dụng khoá công khai này cho nhân dạng nọ. Cơ chế
cảnh báo này trong một PKI được gọi là huỷ bỏ chứng thư (certification
revocation).
Một ví dụ tương tự cho huỷ bỏ chứng thư PKI có thể được hình dung như
sau. Bằng lái xe là một dạng của chứng thư: việc gắn nhân dạng (tên và ảnh)
với số bằng lái xe (quyền được lái) được thực hiện bởi một thẩm quyền tin cậy.
Khi cảnh sát thổi còi dừng xe lại, người cảnh sát không chỉ đơn thuần kiểm tra
ngày hết hạn trên giấy phép lái xe; anh ta còn gọi tới nhà thẩm quyền để xem
giấy phép đã bị huỷ bỏ hay chưa. Việc kiểm tra tính huỷ bỏ là cần thiết bởi vì
đôi khi các tình huống buộc rằng việc gắn kết nhân dạng/quyền được thể hiện
trong chứng thư (chưa hết hạn) thực ra không còn được tin cậy nữa.
Trừ khi các chứng thư có một thời gian sống ngắn đến mức chúng chỉ hiệu
quả cho một lần sử dụng, một khuôn dạng nào đó của việc huỷ bỏ được đòi hỏi
cho những tình huống mà trong đó một chứng thư cần phải được tuyên bố là
không hợp lệ. Các chứng thư sử dụng một lần là không thực tế trong nhiều môi
trường PKI vì một số các nguyên nhân, bao gồm khối lượng khổng lồ mà sẽ
đặt lên CA và sự kiện rằng chính chứng thư của CA, nó giữ khoá công khai
được sử dụng để ký các chứng thư của người sử dụng đầu cuối, cần được sử
dụng không chỉ một lần. Các chứng thư có thời gian sống giới hạn (chúng có
thể được sử dụng nhiều lần trong một giai đoạn hợp lệ hữu hạn) giảm nhẹ sức
nặng lên CA nhưng không loại bỏ nhu cầu huỷ bỏ trong tất cả các tình huống.
Cho nên, chúng ta thấy rằng huỷ bỏ cũng tạo nên một phần của định nghĩa PKI
mở rộng.

Sao lưu và khôi phục khoá (Key Backup and Recovery)

Trong một môi trường PKI đang hoạt động bất kỳ, một tỷ lệ nào đó những
người sử dụng có thể xảy ra bị mất quyền sử dụng khoá bí mật của mình mỗi
chu kỳ thời gian cố định (ví dụ, mỗi tháng hoặc mỗi năm). Điều đó có thể do
một số tình huống, bao gồm:

 Các mật khẩu bị quên. Khoá bí mật đã được mã hoá của người sử dụng đã
cho vẫn còn về mặt vật lý nhưng không truy cập được.

 Phương tiện bị hỏng hóc. Đĩa cứng bị hỏng, hoặc thẻ thông minh bị gãy, ví
dụ.

 Phương tiện bị thay thế. Hệ điều hành được tải lại (ghi đè một cách hiệu quả
các giấy uỷ nhiệm cục bộ), hoặc một máy tính model cũ được thay bằng một
model mới và các giấy uỷ nhiệm là không được sao chuyển trước khi ổ đĩa
cũ được định dạng lại (reformated).
Đối với nhiều môi trường (đặc biệt các môi trường liên hợp xí nghiệp),
việc mất dữ liệu được bảo vệ bởi khoá không truy nhập được hiện tại nhìn
chung là không chấp nhận được. Việc kinh doanh có thể có những tài liệu quan
trọng được mã với khoá đối xứng mà đến lượt nó được mã bởi khoá công khai
của một người sử dụng cụ thể. Nếu như khoá bí mật tương ứng bị mất, các tài
liệu này bị làm cho không khôi phục được, nó có thể gây trở ngại nghiêm
trọng, hoặc thậm chí dừng, việc vận hành kinh doanh.
Một giải pháp cho vấn đề này là mã tất cả dữ liệu cho nhiều người nhận,
nhưng điều này có thể là không thực tế (ví dụ, đối với dữ liệu nhạy cảm cao).
Một giải pháp dễ chấp nhận và thực tế hơn là ứng dụng sao lưu và khôi phục
các khoá bí mật để giải mã (nhưng không phải các khoá bí mật để ký). Tính
cần thiết của giải pháp này cho nhiều môi trường có nghĩa rằng sao lưu và khôi
phục khoá sẽ tạo nên một phần mở rộng của định nghĩa PKI.

Cập nhật khoá tự động

Một chứng thư có thời gian sống hữu hạn. Điều đó có thể do các nguyên
nhân lý thuyết, giống như trạng thái hiện tại của hiểu biết trong mã thám đối
với các thuật toán phi đối xứng và các độ dài khoá. Một cách khác, nó có thể
do các lý do dựa trên các đánh giá thực hành, ví dụ như giới hạn về lượng dữ
liệu được bảo vệ một cách thông thường bởi một khoá chỉ là một số MB nào
đó. Tức là, dù vì lý do gì, trong nhiều môi trường PKI, một chứng thư đã cho
sẽ phải “hết hạn” và được thay bằng một chứng thư mới. Quá trình này được
gọi là “cập nhật khoá” (key update) hoặc “cập nhật chứng thư” (certificate
update).
Phần lớn những người sử dụng PKI sẽ cảm thấy nặng nề và khó chịu vì
phải thực hiện quá trình cập nhật thủ công trên cơ sở định kỳ cho mỗi chứng
thư của họ. Người sử dụng thông thường không nhớ ngày mà chứng thư của họ
bị hết hạn, và họ chỉ thấy điều đó khi đã quá muộn (tức là, khi chứng thư
không hợp lệ nữa). Cho nên, cho đến khi họ hoàn thành quá trình cập nhật, họ
sẽ không được phục vụ bởi PKI. Hơn thế nữa, khi người sử dụng ở trong trạng
thái như vậy, quá trình cập nhật là phức tạp hơn, đòi hỏi một trao đổi ngoại lệ
(out-of-band) với CA, tương tự như quá trình khởi tạo.
Giải pháp là cài đặt PKI theo cách mà khoá và cập nhật chứng thư duy trì
theo một cách hoàn toàn tự động bởi chính PKI, không cần có sự can thiệp nào
của người sử dụng. Mỗi khi chứng thư của người sử dụng được dùng đến cho
một mục đích bất kỳ, thời hạn hợp lệ của nó được kiểm tra. Khi ngày hết hạn
đến gần, thao tác đổi mới xảy ra, một chứng thư mới được tạo ra. Sau đó,
chứng thư mới được sử dụng thay cho chứng thư cũ và giao dịch được yêu cầu
bởi người sử dụng cứ tiếp tục.
Bởi vì việc cập nhật khoá tự động là sống còn đối với PKI hoạt động
trong nhiều môi trường, nó tạo nên một phần của định nghĩa PKI mở rộng.

Lịch sử khoá

Khái niệm về cập nhật khoá, một cách thủ công hoặc tự dộng, kéo theo
rằng, trên toàn bộ diễn biến thời gian, một người sử dụng đã cho có nhiều
chứng thư “cũ” và ít nhất một chứng thư “hiện tại”. Tập hợp các chứng thư này
và các khoá bí mật tương ứng được biết như là “lịch sử khoá” (key history)
của người sử dụng. (một cách đúng hơn là lịch sử chứng thư và khoá, nhưng
thông thường tên ngắn hơn được sử dụng). Việc lưu giữ vết của toàn bộ lịch sử
khoá này là rất quan trọng bởi vì dữ liệu mà George đã mã hoá cho chính anh
ta hoặc một ai đó đã mã hoá cho George vào thời điểm 5 năm trước đây không
thể giải mã được bằng khoá giải mã bí mật hiện thời của anh ta. (Chú ý rằng
việc mã lại toàn bộ dữ liệu mỗi khi khoá được cập nhật là giải pháp hoàn toàn
không thực tế trong phần lớn các môi trường.) George cần lịch sử khóa của anh
ta để cho khoá giải mã đúng có thể tìm thấy nhằm giải mã dữ liệu yêu cầu.
Tương tự, một số chứng thư trong lịch sử khoá này có thể cần thiết để kiểm
chứng các chữ ký của George 5 năm trước đây.
Giống như việc cập nhật khoá, việc quản trị các lịch sử khoá cũng cần
phải tự động và hoàn toàn được duy trì bởi PKI. Những người dùng thông
thường sẽ không chịu đựng bất kỳ một hệ thống nào trong đó họ cần chọn một
cách nào đó khoá bí mật tương ứng với họ, hoặc tồi hơn, thử mỗi khoá bí mật
lần lượt cho đến khi được giải mã ra một cái gì đó có nghĩa. PKI cần nắm giữ
tất cả các khoá trong lịch sử, thực hiện sao lưu và khôi phục ở những nơi thích
hợp, và tìm được khoá thích hợp tương ứng với bất kỳ dữ liệu nào đã được bảo
vệ.
Tầm quan trọng của lịch sử khoá làm cho nó tạo nên một phần của định
nghĩa PKI mở rộng.

Chứng thực chéo

Khái niệm của một PKI toàn cục, duy nhất mà mỗi người dùng trong thế
giới có thể gia nhập dường như không thể trở nên thực tế. Thay vào đó, cái mà
chúng ta nhìn thấy hiện nay là một mô hình mà dường như có khả năng tồn tại:
nhiều PKI, được cài đặt và hoạt động một cách độc lập, phục vụ các môi
trường và các cộng đồng người dùng khác nhau.
Khi cho tập các PKI được phát triển một cách độc lập này, tuy nhiên,
không tránh khỏi là ít nhất một số trong chúng cần phải được liên kết với nhau
theo thời gian. Việc thay đổi các quan hệ thương mại hoặc các nguyên nhân
khác sẽ làm nảy sinh liên lạc an toàn giữa những cộng đồng người sử dụng của
một số PKI, ngay cả khi liên lạc an toàn không phải là một yêu cầu trước đó.
Khái niệm chứng thực chéo đã nảy sinh trong môi trường PKI để giải
quyết chính xác nhu cầu này nhằm tạo ra các quan hệ tin cậy giữa các cài đặt
PKI không có liên quan trước đó. Trong sự thiếu vắng của một PKI tổng thể,
duy nhất, chứng thực chéo (hoặc khái niệm có liên quan, danh sách tin cậy
chứng thư- Certificate Trust List) là cơ chế được chấp nhận để cho phép những
người dùng của một cộng đồng PKI này kiểm chứng các chứng thư của những
người dùng trong một cộng đồng PKI khác. Trong công việc kinh doanh, nhu
cầu kết nối các PKI có thể xảy ra như là kết quả của các liên doanh liên kết,
các tiếp nhận, thêm các bạn hàng và nhà cung cấp mới, ...Không có một cơ chế
cho liên kết các PKI một cách suôn sẻ và kiểm soát được, các thay đổi quyết
liệt và gẫy khúc gấp có thể xảy ra trong môi trường, chẳng hạn như việc huỷ
bỏ tất cả các chứng thư trong một công ty hoặc ban hành các chứng thư mới từ
một công ty khác. Tầm quan trọng của việc thoả mãn yêu cầu kinh doanh cho
độ an toàn liên kết có nghĩa rằng một kiểu nào đó của chứng thực chéo sẽ tạo
nên một phần của định nghĩa PKI mở rộng.

Hỗ trợ chống chối bỏ

Những người dùng một PKI thường thực hiện các hành động được dự
định không thể thay đổi cùng với nhân dạng của họ. Ví dụ, George ký số một
văn bản, tức là làm khẳng định rằng văn bản đi ra từ anh ta. Cho một dòng
công việc suôn sẻ và không bị ngắt, có một yêu cầu rằng những người dùng
không thể phá bỏ một cách bất kỳ liên kết này vào một thời điểm bất kỳ trong
tương lai. Nhiều tháng sau khi ký văn bản, George cần phải không từ chối
được rằng chữ ký thực sự xuất phát từ anh ta bằng cách khẳng định rằng một ai
đó có được khoá ký bí mật của anh ta và đã sử dụng nó lên văn bản mà không
có sự chấp nhận của anh ta hoặc anh ta không biết.
Một sự từ chối như vậy được nhắc đến như là sự chối bỏ của hành động,
cho nên một PKI cần phải cung cấp sự hỗ trợ để tránh hoặc ngăn chặn chối bỏ-
một tính chất được biết như là không chối bỏ (non-repudiation). Một PKI
không thể tự mình cung cấp tính không chối bỏ thực sự và đầy đủ; thông
thường, yếu tố con người là cần thiết để áp dụng sự chín chắn và phán quyết
trong việc cân nhắc sự kiện và đưa ra quyết định cuối cùng. Tuy nhiên, PKI
cần phải hỗ trợ quá trình này bằng cách cung cấp một vài bằng chứng kỹ thuật
nào đó được yêu cầu, chẳng hạn như xác thực nguồn gốc dữ liệu và của thời
gian mà dữ liệu đã được ký. Hỗ trợ cho không chối bỏ vì thế tạo nên một phần
của định nghĩa PKI mở rộng.

Tem thời gian

Một phần tử quan trọng trong việc hỗ trợ cho các dịch vụ không chối bỏ là
việc sử dụng của tem thời gian an toàn (secure time stamping) trong PKI. Tức
là, nguồn thời gian cần được tin cậy, và giá trị thời gian cần phải được vận
chuyển một cách an toàn. Cần phải có một nguồn có thể tin được về thời gian
mà một tập hợp những người dùng PKI sẽ tin cậy. Nguồn có thể tin được về
thời gian cho PKI (tức là, máy chủ tem thời gian an toàn mà chứng thư của nó
là được kiểm tra bởi cộng đồng có liên quan những người dùng PKI) cần
không tồn tại một cách riêng rẽ cho các mục đích của không chối bỏ; nhiều
tình huống nảy sinh trong đó tem thời gian có thể tin cậy được trên một văn
bản có thể trở nên hữu ích. Tuy nhiên, việc hỗ trợ cho các dịch vụ không chối
bỏ có lẽ là người lái quan trọng nhất cho tem thời gian đúng trong nhiều môi
trường. Trong trường hợp bất kỳ, tem thời gian tạo nên một phần của định
nghĩa PKI mở rộng.

Phần mềm khách hàng

Một PKI có thể xem xét, ít nhất ở một mức nào đó, như là một tập hợp các
máy chủ PKI mà sẽ “làm các việc” cho những người dùng, chẳng hạn như:

 CA sẽ cung cấp các dịch vụ chứng thực

 Kho sẽ lưu giữ các chứng thư và thông tin huỷ bỏ

 Máy chủ sao lưu và khôi phục sẽ quản lý đúng các lịch sử khoá

 Máy chủ tem thời gian sẽ liên kết thông tin thời gian tin cậy được vào các
văn bản.
Tuy nhiên, như bất kỳ ai có hiểu biết kiến trúc máy chủ- máy khách đều
biết rằng, các máy chủ thông thường không thể làm được cái gì cho máy khách
trừ khi máy khách yêu cầu dịch vụ (tức là, làm các đòi hỏi). Cũng nguyên tắc
đó đúng cho một PKI. Máy khách trên nền cục bộ của người dùng cần phải yêu
cầu các dịch vụ chứng thực. Máy khách cần phải hỏi về các chứng thư và quá
trình liên quan tới thông tin huỷ bỏ. Máy khách cần phải hiểu các lịch sử khoá
và biết khi nào thì yêu cầu thao tác cập nhật khoá hoặc khôi phục khoá. Máy
khách cần biết khi nào nó yêu cầu một tem thời gian trên một văn bản. Trên
đầu nhận của các liên lạc an toàn (nơi mà, theo quan điểm ứng dụng, một tiến
trình “máy chủ” có thể thực hiện), vẫn là một phần mềm máy khách PKI mà sẽ
cần hiểu (1) chính sách, (2) có hay không, khi nào và bằng cách nào trạng thái
huỷ bỏ được xác định, và (3) xử lý đường dẫn chứng thư, ...
Phần mềm máy khách là một thành phần cần thiết của một PKI đầy đủ đặc
điểm và hoạt động hoàn toàn. Không có nó, nhiều dịch vụ được đề nghị bởi
PKI là không thể có hiệu quả, bởi vì không có gì là có để làm cho nó có thể và
sử dụng chúng. Rất quan trọng chú ý rằng đó không phải là phần mềm ứng
dụng, không phải mã lệnh có nhận thức về PKI mà nằm sẵn trong ứng dụng
như trình duyệt hoặc gói e-mail. Một kiến trúc như vậy sẽ vi phạm một cách
nền tảng khái niệm của PKI như là một cơ sở hạ tầng thực sự, cung cấp độ an
toàn theo một cách bền chắc trải tất cả các ứng dụng và các nền tảng tính toán.
Thay vào đó, phần mềm khách là mã lệnh mà tồn tại bên ngoài mỗi ứng dụng
và thi hành đầu cuối khách được yêu cầu của các dịch vụ PKI. Các ứng dụng
kết nối tới phần mềm khách này thông qua các điểm truy cập được chuẩn hoá,
nhưng tự các ứng dụng không tương tác với nhiều máy chủ PKI. Tức là, các
ứng dụng sử dụng cơ sở hạ tầng, chúng không phải là một phần của cơ sở hạ
tầng.
Rất quan trọng nhận thấy rằng sự cần thiết của phần mềm client-side
không nói gì về kích thước và sự thường xuyên của phần mềm này. Đặc biệt,
thành phần client-side của PKI có thể lớn hoặc nhỏ, nhanh được thay thế hoặc
tồn tại lâu dài tức là, nó có thể

 Tương đối lớn, thực hiện nhiều tiến trình chức năng PKI như xử lý đường
dẫn chứng thư và kiểm chứng;

 Tương đối nhỏ, đơn thuần gọi tới các máy chủ ngoài cho các chức năng PKI
này.

 Một Java applet hoặc mã mobile tương tự, được tải về theo thời gian thực
trên cơ sở như cần đến và sau đó được xoá đi khi ứng dụng đang gọi (như
trình duyệt Web chẳng hạn) được tắt đi.

 Thư viện liên kết động(DLL), hoặc tương tự, nằm thường trực trên nền tảng
máy khách.
Có nhiều khả năng để phần mềm client-side được cài đặt và gọi tới, nhưng
nó cần phải có thể như một thành phần độc lập bên ngoài tất cả các ứng dụng
sử dụng PKI để cung cấp đầy đủ các lợi ích của PKI cho máy khách.
Định nghĩa mở rộng về PKI của chúng ta bao gồm phần mềm máy khách
như là một thành phần cần thiết.

2.1.3. Các chuẩn và đặc tả PKI

 Public-Key Cryptography Standards (PKCS) là tập các đặc tả được đưa ra bởi
RSA Laboratories kết hợp với các nhà phát triển các hệ thống an toàn trên khắp thế
giới cho mục dích tăng tốc sự phát triển của mật mã khóa công khai. PKCS là
chuẩn không chính thức nhưng được chấp nhận rộng rãi trong công nghiệp, một số
được công bố bởi IETF (RFC).

 Họ chuẩn PKCS

- PKCS#1: RSA Encryption Standard là chuẩn về cài đặt mật mã khóa

công khai dựa trên giải thuật RSA. PKCS#1 được đưa vào RFC 3447.
Nội dung của PKCS#1 bao gồm:

 Yếu tố gốc mật mã

 Sơ đồ mã hóa

 Sơ đồ chữ ký có phụ lục

 Cú pháp ASN.1 để trình bày các khóa và để xác định các sơ đồ

trên.

- PKCS#3: Diffie-Hellman Key Agreement Standard: định nghĩa giao

thức trao đổi khóa bí mật sử dụng giải thuật Diffie-Hellman.

- PKCS#5: Password-Based Encryption Standard: cung cấp khuyến cao

cho việc cài đặt mật mã dựa trên mật khẩu, bao gồm

 Key derivation functions

 Encryption schemes

 Message-authentication schemes

 ASN.1 syntax identifying the techniques.

- PKCS#6: Extended-Certificate Syntax Standard: định nghĩa khuôn

dạng mở rộng của chứng thư X.509, phần mở rộng đã được đưa vào
khuôn dạng chứng thư X.509 v3.
 - PKCS#7: Cryptographic Message Syntax Standard: định nghĩa cú
pháp cho một vài loại thông điệp dữ liệu được bảo vệ bằng mật mã
(ký số, mã hóa)

- PKCS#8: Private-Key Information Syntax Standard: mô tả cú pháp

các thông tin của khóa bí mật (thuật toán, thuộc tính)

- PKCS#9: Selected Attribute Types: định nghĩa các kiểu thuộc tính
được lựa chọn sử dụng trong chứng thư số PKCS#6, thông điệp dữ
liệu được ký số PKCS#7, thông tin về khóa PKCS#8, yêu cầu chứng
thư PKCS#10.

- PKCS#10: Certification Request Syntax Standard: Chuẩn mô tả các

cú pháp cho các yêu cầu chứng thực khóa công khai gồm khóa công
khai và một tập các thuộc tính khác.

- PKCS#11: Cryptographic Token Interface Standard: mô tả một API,

gọi là CryptoKi, cho các thiết bị lưu trữ các thông tin mật mã và thực
hiện các chức năng mật mã. CryptoKi giải quyết mục tiêu độc lập
công nghệ và chia sẻ tài nguyên, đưa đến các ứng dụng một cái nhìn
chung và logic về thiết bị gọi là token mật mã.

- PKCS#12: Personal Information Exchange Syntax Standard: chuẩn

mô tả khuôn dạng khả chuyển cho việc lưu trữ và vận chuyển khóa bí
mật của người dùng, chứng thư và những điều bí mật khác.

- PKCS #13: Elliptic Curve Cryptography Standard: (đang phát triển)

chuẩn giải quyết các khía cạnh về mật mã đường cong eliptic như: các
tham số, sinh và kiểm tra khóa, chữ ký số, mã hóa khóa công khai,
thỏa thuận khóa và cú pháp ASN1.

- PKCS #14:Pseudo-random Number Generation: đang phát triển

- PKCS #15: Cryptographic Token Information Format Standard: thiết

lập chuẩn cho phép người dùng sử dụng token mật mã để xác định
chính mình tới nhiều phần mềm biết chuẩn mà không quan tâm tới các
ứng dụng của nhà cung cấp cryptoKi

2.2. CÁC DỊCH VỤ CỦA PKI

 2.2.1. Dịch vụ đảm bảo tính bí mật

Dịch vụ đảm bảo tính bí mật (confidentiality) là đảm bảo tính bí mật của dữ liệu:
dữ liệu chỉ có thể truy nhập bởi những người có quyền, không ai đọc được nội
dung của dữ liệu ngoại trừ những người dùng đó.

Dữ liệu cần phải được đảm bảo bí mật khi ta lưu trữ hay sao lưu dữ liệu đó trên các
thiết bị như ổ đĩa cứng, băng từ, flash và khi truyền dữ liệu trên đường truyền. Các
dữ liệu nhạy cảm đều cần được bảo mật. Tính bí mật này được cung cấp bởi các cơ
chế mã hóa mật mã, bằng cách sử dụng cả mật mã khóa công khai và mật mã khóa
bí mật. Do tốc độ mã hóa và giải mã thấp và kích thước bản mã lớn nên mật mã
khóa công khai không hiệu quả bằng mật mã khóa bí mật trong việc mã hóa dữ liệu
lớn, nó thường được sử dụng để mã hóa những đối tượng dữ liệu nhỏ như các khóa
bí mật được sử dụng trong các hệ thống mã hóa bất đối xứng.

Hình 2-2: Tổ chức liên lạc bí mật

Nhiệm vụ của dịch vụ bảo mật:

• Đảm bảo tính bí mật của dữ liệu

 • Các dữ liệu nhạy cảm đều cần được bảo mật.

• Để đảm bảo tính bí mật, các thuật toán thích hợp và khóa sẽ được thỏa thuận

Dịch vụ PKI về bảo mật sử dụng một cơ chế tương tự với một trong các phương án
của dịch vụ toàn vẹn. Tức là:

• Alice sinh ra khoá đối xứng (chẳng hạn bằng cách sử dụng khoá bí mật của
thoả thuận khoá của cô ta kết hợp với khoá công khai của thoả thuận khoá
của Bob)

• Khoá đối xứng được sử dụng để mã dữ liệu (sử dụng mã khối đối xứng như
3DES chẳng hạn).

• Dữ liệu đã mã được gửi tới Bob, hoặc cùng với khoá công khai của thoả
thuận khoá của Alice hoặc cùng với bản sao của khoá đối xứng đã được mã
hoá bằng khoá công khai để mã của Bob.

2.2.2. Dịch vụ đảm bảo tính toàn vẹn

Toàn vẹn dữ liệu (data integrity) là đảm bảo dữ liệu ổn định không bị thay
đổi thông qua các hoạt động như truyền đi hay lưu trữ. Rõ ràng, một đảm bảo
như vậy là cần thiết trong bất kỳ dạng nào của kinh doanh hoặc môi trường
thương mại điện tử, nhưng nó cũng được mong muốn trong nhiều môi trường
khác. Để đảm bảo tính toàn vẹn một hệ thống cần phải có khả năng phát hiện
những thay đổi dữ liệu trái phép và do đó các kỹ thuật mật mã được sử dụng. Cho
nên, các thuật toán và khoá thích hợp cần được khai thác và được hiểu chung giữa
thực thể muốn cung cấp toàn vẹn dữ liệu và thực thể muốn đảm bảo tính toàn vẹn
của dữ liệu. Mục đích là giúp cho người nhận dữ liệu xác minh được rằng dữ liệu
không bị thay đổi. Dịch vụ PKI về toàn vẹn có thể rất hữu ích khi thoả mãn các lợi
ích của cả 2 bên bởi vì đó là khung cảnh mà qua đó lựa chọn thuật toán và thoả
thuận khoá có thể xảy ra. Hơn nữa, các thoả thuận như thế này có thể xảy ra theo
một cách hoàn toàn trong suốt đối với các thực thể có tham gia, cho nên tính toàn
vẹn có thể giả thiết trong tất cả các giao dịch dữ liệu có liên quan tới PKI. (Tình
huống này thay đổi chỉ khi việc kiểm chứng tính toàn vẹn thất bại cho một mẩu dữ
liệu cụ thể, trong trường hợp này người sử dụng cần phải được thông báo để hành
động thích hợp được làm.)
Các kỹ thuật thực hiện:

- Mã phát hiện lỗi (Cyclic Redundancy Codes – CRCs). Nhược điểm của kỹ
thuật này là chỉ được thiết kế để phát hiện một tỷ lệ nào đó của các bit lỗi
tình cờ; chúng không có sức mạnh cản phá việc thay đổi dữ liệu một
cách chủ định bởi những kẻ thù quyết định với nhiệm vụ là thay đổi nội
dung của dữ liệu sao cho có lợi.

- Mã xác thực thông điệp (Message Authentication code – MAC): Kỹ thuật

này thông thường sử dụng một mã khối đối xứng (ví dụ, DES-CBC-MAC)
hoặc một hàm băm mật mã (ví dụ, HMAC-SHA-1).

Hình 2.3- Sử dụng mã khối đối xứng DES-CBC-MAC

 Hình 2.4- sử dụng hàm băm mật mã HMAC-SHA-1

- Chữ ký số (Digital Signature): Chữ ký số vừa phục vụ mục đích cung cấp
tính xác thực (authenticity) (tức là, xác thực thực thể), vừa cung cấp tính
toàn vẹn trên dữ liệu được ký. Đó là hệ quả của tính chất cần thiết của các
thuật toán băm mật mã và các thuật toán chữ ký; một thay đổi bất kỳ trong
dữ liệu đầu vào dẫn tới một thay đổi lớn, không dự đoán được ở đầu ra với
xác suất rất cao. Nói một cách khác, nếu dữ liệu bị thay đổi (hoặc bởi tai hoạ
hoặc bởi thao tác chủ ý) giữa “ở đây” và “ở kia”, giữa “sau đó” và “bây
giờ”, chữ ký sẽ loại bỏ khi kiểm tra, và sự mất tính toàn vẹn sẽ hiển nhiên
đối với người nhận. Nếu, mặt khác, chữ ký khi kiểm tra cho kết quả tốt, thì
người nhận đã nắm giữ dữ liệu ban đầu (chưa thay đổi).
 Hình 2-5: Sơ đồ ký số

Hình 2-6: Chữ ký số xác định tính xác thực và chống chối bỏ

2.2.3. Dịch vụ xác thực

 Dịch vụ đảm bảo tính xác thực là hành động hay khẳng định điều gì đó đáng
tin cậy, là một thủ tục của một thực thể xác minh các tính chất đã khẳng định về
một thực thể khác. Tính xác thực trong môi trường thương mại điện tử được thực
hiện rất tốt bằng các hệ thống mã hóa khóa công khai, dựa trên mối quan hệ toán
học giữa khóa công khai và khóa bí mật. Thông điệp được ký bởi một thực thể có
thể được kiểm tra bởi bất kỳ thực thể nào quan tâm. Các thực thể này có thể an tâm
rằng chỉ có chủ của khóa bí mật mới có thể tạo ra thông điệp này, bởi vì chỉ có
người đó mới có khóa bí mật.
Xác thực có thể tìm thấy ứng dụng trong 2 ngữ cảnh chính, đó là định
danh thực thể (entity identification) và định danh nguồn gốc dữ liệu (data
origin identification).
Định danh thực thể, tự nó, phục vụ đơn giản để định danh một thực thể cụ
thể đã tham gia vào, về bản chất là tách rời với bất kỳ hoạt động nào mà thực
thể muốn thực hiện. Cái đó rõ ràng là có giá trị bị giới hạn (bởi vì thông
thường thực thể sẽ muốn thực hiện các hoạt động khác trên cơ sở định danh
của mình). Cho nên, trong thực tế, định danh thực thể nói chung sinh ra một
kết quả cụ thể mà sau đó được sử dụng để làm cho có thể các hoạt động hoặc
truyền thông khác. Xác thực thực thể có thể thực hiện theo một chiều (từ A đến B)
hoặc hai chiều (A đến B và B đến A), trong trường hợp hai chiều gọi là xác thực
thực thể lẫn nhau (mutual entity authentication). Ví dụ, quá trình định danh thực
thể có thể mang lại (hoặc mở) một khoá bí mật mà có thể sau đó được sử dụng
để giải mã một file để đọc hoặc thay đổi cập nhật, hoặc để thiết lập một kênh
liên lạc an toàn với thực thể khác. Định danh, tự nó, một khi đã được xác thực,
cũng có thể được tương ứng với một tập các quyền trên một danh sách kiểm
soát truy cập (Access Control List – ACL) cho mục đích làm các quyết định
kiểm soát truy cập.

Định danh nguồn gốc dữ liệu nhận dạng một thực thể cụ thể như là nguồn
gốc hoặc xuất phát điểm của một thông điệp dữ liệu đã cho. Đây không phải là
định danh thực thể một cách tách biệt, cũng không phải định danh thực thể cho
mục đích rõ ràng nhằm làm có thể một hành động khác nào đó. Thay vào đó, đây
là định danh với dự định của một gắn kết tĩnh và không thể huỷ được, gắn kết một
thực thể được định danh với dữ liệu cụ thể nào đó. Một quá trình như vậy có thể
cung cấp hỗ trợ cho một dịch vụ không chối bỏ. Ví dụ A nhận được một khối
thông tin khóa và A muốn biết chính xác khối thông tin khóa này xuất phát từ đâu,
vậy thì A cần yêu cầu một sự xác thực nguồn gốc khóa.

Có hai kiểu xác thực: xác thực cục bộ và xác thực ở xa

Local authentication: xác thực khởi đầu của một thực thể tới môi trường cục bộ -
phần lớn luôn được người sử dụng trực tiếp tham gia (một mật khẩu hay số PIN
cần phải được gõ, hoặc cần phải quét vân tay).

Ngược lại, remote authentication-Xác thực của thực thể tới một môi trường nào đó
ở xa- có thể hoặc không có người sử dụng trực tiếp tham gia. Có thể không cần tới
sự tham gia trực tiếp của người dùng: khó bảo vệ dữ liệu nhạy cảm và không thuận
tiện với người dùng.

Dịch vụ PKI về xác thực có bốn nhân tố chính trong việc chứng minh một
định danh:

 Một cái gì đó người dùng có (thẻ thông minh, thẻ ATM, …)

 Một cái gì đó người dùng biết (mật khẩu, …)

 Một cái gì đó gắn với người dùng (vân tay, mống mắt, …)

 Một cái gì đó người dùng thực hiện (chẳng hạn như các đặc trưng gõ
máy chữ hoặc cách viết tay)
Khái niệm của xác thực một nhân tố là chỉ một phương pháp trong số các
lựa chọn trên được sử dụng. Xác thực nhiều nhân tố sử dụng nhiều hơn một
trong các lựa chọn một cách đồng thời trong quá trình xác thực. Một ví dụ
quen thuộc của xác thực hai nhân tố là quá trình đăng nhập vào máy ATM
trong đó người sử dụng đưa vào một thẻ từ (một cái gì bạn có) và gõ vào số
PIN (một cái gì bạn biết) để được truy cập vào tài khoản ngân hàng của mình.
Dịch vụ PKI về xác thực (đối nghịch với hành đồng xác thực ban đầu với
môi trường cục bộ, việc này có thể bao gồm xác thực một hay nhiều nhân tố
bao gồm các mật khẩu hoặc các thiết bị sinh trắc học) khai thác kỹ thuật mật
mã về chữ ký số. Chữ ký số có thể được tính trên giá trị băm của một trong ba
giá trị sau:
1. Dữ liệu nào đó được xác thực
 2. Một yêu cầu nào đó mà người dùng dự định gửi tới thiết bị ở xa
3. Một thách thức ngẫu nhiên được phát hành bởi một thiết bị ở xa.

Giá trị đầu tiên hỗ trợ dịch vụ PKI về xác thực nguồn gốc dữ liệu; hai giá trị sau hỗ
trợ dịch vụ PKI về xác thực thực thể.

Một hàm băm mật mã tốt sẽ yêu cầu giảm dữ liệu hoặc thông báo thỉnh cầu tới một
kích thước thích hợp cho một lần tính của hàm chữ ký. Nó cũng hữu ích trong việc
ngăn cản kẻ tấn công khỏi việc giải mã một giá trị trông như ngẫu nhiên (trong các
thuật toán nào đó như RSA), việc này có thể cung cấp thông tin giá trị trong một số
tình huống.

Các kỹ thuật xác thực:

 Kỹ thuật xác thực sự “mới mẻ” (fresh) của thông điệp và tính sống
động của người dùng: hỏi/đáp (challenge/response), dấu thời gian
(timestamp),…
 Hình 2-7: Bob xác thực với Alice, sử dụng xác thực từ xa dựa trên khoá
công khai

 Kỹ thuật xác thực lẫn nhau (Mutual Authentication) và kỹ thuật xác

thực sử dụng bên thứ ba tin cậy (Kerberos, PKI)

2.2.4. Dịch vụ dấu thời gian

Dấu thời gian hay còn gọi là tem thời gian (time stamping) là một đối tượng
dữ liệu gắn kết một dữ kiện với một mốc thời gian xác định, giúp biểu thị rằng một
tài liệu nào đó là trước tài liệu X và sau tài liệu Y. Hệ thống phải có khả năng kiểm
tra rằng tem thời gian được liên kết với dữ liệu là xác thực và có tính toàn vẹn.

Tem thời gian bao gồm chữ ký số trên tổ hợp của:

 - Dữ liệu biểu diễn thời gian

- Giá trị băm của chính tài liệu.

Các thực thể PKI liên quan cần biết và tin cậy bằng chứng khóa công khai của dịch
vụ tem thời gian, bằng cách ký trên tem thời gian có thể được kiểm tra và tin cậy;
tất cả các tem thời gian được ký bằng khóa không tin cậy được xem là không hợp
lệ.

Hình 2-8: Dịch vụ dấu thời gian

Dịch vụ tem thời gian an toàn có thể sử dụng các dịch vụ cốt lõi của PKI.

Tem thời gian an toàn là dấu thời gian thỏa mãn các tính chất xác thực và toàn
vẹn. Dịch vụ cấp dấu thời gian sẽ cấp dấu thời gian cho các thực thể cuối được
thực hiện bởi một bên tin cậy thứ ba gọi là thẩm quyền dấu thời gian (Time Stamp
Authority – TSA), thẩm quyền dấu thời gian không yêu cầu chỉ có duy nhất mà có
thể mỗi một môi trường cục bộ có một thẩm quyền dấu thời gian để phục vụ dịch
vụ này. Dấu thời gian được mã hóa dưới dạng ASN.1 và được truyền qua các
phương tiện như file, email, TCP, HTTP. Dịch vụ tem thời gian an toàn sử dụng
các dịch vụ cốt lõi của PKI về xác thực và toàn vẹn.
 Hình 2-9: Mô hình tạo dấu thời gian an toàn

Hình 2-10 : Kiểm tra tính hợp lệ của dấu thời gian an toàn

2.3. CHỮ KÝ SỐ VÀ CHỨNG THƯ SỐ

 2.3.1. Chữ ký số

Chữ ký điện tử được tạo lập dưới dạng từ, chữ, số, ký hiệu, âm thanh hoặc
các hình thức khác bằng phương tiện điện tử, gắn liền hoặc kết hợp một cách lô gíc
với thông điệp dữ liệu, có khả năng xác nhận người ký thông điệp dữ liệu và xác
nhận sự chấp thuận của người đó đối với nội dung thông điệp dữ liệu được ký

"Chữ ký số" là một dạng chữ ký điện tử được tạo ra bằng sự biến đổi một
thông điệp dữ liệu sử dụng hệ thống mật mã không đối xứng theo đó người có
được thông điệp dữ liệu ban đầu và khoá công khai của người ký có thể xác định
được chính xác (Nghị định 26/2007/NĐ-CP):

a) Việc biến đổi nêu trên được tạo ra bằng đúng khoá bí mật tương ứng với
khoá công khai trong cùng một cặp khóa;

b) Sự toàn vẹn nội dung của thông điệp dữ liệu kể từ khi thực hiện việc biến
đổi nêu trên

2.3.1.1 Hàm băm

Hình 2-11: Hàm băm

- Hàm băm mật mã học là hàm băm và có tính chất là hàm 1 chiều. Từ khối
dữ liệu hay giá trị băm đầu vào chỉ có thể đưa ra 1 giá trị băm duy nhất. Như chúng
ta đã biết đối với tính chất của hàm 1 chiều. Một người nào đó dù bắt được giá trị
băm họ cũng không thể suy ngược lại giá trị, đoạn tin nhắn băm khởi điểm.
 - Hàm băm thường được dùng trong bảng băm nhằm giảm chi phí tính toán
khi tìm một khối dữ liệu trong một tập hợp. Giá trị băm đóng vai trò gần như một
khóa để phân biệt các khối dữ liệu
- Giá trị đầu vào(tin nhắn, dữ liệu...) bị thay đổi tương ứng giá trị băm cũng bị
thay đổi. Do vậy nếu 1 kẻ tấn công phá hoại, chỉnh sửa dữ liệu thì server có thể
biết ngay lập tức.

2.3.1.2 Tạo và kiểm tra chữ ký số

Chữ ký số được tạo ra bằng cách áp dụng thuật toán băm một chiều trên văn
bản gốc để tạo ra bản tóm lược (message digest), sau đó bản tóm lược được mã hóa
bằng khóa riêng (trong cặp khóa công khai) tạo ra chữ ký số đính kèm với văn bản
gốc để gửi đi. Khi nhận, văn bản được tách làm 2 phần, phần văn bản gốc được
tính lại bản tóm lược để so sánh với bản tóm lược cũ cũng được phục hồi từ việc
giải mã chữ ký số.

Các bước mã hóa:

Hình 2-12: Cách tạo chữ ký số

1. Dùng giải thuật băm để thay đổi thông điệp cần truyền đi. Kết quả ta được
một bản tóm lược.

2. Sử dụng khóa riêng của người gửi để mã hóa bản tóm lược thu được ở bước
1. Kết quả thu được gọi là chữ ký số.
 3. Ghép chữ ký số vào văn bản gốc, mọi sự thay đổi trên văn bản gốc hoặc
chữ ký sẽ bị phát hiện trong giai đoạn kiểm tra. Ngoài ra, việc ký số này đảm bảo
người nhận tin tưởng văn bản này xuất phát từ người gửi chứ không phải là ai
khác.

Các bước kiểm tra:

Hình 2-13: Kiểm tra chữ ký số

1. Dùng khóa công khai của người gửi (khóa này được công khai trên mạng,
trên thư mục dùng chung…) để giải mã chữ ký số của văn bản.

2. Dùng giải thuật băm để băm văn bản đính kèm.

3. So sánh kết quả thu được ở bước 1 và 2, nếu trùng nhau, ta kết luận:
- Dữ liệu nhận được có tính toàn vẹn (vì kết quả băm là duy nhât, một chiều)
- Dữ liệu nhận được là do chính người gửi gửi đi vì chỉ duy nhất người gửi
mới có khoá bí mật phù hợp với khoá công khai đã được sử dụng để giải mã. Như
vậy tính chống từ chối và tính xác thực được kiểm tra và xác nhận. Lúc này người
nhận tin rằng, khoá công khai đó đại diện hợp pháp cho người gửi..

2.3.2. Chứng thư số

 Chứng thư điện tử là thông điệp dữ liệu do tổ chức cung cấp dịch vụ chứng
thực chữ ký điện tử phát hành nhằm xác nhận cơ quan, tổ chức, cá nhân được
chứng thực là người ký chữ ký điện tử.

"Chứng thư số" là một dạng chứng thư điện tử do tổ chức cung cấp dịch vụ
chứng thực chữ ký số cấp

Chứng thư số là một cấu trúc dữ liệu gắn kết khoá công khai của một người
với một hoặc nhiều thuộc tính để xác định người sử dụng đó, chứng thư số được
đảm bảo bởi một đối tác tin cậy là Trung tâm chứng thực điện tử CA. Loại chứng
thư được sử dụng phổ biến là X509.

Hiện nay có nhiều kiểu chứng thư được sử dụng cho các mục đích khác
nhau. Một trong các kiểu chứng thư quan trọng là chứng thư khoá công khai.
Trong đó, khoá công khai được gắn kết chặt chẽ với một cá nhân, một thiết bị,
hoặc một thực thể riêng biệt. Chứng thư khoá công khai được một cơ quan chứng
thực (có thể là một người hay một thực thể, được gọi tắt là CA) ký. CA chứng thực
nhận dạng và khoá công khai (hoặc các thuộc tính khác) của chủ thể chứng thư.
Chủ thể chứng thư là một người, thiết bị, hoặc thực thể khác, nói chung là đối
tượng nắm giữ khoá riêng tương ứng với khoá công khai được chứng thực có trong
chứng thư. Mã hoá khoá công khai và chữ ký số là các yếu tố thiết yếu để đảm bảo
an toàn thương mại điện tử, các chứng thư khoá công khai là yếu tố cần thiết để áp
dụng các kỹ thuật này trên một phạm vi rộng.

Trong phần này, chúng ta tập trung vào các chứng thư khoá công khai, cách
sử dụng chúng, các chuẩn liên quan, một số vấn đề liên quan đến việc sử dụng các
chứng thư cho các mục đích khác nhau.

2.3.3. Giới thiệu về các chứng thư khoá công khai

Khi người khởi tạo (người gửi) thông báo muốn sử dụng mã hoá khoá công
khai để mã hoá một thông báo gửi cho người nhận, anh ta cần một bản sao khoá
công khai của người nhận. Khi một người bất kỳ muốn kiểm tra chữ ký số do
người khác sinh ra, người kiểm tra cần một bản sao khoá công khai của người ký.
Chúng ta gọi cả người mã hoá thông báo và người kiểm tra chữ ký số là những
người sử dụng khoá công khai hay gọi ngắn gọn là người dùng.
 Khi khoá công khai được gửi đến cho một người dùng thi không cần thiết
phải giữ bí mật khoá công khai này. Tuy nhiên, người sử dụng khoá công khai phải
đảm bảo chắc chắn rằng khoá công khai được sử dụng đúng là của người nhận
thông báo chủ định hoặc người ký. Nếu một đối tượng có thể dùng một khoá công
khai khác thay thế cho khoá công khai hợp lệ, các nội dung của thông báo mã hoá
có thể bị lộ, đối tượng này có thể biết được nội dung của các thông báo và có thể
làm giả chữ ký số. Nói cách khác, các biện pháp bảo vệ (xuất phát từ các kỹ thuật
này) sẽ bị lộ nếu như một đối tượng có thể thay thế các khoá công khai không được
chứng thực.

Đối với các nhóm thành viên nhỏ, yêu cầu này có thể được thoả mãn một
cách dễ dàng. Ví dụ, trong trường hợp có hai người quen biết nhau, khi người này
muốn truyền thông an toàn với người kia, họ có thể có được bản sao khoá công
khai của nhau bằng cách trao đổi các đĩa có chứa khoá công khai của từng người,
nhờ vậy đảm bảo rằng các khoá công khai được lưu trữ an toàn trên mỗi hệ thống
cục bộ của từng người. Đây chính là hình thức phân phối khoá công khai thủ công.
Tuy nhiên, hình thức phân phối khoá công khai thủ công này bị coi là không thực
tế hoặc không thoả đáng trong phần lớn các lĩnh vực ứng dụng khóa công khai, đặc
biệt khi số lượng người sử dụng trở nên quá lớn và ở phân tán. Các chứng thư khoá
công khai giúp cho việc phân phối khoa công khai trở nên có hệ thống.

Hệ thống chứng thư khoá công khai làm việc như sau: CA phát hành chứng
thư cho những người nắm giữ cập khoá công khai và khoá riêng. Mỗi chứng thư
gồm có một khoá công khai và thông tin nhận dạng duy nhất của chủ thể của
chứng thư. Chủ thể của chứng thư có thể là một người, thiết bị, hoặc một thực thể
khác có nắm giữ khoá riêng tương ứng, xem hình sau:
 Hình 2-14: Chứng thư khóa công khai đơn giản

Khi chủ thể của chứng thư là một người hoặc một kiểu thực thể hợp
pháp nào đó, thì chủ thể thường được gọi là một thuê bao của CA. Các chứng thư
được CA ký bằng khoá riêng của CA.

Một khi các chứng thư này được thiết lập, nhiệm vụ của người sử dụng rất
đơn giản. Giả thiết rằng, một người sử dụng đã có khoá công khai của CA một
cách an toàn (ví dụ, thông qua phân phối khoá công khai thủ công) và anh ta tin
cậy CA phát hành các chứng thư hợp lệ, Nếu người dùng cần khoá công khai của
một trong các thuê bao của CA này, anh ta có thể thu được khoá công khai của
thuê bao đó bằng cách lấy từ bản sao chứng thư của thuê bao. Chứng thư của thuê
bao có thể được kiểm tra bằng cách kiểm tra chữ ký của CA có trên chứng thư.
Người sử dụng các chứng thư theo các này được gọi là thành viên đáng tin cậy.

Kiểu hệ thống này tương đối đơn giản và kinh tế khi thiết lập trên diện rộng
và theo hình thức tự động, bởi vì một trong các đặc tính quan trong của các chứng
thư là: Các chứng thư có thể được phát hành mà không cần phải bảo vệ thông qua
các dịch vụ an toàn truyền thông truyền thống để đảm báo bí mật, xác thực và tính
toàn vẹn.
 Chúng ta không cần giữ bí mật khoá công khai, như vậy các chứng thư
không phải là bí mật. Hơn nữa, ở đây không đòi hỏi các yêu cầu về tính xác thực
và toàn vẹn, do các chứng thư tự bảo vệ (chữ ký số của CA có trong chứng thư
đảm bảo tính xác thực và toàn vẹn). Nếu một đối tượng truy nhập trái phép định
làm giả một chứng thư được phát hành cho một người sử dụng khoá công khai, anh
ta sẽ bị người này phát hiện vì có thể kiểm tra được chữ ký số của CA. Chính vì
vậy, các chứng thư khoá công khai được phát hành theo các cách không an toàn, ví
dụ như thông qua các máy chủ, các hệ thống thư mục và/hoặc các giao thức truyền
thông không an toàn.

Lợi ích cơ bản của một hệ thống chứng thư khoá công khai là một người sử
dụng có thể có được một số lượng lớn các khoá công khai cảu các thành viên khác
một cách tin cậy, xuất phát từ thông tin khoá công khai của một thành viên, đó
chính là khoá công khai của CA.

Lưu ý rằng, một chứng thư hữu ích khi người sử dụng khoá công khai tin
cậy CA phát hành các chứng thư hợp lệ.

2.4. CÁC MÔ HÌNH KIẾN TRÚC TIN CẬY

2.4.1. Giới thiệu về kiến trúc hệ thống PKI

Ngày nay PKI được nhiều tổ chức triển khai như là một công cụ để bảo vệ các dữ
liệu tài nguyên nhạy cảm . tuy nhiên, theo từng nhu cầu, quy trình, trạng thái khác
nhau với mỗi loại nghiệp vụ thì một mô hình PKI tiêu chuẩn là điều không thực
hiện được. vì mục đích này, có rất nhiều loại kiến trúc PKI để phù hợp nhất với
từng yêu cầu của mỗi tổ chức. tuy nhiên, bất kỳ kiến trúc PKI nào được triển khai
thì cốt lõi của mỗi kiến trúc chính là sự tin cậy.

Chương này đi chi tiết vào các loại kiến trúc khác nhau và ưu nhược điểm của từng
kiến trúc. Chương này giới thiệu các mô hình kiến trúc tin cậy chủ yếu được sử
dụng tùy theo nhu cầu của tổ chức.

Như chúng ta thấy được rằng PKI mang lại sự tin cậy của thế giới thực vào thế
giới công nghệ thông tin bằng thực hiện giao dịch và liên lạc điện tử tin cậy.

Một ví dụ điển hình giúp hiểu rõ việc thiết lập sự tin cậy trong môi trường PKI.
Giả sử Alice muốn nhận một tài liệu đã được Bob ký số lên đó. Để xác thực tính
hợp lệ của chữ ký trên tài liệu có phải là của Bob hay không, Alice cần sử dụng
khóa công khai của Bob. ở đây nảy sinh câu hỏi về sự tin cậy. Làm sao Alice có
thể chắc chắn khóa công khai đó là khóa công khai thực tế Bob đang sử dụng mà
không phải là của người khác giả mạo Bob.

Câu trả lời cho vấn đề này chính là chứng thư số. như ta đã biết, chứng thư số là
một tài liệu gắn kết thông tin của người sở hữu chứng thư số với khóa công khai.
Chứng thư này được ký số bởi một bên thứ ba, được gọi là bên thứ 3 tin cậy
(Trusted Third Party – TTP) hay còn gọi là thẩm quyền chứng thư số (Certification
Authority – CA). Do đó, để xác thực chứng thư số của Bob, đầu tiên Alice cần có
được khóa công khai của CA. ở đây lại một lần nữa mức độ tin cậy lại được đặt
câu hỏi, làm sao Alice có thể tin cậy vào khóa công khai của CA. Alice có thể có
các khóa công khai của CA bên ngoài. Bằng cách này Alice tin cậy vào khóa công
khai của VA khi Alice đã chắc chắn vào việc xác minh được khóa công khai. Bằng
việc sử dụng khóa công khai tin cậy, Alice có thể xác thực được chứng thư số của
Bob và từ đó tin tưởng chữ ký số của Bob.

Thêm vào đó, để chứng thực các users, CA có thể chứng thực các CA khác, bằng
việc phân phối khóa theo cách thức tin cậy như nhau. Tương tự, các CA này có thể
chứng thực CA khác nữa. Bằng cách này, các thực thể có thể tin tưởng lẫn nhau,
giúp thiết lập một chuỗi tin cậy từ CA tin cậynày tới CA tin cậy của thực thể khác,
chuỗi này được gọi là đường dẫn chứng thực. số lượng các CA trong đường dẫn
chứng thực và sự sắp xếp các CA này xác định các kiến trúc PKI khác nhau.

Đường dẫn chứng thực là một chuỗi các chứng thư được cấp phát; trong đó, thực
thể cấp phát chứng thư đầu tiên là 1 điểm tin tưởng. Chủ thể của chứng thư cuối
cùng là thực thể cuối cùng nhận được chứng thư.

Trong 1 đường dẫn chứng thực, có thể có nhiều điểm tin tưởng (phụ thuộc vào số
lượng các CAs trên đường dẫn đó) Trước khi sử dụng 1 chứng thư, ta cần phải
thiết lập đường dẫn chứng thực giữa các điểm tin tưởng và các chứng thư. Mục
đích là tập hợp, liên kết các chứng thư cần thiết lại với nhau (từ chứng thư của
những người cấp phát tới chứng thư gốc) để tạo thành một đường dẫn được tin
tưởng Chứng thư thực thể cuối (End entity certificate) được cấp phát trực tiếp từ
điểm tin tưởng của nó.

Một ví du cho đường dẫn chứng thực như sau:

Giả sử chứng thư của Bob được ký bởi CA2, chứng thư của CA2 lại được ký bởi
CA1. Chứng thư của CA1 được ký bởi CA gốc. Alice (với khoá công khai của gốc
là kR) có thể kiểm tra chứng thư của CA1, và do đó trích bản sao tin cậy của khoá
công khai của CA1 là k1. Sau đó, khóa này có thể được sử dụng để kiểm tra chứng
thư của CA2, một cách tương tự dẫn tới bản sao tin cậy khoá công khai của CA2 là
k2. Khoá k2 có thể được sử dụng để kiểm tra chứng thư của Bob, dẫn tới bản sao
khoá công khai của Bob là kB. Bây giờ Alice có thể sử dụng khoá mong muốn kB

Hình 2-15: Đường dẫn chứng thực

Cần lưu ý rằng CA của một tổ chức có thể ở bên trong hoặc bên ngoài của tổ chức.
việc giải pháp sử dụng CA ở bên ngoài hay thiết lập CA bên trong tổ chức phụ
thuộc vào mô hình kinh doanh của tổ chức đó. Ví dụ, một cơ quan yêu cầu bắt
buộc các nhân viên phải đưa ra được bằng chứng định danh cho các nhân viên
khác khi thực hiện giao dịch và trao đổi thì tổ chức đó cần thiết lập 1 CA ở bên
trong tổ chức để phát hành và xác thực định danh của nhân viên từ khuôn dạng của
chứng thư số. khuôn dạng chứng thư số được sử dụng rộng rãi nhất là khuôn dạng
chứng thư số X.509 (liên hiệp viễn thông quốc tế - International
Telecommunications Unions)

2.4.2. Mô hình tổng thể hệ thống PKI

- Certificate Authority (CA) là một tổ chức được tin tưởng trong việc cấp phát
chứng chỉ số và công nhận các nội dung thông tin lưu giữ trong chứng chỉ số
- Chứng nhận (certify) việc gắn kết cặp khoá/nhân dạng bằng cách ký số một
cấu trúc dữ liệu mà chứa một biểu diễn nào đó của nhân dạng và khoá công
khai tương ứng. Cấu trúc dữ liệu đó được gọi là chứng chỉ khoá công khai
(public-key certificate) (hoặc đơn giản hơn, là chứng chỉ)
- CA là trái tim của hệ thống PKI, là tổ chức quản lý của PKI
- Registration Authority (RA) là cơ quan chịu trách nhiệm xác nhận về tính
trung thực của yêu cầu sử dụng chứng thư số. RA không có trách nhiệm sinh
và ký chứng chỉ.
- RA sau khi nhận yêu cầu sẽ chuyển sang CA để thực hiện
- Kết quả của CA sẽ được chuyển tới người yêu cầu thông qua RA
- Local Registration Authority (LRA) là đại diện của RA tại địa phương, thực
hiện các chứng năng của RA tại khu vực quản lý của mình
o Xác nhận các thông tin về người đăng ký
o Chấp thuận các yêu cầu đăng ký sử dụng
 o Gửi yêu cầu cấp mới tới CA
o Gửi cầu gia hạn tới CA
o Gửi cầu hủy bỏ chứng chỉ tới CA
o Hỗ trợ tại chỗ cho người sử dụng
- Kho lưu trữ chứng thư lưu trữ toàn bộ các chứng thư số của các cơ quan
chứng thực và các chứng thư số của các thuê bao trong hệ thống, phục vụ
việc tra cứu các chứng thư số. Các thông tin về danh sách hủy bỏ chứng thư
số…
- X.500, LDAP, các máy chủ Web, các máy chủ FTP, DNS, các cơ sở dữ liệu

2.4.3. Hệ thống kiến trúc đơn

Mô hình kiến trúc CA đơn là mô hình cơ bản nhất của PKI. Ở lại mô hình này, chỉ
có duy nhất một CA được quyền cấp phát và phân phối chứng thư và danh sách thu
hồi chứng thư tới các thực thể. Tất cả các thực thể hoàn toàn tin tưởng CA này.
HƠn nữa các thực thể chỉ sử dụng chứng thư số do CA này cấp phát. Do chỉ có
một CA duy nhất trong mô hình nên không tồn tại mối quan hệ với các CA tin cậy
khác, và không cho phép bất kỳ 1 CA mới nào được phép thêm vào trong hệ thống
PKI

Tất cả thực thể trong kiến trúc này liên kết với nhau trong môi trường tin cậy vì chỉ
có duy nhất một CA tin cậy cho toàn bộ thực thể. Ví dụ ở hình dưới, Alice và Bob
là 2 thực thể tin cậy CA 1. Vì vậy cả hai có thể xác minh và chứng thực chứng thư
số của nhau. Hình 2-16 mô tả mô hình kiến trúc CA đơn

Hình 2-16: Mô hình kiến trúc CA đơn

Mỗi người dùng trong hệ thống chỉ có 1 đường dẫn chứng thư duy nhất từ Single
CA. Mỗi đường dẫn chỉ gồm 1 chứng thư duy nhất mà thôi.

 Đường dẫn chứng thư cho Alice

[CA1  Alice]

 Đường dẫn chứng thư cho Bob

[ CA1  Bob]

Việc triển khai mô hình kiến trúc CA cũng khá là đơn giản vì chỉ phải thiết lập duy
nhất một CA. kiến trúc CA đơn cũng nảy sinh một bất cập đó là, chỉ có một CA
duy nhất nắm toàn bộ thông tin về khóa của các thực thể. Nếu khóa riêng của CA
bị tổn thương thì toàn bộ chứng thư số do CA này cấp phát sẽ bị vô hiệu hóa. và hệ
thống PKI có thể bị phá vỡ hoàn toàn. Trong trường hợp này, toàn bộ các thực thể
phải được thông tin về việc khóa riêng của CA bị tổn thương.

Ngoài ra, nếu khóa riêng của CA bị tổn thương thì phải thiết lập lại CA. để thiết
lập lại hệ thống CA, toàn bộ các chứng thư số được CA cấp trước đó phải bị vô
hiệu hóa và được cấp lại. thông tin về CA mới cũng được thông báo tới các thực
thể. Vì thế, CA nên có quy trình cho việc duy trì khóa riêng và có cơ chế bảo mật
cho việc xác thực chứng thư số trực tuyến tới các thực thể.

Kiến trúc CA cũng gặp phải các vấn đề về khả năng mở rộng. tuy kiến trúc này khá
phù hợp với tổ chức nhỏ với sự giới hạn số lượng người dùng, nhưng khi quy mô
của tổ chức được mở rộng thì kiến trúc CA đơn sẽ làm hạn chế phạm vi. Ví dụ,
Alice và Bob là nhân viên của công ty AllSolv, mô hình CA của AllSolv là mô
hình kiến trúc CA đơn cấp phát chứng thư số cho nhân viên của công ty, và cả
Alice và Bob đều tin tưởng vào CA này. Do sự mở rộng kinh doanh của công ty,
các nhân viên buộc phải trao đổi với các công ty khác. Tuy nhiên phạm vi của CA
AllSolv lại chỉ giới hạn trong các nhân viên của AllSolv, nên khi Alice và Bob trao
đổi thông tin với Charlie ở công ty IntelliSol thì họ cần có thêm CA bổ sung để
liên kết tin cậy với Charlie .

2.4.4. Hệ thống kiến trúc cho doanh nghiệp (thương mại)

 2.4.4.1 Kiến trúc phân cấp

Đây là kiến trúc PKI phổ biến nhất được triển khai trong các tổ chức. trong kiến
trúc này, các dịch vụ PKI được cung cấp bởi nhiều CA. Không giống như kiến trúc
danh sách tin cậy, tất cả các CA của kiến trúc PKI chia sẻ mối quan hệ tin cậy lẫn
nhau – mối quan hệ thứ bậc.

Kiến trúc CA phân cấp cũng giống như cấu trúc hình cây ngược, có một gốc ở trên
đỉnh được gọi là CA gốc, rồi tới các nhánh (branch) hoặc các nút (node). Các nút là
các CA cấp dưới của CA gốc, các CA cấp dưới có đầy đủ chức năng của một CA,
cũng đảm nhiệm việc phát hành chứng thư cho các CA cấp dưới họ. Khi CA gốc
có CA cấp dưới, thì CA gốc sẽ phát hành chứng thư số cho cấp dưới, thông qua đó
sẽ thấy được các nhiệm vụ mà CA cấp dưới phải thực hiện.

Các CA gốc thường phát hành chứng thư số cho các CA cấp dưới và không phát
hành cho người dùng cuối. Tuy nhiên, các CA cấp dưới có thể phát hành chứng thư
số cho các CA ở mức thấp hơn và người dùng cuối, và hiển nhiên là không thể phát
hành chứng thư số cho CA gốc và CA cấp cao hơn. Ngoại trừ CA gốc, tất cả các
CA đều có một CA cấp trên duy nhất. CA gốc tự phát ký chứng nhận cho mình
(self-signed) và được mọi thực thể cuối tin tưởng. người phát hành là CA cấp trên
và chủ thể là các CA cấp dưới. để thêm một CA mới vào kiến trúc thì CA gốc hoặc
bất kỳ một CA nào đó phát hành chứng thư số cho CA mới đó.

Ví dụ sau sẽ mô tả kiến trúc PKI phân cấp. Khi CA gốc phát hành chứng thư số tới
CA cấp dưới, gọi là CA-1 và CA-2, CA gốc sẽ tin tưởng CA-1 và CA-2 trong việc
chỉ cấp phát chứng thư cho các CA cấp dưới, để tạo thành các cấp trong mô hình
phân cấp. CA-1 cấp phát chứng thư cho một CA cấp dưới khác là CA-3 với mục
đích duy nhất là cấp phát chứng thư cho người dùng cuối. Hình 3-5 mô tả sự tin
cậy trong mô hình phân cấp
 Hình 2-17: Kiến trúc phân cấp

Tương tự, CA-1 tin tưởng CA-4 trong việc phát hành chứng thư số cho CA cấp
dưới cua nó là CA-5 và CA-6 và 2 CA này lại cấp phát chứng thư số cho các thực
thể cuối.

Trong đó thì CA gốc cấp chứng thư cho CA-2, ở trường hợp này CA-2 không có
CA cấp dưới nên CA-2 chỉ cấp phát chứng thư cho các thực thể cuối bên dưới nó.

CA cấp trên có thể áp đặt các hạn chế lên các CA cấp dưới tùy vào từng yêu cầu.
Một số các tính chất quan trọng trong việc xây dựng kiến trúc PKI phân cấp:

 Khả năng mở rộng: mô hình PKI phân cấp có khả năng mở rộng tốt. kiến
trúc này phù hợp để đáp ứng cho nhu cầu phát triển tổ chức. Để them một
thực thể mới vào hệ thống PKI, CA gốc chỉ cần thiết lập một mối quan hệ tin
cậy với các thực thể CA cấp dưới. như ta thấy ở hình 3-6 và 3-7, một CA
mới có thể được thêm trực tiếp bên dưới CA gốc hoặc bên dưới các CA cấp
trên như một CA cấp dưới.
 Hình 2-18: Thêm CA mới làm CA gốc

 Dễ triển khai: là kiến trúc đơn hướng, nên kiến trúc PKI phân cấp triển khai
rất đơn giản. đường dẫn cho các thực thể đến gốc hay có thể xác định được
CA phát hành nhanh chóng và dễ dàng.

 Đường dẫn chứng thực ngắn: đường dẫn chứng thực ở trong kiến trúc PKI
phân cấp khá ngắn gọn. Đường dẫn chứng thực dài nhất là chứng thư CA
cấp phát cho từng CA cộng với chứng thư cho thực thể cuối. Cách thức tìm
 ra một nhánh xác thực là theo một hướng nhất định không có hiện tượng
vòng lặp.

Đường dẫn chứng thực cho User Dora ở hình trên:

[RootCA  CA-1]:[CA-1  CA-4]:[CA-4  CA-8]:[CA-8  Dora]

Tuy nhiên, kiến trúc PKI phân cấp lại có một khuyết điểm là chỉ có duy nhất một
điểm tin cậy kiểm soát hoàn toàn kiến trúc phân cấp PKI là CA gốc. Trong trường
hợp CA gốc bị tổn thương thì toàn bộ kiến trúc PKI này sẽ bị sụp đổ. Nếu các CA
cấp dưới bị tổn thương thì vẫn có thể được xử lý bằng việc các CA cấp trên thu hồi
lại các chứng thư số của CA cấp dưới đó và cấp lại cho họ. Tuy nhiên, CA gốc là
đỉnh cao nhất của phân cấp và bất kỳ sự mất tin cậy với CA gốc đều dẫn tới việc
mất tin tưởng toàn bộ các thực thể của kiến trúc PKI. Trong một phạm vi rộng, một
CA duy nhất không thể đảm nhận được tất cả quá trình xác thực. Ngoài ra, việc
thiết lập một tập hợp các CA độc lập thành một PKI phân cấp có thể không thực tế,
bởi vì toàn bộ các thực thể đều phải điều chỉnh điểm tin cậy của họ.

Do đó, kiến trúc mạng lưới được sử dụng để khắc phục khuyết điểm một điểm tin
cậy duy nhất của kiến trúc PKI phân cấp.

2.4.4.2 Kiến trúc mạng lưới

Trong kiến trúc PKI mạng lưới, các CA có quan hệ ngang hàng với nhau, và không
có CA đơn lẻ nào trong toàn bộ kiến trúc PKI. Tất cả các CA trong mô hình mạng
lưới đều là các điểm tin cậy, khi các CA cấp phát chứng thư số cho nhau thì các
CA này chia sẽ một mối quan hệ tin tưởng hai chiều.

Trong kiến trúc PKI mạng lưới, tất cả các CA cần chứng thực chéo lẫn nhau(cross-
certified). Việc chứng thực chéo là quá trình kết nối hai CA, nhằm thiết lập mối
quan hệ tin cậy lẫn nhau được thiết lập giữa các CA. Hai CA sẽ xác thực lẫn nhau
khi các thực thể của 2 CA này muốn liên lạc an toàn với nhau.

Trong kiến trúc PKI mạng lưới có nhiều điểm tin cậy, và do đó một CA đơn bị tổn
thường sẽ không phá vỡ toàn bộ kiến trúc PKI. Thậm chí nếu một CA bị tổn
thương thì các thực thể của các CA khác vẫn có thể tiếp tục liên lạc với các thực
thể khác. Chứng thư số của CA bị tổn thương sẽ bị các CA cấp phát chứng thư số
cho CA đó thu hồi lại, và việc tổn thương của một CA chỉ làm ảnh hưởng đến các
thực thể liên quan đến CA đó chứ không liên quan đến các thực thể trong hệ thống
PKI.

CA mới dễ dàng được thêm vào kiến trúc PKI bằng cách phát hành chứng nhận
đến ít nhất một CA khác trong lưới. Kiến trúc lưới có một điểm đặc biệt là mỗi CA
phải kết nối với các CA khác, tạo thành một đồ thị đầy đủ. Điều đó có nghĩa là nếu
có n CA, số lượng liên kết cần thiết sẽ là n × (n – 1). Do đó, khi số lượng CA
tăng lên, số lượng chứng nhận chéo cũng như số lượng chuỗi chứng nhận trở nên
vô cùng lớn.

Hình 2-19: Kiến trúc mạng lưới

Trong hình trên các CA đều có quan hệ ngang hàng và tin tưởng lẫn nhau. ở ví dụ
trên cả Alice và Bob đều tin tưởng CA-1. James tin tưởng CA-2, Charlie tin tưởng
CA-3. Nếu Alice muốn thiết lập phiên làm việc an toàn với Charlie thì Alice phải
thiết lập một đường dẫn tới Charlie. Khi CA-1 có mối quan hệ tin tưởng ngang
hàng trực tiếp thì Alice sẽ có 2 chứng thư số. Nếu CA-1 kết nối tới CA-2 qua CA-3
thì Alice sẽ có 3 chứng thư số. cấu trúc của đường dẫn chứng thực trong kiến trúc
PKI mạng lưới phức tạp hơn kiến trúc PKI phân cấp. Không giống như hệ thống
phân cấp, việc xây dựng đường dẫn chứng thực từ một chứng thư số của người
dùng tới điểm tin cậy là không xác định.

2.4.4.3 Hệ thống lai

Các kiến trúc PKI kể trên trong chừng mực nào đó đã thỏa mãn các nhu cầu của
một tổ chức hay một nhóm người sử dụng. Tuy nhiên, khi các tổ chức muốn tương
tác với nhau thì việc triển khai kiến trúc PKI trở nên phức tạp do các tổ chức này
không phải lúc nào cũng sử dụng các kiến trúc PKI giống nhau. Ví dụ, một tổ
chức triển khai kiến trúc CA đơn, trong khi tổ chức khác lại triển khai kiến trúc
phân cấp hay lưới.

Trong tình huống như vậy, PKI cần cung cấp một giải pháp tối ưu cho phép các
tổ chức có thể tương tác với nhau trong một môi trường tin cậy. Trong trường hợp
này, kiến trúc “lai” sẽ rất hữu dụng trong việc cho phép quá trình tương tác giữa
các tổ chức thành công.

Một kiến trúc PKI lai chung sẽ liên quan đến kiến trúc đơn, kiến trúc PKI phân cấp
và kiến trúc PKI mạng lưới. Xem như ba tổ chức có ba loại kiến trúc khác nhau. Tổ
chức AllSolv là kiến trúc CA đơn có tên là tổ chức 2. WebEyes, Inc. có kiến trúc
PKI phân cấp gọi là tổ chức 1 và kiến trúc của SureSolv, Inc là kiến trúc PKI mạng
lưới có tên là tổ chức 3. Hình 3-11 mô tả trường hợp trên.
 Hình 2-20: Hệ thống lai

Có ba loại kiến trúc PKI lai, đó là:

 Kiến trúc danh sách tin cậy mở rộng (Extended trust list): đây là mạng mở
rộng của kiến trúc danh sách tin cậy để hỗ trợ đường dẫn chứng thực dài hơn
một chứng thư số.

 Kiến trúc PKI chứng thực chéo (cross-certified PKI): các PKI thiết lập mối
quan hệ ngang hàng để cho phép liên lạc an toàn.

 Kiến trúc CA cầu nối (bridge CA): hỗ trợ các kiến trúc PKI phức tạp

Kiến trúc danh sách tin cậy mở rộng

Giống như kiến trúc danh sách tin cậy cơ bản, ở kiến trúc danh sách tin cậy mở
rộng, thực thể cuối duy trì một danh sách các điểm tin cậy. mỗi điểm tin cậy liên
quan đến một PKI của tổ chức mà thực thể cuối tin cậy. Mỗi điểm tin cậy này có
thể là một CA đơn, PKI phân cấp hoặc PKI mạng lưới.
 Hình 2-21: Kiến trúc danh sách tin cậy mở rộng

Danh sách tin cậy của DBPhuong, HTPTrang, TMTriet là {CA-1, CA-2, CA-3}
hoặc {CA-1, CA-2, CA-4} hoặc {CA-1, CA-2, CA-5}. Danh sách tin cậy của
LVMinh là {CA-1, CA-2, CA-4}.

Kiến trúc chứng thực chéo

Trong kiến trúc chứng thực chéo, CA gốc hoặc CA cấp con của một PKI thiết lập
quan hệ tin cậy ngang hàng với các CA gốc hoặc các CA cấp con của PKI khác,
tức là các CA gốc của mỗi nhóm sẽ cấp chứng nhận cho nhau (cross-certification).

Mỗi người dùng có một điểm tin cậy đơn, quan hệ chứng thực chéo là quan hệ
ngang hàng. Khi các CA chứng thực chéo với nhau, các thực thể có thể xác thực
các thực thể ở hệ thống PKI khác. Vì thế, có thể liên lạc an toàn giữa tất cả các
thực thể qua các PKI. Trong kiến trúc danh sách tin cậy mở rộng, cả Alice và
Robert đều phải cập nhật danh sách tin cậy của mình. Kiến trúc này phù hợp cho
một nhóm nhỏ các PKI muốn thiết lập mối quan hệ tin cậy lẫn nhau.
 Hình 2-22: Kiến trúc chứng thực chéo

Theo hình 2-22, ba quan hệ ngang hàng và 6 chứng thư số được thiết lập. do đó
việc chứng thực chéo các PKI yêu cầu (n*n-n)/2 quan hệ ngang hàng và (n*n-n)
chứng thư số.

Đường dẫn chứng nhận sau được dựng lên bởi DBPhương cho HTPTrang:

 [CA–1  CA–12] : [CA–12  HTPTrang]

Đường dẫn chứng nhận sau được dựng lên bởi ĐBPhương cho TMTriet:
 [CA–1  CA–2] : [CA–2  TMTriet]

Các đường dẫn chứng nhận sau được dựng lên bởi DBPhương cho LVMinh:

 [CA–1  CA–3] : [CA–3  CA–4] : [CA–4  LVMinh]

 [CA–1  CA–3] : [CA–3  CA–5] : [CA–5  CA–4] : [CA–4  LVMinh]

Kiến trúc CA cầu nối

Kiến trúc CA cầu nối là kiến trúc phù hợp nhất để kết nối các PKI có kiến trúc
khác nhau. Không giống như kiến trúc CA mạng lưới, kiến trúc CA cầu nối không
cấp phát chứng thư số trực tiếp cho người dùng. CA cầu nối thiết lập mối quan hệ
tin cậy ngang hàng với các CA của các thực thể khác nhau.

Sự thiết lập mối quan hệ tin cậy trong kiến trúc CA cầu nối phụ thuộc vào loại kiến
trúc PKI có thiết lập sự tin cậy. ví dụ trong kiến trúc PKI phân cấp, sự tin cậy được
thiết lập với CA gốc, trong khi kiến trúc mạng lưới thì mối quan hệ tin cậy lại được
thiết lập với bất kỳ CA nào trong hệ thống PKI. CA thiết lập mối quan hệ với CA
cầu nối được coi như là một CA chính, các mối quan hệ tin cậy giữa CA chính này
với CA cầu nối đều là mối quan hệ ngang hàng. Dễ dàng để thêm một CA hoặc
toàn bộ PKI vào kiến trúc này và sự thay đổi này là trong suốt với người dùng và
không có thay đổi nào trong các điểm tin cậy xảy ra.

Trong kiến trúc CA cầu nối PKI cầu nối kết nối các PKI khác tại một điểm chung
hoặc một trung tâm. Trong kiến trúc này, nếu CA chính bị tổn thương thì CA cầu
nối sẽ thu hồi chứng thư số của CA này, bằng cách này, các mối quan hệ sẽ không
bị ảnh hưởng. trong trường hợp CA cầu nối bị tổn thương thì các CA chính sẽ thu
hồi chứng thư số đã cấp phát cho CA cầu nối
 Hình 2-23: Kiến trúc CA cầu nối

Đường dẫn chứng nhận sau được dựng lên bởi DBPhuong cho HTPTrang:

 [CA–1  CA–12] : [CA–12  HTPTrang]

Đường dẫn chứng nhận sau được dựng lên bởi DBPhuong cho TMTriet:

 [CA–1  BCA] : [BCA  CA–2] : [CA–2  TMTriet]

Các đường dẫn chứng nhận sau được dựng lên bởi DBPhuong cho LVMinh:

 [CA–1  BCA] : [BCA  CA–3] : [CA–3  CA–4] : [CA–4  LVMinh]

 [CA–1  BCA] : [BCA  CA–3] : [CA–3  CA–5] : [CA–5  CA–4] :

[CA–4  LVMinh]

2.4.5. Đường dẫn chứng thực

Nếu việc thiết lập một CA (có thể phát hành các chứng thư khoá công khai cho tất
cả những người giữ các cặp khoá công khai và khoá riêng trên thế giới) là khả thi
và tất cả những người sử dụng tin cậy vào các chứng thư do CA này phát hành thì
chúng ta có thể giải quyết được vấn đề phân phối khoá công khai. Rất tiếc là điều
này không thể thực hiện được. Đơn giản vì một CA không thể có đầy đủ thông tin
và các mối quan hệ với tất cả các thuê bao để có thể phát hành các chứng thư được
tất cả những người sử dụng chấp nhận. Vì vậy, chúng ta cần chấp nhận sự tồn tại
của nhiều CA trên thế giới.

Giả thiết khi có nhiều CA, một người sử dụng giữ khoá công khai của một
CA (CA này đã phát hành một chứng thư cho thành viên mà anh ta muốn truyền
thông an toàn) một cách bí mật là không thực tế. Tuy nhiên, để có được khoá công
khai của CA, người sử dụng có thể tìm và sử dụng một chứng thư khác có khoá
công khai của CA này nhưng do CA khác phát hành, khoá công khai của CA này
được người sử dụng lưu giữ an toàn.

Vì vậy, một người sử dụng có thể áp dụng phương thức đệ quy chứng thư để
có được khoá công khai của các CA và khoá công khai của những người sử dụng
từ xa. Điều này dẫn đến một mô hình gọi là dây chuyền chứng thực hoặc đường
dẫn chứng thực, dựa vào các hệ thống phân phối khoá công khai. Mô hình này
được minh hoạ như sau:
 Hình 2-24: Đường dẫn chứng thực

Người sử dụng có thể lấy và sử dụng khoá công khai cảu một người giữ cặp
khoá bất kỳ, ví dụ như lqtung, cung cấp một đường dẫn chứng thực tin cậy từ một
CA gốc của người sử dụng khoá công khai này tới lqtung, thông qua một số CA
trung gian.

Ở đây chúng ta chưa nói đến bất kỳ giới hạn nào liên quan đến cấu trúc quan
hệ giữa các CA. Khi tìm thấy một đường dẫn chứng thực, hệ thống sẽ làm việc.
 Chương 3. QUY TRÌNH HOẠT ĐỘNG CỦA HỆ THỐNG PKI
3.1. CHỨC NĂNG CỦA CÁC THÀNH PHẦN TRONG HỆ THỐNG PKI

Cơ sở hạ tầng khóa công khai (Public Key Infrastructure – PKI) là tập hợp các
phần cứng, phần mềm, con người, các chính sách và các thủ tục cần thiết để tạo,
quản lý, lưu trữ và phân phối khóa, chứng thư. Để nó thực hiện được các chức
năng này, cần phải có các thành phần khác nhau, đó là:

 Thẩm quyền chứng thực (Certificate Authority - CA): Cấp và thu hồi
chứng thư số

 Thẩm quyền đăng ký (Registration Authority - RA): gắn kết giữa khóa
công khai và định danh của người giữ chứng thư số
 Thẩm quyền xác nhận (Validation Authority - VA)

 Người dùng, ứng dụng cuối (PKI client): là chủ thể của chứng thư số
PKI
 Hình 3-1: Các thành phần của một hạ tầng khoá công khai

3.1.1. Thành phần CA (Certification Authority)

Trong PKI có một số người có thẩm quyền, những người này được tin cậy bởi tất
cả người dùng khác. Họ có những nhiệm vụ chính:

 Gắn một cặp khóa công khai với một định danh đã cho

 Chứng nhận việc gắn kết này bằng cách ký số một cấu trúc dữ liệu có
chứa biểu diễn của định danh (gọi là chứng thư)
  Thành phần này được gọi là thẩm quyền chứng thực (Certification
Authority – CA)

Certificate Authority (CA) là một tổ chức được tin tưởng trong việc cấp phát
chứng thư số và công nhận các nội dung thông tin lưu giữ trong chứng thư số. Nói
một cách khác, CA là trái tim của hệ thống PKI, là tổ chức quản lý của PKI.

CA cũng đồng thời chịu trách nhiệm phát hành các danh sách chứng thư bị
hủy (CRL) nếu nó không ủy quyền cho một đơn vị chuyên trách làm việc này
(CRL Issuer). CA cũng thực hiện một số tác vụ quản trị như đăng ký cho người
dùng, tuy nhiên việc này thường được ủy thác cho RA (Registration Authority)
(RA sẽ được giải thích rõ ràng sau). Trong quá trình hoạt động, CA còn kiêm
nhiệm cả việc lưu và khôi phục khóa mặc dù công việc này cũng có thể được ủy
thác cho một bộ phận chuyên trách.

Trước khi phát hành một chứng thư số, CA kiểm tra lại yêu cầu lấy chứng
thư của RA (Registration Authority). Nếu yêu cầu là hợp lệ, CA sẽ sử dụng thủ tục
của nó (thủ tục này tùy vào chính sách của tổ chức, và cơ sở hạ tầng có khả năng
xác thực yêu cầu) và phát hành chứng thư.

Chức năng của CA:

- Cấp mới, gia hạn, thu hồi chứng thư số.

- Phát hành CRL.

- Quản lý mọi mặt (vòng đời) của chứng thư số sau khi phát hành.

3.1.2. Thành phần RA (Registration Authority)

Mặc dù CA có thể thực hiện những chức năng đăng ký cần thiết, nhưng đôi khi
cần có thực thể độc lập thực hiện chức năng này. Thực thể này được gọi
là “registration authority” - trung tâm đăng ký. Ví dụ khi số lượng thực thể cuối
trong miền PKI tăng lên và số thực thể cuối này được phân tán khắp nơi về mặt địa
lý thì việc đăng ký tại một CA trung tâm trở thành vấn đề khó giải quyết. Để giải
quyết vấn đề này cần thiết phải có một hoặc nhiều RAs (trung tâm đăng ký địa
phương).
 Mục đích chính của RA là để giảm tải công việc của CA. Chức năng thực hiện
của một RA cụ thể sẽ khác nhau tuỳ theo nhu cầu triển khai PKI nhưng chủ yếu
bao gồm những chức năng sau:

 Xác thực cá nhân chủ thể đăng ký chứng thư.

 Kiểm tra tính hợp lệ của thông tin do chủ thể cung cấp.

 Xác nhận quyền của chủ thể đối với những thuộc tính chứng thư được yêu
cầu.

 Kiểm tra xem chủ thể có thực sự sở hữu khoá riêng đang được đăng ký hay
không - điều này thường được đề cập đến như sự chứng minh sở hữu (proof
of possession - POP).

 Tạo cặp khoá bí mật /công khai.

 Phân phối bí mật được chia sẻ đến thực thể cuối (ví dụ: khoá công của CA).

 Thay mặt chủ thể thực thể cuối khởi tạo quá trình đăng ký với CA.

 Lưu trữ khoá riêng.

 Khởi sinh qúa trình khôi phục khoá.

 Phân phối thẻ bài vật lý (ví dụ như thẻ thông minh) chứa khoá riêng.

Nhìn chung, RA xử lý việc trao đổi (thường liên quan đến tương tác người
dùng) giữa chủ thể thực thể cuối và quá trình đăng ký, phân phối chứng thư và
quản lý vòng đời chứng thư/khoá. Tuy nhiên, trong bất kỳ trường hợp nào thì RA
cũng chỉ đưa ra những khai báo tin cậy ban đầu về chủ thể. Chỉ CA mới có thể cấp
chứng thư hay đưa ra thông tin trạng thái thu hồi chứng thư như CRL

Tóm lại, việc xuất hiện của RA mang lại 2 lợi ích chính:

- Giảm chi phí, đặc biệt là đối với các tổ chức phân tán trên diện rộng, có thể
phân tán các RA để quản lý giúp CA.

- Việc giảm nhẹ công việc cho CA giúp CA có thể nghỉ ngơi nhiều hơn. Do đó
sẽ giảm thiểu được các cơ hội tấn công nhằm vào CA đó.
 3.1.3. Thành phần VA (Varidation Authority)

VA đóng vai trò là:

Kho công cộng chứa chứng thư số: CA phát hành chứng thư, gửi cho người dùng
và lưu trữ nó vào kho chứng thư (Certificate Repository). Kho chứng thư được CA
công bố và được truy cập bằng nhiều giao thức khác nhau (http,ftp...)

Các dịch vụ chứng thực: CRL, OCSP, TimeSamp....

+ CRL (Certificate Revocation List) là danh sách các chứng thư bị thu hồi và
không còn được tin dùng nữa. Mỗi một mục trong CRL tương ứng với một chứng
thư và thường gồm 3 thông tin sau: Serial number của chứng thư, thời điểm bị thu
hồi, lý do thu hồi. Một CRL được tạo và phát hành định kỳ sau một khoảng thời
gian nào đó do người quản trị CA chỉ định.

+OCSP là một giao thức được sử dụng để nhận về trạng thái của một chứng thư có
chuẩn dưới dạng là X.509. Hoạt động theo mô hình client/server, các thông điệp
cảu OCSP được mã hóa theo chuẩn ANS.1 và được truyền qua giao thức HTTP.

+ Time Stamp : Dấu (tem) thời gian – time stamping là một đối tượng dữ liệu gắn
kết một dữ kiện với một mốc thời gian xác định. Dấu thời gian an toàn là dấu thời
gian thỏa mãn các tính chất xác thực và toàn vẹn. Dịch vụ cấp dấu thời gian cấp
dấu thời gian cho các thực thể cuối được thực hiện bởi một bên tin cậy thứ ba gọi
là thẩm quyền dấu thời gian – Time-Stamp Authority (TSA). Dấu thời gian được
mã hóa dưới dạng ASN.1 và được truyền qua các phương tiện: email, file, tcp,
http.

3.1.4. Người sử dụng/thực thể đầu cuối (End Entities – EE)

Trên thực tế, một EE có thể là người dùng cuối, hoặc một thiết bị như router, máy
chủ, một xử lý, hay bất kì thứ gì có thể được gán là đối tượng của hệ thống chứng
thư khóa công khai. Tóm lại, EE có thể được hiểu là khách hàng của các dịch vụ
PKI. Thậm chí, một nhà cung cấp các dịch vụ PKI cũng đôi khi được coi là EE, ví
dụ một RA có thể coi là EE của CA (CA và RA sẽ được giải thích cụ thể sau). Các
EE bị ràng buộc bởi các chứng thư. Ví dụ như các server và các người dùng đầu
cuối phải được kết nạp vào PKI trước khi có thể tham gia như một thành viên của
PKI.
Các thực thể yêu cầu CA hoặc RA để yêu cầu chứng thư là PKI client. Để đạt được
chứng thư từ CA, PKI Client thường phải thực hiện các bước sau:

 Gửi một yêu cầu sinh cặp khóa bí mật – công khai

 Sau khi cặp khóa được sinh ra, một yêu cầu được gửi tới CA để sinh chứng
thư. Yêu cầu này có thể thông qua RA.

 Sau khi client nhận chứng thư từ CA, họ có thể sử dụng chứng thư để định
danh cho chính bản thân hoặc dùng để xác thực người nắm giữ chứng thư.

Tất cả giao dịch giữa client và CA phải được giữ an toàn. Mặt khác, client phải có
trách nhiệm đảm bảo an toàn cho khóa riêng của họ. Bởi vì nếu khóa bí mật bị mất
thì việc mã hóa có thể dễ dàng bị giải mã. Hoặc, nếu khóa bí mật bị tấn công thì
những người dùng không được phép có thể sử dụng khóa này để giải mã. Bạn có
thể đảm bảo an toàn cho khóa riêng bằng cách sử dụng các phần cứng có khả năng
bảo mật như thẻ token hoặc smart card.

3.1.5. Chức năng của các hệ thống dịch vụ chứng thực chữ ký số

Chứng thư và hệ thống kho lưu trữ các chứng thư

Trong việc dùng khóa công khai, chứng thư là một văn bản điện tử được
CA ký cho các EE, công nhận tính đúng đắn và xác thực của các thông tin mà EE
dùng để giao tiếp.

Kho lưu trữ các chứng thư thường là một thư mục. Tuy nhiên, trong kiến
trúc PKI, kho này thực chất là một cách nào đó để lưu các thông tin liên quan của
PKI, ví dụ như các chứng thư khóa công khai, các CRL.

Trong chuẩn X.500, kho lưu trữ này là một thư mục máy chủ mà máy khách
có thể truy cập qua giao thức LDAP (Lightweight Directory Access Protocol),
hoặc lấy file trên máy chủ qua giao thức FTP (File Transfer Protocol), giao thức
HTTP (Hyper Text Transfer Protocol).

Ngoài ra, kho này còn đáp ứng được một số yêu cầu từ phía hệ thống máy
khách. Ví dụ có thể trả lời cho máy khách về tình trạng của các chứng thư, xem
chúng đã bị hủy chưa. Tuy nhiên, lợi ích cơ bản của các kho lưu trữ này chính là
việc các EE có nơi để tìm các chứng thư và các CRL. Ví dụ khi A muốn giao tiếp
với B, A phải biết được khóa công khai của B, và khóa đó có thể tìm thấy trong
kho lưu trữ này. Danh sách các chứng thư bị hủy (CRL - Certificate Revocation
List) và bộ phận phát hành (CRL Issuers). CRL chứa danh sách các chứng thư bị
hủy, kèm theo chữ kí điện tử để đảm bảo sự toàn vẹn và xác thực của nó. Chữ kí
trong CRL thường chính là của thực thể đã kí và phát hành các chứng thư trong
CRL này. Các CRL thường được lưu để có thể dễ dàng thực hiện xác minh các
chứng thư khi làm việc off-line.

Thông thường, CA phát hành các chứng thư số nào thì sẽ đồng thời chịu
trách nhiệm phát các thông tin về các chứng thư bị hủy trong số đó. Tuy nhiên, CA
cũng có thể ủy thác cho một bộ phận khác chuyên phát hành các thông tin này, đó
chính là bộ phận phát hành CRL (CRL Issuer). Trong trường hợp đó, các CRL
được phát hành gọi là các CRL gián tiếp.

3.2. QUY TRÌNH QUẢN LÝ VÒNG ĐỜI CHỨNG THƯ SỐ

Chứng thư số là một phần của hệ thống PKI. Quá trình quản lý chứng thư số bắt
đầu khi người dùng yêu cầu đăng ký chứng thư số. Một cơ quan đăng ký
(Registration Authority – RA) thay mặt cho Trung tâm chứng thực (Certification
Authority – CA) thực hiện việc đăng ký này. Khi chứng thư số được phát hành thì
sẽ hiệu lực trong một khoảng thời gian, được gọi là thời gian sống của chứng thư
số, thời gian sống này được xác định bởi chính sách CA. tuy nhiên, chứng thư số
có thể bị vô hiệu hóa trước khi hết hạn. Ví dụ, nếu khóa bí mật bị tổn thương hoặc
bị nghi ngờ thì chứng thư số sẽ không được xem là hợp lệ trước khi hết hạn.

Trước khi xử lý dữ liệu nhận từ mạng, người dùng kiểm tra tính hợp lệ của chứng
thư số thông qua thời gian sống của chứng thư. Khi chứng thư số bị tổn thương,
ngày hết hạn không được hiển thị nếu chứng thư số đó hợp lệ. trong tình huống
như vậy, làm thế nào để chắc chắn liệu rằng chứng thư số là hợp lệ?

Việc này được giải quyết bằng danh sách thu hồi chứng thư số (Certificate
Revocation List – CRL). CRL là một danh sách bao gồm tất cả các chứng thư số bị
thu hồi. Ngoài danh sách chứng thư số bị thu hồi, CRL còn bao gồm thông tin, lý
do thu hồi của các chứng thư số đó.

Trong phần này, chúng ta sẽ tìm hiểu về quá trình đăng ký chứng thư số và cơ quan
đăng ký RA thực hiện việc đăng ký chứng thư số cho người dùng cuối. sau đó sẽ
tìm hiểu về quá trình sao lưu khóa và hết hạn và lưu trữ chứng thư số, đồng thời
tìm hiểu về quá trình lấy và xác nhận tính hợp lệ của chứng thư số.

Tiếp theo, chúng ta tìm hiểu tổng quan về CRL và các phiên bản, các trường mở
rộng khác nhau của CRL. Cuối cùng sẽ tìm hiểu về quá trình phân phối CRL.

3.2.1. Hoạt động đăng ký chứng thư số và cơ quan đăng ký

Đăng ký chứng thư số là một quá trình người dùng gửi yêu cầu xin cấp một chứng
thư số tới cơ quan thẩm quyền chứng thực (CA). Quá trình đăng ký chứng thư số
có thể được thực hiện bởi một cơ quan khác với CA, cơ quan đó là cơ quan đăng
ký (Registration Authority – RA), cơ quan này hỗ trợ cho nhiệm vụ đăng ký cho
CA.

Một tiêu chuẩn cho quá trình đăng ký chứng thư số quy định việc đăng ký chứng
thư gồm ba lý do sau:

- Để trở thành một PKI client và cơ quan đăng ký RA hoặc cơ quan chứng
thực CA

- Để việc cấp phát chứng thư số duy nhất và thuận lợi, giúp đảm bảo việc thu
hồi chứng thư số nhanh chóng.

- Sử dụng chuẩn chứng thư số X509.

PKIX hay cơ sở hạ tầng khóa công khai X509 (Public Key Infrastructure X.509)
là một khuyến cáo để giải quyết các chứng thư số cụ thể và các hồ sơ CRL liên
quan với Internet. Nhóm PKIX của TETF (Internet Engineering Task Force) được
thành lập năm 1995 và đã đưa ra một số các tài liệu RFC và Internet Draft để xác
định định dạng và truyền thông tin giữa các hệ thống PKI khác nhau.PKIX đưa ra
các RFC gồm: RFC2459, RFC2511, RFC2560, và RFC2587 góp phần vào việc
đưa PKI ra Internet một cách đáng kể.

Cơ quan đăng ký RA hoạt động như một vị trí trung gian giữa người dùng và cơ
quan chứng thực CA. thông thường RA sẽ nhận yêu cầu xin cấp phát chứng thư từ
người dùng. Yêu cầu này được thực hiện theo mẫu đăng ký do RA ban hành. Chức
năng chính của RA là:

- Xác thực định danh người dùng khi tiếp nhận yêu cầu
 - Xử lý việc đăng ký chứng thư
- Chuyển thông tin tới CA để hoàn thành quá trình đăng ký.

Thông thường, RA liên quan đến 3 thành phần: trình điều khiển đăng ký, nhân viên
đăng ký, và người quản lý đăng ký.

- Trình điều khiển đăng ký: là một máy chủ tiếp nhận yêu cầu đăng ký từ
người dùng, và máy chủ này kết nối với máy chủ CA.

- Nhân viên đăng ký: là một cá nhân xử lý, xác mình và chấp nhận yêu cầu
đăng ký. Khi CA cấp phát chứng thư số tưởng ứng, thì nhân viên này sẽ
phân phối chứng thư số tới người dùng

- Người quản lý RA: là một cá nhân quản lý các nhân viên RA và đảm bảo
rằng các giao dịch công bằng, trước khi nhân viên RA chuyển yêu cầu chứng
thư tới CA, tất cả các yêu được được xác minh phải được sự chấp thuận của
quản lý RA.

3.2.1.1 Đăng ký chứng thư số

Đăng ký chứng thư số là quá trình nhận yêu cầu đăng ký chứng thư từ người dùng.
Những yêu cầu này sẽ đượccơ quan đăng ký RA xử lý và xác nhận. Quá trình
đăng ký chứng thư gồm các bước sau đây:

- Người dùng gửi yêu cầu mẫu đăng ký tới cơ quan RA. Cơ quan đăng ký RA
xác định trước định dạng của mẫu đăng ký này. Yêu cầu này có thể được
thực hiện trực tuyến phụ thuộc vào chính sách theo chức năng của cơ quan
đăng ký

- Khi nhận được yêu cầu đăng ký, cơ quan đăng ký RA sẽ gửi mẫu đăng ký
tới người dùng

- Người dùng gửi mẫu đăng ký đã được hoàn tất cho RA

- Dựa trên các thông tin trong mẫu đăng ký, RA xác minh danh tính của người
dùng và gửi yêu cầu đăng ký tới CA tương ứng

Việc xác minh này được thực hiện bởi RA ở bước 4 phụ thuộc vào mỗi chính sách
theo quá trình hoạt động của RA và cách thức chứng thư số sẽ được sử dụng. ví dụ,
nếu người dùng dự định sử dụng chứng thư số trong giao dịch tài chính, quá trình
xác thực có thể rất nghiêm ngặt. tuy nhiên nếu chứng thư số chỉ sử dụng để ký mã
thông thường thì quá trình xác minh sẽ có thể được nới lỏng hơn.

- Sau khi kiểm tra yêu cầu, CA gửi trả lại phản hồi tới RA. Phản hồi này có
thể bị từ chối nếu người dùng không điền vào các yêu cầu bắt buộc trên mẫu
đăng ký

- Nếu phản hồi từ CA được chấp nhận, RA đăng ký người dùng và gửi thông
tin đăng ký cho người dùng

Hình 3-2: Quá trình đăng ký

Sau khi quá trình đăng ký được hoàn thất, thì một cặp khóa sẽ được sinh ra. Cặp
khóa này rất quan trọng đối với các vấn đề như chống chối bỏ trách nhiệm, xác
thực, … khóa công khai của cặp khóa này được gắn với chứng thư số phát hành
cho người dùng.
 3.2.1.2 Sinh khóa

Một cặp khóa có thể được sinh ra tại người dùng cuối hoặc CA cuối. Quyết định
nơi sinh cặp khóa phụ thuộc vào tính sẵn sàng của tài nguyên sinh khóa và phụ
thuộc vào mục đích sử dụng chứng thư số. ví dụ, nếu một người dùng sử dụng cặp
khóa vào mục đích xác thực, thì hoặc là CA hoặc người dùng đó có thể sinh ra cặp
khóa. Tuy nhiên, nếu người dùng không có đủ các tài nguyên cho việc sinh khóa
thì CA sẽ đảm nhiệm trách nhiệm này.

Trong trường hợp chống chối bỏ, người dùng được khuyến khích sinh ra cặp khóa,
nếu CA sinh ra cặp khóa thì sẽ có khóa riêng của cặp khóa được sinh ra, khóa riêng
này được truyền tới cho người dùng và có thể gặp phải các hiểm họa an toàn. Ví
dụ, nếu khóa riêng này bị tổn thương trong quá trình truyền thì một số người dùng
có thể sử dụng nó để thực hiện giao dịch mà không phải là người dùng ban đầu.
trong trường này người dùng ban đầu không có thông tin về giao dịch được thực
hiện và sẽ từ chối trách nhiệm với giao dịch đã hoàn tất đó. Nếu khóa được sinh ra
ở người dùng cuối, khóa riêng sẽ không phải truyền đi, , người dùng sẽ sở hữu
khóa riêng đó và họ sẽ không từ chối được trách nhiệm đối với giao dịch mình
thực hiện.

trong việc sinh khóa CA, CA sử dụng thuật toán đã được thỏa thuận trước để ký
lên cặp khóa, và CA phải truyền khóa riêng tới cho người dùng, để thực hiện được
điều này, CA cần phải tạo ra một kênh truyền khóa riêng an toàn, hơn nữa, để
truyền khóa riêng, CA cũng phải công bố chứng thư số với khóa công khai tương
ứng trong cơ sở dữ liệu thư mục quốc tế.

CA và người dùng không những có đủ các tài nguyên cần thiết cho việc tạo khóa
mà còn phải có các tài nguyên thực hiện việc sao lưu khóa. Việc sao lưu cần phải
thực hiện khi khóa được sinh ra. Bản sao này được sử dụng để giải mã các thông
điệp trong trường hợp người dùng làm mất khóa gốc. khóa riêng của cặp khóa cần
phải luôn luôn được lưu trữ an toàn bởi người sở hữu để giảm thiểu tối đa hiểm
họa đối với khóa riêng. Chủ sở hữu khóa riêng cũng cần có bản sao lưu khóa phù
hợp. sau khi khóa được tạo ra và khóa riêng được bảo vệ an toàn, thì chứng thư số
được tạo ra. Khóa công khai của cặp khóa tương ứng được gắn với chứng thư số
này.

3.2.2. Quản lý, duy trì khóa và chứng thư số

Quản lý duy trì khóa và chứng thư số

Chứng thư số gắn kết thông tin của chủ sở hữu với khóa công khai của họ. CA tạo
chứng thư số không quan tâm đến nơi sinh cặp khóa. Nếu cặp khóa được người
dùng cuối sinh ra, khóa công khai sẽ được gửi tới CA cùng với yêu cầu sinh chứng
thư số. tuy nhiên nếu bên thứ ba tin cậy hoặc CA sinh cặp khóa, thì khóa riêng
tương ứng với cặp khóa đó nhất định phải phân phối tới cho người chủ sở hữu
thông qua một cơ chế bảo mật.

Một số các triển khai PKI có cơ chế cho mô hình hai cặp khóa. Trong mô hình này,
một cặp khóa được sử dụng để ký và kiểm tra chữ ký trong khi cặp khóa kia dùng
để mã hóa và giải mã. Do vậy, trong mô hình 2 cặp khóa này, sẽ có 2 chứng thư số
được phân phối tới người dùng.

3.2.2.1 Sao lưu khóa

Một hành động khác liên quan đến việc duy trì khóa cần phải được xem xét kỹ
lưỡng là vấn đề sao lưu khóa. Một CA thực hiện bản sao của khóa để chắc chắn
rằng nếu người dùng bị mất khóa riêng của họ, thì dữ liệu được mã hóa bởi khóa
công khai tương ứng với khóa riêng đó vẫn có thể được giải mã. Khóa này phải sao
lưu thường xuyên khi chứng thư số được sinh ra. CA hoặc người dùng có thể thực
hiện việc sao lưu khóa này. Trong trường hợp khóa riêng được sử dụng để ký lên
các tài liệu, thì CA không cần thiết phải sao lưu các khóa này. do vậy, không có
một quy luật rõ ràng dành cho việc sao lưu khóa. Các chính sách nhất thiết phải
phụ thuộc vào yêu cầu sử dụng khóa.

Nếu hai cặp khóa được sử dụng, một dành cho mã hóa dữ liệu và một dành để ký
số tài liệu, thì cặp khóa dành cho ký số không cần phải sao lưu, thậm chí nếu có bị
mất thì cũng không có dữ liệu mã hóa nào cần khóa này để giải mã.

3.2.2.2 Hết hạn và lưu trữ chứng thư số

Chứng thư số gắn kết với khóa công khai của người dùng có hiệu lực trong một
khoảng thời gian giới hạn. Khi kết thúc giai đoạn này, chứng thư số sẽ bị hết hạn.
một số các chứng thư số có thể không còn hiệu lực trước khi đến ngày hết hạn.

CA có thể thu hồi các chứng thư số hết hạn và không còn hiệu lực. các CA cấp
phát sẽ căn cứ vào yêu cầu thu hồi chứng thư từ chủ sở hữu, vô hiệu hóa chứng
thư số gốc và điền thông tin các chứng thư này vào danh sách thu hồi chứng thư số
(Certificate Revocation List – CRL).

CA phải có khả năng thiết lập tính hợp lệ của chứng thư số khi các chứng thư này
bị hết hạn. bởi vì ngay cả khi chứng thư số bị hết hạn, các giao dịch đã được thực
hiện bởi chứng thư số đó khi có hiệu lực nên được cho phép. Do vậy, các CA cần
phải duy trì đầy đủ thông tin lưu trữ để xác thực định danh của người dùng hoặc hệ
thống có tên trong chứng thư số và xác nhận tính hợp lệ của chứng thư số tại thời
điểm tài liệu được ký. Việc này có thể được thực hiện bằng tem thời gian mật mã.

Kho lưu trữ là nơi lưu trữ thông tin lâu dài an toàn. Kho lưu trữ sẽ khẳng định rằng
thông tin là chính xác tại thời điểm lưu trữ và không bị sửa đổi trong suốt quá trình
lưu trữ. Kho lưu trữ đóng vai trò thứ yếu trong hoạt động thường nhật của hệ thống
PKI nhưng lại có những yêu cầu kiểm soát kỳ thuật và thủ tục nghiêm ngặt.

3.2.2.3 Cập nhật chứng thư số

Chứng thư số chỉ có hiệu lực trong một khoảng thời gian cố định, bắt đầu từ khi
chứng thư số được cấp phát. Khi chứng thư số bị hết hạn, một khóa công khai/khóa
bí mật được sinh ra và khóa công khai được gắn kết với chứng thư số. Việc này
được gọi là cập nhật khóa. Cập nhật khóa được thực hiện tự động khi khóa đã sử
dụng được 70-80% thời gian sống và khóa mới nên sử dụng cho các hoạt động mật
mã sau này. Quá trình này là một giai đoạn chuyển tiếp hợp lý cho thực thể cuối có
được chứng thư số mới. Khi có chứng thư số mới trong thời gian thích hợp, các
thực thể có thể tiến hành hoạt động giao dịch mà không phải quan tâm đến việc hết
hạn chứng thư số.

Để cấp phát một chứng thư số mới, CA cũng đồng thời cấp phát một cặp khóa tái
sử dụng chứng thư số. Mô tả về hai khóa trong chứng thư số sử dụng lại khóa được
đưa ra như sau:

- Chứng thư số đầu tiên bao gồm một khóa công khai cũ và được ký với một
khóa bí mật mới. chứng thư số tái sử dụng này cho phép thuê báo có chứng
thư số được ký với khóa bí mật mới để thiết lập một đường dẫn chứng thực
hợp lệ tới các chứng thư số đã ký với khóa bí mật cũ trước đó.

- Chứng thư số thứ hai bao gồm khóa công khai mới và được ký với khóa bí
mật cũ. Chứng thư số này cho phép thuê bao có chứng thư số được ký với
 khóa bí mật cũ để thiết lập đường dẫn chứng thực với chứng thư số được ký
với khóa bí mật mới.

Bằng cách này, các thuê báo có chứng thư số được ký bởi các khóa bí mật cũ và
thuê bao có chứng thư số được ký bởi khóa bí mật mới có thể xác thực được các
chứng thư số của nhau.

3.2.2.4 Tải và xác nhận tính hợp lệ của chứng thư số

Sau khi được cấp phát, chứng thư số phải trải qua các giai đoạn khác nhau, như
hủy bỏ, hết hạn,… Do vậy, việc thiết lập độ tin cậy của chứng thư số trước khi
chứng thư số được sử dụng để tin cậy chủ sở hữu là rất quan trọng. Thiết lập danh
tính của người dùng liên quan tới hai nhiệm vụ, tải chứng thư và xác nhận chứng
thư số. Ví dụ, James là một người dùng của công ty AllSolv Inc., được CA cấp
phát một chứng thư số. Charlie là thành viên của Solution Inc., muốn liên lạc với
Jame. Để thực hiện được việc này, Charlie phải đảm bảo rằng người mà anh ta giao
dịch chính là James. Do vậy để chứng minh danh tính của James, đầu tiên Charlie
phải có được chứng thư số của James, chứng thư số đó bao gồm thông tin liên quan
đến định danh của James và được ký bởi một CA tin cậy. sau đó Charlie sử dụng
chứng thư số của CA đó để xác thực chữ ký số trên chứng thư số của James. Bằng
cách đó, Charlie xác thực được định danh của James.

 Tải chứng thư số

Để xác thực định danh của thực thể, ta cần phải truy xuất vào chứng thư số đã cấp
phát để xác định danh tính và cũnglà chứng thư số của CA cấp phát.

Việc tải chứng thư số phụ thuộc vào vị trí của chứng thư. Chứng thư có thể được
phân phối bởi các phương tiện thư điện tử sử dụng giao thức S-MIME (Secure
Multipurpose Internet Mail Extensions) hoặc có thể được công bố trong thư mục
X.500. Nếu chứng thư số được công bố trong thư mục X.500, người dùng có thể sử
dụng LDAP (Lightweight Directory Access Protocol) để lấy chứng thư về. LDAP
cho phép các ứng dụng chạy trên nhiều hệ điều hành để có thể lấy được thông tin
thư mục, như địa chỉ email và khóa công khai. CA có thể nằm trên một thư mục
LDAP với thông tin chi tiết của CA. CA có thể sử dụng các thông tin này trên thư
mục LDAP để cấp phát nhiều chứng thư số cho các người dùng cùng một lúc với
cùng một tiêu chí. Thư mục LDAP có thể tích hợp với Quản lý chứng thư số
(Certificate Manager) để tự động lấy thông tin chứng thư số từ quản lý chứng thư
số và cập nhật trong thư mục.

Chứng thư số cần phải được công bố dựa trên các triển khai PKI.

James và John cùng là nhân viên của công ty AllSolv Inc., tổ chức này có kế hoạch
triển khai PKI để liên lạc an toàn trên mạng intranet. Để thuận tiện cho việc tải
chứng thư số, các chủ sở hữu chứng thư số có thể truyền chứng thư số tới các
người dùng khác theo mỗi yêu cầu được thiết lập hoặc tất cả các chứng thư số
được công bố trên cơ sở dữ liệu thư mục nội bộ. Bất kỳ khi nào James muốn gửi
thông tin bảo mật tới John, James vào cơ sở dữ liệu thư mục nội bộ lấy chứng thư
số của John và mã hóa thông điệp đó bằng việc sử dụng khóa công khai trong
chứng thư số đó. Sau đó James gửi thông điệp được mã hóa đó tới John và John sẽ
sử dụng khóa riêng của mình để giải mã thông điệp này.

Nhờ vào sự mở rộng này, AllSolv có thể quyết định lấy chứng thư số của CA từ
một CA gốc để sinh và phân phối chứng thư số tới nhân viên của mình. Chứng thư
số này được phân phối tới các nhân viên để thực hiện các giao dịch tài chính với
các công ty khác hoặc các thực thể ở bên ngoài trên Internet. Trong trường hợp
này, nếu chứng thư số khóa công khai của nhân viên được lưu trữ trên cơ sở dữ
liệu thư mục nội bộ thì không thể đáp ứng được yêu cầu trên. Bởi vì các các người
dùng chứng thư số ở ngoài giới hạn của tổ chức và không thể lấy chứng thư số
được lưu trữ bên trong cơ sở dữ liệu nội bộ của công ty. Do vậy, chứng thư số khóa
công khai của nhân viên cần phải được công bố trên một cơ sở dữ liệu toàn cầu
trực tuyến tuân thủ chuẩn X500 để chứng thư số có thể có tính sẵn sàng cao trong
việc xác mình và xác thực tất cả các người dùng.

 Xác minh tính hợp lệ của chứng thư số

Sau khi tải chứng thư số về, ta cần phải kiểm tra tính hợp lệ của chứng thư số đó.
Việc xác minh tính hợp lệ của chứng thư số gồm các bước sau:

- Kiểm tra được rằng chứng thư số còn hiệu lực

- Xác minh được chứng thư số đó do một CA tin tưởng cấp phát

- Đảm bảo rằng chứng thư số đó được sử dụng vào đúng mục đích

- Kiểm tra, xác định được chứng thư số có bị thu hồi hay không
Một kịch bản sau đây mô tả quá trình xác minh tính hợp lệ của chứng thư số:
James cần xác minh tính hợp lệ chứng thư số của John. Bước đầu tiên, James thực
hiện các công việc

- Kiểm tra thời gian sống của chứng thư số để đảm bảo chắc chắn rằng chứng
thư số không bị hết hạn

- Kiểm tra thông tin chính sách trong chứng thư số để chắc chắn chứng thư số
được cấp phát cho John là không bị lạm dụng

Tiếp theo, James kiểm tra tính xác thực của chứng thư số:

- Kiểm tra danh sách CA tin cậy của James để tìm xem CA của John có trong
danh sách đó không. Nếu CA của John không có trong danh sách, James tiếp
tục tìm kiếm CA đó trong đường dẫn chứng thực trong CA phân cấp

- Sau khi tìm được CA tin cậy đó, James kiểm tra chữ ký số trong chứng thư
số của John. Để xác minh chữ ký số, James tạo ra một hàm băm cho thông
điệp đó. Sau đó, sử dụng khóa công khai để giải mã giá trị băm mà John gửi.
cuối cùng, James so sánh giá trị băm được giải mã với giá trị băm mà anh ta
tạo ra. James lấy chứng thư khóa công khai của CA cấp phát cho John, sử
dụng thuật toán băm trên thông điệp để tính toán giá trị băm và so sánh với
giá trị hăm vừa được giải mã. Nếu hai giá trị trùng nhau, thì chứng thư số
không bị sửa đổi và xác thực.

Sau khi James xác thực được chứng thư số của John, James sẽ lấy danh sách thu
hồi chứng thư CRL mới nhất để xác minh rằng chứng thư số này chưa bị thu hồi vì
bất kỳ lý do nào.

3.2.3. Công bố chứng thư số

Phương pháp phân phối phổ biến nhất các chứng chỉ và thông tin thu hồi
chứng chỉ trong khu vực doanh nghiệp là công bố công khai. ý tưởng là thông
tin PKI được gửi đến nơi ai cũng biết, sẵn sàng công cộng và dễ dàng truy
nhập. Công bố công khai đặc biệt thu hút vì những cộng đồng người dùng lớn
nói chung đều không biết nhau (nghĩa là thông tin PKI không được phân phối
trực tiếp đến mỗi cá nhân).
Ý tưởng công bố trong khuôn khổ mật mã khoá công khai đã được giới
thiệu trong bài báo của Diffie và Hellman. Đó là công trình đầu tiên về mật mã
khoá công khai, và nó yêu cầu một mô hình ở đó các khoá công khai được
công bố và phân phối ở dạng tương tự như cuốn danh bạ điện thoại.

LDAPv2 và LDAPv3

Mặc dù LDAPv2 là cơ sở chính của các triển khai PKI doanh nghiệp thời kỳ đầu,
song nó nói chung được xem là không đầy đủ do:

 Cơ chế xác thực buộc thi hành giữa một client và kho chứa được dựa trên id
người dùng và mật khẩu được truyền đi ở dạng rõ.

 Không có sơ đồ kiểm soát truy nhập chuẩn,

 Không có cơ chế chuẩn để nhân bản dữ liệu giữa các kho chứa dữ liệu theo
LDAP (thực tế, không hỗ trợ mọi liên lạc từ máy chủ đến máy chủ)

 Các bộ lọc tìm kiếm được xem là không đầy đủ

 Không có cơ chế thoả thuận về tính bí mật nào để bảo vệ dữ liệu được lưu
hay dữ liệu đang chuyển đi.

 Không có khả năng cho các hoạt động thoả thuận về dữ liệu đã ký

Các thiếu sót của LDAP v2 đã được công nhận và một số tính năng mới đã được
đưa ra trong LDAP v3. Các bản đặc tả lõi LDAP v3 chứa trong RFC 2251 - 2256
và 2829 - 2830. LDAP v3 có hỗ trợ các cơ chế xác thực mạnh hơn và có các chức
năng phụ thêm LDAP v3 được khuyến nghị nhiều hơn so với LDAP v2.

Chú ý rằng, LDAP vẫn tiếp tục phát triển. Các phát triển gần đây nhất xung quanh
LDAP v3 có thể tìm thấy trên:

html://www.ietf.org/html.charters/1dapbis-charter.html

html://www.ietf.org/html.charters/1dapext-charter.html
Bảng 3.1: LDAPv2 và LDAPv3

Trong các doanh nghiệp ngày nay, thực tế nhất là gửi (hay công bố) các
chứng chỉ, thông tin thu hồi chứng chỉ (đặc biệt là thông tin thu hồi chứng chỉ
dựa trên CRL) vào một kho chứa, Kho chứa là một thuật ngữ chung dùng để
chỉ một cơ sở dữ liệu tập trung cục bộ bất kỳ, có khả năng lưu trữ thông tin và
phổ biến thông tin đó khi có yêu cầu.
Trong phạm vi doanh nghiệp, các kho chứa điển hình là những máy chủ ở
xa, được truy nhập được đến qua giao thức Lightweight Directory Access
Protocol - LDAP, phiên bản 2 hoặc 3.
Ngay cả khi LDAP là cơ chế truy nhập đến kho chứa thì bản thân kho
chứa lại thường được dựa trên mô hình thông tin và các giao thức như định
nghĩa trong loạt các khuyến nghị X 500. Tuy nhiên, thuật ngữ kho chứa có thể
áp dụng cho cơ sở dữ liệu hoặc dạng lưu trữ và phân phối thông tin khác,
chẳng hạn như bộ đáp lại (responder) trạng thái thu hồi trực tuyến (xem thảo
luận liên quan đến giao thức trạng thái chứng chỉ trực tuyến trong phần trước).

Một số ví dụ thuộc phạm vi định nghĩa về kho chứa này gồm:

 Các máy chủ LDAP

 Đại lý hệ thống Thư mục X500 (Directory System Agent- DSA)

 Bộ phúc đáp OCSP (mặc dù OCSP như mô tả trong khuyến nghị RFC 2560
bị hạn chế chỉ tới thông tin trạng thái thu hồi)

 Hệ thống tên miền (DNS) (với các chứng chỉ và thông tin thu hồi chứng chỉ
được hỗ trợ phù hợp với RFC 2538)

 Các máy chủ web (có thể chứa các chứng chỉ và thông tin thu hồi chứng chỉ
phù hợp với RFC2585 và có thể lấy ra qua Giao thức vận chuyển Siêu văn
bản - Hypertext Transfer Protocol, hay HTTP)

 Các máy chủ dựa trên Giao thức chuyển tệp (FTP) (có thể chứa các chứng
chỉ và thông tin thu hồi chứng chỉ phù hợp với RFC2585)

 Các cơ sở dữ liệu kết hợp (có thể chứa các chứng chỉ và thông tin thu hồi
chứng chỉ và có khả năng truy cập và quản lý tốt)
Từ danh sách trên có thể thấy các hệ thống client có thể lấy thông tin từ
các kho chứa này qua một số giao thức truy cập khác nhau (mặc dù LDAP là
giao thức truy nhập kho chứa có ưu thế nhất trong vùng PKI doanh nghiệp).
Một cách lý tưởng, điều này sẽ cho phép các thực thể cuối lấy các chứng chỉ và
thông tin thu hồi chứng chỉ theo yêu cầu gần như không kiểm soát truy nhập.
Thực tế, đọc ẩn danh cũng thường được dùng để lấy các chứng chỉ và CRL
trong phạm vi vùng doanh nghiệp. Tuy nhiên, kiểm soát truy nhập cũng là vấn
đề quan tâm khi thực thể đến để gửi các chứng chỉ và các CRL vào kho chứa vì
truy nhập trái phép có thể dẫn đến rủi ro về an toàn; ví dụ, một CRL có thể bị
tráo đổi với một CRL khác, hoặc các chứng chỉ người dùng cuối có thể bị thay
thế bằng chứng chỉ người dùng khác.

3.2.4. Các phương pháp hủy bỏ chứng thư số

Thu hồi chứng thư số là quá trình loại bỏ tính hợp lệ của chứng thư số một cách
sớm nhất. Có nhiều lý do để thu hồi chứng thư số, ví dụ:

- Chủ sở hữu của chứng thư số đi ra khỏi tổ chức

- Người chủ sở hữu thay đổi tên hoặc thông tin

- Cơ quan cấp phát hoặc mối quan hệ giữa các cơ quan cấp phát và tổ chức
không còn tồn tại.

- Khóa bí mật bị nghi ngờ là bị tổn thương.

Thu hồi chứng thư số có thể được thực hiện bằng nhiều cách. Phương thức thu hồi
được tổ chức lựa chọn dựa trên chi phí, cơ sở hạ tầng và số lượng giao dịch được
thực hiện. một cơ chế được thực hiện là công bố định kỳ. Một phương pháp khác là
sử dụng cơ chế truy vấn trực tuyến.

- Cơ chế công bố định kỳ: Cơ chế này sử dụng danh sách thu hồi chứng thư số
(Certificate Revocation Lists – CRL) và cây thu hồi chứng thư số
(Certificate Revocation Tree – CRT)
o CRL: CRL là một danh sách bao gồm tất cả các chứng thư số được
thu hồi trước khi bị hết hạn. CRL được cơ quan phát hành hoặc CA
cấp phát, duy trì và cập nhật thường xuyên.
o CRT: kỹ thuật thu hồi này dự trên cấu trúc hàm băm Merkle, ở đó cấu
trúc hình cây thể hiện toàn bộ các thông tin thu hồi chứng thư số liên
quan đến các thiết lập PKI. Hạn chế lớn nhất của phương pháp này là
 CRT có thể được tính toán lại với các bản cập nhật. điều đó là tăng tải
trọng cho bộ vi xử lý và làm giảm tính tức thời của CRT
- Cơ chế truy vấn trực tuyến: Cơ chế truy vấn trực tuyến bao gồm Giao thức
trạng thái chứng thư số trực tuyến (Online Certificate Status Protocol –
OCSP) và Giao thức phê duyệt giao dịch trực tuyến (Online Transaction
Validation Protocol)
o OCSP: được dùng để lấy các thông tin thu hồi chứng thư số trực tuyến
o Online validation transaction protocol: được dùng cho việc phê duyệt
trực tuyến như giao dịch kinh doanh thông qua thẻ tín dụng

Ở đây ta nghiên cứu phương pháp CRL và OCSP cho việc thu hồi chứng thư số.

3.2.4.1 CRL

Một khi chứng thư số bị thu hồi thì các thông tin về việc thu hồi sẽ được công bố
trong CRL. Thông thường CA cấp phát chứng thư số sẽ cấp phát luôn CRL tương
ứng. Các CRL được ký số bởi CA để đảm bảo tính xác thực.

Để xác minh tính hợp lệ của chứng thư số phải thực hiện các bước sau:

- Kiểm tra trường ngày hợp lệ của chứng thư số

- Nếu chứng thư số không hết hạn, người dùng đề nghị CA tin cậy cấp phát
bản CRL mới nhất
- Nhận được CRL, người dùng xác minh tính hợp lệ của chữ ký số của CA
cấp phát trên CRL
- Cuối cùng, người dùng tìm kiếm trên CRL để kiểu tra liệu số serial của
chứng thư số có được hiển thị trên CRL hay không. Nếu số serial của chứng
thư số có mặt trên CRL, thì có nghĩa chứng thư số đó đã bị thu hồi.

Người dùng cần phải thực hiện các bước trên để kiểm tra tính hợp lệ của chứng thư
số. Tuy nhiên, có nhiều trường hợp không thể thực hiện được, ví dụ, người dùng
không kết nối được với Internet. Kết quả là, bản CRL mới nhất không thể sử dựng
vào việc xác minh tính hợp lệ của chứng thư số. để kiểm tra chứng thư số trong
trường hợp như vậy, người ta sử dụng các bộ đệm CRL. Các bộ đệm CRL được
lưu trữ trong máy tính người dùng. Điều này làm tăng tốc độ xác minh chứng thư
số vì người dùng không phải truy vấn tới CA để xin CRL vào mỗi thời điểm xác
minh chứng thư.
Trong bộ đệm CRL có thể chỉ lưu lại các thông tin cũ, vì thế người dùng cần phải
cập nhật bộ đệm CRL thường xuyên thông qua việc tải các bản sao mới nhất của
CRL.

CRL bao gồm các thông tin thu hồi của chứng thư số CA được gọi là danh sách thu
hồi thẩm quyền (Authority Revocation List – ARL). Các ARL chỉ bao gồm thông
tin thu hồi chứng thư số CA chứ không có thông tin của chứng thư số người dùng.

Sự phát triển của CRL

CRL tồn tại với các đặc điểm kỹ thuật của X.509, xác định thông tin là một phần
của chứng thư số và định dạng các thông tin đó yêu cầu trong chứng thư số. đặc tả
X509 sẽ quyết định sự phát triển cho các phiên bản của CRL.

Phiên bản 1 CRL được biết đến là CRL v1, là một chuẩn xác định cấu trúc dữ liệu
cơ bản của một CRL. CRL v1 cũng xác định các thông tin cần thiết được lưu trữ
trong CRL và các thông tin của chứng thư số phải được thu hồi. bên cạnh chữ ký
số, CRL này còn bao gồm các thông tin sau:

- Số serial: trường này bao gồm số serial của chứng thư số được cấp phát bởi
cơ quan thẩm quyền.
- Định danh thuật toán ký: trường này gồm thuật toán được CA sử dụng để
cấp phát chứng thư số.
- Tên cơ quan cấp phát: trường này bao gồm tên của cơ quan thẩm quyền cấp
phát, thông thường là CA
- Thời gian hiệu lực: trường này bao gồm thời gian bắt đầu và thời gian kết
thúc mà chứng thư số có hiệu lực
- Tên chủ thể: trường này bao gồm tên của thực thể sở hữu khóa công khai
được định danh trong chứng thư số.
- Thông tin khóa công khai của chủ thể: trường này bao gồm khóa công khai
của chủ thể phát hành chứng thư số. khóa công khai này cùng với thuật toán
được xác định trên trường định danh thuật toán ký sẽ xác định bộ mã hóa
của khóa công khai.

Khi được phát triển và sử dụng lần đầu tiên, CRL v1 đã trải qua một số lần thay
đổi do:
 - Độ an toàn: thông tin trong CRL v1 được thay thế không cần sự am hiểu
của CA hoặc người dùng. Do đó, các thông tin không chính xác về CRL có
thể được truyền tới người dùng
- Kích thước: CRL v1 không có cơ chế để kiểm soát hay giới hạn kích thước
của nó
- Tính mềm dẻo: CRL v1 không cho phép các trường mở rộng liên kết với
CRL thêm bất kỳ một thông tin bổ sung nào

Tất cả các vấn đề trên được giải quyết ở CRL phiên bản 2 (CRL v2). CRL v2 giới
thiệu khái niệm trường mở rộng, tương tự như các trường mở rộng của chứng thư
số khóa công khai X.509 v3. Các trường mở rộng này dựa trên chứng thư số và
một số dựa vào chính CRL.

CRL v2: thay đổi lớn nhất trong CRL v2 là các trường mở rộng giúp cho CRL linh
hoạt và khả năng mở rộng hơn phiên bản 1. Trường mở rộng cho phép thêm các
thuộc tính được gắn kết với người dùng hoặc khóa công khai, như thuộc tính để
quản lý phân cấp chứng thư và phân bố CRL. Hình 3-3 mô tả CRL phiên bản 2

Hình 3-3: Định dạng CRL phiên bản 2

Các trường được mô tả như sau:

 - Version: trường này thể hiện phiên bản của CRL. Giá trị của trường này nếu
biểu diễn là 2 thì là phiên bản CRL 2.
- Chữ ký: trường này bao gồm định danh thuật toán được CA cấp phát ký số
lên mỗi CRL
- Người phát hành (isusser): trường này chứa tên phân biệt X.500
(Distinguished name – DN) của CA cấp phát CRL
- This update (cập nhật lần này): trường này bao gồm ngày mà CRL được
phát hành
- Next update (cập nhật lần sau): chứa thông tin ngày mà CRL tiếp theo sẽ
được phát hành hoặc CRL đó bị hết hạn.
- Danh sách chứng thư số bị thu hồi (List of Revoked certificate) bao gồm các
chứng thư số bị thù hồi, các thông tin liên kết với các chứng thư số đó gồm:
số serial, ngày thu hồi, các trường mở rộng dựa trên chứng thư số (certificate
based extensions) như hình 3-4.

Hình 3-4: Thông tin chứng thư số bị thu hồi

- Trường mở rộng CRL: trường này được giới thiệu trong CRL v2 và bao gồm
các thông tin bổ sung như lý do thu hồi chứng thư số, tên cơ quan cấp phát
chứng thư, mã đình chỉ chứng thư số và ngày hết hiệu lực liên quan đến
CRL và chứng thư số.

Trường mở rộng CRL

Trường mở rộng CRL được định nghĩa trong X509 v3 và CRL v2, cung cấp cơ chế
thêm vào các thuộc tính bổ sung cho người dùng và khóa công khai. Trường mở
rộng CRL cũng được định nghĩa để thuận tiện thêm vào các thông tin bổ sung để
gần với CRL, do đó sẽ giúp mở rộng CRL. Một số trường mở rộng hay được sử
dụng: định danh thẩm quyền khóa (AuthorityKeyIdentifier), sử dụng khóa
(KeyUsage) và tên khác (AlternativeNames).

Dựa trên chính sách của CA, trường mở rộng được xác định là cần thiết hay không
cần thiết. trường mở rộng cần thiết là trường được xử lý bởi một ứng dụng liên
quan đến quá trình xác minh CRL. Ngược lại, trường mở rộng không cần thiết
không phải trải qua quá trình đó.

Tổ chức có thể xác định các trường mở rộng riêng cho họ để sử dụng tên miền đặc
trưng. Các trường này thể hiện đặc trưng riêng của tổ chức, dựa vào chức năng,
hoạt động của họ, thì các trường mở rộng được phân thành:

- Các trường mở rộng dựa vào chứng thư số

- Các trường mở rộng dựa trên CRL
 Các trường mở rộng dựa vào chứng thư số

Trường mở rộng dựa vào chứng thư số hỗ trợ việc xác định các chứng thư số bị thu
hồi nhanh chóng. Trường này bao gồm thông tin định danh của chứng thư số như:
số serial của chứng thư, tên CA, tên thực thể và các thông tin sau:

- Mã lý do (Reason Code): là một trường mở rộng không thiết yếu, nó xác

định nguyên nhân chứng thư số bị thu hồi, bao gồm các giá trị
o Khóa tổn thương
o Thay đổi liên kết
o Bị rút quyền
o CA bị tổn thương
o Tổ chức ngừng hoạt động
o Chứng thư bị thu giữ
o Không xác định
o Bị loại bỏ khỏi CRL
- Ngày không hợp lệ: là thời gian mà chứng thư số bị vô hiệu hóa
- Cơ quan phát hành chứng thư số: trường này tạo thuận lợi cho CRL, gồm
thông tin thu hồi chứng thư số được phát hành bởi các CA khác nhau.
Trường này cũng xác định CA đã phát hành chứng thu số bị thu hồi.
- Mã cấu trúc lưu trữ: ngoài danh sách chứng thư số bị thu hồi, CRL còn chưa
danh sách của các chứng thư số bị đình chỉ hoạt động (chứng thư số treo).
 Các chứng thư số treo này chưa bị thu hồi, nhưng không được sử dụng trừ
khi chúng được kích hoạt trở lại. các lý đo dẫn đến việc đình chỉ hoạt động
tạm thời các chứng thư số này dựa vào chính sách của CA. Trường này bao
gồm định danh đối tượng hay còn gọi là OID. Dựa vào giá trị của OID, các
ứng dụng hoặc người dùng cân nhắc có nên sử dụng chứng thư số treo hay
không.
o Giao tác với CA để cho phép chứng thư số này hoạt động lại
o Loại bỏ chứng thư số này

Trường này hỗ trợ các mã cấu trúc sau:

- id−holdinstruction−callissuer: mã này yêu cầu các ứng dụng phải chỉ đến cơ
quan phát hành chứng thư số, nếu không thì chứng thư số sẽ bị loại bỏ.
- id−holdinstruction−reject: mã này yêu cầu loại bỏ chứng thư số
- id−holdinstruction−none: nếu gặp phải mã này, thì loại bỏ chứng thư số

Nhìn chung, các ứng dụng đều không được cấu hình để phát huy được các ưu thế
của trường này bởi vì việc chỉ đến một CA đôi khi không thể thực hiện được, do
vậy, trường này thường ít được sử dụng

 Trường mở rộng dựa trên CRL

Các trường này giúp CRL mềm dẻo và linh hoạt hơn. Việc sử dụng các trường này
giúp CA có thể kiểm soát được kích thước của CRL. Một số trường mở rộng dựa
trên CRL cụ thể như sau:

- Định danh thẩm quyền khóa (Authority Key Identifier): CA ký số lên mỗi
CRL, và CRL được xác nhận bằng chứng thư số khóa công khai của CA cấp
phát. CA có thể sử dụng nhiều hơn một khóa để ký số. ví dụ, CA có thể sử
dụng một khóa để ký lên CRL và một khóa khác để ký lên chứng thư số.
Trường mở rộng này xác định các khó được sử dụng để ký lên CRL. Các
trường trong Định danh thẩm quyền khóa gồm:
o Định danh khóa (keyIdentifier): là một trường tùy chọn, bao gồm
trường mở rộng định danh khóa từ chứng thư số của cơ quan phát
hành CRL
o Cơ quan thẩm quyền phát hành chứng thư số (AuthorityCerIssuer):
đây cũng là một tùy chọn bao gồm tên của cơ quan thẩm quyền phát
 hành, có thể có một hoặc nhiều tên. Nếu trường này được sử dụng thì
giá trị của số serial của cơ quan phát hành chứng thư
số(authorityCerSerialNumber) phải được xác định
o authorityCertSerialNumber: cũng là một tùy chọn bao gồm số serial
chứng thư số của cơ quan thẩm quyền cấp phát CRL
- Tên khác của cơ quan phát hành (Issuer alternate name): là trường mở rộng
được dùng để hỗ trợ các thông tin bổ sung giúp xác định được CA ngoại trừ
tên phân biệt của CA. trường này có thể gồm các tên gắn liền với người
dùng như địa chỉ thư điện tử hay tên máy chủ,…
- Điểm phân phối phát hành (Issuing distribution point): đây là một trường mở
rộng thiết yếu để xác định được vị trí của CRL và loại chứng thư số chứa
trong CRL. Nếu trường mở rộng này không được nhìn thấy trong quá trình
xác minh tính hợp lệ của chứng thư số thì CRL bị loại bỏ. trường này cho
biết liệu CRL có chứa danh sách chứng thư số của người dùng bị thu hồi,
chứng thư số của CA hay mã lý do thu hồi hay không. Một thẩm quyền cấp
phát CRL có thể có nhiều điểm phân phối. trong các trường hợp như vậy, thì
các điểm phân phối được hỗ trợ bởi một thẩm quyền cấp phát CRL cùng tên
với cùng khóa ký.
- Số CRL: đây là trường không thiết yếu, bao gồm một số duy nhất để xác
định CRL. Trường này cũng thể hiện chuỗi CRL được cấp phát bởi cơ quan
thẩm quyền phát hành
- Báo hiệu Delta CRL (Delta CRL Indicator): trường nay luôn chứa số CRL
cơ sở cho việc cập nhật được phân bổ. để kiểm soát được kích thước của
CRL hoặc làm đơn giản quá trình phân phối, các CRL được phân phối từng
phần. Ở giai đoạn đầu tiên thì một CRL đầy đủ sẽ được phân phối, CRL này
được gọi là CRL cơ sở. tuy nhiên đối với lần tiếp theo, chỉ có bản cập nhật
được phấn phối thay vì phân phối một CRL đầy đủ. Các bản cập nhật hoặc
các phần CRL được gọi là Delta CRL. Khi Delta CRL chỉ chứa các bản cập
nhật từ CRL cơ sở thì họ sẽ duy trì được kích thước CRL phân phối ở mức
nhỏ và giảm thiểu lưu lượng đường truyền và quá trình tải. Đây là một
trường mở rộng thiết yếu của CRL
- CRL gián tiếp (Indirect CRL): thông thường CA cấp phát chứng thư số sẽ
cấp phát luôn CRL. Tuy nhiên, một số trường hợp lại không xảy ra như vậy.
Phương pháp CRL gián tiếp được đề xuất để hợp nhất các CRL. Ví dụ, một
nhóm CA giao cho một cơ quan thẩm quyền nhiệm vụ cấp phát CRL tương
 ứng. Cơ quan thẩm quyền tin cậy này sẽ có các thông tin thu hồi từ nhiều
CA và sẽ chia sẻ cho các CA khác. Một CRL gián tiếp cũng làm đơn giản
hóa quá trình xác nhận được thực hiện bởi người dùng là những người
không có nhu cầu lấy nhiều CRL từ nhiều cơ quan cấp phát. Cơ quan được
nhóm CA giao nhiệm vụ phát hành CRL được gọi là cơ quan thẩm quyền
CRL gián tiếp (Indirect CRL Authority – ICRLA)

Phân phối CRL

Như ta đã biết, yếu tố quan trọng trong việc quản lý CRL là quá trình phân phối
CRL. Để quá trình phân phối CRL được đơn giản và truy cập CRL dễ dàng thì CA
cần xác định nhiều điểm phân phối CRL. Ví dụ, một điểm phân phối có thể cho
CRL của người dùng, còn 1 điểm khác thì cho CRL của CA. điều này sẽ giảm tải
kích thước của CRL cũng như giảm bớt tắc nghẽn mạng, đồng thời cũng giúp giảm
thời gian người dùng yêu cầu xử lý các CRL

CA có thể phân phối CRL trên cơ sở của việc thay đổi yêu cầu kinh doanh. Một tổ
chức CA có thể chia nhỏ CRL dựa trên cơ sở các phòng ban khác nhau và phát
hành CRL tới các người dùng ở các phòng ban tương ứng. Ví dụ, James là thành
viên ở phòng nghiên cứu, cần xem chứng thư số của Charlie ở phòng Kinh doanh.
Thay vì xem các CRL của tổ chức, James xác nhận chứng thư số của Charlie trực
tiếp từ CRL của phòng kinh doanh.

Việc phân vùng CRL có những giới hạn nhất định. Khi chứng thư số được cấp phát
cho người dùng thì ngay sau đó điểm phân phối CRL cho người dùng sẽ được
quyết định. Vì vậy, việc phân vùng nhỏ không phải là giải pháp linh hoạt, bởi vì
các điểm phân phối có thể thay đổi nếu kích thước của CRL tăng. Do đó, khi quyết
định các điểm phân phối, tính linh hoạt được yêu cầu và được cung cấp bởi các
CRL chuyển hướng.

CRL chuyển hướng

CRL chuyển hướng là các CRL trỏ đến nhiều điểm phân phối CRL khi CRL được
xác định vị trí. Khi tổ chức sử dụng CRL chuyển hướng, thông tin CRL có thể bị
thay đổi mà không làm ảnh hưởng đến trạng thái của chứng thư số. Cách tiếp cận
này tương đối linh hoạt so với việc cố định các điểm phân phối mà không thể thay
đổi được vị trí của CRL.
Ví dụ sau giải thích cho quá trình chuyển hướng CRL. James là người dùng của
công ty A, được CA cấp phát chứng thư số. Để xác thực chứng thư số này, một
người dùng khác của công ty là Charlie cần tìm kiếm trong trường mở rộng điểm
phân phối CRL trỏ đến một CRL chuyển hướng. Charlie lấy thông tin của CRL
chuyển hướng và có thể lấy được thông tin của CRL liên quan.

Hình 3-5:Xác minh bằng CRL chuyển hướng

3.2.4.2 Giao thức trạng thái chứng thư số trực tuyến

(Online Certificate Status Protocol – OCSP)

Các CRL chuyển hướng làm việc hiệu quả ngay cả khi chứng thư số được xác thực
ở chế độ offlien hoặc sử dụng bộ đệm CRL. Nhưng điều này có sinh ra một số các
rủi ro khi CRL được cập nhật. Do đó, một phương pháp khác được xác định để
kiểm tra tinh trạng chứng thư số trực tuyến, được gọi là OCSP – Online Certificate
Status Protocol.
Một máy phản hồi OCSP được dùng để xử lý các thông tin liên quan đến tất cả các
yêu cầu xác minh OCSP. Máy phản hồi OCSP là một thực hể tin cậy trong việc
nhận các yêu cầu về thông tin hủy bỏ, trả lời các yêu cầu đó với các thông tin tình
trạng chứng thư số trực tuyến.

Quá trình này thu thập thông tin thu hồi trực tuyến thông qua trình tự các bước
được miêu tả ở hình sau:

Hình 3-6: OCSP

1. người dùng gửi một yêu cầu OCSP tới máy phản hồi OCSP. Yêu cầu này bao
gồm các thông tin như: tên của CA, số serial của chứng thư số, số phiên bản giao
thức

2. Khi nhận được yêu cầu, máy phản hồi OCSP xử lý các yêu cầu và trả lời các
thông tin trạng thái của chứng thư số. các thông tin trạng thái này cũng có thời gian
hợp lệ cảu thông tin và định danh chứng thư số. trạng thái của chứng thư số có thể
có 3 giá trị: tốt, bị thu hồi hoặc không xác định. Các giá trị được miêu tả cụ thể như
sau:

- Chứng thư số tình trạng tốt: chứng thư số vẫn còn hợp lệ và không bị thu hồi

- Chứng thư số bị thu hồi: trạng thái này miêu tả chứng thư số đã bị thu hồi
- Chứng thư số không xác định tình trạng: miêu tả thông tin liên quan đến tình
trạng của chứng thư số không thể gọi tới được.

3. Dựa vào thông tin trạng thái chứng thư số, người dùng có thể thực hiện các hành
động thích hợp.

Máy phản hồi OCSP ký số lên các phản hồi trước khi gửi tới người dùng để đảm
bảo các phản hồi này được xác thực. phương pháp OCSP khá phổ biến nhưng nó
không cung cấp một phương thức xác thực rõ ràng. Một số các hạn chế trong
OCSP như sau:

- Mặc dù là một giao thức trực tuyến, nhưng không thể đảm bảo chắc chắn
rằng việc thu hồi chứng thư số không bị chậm trễ trong khi sử dụng OCSP
- OCSP không xác định cách thức thông tin được gọi ra từ kho lưu trữ CRL
tới máy phản hồi CRL cuối.
- Phản hối của máy phản hồi được ký số, vì thế có thể làm giảm hiệu xuất hoạt
động.

Bỏ qua các hạn chế này, OCSP cho phép tổ chức có thể xác minh tính hợp lệ của
chứng thư số một cách hiệu quả với chi phí hợp lý. Bên cạnh đó, bằng việc sử dụng
OCSP, tổ chức có thể nâng cao tính bảo mật cho giao dịch thương mại. OCSP cho
phép tổ chức liên kết nhiều máy phản hồi lại với nhau để thực hiện các giao dịch
thương mại. Bằng cách này, nếu một máy phản hồi không có thông tin được yêu
cần, thì có thể liên kết được với các máy khác để lấy các thông tin cần thiết. Một
mạng lưới các máy phản hồi như vậy cho phép linh hoạt hơn trong việc xác minh
tính hợp lệ của chứng thư số ở nước ngoài và giúp tạo thuận lợi cho việc kinh
doanh trên Internet.

3.2.4.3 Các cơ chế thu hồi chứng thu số khác

Mặc dù CRL và OCSP là 2 cơ chế phổ biến nhưng vẫn có các cơ chế khác được sử
dụng để phục vụ cho việc thu hồi chứng thư số, cụ thể như sau:

- OCSP-X hay còn gọi là OCSP mở rộng, cung cấp các thông tin bổ sung so
với OCSP. Với việc mở rộng này các thực thể có thể giao nhiệm vụ quyết
định liệu rằng chứng thư số đó có thể tin cậy hay không
- Máy chủ chứng thư số dữ liệu (Data Certification Server ) gọi là bên thứ ba
tin cậy dùng để xác minh tính chính xác của dữ liệu được gửi đến. Phương
 pháp được dùng để xác minh chữ ký số và trạng thái thu hồi của chứng thư
số.
- Thư mục trạng thái thu hồi chứng thư số (Certificate Revocation Status
Directory) là một kho lưu trữ các chứng thư số xác thực và được cấp phát
mà không bị hết hạn. với các chứng thư số không bị hết hạn, thì thư mục này
sẽ chứa các thông tin chi tiết về nội dung chứng thư số.

3.3. BÀI THỰC HÀNH SỐ 1

Xây dựng mô hình CA 2 cấp: 01 RootCA và 02 SubCA (SubCA1 sinh

chứng thư số ký, SubCA2 sinh chứng thư số mã, mỗi SubCA có một bộ phận
đăng ký RA, Kho chứng thư số (LDAP, AD,..)

Sinh viên có thể xây dựng hệ thống CA phân cấp sử dụng Microsoft CA hệ
điều hành Windows Server hoặc phần mềm EJBCA trên HĐH Ubuntu để có 01
RootCA và 02 SubCA, trong đó có 01 SubCA sinh chứng thư số ký, 01 SubCA
sinh chứng thư số mã, mỗi SubCA này có một bộ phần đăng ký RA, kho chứng thư
số (LDAP, AD,…).
 Chương 4. MỘT SỐ GIAO THỨC QUẢN LÝ PKI VÀ CÁC
CHUẨN LIÊN QUAN
4.1. CÁC GIAO THỨC QUẢN LÝ PKI

4.1.1. Các chuẩn PKCS

Giới thiệu một số loại đặc tả PKCS được đưa ra bởi RSA Laboratories nhằm mục
đích tăng tốc độ phát triển của mật mã khóa công khai.

4.1.1.1 PKCS#1

PKCS#1: RSA Encryption Standard là chuẩn về cài đặt mật mã khóa công khai
dựa trên giải thuật RSA. PKCS#1 được đưa vào RFC 3447. Nội dung của PKCS#1
bao gồm:

- Yếu tố gốc mật mã

- Sơ đồ mã hóa

- Sơ đồ chữ ký có phụ lục

- Cú pháp ASN.1 để trình bày các khóa và để xác định các sơ đồ trên
A. Các yếu tố gốc chuyển đổi dữ liệu
Có hai yếu tố gốc chuyển đổi dữ liệu được sử dụng trong các sơ đồ được xác
định trong tài liệu này:
I2OSP – Số nguyên – sang - Bát phân-Yếu tố gốc chuỗi: I2OSP chuyển đổi một
số nguyên không âm sang một chuỗi bát phân của một đoạn cụ thể
 OS2IP – Bát phân-Chuỗi-sang-Yếu tố gốc số nguyên: chuyển đổi một chuỗi
bát phân thành một số nguyên không âm
B Các yếu tố gốc mật mã
Các yếu tố gốc mật mã là các thao tác cơ bản mà các sơ đồ mật mã có thể được
xây dựng dựa trên đó. Mục đích của chúng là để thực hiện trong phần cứng hoặc
làm các module phần mềm, và không nhằm mục đích đem lại sự an toàn ngoài
một sơ đồ.
Có bốn loại yếu tố gốc được trình bày trong tài liệu này và được sắp xếp thành
cặp: mã hóa và giải mã, chữ ký và xác thực chữ ký.
B.1 Các yếu tố gốc mã hóa và giải mã
Yếu tố gốc mã hóa tạo ra một biểu diễn thông điệp từ một biểu diễn thông điệp
dưới sự kiểm soát của một khóa chung, và góc giải mã giúp khôi phục lại biểu
diễn thông điệp từ biểu diễn thông điệp dưới sự kiểm soát của khóa riêng tương
ứng.
Một cặp yếu tố gốc mã hóa và giải mã được sử dụng trong các sơ đồ mã hóa được
xác định trong tài liệu này và được nêu cụ thể ở đây: RSAEP/RSADP. RSAEP và
RSADP liên quan đến cùng một thao tác, với các khóa riêng là đầu vào.
Thao tác chính trong mỗi yếu tố gốc chính là phép mũ.
B.2 Các yếu tố gốc chữ ký và xác thực chữ ký
Yếu tố gốc chữ ký tạo ra một biểu diễn chữ ký từ một biểu diễn thông điệp dưới
sự kiểm soát của một khóa riêng, và yếu tố gốc xác thực khôi phục biểu diễn
thông điệp từ biểu diễn chữ ký dưới sự kiểm soát của khóa chung tương ứng.
Một cặp chữ ký và yếu tố gốc xác thực được sử dụng trong các sơ đồ chữ ký
trong tài liệu này và được nêu cụ thể ở đây: RSASP1/RSAVP1.
C Các sơ đồ mã hóa
Trong tài liệu này, sơ đồ mã hóa bao gồm thao tác mã hóa và thao tác giải mã,
trong đó thao tác mã hóa tạo ra một thông điệp từ một thông điệp có khóa chung
RSA của người nhận, và thao tác giải mã khôi phục thông điệp từ thông điệp với
khóa riêng RSA tương ứng của người nhận.
Co hai sơ đồ mã hóa được trình bày trong tài liệu này: RSAES-OAEP và
RSAES- PKCS1-v1_5. RSAES-OAEP được đề xuất cho các ứng dụng mới;
RSAES-PKCS1- v1_5 chỉ được đưa vào để đảm bảo tương thích với các ứng
dụng hiện có, và không được đề xuất cho các ứng dụng mới.
D Sơ đồ chữ ký có phụ lục
Trong tài liệu này, sơ đồ chữ ký có phụ lục bao gồm một thao tác tạo chữ ký và
một thao tác xác nhận chữ ký, trong đó thao tác tạo chữ ký từ thông điệp có khóa
riêng RSA của người ký, và thao tác xác nhận chữ ký sẽ xác nhận chữ ký trên
thông điệp với khóa chung RSA tương ứng của người ký. Để xác nhận chữ ký
được xây dựng trong loại sơ đồ này, cần phải có thông điệp đã. Bằng cách này,
các sơ đồ chữ ký có phụ lục được phân biệt với các sơ đồ chữ ký có khôi phục
thông điệp, vốn không được hỗ trợ trong tài liệu này.
Có hai sơ đồ chữ ký có phụ lục được nêu trong tài liệu này: RSASSA-PSS và
RSASSA-PKCS1-v1_5. Mặc dù không có sự tấn công nào đối với RSASSA-
PKCS1-v1_5 được biết đến, vì lợi ích của sự mạnh mẽ ngày càng lớn, RSASSA-
PSS được đề xuất cho áp dụng sau cùng trong những ứng dụng mới. RSASSA-
PKCS1-v1_5 được đưa vào để đảm bảo tính tương thích với các ứng dụng hiện
có, và trong khi vẫn phù hợp với các ứng dụng mới, người ta vẫn khuyến khích
chuyển dần sang RSASSA-PSS.
D.1 RSASSA-PSS
RSASSA-PSS kết hợp các yếu tố gốc RSASP1 và RSAVP1 với phương pháp
mã hóa EMSA-PSS. Nó tương thích với sơ đồ IFSSA được sửa đổi trong IEEE
P1363a dự thảo, trong đó các yếu tố gốc chữ ký và xác nhận là IFSP-RSA1 và
IFVP-RSA1 được xác định trong IEEE Std 1363-2000 và phương pháp mã hóa
thông điệp là EMSA4. EMSA4 phổ biến hơn một chút so với EMSA-PSS vì nó
hoạt động trên các chuỗi bit chứ không phải là các chuỗi bát phân. EMSA-PSS
tương đương với EMSA4 bị hạn chế tới trường hợp mà các toán hạng cũng như
các giá trị hash và muối là các chuỗi bát phân.
Độ dài của các thông điệp mà RSASSA-PSS có thể vận hành trên đó không bị
hạn chế hoặc bị ngăn cản bởi một lượng rất lớn, phụ thuộc vào hàm băm ẩn trong
phương pháp mã hóa EMSA-PSS.
D.2 RSASSA-PKCS1-v1_5
RSASSA-PKCS1-v1_5 kết hợp các gốc RSASP1 và RSAVP1 với phương pháp
mã hóa EMSA- PKCS1-v1_5.
Chiều dài của các thông điệp mà RSASSA-PKCS1-v1_5 có thể thao tác là không
hạn chế hoặc bị hạn chế bởi một lượng rất lớn, tùy thuộc vào hàm băm ngàm
trong phương pháp EMSA-PKCS1-v1_5.
E Các phương pháp mã hóa cho chữ ký có phụ lục
Phương pháp mã hóa bao gồm các thao tác xác định gianh giới giữa các thông
điệp chuỗi bát phân và các thông điệp được mã hóa chuỗi bát phân, vốn được
chuyển đổi sang và từ đại diện thông điệp số nguyên trong các sơ đồ. Các biểu
diễn thông điệp thông điệp được xử lý thông qua các gốc. Các phương pháp mã
hóa do đó sẽ giúp kết nối giữa các sơ đồ, vốn xử lý thông điệp và các gốc.
Có hai phương pháp mã hóa cho các chữ ký có phụ lục được sử dụng trong các sơ
đồ chữ ký và được nêu tại đây: EMSA-PSS và EMSA-PKCS1-v1_5.

4.1.1.2 PKCS#7

PKCS#7 là chuẩn ký tự thông báo mật mã định nghĩa các ký tự cho dữ liệu mật mã
như chữ ký số. PKCS#7 cho phép xác thực thuộc tính thông tin trong việc bổ sung
đến việc xác thực nội dung thông báo.
Một vài tính quan trọng khi sử dụng PKCS#7:
-         CA sử dụng PKCS#7 như một phản hồi đến thực thể yêu cầu chứng thư.
-         Nó sử dụng để xác thực thông báo chứng thực đã gửi đến một thực thể.
-         Nó cung cấp thông tin hoàn thiện đến CA cho việc xử lý các yêu cầu chứng
thư.
-         Nó được sử dụng bởi nhiều giao thức S/MME cho việc cung cấp sự bảo mật.
Mỗi mẫu thông báo theo chuẩn PKCS#7 bao gồm: kiểu nội dung và nội dung:
 Kiểu nội dung
           Miêu tả các đặc điểm kỹ thuật cho mẫu nội dung và được tham chiếu đến
như là định danh đối tượng. Sáu kiểu nội dung được định nghĩa bởi PKCS#7 là:
- Data
- Signed data.
- Enveloped data
- Signed and enveloped data
 - Digested data
- Encrypted data
Kiểu nội dung có thể phân thành 2 lớp: base , enhenced
-         Base: nội dung được soạn thảo về dữ liệu không có  tính chất mật mã. Kiểu
nội dung data được chứa trong lớp này.
-         Enhenced: tất cả các kiểu nội dung còn lại được chứa trong lớp này
 Mã hóa một giá trị ContentInfo
           Để tạo ra một thông báo chữ ký cho Bob trước tiên cần mã hóa một giá trị
ContentInfo như mỗi PKCS#7. Giá trị này chứa đựng thông báo của Bob trong một
mẫy của một OCTET STRING.
           Giả sử Bob muốn mã hóa một thông báo gửi đến Alice là người quản trị hệ
thống mới. Kiểu nội dung thông báo của Bob là một dữ liệu PKCS#7 và một giá trị
định danh đối tượng về:
{3 2 520 126731 3 6 2}
Khi Bob mã hóa giá trị ContentInfo, nó  có thể thực hiện như sau
20 36
            03 06 contentType = data
            1b 76 84 78 d6 0c 03 06 02
            b0 2a [0] EXPLICIT
            03    21  content    =  OCTET      STRING      value:   "Alice   is  the  new   
system  administrator"
            34 84 45 65 80 3d 3s 70 30 32 31 12 24 45 53 30
            41 52 26 89 30 5d 77 88 2f
Sau khi mã hóa nội dung tiếp theo là băm nhỏ dữ liệu
 Băm dữ liệu
            Bob có thể sử dụng bất kỳ thuật toán phân biệt như MD2 để băm nội dung
thông báo cho mỗi PKCS#7. Kết quả là một thông báo băm. Nó có thể được thấy
trong bước trước là nội dung của thông báo gốc trong giá trị ContentInfo được thể
hiện như sau
34 84 45 65 80 3d 3s 70 30 32 31 12 24 45 53 30 41 52 26 89 30
Khi  Bob băm giá trị này với MD2, nó sinh ra kết quả băm như sau
2c 23 ac 11 7e 3a 63 dc 67 48 c2 2b cd ea dc b2
Sau đó Bob sử dụng thông báo băm này để mã hóa một giá trị DigestInfo
 Mã hóa một giá trị DigetsInfo
            Thông báo băm nhận được từ giá trị ContentInfo được sử dụng để  mã hóa
DigestInfo.Giá trị DigestInfo đã mã hóa này và giá trị ContentInfo đầu tiên sau đó
được sử dụng để sinh ra một giá trị SignedData
 Mã hóa một giá trị SignedData
            Sau việc mã hóa giá trị DigestInfo,  Bob cần mã hóa giá trị SignedData
bằng việc sử dụng giá trị DigestInfo đã mã hóa, giá trị ContentInfo đầu tiên, và
nhiều thông tin khác như là chứng thư của anh ta, người phát hành chứng thư và số
seral của chứng thư, và định danh thuật toán thông báo băm.
            Sau khi Bob đa mã hóa giá trị SignedInfo, Bob mã hóa giá trị SifgnedInfo
khác cho mỗi PKCS#7 từ giá trị SignedInfo đã mã. Giả sử rằng giá trị định danh
nội dung đối tượng cho nội dung này là:
{3 2 520 126731 3 6 3}
Kết quả giá trị ContentInfo đã mã hóa có thể được trình bày như sau:
30 82 02 50
03 06 1b 76 84 78 d6 0c 03 06 02 contentType = signedData b1 72 03 54 [0]
EXPLICIT
20 46 01 4c ......... 46 24 d2 a2 content = SignedData value
 Hạn chế của PKCS#7
Tương tự như PKCS#10, PKCS#7 không định nghĩa bất kỳ ký tự cho thông báo
thu hồi chứng thư. Tuy nhiên, việc kết nối PKCS#10 và PKCS#7 tạo ra sự hình
thành về một kiểu giao dịch hoàn tất và an toàn. Cả hai giao thức đó có thể thực thi
dễ dàng kể từ khi các mẫu của chúng được hỗ trợ bởi nhiều hệ thống. PKCS#7 thì
mở rộng một cách cao hơn. Bất kỳ thông tin có thể được ghép vào mẫu này bằng
việc sử dụng các thuộc tính xác thực và thuộc tính không xác thực.
 4.1.1.3 PKCS#10

PKCS#10 là một chuẩn ký tự yêu cầu chứng thư, định nghĩa ký tự cho các yêu cầu
chứng thư. Tùy thuộc vào chuẩn PKCS#10, một yêu cầu chứng thư bao gồm:

- Thông tin yêu cầu chứng thư

- Một ID thuật toán chữ ký

- Một chữ ký số trên thông tin yêu cầu chứng thư

Thông in yêu cầu chứng thư được soạn trong trường Tên phân biệt (Distingished
Name) của thực thể, khóa công khai của thực thể, và một vài thuộc tính tùy chọn
khác. Các thuộc tính chứa đựng thông tin bổ sung về các thực thể, như là địa chỉ
bưu chính mà nó ký lên chứng thư nên được phản hồi lại nếu như thư điện tử
không có sẵn. Những thuộc tính cũng chứa đựng một password yêu cầu thách đố
mà thực thể có thể sử dụng khi đang yêu cầu thu hồi chứng thư tại một giai đoạn
nào đó.

Mẫu yêu cầu chứng thư theo chuẩn PKCS#10

Distingished Name

Public Keys

Optional Attributes

Algorithm Identifier

Digital Signature

Giả sử Bob yêu cầu cơ quan chứng thực CA X nào đó theo chuẩn PKCS#10. Bob
sẽ cần thực hiện các bước sau:

1. Tạo ra một giá trị CertificateRequestInfo theo chuẩn PKCS#10 từ khóa công
khai của Bob và tên người dùng. Khi giai đoạn bắt tay đã sẵn sàng, giá trị
CertificateRequestInfo này bao gồm tên phân biệt của thực thể, trong trường
hợp này là Bon và khóa công khai của thực thể

2. Sau khi phát hành giá trị CertificateRequestInfo, Bob cần ký giá trị này với
khóa riêng của mình.
 3. Cuối cùng, Bob cần tạo ra một giá trị CertificateRequest như mỗi PKCS#10
từ giá trị CertificateRequestInfo và chữ ký của anh ta.

 Tạo giá trị CertificateRequestInfo

Bob tạo ra một giá trị CertificateRequestInfo thông qua tên phân biệt (DN –
Distinguished Name) và khóa công khai của anh ta. Chúng ta công nhận rằng Bob
thường đặt tên là Bob và làm việc cho công ty X, đặt trong hoàn cảnh ở Hoa Kỳ.
Giá trị CertificateRequestInfo này được mã DER, kết quả sinh ra là một chuỗi
Octet.

CertificateRequestInfo bao gồm:

CertificationRequestInfo:Tạo giá trị certificateRequestInfo

   CertificationRequestInfo ::= SEQUENCE

   {

       version INTEGER { v1(0) } (v1,...),=0 standart

       subject Name,                 //tên phân biệt của đối tượng

       subjectPKInfo  SubjectPublicKeyInfo{{

PKInfoAlgorithms }},

       attributes    [0] Attributes{{ CRIAttributes }}

   }

-Version:  thể hiện số version tương thích với bất kỳ các đặc điểm kỹ thuật trong
tương lai.

-Subject: thể hiện tên phân biệt của các chủ thể của chứng thư.

- SubjectPublickeyInfor: thể hiện thông tin khóa công khai của chủ thể của chứng
thư mà nó là được chứng nhận.
-Attributes: thể hiện thông tin bổ sung về chủ thể của chứng thư như tên thông
dụng của chủ thể và tên tổ chức.

Sau khi tạo một giá trị CertificateRequestInfo, Bon cần ký lên giá trị này

 Ký giá trị CertificateRequestInfo

Sau khi tạo được giá trị CertificateRequestInfo, Bob cần ký lên đó bằng việc sử
dụng khóa riêng của mình. Bob có thể sử dụng bất kỳ thuật toán ký phân biệt như
PKCS#1, MD5, RSA. Các bước ký giá trị CertificateRequestInfo gồm:

1. Một thông báo MD5 được nhập vào CertificateInfo đã mã hóa

2. Một giá trị DigestInfo được mã hóa từ thông báo băm và giá trị
CertificateInfo

3. Cuối cùng, giá trị DigestInfo đã mã hóa được mã hóa bằng khóa riêng của
Bob

Sự mã hóa về giá trị DigestInfo sinh ra một chuỗi Octet hoặc một chữ ký. Sau khi
ký lên giá trị CertificateRequestInfo, Bob cần tạo ra các giá trị CertificateRequest.

 Tạo một giá trị CertificateRequest

Giá trị CertificateRequestInfo và chữ ký số là cùng được sử dụng để tạo giá trị
CertificateRequest cho mỗi PKCS#10. Đây là giá trị được gửi tới CA như một yêu
cầu chứng thư.

CertificateRequest có cấu trúc như sau:

CertificationRequest ::= SEQUENCE {

        certificationRequestInfo CertificationRequestInfo,

        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},

        signature          BIT STRING

   }

   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {

        algorithm          ALGORITHM.&id({IOSet}),

        parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL

   }

   SignatureAlgorithms ALGORITHM ::={ ... -- add any locally defined algorithms

here -- }

- CertificateRequestInfo: Thể hiện giá trị thông tin yêu cầu chứng thư
đang được ký.

- Signature Algorithm: thể hiện thuật toán ký được sử dụng để ký thông

tin yêu cầu chứng thư.

- Signature: Thể hiện kết quả của việc mã hóa CertificateRequestInfo

với khóa riêng của chủ thể

Sau khi tạo giá trị CertificateRequest, Bob gửi giá trị này như là yêu cầu chứng thư
đến CA. Sau khi xác thực các tiêu chuẩn của Bob thông qua việc kiểm tra chữ ký
của Bob và thông tin đã chứa dựng trong giá trị CertificateRequest, CA có thể phát
hành chứng thư đến Bob.

PKCS#10 là chuẩn phổ biến nhất cho yêu cầu chứng thư. Hầu hết các ứng dụng
PKI có sự phát triển trong ứng dụng Web, yêu cầu chứng thư có thể được làm trực
tuyến. Tuy nhiên PKCS#10 không hỗ trợ giao thức HTTP, khi một yêu cầu chứng
thư được tạo ra trên nền Web bằng việc sử dụng giao thức HTTP, CA không thể
xác thực được thực thể. Vì vậy, PKCS#10 không được sử dụng phổ biến với giao
thức SSL (secure Socket Layer) cho việc tạo yêu cầu chứng thư.

Nhìn chung, PKCS#10 và SSL được sử dụng trong liên lạc ba bên, trong trường
hợp đó, một RA xác thực yêu cầu sau khi một thực thể gửi yêu cầu của nó đến CA.
Các tiến trình trong một liên lạc ba bên khi PKCS#10 được sử dụng với SSL như
sau:

- Một kết nối SSL được thiết lập giữa Client và CA.

- Client gửi một yêu cầu PKCS#10 đến CA

- CA gửi yêu cầu đến RA cho sự kiểm tra

 - Một phiên SSL được thiết lập giữa CA và RA

- Dựa trên sự kiểm tra thông tin, RA sẽ xử lý thông báo (chấp nhận
hoặc từ chối yêu cầu)

- Nếu RA chấp nhận chứng thư, CA sẽ phát hành chứng thư.

Hạn chế của PKCS#10.

- Không có thuật toán độc lập, chỉ là thuật toán RSA, nó cũng công nhận rằng khóa
riêng phải được sử dụng cho việc tạo chữ ký số.

- Chữ ký số trên mẫu yêu cầu PKCS#10 không cung cấp tất cả các thông tin cần để
xác thực người dùng. Hơn nữa không có cơ chế định nghĩa tốt để đảm rằng một
yêu cầu chứng thư không bị thay thế trong quá trình truyền.

- PKCS#10 chỉ định nghĩa ký tự cho một kiểu thông báo, mà nó là một yêu cầu
chứng thư và không cho sự hoàn thiện các giao thức. Nó không phân biệt các ký tự
và giao thức cho bất kỳ các kiểu thông báo khác như yêu cầu thu hồi chứng thư. Vì
vậy, các thông báo khác với kiểu thông báo yêu cầu chứng thư có thể được thực thi
bằng việc sử dụng giao thức khác như là HTTP.

4.1.2. Giao thức quản lý chứng thư số (CMP)

4.1.2.1 CMP

Giao thức quản lý chứng thư số (Certificate Management Protocol )gọi tắt là
CMP, được yêu cầu cho việc tương tác trực tuyến giữa các thực thể PKI khác
nhau. Các thực thể này có thể là những người dùng có chứng thư số được cấp phát
hoặc CA chịu trách nhiệm cho việc cấp phát chứng thư số tới người dùng. CMP có
thể hoạt động giữa 2 CA cho việc chứng thư chéo và có thể hoạt động giữa một
người dùng và một CA cấp phát. CMP cũng hỗ trợ cho cơ quan đăng ký RA. Do
khả năng tương tác cao nên CMP được các nhà cung cấp PKIX áp dụng rộng rãi
như: IBM và Lotus. Quá trình quản lý chứng thư số của Cryptlib được tự động hóa
hoàn toàn bằng việc sử dụng CMP. CMP cũng cho phép cấp phát, đăng ký và thu
hồi chứng thư số trực tuyến tại Cryptlib. Bằng việc loại bỏ các yêu cầu người dùng
phải có kiến thức kỹ thuật trong việc quản lý chứng thư số như CA xử lý các quản
lý chứng thư số thì việc triển khai CMP đã hỗ trợ người dùng rất nhiều.
CMP bao gồm 4 thành phần

- Phần tiêu đề (Header): thành phần này bao gồm tên người gửi và người
nhận, thời gian của thông điệp, và thuật toán mã hóa được sử dụng. ngoài
các thông tin này, phần tiêu đề còn bao gồm một số trường tùy chọn như
định danh khóa và định danh giao dịch. Phần này cũng gồm có 2 trường nữa,
một trường dùng cho mở rộng thông tin xử lý và một trường dùng cho các
thông tin người dùng.
- Phần bảo vệ (Protection):là phần tùy chọn, phần này thường chứa mã xác
thực thông điệp . thường được dùng để kiểm tra tính toàn vẹn của phần tiêu
đề (header) và phần nội dung (body).
- Các chứng thư số phụ (Extra certificates): thành phần này bao gồm các
chứng thư số phụ mà các thuê bao có thể yêu cầu thêm.
- Phần nội dung (body): là thành phần chứa các loại thông điệp, một số dạng
thông điệp như sau:
o Thông điệp yêu cầu – trả lời chứng thư số: thông điệp này cần thiết
cho mực đích yêu cầu và cấp phát chứng thư số cho người dùng. Các
loại thông điệp khác nhau xác định các yêu cầu chứng thư số khác
nhau
o Thông điệp yêu cầu – trả lời chứng thực chéo: thông điệp này cần
thiết cho việc yêu cầu và phân phối chứng thư số tới các CA
o Thông điệp yêu cầu – trả lời thu hồi chứng thư số: cần thiết cho yêu
cầu thu hồi chứng thư số và các phản hồi của chứng thư số.
o Thông điệp yêu cầu – trả lời khôi phục khóa: được yêu cầu cho việc
truyền khóa bí mật dùng để sao lưu
o Proof of possession challenge and response messages: được yêu cầu
như là bằng chứng chứng minh quyền sở hữu khóa bí mật trong suốt
quá trình thỏa thuận khóa.
o Thông điệp phân phối chứng thư số và CRL: được dùng cho việc cấp
phát chứng thư số hoặc CRL.
o Các thông điệp khác: thông điệp này có thể là một lỗi, một xác nhận,
một yêu cầu hay là các loại tin nhắn chồng nhau.

Theo CMP, thông điệp yêu cầu chứng thư số gồm 3 thành phần chính, cụ thể là:
 - Định dạng thông điệp yêu cầu chứng thư số (Certificate Request Message
Format – CRMF): CRMF bao gồm một định danh yêu cầu, một mẫu gồm
các thông tin về chứng thư số và một số optional controls. Mẫu này không
chỉ gồm tất cả các trường trong chứng thư số mà còn chứa cả các trường mở
rộng của chứng thư số.
- Chứng minh tính sở hữu (Proof of Possession – POP): POP cho phép thực
thể liên kết với chứng thư số để chứng minh thực thể sở hữu khóa riêng
tương ứng với khóa công khai của chứng thư số. ta có thể thực hiện POP
theo nhiều cách, như sử dụng of the out−of−bound methods or PKIX−CMP
in−band messages, phụ thuộc vào loại khóa sử dụng trong chứng thư số. Ví
dụ, nếu yêu cầu chứng thư được thiết lập để ký một cặp khóa thì POP của
khóa ký bí mật được thiết lập bằng việc dùng cấu trức khóa ký POP
(POPOSigningkey structure). Tuy nhiên, nếu khóa đó sử dụng cho nhiều
mục dích, như khóa RSA thì có thể chọn bất kỳ phương pháp nào
- Thông tin đăng ký (Registration information): bao gồm một số các thông tin
hỗ trợ được sử dụng trong quá trình yêu cầu chứng thư số như: thông tin liên
hệ các thực thể, thông tin thanh toán

4.1.2.2 Quá trình phát triển CMP

CMP cung cấp một giải pháp an toàn toàn vẹn cho giao dịch PKI. CMP cũng hỗ
trợ cho cơ quan đăng ký RA. Tuy nhiên, triển khai CMP là một quá trình phức tạp
và yêu cầu thiết lập một phần mềm mới vì CMP không được hỗ trợ bởi định dạng
có sẵn. Sau đây là một số đặc tính của CMP:

- CMP được sử dụng ở bất kỳ mô hình giao dịch nào

- CMP hỗ trợ công cụ cho việc khẳng định quyền sở hữu khóa bí mật trong
suốt quá trình thỏa thuận khóa bằng cơ chế trả lời – thách đố.
- CA cần luôn luôn duy trì thông tin trạng thái trong luồng giao dịch và thông
điệp vì một CMP không thể chắc chắn chỉ ra được thông điệp hay giao dịch
được sử dụng.
- Việc mở rộng được thực hiện trong CMP với sự hỗ trợ của trường thông tin
chung. Ta có thể tính đến loại và giá trị trong trường đó để giúp nhận ra các
dữ liệu tại nơi nhận cuối.
 - CMP sử dụng kỹ thuật mật mã để bảo vệ tất cả các thông điệp, bắt đầu từ
yêu cầu chứng thư số ban đầu cho đến các phản hồi từ CA. những thông
điệp được ký số này có thể được lưu trữ bởi người dùng hoặc CA.

4.1.2.3 Quản lý chứng thư số sử dụng CMS (CMC)

CMC cung cấp tất cả các chức năng quan trọng của CMP, như lưu trữ khóa, cấp
phát chứng thư số và thu hồi chứng thư số. Giao thức này sử dụng cú pháp thông
điệp mã hóa (cryptographic message syntax) và chuẩn PKCS#10 và PKCS#7.

Không giống với sự phức tạp của CMP trong việc xác định quá nhiều thông điệp
và giao dịch qua nhiều vòng, thì giao dịch CMC hoàn toàn là một vòng duy nhất.
Các định dạng thông điệp sử dụng cho yêu cầu và tiếp nhận chứng thư số cũng như
các phương thức liên quan đến giao thức này đều khác nhau.

Nội dung giao dịch trong giao thức quản lý CMC gồm 2 loại: dữ liệu PKI và phản
hồi PKI. Thông điệp yêu cầu từ thực thể tới CA được gọi là dữ liệu PKI (PKI Data)
và thông điệp phản hồi các yêu cầu gọi là phản hồi PKI (PKI Response). Tuy
nhiên, thông điệp giao dịch CMC không cần thiết phải giữ bí mật, nhưng có một cơ
chế để đóng gói các thông điệp dữ liệu PKI hoặc phản hồi PKI trong các dữ liệu
được ký số CMS vào bao dữ liệu CMS. Với 24 thuộc tính điều khiển, CMC sẽ
kiểm soát thông điệp dữ liệu PKI và phản hồi PKI, mọi thuộc tính này có các định
danh đối tượng riêng và trong suốt quá trình xử lý, định danh đối tượng này được
xử lý đầu tiên rồi đến nội dung thông điệp. Các thuộc tính với các định danh sẽ
kiểm soát luồng thông điệp. Nếu thông điệp dữ liệu hoặc phản hồi PKI chứa các
thuộc tính không xác định thì các thông điệp này sẽ bị loại bỏ.

Một số các thuộc tính điều khiển là các trường mở rộng, các giao dịch, và sự chứng
minh tính sở hữu. các thuộc tính này được sử dụng để xác định các loại yêu cầu và
phản hồi. Nói tóm lại, CMC đơn giản hơn CMP nhưng lại phức tạp hơn PKCS#10
và PKSC#7. Giao thức quản lý này có thể được dùng trong kiến trúc có sự tham
gia của cơ quan đăng ký RA

4.1.3. Giao thức đăng ký chứng thư số đơn giản(SCEP)

 4.1.3.1 Giao thức đăng ký chứng thư số đơn giản (Simple
Certificate Enrollment Protocol – SCEP)

Giao thức đăng ký chứng thư số đơn giản (Simple Certificate Enrollment Protocol
– SCEP) được hãng Cisco phát triển như là một giao thức giao tiếp bằng PKI. Giao
thức này được thiết kế cho việc cấp phát chứng thư số tới các thiết bị mạng khác
(bằng việc dùng các công nghệ có sẵn) trong môi trường an toàn và mở rộng cao.
Một số nhà cung cấp dịch vụ như Verisign, Entrust hay Microsoft cũng hỗ trợ
SCEP. SCEP được dùng trong các sản phẩm client như các router của Cisco, SSH,
ứng dụng VPN. SCEP cũng được sử dụng bởi sản phẩm RSA Keon Certificate
Server 5.5 để cung cấp khả năng tích hợp với các routers, tường lửa và các sản
phẩm Cisco khác.

SCEP hỗ trợ các giao dịch sau:

- Phân phối khóa công khai của CA và RA

- Thu hồi chứng thư số
- Đăng ký chứng thư số
- Truy vấn chứng thư số
- Truy vấn CRL

4.1.3.2 Hoạt động của SCEP

Theo SCEP, các thực thể nên có các thông tin sau đây như một điều kiện tiên
quyết để thực hiện bất kỳ một hoạt động PKI nào:

- Tên miền tiêu chuẩn đầy đủ (Fully Qualified Domain Name – FQDN) của
CA hoặc địa chỉ IP của CA
- Đường dẫn tập lệnh CA HTTP và thông tin proxy trong trường hợp không
kết nối trực tiếp với máy chủ
- Đường dẫn URL của chứng thư số và CRL được truy vấn

Quá trình giao dịch PKI bắt đầu khi cặp khóa được sinh ra. Để thực hiện điều này
các thực thể có thể sử dụng bất kỳ một thuật toán được SCEP hỗ trợ như RSA. Sau
đó, ta có một khóa công khai của CA sử dụng standard HTTP Get operation khi
thực thể tin cậy vào CA. Sauk hi định danh của CA được thiết lập, thực thể sử
dụng PKCS#10 để cấp phát yêu cầu chứng thư số và PKCS#7 để gửi yêu cầu tới
CA.

Tại thời điểm đăng ký chứng thư số bắt đầu, SCEP hỗ trợ 2 quá trình đăng ký

- Manual: trong xác thực bằng tay, thực thể phải đợi nhận yêu cầu của CA
cho tớ khi CA xác thực danh tính của thực thể.
- Challenge password: trong kiểu đăng ký này, thực thể cung cấp mật khẩu
cho CA. CA sẽ xác thực yêu cầu dựa vào mật khẩu nhận được.

Sau khi hoàn tất việc xác thực, CA sẽ cấp phát chứng thư số cho thực thể

4.1.3.3 Thu hồi chứng thư số trong SCEP

Quá trình thu hồi chứng thư số trong SCEP được thực hiện thủ công. Khi một thực
thể gửi yêu cầu thu hồi chứng thư số, thực thể đó phải liên hệ với CA thông qua
điện đàm. CA sẽ đề nghị thực thể đưa ra mật khẩu, nếu mật khẩu được xác thực thì
chứng thư số sẽ được thu hồi.

4.1.3.4 Truy cập chứng thư số và CRL

Để truy vấn một chứng thư số, thực thể có thể sử dụng giao thức LDAP hoặc thông
điệp truy vấn được quy định trong SCEP. Các thông điệp truy vấn bao gồm các
thông điệp GetCertPKI và CertRepPKI. Để truy cập tới CRL, thực thể có thể dùng
ba phương pháp sau:

- Sử dụng yêu cầu HTTP Get đơn giản

- Sử dụng LDAP: giả thiết máy chủ CA hỗ trợ công bố CRL LDAP và cấp
phát điểm phân phối CRL trong chứng thư số. điểm phân phối CRL được mã
hóa như một DN
- Tạo thông điệp có chứa tên CA phát hành và số serial chứng thư số của CA.
phương pháp này không được khuyến cáo vì phạm vi sử dụng không tốt và
yêu cầu CA có tính sẵn sàng cao.

4.1.3.5 Sự phát triển SCEP

SCEP có những hạn chế sau:

 - Không xác định được thông điệp yêu cầu thu hồi chứng thư, chỉ hỗ trợ cho
các thông điệp yêu cầu chứng thư số.
- Là một thuật toán đặc trưng và chỉ hỗ trợ thuật toán RSA.
- Chỉ sử dụng cho cấp phát chứng thư số trong thiết bị mạng. Do vậy, SCEP
rất đặc trưng để ứng dụng.

4.2. NHÓM CHUẨN VỀ KHUÔN DẠNG CHỨNG THƯ SỐ VÀ CRL

Chuẩn về khuôn dạng mô tả chi tiết các trường trong cấu trúc dữ liệu chứng
thứ số (v3) và danh sách thu hồi chứng thư (v2). Giới thiệu RFC 5280 – Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile 2008-05 ( Định dạng X.509: danh sách chứng thư bị thu hồi và chứng thư
số hạ tầng khóa công khai trong Internet)

4.2.1. Chứng thư số X.509 version 3

Khuôn dạng chứng thư X.509 gồm có 3 phiên bản 1,2,3 được trình bày như
sau:

Các trường của chứng thư:

- Phiên bản (Version): chỉ ra dạng phiên bản 1,2,3

- Số hiệu (Serial Number): Số hiệu nhận dạng duy nhất của chứng thư này. Nó
được CA phát hành gán cho.

- Tên thuật toán ký (Signature): Tên thuật toán ký được CA sử dụng để ký

chứng thư.

- Người phát hành (Issuer): Tên theo chuẩn X.500 của CA phát hành.

- Thời gian hợp lệ (Validity): Ngày/giờ có hiệu lực và hết hạn của một chứng
thư.

- Chủ thể (Subject): Tên X.500 của đối tượng nắm giữ khoá riêng (tương ứng
với khoá công khai được chứng thực).
- Thông tin về khoá công khai của chủ thể (Subject Public key Information):
gồm khoá công khai của chủ thể cùng với một tên thuật toán sử dụng khoá
công khai này.

- Tên duy nhất của người phát hành (Issuer unique identifier): Là một chuỗi
bit tuỳ chọn, được sử dụng để chỉ ra tên rõ rang của CA phát hành, trong
trường hợp cùng một tên được gán cho các thực thể khác nhau trong cùng
thời gian.

- Tên duy nhất của chủ thể (Subject unique identifier): là một chuỗi bit tuỳ
chọn, được sử dụng để chỉ ra tên rõ rang của chủ thể, trong trường hợp cùng
một tên được gán cho các thực thể khác nhau trong cùng thời gian.
 Hình 4-1: Khuôn dạng chứng thư trong phiên bản 1 và 2 của X.509

4.2.1.1 Tên trong X.509

Khi các chứng thư không bị hạn chế sử dụng kết hợp với các hệ thống thư
mục X.509, các chứng thư của phiên bản 1,2 sử dụng cách đặt tên theo X.509 để
nhận dạng các chủ thể và phát hành.
 Thông tin được lưu giữ trong các thư mục X.509 gồm có một tập hợp các
đầu vào. Mỗi đầu vào liên quan tới một đối tượng thực, ví dụ một người, một tổ
chức, hoặc một thiết bị. Đối tượng này có một tên rõ ràng, được gọi là tên phân
biệt (DN). Đầu vào thư mục của một đối tượng có chứa các giá trị của một tập hợp
các thuộc tính, gắn liền với đối tượng này. Ví dụ như thông tin đầu vào về một
người có thể chứa các giá trị của các thuộc tính như tên, số điện thoại và địa chỉ
thư điện tử. Để hỗ trợ yêu cầu đặt tên rõ rang, tất cả các đầu vào của X.509 được tổ
chức hợp lý theo cấu trúc cây, được gọi là cây thông tin thư mục. Cây này có một
gốc và không hạn chế số đỉnh. Tất cả các đỉnh này (trừ gốc) phụ thuộc vào các
đỉnh xa hơn. Mỗi đỉnh (trừ gốc) tương ứng với một đầu vào thư mục và có một tên
phân biệt (tên phân biệt của gốc là Null). Ví dụ
 Hình 4-2 : Tên phân biệt

Tên phân biệt của một đầu vào được tạo ra bằng cách kết hợp tên phân biệt
của đầu vào mức trên gần nó nhất (ở trên cây) cùng với tên phân biệt liên quan
(RDN), nó phân biệt đàu vào phụ thuộc vào các mức dưới trực tiếp khác của cùng
một thực thể mức trên.

RDN biểu diễn một (hoặc nhiều thuộc tính của một thực thể. Chính xác hơn,
đây là một tập hợp các xác nhận về giá trị của thuộc tính, mỗi xác nhận phải hoàn
toàn chính xác, liên quan đến các giá trị phân biệt của một thực thể (đây là các giá
trị thuộc tính được cung cấp duy nhất.
 Các tên duy nhất không phải là giải pháp đáng tin cậy cho vấn đề này bởi vì
chúng rất khó quản lý, có xu hướng che dấu không cho xem và rất dễ bị bỏ qua
hoặc quên khi bổ sung. Có một giải pháp tốt hơn nhiều, có thể đảm bảo rằng tất cả
các tên X.500 đều rõ ràng. Trên một RDN, chỉ cần lấy một giá trị thuộc tính duy
nhất trong toàn bộ thời gian.

Ở đây có một vấn đề đối với tên thường dùng (CN), ví dụ như trường ĐHBK
có thể có một hoặc nhiều người tên Lê Tùng. Các tổ chức thường có một hệ thống
số hiệu dành cho người của hệ thống mình, hệ thống số hiệu này cũng gặp phải sự
không rõ rang như trên và khó có thể đảm bảo rằng các số hiệu của một người
không bị tái sử dụng trong toàn bộ thời gian. Vì vậy, một dạng RDN có thể như
sau: {CN=Lê Tùng, Student Number = 123456789}. Giải pháp này được nhiều tổ
chức chấp nhận.

4.2.1.2 Đăng ký đối tượng

Khuôn dạng chứng thư X.509 được trình bày ở trên có các tên thuật toán.
Các tên này được sử dụng để nhận dạng thuật toán ký (dùng cho chữ ký người phát
hành) và thuật toán sử dụng khoá công khai được chứng thực. Ví dụ, các tên thuật
toán khác nhau có thể được định rõ:

- Chữ ký số, sử dụng DSS với hàm băm SHA.

- Chữ ký số, sử dụng RSA với hàm băm MD5.

- Thiết lập khoá mã hoá, sử dụng truyền khoá RSA

- Thiết lập khoá mã hoá, sử dụng kỹ thuật Diffe-Hellman.

Đây là một số ví dụ về một lớp các đối tượng yêu cầu đăng ký, hay là việc
gán các tên của đối tượng duy nhất.

Một hệ thống đăng ký của đối tượng được sử dụng cho các tên thuật toán và
cho các lớp đối tượng chính là cơ chế tên đối tượng được định rõ trong các chuẩn
và được sự hỗ trợ của rất nhiều các cơ quan đăng ký đối tượng.

Tên đối tượng là một giá trị, bao gồm một dãy các số nguyên. Giá trị này có
thể được gán cho một đối tượng đã đăng ký. Các tên đối tượng hoàn toàn khác
nhau hay một tên đối tượng là duy nhất.
 4.2.1.3 Khuôn dạng chứng thư X.509 mở rộng (V.3)

Càng ngày các khuôn dạng chứng thư trong phiên bản 1,2 không đáp ứng
được tất cả yêu cầu. Dưới đây là các lý do bổ sung thêm thông tin.

 Giả thiết chủ thể của một chứng thư bất kỳ có các chứng thư khác nhau với
các khoá công khai khác nhau (các khoá này được sự dụng cho các mục đích
khác nhau) và giả thiết rằng các cặp khoá cần được cập nhật định kỳ, do vậy
cần phải có cách để phân biệt các chứng thư khác nhau của đối tượng này
một cách dễ dàng.

 Một tên trong X.500 trở thành tên duy nhất của chủ thể nhưng không có đủ
thông tin cho những người sử dụng chứng thư khác nhận dạng chủ thể, vì thế
cần chuyển thêm thông tin nhận dạng chủ thể ngoài tên X.500.

 Một số các ứng dụng cần nhận dạng những người sử dụng thông qua các
dạng tên xác định ứng dụng, ngoài các tên X.500. Ví dụ, trong an toàn thư
tín điệu tử, việc gắn một khoá công khai với một địa chỉ thư tín điện tử quan
trọng hơn nhiều so với việc gắn với một tên X.500

 Các chứng thư khác nhau có thể được phát hành theo các chính sách và các
hoạt động chứng thực khác nhau. Các chính sách và các hoạt động chứng
thực này thường chi phối mức tin cậy của người sử dụng đối với một chứng
thư. Ví dụ, nếu một chứng thư được phát hành cho một thuê bao với hy vọng
rằng, đôi khi nó sẽ được sử dụng cho mục đích mã hoá thư điện tử, CA sẽ
không phải thực hiện tất cả các kiểm tra nhận dạng và xác thực thích hợp
nếu chứng thư đã được sử dụng cho việc kiểm tra các chữ ký số trong các
giao dịch tài chính giữa các tổ chức. Những người sử dụng chứng thư cần
biết rằng, các đảm bảo và các hoạt động sẽ được áp dụng cho việc phát hành
từng chứng thư.

 Các đường dẫn chứng thực không được dài tuỳ tiện và phức tạp. Khi một
CA (CA phát hành) chứng thực CA khác (CA của một chủ thể), CA phát
hành có thể chỉ muốn chấp nhận một tập hợp con các chứng thư được CA
của một chủ thể phát hành (ví dụ, các chứng thư này bao phủ lên không gian
tên của chủ thể riêng biệt).
 Trong thực tế, để thoả mãn các yêu cầu (đã biết hoặc chưa biết) trong tương
lai, cần bổ sung thêm các trường vào khuôn dạng của chứng thư. Các tổ chức
chuẩn chấp nhận bổ sung thêm vào chứng thư X.509 một cơ chế mở rộng chung.
Kết quả là X.509 có 3 khuôn dạng chứng thư được định nghĩa.

Chứng thư trong phiên bản 3 có cùng khuôn dạng với các chứng thư trong
phiên bản 1 và 2 nhưng có bổ sung thêm các trường mở rộng được trình bày như
sau:
Mỗi trường mở rộng có một kiểu (cần được đăng ký). Giống với cách đăng ký một
thuật toán, kiểu của trường mở rộng được đăng ký bằng cách gán cho nó một tên
đối tượng. Về nguyên tắc, các kiểu của trường mở rộng được một người nào đó xác
định. Trong thực tế, để làm được điều này, các kiểu của trường mở rộng thông
thường phải được biết rộng rãi qua các thiết lập khác nhau, chính vì vậy các kiểu
quan trọng của trường mở rộng phải được chuẩn hoá. Tuy nhiên, các cộng đồng
quan tâm có thể xác định các kiểu của trường mở rộng để đáp ứng các nhu cầu
riêng của họ.

Trong phiên bản 3, mỗi trường mở rộng chứa một giá trị tên đối tượng (chỉ
ra kiểu của trường, một chỉ báo thiết yếu và một giá trị). Kiểu của mục dữ liệu
trong trường con (ví dụ như chuỗi văn bản, ngày hoặc cấu trúc dữ liệu phức tạp)
ngữ nghĩa liên quan đến giá trị này do kiểu của trường mở rộng chi phối. Điều này
có thể xảy ra như là kết quả của việc định nghĩa các chứng thư nhằm hỗ trợ cho các
nhu cầu của nhiều ứng dụng, hoặc là kết quả của việc đưa ra các trường mở rộng
mới thông qua việc di trú kỹ thuật.

Chỉ báo thiết yếu là một cờ, cờ này sẽ xuất hiện khi trường mở rộng là thiết
yếu hoặc không thiết yếu. Nếu cờ chỉ báo là “không thiết yếu” thì một hệ thống sử
dụng chứng thư được phép bỏ qua trường mở rộng nếu nó không chấp nhận kiểu
của trường. Nếu cờ chỉ báo là “thiết yếu” thì một hệ thống sẽ không an toàn nếu sử
dụng bất kỳ phần nào của chứng thư, trừ khi hệ thống này chấp nhận kiểu của
trường mở rộng và thiết lập chức năng liên quan.

Ví dụ, giả sử rằng trường mở rộng được xác định để chuyển một dạng tên
lựa chọn cho đối tượng của chứng thư sử dụng, thông qua một tập hợp các ứng
dụng đặc thù. Một trường như vậy có thể được chỉ báo là không thiết yếu vì các
ứng dụng khác không sử dụng dạng tên lựa chọn vẫn được phép sử dụng chứng thư
dựa vào trường tên chủ thể nguyên thuỷ ngay cả khi các ứng dụng này không so sự
thoả thuận về việc mở rộng tên lựa chọn. Hoặc, giả thiết có một trường mở rộng
chuyển thông tin, nó hạn chế các mục đích mà một CA có thể được áp đáp ứng khi
sử dụng chứng thư. Nếu một hệ thống sử dụng chứng thư không hiểu trường mở
rộng này hoặc bỏ qua nó thì hệ thống này có thể hoạt động không an toàn. Trong
trường hợp sau, trường mở rộng phải được CA chỉ báo.
 Khái niệm “thiết yếu” thường xuyên bị hiểu sai. Một trường mở rộng có thể
quan trọng với người sử dụng chứng thư nhưng không nhất thiết phải chỉ báo thiết
yếu. Một hệ thống sử dụng chứng thư có thể yêu cầu các trường mở rộng nào đó
xuất hiện trong một chứng thư hoặc thông tin nào đóphải có trong các trường của
chứng thư trước khi chứng thư được chấp nhận. Một yêu cầu như vậy không liên
quan đến tính thiết yếu, hệ thống sử dụng chứng thư có thể yêu cầu sự xuất hiện
của các trường mở rộng không thiết yếu chẳng khác gì với yêu cầu sự xuất hiện
của các trường mở rộng thiết yếu nào đó.

Các trường mở rộng không thiết yếu giúp cho việc sử dụng các chứng thư
thông qua các ứng dụng khác nhau trở nên dễ dàng hơn và giúp cho sự di trú trở
nên đơn giản hơn thông qua việc bổ sung dần dần các kiểu mới cho trường mở
rộng. Các trường mở rộng thiết yếu dẫn đến các vấn đề về khả năng liên hoạt động
và cần phải tránh, trừ khi giải quyết các mối quan tâm về an toàn. Thông thường
khi sử dụng, đa số các trường mở rộng được chỉ báo không thiết yếu.

4.2.1.4 Các trường mở rộng chuẩn của chứng thư

Một tập hợp các trường mở rộng chuẩn (dành cho chứng thư trong phiên bản
3 của X.509) được một số tổ chức phát triển. Các trường mở rộng có thể được chia
nhỏ thành các nhóm như sau:

(1) Thông tin về khoá và chính sách

(2) Các thuộc tính của chủ thể và người phát hành

(3) Các ràng buộc đối với đường dẫn chứng thực

(4) Các trường mở rộng liên quan đến danh sách các chứng thư bị thu hồi
(CRL)

Các trường mở rộng nhóm (1) chuyển thêm các thông tin về các khoá của
chủ thể và người phát hành, ví dụ như các tên khoá và các chỉ báo về việc sử dụng
khoá được phê chuẩn. Nó cũng chuyển các chỉ báo về chính sách chứng thư (các
chính sách liên quan đến các hoạt động của CA), giúp cho việc thiết lập cơ sở hạ
tầng khoá công khai trở nên dễ dàng và cho phép các nhà quản trị hạn chế các mục
đích sử dụng các chứng thư và các khoá đã được chứng thực. Các trường mở rộng
này bao gồm:
 Tên khoá của CA phát hành (Authority Key Identifier):

Trường này được sử dụng để phân biệt các khoá khác nhau được CA phát
hành sử dụng khi ký chứng thư (ví dụ như các khoá khác nhau được sử dụng trong
các khoảng thời gian khác nhau). Các khoá này có thể được nhận dạng bằng cách:

 Thông qua một tên khoá rõ ràng

 Thông qua một con trỏ tới một chứng thư khác, trong đó khoá của người
phát hành chứng thư này được CA khác chứng thực, hoặc

 Thông qua tên khoá ràng và một con trỏ chứng thư.

Trường này giúp cho các hệ thống sủ dụng chứng thư tìm kiếm các chuỗi chứng
thư một cách hiệu quả, vì vậy các CA sẽ cập nhật các cặp khoá của họ một cách
định kỳ như là một phần trong quản lý vòng đời khoá. Trường này giúp cho các
CA tiếp theo tìm kiếm chính xác chứng thư trong chuỗi chứng thư.

Tên khoá của chủ thể (Subject Key Identifier):

Trường này được sử dụng để phân biệt các khoá mà chủ thể của một chứng
thư sử dụng. Ví dụ, chủ thể có thể thiết lập một cặp khoá mới một cách định kỳ và
trường này chỉ ra khoá công khai nào (của một chứng thư xác định) được chứng
thực.

Sử dụng khoá (Key Usage):

Trường này được sử dụng để chỉ ra mục đích sử dụng khoá, chẳng hạn cho
chữ ký số, hoặc thiết lập khoá mã. Trường này có hai biến thể, “thiết yếu” và
“không thiết yếu”. Khi trường chỉ báo “thiết yếu”, CA quy định chỉ được sử dụng
chứng thư và khoá vào các mục đích đã được xác định. Nếu người sử dụng dùng
chứng thư vào các mục đích khác thì coi như đã vi phạm chính sách của CA và
không nên tin tưởng vào chứng thư này. Khi trường chỉ báo “không thiết yêu”,
trường không khác gì một chỉ báo, người sử dụng chứng thư có thể sử dụng nó để
tìm ra chứng thư đúng. Ví dụ, một người sử dụng cho các mục đích lưu giữ trong
đầu vào thư mục của người sử dụng, trường này có thể giúp một người sử dụng
chứng thư tìm ra chứng thư đúng. Hai biến thể của trường này có mục đích sử
dụng riêng, nhưng sử dụng nhiều nhất là các CA sẽ chọn và sử dụng biến thể thiết
yếu để hạn chế việc đưa ra trách nhiệm pháp lý của mình.
 Khoảng thời gian sử dụng khoá riêng (Private-key Usage Period):

Chỉ ra thời hạn sử dụng một khoá riêng cho mục đích ký số (khoá riêng này
cùng cặp với khoá công khai dùng trong ký số và đã được chứng thực). Việc sử
dụng trường này góp phần hạn chế khả năng lộ khoá riêng.

Các chính sách chứng thư (Certificate policies):

Chỉ ra các chính sách hoặc các hoạt động liên quan đến chứng thư.

Ánh xạ chính sách (Policy Mapping):

Chỉ được sử dụng khi chủ thể của chứng thư là một CA) cho phép người
phát hành xác định một hoặc nhiều chính sách (dành cho chứng thư của người phát
hành này) có thể được quan tâm ngang bằng với các chính sách khác đượg sử dụng
trong miền của CA.

Các trường mở rộng của nhóm (2) chỉ ra các tên lựa chọn dành cho các chủ
thể và người phát hành chứng thư. Chúng cũng có thể cho biết thêm các thông tin
thuộc tính của chủ thể, giúp cho người sử dụng chứng thư có được sự tin cậy đối
với chứng thư (áp dụng cho một người, một tổ chức hoặc một thiết bị xác định).
Các trường mở rộng này gồm:

Tên lựa chọn của chủ thể (Subject Alternative Name):

Trường này chỉ ra một hoặc nhiều tên lựa chọn phân biệt. Các chủ thể của
chứng thư sử dụng nhiều dạng tên khác nhau. Nó cho phép chứng thư hỗ trợ các
ứng dụng như thư tín điện tử... sử dụng các dạng tên của mình và không nhất thiết
phải sử dụng các thư mục X.500.

Tên lựa chọn của người phát hành (Issuer Alternative Name):

Trường này chỉ ra một hoặc nhiều tên lựa chọn dành cho người phát hành
chứng thư. Các dạng tên dành cho người phát hành cho người phát hành cũng
giống như dạng tên dành cho trường Tên lựa chọn của chủ thể.

Các thuộc tính thư mục của chủ thể (Subject Directory Attributes):
 Trường này chuyển thêm các giá trị thuộc tính X.500 mà chủ thể mong
muốn (ngoài thông tin nhận dạng có trong các trường tên), chẳng hạn như vị trí của
chủ thể trong một tổ chức, số điện thoại hoặc địa chỉ thư.

Các trường mở rộng của nhóm (3) có thể giúp cho các tổ chức khác nhau
liên kết các cơ sở hạ tầng của họ với nhau. Khi CA chứng thực một CA khác, trong
chứng thư có thể có nhiều thông tin được sử dụng để chỉ báo cho người sử dụng
chứng thư biết các giới hạn về kiểu đường dẫn chứng thực xuất phát từ chứng thư
này. Các trường mở rộng này gồm:

(1)Các ràng buộc cơ bản (Basic Constraints): Trường này chỉ ra chủ thể
của chứng thư là một CA, hoặc chỉ là một thực thể cuối. Sự chỉ báo này rất
quan trọng, được sử dụng để ngăn chặn những người dùng cuối cạnh tranh
gian lận với các CA. Nếu chủ thể là một CA, có thể định rõ ràng buộc đối với
độ dài của đường dẫn chứng thực.

(2)Các ràng buộc đối với tên (Name Constranints): Trường này giới hạn
không gian tên có thể chấp nhận trong các chứng thư có trong một đường dẫn
chứng thực.

(3)Các ràng buộc đối với chính sách (Policy constraints): Trường này xác
định một tập hợp các ràng buộc cho việc nhận dạng chính sách chứng thư và
tham chiếu đến chính sách một cách tường minh

4.2.2. Danh sách chứng thư số bị thu hồi (CRL) và hồ sơ các trường mở
rộng của CRL

Các CLR có thể được sử dụng rộng rãi trong các ứng dụng và môi trường, bao
gồm một chuỗi các mục tiêu về tính tương hợp và thậm chí một chuỗi dài các yêu
cầu về hoạt động và sự bảo đảm. Hồ sơ này thiết lập một nền tảng cơ bản cho các
ứng dụng chung yêu cầu tính tương hợp rộng. Hồ sơ này xác định một bộ thông tin
có thể được tìm thấy trong mọi CLR. Hồ sơ này cũng quy định những vị trí phổ
biến trong CLR chứa các thuộc tính được sử dụng thường xuyên, cũng như các
biểu hiện phổ biến của các thuộc tính này.

Các tổ chức cấp CRL phát hành các CRL. Tổ chức cấp CRL có thể là tổ chức cấp
chứng thư khoá công khai (CA) hoặc một cơ quan được CA ủy quyền để cấp các
CRL.Các CA phát hành các CLR nhằm cung cấp các thông tin về tình trạng của
các chứng thư mà họ đã cấp. Tuy nhiên, CA có thể giao phó trách nhiệm này cho
một tổ chức khác.

Một CRL hoàn chỉnh sẽ bao gồm tất cả các chứng thư quá hạn trong phạm vi của
CRL đã bị thu hồi vì những lý do nêu trọng phạm vi của CRL đó. Một CRL đầy đủ
và hoàn chỉnh sẽ bao gồm tất cả các chứng thư quá hạn do CA cấp và đã bị thu hồi
vì bất kỳ lý do nào. (Lưu ý: Do các CA và các tổ chức cấp CRL được phân biệt
theo tên nên phạm vi của các CRL không bị ảnh hưởng bởi khóa sử dụng để ký
vào CRL hoặc các khóa được sử dụng để ký vào các chứng thư.)

Nếu phạm vi của CRL bao gồm một hoặc nhiều chứng thư do một tổ chức (không
phải là tổ chức cấp CRL) phát hành thì đó là một CRL gián tiếp . Phạm vi của một
CRL gián tiếp bị hạn chế bởi các chứng thư do một CA cấp hoặc có thể bao gồm
các chứng thư do nhiều CA cấp. Nếu tổ chức cấp CRL gián tiếp là một CA, phạm
vi của CRL có thể bao gồm các chứng thư do tổ chức cấp CRL phát hành.

Tổ chức cấp CRL cũng có thể tạo ra các CRL delta. Một CRL delta chỉ liệt kê
những chứng thư đã có trạng thái thu hồi thay đổi kể từ sau lần phát hành của CRL
tham chiếu hoàn chỉnh. CRL tham chiếu hoàn chỉnh thường được coi là CRL gốc.
Phạm vi của một CRL delta phải giống phạm vi của CRL gốc mà nó tham chiếu.

4.2.2.1 Các trường sử dụng trong CRL

Cấu trúc của CRL X.509 version 2 như sau. Đối với việc tính toán các chữ ký,
các dữ liệu chữ ký là ASN.1 DER đã được mã hóa. ASN.1 DER được mã hóa
là một hệ thống ký tự dài và mã hóa giá trị cho mỗi yếu tố.

CertificateList ::= SEQUENCE { tbsCertList

TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }

TBSCertList ::= SEQUENCE {

version Version OPTIONAL,

-- nếu hiện diện, phải là v2

 signature AlgorithmIdentifier,

issuer Name,

thisUpdate Time,

nextUpdate Time OPTIONAL,

revokedCertificates SEQUENCE OF SEQUENCE {

userCertificate CertificateSerialNumber,

revocationDate Time,

crlEntryExtensions Extensions OPTIONAL

-- nếu hiện diện, phải là v2

} OPTIONAL,

crlExtensions [0] EXPLICIT Extensions OPTIONAL

-- nếu hiện diện, phải là v2

-- Version, Time, CertificateSerialNumber, và AlgorithmIdentifier

4.2.2.2 Các trường trong CertificateList

CertificateList là một chuỗi tuần tự (SEQUENCE) gồm ba trường bắt buộc. Các
trường này được mô tả chi tiết dưới đây.

4.2.2.3 Trường Danh sách chứng thư được ký

(tbsCertList)

Trường đầu tiên trong chuỗi này là trường danh sách chứng thư được ký
(tbsCertList). Trường này là một chuỗi tuần tự có tên của tổ chức phát hành, ngày
phát hành, ngày phát hành danh sách tiếp theo, danh sách tùy chọn các chứng thư
bị thu hồi, và các phần mở rộng CRL tùy chọn. Khi không có chứng thư bị thu hồi
nào thì danh sách các chứng thư bị thu hồi không xuất hiện. Khi có một hoặc nhiều
chứng thư bị thu hồi, mỗi chứng thư bị thu hồi sẽ được xác định bởi một chuỗi
thông tin là số hiệu của chứng thư người dùng, ngày bị thu hồi, và các trường mở
rộng đầu mục CRL tùy chọn

4.2.2.4 Trường thuật toán chữ ký (signatureAlgorithm)

Trường thuật toán chữ ký xác định thuật toán mà tổ chức cấp CRL sử dụng để ký
CertificateList. Trường này là một loại nhận dạng thuật toán (AlgorithmIdentifier).
Những thuật toán chữ ký khác có thể cũng được hỗ trợ. Trường này phải dùng
cùng một thuật toán với trường Chữ ký trong chuỗi tbsCertList.

4.2.2.5 Trường giá trị chữ ký (signatureValue)

Trường giá trị chữ ký chứa một chữ ký số được tính toán từ tbsCertList đã được
mã hóa theo ASN.1 DER. tbsCertList mã hóa theo ASN.1 DER được sử dụng như
đầu vào cho chức năng ký. Giá trị chữ ký này được mã hóa như là một chuỗi bit và
được bao gồm trong trường signatureValue của CRL.

4.2.2.6 Trường trong tbsCertList

Danh sách chứng thư được ký TBSCertList là một chuỗi các trường tùy chọn và
bắt buộc. Các trường bắt buộc xác định tổ chức phát hành CRL, thuật toán được
sử dụng để ký CRL, ngày và thời gian phát hành CRL, ngày và thời gian sẽ phát
hành CRL tiếp theo.

4.2.2.7 Version (version)

Trường tùy chọn này mô tả phiên bản của CRL được mã hóa. Khi các trường mở
rộng được sử dụng trường này phải hiện diện và xác định phiên bản 2 (giá trị
nguyên là 1).

4.2.2.8 Chữ ký (signature)

Trường này chứa đựng nhận dạng thuật toán cho các thuật toán được sử dụng để
ký CRL. Thuật toán chứa trong trường này phải cùng nhận dạng thuật toán như
trường thuật toán chữ ký trong chuỗi CertificateList.

4.2.2.9 Tên tổ chức phát hành (Issuer Name)

Tên tổ chức phát hành xác định thực thể đã ký và phát hành CRL. Nhận dạng tổ
chức phát hành có trong trường tên tổ chức phát hành. Các loại tên thay thế có thể
xuất hiện trong trường mở rộng tên thay thế của tổ chức phát hành Trường tên tổ
chức phát hành phải bao gồm một tên X.500 phân biệt (DN). Trường tên tổ chức
phát hành được xác định theo dạng tên trong X.501., và phải tuân thủ các nguyên
tắc mã hóa của trường tên tổ chức phát hành.

4.2.2.10 Ngày phát hành CRL (thisUpdate)

Trường này chỉ ra ngày phát hành của CRL này. Ngày phát hành CRL có thể
được mã hóa như UTCTime hoặc GeneralizedTime.

4.2.2.11 Ngày phát hành CRL tiếp theo (nextUpdate)

Trường này chỉ ra ngày mà CRL tiếp theo sẽ được phát hành. CRL tiếp theo có thể
được phát hành trước thời gian đã chỉ định, nhưng không được phát hành chậm
hơn thời gian đã chỉ định này. Các tổ chức cấp CRL nên phát hành các CRL với
ngày phát hành CRL tiếp theo cùng lúc hoặc chậm hơn tất cả các CRL trước đó.
Ngày phát hành CRL tiếp theo có thể được mã hóa trong UTCTime hoặc
GeneralizedTime.

4.2.2.12 Các chứng thư bị thu hồi (revokedCertificates)

Khi không có các chứng thư bị thu hồi, danh sách các chứng thư bị thu hồi phải
không có mặt. Nói cách khác, các chứng thư bị thu hồi được liệt kê bởi các số hiệu
của chúng. Các chứng thư bị thu hồi bởi CA được xác định duy nhất bởi số hiệu
của chứng thư. Ngày thu hồi chứng thư phải được xác định. Thời gian thu hồi
chứng thư phải được thể hiện như đã mô tả trong Mục 5.1.2.4. Những thông tin bổ
sung có thể được cung cấp trong trường CRL mở rộng; Trường CRL mở rộng
được đề cập trong Mục 5.3.
 4.2.2.13 Các trường mở rộng (extensions)

Các trường này chỉ có thể xuất hiện nếu phiên bản là 2. Nếu xuất hiện, trường này
là một chuỗi của một hoặc nhiều trường mở rộng CRL.

4.2.3. Các trường CRL mở rộng

Khuôn dạng của CRL X.509 version 2 cũng cho phép các cộng đồng xác định các
trường mở rộng riêng để cung cấp thông tin cho các cộng đồng này. Mỗi trường
mở rộng trong một CRL có thể được xác định là quan trọng hoặc không quan
trọng. Nếu một CRL chứa một trường mở rộng quan trọng mà một ứng dụng
không thể xử lý, ứng dụng này không được phép sử dụng CRL đó để xác định tình
trạng của các chứng thư.

4.2.3.1 Trường nhận dạng khoá của tổ chức cấp chứng

thư (authority Key Identifier)

Trường mở rộng nhận dạng khoá của tổ chức cấp chứng thư cung cấp các công cụ
nhận dạng các khóa công khai đi kèm với các khóa bí mật (Private key) được sử
dụng để ký một CRL. Sự nhận dạng có thể dựa trên nhận dạng khóa (nhận dạng
khóa trong chứng thư của người ký CRL) hoặc tên của tổ chức cấp chứng thư và
số hiệu. Trường mở rộng này đặc biệt hữu ích khi tổ chức phát hành có từ hai chữ
ký trở lên do có nhiều cặp chữ ký trùng nhau hoặc do các thay đổi. Các tổ chức
cấp CRL phải sử dụng phương pháp nhận dạng khóa và phải bao gồm trường mở
rộng này trong tất cả các CRL được cấp ra.

4.2.3.2 Trường tên thay thế của tổ chức cấp chứng thư
(Issuer Alternative Name)

Trường tên thay thế của tổ chức cấp chứng thư cho phép tăng cường các đặc điểm
nhận dạng của tổ chức cấp CRL. Các tùy chọn bao gồm một địa chỉ thư điện tử
(rfc822Name), một tên DNS, một địa chỉ IP và một URI. Có thể có nhiều version
của một dạng tên và nhiều dạng tên. Khi các đặc điểm nhận dạng này được sử
dụng, trường tên thay thế của tổ chức cấp chứng thư phải được sử dụng; tuy nhiên,
một tên DNS có thể được thể hiện trong trường của tổ chức cấp chứng thư sử dụng
thuộc tính thành phần miền (domainComponent)
 4.2.3.3 Số hiệu của CRL (CRL number)

Số hiệu của CRL - một trường mở rộng không quan trọng – là một số theo thứ tự
tăng dần cho mỗi CRL và tổ chức cấp CRL. Trường mở rộng này cho phép người
sử dụng dễ dàng xác định khi một CRL cụ thể thay thế cho một CRL khác. Các
số hiệu của CRL cũng hỗ trợ việc nhận dạng các CRL và CRL delta bổ sung. Các
tổ chức cấp CRL theo tiêu chuẩn này cần bao gồm trường mở rộng này trong tất
cả các CRL và đánh dấu trường mở rộng này là không quan trọng.

4.2.3.4 Chỉ thị CRL delta (Delta CRL indicator)

Chỉ thị CRL delta là một trường CRL mở rộng quan trọng, nhận diện CRL như là
CRL delta. Các CRL delta chứa các cập nhật về thông tin thu hồi được đưa ra
trước đó thay vì tất cả các thông tin xuất hiện trong một CRL hoàn chỉnh. Việc sử
dụng các CRL detlta có thể giúp giảm đáng kể gánh nạng của mạng và thời gian
xử lý trong một số môi trường. CRL delta thường nhỏ hơn các CRL mà chúng cập
nhật, do vậy các ứng dụng có chứa CRL delta tiêu tốn ít độ rộng dải tần mạng hơn
các ứng dụng có chứa các CRL hoàn chỉnh tương ứng. Các ứng dụng có chứa
thông tin thu hồi trong một khuôn dạng thay vì trong một cấu trúc CRL có thể bổ
sung thêm thông tin thu hồi mới vào cở sở dữ liệu cục bộ mà không phải xử lý lại
thông tin.

Trường chỉ thị CRL delta bao gồm giá trị đơn của một loại số hiệu CRL gốc. Số
hiệu CRL giúp nhận dạng CRL hoàn chỉnh, trong một phạm vi nhất định, được sử
dụng như bước đầu trong việc tạo ra các CRL delta. Một tổ chức cấp CRL phải
phát hành CRL gốc tham chiếu như một CRL hoàn chỉnh. CRL delta bao gồm tất
cả các cập nhật về tình trạng thu hồi trong cùng một phạm vi. Sự kết hợp một CRL
delta và một CRL gốc tham chiếu tương đương với một CRL hoàn chỉnh trong
phạm vi có thể áp dụng được tại thời điểm phát hành CRL delta.

Một CRL hoàn chỉnh và một CRL delta có thể được kếp hợp nếu thỏa mãn 4 điều
kiện sau:

(a) CRL hoàn chỉnh và CRL delta do cùng một tổ chức cấp.

(b) CRL hoàn chỉnh và CRL delta có cùng một phạm vi. Cả hai CRL có
cùng một phạm vi nếu thỏa mãn một trong hai điều kiện sau:
 (1) Trường mở rộng điểm phân phối trong cả CRL hoàn chỉnh và
CRL delta bị bỏ qua.

(2) Trường mở rộng điểm phân phối CRL có mặt trong cả CRL hoàn
chỉnh và delta CRL và giá trị của mỗi trường là như nhau trong cả
hai CRL.

(c) Số hiệu của CRL hoàn chỉnh ngang bằng hoặc lớn hơn số hiệu của
CRL gốc trong CRL delta. Nghĩa là CRL hoàn chỉnh chứa (tối thiểu)
tất cả các thông tin thu hồi có trong CRL gốc dùng để tham chiếu.

(d) Số hiệu của CRL hoàn chỉnh nhỏ hơn số hiệu của CRL delta. Nghĩa là
CRL delta theo sau CRL hoàn chỉnh trong chuỗi số hiệu.

4.2.3.5 - Điểm phân phối phát hành

Điểm phân phối là một trường mở rộng quan trọng trong CRL giúp phân biệt điểm
phân phối CRL và phạm vi của một CRL cụ thể và cho thấy CRL chỉ thu hồi các
chứng thư Người dùng cuối/Thực thể cuối, chứng thư thuộc tính hoặc một bộ lý
do hạn chế hay không. Mặc dù trường này khá quan trọng, các hoạt động tương
ứng không bắt buộc phải hỗ trợ trường mở rộng này. Tuy nhiên, các hoạt dộng
không hỗ trợ trường mở rộng này phải coi hiện trạng của bất kỳ chứng thư nào
trong CRL này là không rõ hoặc chỉ ra CRL khác không chứa bất kỳ trường quan
trọng chưa được nhận dạng nào.

4.2.3.6 CRL mới nhất (a.k.a. Điểm phân phối CRL delta)

Trường mở rộng CRL mới nhất cho biết thông tin CRL delta cho CRL hoàn chỉnh
này được thu thập như thế nào. Các tổ chức cấp CRL phải đánh dấu trường này là
không quan trọng. Trường mở rộng này phải xuất hiện trong các CRL delta.
Trường mở rộng này sử dụng cùng một cấu trúc tương như trường mở rộng điểm
phân phối CRL. Tuy nhiên, trường điểm phân phối chỉ có ý nghĩa trong bối cảnh
này. Những trường lý do và tổ chức cấp chứng thư trong trường CRL mở rộng này
phải bị bỏ qua.
 4.2.3.7 Truy nhập thông tin của tổ chức cấp chứng thư
(Authority Information Access)

Trường CRL mở rộng này cũng phải được đánh dấu là không quan trọng. Khi hiện
diện trong một CRL, trường mở rộng này phải bao gồm ít nhất một mô tả truy
nhập quy định id-ad-caIssuers như một phương pháp truy nhập.

Nhận dạng chủ thể Id-ad-caIssuers được sử dụng khi thông tin có sẵn liệt kê các
chứng thư có thể được sử dụng nhằm xác minh chữ ký trong CRL (ví dụ, các
chứng thư có tên trùng khớp với tên của tổ chức cấp chứng thư trên CRL và có mã
khóa công khai tương ứng với mã khóa bí mật (Private key) được sử dụng để ký
vào CRL).

4.2.3.8 Các trường mở rộng đầu mục của CRL

Các trường mở rộng đầu mục của CRL được định nghĩa bởi ISO/IEC, ITU-T, và
ANSI X9 đối với CRL X.509 version 2 nhằm cung cấp các phương pháp để tích
hợp thêm các thuộc tính vào các đầu mục CRL [X.509] [X9.55]. Khuôn dạng
CRL X.509 version 2 cũng cho phép cộng đồng định nghĩa các đầu mục CRL
riêng nhằm cung cấp thông tin cho các cộng đồng đó. Mỗi trường mở rộng trong
một đầu mục CRL có thể được xem là quan trọng hoặc không quan trọng. Nếu
một CRL chứa một trường đầu mục CRL quan trọng mà các ứng dụng không thể
xử lý, thì các ứng dụng này không được sử dụng CRL để quyết định hiện trạng
của bất kỳ chứng thư nào. Tuy nhiên, các ứng dụng có thể bỏ qun các trường mở
rộng đầu mục CRL không quan trọng và không được nhận dạng.

4.2.3.9 Mã lý do thu hồi (reasonCode)

Mã lý do thu hồi là một trường mở rộng không quan trọng của đầu mục CRL, xác
định các lý do thu hồi chứng thư. Tổ chức cấp CRL được khuyến khích nêu các
mã lý do có ý nghĩa trong các đầu mục CRL; tuy nhiên, trường mở rộng mã lý do
thu hồi trong đầu mục CRL không nên xuất hiện thay vì sử dụng các giá trị mã lý
do không cụ thể (0).

Giá trị của mã lý do thu hồi removeFromCRL (8) có thể chỉ xuất hiện trong các
CRL delta và chỉ ra rằng chứng thư sẽ bị loại bỏ khỏi CRL do chứng thư đã quá
hạn hoặc không còn bị kiểm soát nữa. Tất cả các mã lý do có thể xuất hiện trong
bất kỳ CRL nào và chỉ ra rằng các chứng thư cụ thể nên được xem xét để thu hồi.

4.2.3.10 Thời gian hết hiệu lực

Thời gian hết hiệu lực là một trường mở rộng không quan trọng trong đầu mục
CRL, cho biết thời gian đã được biết rõ hoặc nghi rằng khóa bí mật (Private key)
được thỏa hiệp hoặc chứng thư hết hiệu lực. Thời gian này có thể sớm hơn so với
ngày thu hồi trong đầu mục CRL, ngày mà CA tiến hành thu hồi. Khi một lệnh thu
hồi được một tổ chức cấp CRL đưa ra lần đầu tiên trong một CRL, thời gian hết
hiệu lực có thể diễn ra trước ngày cấp các CRL trước đó. Khi có thông tin này, các
tổ chức cấp CRL nên thông báo tới người sử dụng CRL.

4.2.3.11 Tổ chức cấp chứng thư

Trường mở rộng đầu mục CRL này nhận dạng tổ chức phát hành chứng thư gắn
với một đầu mục trong một CRL gián tiếp, nghĩa là một CRL có chỉ thị CRL gián
tiếp đặt trong trường điểm phân phối CRL mở rộng. Khi hiện diện, tổ chức cấp
chứng thư trong trường mở rộng đầu mục CRL này bao gồm một hoặc nhiều tên
từ trường của tổ chức cấp CRL và/hoặc trường mở rộng tên thay thế của tổ chức
cấp CRL của chứng thư tương ứng với đầu mục CRL. Nếu trường mở rộng này
không hiện diện trong đầu mục đầu tiên của một CRL gián tiếp, tổ chức cấp chứng
thư được ngầm mặc định là tổ chức cấp CRL. Trong các đầu mục tiếp theo của
CRL gián tiếp, nếu trường mở rộng này không hiện diện, tổ chức cấp chứng thư
được mặc định là tổ chức cấp CRL. Trong các đầu mục tiếp theo của một CRL
gián tiếp, nếu trường mở rộng này không hiện diện, tổ chức cấp chứng thư cho đầu
mục này là tương tự như đầu mục có trước.

4.3. NHÓM CHUẨN VỀ GIAO THỨC HOẠT ĐỘNG

Nhóm chuẩn về giao thức hoạt động được quy định trong các tài liệu

- RFC 2585 – Internet X.509 Public Key Infrastructure Operational

Protocols: FTP and HTTP. 1999-05

- RFC 3494 - Internet X.509 Public Key Infrastructure Operational Protocols -

LDAPv2. 2003-03.
 - RFC 4387 - Internet X.509 Public Key Infrastructure Operational Protocols:
Certificate Store Access via HTTP. 2006-02.
Ở phần này sẽ tập trung nói chi tiết về RFC 2585 – Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP. 1999-05

4.3.1. RFC 2585 – Internet X.509 Public Key Infrastructure

Operational Protocols: FTP and HTTP

Đây là một của một tiêu chuẩn gồm nhiều phần của PKI thông qua việc sử dụng
sử dụng Chứng thư số X.509 và danh sách chứng thư bị thu hồi (các CRL). Tài liệu
này quy định cụ thể về các quy ước sử dụng FTP và HTTP nhằm có được chứng
thư và các CRL từ nguồn PKI. Các cơ chế bổ sung xử lý truy nhập nguồn được đặc
tả trong các tài liệu riêng biệt.

4.3.1.1 Mô hình

Sau đây là một góc nhìn đơn giản về mô hình kiến trúc sau đây được giả định
bởi các tham số kỹ thuật PKI mạng Internet.

Các thành phần trong mô hình gồm có:

- Thực thể cuối: người sử dụng chứng thư PKI  và / hoặc hệ thống người dùng

cuối là đối tượng của một chứng thư;

- CA: Tổ chức chứng nhận;

- RA: Tổ chức đăng ký cấp phát chứng thư, tức là một hệ thống tùy

chọn mà CA ủy thác cho một số tính năng quản lý;

- Nguồn: là một hệ thống hoặc tập hợp các hệ thống phân phối, nơi lưu
trữ các chứng thư, các CRL có vai trò là một phương tiện phân
phối các chứng thư cũng như các CRL này đến các thực thể cuối.
 4.3.1.2 Chứng thư và nguồn CRL

Một số CA chỉ thị việc sử dụng các dịch vụ chứng nhận trực tuyến, trong khi
những CA khác lại phân phối các CRL nhằm cho phép người sử dụng chứng thư tự
thực hiện việc phê duyệt chứng thư. Nói chung, các CA cung cấp các CRL cho
người dùng chứng thư thông qua việc công bố chúng trong Thư mục. Thư mục này
cũng là một cơ chế phân phối chứng thư thông thường. Tuy nhiên, ngày nay Dịch
vụ Thư mục không sẵn có tại nhiều phần trong mạng Internet.

Các thực thể cuối và các CA có thể có được các chứng thư và các CRL từ nguồn
sử dụng FTP hoặc HTTP. Các thực thể cuối có thể công bố các chứng thư của họ
trong nguồn sử dụng FTP hoặc HTTP, và các RA hoặc các CA mà có thể công bố
các chứng thư và CRL trong nguồn sử dụng FTP hoặc HTTP.

4.3.2. Quy ước FTP

Trong các mở rộng chứng thư và mở rộng CRL, dạng URI của GeneralName được
sử dụng để xác định vị trí có thể có được các chứng thư và CRL của người phát
hành. Ví dụ, một URI xác định đối tượng của một chứng thư có thể được thực
hiện trong phần mở rộng chứng thư SubjectAltName. Một IA5String mô tả việc
sử dụng FTP ẩn danh nhằm lấy chứng thư hoặc thông tin CRL. Chẳng hạn như:

ftp://ftp.netcom.com/sp/spyrus/housley.cer

ftp://ftp.your.org/pki/id48.cer

ftp://ftp.your.org/pki/id48.no42.crl

Người sử dụng mạng Internet có thể công bố tham chiếu URI vào một tập tin có
chứa các chứng thư của họ trên danh thiếp của họ. Điều này rất hữu ích khi không
có mục Thư mục nào cho người sử dụng đó. FTP được triển khai rộng rãi, và FTP
ẩn danh được điều tiết bởi các bức tường lửa.

Như vậy, FTP là một biện pháp thay thế hấp dẫn cho các giao thức truy cập thư
mục cho việc phân phối chứng thư và CRL. Trong khi dịch vụ này đáp ứng các yêu
cầu tìm kiếm các thông tin liên quan đến một chứng thư đã được xác định bởi một
URI, không nhằm mục đích đáp ứng các vấn đề chung hơn trong việc tìm một
chứng thư cho người dùng về một số thông tin khác đã biết, chẳng hạn như địa chỉ
thư điện tử của họ hoặc chi nhánh tập đoàn.

Để thuận tiện, tên của các tập tin có chứa các chứng thư cần phải có hậu tố ".Cer"
theo sau. Mỗi tập tin "cer" chứa chính xác một chứng thư, được mã hóa trong quy
tắc mã hóa khác biệt DER. Tương tự như vậy, tên của các tập tin có chứa các CRL
cần phải có hậu tố ".Crl". Mỗi tập tin "Crl" chứa chính xác một CRL, được mã hóa
trong định dạng DER.

4.3.3. Quy ước HTTP

Trong các mở rộng chứng thư và mở rộng CRL, dạng URI của GeneralName được
sử dụng để xác định vị trí có thể có được các chwungs thư và CRL của người phát
hành. Ví dụ, một URI xác định đối tượng của một chứng thư có thể được thực hiện
trong mở rộng chứng thư subjectAltName. Chẳng hạn như:

http://www.netcom.com/sp/spyrus/housley.cer

http://www.your.org/pki/id4 8.cer

http://www.your.org/pki/id4 8.no42.crl

Người sử dụng mạng Internet có thể công bố tham chiếu URI vào một tập tin có
chứa các chứng thư của họ trên danh thiếp của họ. Điều này rất hữu ích khi khong
có mục Thư mục nào cho người sử dụng đó. FTP được triển khai rộng rãi, và FTP
ẩn danh được điều tiết bởi các bức tường lửa.

Như vậy, FTP là một biện pháp thay thế hấp dẫn cho các giao thức truy cập thư
mục cho việc phân phối chứng thư và CRL. Trong khi dịch vụ này đáp ứng các yêu
cầu tìm kiếm các thông tin liên quan đến một chứng thư đã được xác định bởi một
URI, không nhằm mục đích đáp ứng các vấn đề chung hơn trong việc tìm một
chứng thư cho người dùng về một số thông tin khác đã biết, chẳng hạn như địa chỉ
thư điện tử của họ hoặc chi nhánh tập đoàn.

Để thuận tiện, tên của các tập tin có chứa các chứng thư cần phải có hậu tố ".Cer"
theo sau. Mỗi tập tin "cer" chứa chính xác một chứng thư, được mã hóa trong định
dạng DER. Tương tự như vậy, tên của các tập tin có chứa các CRL cần phải có hậu
tố ".Crl". Mỗi tập tin "Crl" chứa chính xác một CRL, được mã hóa trong định dạng
DER.

4.3.4. Đăng ký MIME

Hai loại MIME được định nghĩa để hỗ trợ việc chuyển các chứng thư và các CRL.
Đó là:
application / pkix-CERT

application / pkix-crl

 Application/ pkix-cert

Tới: ietf-types@iana.org

Tiêu đề: Đăng ký ứng dụng loại phương tiện MIME  /pkix-cert

Tên loại phương tiện MIME: ứng dụng

Tên loại con MIME: pkix-CERT

Các tham số được yêu cầu: Không có

Các tham số tùy chọn: phiên bản (giá trị mặc định là "1")

Chú ý mã hóa: sẽ là không cho các truyền tải 8 bit và có khả năng là Base64 cho
SMTP hoặc các truyền tải 7 bit khác.

Chú ý bảo mật: thực hiện một chứng thư mật mã

Chú ý khả năng tương tác: Không có

Đặc điểm đã công bố: draft-ietf-pkix-ipki-part1

Ứng dụng sử dụng loại phương tiện này: bất kỳ truyền tải khiếu nại MIME nào.

Thông tin bổ sung:

Số kỳ ảo:  không

Mở rộng tập tin: .CER 

Mã loại tập tin Macintosh : không có

Người & địa chỉ email để biết thêm thông tin:

Russ Housley <housley@spyrus.com>

Dự kiến sử dụng: THÔNG THƯỜNG

Người thực thi / Người kiểm soát thay đổi:

Russ Housley <housley@spyrus.com>

 Ứng dụng / pkix-crl

Tới:ietf-types@iana.org

Tiêu đề: Đăng ký ứng dụng loại phương tiện MIME  /pkix-crl

Tên loại phương tiện MIME: ứng dụng

Tên loại con MIME: pkix-crl

Các tham số được yêu cầu: Không có

Các tham số tùy chọn: phiên bản (giá trị mặc định là "1")

Chú ý mã hóa: sẽ là không cho các truyền tải 8 bit và có khả năng là Base64 cho
SMTP hoặc các truyền tải 7 bit khác.

Chú ý bảo mật: thực hiện một danh sách hủy bỏ chứng thư mật mã

Chú ý khả năng tương tác: Không có

Đặc điểm đã công bố: draft-ietf-pkix-ipki-part1

Ứng dụng sử dụng loại phương tiện này: bất kỳ truyền tải khiếu nại MIME nào.

Thông tin bổ sung:

Số kỳ ảo:  không

Mở rộng tập tin: .CRL 

Mã loại tập tin Macintosh : không có

Người & địa chỉ email để biết thêm thông tin:

Russ Housley <housley@spyrus.com>

Dự kiến sử dụng: THÔNG THƯỜNG

Người thực thi / Người kiểm soát thay đổi:

Russ Housley <housley@spyrus.com>
4.4. NHÓM CHUẨN VỀ GIAO THỨC QUẢN LÝ

Các giao thức quản lý hỗ trợ việc truyền các yêu cầu và thông tin quản lý giữa các
thực thể cuối với các thực thể quản lý và truyền thông giữa các thực thể quản lý.
Giao thức có thể chuyên chở các yêu cầu và các đáp ứng tương ứng trong việc
đăng ký, các thông tin trạng thái. Giao thức quản lý cũng định nghĩa các khuôn
dạng thông điệp, nội dung thông tin trong thông điệp được gửi và nhận giữa các
thực thể quản lý và thực thể cuối.

- RFC 4210 - Internet X.509 Public Key Infrastructure Certificate

Management Protocol (CMP). 2005-09.

- RFC 4211 - Internet X.509 Public Key Infrastructure Certificate

Request Message Format (CRMF). 2005-09.

- RFC 5272 - Certificate Management over CMS (CMC). 2008-06.

CMP và CMC được trình bày ở phần trên nên phần này giới thiệu RFC 4211 -
Internet X.509 Public Key Infrastructure Certificate Request Message Format
(CRMF).

4.4.1. Giới thiệu Internet X.509 Public Key Infrastructure Certificate

Request Message Format (CRMF)

Tài liệu này miêu tả định dạng thông điệp yêu cầu chứng thư số (Certificate
Request Message Format – CRMF). Một đối tượng thông điệp yêu cầu chứng thư
số (Certificate Request Message) được dùng trong một giao thức truyền tải yêu cầu
xin cấp chứng thư số tới CA, có thể thông qua RA cho mục đích xin chứng thư số
X.509. Thông thường yêu cầu này bao gồm khóa công khai và các thông tin đăng
ký liên quan.

Các đối tượng yêu cầu chứng thư số trong tài liệu này không phải là một giao thức
độc lập. các thông tin được quy định trong tài liệu này cũng được thiết kế để sử
dụng được giao thức yêu cầu chứng thư số (Certificate Request Protocol – CRP)

4.4.2. Tổng quan

Xây dụng một yêu cầu chứng thư số gồm các bước sau

- Xây dụng một đối tượng CerRequest. Đối tượng này có thể là khóa công
khai, toàn bộ hoặc một phần tên chủ thể (Subject name), các trường yêu cầu
chứng thư số khác và các thông tin điều khiển bổ sung liên quan đến quá
trình đăng ký.
- Trong trường hợp cần thiết, sự chứng minh tính sở hữu (Proof of Possession
– POP)của khóa bí mật tương ứng với khóa công khai của chứng thư số sẽ
được sử dụng
- Thông tin đăng ký bổ sung có thể được kết hợp với giá trị của POP và cấu
trúc CertR equest từ định dạng của một CerReqMessage và được thêm vào
bởi cả chủ thể và RA.
- CertReqMessage được truyền an toàn tới CA qua các phương tiện truyền
thông an toàn và được xác định cụ thể bởi mỗi CRP

4.4.3. Cấu trúc CertReqMessage

Thông điệp yêu cầu chứng thư số bao gồm yêu cầu chứng thư số, trường POP tùy
chọn và trường thông tin đăng ký tùy chọn

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {

certReq CertRequest,

popo ProofOfPossession OPTIONAL,

regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL

4.4.4. Chứng minh tính sở hữu (Proof of Possesion – POP)

Để ngăn chặn một cuộc tấn công nhất định và cho phép CA/RA kiểm tra tính hợp
lệ của các ràng buộc giữa chủ thể và cặp khóa, cấu trúc quản lý PKI quy định một
chủ thể phải chứng minh được tính sở hữu của mình đối với khóa bí mật tương ứng
với khóa công khai trong yêu cầu xin cấp chứng thư số. Đối với một CRP, CA và
RA được tự do lựa chọn các phương pháp POP. Một CRP cần phải xác định
phương pháp POP nào được yêu cầu, hay cơ chế nào cho client để tìm thấy các
phương pháp POP được hỗ trợ.

ProofOfPossession ::= CHOICE {

raVerified [0] NULL,

signature [1] POPOSigningKey,

keyEncipherment [2] POPOPrivKey,

keyAgreement [3] POPOPrivKey }

4.4.5. Cú pháp CertReq

Cú pháp CertReq bao gồm định danh yêu cầu, nội dung chứng thư số mẫu và chuỗi
tùy chọn của thông tin điều khiển:

CertRequest ::= SEQUENCE {

certReqId INTEGER,

certTemplate CertTemplate,

controls Controls OPTIONAL }

CertTemplate ::= SEQUENCE {

version [0] Version OPTIONAL,

serialNumber [1] INTEGER OPTIONAL,

signingAlg [2] AlgorithmIdentifier OPTIONAL,

issuer [3] Name OPTIONAL,

validity [4] OptionalValidity OPTIONAL,

subject [5] Name OPTIONAL,

publicKey [6] SubjectPublicKeyInfo OPTIONAL,

issuerUID [7] UniqueIdentifier OPTIONAL,

 subjectUID [8] UniqueIdentifier OPTIONAL,

extensions [9] Extensions OPTIONAL }

OptionalValidity ::= SEQUENCE {

notBefore [0] Time OPTIONAL,

notAfter [1] Time OPTIONAL }

Time ::= CHOICE {

utcTime UTCTime,

generalTime GeneralizedTime }

4.4.6. Cú pháp thuộc tính kiểm soát (Controls syntax)

CertRequest bao gồm một hoặc nhiều giá trị thuộc tính kiểm soát liên quan tới việc
xử lý yêu cầu.

Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

4.4.6.1 Kiểm soát thẻ đăng ký (Registration Token

Control)

Kiểm soát regToken bao gồm thông tin one-time (hoặc dựa trên giá trị an toàn
hoặc thông tin chia sẻ) dự định để CA xác thực định danh của chủ thể trước cho
việc cấp phát chứng thư số. Sau khi nhận được yêu cầu có chứa giá trị cho
regToken, CA phía bên nhận chứng minh các thông tin đó để xác thực định danh
được nêu ra trong yêu cầu chứng thư số. Trong trường hợp được sử dụng, giá trị
cho regToken có thể là chuỗi ký tự hoặc một giá trị ngẫu nhiên, giá trị của này
được mã hóa như chuỗi ký tự đại diện cho giá trị nhị phân. Việc mã hóa regToken
nên dùng chuỗi UTF8String

id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }

 4.4.6.2 Kiểm soát xác thực (Authenticator Control)

Kiểm soát xác thực gồm có thông tin sử dụng liên tục cho việc thiết lập kiểm tra
định danh không được mã hóa trong liên lạc với CA . Ví dụ: Tên thời con gái của
mẹ (mother’s maiden name), bốn số cuối của an sinh xã hội, hoặc các thông tin cơ
bản được chia sẻ với CA của thuê báo, hàm băm các thông tin như vậy hoặc các
thông tin được sinh ra cho mục đích đó. Các giá trị cho kiểm soát xác thực được
thuê bao hoặc CA sinh ra.

Trong trường hợp được sử dụng, giá trị cho việc xác thực có thể là chuỗi ký tự
hoặc một giá trị ngẫu nhiên, giá trị của trường hợp này được mã hóa như chuỗi ký
tự đại diện cho giá trị nhị phân. Việc mã hóa xác thực nên dùng chuỗi UTF8String

id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }

4.4.6.3 Kiểm soát thông tin công khai (Publication

Information Control)

Kiểm soát pkiPublicationInfo cho phép thuê báo tác động đến việc công bố công
khai chứng thư số của CA và RA. Tuy nhiên chỉ mang tính chất tham khảo và có
thể bị CA và RA bỏ qua. Kiểm soát này được xác định bằng OID và cú pháp sau:

id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }

PKIPublicationInfo ::= SEQUENCE {

action INTEGER {

dontPublish (0),

pleasePublish (1) },

pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }

SinglePubInfo ::= SEQUENCE {

pubMethod INTEGER {
 dontCare (0),

x500 (1),

web (2),

ldap (3) },

pubLocation GeneralName OPTIONAL }

4.4.6.4 Kiểm soát tùy chọn lưu trữ (Archive Options

Control)

Tùy chọn pkiArchiveOptions cho phép thuê báo được hỗ trợ thông tin cần thiết lập
để lưu trữ khóa bí mật tương ứng với khóa công khai của yêu cầu chứng thư
số.OID và cú pháp của Archive Options Control như sau:

id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }

PKIArchiveOptions ::= CHOICE {

encryptedPrivKey [0] EncryptedKey,

keyGenParameters [1] KeyGenParameters,

archiveRemGenPrivKey [2] BOOLEAN }

EncryptedKey ::= CHOICE {

encryptedValue EncryptedValue, -- deprecated

envelopedData [0] EnvelopedData }

EncryptedValue ::= SEQUENCE {

intendedAlg [0] AlgorithmIdentifier OPTIONAL,

symmAlg [1] AlgorithmIdentifier OPTIONAL,

encSymmKey [2] BIT STRING OPTIONAL,

keyAlg [3] AlgorithmIdentifier OPTIONAL,

 valueHint [4] OCTET STRING OPTIONAL,

encValue BIT STRING }

KeyGenParameters ::= OCTET STRING

4.4.6.5 Kiểm soát OldCert ID

OldCertID xác định chứng thư số được cập nhật bởi yêu cầu chứng thư hiện tại.
OID và cú pháp của kiểm soát này là:

id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }

CertId ::= SEQUENCE {

issuer GeneralName,

serialNumber INTEGER

4.4.6.6 Kiểm soát khóa mã hóa giao thức (Protocol

Encryption Key Control)

Kiểm soát protocolEncryKey xác định một khóa mà CA sử dụng để mã hóa phản
hồi tới CertReqMessage. OID cho kiểm soát này là id-regCtrl-protocolEncrKey.
Cấu trúc tham số cho trường này là SubjectPublicKeyInfo

id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }

Kiểm soát này được sử dụng khi CA có thông tin cần được mã hóa gửi tới thuê
bao. Thông tin này có thể gồm khóa bí mật được sinh ra bởi CA sử dụng cho thuê
bao.

4.4.7. Kiểm soát RegInfo (RegInfo Controls)

Phần này miêu tả trường regInfo trong cấu trúc CertReqMsg

4.4.7.1 utf8Pairs

Kiểm soát này được dùng để truyền tải thông tin ký tự (text-based information) từ
chủ thể tới RA tới CA cấp phát chứng thư số. OID cho cấu trúc id-regInfo-
utf8Pairs và có kiểu UTF8String.

id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }

sau tên Name là dấu hỏi chấm (?), và sau giá trị là dấu phần trăm (%). Cặp giá trị
tên có thể được lặp lại. do vậy cú pháp như sau:

Name?Value%[Name?Value%]*

4.4.7.2 certReq

Phần này này được thiết kế để giải quyết vấn đề khi RA cần thay đổi mẫu chứng
thư số mà chủ thể đề xuất, nhưng chủ thể sử dụng mẫu chứng thư số như một phần
của kết quả tính toán POP. Trong trường này, RA có thể chỉ ra vị trí của một mẫu
chứng thư số mới trong chỗi regInfo.

Phần này có một OID id-regInfo-certReq và cấu trúc CerRequest, và thuộc tính
này chỉ nhìn thấy trong chuỗi regInfo. Nếu certReq tổn tài trong cấu trúc regInfo,
thì mẫu chứng thư số trong yêu cầu sẽ bị bỏ qua. Cơ quan đăng ký RA bắt buộc
phải sao chép toàn bộ dữ liệu từ mẫu gốc tới thuộc tính này.

id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }

4.4.8. Object Identifiers

OID id-pkix có giá trị:

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)

dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

-- arc cho giao thức PKI X509 và các thành phần

id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }

 -- arc cho kiểm soát đăng ký (Registration Controls) trong CRMF

id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }

-- arc cho thông tin đăng ký (Registration Info) trong CRMF

id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }

4.5. NHÓM CHUẨN VỀ CHÍNH SÁCH

Quy định 2 loại chính sách CP và CPS được mô tả trong tài liệu RFC 3647 –
Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework 2003-11.

Hạ tầng khóa công khai chỉ an toàn khi các chính sách và thủ tục được thực thi
bởi tổ chức quản lý hạ tầng đó. Chính sách là một tài liệu chứa tập các quy tắc
hoặc quy định cụ thể và duy trì một cấu trúc với các thủ tục buộc phải tuân thủ.

Với mỗi hạ tầng khóa công khai có 3 loại chính sách ảnh hưởng trực tiếp:

- Chính sách an toàn (Security Policy): là một tài liệu mô tả các chuẩn của
một tổ chức có liên quan đến an toàn.
- Chính sách chứng thư.
- Quy chế chứng thực.

Mối quan hệ giữa các chính sách:

- Một tổ chức xây dựng chính sách an toàn để định nghĩa chuẩn an toàn
cho tổ chức đó.
- Chính sách chứng thư được phác thảo tuân thủ và phản ánh chính sách an
toàn của tổ chức đó.
- Quy chế chứng thực định nghĩa các thủ tục quản lý CA tuân thủ chính
sách chứng thư.
 Hình 4-3: Mối quan hệ giữa các chính sách

4.5.1. Chính sách chứng thư.

4.5.1.1 Khái niệm

Chính sách chứng thư (Certificate Policy): là một tài liệu mô tả các biện
pháp mà một tổ chức chứng thực sẽ sử dụng để kiểm tra danh tính của chủ thể
chứng thư trước khi phát hành chứng thư và mục đích dự kiến của một chứng thư.

Chính sách chứng thư (Certificate Policy - CP): là một tập các quy tắc xác
định khả năng áp dụng của chứng thư cho một lĩnh vực nhất định hay cho một lớp
các ứng dụng với các yêu cầu bảo mật chung.

Về mặt bản chất CP là một tài liệu mô tả (xác định) các yêu cầu cho các bên
tham gia trong một miền PKI và xác định những gì các bên tham gia đó phải thực
hiện.

Chính sách được biểu diễn trong chứng thư số bằng một giá trị định danh đối
tượng – OID kèm theo một con trỏ tới vị trí mô tả chính sách, trong trường
Certificate Policies Extension. Mỗi chứng thư có thể được phát hành với một hay
nhiều chính sách khác nhau.

4.5.1.2 Sự cần thiết của chính sách chứng thư

- Chính sách chứng thư cung cấp mức tin cậy xác định cho relying party quyết
định có sử dụng chứng thư số hay không trong trường hợp cụ thể.
- Chính sách chứng thư cũng là cơ sở cho hoạt động kiểm toán.
- Xây dựng dựng lòng tin hay đánh giá về một CA.

4.5.1.3 Phân loại chính sách chứng thư

Có hai loại chính sách chứng thư:

- Loại thứ nhất xác định khả năng áp dụng của chứng thư đối với một cộng
đồng, khu vực nhất định. Loại chính sách này quy định trước các yêu cầu về
việc sử dụng chứng thư và các yêu cầu về các thành viên của cộng đồng.

Ví dụ:

- Yêu cầu về sử dụng chứng thư: ký, mã, xác thực…

- Yêu cầu về thành viên: áp dụng cho một cộng đồng cùng chung một vùng
địa lý (quốc gia), hoặc chính sách áp dụng cho các thành viên thực hiện
dịch vụ tài chính.
- Loại thứ hai xác định khả năng áp dụng của chứng thư đối với một lớp các
ứng dụng với các mức yêu cầu bảo mật nhất định.
- Loại chính sách này xác định trước một tập các ứng dụng hoặc mục đích
(khả năng) sử dụng của chứng thư cần có một mức an toàn xác định. Sau
đó xác định các yêu cầu phù hợp với ứng dụng hay mục đích sử dụng đó.
CP thuộc
- loại này thường đưa ra tập các yêu cầu phù hợp với mức an toàn nhất
định được cung cấp bởi chứng thư (lớp, loại).
- Ví dụ chính sách xác định các mức an toàn cho chứng thư số từ thấp đến
cao kèm theo các yêu cầu cụ thể cho từng mức (rudimentary, basic,
medium, or high).

4.5.1.4 Nội dung của chính sách chứng thư

Nội dung cơ bản của CP gồm:

- Cách kiểm tra định danh (danh tính) người dùng trong quá trình đăng ký:
form mẫu điền thông tin, gặp trực tiếp hay không, cách xác thực thông tin…
- Mục đích dự kiến của chứng thư: xác thực, ký số (giá trị ?)
- Yêu cầu của thiết bị lưu khóa bí mật: HSM hay file, phương thức bảo vệ truy
nhập tới khóa…
 - Trách nhiệm của chủ thể sở hữu khóa bí mật khi khóa bí mật bị lộ hay mất:
có lưu khóa bí mật của người dùng?.
- Trách nhiệm, chính sách, thủ tục thu hồi chứng thư: Trường hợp thu hồi, quy
trình, mẫu biểu.

4.5.2. Quy chế chứng thực.

4.5.2.1 Khái niệm

Quy chế chứng thực (Certification Practice Statement): là một tài liệu mô tả
các biện pháp đảm bảo an toàn cho hoạt động của CA và quản lý các chứng thư đã
phát hành của CA đó.

Quy chế chứng thực (Certification Practice Statement - CPS): là bản tuyên
bố chi tiết của thẩm quyền chứng thực (CA) về sự tin cậy trong hệ thống của nó và
các quy trình hoạt động của CA và quản lý chứng thư (tạo, phát hành, thu hồi …)

Quy chế chứng thực: định nghĩa các biện pháp được thực hiện để đảm bảo
an toàn cho vận hành CA, quản lý các chứng thư đã phát hành.

Về bản chất CPS là một tài liệu định nghĩa cách thức các bên tham gia thực
hiện chức năng của mình. Nó cũng được xem như là một bản giao ước giữa tổ
chức quản lý CA và người dùng tin vào các chứng thư được phát hành bởi CA đó.

4.5.2.2 Sự cần thiết của quy chế chứng thực

- Quy chế chứng thực cung cấp mức tin cậy xác định cho relying party quyết
định có sử dụng chứng thư số hay không trong trường hợp cụ thể.
- Vì quy chế chứng thực bản chất là tài liệu chỉ ra các biện pháp thực hiện yêu
cầu của chính sách chứng thư, mỗi tổ chức chứng thực khác nhau thì lại có
các biện pháp thực hiện khác nhau do đó CPS thường được viết dùng riêng
cho mỗi tổ chức nên đây chính là cơ sở để so sánh độ tin cậy giữa chứng thư
của các tổ chứng chứng thực khác nhau.
- Dựa vào CPS có thể đưa ra đánh giá chính xác hơn về độ tin cậy của CA so
với dựa vào CP vì CP có thể được viết ra và dùng được cho nhiều miền PKI,
CA khác nhau.
 4.5.2.3 Nội dung của quy chế chứng thực

Nội dung quy chế chứng thực gồm:

- Một danh sách các CP mà nó hỗ trợ.

- Với mỗi CP mà nó hỗ trợ, một tập các điều khoản được thiết lập chứa các
quy trình tương ứng nhằm chỉ ra cách CPS này thực hiện các yêu cầu
trong mỗi CP.
- Một tập các quy định chứa quy trình liên quan đến vận hành CA không
liên quan đến CP.

4.5.3. Mối quan hệ giữa chính sách chứng thư và quy chế chứng thực.

Sự giống nhau:

- CP và CPS đều giải quyết các chủ đề về mối quan tâm của RP (relying
party) đến cấp độ an toàn và mục tiêu của chứng thư số có nên tin cậy
hay không.
- CP và CPS đều do tổ chức vận hành CA ban hành.

Sự khác nhau:

- Điểm khác biệt thứ nhất là mục đích tài liệu: Mục đích của CP là xác
định các bên tham gia cần phải thực hiện điều gì. Mục đích của CPS là
chỉ ra cách các bên tham gia thực hiện chức năng và thi hành quyền của
mình như thế nào.
- Điểm khác biệt thứ hai là phạm vi của hai loại tài liệu: CP chỉ xác định
các yêu cầu và chuẩn nên nó có thể được coi như một hướng dẫn hoạt
động và thích hợp, áp dụng được với nhiều miền PKI, tổ chức, CA khác
nhau. CPS xác định cách thức thực hiện của các bên tham gia nên nó chỉ
áp dụng được với một miền PKI, tổ chức, CA cụ thể.
- Điểm khác biệt thứ ba là mức chi tiết của các điều khoản: CPS chỉ ra
cách thức thực hiện còn CP chỉ ra các yêu cầu nên CPS thường chi tiết
hơn CP.

4.6. NHÓM CHUẨN VỀ DẤU THỜI GIAN VÀ CHỨNG THỰC DỮ LIỆU

Các dịch vụ dấu thời gian và chứng thực dữ liệu được xây dựng bên trên các dịch
vụ cơ bản của PKI. Dịch vụ chứng thực dữ liệu kiểm tra tính chính xác của dữ liệu
gửi tới nó. Dịch vụ này gần giống như dịch vụ công chứng.

- RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp

Protocol (TSP). 2001-08

- RFC 3628 - Policy Requirements for Time-Stamping Authorities

(TSAs). 2003-11.

- RFC 5816 - ESSCertIDv2 Update for RFC 3161. 2010-04.

Phần này sẽ trình bày về Policy Requirements for Time-Stamping Authorities

(TSAs) cụ thể như sau:

Tài liệu này quy định các yêu cầu về một chính sách gán nhãn thời gian cơ bản
cho TSA phát hành mã xác thực nhãn thời gian, được hỗ trợ bằng các giấy chứng
nhận khóa công khai, với độ chính xác tới một giây hoặc hơn. Một TSA có thể quy
định chính sách riêng của mình, giúp tăng cường chính sách được quy định trong
tài liệu này. Chính sách này sẽ được kết hợp hoặc củng cố thêm cho các yêu cầu
được quy định trong tài liệu này.

4.6.1. Giới thiệu

Để tạo ra bằng chứng số đáng tin cậy và có thể quản lý, cần thiết phải thoả thuận
phương pháp liên kết dữ liệu thời gian và giao dịch để có thể so sánh với nhau về
sau. Chất lượng của bằng chứng này được dựa trên việc tạo ra và quản lý cấu trúc
dữ liệu đại diện cho các sự kiện và chất lượng của các điểm dữ liệu tham số neo
chúng vào thế giới thực. Trong trường hợp này đây là các dữ liệu thời gian và cách
nó được áp dụng.

Một giao dịch điển hình là một tài liệu kỹ thuật số đã ký, mà cần thiết để chứng
minh rằng chữ ký số của người ký được áp dụng khi chứng nhận cho người ký là
hợp lệ.

Nhãn thời gian hoặc đánh dấu thời gian (đó là một hồ sơ kiểm tra được lưu giữ
trong một biên bản kiểm tra an toàn từ một bên thứ ba đáng tin cậy) được áp dụng
đối với giá trị chữ ký số, chứng tỏ rằng chữ ký số được tạo ra trước ngày in trong
nhãn thời gian và dấu thời gian.

Để chứng tỏ chữ ký số được tạo ra khi Giấy chứng nhận của người ký là hợp lệ,
chữ ký số phải được kiểm tra, thẩm định và thỏa mãn các điều kiện sau đây:

Nhãn thời gian (hoặc dấu thời gian) được áp dụng trước khi kết thúc hiệu lực giấy
chứng nhận của người ký.

Nhãn thời gian (hoặc dấu thời gian) được áp dụng hoặc khi Giấy chứng nhận của
người ký không bị thu hồi hoặc trước ngày thu hồi giấy chứng nhận.

Vì vậy, một nhãn thời gian (hoặc dấu thời gian) được áp dụng theo cách này chứng
tỏ rằng chữ ký số được tạo ra khi giấy chứng nhận của người ký là hợp lệ. Điều
này chứng tỏ tính hợp lệ của một chữ ký số trong toàn bộ bất kể chuỗi chứng nhận
nào.

   Căn cứ vào mục đích của các tài liệu, những chữ viết tắt sau được áp dụng:

- TSA Cơ quan gắn nhãn thời gian

- TSU Đơn vị gắn nhãn thời gian
- TST Mật mã nhãn thời gian
- UTC Thời gian phối hợp quốc tế

4.6.2. Khái niệm chung

4.6.2.1 Các dịch vụ gắn nhãn thời gian

Việc cung cấp dịch vụ gắn nhãn thời gian được chia thành các thành phần dịch vụ
nhằm đáp ứng các yêu cầu phân loại:

- Cung cấp dịch vụ gắn nhãn thời gian: dịch vụ này tạo ra mật mã nhãn thời
gian.
- Quản lý gắn nhãn thời gian: Các thành phần dịch vụ điều hành và kiểm soát
hoạt động của các dịch vụ gắn nhãn thời gian để đảm bảo rằng dịch vụ này
được cung cấp theo quy định của TSA. Thành phần dịch vụ này chịu trách
nhiệm cài đặt và giảm cài đặt việc cung cấp dịch vụ gắn nhãn thời gian.
 4.6.2.2 Cơ quan gắn nhãn thời gian

Cơ quan cấp mật mã nhãn thời gian, được ủy thác bởi những người sử dụng các
dịch vụ tem thời gian, tức là, thuê bao và các bên tin tưởng, được gọi là Cơ quan
gắn nhãn thời gian (TSA). TSA có trách nhiệm tổng thể về các dịch vụ nhãn thời
gian được quy định tại mục 4.1. TSA có trách nhiệm với các hoạt động của một
hoặc nhiều TSU, tạo ra và ký thay mặt TSA. TSA chịu trách nhiệm cấp mật mã
nhãn thời gian có thể nhận dạng được

TSA có thể sử dụng các bên khác để cung cấp các dịch vụ gắn nhãn thời gian. Tuy
nhiên, TSA luôn luôn duy trì chịu trách nhiệm tổng thể và đảm bảo rằng các yêu
cầu chính sách được quy định trong tài liệu này được đáp ứng. Ví dụ, một TSA có
thể lập hợp đồng phụ cho tất cả các dịch vụ thành phần, bao gồm cả các dịch vụ tạo
ra mật mã nhãn thời gian sử dụng khóa của TSU. Tuy nhiên, khóa và các khóa bí
mật (private key) được sử dụng để tạo ra mật mã nhãn thời gian thuộc TSA, duy trì
trách nhiệm tổng thể, đáp ứng các yêu cầu trong tài liệu này.

TSA có thể điều hành hoạt động của một số đơn vị gắn nhãn thời gian có thể nhận
dạng được. Mỗi đơn vị có một khóa khác nhau.

4.6.2.3 Thuê bao

Thuê bao có thể là một tổ chức, bao gồm một số người sử dụng cuối cùng hoặc cá
nhân người sử dụng cuối.

Khi thuê bao là một tổ chức, một số nghĩa vụ mà áp dụng đối với tổ chức đó cũng
sẽ được áp dụng cho người sử dụng cuối cùng. Trong mọi trường hợp tổ chức đó
sẽ phải chịu trách nhiệm nếu những nghĩa vụ của người sử dụng không được thực
thi chính xác và vì thế tổ chức đó phải thông báo cụ thể tới người sử dụng cuối
cùng .

Khi thuê bao là người sử dụng cuối cùng, họ sẽ chịu trách nhiệm trực tiếp nếu các
nghĩa vụ không được hoàn thành đầy đủ.
 4.6.2.4 4.4. Chính sách gắn nhãn thời gian và nội dung
nghiệp vụ TSA

Phần này giải thích vai trò tương đối của các chính sách gắn nhãn thời gian và nội
dung nghiệp vụ TSA. Nó không hạn chế về hình thức của một chính sách gắn nhãn
thời gian hoặc quy chuẩn nội dung nghiệp vụ.

Nói chung, chính sách gắn nhãn thời gian nêu "những điều phải được tôn trọng,"
trong khi nội dung nghiệp vụ TSA nêu "làm thế nào để được tôn trọng", tức là các
quá trình nó sẽ sử dụng trong việc tạo ra nhãn thời gian và duy trì tính chính xác
của đồng hồ gắn nhãn thời gian. Mối quan hệ giữa chính sách gắn nhãn thời gian
và nội dung nghiệp vụ TSA về bản chất là tương tự như mối quan hệ của các
chính sách kinh doanh khác, trong đó nêu các yêu cầu của doanh nghiệp, trong khi
các đơn vị hoạt động xác định các công việc và các thủ tục để làm sao cho các
chính sách này được thực hiện.

4.6.3. Các chính sách gắn nhãn thời gian

4.6.3.1 Sơ lược

Một chính sách gắn nhãn thời gian là một "bộ các quy tắc cho biết tính khả dụng
của một nhãn thời gian cho một cộng đồng cụ thể và / hoặc lớp ứng dụng với
những yêu cầu an ninh chung.

Tài liệu này quy định các yêu cầu cho một chính sách gắn nhãn thời gian cơ sở để
TSA cấp các mật mã nhãn thời gian, được hỗ trợ bởi chứng thực khóa công khai
với độ chính xác 1 giây hoặc hơn.

TSA có thể quy định chính sách riêng để tăng cường chính sách của mình được
quy định trong tài liệu này. Một chính sách như vậy sẽ kết hợp hoặc tiếp tục hạn
chế các yêu cầu được quy định trong tài liệu này.

Nếu độ chính xác của TSA tốt hơn 1 giây và nếu tất cả các TSUs có đặc điểm
giống nhau, thì tính chính xác sẽ được quy định trong nội dung công khai của TSA,
mỗi mật mã nhãn thời gian được cấp với độ chính xác hơn 1 giây.
 4.6.3.2 Sự phù hợp

Chính sách này có thể được sử dụng cho các dịch vụ gắn nhãn thời gian công cộng
hoặc các dịch vụ gắn nhãn thời gian được sử dụng trong một cộng đồng khép kín.

TSA sẽ sử dụng định danh chính sách gắn nhãn thời gian trong mật mã nhãn thời
gian, hoặc định nghĩa chính sách gắn nhãn thời gian riêng kết hợp hoặc hạn chế
thêm các yêu cầu được quy định trong tài liệu này:

a) nếu TSA nêu ra sự phù hợp cho chính sách gắn nhãn thời gian được nhận dạng
và sẵn có cho thuê bao và các bên tin tưởng khi yêu cầu bằng chứng hỗ trợ về sự
phù hợp; hoặc

b) nếu TSA đã được đánh giá phù hợp với chính sách gắn nhãn thời gian bởi một
bên độc lập.

4.6.4. Nghĩa vụ và trách nhiệm

4.6.4.1 Các nghĩa vụ TSA

TSA phải đảm bảo rằng tất cả các yêu cầu về TSA, được thực hiện phù hợp với
chính sách gắn nhãn thời gian ủy thác đã được lựa chọn.

TSA sẽ đảm bảo sự phù hợp với các thủ tục quy định tại chính sách này, ngay cả
khi các chức năng TSA được thực hiện bởi các nhà thầu phụ.

TSA cũng phải đảm bảo tuân thủ bất kỳ nghĩa vụ bổ sung được nêu ra trong nhãn
thời gian hoặc trực tiếp hoặc kết hợp bởi sự tham chiếu.

TSA sẽ cung cấp tất cả các dịch vụ gắn nhãn thời gian phù hợp với nội dung
nghiệp vụ TSA.

TSA sẽ đáp ứng các yêu cầu như được đưa ra trong các điều khoản và điều kiện
bao gồm cả sự sẵn có và tính chính xác của dịch vụ.

4.6.4.2 Các nghĩa vụ của thuê bao

Tài liệu này không quy định nghĩa vụ cụ thể cho thuê bao ngoài những yêu cầu chi
tiết được nêu trong các điều khoản và điều kiện của TSA.
 4.6.4.3 Các nghĩa vụ của bên tin tưởng

Các điều khoản và điều kiện sẵn có cho các bên tin tưởng sẽ bao gồm một nghĩa vụ
cho bên tin tưởng rằng, khi tin cậy vào một mật mã nhãn thời gian, thì mật mã
nhãn thời gian sẽ:

a) xác nhận rằng mật mã nhãn thời gian đã được ký một cách chính xác và khóa bí
mật (private key) được sử dụng để ký tem thời gian vẫn chưa bị lộ cho đến thời
điểm được kiểm tra;

b) cân nhắc bất kỳ hạn chế về việc sử dụng nhãn thời gian được quy định trong
chính sách gắn nhãn thời gian;

c) cân nhắc bất kỳ biện pháp phòng ngừa nào khác theo quy định trong các thỏa
thuận hoặc bất kể đâu.

4.6.5. Những yêu cầu về nghiệp vụ TSA

TSA sẽ thực hiện kiểm soát đáp ứng những yêu cầu sau đây.

Những yêu cầu chính sách này không có nghĩa là bao hàm bất kỳ sự hạn chế nào
về việc tính phí cho các dịch vụ TSA.

Các yêu cầu được quy định về mặt an ninh, tiếp theo là các yêu cầu cụ thể hơn cho
việc kiểm soát để đáp ứng những mục tiêu này cần thiết để tin rằng những mục tiêu
này sẽ được đáp ứng.

Việc cung cấp một mật mã nhãn thời gian đáp ứng các yêu cầu theo quyết định của
TSA phụ thuộc vào bất kể thỏa thuận nào về mức độ dịch vụ nào với thuê bao.

4.6.5.1 Nội dung nghiệp vụ và nội dung công khai TSA

 Nội dung nghiệp vụ TSA

TSA phải đảm bảo cho thấy được sự tin cậy cần thiết khi cung cấp dịch vụ gắn
nhãn thời gian.

a) TSA có trách nhiệm đánh giá rủi ro được thực hiện để đánh giá các tài sản kinh
doanh và các mối đe dọa đến tài sản để quyết định khả năng kiểm soát an ninh cần
thiết và các quy trình hoạt động.
b) TSA sẽ có một nội dung nghiệp vụ và các quy trình được sử dụng để giải quyết
tất cả các yêu cầu được quy định trong chính sách tem thời gian.

c) nội dung nghiệp vụ TSA sẽ quy định các nghĩa vụ của tất cả các tổ chức bên
ngoài hỗ trợ các dịch vụ TSA bao gồm cả các chính sách và nghiệp vụ ứng dụng.

d) Nội dung nghiệp vụ TSA sẽ sẵn có cho thuê bao và các bên tin tưởng, và các tài
liệu liên quan khác cần thiết để đánh giá sự phù hợp về chính sách gắn nhãn thời
gian.

e) TSA sẽ công khai cho tất cả thuê bao và bên tin tưởng về các điều khoản và điều
kiện liên quan đến việc sử dụng nhãn thời gian được quy định tại mục 7.1.2.

f) Các TSA phải có cơ quan quản lý cấp cao với thẩm quyền phê duyệt nội dung
nghiệp vụ TSA cuối cùng.

g) Việc quản lý cấp cao của TSA sẽ đảm bảo rằng các nghiệp vụ TSA được triển
khai thực hiện đúng đắn.

h) Các TSA sẽ quy định một quá trình xem xét nghiệp vụ này bao gồm cả trách
nhiệm duy trì nội dung nghiệp vụ TSA.

i) Các TSA phải thông báo nếu dự định thay đổi nội dung nghiệp vụ và theo phê
duyệt như phần (f) ở trên, tạo cho nghiệp vụ TSA đã được sửa đổi ngay lập tức có
sẵn như được yêu cầu trong phần (d) ở trên.

 Nội dung công khai TSA

TSA được tiết lộ cho tất cả thuê bao và các bên tin tưởng tiềm năng các điều khoản
và điều kiện về việc sử dụng các dịch vụ gắn nhãn thời gian. Nội dung này sẽ quy
định cụ thể cho mỗi chính sách gắn nhãn thời gian được hỗ trợ bởi TSA:

- Các thông tin liên lạc TSA.

- Chính sách gắn nhãn thời gian được áp dụng.
- Có ít nhất một thuật toán băm có thể được sử dụng để đại diện cho dữ liệu
nhãn thời gian. (Không thuật toán băm nào được uỷ quyền).
- thời gian tồn tại của chữ ký được sử dụng để ký mật mã nhãn thời gian (phụ
thuộc vào các thuật toán băm được sử dụng, thuật toán chữ ký được sử dụng
và chiều dài khóa bí mật (private key).
 - Độ chính xác của thời gian trong mật mã nhãn thời gian đối với giờ UTC.
- Bất kỳ hạn chế nào về việc sử dụng các dịch vụ gắn nhãn thời gian.
- Các nghĩa vụ của thuê bao được quy định trong phần trên, nếu có.
- Các nghĩa vụ của bên tin tưởng dựa theo định nghĩa trong phần trên.
- Thông tin về việc làm thế nào để thẩm định mật mã nhãn thời gian, bên tin
tưởng được coi là "tin tưởng một cách hợp lý" vào các mật mã nhãn thời
gian và bất kỳ những hạn chế có thể trong thời gian hiệu lực.
- Khoảng thời gian mà trong đó các bản ghi sự kiện TSA được lưu giữ lại.
- Hệ thống pháp luật ứng dụng, bao gồm bất cứ yêu cầu bồi thường nào để
đáp ứng yêu cầu của dịch vụ gắn nhãn thời gian theo quy định của pháp luật
nhà nước.
- Những hạn chế về trách nhiệm.
- Thủ tục khiếu nại và giải quyết tranh chấp.
- Nếu TSA đã được đánh giá là tuân thủ chính sách gắn nhãn thời gian, và
nếu như vậy thì bởi cơ quan độc lập nào.

Thông tin này sẽ có sẵn thông qua phương tiện thông tin liên lạc có tuổi thọ. Thông
tin này sẽ có sẵn bằng thứ ngôn ngữ dễ hiểu và có thể được truyền tải điện tử.

4.6.5.2 Vòng đời quản lý khóa

 Tạo hệ khóa TSA

TSA phải đảm bảo rằng bất kỳ các khóa mật mã được tạo ra trong trường hợp được
kiểm soát.

Việc tạo ra các khóa ký của TSU (s) sẽ được thực hiện trong một môi trường đảm
bảo an toàn của cá nhân trong vai trò đáng tin cậy dưới, ít nhất, hai lần kiểm soát.
Các cá nhân được ủy quyền thực hiện chức năng này sẽ bị giới hạn đối với những
người đòi hỏi phải làm như vậy theo nghiệp vụ của TSA. TSA sẽ đảm bảo bất cứ
khóa mã hóa được tạo ra nào cũng phải chịu sự kiểm soát.

Việc tạo ra các khóa ký của TSU (s) sẽ được thực hiện trong một mô-đun mã hóa
(s), Thuật toán tạo ra khóa TSU, chiều dài khóa ký hệ quả và thuật toán chữ ký
được sử dụng để đăng ký mật mã nhãn thời gian sẽ được công nhận bởi bất kỳ cơ
quan giám sát quốc gia nào, hoặc phù hợp với quy định hiện hành của Nhà nước,
như phù hợp với các mục đích của mật mã khóa thời gian được cấp bởi TSA.
  Bảo vệ khóa TSU riêng

TSA sẽ đảm bảo rằng các khóa bí mật (private key) TSU được giữ kín và  duy trì
tính toàn vẹn của chúng.

Khóa ký TSU sẽ được tổ chức và sử dụng trong một mô đun mã hóa

Nếu khóa bí mật (private key) TSU được sao lưu, chúng sẽ được sao chép, lưu trữ
và phục hồi chỉ bởi cá nhân có vai trò tin cậy, sử dụng ít nhất sự kiểm soát kép
trong một môi trường vật lý được bảo đảm. Các cá nhân được ủy quyền thực hiện
chức năng này sẽ bị giới hạn đối với những người đòi hỏi phải làm như vậy theo
nghiệp vụ của TSA.

Bất kỳ bản sao lưu của các khóa ký TSU riêng sẽ được bảo vệ để đảm bảo tính
bảo mật bằng mật mã mô-đun trước khi được lưu trữ bên ngoài thiết bị đó.

 Phân phối khóa công cộng TSU

TSA sẽ đảm bảo rằng sự toàn vẹn và tính xác thực của khóa (công cộng) thẩm định
chữ ký TSU và bất kỳ thông số liên quan được duy trì trong quá trình phân phối
cho các bên tin tưởng.

a) Khóa (công cộng) thẩm định chữ ký TSU sẽ sẵn có cho các bên tin tưởng trong
chứng thực khóa công khai.

b) Thẩm định chữ ký của TSU, chứng nhận khóa (công cộng) sẽ được cấp bởi CA
hoạt động theo chính sách chứng thực cung cấp một mức độ bảo mật tương đương,
hoặc cao hơn chính sách gắn nhãn thời gian này.

 Tạo lại khóa TSU

Vòng đời của chứng thực khóa TSU sẽ không dài hơn khoảng thời gian mà thuật
toán được lựa chọn và chiều dài khóa được công nhận là phù hợp với mục đích

 Kết thúc vòng đời khóa TSU

TSA sẽ đảm bảo rằng các khóa ký TSU riêng không được sử dụng khi kết thúc
vòng đời.Các quy trình hoạt động hoặc kỹ thuật sẽ được thực hiện để đảm bảo một
khóa mới được thay thế khi một khóa TSU hết hạn.Các khóa ký riêng TSU, hoặc
bất kể phần khóa nào, bao gồm bản sao bất kỳ phải được phá hủy để các khóa bí
mật (private key) không thể được phục hồi. Hệ thống tạo TST sẽ từ chối bất kỳ nỗ
lực nào để cấp TSTs nếu khóa ký riêng đã hết hạn.

 Quản lý vòng đời của mô đun mã hóa được sử dụng để ký tem thời gian

TSA phải đảm bảo sự an toàn của phần cứng mã hóa trong suốt vòng đời.

Đặc biệt là TSA phải đảm bảo rằng:

a) phần cứng mã hóa ký nhãn thời gian không phải là giả mạo trong quá trình vận
chuyển;

b) phần cứng mã hóa ký nhãn thời gian không phải là giả mạo trong khi lưu trữ;

c) Cài đặt, kích hoạt và sao chép các khóa ký của TSU trong phần cứng mã hóa sẽ
được thực hiện chỉ bởi các cá nhân có vai trò tin cậy, sử dụng, ít nhất, hai kiểm
soát trong một môi trường vật lý được bảo đảm.

d) phần cứng mã hóa ký tem thời gian đang hoạt động chính xác; và

e) khóa ký riêng TSU được lưu trữ trên mô-đun mã hóa TSU bị xóa khi thiết bị hết
hạn.

4.6.5.3 Nhãn thời gian

 Mật mã nhãn thời gian

TSA sẽ đảm bảo rằng mật mã nhãn thời gian được cấp một cách an toàn và bao
gồm thời gian chính xác. Như là: Các mật mã nhãn thời gian sẽ bao gồm định danh
cho chính sách gắn nhãn thời gian; Mỗi mật mã nhãn thời gian sẽ có một định danh
duy nhất; Giá trị thời gian mà TSU sử dụng trong các mật mã nhãn thời gian có thể
được mô tả theo một trong số các giá trị thời gian thực phân phối bởi một phòng
thí nghiệm UTC (k)…

 Đồng bộ hóa đồng hồ với giờ UTC

TSA phải đảm bảo rằng đồng hồ được đồng bộ với giờ UTC trong phạm vi chính
xác đã được tuyên bố.

Hồ sơ được duy trì về độ chính xác của thời gian (trong phạm vi chính xác đã được
tuyên bố) khi thay đổi này xảy ra.
 4.6.5.4 Quản lý và hoạt động của TSA

 Quản lý an ninh

TSA phải đảm bảo rằng các thủ tục hành chính và quản lý được áp dụng là phù hợp
và tương ứng với nghiệp vụ đã được công nhận.

 An ninh nhân sự

TSA sẽ đảm bảo rằng thông lệ tuyển dụng và nhân sự sẽ tăng cường và hỗ trợ lòng
tin cho các hoạt động của TSA.

 An ninh môi trường và vật lý

TSA phải đảm bảo rằng việc tiếp cận về mặt vật lý với các dịch vụ quan trọng
được kiểm soát và rủi ro vật lý đến các tài sản của TSA được giảm thiểu.

 Quản lý hoạt động

TSA phải đảm bảo rằng các thành phần hệ thống TSA phải an toàn và hoạt động
một cách chính xác, với rủi ro hỏng hóc ít nhất:

Các hoạt động này sẽ được quản lý bởi nhân viên TSA tin cậy, nhưng có thể thực
sự được thực hiện bởi các phi chuyên gia, nhân viên hoạt động (dưới sự giám sát),
như quy định trong chính sách an ninh thích hợp, các vai trò và các văn bản trách
nhiệm.

 Quản lý truy cập vào hệ thống

TSA phải đảm bảo rằng việc truy cập vào hệ thống TSA được giới hạn đúng cho
các cá nhân được ủy quyền.

 Bảo trì và triển khai các hệ thống tin cậy

TSA sẽ sử dụng các hệ thống và các sản phẩm tin cậy được bảo vệ để tránh bị sửa
đổi.

 Tiết lộ các dịch vụ TSA.

TSA sẽ phải đảm bảo trong trường hợp có sự ảnh hưởng đến các dịch vụ an ninh
của TSA, bao gồm cả sự thỏa hiệp khóa ký cá nhân của TSU hoặc tổn hại được
phát hiện của hiệu chuẩn, thì các thông tin liên quan đó phải luôn sẵn có cho thuê
bao và các bên tin tưởng.

 Chấm dứt TSA

TSA phải đảm bảo rằng sự gián đoạn tiềm ẩn cho các thuê bao và bên tin tưởng
được giảm thiểu, kết quả cho sự chấm dứt dịch vụ nhãn thời gian TSA, và đặc biệt
là đảm bảo duy trì liên tục những thông tin cần thiết để xác minh tính đúng đắn của
mật mã nhãn thời gian.

 Tuân thủ các yêu cầu pháp lý

TSA phải đảm bảo tuân thủ các yêu cầu pháp lý.

 Lưu lại các thông tin liên quan đến hoạt động của dịch vụ gắn nhãn thời
gian

TSA phải đảm bảo rằng tất cả các thông tin liên quan đến hoạt động của dịch vụ
gắn nhãn thời gian phải được lưu lại trong một khoảng thời gian xác định, đặc biệt
với mục đích cung cấp bằng chứng cho các thủ tục tố tụng pháp lý.

4.6.5.5 Tổ chức

TSA phải đảm bảo rằng tổ chức của nó là đáng tin cậy.

a) Chính sách và thủ tục theo đó TSA hoạt động sẽ không khác biệt.

b) TSA sẽ làm cho dịch vụ của mình dễ dàng truy cập vào cho tất cả các đương
đơn có các hoạt động thuộc trong lĩnh vực đã kê khai và đồng ý tuân thủ các nghĩa
vụ theo quy định của các nội dung công khai TSA.

c) TSA là một thực thể pháp lý theo luật pháp quốc gia.

d) TSA có một hệ thống hoặc hệ thống chất lượng và quản lý bảo mật thông tin
thích hợp cho các dịch vụ gắn nhãn thời gian mà nó cung cấp.

e) TSA có sự sắp xếp đầy đủ để trang trải các khoản nợ phát sinh từ các hoạt động
của nó và / hoặc hoạt động.

f) có sự ổn định tài chính và nguồn lực cần thiết để hoạt động phù hợp với chính
sách này.
g) thuê một số lượng đầy đủ các nhân viên có giáo dục, đào tạo, kiến thức và kinh
nghiệm kỹ thuật liên quan đến loại, phạm vi và khối lượng công việc cần thiết để
cung cấp dịch vụ gắn nhãn thời gian.

h) có chính sách và thủ tục giải quyết khiếu nại và tranh chấp nhận được từ khách
hàng hoặc các bên khác về việc cung cấp các dịch vụ gắn nhãn thời gian hoặc bất
kỳ vấn đề nào khác có liên quan.

i) có thỏa thuận tài liệu và mối quan hệ hợp đồng tại nơi mà việc cung cấp các dịch
vụ liên quan đến hợp đồng phụ, thuê ngoài hoặc các thỏa thuận với bên thứ ba
khác.

4.6.6. Những xem xét đến an ninh

Khi thẩm định mật mã nhãn thời gian, cần thiết cho người thẩm định phải đảm bảo
rằng các chứng thực TSU là đáng tin cậy và không bị thu hồi. Điều này có nghĩa là
an ninh phụ thuộc vào an ninh của CA nơi đã cấp chứng thực TSU cho cả hai việc
cấp chứng thực và cung cấp thông tin chính xác về tình trạng thu hồi chứng thực
đó.

Khi một nhãn thời gian được thẩm định là có hiệu lực tại một thời điểm nhất định,
điều này không có nghĩa là nhất thiết sẽ vẫn có hiệu lực sau này. Mỗi khi một mật
mã nhãn thời gian được thẩm định trong thời hạn hiệu lực của chứng thực TSU, thì
nó phải được xác nhận một lần nữa về thông tin trạng thái thu hồi hiện tại, từ khi
có sự tiết lộ khóa bí mật (private key) của TSU, tất cả các mật mã nhãn thời gian
được tạo ra bởi TSU trở nên không hợp lệ. Phụ lục C hướng dẫn việc thẩm định lâu
dài các mật mã nhãn thời gian.

Khi áp dụng nhãn thời gian cho các ứng dụng, cũng cần xem xét cả sự an toàn của
ứng dụng. Đặc biệt, khi áp dụng nhãn thời gian, cần thiết phải đảm bảo tính toàn
vẹn của dữ liệu được duy trì trước khi tem thời gian được áp dụng. Người yêu cầu
phải thực sự đảm bảo rằng giá trị băm bao gồm trong mã thời gian phải phù hợp
với hàm băm của các dữ liệu.

Quản lý dịch vụ gắn nhãn thời gian

 Hình 4-4: Quản lý dịch vụ gán nhãn thời gian

4.7. BÀI THỰC HÀNH SỐ 2

Đăng ký, cấp phát, hủy bỏ các chứng thư số của 02 SubCA (sinh danh sách
hủy bỏ)

Với hệ thống CA phân cấp đã hoàn thành ở bài thực hành số 1. Sinh viên thực hiện
việc sinh chứng thư số cho RootCA, SubCA, chứng thư số cho SSL Server,
SecureMail, chữ ký số, mã hóa,… và sinh danh sách hủy bỏ chứng thư số của
RootCA và SubCA
 Chương 5. MỘT SỐ HỆ THỐNG PKI ĐIỂN HÌNH VÀ CÁC
ỨNG DỤNG CỦA PKI
5.1. CÁC HỆ THỐNG PKI ĐIỂN HÌNH

5.1.1. Hệ thống mã đóng

Giải pháp RSA Certificate Manager, đảm bảo bảo mật và khả năng mở rộng các
giao dịch bằng cách cung cấp một hệ thống linh hoạt, khả năng mở rộng để quản lý
các định danh số. Việc thiết lập sự tin tưởng bằng chứng thư số và việc quản lý sử
dụng các khóa và chứng thư số đó là rất quan trọng cho việc triển khai và bảo trì
các ứng dụng của chính phủ điện tử.

Giải pháp RSA Certificate Manager cung cấp các mô-đun có khả năng tương tác
cho phép tổ chức phát triển, triển khai và mở rộng các ứng dụng an toàn bằng cách
quản lý các khóa mật mã và chứng thư số một cách tập trung và tự động. Giải pháp
hoàn chỉnh quản lý chứng thư số bao gồm bốn sản phẩm tích hợp đầy đủ với nhau
để cung cấp một hệ thống duy nhất, liền mạch giúp giải quyết một loạt các nhu cầu
chính phủ.
 RSA Certificate Manager core
 RSA Registration Manager
 RSA Validation Solution
 RSA Key Recovery Manager

5.1.1.1 Kiến trúc

Giải pháp RSA Certifcate Manager có kiến trúc module hóa như sau:
 Hình 5-1: Kiến trúc giải pháp RSA Certificate Manager Solution

 Module quản trị

Module quản trị cho phép người quản trị thực hiện qua giao diện web với
giao thức https. Hệ thống sử dụng cơ chế xác thực qua chứng thư số.
 Module đăng ký
  Module đăng ký cấp phát chứng thư này có giao diện web, cho phép đăng
ký người dùng với hệ thống RSA Certicate Manager.
 Cho phép tạo các yêu cầu chứng thư và download chứng thư tương ứng.
 Mọi người dùng đều có thể truy nhập tới giao diện web này.
 Module cấp mới chứng thư

Module cấp mới chứng thư cung cấp các tính năng sau:
 Ký lại chứng thư của thực thể cuối
 Cho phép sử dụng lại cặp khóa cũ
 Người dùng kết nối tới module Certificate Renewal Server từ một đường
link được cung cấp bởi Enrollment Server
 Cho phép xác thực client
 Module danh sách thu hồi
Module này cung cấp các tính năng sau:
 Cung cấp các danh sách chứng thư bị thu hồi CRLs tới các Client bằng
giao thức HTTP theo định dạng DER
 Không yêu cầu xác thực Client/Server
 Được cấu hình qua CA
 Module SCEP

Module SCEP cung cấp các tính năng sau:

 Cho phép đăng ký các loại thiết bị như Router, VPN
 Hỗ trợ chứng thư SCEP(Simple Certificate Enrollment Protocol) cho
thiết bị của Cisco
 Chứng thư CRS (Certificate Request Syntax) cho thiết bị Nortel
Contivity VPN\
 Không yêu cầu xác thực Client/Server
  SCEP và CRS cung cấp các bảo mật riêng của nó.
 Module OCSP

Module OCSP cung cấp các tính năng sau:

 Chấp nhận các yêu cầu từ các ứng dụng cho phép OCSP
 Kiểm tra trạng thái của chứng thư ngay lập tức
 Không yêu cầu xác thực Client/Server
 Module giao tiếp thư muc

Module này cung cấp các tính năng sau:

 Tương thích với dịch vụ thư mục LDAP chuẩn X.500
 Với cổng bảo mật (Secure Port) được sử dụng bởi Virtual Web Server,
các thành phần của hệ thống RSA Certificate Manager, và các ứng dụng
 sử dụng API để kết nối với RSA Certificate Manager.
 Các cổng không bảo mật (Non-Secure port) được sử dụng bởi các người
dùng công cộng (thuộc hệ thống PKI) muốn truy cập các thông tin chứng
thư số.
 Module LogServer

Module này cung cấp các chức năng sau:

 Lưu trữ bảo mật tất cả các sự kiện của hệ thống PKI này
 Cho phép thực hiện kiểm tra đánh giá log
 Cho phép các kết nối bảo mật từ các máy trạm
 Ký lên các dữ liệu log đảm bảo tính toàn vẹn của dữ liệu log
 Các log file được lưu theo định dạnh XML.
 Module CMP Server
 Module này cung cấp các tính năng sau:
 Là một giao diện web khác cho phép đăng ký chứng thư.
 Quản lý các yêu cầu chứng thư từ các clients sử dụng giao thức CMP.
 Yêu cầu một KeyID và một khóa mật được chia sẻ để định danh người
yêu cầu.
 Các giao thức được sử dụng

Giao thức Mô tả
HTTP HyperText Transfer Protocol: Giao thức này được sử
HTTPs dụng để truyền dữ liệu qua môi trường web.
LDAP Lightweight Directory Access Protocol: được sử dụng
LDAPs cho việc truy nhập các dịch vụ thư mục trên môi trường
mạng.
SSL Secure Sockets Layer: được sử dụng để bảo mật các thông
điệp được truyền qua môi trường mạng. Được kết hợp với
LDAP và HTTP để tạo ra các kênh truyền dữ liệu an toàn.
CMP Certificate Management Protocol: là một giao thức được
sử dụng trong việc quản lý chứng thư.
OCSP Online Certificate Status Protocol: Cho phép một máy
client yêu cầu thông tin trạng thái của một chứng thư từ một
máy chủ OCSP Responder.
CRS Certificate Request Syntax: là cú pháp cho các yêu cầu
chứng thư số, cú pháp này được định nghĩa trong
PKCS#10.
SCEP Simple Certificate Enrollment Protocol: giao thức này
được sử dụng trong việc quản lý các yêu cầu cấp phát
chứng thư số trực tuyến.
 5.1.1.2 Thành phần

Hình 5-2: Các thành phần giải pháp RSA Certificate Manager

RSA Certificate Manager

RSA Certificate Manager là một hệ thống quản lý chứng thư số mà cho phép các tổ
chức phát triển, triển khai và mở rộng các ứng dụng bảo mật và dịch vụ trực tuyến.
RSA Certificate Manager giúp quản lý các định danh số và tự động hóa và tập
trung hóa việc quản lý các khóa mật mã và chứng thư số.

RSA Certificate Manager mang lại các lợi ích sau:

 Tăng cường bảo mật: RSA Certificate Manager được chứng nhận đạt
chuẩn Common Criteria EAL 4+. Nó cũng được xây dựng để hỗ trợ đầy
đủ chuẩn công nghiệp danh sách chứng thư số bị thu hồi (CRLs).
 Khả năng mở rộng: RSA Certificate Manager cung cấp một quá trình
đăng ký người dùng có khả năng mổ rộng tới 8.000.000 người dùng, hỗ
 trợ nhu cầu lớn cho các hoạt động ký chứng thư, truy vấn PKI, và lưu trữ
chứng chư quy mô lớn và quản lý.
 Khả năng tương tác: RSA Certificate Manager hỗ trợ cho nhiều tiêu
chuẩn công nghiệp và tương thích với hơn 200 ứng dụng, bao gồm các
ứng dụng email và thư mục.
 Dễ dàng phát triển và quản trị: RSA Certificate Manager cung cấp giao
diện quản trị trên nền Web bởi vậy cho phép người quản tri thực hiện từ
xa hoặc local, và có khả năng tích hợp với Microsoft Outlook.
RSA Registration Manager

RSA Registration Manager cho phép xử lý một lượng lớn các yêu cầu về chứng
thư của người dùng cuối, với các việc như kiểm tra thông tin yêu cầu chứng thư và
cung chứng thư tới người yêu cầu.

RSA Registration Manager cho phép các tổ chức thành lập Trung tâm đăng ký
người dùng độc lập, cho phép triển khai tại các địa điểm địa lý phân phối từ xa
hoặc địa phương, do đó cho phép các tổ chức quy mô hệ thống quản lý chứng thư
của họ trong khi di chuyển quá trình phê duyệt gần hơn với người sử dụng. Quá
trình này làm giảm đáng kể nguy cơ phê duyệt giấy chứng nhận cho bên trái phép.

RSA Registration Manager cung cấp các lợi ích sau:

 Khả năng mở rộng: RSA Registration Manager có khả năng mở rộng
triển khai với nhiều cơ quan đăng ký (RAs). Việc hỗ trợ triển khai nhiều
RA giúp dễ dàng cung cấp giấy chứng thư cho hàng trăm hoặc hàng ngàn
nhân viên, đối tác, khách hàng, hệ thống, và các thiết bị.
 Tăng cường bảo mật: RSA Registration Manager là một hệ thống đăng
ký có độ an toàn cao với việc xác thực các người quản trị qua chứng thư
số được lưu trên thiết bị hoặc thẻ thông minh. Nó được thiết kế cho việc
quản trị dựa trên web an toàn và chính thông qua chứng thực, kiểm soát
truy cập phiên SSL.
 Đăng ký mềm dẻo: RSA Registration Manager được thiết kế để dễ dàng
hỗ trợ số lượng lớn các yêu cầu cấp chứng thư và linh hoạt để làm việc
trong bất kỳ mô hình tin cậy nào.

RSA Validation Solution

RSA Validation Solution cho phép kiểm tra ngay lập tức các chứng thư số để đảm
bảo tính toàn vẹn của các giao dịch điện tử trong các tổ chức và cơ quan nhà nước.

RSA Validation cung cấp các lợi ích sau:

 Tăng cường bảo mật: RSA validation là một phương pháp hiệu quả và
đáng tin cậy hơn rất nhiều so với danh sách dữ liệu trạng thái chứng thư
số (CRL-Certificate Revocation Lists), bằng cách cung cấp kiểm tra trạng
thái chứng thư theo thời gian thực. Điều này giảm thiểu nguy cơ từ
những chứng thư đã bị thu hồi.
 Đạt các chứng nhận bảo mật quản lý chứng thư thương mại: RSA
Validation cung cấp một giải pháp dựa trên các tiêu chuẩn công nghiệp
được cấp giấy chứng nhận kỹ thuật số đáp ứng nhu cầu khắt khe của môi
trường trực tuyến ngày nay.
 Dễ dàng tính hợp: RSA Validation Client cho phép kiểm tra trạng thái
chứng thư thời gian thực phù hợp với các ứng dụng của Microsoft và các
hãng thứ 3 khác như e-mail client, Web Browsers và Web Server.
 Độ tin cậy, tính sẵn sàng và hiệu năng cao: RSA Validation có thể hỗ
trợ nhiều đơn vị chứng thực (CA), hàng triệu user và tăng hiệu năng hệ
thống với việc sử dụng thiết bị HSM-Hardware Security Modules đạt
chứng chỉ FIPS Level 3
RSA Key Recovery Manager

RSA Key Recovery Manager lưu trữ bảo mật và khôi phục khóa mã của người
dùng để hạn chế các rủi ro mất dữ liệu trong trường hợp khóa mã bị mất, hoặc bị
hỏng. RSA Key Recovery Manager được cung cấp như một gói tùy chọn của RSA
Certificate Manager. RSA Key Recovery Manager có chức năng sinh khóa và lưu
trên thiết bị phần cứng (HSM), đảm bảo một nền tảng quản lý khóa an toàn hơn
việc sử dụng phần mềm. HSM cung cấp một cơ chế bảo mật đảm bảo rằng mọi
khóa mã không được lấy ra ngoài mà không được mã hóa. Việc sử dụng thiết bị
HSM tích hợp với giải pháp RSA Key Recovery Manager cung cấp một chuẩn bảo
mật và toàn vẹ dữ liệu cao nhất trong dịch vụ khôi phục khóa.

5.1.1.3 Công nghệ

Nền tảng Solaris(Sparc), Linux, Window and VMware
(Platform)

Hệ điều hành - Windows 2003 R2 Service Pack 2

hỗ trợ - Windows 2003 Service Pack 2
- Windows 2008 32 bit Service Pack 1
- Windows 2008 R2 64 bit Service Pack 1
- Sun SolarisTM 10
- Red Hat Enterprise Linux 5.5 32 bit
- Red Hat Enterprise Linux 5.5 64 bit
- SUSE Linux Enterprise Server 11 SP1 32 bit
- SUSE Linux Enterprise Server 11 SP1 64 bit
- VMware ESX Server 4.1

Yêu cầu bộ - Windows: tối thiểu 1 GB RAM

nhớ tối thiểu - Solaris: tối thiểu 512 RAM
- Linux: tối thiểu 512 MB RAM
- Windows NT: tối thiểu 250 MB
Yêu cầu ổ đĩa
- Solaris: tối thiểu 250 MB
- Linux: tối thiểu 250 MB
- Windows NT: Intel Pentium IV 2.66 GHz hoặc hơn
Tốc độ CPU
- Solaris: Sparcv9 1280MHz hoặc hơn
- Linux: Intel Pentium IV 2.66 GHz hoặc hơn

Chuẩn chứng X.509 v3 (including all standard extensions)

thư - PKIX
- SSL
- S/MIME
- IPSec
- SET
- Extended Validation

Chuẩn công Tuân thủ các chuẩn sau:

 - Common Criteria EAL4+
nghiệp
- Federal Bridge CA (FBCA)
- IdenTrust Certification

Hỗ trợ thư mục Hỗ trợ tich hợp và lưu trữ chứng thư trên LDAP theo
chuẩn LDAP v2/v3 và X.500.

Các đặc tính - X.509 CRLs và CRLs với các tùy chọn mở rộng
PKI - Không giới hạn các Sub-CA bên dưới theo mô hình
phân cấp (hierarchical PKIs)

Các đặc tính - Chứng thư số theo chuẩn X.509 v1, v3

chứng thư số - Chứng thư số với chuẩn RSA, DSA và ECDSA
- Linh hoạt trong các cấu hình DN cho chứng thư số
- Chứng thư số S/MIME
- Chứng thư số cho ký đối tượng (JavaApplet,
ActiveX)
- Các tùy chọn mở rộng phù hợp PKIX v3
- Tùy chọn mở rộng SET

Hỗ trợ các - RSA

thuật toán - DSA P-256, P-384, và P-521
- ECDSA
- SHA-1 và SHA-2

Thiết bị mã - Lưu trữ khóa bí mật của CA trên thiết bị phần cứng
HSM
hóa phần cứng
- Việc lưu trữ/nhân bản khóa của CA dựa trên phần
cứng với các thiết bị đáp ứng chuẩn PKCS#11.
- Hỗ trợ các thiết bị lưu khóa theo chuẩn FIPS 140-1
level 1 tới 3 như: SafeNet, Thales, AEP và nhiều thiết
bị hỗ trợ chuẩn PKCS#11.
 5.1.1.4 Tùy biến

Giải pháp RSA gần như không cho phép khả năng tuỳ biến các thành phần của hệ
thống như giao diện, chức năng. Còn việc tuỳ biến thuật toán lại càng khó khăn
hơn, vì đây là một sản phẩm thương mại nên mỗi lần tuỳ biến một thành phần là cả
hệ thống cần đóng gọi lại.

5.1.2. Giải pháp của Entrust

5.1.2.1 Tổng quan

Entrust PKI là một phần mềm PKI thương mại của hãng Entrust. Phần mềm
Entrust PKI là một bộ các ứng dụng tương tác với nhau để tạo thành một giải pháp
PKI cho tổ chức. Các ứng dụng chính của giải pháp Entrust PKI như sau:
- Entrust Authority™ Security Manager
- Entrust Authority™ Security Manager Control
- Entrust Authority™ Security Manager Administration
- Entrust Authority™ Security Manager database
- Entrust Ready Directory

Hình sau sẽ thể hiện sự tương tác giữa các ứng dụng này.
 Entrust Authority Security Manager
- Gửi các chứng thư số đã được tin tưởng tới Directory.
- Lưu trữ giữ liệu trong database
- Áp đặt các chính sách trong hệ thống Entrust PKI

Entrust Authority Security

Manager database
Lưu trữ tất cả dữ liệu được sử Entrust Authority
dụng trong hệ thống Entrust Security Manager
PKI Control
Công cụ cho phép
người quản trị có thể
cấu hình Entrust
Authority Security
Manager

Dịch vụ Directory Entrust Authority

Thực hiện việc lưu Security Manager
trữ các chứng thư Administration
và CRLs của hệ Công cụ cho phép quản
thống Entrust PKI lý người dùng và gửi
theo định dạng thư các thông tin người
mục dùng tới Entrust
Authority Security
Manager

Các ứng dụng tương thích với Entrust PKI

Hình 5-3: Các ứng dụng tương thích với Entrust PKI

5.1.2.2 Kiến trúc

Giải pháp Entrust PKI tổng thể có kiến trúc như hình dưới đấy
Administration Security Manager
Services Administration
Entrust Authority
Security Manager

HSM is
Optional

Entrust/Entelligence
and 3rd applications Database

Directory
Enrollment
Server for Web

Hình 5-4: Kiến trúc tổng thể hệ thống Entrus PKI

  Thành phần Entrus Authority Security Manager

Entrust Authority Security Manager thành phần Core CA của giải pháp Entrust
PKI, nó đảm nhiệm các chức năng chính sau:
- Cấp phát, quản lý các khóa và chứng thư số của người dùng.
- Quản lý vòng đời của các định danh số (khóa và chứng thư).
- Cung cấp một giải pháp hoàn chỉnh dựa trên các định danh số (khóa và
chứng thư) cho các dịch vụ xác thực, chữ ký số, và mã hóa.
- Duy trì một cơ sở dữ liệu (Database) lịch sử sử dụng khóa/chứng thư số
của người dùng để cho phép khôi phục lại khi người mất quyền truy
nhập tới khóa của họ.
- Duy trì các báo cáo và logs sự kiên đảm bảo có thể kiểm tra được tất cả
các thao tác diễn ra trong hệ thống.

 Database

Hiện tại giải pháp Entrust PKI đang hỗ trợ 2 loại cơ sở dữ liệu đó là PostgreSQL
và Oracle. Cơ sở dữ liệu này sẽ lưu các thông tin Database Entrust Authority
sau: Security Manager

- Thông tin trạng thái người dùng (bao

gồm tên DN và các thông tin khác của
người dùng).
- Thông tin khóa và chứng thư số của mỗi
người dùng.
- Thông tin về người quản trị
Directory
(Administrator) và Security Officer.
- Thông tin về chính sách người dùng và chính sách bảo mật
- Thông tin thu hồi chứng thư

 Directory
Giải pháp Entrust PKI có thể tích hợp được với các dịch vụ thư mục tuân theo
chuẩn X.500 như Critical Path, Microsoft AD, Sun Directory Server, IBM… Dịch
vụ thư mục này sẽ lưu trữ các thông tin sau:
- Các chứng thư số của người dùng được cấp phát ra bởi hệ thống Entrust
PKI
- Danh sách các chứng thư số bị thu hồi.
- Thông tin về chính sách các máy trạm

 Security Manager Administration

Entrust Authority
Security Manager

Security Manager
Administration

Hình 5-5: Security Manager Administration

Thành phần Security Manager Administration (SMA) là một giao diện GUI cho
phép người quản trị có thể cấu hình và quản trị hệ thống Security Manager một
cách đơn giản. Giao tiếp giữa SMA với Security Manager sử dụng giao thức ASH
(TCP/710).

Khi sử dụng công cụ này người quản trị có thể thực hiện được những loại công
việc sau:
- Quản lý người dùng.
- Quản lý cấp phát chứng thư.
- Quản lý các chính sách bảo mật của hệ thống.
- Thực hiện việc cấu hình chứng thực chéo với hệ thống CA khác.
- Thiết lập kiến trúc hệ thống CA.
  Entrust/Entelligence applications

Các sản phầm Entrust Entelligence sẽ tương tác với hệ thống Security Manager để
tự động trong quá trình quản lý khóa của người dùng. Đây có thể là các sản phẩm
của một hãng thứ 3 nào đó mà tương thích với giải pháp Security Manager của
Entrust. Các sản phầm này làm trong suốt các quá trình sau:
- Tạo cặp khóa ký cho người dùng.
- Trao đổi khóa giữa các người dùng thuộc các CA khác nhau mà không
có sự tin tưởng chéo.

Ngoài ra các ứng dụng này còn cho phép người dùng thực hiện các công việc sau:
- Mã hóa và ký số lên dữ liệu
- Mã hóa/giải mã dữ liệu và kiểm tra chữ ký số trên các dữ liệu đã ký.
- Xóa dữ liệu một cách an toàn.
 Entrust Authority Administration Service

Đây là một ứng dụng tùy chọn trong bộ giải pháp Entrust PKI, nó có giao diện
Web cho phép người quản trị có thể quản trị hệ thống Entrust Authority Security
Manager một cách dễ dàng và trực quan.
Database
Security Manager

Directory
Entrust Authority
Administration
Services

Hình 5-6: Entrust Authority Administration Service

Với giao diện này người quản trị chỉ có thể thực hiện được một số lượng các thao
tác quản tri hạn chế hơn so với công cụ Security Manager Administration. Các thao
tác quản trị ở đây chủ yếu chỉ liên quan tới việc quản trị người dùng.

Vì công cụ này được phát triển trên nền Web nên người quản trị có thể thực hiện
công việc quản trị ở bất cứ máy nào có hỗ trợ trình duyệt vào kết nối được tới hệ
thống Security Manager.

5.1.2.3 Thành phần

Entrust PKI là một phần mềm PKI thương mại của hãng Entrust. Phần mềm
Entrust PKI là một bộ các ứng dụng tương tác với nhau để tạo thành một giải pháp
PKI cho tổ chức. Các thành phần chính của giải pháp Entrust PKI như sau:
1) Entrust Authority Security Manager

Trong giải pháp Entrust PKI, thành phần đóng vai trò của CA (Certificate
Authority) là Entrust Authority Security Manager (gọi tắt là Security Manager).
Các chức năng chính của Security Manager là:
- Tạo chứng thư số cho tất cả các khóa công khai (Public key).
- Duy trì bảo mật cơ sở dữ liệu các thông tin của hệ thống Entrust PKI và
cho phép khôi phục lại cặp khóa của người dùng (trong trường hợp họ
bị mất password,…)
- Áp đặt các chính sách của tổ chức vào hệ thống.

Người quản trị có thể sử dụng 1 trong 2 công cụ sau để kết nối tới Security
Manager và thực hiện các công tác quản trị:
- Entrust Authority Security Manager Control
- Entrust Authority Security Manager Administration
2) Entrust Authority Security Manager Control

Entrust Authority Security Manager Control là giao diện local cho phép truy cập
trực tiếp vào hệ thống Security Manager. Chỉ người quản trị cao nhất của hệ thống
có thể sử dụng công cụ này để truy cập vào Security Manager. Giao diện của
Security Manager Control có 2 dạng là dòng lệnh và GUI form, cho phép thực hiện
các công việc sau:
- Khởi động hoặc dừng dịch vụ Security Manager
 - Khôi phục các profiles cho Security Officers
- Quản lý cơ sở dữ liệu của hệ thống.
3) Entrust Authority Security Manager Administration

Entrust Authority Security Manager Administration là một thành phần quản trị của
hệ thống Entrust PKI. Security Manager Administration sử dụng một giao diện đồ
họa vào giao tiếp bảo mật với Security Manager. Khi sử dụng Security Manager
Administration có thể thực hiện được các công việc sau:
- Quản lý người dùng
- Quản lý chứng thư số của người dùng
- Quản lý các chính sách bảo mật được áp dụng cho hệ thống
- Thực hiện việc cấu hình chứng thực chéo với hệ thống CA khác.
- Thiết lập kiến trúc hệ thống CA.
4) Entrust Authority Security Manager database

Entrust Authority Security Manager database được quản lý bởi Security Manager,
nó thực hiện lưu trữ toàn bộ các thông tin liên quan tới hệ thống Entrust PKI. Các
loại thông tin được lưu trữ trong cơ sở dữ liệu là:
- Cặp khóa của CA (trường hợp không sử dụng thiết bị phần cứng để lưu
khóa)
- Thông tin trạng thái người dùng
- Thông tin khóa và chứng thư của mỗi người dùng
- Thông tin về người quản trị (Administrator) và Security Officer.
- Thông tin về chính sách người dùng và chính sách bảo mật
- Thông tin thu hồi chứng thư
5) Entrust Ready Directory

- Một trong những nhu cầu chính của người dùng đó là truy xuất thông tin về
chứng thư số được cấp phát ra bởi CA. Để cung cấp các thông tin này tới
người dùng, giải pháp Entrust PKI sử dụng các dịch vụ thư mục đáp ứng
chuẩn X.500 và tương thích với giao thức LDAP. Các thông tin có thể được
lưu trữ trên dịch vụ thư mục là:
- Các chứng thư số của người dùng được cấp phát ra bởi hệ thống Entrust
 PKI
- Danh sách các chứng thư số bị thu hồi.
- Thông tin về chính sách các máy trạm

5.1.2.4 Công nghệ

Dưới đây là bảng thông số đặc tính kỹ thuật cũng như khả năng hỗ trợ của hệ thống
Entrust PKI
Security Manager
OS 7.0 7.1

Windows 2000 2000, 2003

Solaris 7,8 8, 9
IBM AIX 5.1 5.1
HP-UX 11, 11i 11i
Other Platform
Highlights
Microsoft Active
2000, 2003 2000, 2003, ADAM
Directory
CP 4.1, 4.2,
Siemens 6, IBM CP 4.2, Siemens 6, IBM DS
Other Directories
DS 5.2, Sun ONE 5.2, Sun ONE DS 5.2
DS 5.1, 5.2
PostgreSQL,
PostgreSQL, Informix 9.4,
Databases* Informix 9.21,
Oracle 9i
Oracle 8i, 9i
SafeNet/Chrysalis Luna CA3 & SA,
Luna CA3 & SA, nShield
HSM nShield
SMA tokens PKCS#11v2** PKCS#11v2
Bảng 5.1: Bảng thông số kỹ thuật của hệ thống Entrust

Các chuẩn chính được hỗ trợ trong hệ thống Entrust PKI

 Chuẩn Mục đích
X.509 Định dạng chứng thư số
PKIX-CMP Giao thức quản lý chứng thư
PKCS #7/10 Sử dụng trong quá trình đăng ký cấp phát chứng thư
PKCS#11 Chuẩn giao tiếp với các thiết bị mã hóa phân cứng
LDAP Lightweight Directory Access Protocol
RFC 3039 Một loại định dạng chứng thư số
Cisco Certificate Enrollment Protocol (cho giải pháp
Cisco SCEP
VPN của Cisco)
SPEKE Một phương pháp mã hóa sử dụng trong xác thực p/w
Bảng 5.2: Các chuẩn hỗ trợ trong Entrust PKI

Các loại thuật toán được sử dụng:

Loại thuật toán Giải thuật hỗ trợ
Symmetric
DES, Triple-DES, CAST, RC4, IDEA, AES
Encryption
Digital Signature RSA, DSA, ECDSA
Hash Functions SHA, MD5, RIPEMD-160
Key Exchange RSA key transfer, Diffie-Hellman, SPKM
Symmetric Integrity MAC, HMAC
Bảng 5.3: Các loại thuật toán sử dụng

5.1.3. Hệ thống mã mở

5.1.3.1 OpenCA

Cơ sở hạ tầng khóa công khai (PKI) đang rất được quan tâm phát triển. Các
ứng dụng có thể được bảo mật với các chứng thư số và khóa bí mật, nhưng một
vấn đề là để thiết lập một PKI rất phức tạp và tốn kém, nguyên nhân là bộ phần
mềm trung tâm tốt(đặc biệt đối với các hệ UNIX) có giá rất đắt. Đây là điểm mấu
chốt để OpenCA phát triển. Mục đích là xây dựng bộ phần mềm trung tâm ổn định
mã nguồn mở để hỗ trợ cộng đồng một cách tốt nhất, rẻ và phát triển trong tương
lai. OpenCA được bắt đầu xây dựng vào năm 1999. Gồm ba phần chính: một giao
diện web Perl, OpenSSL là hạt nhân cho các hoạt động mật mã và một cơ sở dữ
liệu. Đến nay toàn bộ các hoạt động có thể thực hiện qua các giao diện Web. Ta sẽ
có sáu giao diện cấu hình trước và một số sẽ được tạo ra sau đó. Hạt nhân của các
hoạt động mật mã vẫn là OpenSSL. Cơ sở dữ liệu chứa toàn bộ các thông tin cần
thiết về các đối tượng mật mã của người sử dụng như: các yêu cầu ký chứng thư
(CSR), chứng thư, các yêu cầu hủy chứng thư và danh sách hủy bỏ chứng thư.

Ngày nay OpenCA hỗ trợ theo các phần sau [8]:

- Giao diện công khai (Public interface)

- Giao diện LDAP (LDAP interface)

- Giao diện RA (RA interface)

- Giao diện CA (CA interface)

- SCEP (Simple Certificate Enrollment Protocol)

- OCSP (Online Certificate Status Protocol)

- Các bộ lọc IP cho các giao diện

- Đăng nhập dựa vào mật khẩu

- Đăng nhập dựa vào chứng thư

- Điều khiển truy nhập dựa trên Role

- Các chủ thể chứng thư

- Các mở rộng chứng thư

- Hủy bỏ dựa vào mã PIN

- Hủy bỏ dựa vào chữ ký số

 - Phát hành CRL

- Cảnh báo tới các chứng thư hết hạn

- Hỗ trợ tất cả các trình duyệt

OpenCA được thiết kế cho một cơ sở hạ tầng phân tán. Không những có thể
điều khiển một CA offline và RA online, mà ta còn có thể sử dụng để xây dựng
toàn bộ cấu trúc phân cấp với ba hoặc nhiều hơn các mức. OpenCA có thể hỗ trợ
rất tốt cho các tổ chức lớn như quốc gia, các tập đoàn lớn….

5.1.3.2 Kiến trúc của OpenCA

 Kiến trúc nền tảng

Ý tưởng cơ bản của mỗi PKI X.509 là một tổ chức phân cấp rõ rệt. Điều này sẽ
hình thành nên một cây cơ sở dữ liệu nếu chúng ta cố gắng tạo ra kiến trúc PKI
phân tán

Hình 5-7: Kiến trúc PKI phân tán

Dữ liệu trao đổi giữa các cơ sở dữ liệu đơn có thể được điều khiển độc lập nếu
ta sử dụng hệ thống cơ sở dữ liệu phân tán. Nếu ta thực sự có một cơ sở dữ liệu
độc lập (chẳng hạn của CA offline) sau đó ta phải có một kỹ thuật trao đổi dữ liệu
và quản trị đầy đủ các nút trên cấu trúc phân cấp. Chức năng quản trị này được gói
vào một giao diện được gọi là nút hoặc quản trị nút. Vì thế thiết kế của OpenCA sẽ
như sau:

Hình 5-8: Kiến trúc nền tảng của OpenCA

Thông thường thì mỗi server trong cơ sở hạ tầng của trung tâm tin cậy đều
có cơ sở dữ liệu của riêng nó nhằm mục đích an ninh. Sự phân cấp này là phần cốt
lõi của trung tâm tin cậy

Ý tưởng cơ bản của các PKI chuẩn X.509 là một tổ chức phân cấp. Kết quả
ta sẽ có một mô hình cây cơ sở dữ liệu nếu xây dựng một kiến trúc PKI phân tán.

Các giao diện

Sau khi ta xem xét cơ sở nền tảng của OpenCA ta có thể muốn biết thêm về
CA, RA, LDAP và các giao diện công cộng – đôi khi được gọi là web-gateway.
OpenCA hỗ trợ toàn bộ các thành phần phần mềm qua các giao diện web. Nếu ta
muốn thiết kế một trung tâm chứng thực mạnh ta phải có một khái niệm về tổ chức
các luồng công việc, có thể như sau:
 Hình 5-9 Các giao diện nút của OpenCA

a. Nút

Giao diện này để quản lý cơ sở dữ liệu và điều khiển toàn bộ các chức năng
xuất nhập. Cơ sở dữ liệu có thể được khởi tạo có nghĩa là OpenCA có thể tạo toàn
bộ các bảng, nhưng OpenCA không thể tự nó tạo ra cơ sở dữ liệu bởi vì sự khác
nhau giữa các tổ chức sử dụng. Vì vậy ta cần một cơ sở dữ liệu với quyền truy xuất
hợp lệ và một cơ sở dữ liệu mới. Giao diện bao gồm một vài chức năng sao lưu và
phục hồi, nhưng cần nhớ rằng phải tách biệt sao lưu khóa bí mật của CA và chứng
thư.

b. CA

Giao diện CA có toàn bộ các chức năng cần thiết để tạo các chứng thư và
danh sách hủy bỏ chứng thư. CA cũng có thể bao gồm toàn bộ các chức năng sử
dụng để thay đổi cấu hình qua một giao diện web.

c. RA
 RA của OpenCA cũng có thể điều khiển toàn bộ yêu cầu các loại. Bao gồm:
yêu cầu chỉnh sửa thông tin, yêu cầu phê chuẩn, có thể tạo các khóa bí mật với các
thẻ thông minh, xóa các yêu cầu sai và các thư điện tử của người dùng

d. LDAP

Giao diện LDAP được thực hiện để tách biệt phần quản trị LDAP ra khỏi
phần mềm. Điều này là cần thiết bởi vì có rất nhiều chức năng đặc biệt đối với việc
quản trị LDAP.

c. Pub

Giao diện công cộng bao gồm các khoản người dùng cần. Sau đây là danh
sách nhỏ các khoản:

- Sinh các CSR (Certificate signing request) cho IE, Mozilla, netscape...

- Sinh các yêu cầu client và các khóa bí mật

- Nhận các yêu cầu định dạng PEM của PKCS#10 từ các server

- Đăng ký chứng thư

- Đăng ký CRL

- Hỗ trợ các phương thức hủy bỏ

- Tìm kiếm chứng thư

- Kiểm tra chứng thư số trên các trình duyệt

 Chu trình đăng ký, huỷ bỏ chứng thư của hệ thống OpenCA
 Chứng thư bị Lưu trữ yêu
Yêu cầu CRL hủy bỏ cầu hủy
User

Xóa yêu cầu

Phát hành
Hủy bỏ
CRL
chứng thư
Phê duyệt yêu
cầu

Chứng thư số
CA Phê duyệt hủy
bỏ

Lưu yêu cầu

Phát hành Xóa yêu cầu

chứng thư hủy

Treo chứng Yêu cầu hủy

thư bỏ

Bắt đầu hủy

bỏ

Yêu cầu hủy

Chứng thư số bỏ đã xóa

Hình 5-10: Vòng đời của các đối tượng

Người sử dụng muốn đăng ký một chứng thư số phải đến cơ quan đăng ký
địa phương khai báo các thông tin cần thiết để tạo một yêu cầu, cơ quan đăng ký
địa phương kiểm tra các thông tin cá nhân của người đăng ký, nếu thông tin chưa
phù hợp, hoặc không đồng ý cấp chứng thư cho người sử dụng thì sẽ xóa, ngược
lại nếu thông tin người sử dụng là chính xác và hợp lệ, cơ quan đăng ký địa
phương sẽ phê chuẩn yêu cầu xin cấp gửi lên RA, RA chuyển cho CA. Sau đó các
yêu cầu được phê chuẩn chuyển về CA, CA tiếp nhận yêu cầu và sinh chứng thư
số. Ngoài ra CA cũng sinh chứng thư tự ký của mình và danh sách chứng thư bị
thu hồi trước khi sinh chứng thư cho người sử dụng. Sau đó trong quá trình sử
dụng chứng thư của người sử dụng, khi hết hạn hoặc muốn hủy bỏ, quy trình sẽ bắt
đầu hủy bỏ (start revocation), có thể hủy bỏ hoặc tạm dừng chứng thư (pending
CRR, suspended certificate). Nếu yêu cầu hủy bỏ được phê chuẩn (approved
CRR), chứng thư sẽ được hủy bỏ, lưu trữ lại yêu cầu hủy và đăng ký lên danh sách
hủy bỏ chứng thư. Trong trường hợp tạm dừng (suspended certificate) nếu hết thời
hạn tạm dừng, chứng thư có thể sử dụng lại và CA thực hiện xóa yêu cầu hủy, còn
nếu hết hạn tạm dừng và không muốn dùng chứng thư nữa thì sẽ thực hiện quy
trình hủy bỏ chứng thư.

5.1.3.3 EJBCA

5.1.3.3.1 Giới thiệu

Kiến trúc Enterprise Java Beans (EJB) là một đặc tả được công ty Sun
Microsystems phát triển. EJB mô tả một kiến trúc dựa trên thành phần cho việc
phát triển và triển khai các ứng dụng phân tán, cho phép các ứng dụng doanh
nghiệp có thể mở rộng, an toàn và có thể giao tác.

EJB là các thành phần thực thi bên trong “khung chứa EJB” (EJB container),
dưới sự giám sát của một máy chủ ứng dụng (như JBOSS 19). Máy chủ ứng dụng
và khung chứa EJB cung cấp các dịch vụ hệ thống cho EJB như tính bền vững dữ
liệu, giao tác, bảo mật và quản lý tài nguyên. EJB là phần cốt lõi của ứng dụng
J2EE20. Khung chứa EJB duy trì các kết nối dữ liệu dùng chung cũng như các
thực thể EJB dùng chung được cung cấp cho người dùng khi cần.

EJBCA là một CA đầy đủ chức năng được xây dựng trên Java. Do được dựa
trên công nghệ J2EE, EJBCA tạo thành một CA mạnh, hiệu suất cao và dựa trên
thành phần. Với sự mềm dẻo và độc lập môi trường nền, EJBCA có thể được sử
dụng độc lập hoặc được tích hợp trong các ứng dụng J2EE. EJBCA là một sản
phẩm của công ty PrimeKey, một trong các công ty PKI mã nguồn mở đứng đầu
trên thế giới, được thành lập năm 2002 tại Stockholm, Thụy Điển. PrimeKey cung
cấp các sản phẩm PKI và thẻ thông minh, các giải pháp liên quan và các dịch vụ
chuyên nghiệp.

EJBCA trải qua các giao đoạn phát triển như sau:

- Phiên bản 1.x bắt đầu như một bản beta trên SourceForge vào tháng
11/2001. Ý tưởng của EJBCA là thực thi một CA bên trong một máy chủ ứng dụng
J2EE. Phiên bản 1.0-1.4 cung cấp các hỗ trợ đối với Jboss, WebLogic, CRL,
LDAP, MySQL, PostgreSQL, Oracle.
 - Phiên bản 2.x lấy kinh nghiệm từ phiên bản 1.x và được bắt đầu từ tháng
3/2003. Phiên bản này cung cấp các hỗ trợ đối với thẻ từ, PIN/PUK, phục hồi
khóa, trạng thái chứng nhận, OCSP, SCEP, các tính năng đặc biệt cho AD và
Outlook, OpenLDAP.

- Phiên bản 3.x bắt đầu từ tháng 6/2004, cung cấp các hỗ trợ đối với CA
ảo, kiếm tra JUnit, hỗ trợ HSM (nCipher, Luna/Eracom/SafeNet), ngôn ngữ (Tây
Ban nha, Pháp, Ý, Trung Quốc, Thụy Điển, Đức), OCSP Responder bên ngoài,
Infomix, OpenVPN, RA API ngoài, CMP, XKMSv2, các dịch vụ theo dõi,
ECDSA, các mở rộng chứng nhận tùy thích, DN và altName OIDs.

EJBCA là phần mềm mở nguồn mở, hỗ trợ rất nhiều chức năng. Tính đến
6/10/2008, phiên bản 3.x đã có hơn 47.600 lượt tải về. EJBCA thực sự đã trở thành
một sản phẩm toàn diện cho các giải pháp PKI/CA thay thế cho mọi ứng sản phẩm
khác.

5.1.3.3.2 Kiến trúc

Kiến trúc của EJBCA bao gồm các thành phần sau:

- Tầng dữ liệu (Data Tier): Tầng dữ liệu lưu trữ các chứng nhận, CRL cũng
như các thực thể cuối. EJBCA sử dụng một cơ sở dữ liệu mặc định để lưu trữ các
thực thể cuối. Các chứng nhận được lưu trữ trong một kho chứa LDAP
(Lightweight Directory Access Protocol).
 Hình 5-11: Kiến trúc của EJBCA

- Thành phần CA: Thành phần có chức năng tạo các CA gốc, CA con,
chứng nhận, CRL và giao tiếp với kho chứa LDAP để lưu trữ thông tin chứng
nhận.

- Thành phần RA: Thành phần có chức năng tạo, xóa và hủy bỏ người
dùng. Nó giao tiếp với cơ sở dữ liệu cục bộ để chứa thông tin người dùng.

- Tầng Web: Đây là giao diện (điển hình là giao diện người – máy bằng
đồ

họa) để trình khách tương tác với hệ thống EJBCA, đồng thời quy định các cấp độ
và phạm vi truy cập thông tin khác nhau cho thực thể cuối.

- Trình khách: Trình khách là thực thể cuối hay người sử dụng như trình
khách thư điện tử, máy chủ web, trình duyệt web hay cổng VPN. Các thực thể cuối
không được phép phát hành chứng nhận đến các thực thể khác, nói cách khác
chúng là các nút lá trong PKI.

5.1.3.3.3 Chức năng

 EJBCA là một tổ chức chứng nhận rất phổ biến hiện đang được sử dụng,
một trong những CA được ưa thích hiện nay. Các đặc trưng cơ bản của CA này
bao gồm sự lựa chọn của thuật toán ta cần như tùy chọn giữa các thuật toán SHA1
hay SHA-256 với RSA và với các kích thước khóa khác nhau như 1024, 2048 và
4096.

EJBCA cung cấp một số tính năng nổi bật về lựa chọn ngôn ngữ trong quá
trình cấu hình hệ thống. Ngoài ra ta cũng có thể chọn loại publisher chúng ta muốn
như LDAP, thư mục động (AD – Active Directory) hay một kết nối publisher tự
làm.

Sự phát hành của chứng nhận luôn luôn thuộc chuẩn X509. Cũng có một
tùy chọn được cung cấp để chọn loại khóa ký – soft hay hard. Việc ký chứng nhận
có thể là tự ký (self-signed), CA bên ngoài (external CA) hay CA quản trị (admin
CA).

CA gốc có khóa RSA độ dài mặc định là 2048 bit và có hiệu lực 10 năm.
Việc đăng ký chứng nhận trong EJBCA cung cấp cho người sử dụng nhiều lựa
chọn như người sử dụng có thể chọn nhà cung cấp dịch vụ mã hóa (Cryptographic
Service Provider – CSP) mà họ thích và có thể chọn kích thước khóa khác nhau
được cung cấp như 512, 1024 và 2048. Nó cũng cung cấp cho người sử dụng
những tùy chọn của việc thêm chứng nhận vào thẻ nhận dạng điện tử (Electronic
Identity Card).

5.2. CÁC ỨNG DỤNG PKI

5.2.1. Ứng dụng của PKI trong bảo mật thư điện tử S/MIME

Các sản phẩm e mail an toàn dựa trên khoá công khai bao gồm cả
Microsoft Exchange đã có một thời gian và đã được triển khai rộng rãi. Các hệ
thống này dựa trên công nghệ khóa công khai để:

 Các chữ ký số: nhằm chứng minh nguồn gốc và tính xác thực của một
thông báo email

 Mã hóa mà không cần chia sẻ tin mật trước đó: để giữ bí mật giữa các
bên trao đổi.
 Bản chất phân tán của email và sự tin cậy vào quá trình chuyển tiếp và lưu
trữ đối với nhiều người nhận đã quyết định các nhân tố dùng công nghệ khoá
công khai. Các biện pháp khác dựa trên mật mã chia sẻ tin mật buộc chấp nhận
các yêu cầu an toàn vật lý và quản trị, gây khó khăn cho việc sử dụng.
Một hạn chế của một số thực hiện trước đây là thiếu khả năng liên vận
hành giữa các nhà cung cấp chéo (cross - vendor interoperability). Không có
các chuẩn phù hợp, các nhà cung cấp đã thực hiện các hệ thống dựa trên các
giao thức độc quyền (thuộc quyền sở hữu riêng) , các mã (encoding) thông báo
và các giả thiết về sự tin cậy được xác định hiệu quả các PKI không có khả
năng liên vận hành. Chỉ gần đây mới có cơ sở cho các hệ thống email an toàn
có khả năng liên vận hành được hợp nhất từ các nhà cung cấp chính, với chuẩn
IETF S/MIME V 3. (được xây dựng trên S/MINE Version 2 từ RSA Data
Security. Mặc dù mới chỉ ở dạng bản thảo song S/MINE hiện đã được dùng với
một số sản phẩm, kể cả Microsoft Outlook 98 và Microsoft Outlook Express,
với tính liên vận hành đã được chứng minh giữa các nhà cung cấp mã hóa PK,
chữ ký số và dùng các thuật toán RSA.

Trong hoạt động, các hệ thống này dùng khóa riêng của người dùng để ký số
email sắp gửi đi. Chứng thực người dùng sau đó được gửi cùng với email sao cho
người nhận có thể xác minh được chữ ký. S/MIME xác định một mô tả sơ lược cho
các chứng chỉ này để bảo đảm khả năng liên vận hành và giả thiết một mô hình CA
phân cấp để quản lý tin cậy theo mở rộng được. Để mã email, người dùng nhận
một chứng chỉ mã hóa của người nhận, hoặc từ email trước hay từ dịch vụ thư
mục. Ngay khi chứng chỉ này được xác minh, người dùng có thể dùng khóa công
khai trên đó để mã hóa khóa mật (dùng để mã hóa email)

5.2.2. Ứng dụng của PKI trong hệ thống mạng riêng ảo VPN

IPSec xác định các giao thức mã hóa mạng ở tầng giao thức IP. IPSec
không yêu cầu công nghệ dựa trên khoá công khai và có thể dùng các khóa mật
chia sẻ để mã hóa, chúng được truyền một cách qn toàn qua cơ chế ngoài dải
(out of band) tại các điểm cuối mạng cho việc mã. Tuy nhiên, nhóm làm việc
IETF IPSec đã nhận thấy rằng, công nghệ dựa trên khoá công khai đưa ra giải
pháp thực tế để tạo một kiến trúc phân phối quy mô, tin cậy, cụ thể, một giải
pháp trong đó, các thiết bị IPSec có thể xác thực lẫn nhau và thỏa thuận các
khóa mã mà không nhờ đến các bí mật chia sẻ đã chuẩn bị trước đó.
Cộng đồng IPsec, kể cả Microsoft, đang làm việc tích cực về các chuẩn
cho các chứng chỉ có tính tương tác, kết nạp chứng chỉ và các giao thức quản
lý. Mặc dù một mức của tính tương tác đã được trình diễn, song vẫn còn công
việc cần thiết để đảm bảo tính liên vận hành rộng giữa các thiết bị IPSec và các
cài đặt PKI. Microsoft đã cam kết phát triển PKI Windows có sự kết hợp với
những thứ liên quan đến chuẩn.

5.2.3. Ứng dụng của PKI trong việc bảo mật kênh SSL

  1. SSL là gì ?

SSL (Secure Socket Layer) là giao thức đa mục đích được thiết kế nhằm mã hóa
toàn bộ thông tin đến/ đi giữa hai chương trình ứng dụng trên một cổng định trước
(socket 443). Giao thức SSL được hình thành và phát triển đầu tiên năm 1994 bởi
nhóm nghiên cứu Netscape và ngày nay trở thành chuẩn bảo mật thực hành trên
mạng Internet.

Giao thức SSL được hình thành và phát triển đầu tiên năm 1994 bởi nhóm nghiên
cứu Netscape và ngày nay trở thành chuẩn bảo mật thực hành trên mạng Internet.
Phiên bản hiện nay là SSL 3.0 và đang tiếp tục được bổ sung hoàn thiện.

2.   SSL làm việc như thế nào ?

Giao thức SSL hoạt động bên trên tầng TCP/IP mô hình OSI và bên dưới các giao
thức ứng dụng tầng cao hơn như là HTTP (Hyper Text Transport Protocol), IMAP
( Internet Messaging Access Protocol) và FTP (File Transport Protocol). SSL có
thể sử dụng để hỗ trợ các giao dịch an toàn cho rất nhiều ứng dụng khác nhau trên
Internet. Hiện nay SSL được sử dụng chính cho các giao dịch trên Web. 
SSL không phải là một giao thức đơn lẻ, mà là một tập các thủ tục đã được chuẩn
hoá để thực hiện các nhiệm vụ bảo mật sau: 

Xác thực server: Cho phép người sử dụng xác thực được server muốn kết nối. Lúc
này, phía browser sử dụng các kỹ thuật mã hoá công khai để chắc chắn rằng
certificate và public ID của server là có giá trị và được cấp phát bởi một CA
(certificate authority) trong danh sách các CA đáng tin cậy của client. Điều này rất
quan trọng đối với người dùng. Ví dụ như khi gửi mã số credit card qua mạng thì
người dùng thực sự muốn kiểm tra liệu server sẽ nhận thông tin này có đúng là
server mà họ định gửi đến không. 

Xác thực Client: Cho phép phía server xác thực được người sử dụng muốn kết nối.
Phía server cũng sử dụng các kỹ thuật mã hoá công khai để kiểm tra xem
certificate và public ID của Client có giá trị hay không và được cấp phát bởi một
CA (certificate authority) trong danh sách các CA đáng tin cậy của server không.
Điều này rất quan trọng đối với các nhà cung cấp. Ví dụ như khi một ngân hàng
định gửi các thông tin tài chính mang tính bảo mật tới khách hàng thì họ rất muốn
kiểm tra định danh của người nhận. 

Mã hoá kết nối: Tất cả các thông tin trao đổi giữa client và server được mã hoá trên
đường truyền nhằm nâng cao khả năng bảo mật. Điều này rất quan trọng đối với cả
hai bên khi có các giao dịch mang tính riêng tư. Ngoài ra, tất cả các dữ liệu được
gửi đi trên một kết nối SSL đã được mã hoá còn được bảo vệ nhờ cơ chế tự động
phát hiện các xáo trộn, thay đổi trong dữ liệu. ( đó là các thuật toán băm – hash
algorithm).

Giao thức SSL bao gồm 2 giao thức con: giao thức SSL record (bản ghi) và giao
thức SSL handshake (bắt tay). Giao thức SSL record xác định các định dạng dùng
để truyền dữ liệu. Giao thức SSL handshake sẽ sử dụng SSL record protocol để
trao đổi một số thông tin giữa server và client vào lần đầu tiên thiết lập kết nối
SSL. 

Khi hai ứng dụng máy tính, ví dụ giữa một trình duyệt web và máy chủ web, làm
việc với nhau, thì máy chủ và máy khách sẽ trao đổi "lời chào" (hello) dưới dạng
các thông điệp cho nhau với xuất phát đầu tiên chủ động từ máy chủ, đồng thời xác
định các chuẩn về thuật toán mã hoá và nén số liệu có thể được áp dụng giữa hai
ứng dụng. Ngoài ra, các ứng dụng còn trao đổi "số nhận dạng/khoá theo phiên"
(session ID, session key) duy nhất cho lần làm việc đó. Sau đó ứng dụng khách
(trình duyệt) yêu cầu có chứng chỉ điện tử (digital certificate) xác thực của ứng
dụng chủ (web server).
Ứng dụng công nghệ xác thực máy chủ SSL trong các giao dịch thương mại trực
tuyến được diễn ra theo các bước sau:

(1) Một khách hàng làm quen với Website và truy nhập một địa chỉ URL an toàn,
được đảm bảo bằng mã số máy chủ. Điều này có thể là một mẫu đơn đặt hàng trực
tuyến thu thập những thông tin cá nhân từ khách hàng như địa chỉ, số điện thoại, số
thẻ tín dụng hoặc các thông tin thanh toán khác.

(2) Trình duyệt của khách hàng tự động truyền cho máy chủ số phiên bản SSL của
trình duyệt đó, các cài đặt mật mã, các dữ liệu được sinh ngẫu nhiên, và những
thông tin khác mà máy chủ đó cần để giao tiếp với khách hàng sử dụng SSL.

(3) Máy chủ trả lời, tự động truyền tới trình duyệt của người sử dụng xác nhận số
của Website cùng với số phiên bản SSL của máy chủ, các thiết lập mật mã.

(4) Trình duyệt của người sử dụng xem xét các thông tin chứa trong xác nhận máy
chủ đó và xác nhận rằng: Xác nhận máy chủ đó có giá trị  và còn trong thời hạn sử
dụng; Cơ quan chức năng xác thực CA cho máy chủ này có quyền được ký và là
một cơ quan xác thực tin cậy, xác thực của cơ quan này được liệt kê sẵn trong trình
duyệt đang sử dụng; Khoá công cộng của CA này được cài đặt sẵn trong trình
duyệt đang sử dụng, xác nhận tính hợp lệ của chữ ký điện tử của người cung cấp;
Tên miền được chỉ định bằng xác thực máy chủ khớp với tên miền thực của máy
chủ đó.

 Nếu máy chủ này không được xác thực, người sử dụng sẽ được cảnh báo rằng một
kết nối được mã hoá, được xác thực có thể không thiết lập được.

(5) Nếu máy chủ đó được xác thực thành công, trình duyệt Web của khách hàng
này sẽ tạo ra một khoá phiên (session key) duy nhất để mã hoá tất cả các giao tiếp
với Website đó bằng việc sử dụng mã hoá không đối xứng.

(6) Trình duyệt của người sử dụng tự mã hoá khoá phiên đó bằng khoá công cộng
của site sao cho chỉ site đó mới có thể đọc được khoá phiên đó, rồi gửi nó tới máy
chủ.
(7) Máy chủ giải mã cho khoá phiên đó bằng việc sử dụng khoá cá nhân của chính
nó.

(8) Trình duyệt gửi một thông điệp tới máy chủ thông báo cho máy chủ biết rằng
các thông điệp tiếp sau đó từ khách hàng sẽ được mã hoá bằng khoá phiên đó.

(9) Máy chủ sau đó gửi một thông điệp tới khách hàng thông báo với khách hàng
rằng các thông điệp tiếp sau từ máy chủ sẽ được mã hoá bằng khóa phiên đó.

(10) Một phiên giao dịch an toàn SSL bây giờ đã được thiết lập. Giao thực máy
chủ SSL sau đó sử dụng mã hoá đối xứng để mã hoá và giải mã thông điệp bên
trong phiên giao dịch an toàn SSL này.

(11)  Một khi phiên giao dịch kết thúc, khoá phiên sẽ được vô hiệu hoá.

Tất cả quá trình trên diễn tự động trong vài giây, chính vì thế mà giao thức xác
thực máy chủ SSL giúp cho các giao dịch điện tử này được thực hiện trực tuyến, an
toàn; đồng thời nó cũng không gây ra bất cứ phiền toái nào cho người sử dụng, tạo
điệu kiện cho việc mở rộng các ứng dụng TMĐT.

Hình 5-12: Quá trình bắt tay của giao thức SSL
Các thuật toán mã hoá và xác thực của SSL được sử dụng bao gồm (phiên bản 3.0):

DES - chuẩn mã hoá dữ liệu (ra đời năm 1977),  được phát minh và sử dụng bởi
chính phủ Mỹ

DSA - thuật toán chữ ký điện tử, chuẩn xác thực điện tử), phát minh và sử dụng
bởi chính phủ Mỹ

KEA - thuật toán trao đổi khoá), phát minh và sử dụng bởi chính phủ Mỹ

MD5 - thuật toán tạo giá trị “băm” (message digest), phát minh bởi Rivest;

RC2, RC4 - mã hoá Rivest, phát triển bởi công ty RSA Data Security;

RSA - thuật toán khoá công khai, cho mã hoá va xác thực, phát triển bởi Rivest,
Shamir và Adleman;

RSA key exchange - thuật toán trao đổi khoá cho SSL dựa trên thuật toán RSA;

SHA-1 - thuật toán hàm băm an toàn, phát triển và sử dụng bởi chính phủ Mỹ

SKIPJACK - thuật toán khoá đối xứng phân loại được thực hiện trong phần cứng
Fortezza, sử dụng bởi chính phủ Mỹ

Triple-DES - mã hoá DES ba lần.

 Hình 5-13: Mô hình kết nối sử dụng SSL

Theo mô hình trên, để tạo kết nối trao đổi thông tin an toàn giữa khách hàng
(người dùng cố định/ di động) và trung tâm dữ liệu (dịch vụ web, mail, truy cập từ
xa…) sẽ sử dụng một thiết bị cho phép tạo kênh SSL. Thiết bị này sẽ mã hóa/ giải
mã luồng thông tin theo yêu cầu từng bên. Quá trình bắt tay giữa 2 bên đã được mô
tả ở phần trước

5.2.4. Ứng dụng của PKI trong hệ thống Single Sign On

Đăng nhập một lần (SSO - single sign-on) là một khái niệm không thể
thiếu đối với cơ sở hạ tầng an ninh. Giống như một hệ thống hoặc một ứng
dụng bất kỳ yêu cầu đăng nhập, cơ sở hạ tầng có phán đoán nào đó được mã
hoá một cách hiện của “định danh” người sử dụng sao cho nó có thể so sánh
đăng nhập được thử với cái được chờ đợi từ người sử dụng hợp pháp. Tuy
nhiên, “định danh” này được hiểu thông qua một mở rộng đầy đủ của cơ sở hạ
tầng (nó được công nhận như là tổng thể), cho nên nó là có thể cho mỗi hệ
thống và ứng dụng được lắp vào cơ sở hạ tầng. (Phương án này cho SSO có
một số nhược điểm, chẳng hạn như tính mềm dẻo bị giảm đi trong việc gọi tên
các thực thể chạy suốt cơ sở hạ tầng. Tuy nhiên, từ quan điểm hành chính và
khả năng quản lý, nó có thể hiệu quả hơn so với phương án khác của việc cho
phép “nhiều định danh” cho mỗi thực thể và ánh xạ từ một tới các giả danh
khác khi thực thể chuyển động trong nhiều hệ thống và ứng dụng.

Hình 5-14: Đăng nhập tới nhiều ứng dụng ở xa

Một lần đăng nhập là đủ để chiếm được quyền truy nhập tới nhiều thiết bị,
các miền, các máy chủ, nhiều hệ thống, nhiều ứng dụng,...Chú ý rằng các sự
kiện đăng nhập vẫn có thể được kết hợp lại với các cơ chế kiểm soát truy nhập
(cho phép) khác. Như vậy, một lần đăng nhập an toàn là điều mong muốn từ
quan điểm tính sử dụng bởi vì người sử dụng có ít hơn các mật khẩu cần nhớ
và chỉ cần biết một quy trình duy nhất để truy nhập nhiều hệ thống. Nó cũng là
rất mong muốn từ quan điểm an toàn bởi vì các mật khẩu ít thường xuyên được
vận chuyển trên mạng hơn và bởi vì khả năng là cao hơn để cho một mật khẩu
duy nhất được lựa chọn bởi người sử dụng sẽ là một mật khẩu “tốt”.
Một lần đăng nhập an toàn là một dịch vụ mà có thể đưa lại bởi cơ sở hạ
tầng an ninh cho tất cả các ứng dụng và thiết bị đang được sử dụng. Cơ sở hạ
tầng kết hợp các cơ chế được yêu cầu để phân tán an toàn thông tin xác thực
khi nó cần thiết và ở nơi nó cần thiết; các ứng dụng “nối vào” cơ sở hạ tầng để
truy nhập thông tin này khi cần thiết. Dịch vụ cơ sở hạ tầng này giải phóng
người sử dụng khỏi việc phải đăng nhập nhiều lần. Một lợi ích an toàn quan
trọng thêm vào đó là một cơ sở hạ tầng được thiết kế tốt có thể đảm bảo cho
người sử dụng chỉ cần đăng nhập vào máy cục bộ mà tại đó họ làm việc. Cho
nên, ít nhất trong một số trường hợp, các mật khẩu không truyền trên một
mạng có thể bị tổn thương, giảm đáng kể các mối hiểm hoạ tương ứng với việc
bắt giữ/ăn cắp mật khẩu và các tấn công lưu trữ/lặp lại mật khẩu. Hơn thế nữa,
một cơ sở hạ tầng được thiết kế tốt như vậy loại bỏ một số khó khăn tương ứng
với nhiều dạng khác của giải pháp SSO, chẳng hạn như thông tin trạng thái
đăng nhập cần phải được bảo quản tập trung (nó là bị tổn thương bởi tấn công
và biểu diễn điểm thất bại duy nhất cho hệ thống).

5.3. CÁC THIẾT BỊ PHẦN CỨNG AN TOÀN (HSM, USB TOKEN)

5.3.1. Vai trò của các thiết bị phần cứng an toàn trong hệ thống PKI

Hiện nay, công nghệ thẻ thông minh có thể tạo ra một môi trường an toàn để lưu
trữ khóa bí mật và thực thi các thao tác mật mã. Thiết bị USB Token và HSM dựa
trên công nghệ thẻ thông minh tạo ra môi trường lưu trữ và tính toán cách ly an
toàn và không thể nhân bản được nên không thể bị sao chép hoặc làm giả.

Hoạt động chứng thực điện tử (CTĐT) với ký số và bảo mật thông tin điện tử
(TTĐT) sử dụng mật mã khóa công khai, được hiện thực hóa qua các hoạt động
liên quan tới Chứng thư số (CTS). Đến lượt mình hoạt động ký số và bảo mật là
hoạt động mật mã nên độ an toàn mật mã là giữ bí mật khóa để ký số và lập mã và
đảm bảo tính toàn vẹn của các thao tác mật mã này.

Hoạt động CTĐT được giả thiết là thực hiện trong môi trường mạng máy tính
không tin cậy. Hạ tầng PKI cung cấp các dịch vụ cần thiết về CTS, nên phần mềm
Core CA sẽ thực hiện nhiều “thao tác mật mã” để sinh tham số và cặp khóa cho
CTS, ký số và mã hoá TTĐT khi cần thiết.

Trong phần mềm thuê bao tại các máy tính trạm, các phần mềm ràng buộc PKI
cũng tiến hành các thao tác mật mã để ký số và mã hóa các TTĐT. Hoạt động
CTĐT chỉ được coi là an toàn nếu các thao tác mật mã và khóa mật mã được bảo
vệ an toàn.

Để bảo đảm an toàn, khóa mật mã phải được bảo vệ không bị lộ khi lưu trữ cũng
như khi sử dụng. Các môđun phần mềm thực thi mật mã phải đảm bảo toàn vẹn,
không bị thay thế hoặc sửa đổi nhằm cài thêm các chức năng độc hại hoặc thực thi
không đúng chức năng. Môi trường mạng máy tính thông thường (môi trường vật
lý và môi trường lôgic) không thể đáp ứng được các yêu cầu an toàn này vì không
đủ khả năng bảo vệ chống lại sự tiếp cận trái phép bằng các phương pháp phân tích
mã hoặc các tấn công khác. Bởi vậy, cần phải tạo ra một môi trường có tính cách ly
cao để lưu trữ khóa bí mật và bảo đảm thực hiện các thao tác mật mã một cách an
toàn (cách ly cả về vật lý và lôgic).

Hiện nay, công nghệ thẻ thông minh (SmartCard) có thể tạo ra một môi trường an
toàn để lưu trữ khóa bí mật và thực thi các thao tác mật mã. Thẻ thông minh thực
chất là một máy tính chuyên dụng mà ở đó môi trường hoạt động được bảo vệ cả
về an toàn vật lý và an toàn lôgic. Có thể sinh các cặp khóa mật mã và lưu trữ
chúng bên trong các SmartCard này một cách an toàn mà không cần phải mã hóa
khóa bí mật, vì chúng chỉ được sử dụng nội tại trong thẻ. Hơn nữa, ở đây các
môđun mật mã và việc thực thi chúng cũng được đảm bảo tính toàn vẹn không thể
bị xóa hoặc sửa đổi.

Vấn đề giao tiếp an toàn giữa SmartCard với các máy tính trạm được thực hiện trên
các giao thức thông qua chuẩn giao diện mật mã PKCS#11. Giao tiếp vật lý giữa
SmartCard và máy tính trạm được thực hiện thông qua ba loại giao diện là USB,
giao diện đọc thẻ có tiếp xúc và giao diện đọc thẻ không tiếp xúc.

Các ứng dụng PKI hiện nay chủ yếu sử dụng giao diện USB sẵn có tại các máy
tính trạm cùng với các USB Token (là các SmartCard) để lưu trữ khóa bí mật và
môđun thao tác mật mã. Ngoài ra, người ta cũng sử dụng một loại SmartCard khác
với cùng chức năng nhưng phải đặt thêm các ổ đọc thẻ tại các máy tính trạm. Sử
dụng các USB Token lưu trữ CTS, khóa bí mật, các môđun mật mã và thực thi các
môđun mật mã này sẽ tạo ra môi trường an toàn cao cho hoạt động CTĐT. Để sử
dụng CTS trong việc ký số và mã hoá TTĐT cần phải có đủ cả hai nhân tố là USB
Token (lưu trữ khóa bí mật và các môđun thao tác mật mã) và số bí mật cá nhân
PIN.
Loại SmartCard sử dụng tại phía hạ tầng PKI, với cùng chức năng nhưng phục vụ
được nhiều yêu cầu ký số và lập mã cùng một lúc do hiệu năng tính toán và lưu trữ
cao được gọi là Môđun an toàn phần cứng (HSM).

Thiết bị USB Token và HSM đều tạo ra môi trường lưu trữ và tính toán cách ly an
toàn và không thể nhân bản được nên không thể bị sao chép hoặc làm giả. Chất
lượng an toàn mật mã của HSM và USB Token được đánh giá tuân theo các tiêu
chuẩn quốc tế như Tiêu chuẩn Môđun mật mã an toàn (FIPS 140 - 2) và Tiêu chí
chung (Common Criteria - CC) hay Tiêu chuẩn ISO/IEC 15408.
Sau đây sẽ xem xét một số yêu cầu cơ bản về an toàn vật lý, an toàn lôgic và an
toàn kênh thứ cấp của các SmartCard  khi đưa vào ứng dụng thực tế trong hoạt
động CTĐT.

An toàn vật lý

Các thiết bị HSM và USB Token sẽ đảm bảo an toàn vật lý nếu chúng kháng được

đầy đủ các tấn công vật lý đặc trưng hiện nay. Bảo đảm an toàn vật lý nhằm phát
hiện và ngăn chặn được các tấn công trực tiếp đến phần cứng của SmartCard để
đọc khóa bí mật hoặc dịch ngược các hàm trong chip điện tử để tìm hiểu thuật
toán. Chúng ta cần phải hiểu rõ các tấn công vật lý lên các thiết bị SmartCard trước
khi đưa ra các giải pháp hữu hiệu để kháng lại các tấn công này.

Loại tấn công điển hình là sử dụng chất dung môi hóa học, các chất khắc axít và
biến mầu. Các SmartCard có thể bị bóc lớp và tách lớp vỏ đóng gói bên ngoài bởi
các chất khắc axít. Chất biến màu cũng là kỹ thuật khắc axít tiên tiến sử dụng sự
khác nhau của tốc độ khắc axít để làm lộ ra sự khác biệt vật chất tinh tế và xác định
được đâu là bit 0, đâu là bit 1 trong bộ nhớ ROM.

Bên cạnh đó là loại tấn công sử dụng kính hiển vi. Các kính hiển vi hạt điện
tử quét và quang học được sử dụng đối với các phân tích quang học và kỹ nghệ
dịch ngược. Một chip điện tử có thể bị phân tích nhằm làm lộ ra các khu vực đang
hoạt động và thậm chí là các mã chương trình đang thực hiện hay các giá trị dữ liệu
đang được chuyển đi.

Kẻ tấn công cũng có thể tiến hành loại tấn công sử dụng các loại trạm dò
thử. Các trạm dò thử này cho phép đặt các kim dò thử vào các dây dẫn bất kỳ trên
chip điện tử đã lột vỏ để tạo ra các kênh mới truyền ra bên ngoài. Dữ liệu trao đổi
giữa CPU và bộ nhớ có thể bị thu chặn và khôi phục đầy đủ mã thực hiện chương
trình hay dữ liệu chương trình kể cả các khóa bí mật.

Kẻ tấn công cũng có thể sử dụng chùm hạt ion tập trung để bắn các hạt ion
nhằm thực hiện các thay đổi trong vi mạch. Các ngắt mạch của các vi mạch có thể
được nối lại hay các tín hiệu ngầm bên trong có thể được truyền ra các dây dẫn bên
ngoài. Khả năng chống lại các tấn công vật lý của chip điện tử có thể thực hiện nhờ
việc thiết kế chip có độ phức tạp cao cùng với các cải thiện đáng kể về độ an toàn
vật lý.
 Với kích cỡ nhỏ và đa lớp,  SmartCard có thể chống lại việc sử dụng các
kính hiển vi quang học, chống lại việc dò thử và che giấu được các dòng dữ liệu
nhạy cảm bên trong. Cũng có thể tạo thêm lớp bảo vệ ngoài cùng có chứa một
“lưới” chứa các tín hiệu bảo vệ ngăn chặn việc phân tích xử lý dữ liệu động.

Ngoài ra còn có các biện pháp chống tấn công vật lý như: Sử dụng các cảm biến
với tín hiệu đo, các biến môi trường (như ánh sáng, nhiệt độ, nguồn điện và tần số
đồng hồ) để ngừng hoạt động của chip điện tử khi các điều kiện vượt quá giới hạn
nhằm giảm thiểu khả năng của kẻ tấn công muốn phân tích dữ liệu động trên chip;
Xáo trộn tần số truyền dữ liệu; Tạo ra một lôgic kết dính hay pha trộn tất cả các
khối chức năng để làm “rối” kẻ tấn công trong việc nhận biết các khối thành phần
chức năng và phân tích cấu trúc vật lý của chip điện tử.

An toàn logic

Các SmartCard sử dụng giao diện tuần tự để đưa ra các lệnh thực hiện. Chúng hỗ
trợ một số  tùy chọn lệnh đưa vào một kênh liên lạc đơn để trao đổi dữ liệu với bộ
đọc của SmartCard.

Bảo đảm tính bí mật và tính toàn vẹn của dữ liệu sẽ liên quan đến khả năng
chống lại các tấn công lôgic. Bởi vậy, chúng ta cần hiểu rõ về các tấn công điển
hình để đưa ra các biện pháp khắc phục chúng. Sau đây là một số tấn công logic
điển hình:

-  Tấn công sử dụng các lệnh được che giấu là loại tấn công lạm dụng một số
câu lệnh của hệ điều hành Smartcard để khôi phục dữ liệu từ đó hoặc sửa đổi dữ
liệu bên trong SmartCard. Các lệnh này có thể vẫn còn kích hoạt từ pha khởi hoạt
hay thực hiện của ứng dụng trước đó.

- Tấn công hủy hoại tham số và tràn bộ đệm  xảy ra khi các khả năng diễn
dịch sai các tham số của các lệnh có thể dẫn đến các kết quả bất thường.
- Tấn công truy cập tệp xảy ra khi các hệ thống tệp của SmartCard đưa ra chi tiết
các quyền cho phép truy cập đến các tệp và các thư mục; Các quyền này xác định
quy trình an toàn để truy cập tệp. Các quyền cho phép truy cập có thể làm rối hệ
điều hành của SmartCard với các tương tác phức tạp:

-  Bị tổn hại bởi các chương trình Applet độc hại.

 -  Tấn công vào lỗ hổng trong giao thức liên lạc giữa SmartCard và máy
trạm (được điều khiển bởi giao thức quản lý kiểm soát dòng dữ liệu và phục hồi
lỗi), Giao thức mật mã, thiết kế và quá trình thực thi.

Tấn công lôgic phụ thuộc vào độ phức tạp chương trình phần mềm của
SmartCard. Số lượng các lỗ hổng về an toàn sẽ tăng lên cùng với kích cỡ của mã
phần mềm. Sau đây là các biện pháp chống lại các tấn công lôgic:

- Thực thi thiết kế có cấu trúc, là phương pháp tạo ra phần mềm từ các
môđun chức năng nhỏ để có thể dễ dàng nắm bắt và kiểm tra, nhằm tránh những
sai sót trong phần mềm và phát hiện sự phá hoại ngầm. Với phương pháp kiểm tra
hình thức sử dụng các mô hình toán học để chứng tỏ tính đúng đắn của các chức
năng thì có thể chứng minh tường minh được rằng một chương trình được phát
triển có đúng hoàn toàn với thiết kế hay không.

-  Thực hiện kiểm thử, là việc kiểm tra trên thực nghiệm của quá trình thực thi
SmartCard. Kiểm thử giúp nhanh chóng phát hiện ra các lỗi thông dụng. Tuy
nhiên, việc chưa phát hiện ra lỗi chưa chứng tỏ rằng chương trình không có lỗi.
- Chuẩn hóa các giao diện và các ứng dụng bằng cách tái sử dụng phần mềm đã
được chứng tỏ là đúng đắn để làm giảm thiểu khả năng xuất hiện lỗi. Dùng các
phần mềm đã được kiểm chứng qua sử dụng nhiều lần sẽ ít có khả năng để lại sai
sót.
- Hướng đến sử dụng hệ điều hành Java Card, là ngôn ngữ hướng đối tượng được
thiết kế dành cho các chức năng an toàn.

Trong thiết bị SmartCard, giao thức lôgic kết nối với máy tính trạm thông
qua chuẩn PKCS#11 là tập hợp các hàm API phục vụ cho các thao tác mật mã với
các thuộc tính “không thiết lập lại được” để bảo đảm kiểm soát chặt chẽ hoạt động
của SmartCard. Do vậy, khóa bí mật không thể bị truyền ra ngoài giới hạn vật lý
của SmartCard. Các thao tác ký số, giải mã sử dụng khóa bí mật đều được thực
hiện bên trong phạm vi vật lý của SmartCard. Các môđun chương trình thao tác
mật mã, khóa công khai và CTS được lưu trữ bên trong thiết bị SmartCard không
thể bị sửa đổi, cho dù các thông tin công khai có thuộc tính cho phép được đọc
thông tin ra mà không cần xuất trình số bí mật cá nhân PIN.

An toàn lôgic của thiết bị HSM và USB Token được thiết kế ở mức cao hơn
nhiều so với các máy tính thông thường, các hệ thống nhúng... và tùy biến phần
mềm trong các thiết bị này rất phức tạp.  Vì vậy, chỉ có các hãng công nghệ lớn sản
xuất các thiết bị này mới có khả năng thực hiện tùy biến được phần “sụn” và phần
mềm hệ điều hành cũng như các phần mềm ứng dụng khác. Điều đó cũng làm
giảm đáng kể sự xuất hiện các mã độc bên trong thiết bị.

An toàn kênh thứ cấp

Bên cạnh an toàn vật lý và an toàn lôgic, SmartCard còn phải có khả năng
chống lại các tấn công không tiếp xúc trực tiếp có kết hợp cả phần cứng và phần
mềm, gọi là các tấn công kênh thứ cấp, hay tấn công kênh kề (Side Channel
Attacks).
SmartCard được thiết kế với các mạch tích hợp IC tạo thành từ các mạch bán dẫn
nhạy cảm với các hiện tượng vật lý như dòng điện và bức xạ. Tấn công kênh thứ
cấp sử dụng các hiện tượng vật lý để phân tích hay điều khiển hành vi chip điện tử
của SmartCard. Các tấn công này có thể thực hiện mà  không cần tác động vật lý
(hay tiếp xúc trực tiếp) tới thiết bị. Một số loại tấn công kênh thứ cấp điển hình
gồm:
- Tấn công phân tích lượng sai dòng điện (Differential Power Analysis), là tấn
công thống kê lên thuật toán mật mã, so sánh giả thuyết với kết quả đo được và
thường có khả năng trích ra khóa lập mã từ SmartCard hay từ thiết bị tính toán
khác.
- Tấn công gây sự cố dòng điện, trong trường hợp khi các bộ vi xử lý được thiết kế
để vận hành từ một điện thế ổn định, khi mà các sự ngắt nguồn điện sẽ phá hỏng
các ứng dụng đang chạy hay làm khởi động lại vi mạch. Gây sự cố dòng điện sẽ
ảnh hưởng đến cả các giá trị ngưỡng và các giá trị được lưu trữ. Các thiết kế  bên
trong khác nhau sẽ gây ra các tác động khác nhau và có thể gây ra sự diễn dịch sai
của giá trị hiện hành.

Người ta có thể khắc phục các tấn công kênh thứ cấp trên ba mức bảo vệ
khác nhau:

- Khắc phục tại mức phần cứng, là các biện pháp dựa trên phần cứng nhằm
làm giảm thiểu khả năng nhạy cảm đối với phân tích kênh thứ cấp. Nó giảm thiểu
tỷ lệ tín hiệu đối với nhiễu và làm cho các tấn công khó xảy ra hơn. Người ta cân
bằng các vi mạch và giảm thiểu các phát xạ điện từ để hạ thấp tín hiệu điện, thực
hiện các quá trình ngẫu nhiên tương tranh nhằm làm tăng biên độ mức nhiễu. Xử lý
các ngắt và tốc độ đồng hồ biến thiên được đưa vào với các nhiễu đếm thời gian để
ngăn cản hoặc cản trở sự liên kết của các vết.

- Khắc phục tại mức phần mềm bao gồm các giải pháp: Thực hiện sắp thứ tự
quá trình ngẫu nhiên đối với các  giải pháp thay thế thuật toán song song nhằm
giảm thiểu các tín hiệu liên quan; Thực hiện các trễ ngẫu nhiên hay các tuyến thay
thế để thêm vào nhiễu đếm thời gian, nhằm cản trở sự liên kết của các vết và làm
hỏng chất lượng của vết lượng sai; Cài đặt các vận hành khóa cố định thời gian để
khử những tham số phụ thuộc thời gian trong nguyên liệu khóa và tránh cho các
giá trị trung gian sự phân tích dòng điện đơn giản bằng theo dõi trực quan các vết;
Thêm vào các giá trị ngẫu nhiên (sẽ được khử đi sau này) làm mù các giá trị trung
gian nhằm ngăn chặn rò rỉ thông tin hữu ích. Những giá trị này được thiết kế cẩn
thận để bù lại cho sự chênh lệch gây ra bởi các giá trị ngẫu nhiên.
-  Khắc phục tại mức ứng dụng là việc kiểm tra mã số bí mật cá nhân PIN. Mã số
này bị khóa lại sau ba lần thử liên tục không thành công sẽ là sự bảo vệ hữu ích
chống lại phân tích lượng sai. Việc bộc lộ đầu vào và đầu ra của các thuật toán mật
mã cần phải được hạn chế hoặc giới hạn để tránh kẻ tấn công thực hiện phân tích
lượng sai.

- Cách khắc phục đối với tấn công gây sự cố dòng điện là sử dụng các cảm
biến đối với điện thế, tần số và nhiệt độ. Tuy vậy, thiết lập cảm biến có thể tác
động đến độ tin cậy và tiềm năng gây ra các tác động không mong muốn trong các
môi trường của SmartCard.

Các biện pháp  kết hợp cả phần cứng và phần mềm sẽ được thực thi để bảo
vệ và phục hồi chống lại khả năng chèn lỗi vào chương trình. Kiểm tra các quyết
định điều khiển luồng chương trình cốt yếu và các yếu tố mật mã giúp thực hiện
việc phát hiện lỗi. Tính hợp lệ của các kết quả được thực hiện bằng cách tính kết
quả hai lần và so sánh chúng với nhau.

5.3.2. Thiết bị an toàn cá nhân USB Token

Thiết bị USB Token tại phía thuê bao PKI là giải pháp có khả năng bảo đảm an
toàn cao cho khóa bí mật dùng để sinh CKS hay mã hóa các tệp tin. Việc thực hiện
các thao tác mật mã đối với USB Token cần có số bí mật PIN cho nên dù đã lấy
được USB Token và CTS nhưng kẻ tấn công cũng không sử dụng được vì không
có số PIN của thuê bao. Sử dụng USB Token, đáp ứng các yêu cầu an toàn vật lý
và lôgic đặt ra và thuê bao có thể cách ly hoàn toàn hoạt động CTĐT khỏi môi
trường máy tính không an toàn. Hơn nữa, đây là phương thức an toàn hai nhân tố
nên kẻ tấn công phải có cả USB Token và số bí mật cá nhân PIN của thuê bao mới
có thể  giả mạo thuê bao trong giao dịch điện tử. Trường hợp khóa bí mật ký số bị
lộ rất khó xảy ra.

Đối với các USB Token chứa khóa bí mật, các môđun cũng như thực thi các thao
tác mật mã thì giao diện giữa SmartCard và máy trạm cần theo chuẩn PKCS#11.

5.3.3. Thiết bị an toàn cho hệ thống PKI HSM

Thiết bị HSM làm tăng hiệu suất hoạt động của dịch vụ CTĐT của hạ tầng PKI khi
cần đáp ứng một lượng lớn các nhu cầu tại một thời điểm. Đó là các nhu cầu về
sinh tham số mật mã, sinh CKS, nhu cầu về kiểm tra hợp lệ CTS, CKS hay các
dịch vụ an toàn mật mã khác. Chính vì vậy mà các thiết bị HSM lắp đặt tại hạ tầng
PKI thường được gọi là CryptoServer.

Đối với thiết bị HSM thì có thể sử dụng giao diện mạng hoặc giao diện PCI, nhưng
vẫn giao tiếp qua chuẩn PKCS#1.

5.4. BÀI THỰC HÀNH SỐ 3

5.4.1. Sử dụng các chứng thư số để ký số mã hóa các tài liệu điện tử
dạng PDF, Word, thư điện tử,…

Sử dụng hệ thống CA phân cấp ở bài thực hành số 1, sinh viên thực hiện

- Sinh chứng thư số ký, mã trên các hệ thống CA phân cấp (sinh chứng thư số
cho 2 người dùng để kiểm tra chéo)
- Cài đặt các phần mềm MS office, PDF
 Chương 6. HÀNH LANG PHÁP LÝ PKI Ở VIỆT NAM VÀ
XU HƯỚNG PHÁT TRIỂN PKI
6.1. MÔ HÌNH PKI TẠI VIỆT NAM

Hình 6-1: Mô hình PKI ở Việt Nam

Hiện nay, tại Việt Nam có hai hệ thống PKI chính đó là:
 - Hệ thống PKI công cộng do Bộ Thông tin và Truyền thông quản lý và cấp
phép phục vụ các giao dịch công cộng, kinh tế xã hội (bao gồm các giao dịch G2B,
G2C, B2B, B2C, C2C)
- Hệ thống thứ hai là hệ thống PKI chuyên dùng Chính phủ do Ban Cơ yếu
Chính phủ thiết lập và duy trì phục vụ các cơ quan thuộc hệ thống chính trị: giao
dịch điện tử nội bộ cơ quan nhà nước và giữa các cơ quan nhà nước với nhau; Các
thông tin chỉ đạo, điều hành, tác nghiệp của cơ quan nhà nước các cấp

6.2. HÀNH LANG PHÁP LÝ

Trong thời gian gần đây, đặc biệt là sau khi có Luật Giao dịch điện tử (GDĐT)
số 51/2005/QH11 ngày 29 tháng 11 năm 2005, việc ứng dụng Công nghệ Thông
tin (CNTT) vào các hoạt động lãnh đạo, điều hành các cơ quan Đảng, nhà nước đã
phát triển mạnh mẽ và mang lại các hiệu quả bước đầu quan trọng, đặc biệt là các
văn bản quy phạm pháp luật của nhà nước và các văn bản của Đảng đã tạo ra hành
lang pháp lý và các điều kiện thiết thực nhằm thúc đẩy mạnh mẽ quá trình triển
khai ứng dụng chứng thực và chữ ký số- một yêu cầu quan trọng trong quá trình
xây dựng Chính phủ điện tử mà trước hết là phải triển khai có hiệu quả ở từng cơ
quan, bộ, ngành thuộc hệ thống chính trị

Luật Giao dịch điện tử số 51/2005/QH11 ngày 29 tháng 11 năm 2005 đã tạo
hành lang pháp lý quan trọng nhằm thúc đẩy mạnh mẽ các ứng dụng Công nghệ
Thông tin (CNTT), điều chỉnh các quan hệ phát sinh từ giao dịch điện tử (GDĐT)
trong tất cả các lĩnh vực KTXH, quốc phòng, an ninh và quản lý điều hành đất
nước…,đảm bảo quyền lợi hợp pháp của Nhà nước, tổ chức và cá nhân; đảm bảo
sự bình đẳng và an toàn trong GDĐT; Tạo hành lang pháp lý cho các bên tham gia
GDĐT; Công nhận giá trị pháp lý của thông điệp điện tử, chữ ký điện tử và dịch vụ
chứng thực chữ ký điện tử với các điều kiện an toàn kèm theo. Quy định quyền lợi
và trách nhiệm của các bên có liên quan.

Các loại hình GDĐT của cơ quan nhà nước gồm có: GDĐT nội bộ cơ quan
Nhà nước, GDĐT giữa các cơ quan Nhà nước với nhau, GDĐT giữa các cơ quan
Nhà nước với cơ quan, tổ chức, cá nhân. Trong đó, GDĐT giữa các cơ quan Nhà
nước phải được chứng thực bởi tổ chức chứng thực điện tử do cơ quan Nhà nước
có thẩm quyền.
 Tiếp theo, Nghị định 64/2007/NĐ-CP ngày 10 tháng 4 năm 2007 về ứng
dụng CNTT trong các hoạt động của cơ quan nhà nước đã Quy định và tạo hành
lang pháp lý trong việc thúc đẩy ứng dụng CNTT trong hoạt động của cơ quan Nhà
nước: Quy định các điều kiện đảm bảo ứng dụng CNTT trong các cơ quan nhà
nước: hạ tầng thông tin, cung cấp thông tin, phát triển nguồn nhân lực CNTT...;
Quy định hoạt động các cơ quan Nhà nước trên môi trường mạng: quy trình công
việc, quản lý văn bản điện tử, đảm bảo an toàn và bảo mật thông tin, sử dụng chữ
ký điện tử để xác nhận văn bản điện tử...; Quy định trách nhiệm của các cơ quan,
Bộ, ngành trong việc ứng dụng CNTT

Nghị định của Chính phủ số 26/2007/NĐ-CP ngày 15 tháng 2 năm 2007 quy
định chi tiết thi hành Luật GDĐT về chữ ký số và dịch vụ chứng thực chữ ký số,
đối tượng áp dụng là cơ quan, tổ chức cung cấp dịch vụ chứng thực chữ ký số và
cơ quan, tổ chức, cá nhân lựa chọn sử dụng chữ ký số và dịch vụ chứng thực chữ
ký số trong GDĐT.

Nghị định đã quy định với các nội dung quan trọng nhằm đảm bảo độ an toàn
và tin cậy của tài liệu điện tử và thúc đẩy quá trình sử dụng, làm cơ sở để thúc đẩy
quá trình ứng dụng công nghệ thông tin, các dịch vụ hành chính công và tiến tới
Chính phủ điện tử.

Nghị định cũng xác định chính sách phát triển dịch vụ chứng thực chữ ký số của
nhà nước, khuyến khích việc ứng dụng chữ ký số và dịch vụ chứng thực chữ ký số
trong tất cả các lĩnh vực của đời sống xã hội.

6.2.1. Luật giao dịch điện tử số 51/2005/QH11

Cơ cấu của luật

Luật Giao dịch điện tửgồm 8 chương với 54 điều.

Chương I:Những quy định chung, gồm 9 điều, từ Điều 1 đến Điều 9;

Chương II:Thông điệp dữ liệu, gồm 11 điều, từ Điều 10 đến Điều 20;

Chương III: Chữ ký điện tửvà chứng thực chữký điện tử, gồm 12 điều, từ
Điều 21 đến Điều 32;
 Chương IV: Giao kết và thực hiện hợp đồng điện tử, gồm 6 điều, từ Điều 33
đến Điều 38;

Chương V: Giao dịch điện tửcủa cơquan nhà nước, gồm 5 điều, từ Điều 39
đến Điều 43;

Chương VI: An ninh, an toàn, bảo vệ, bảo mật trong giao dịch điện tử, gồm 6 điều,
từ Điều 44 đến Điều 49;

Chương VII: Giải quyết tranh chấp và xửlý vi phạm, gồm 3 điều, từ Điều 50 đến
Điều 52;

Chương VIII: Điều khoản thi hành, gồm 2 điều, Điều 53 và Điều 54.

Những nội dung cơ bản của Luật

1) Chương I: Những quy định chung

Chương này quy định về phạm vi điều chỉnh; đối tượng áp dụng; áp dụng Luật
Giao dịch điện tử; giải thích từ ngữ; nguyên tắc chung tiến hành giao dịch điện tử;
chính sách phát triển và ứng dụng giao dịch điện tử; nội dung quản lý nhà nước về
hoạt động giao dịch điện tử; trách nhiệm quản lý nhà nước về hoạt động giao dịch
điện tử; các hành vi bị nghiêm cấm trong giao dịch điện tử.

Về phạm vi điều chỉnh, Luật này quy định về giao điện tử trong hoạt động của các
cơ quan nhà nước; trong lĩnh vực dân sự, kinh doanh, thương mại và các lĩnh vực
khác do pháp luật quy định.

Việc cấp giấy chứng nhận quyền sử dụng đất, quyền sở hữu nhà và các bất động
sản khác, văn bản về thừa kế, giấy đăng ký kết hôn, quyết định ly hôn, giấy khai
sinh, giấy khai tử, hối phiếu và các giấy tờ có giá khác không áp dụng các quy định
của Luật giao dịch điện tử.

Về nguyên tắc, cơ quan, tổ chức, cá nhân có quyền tự thỏa thuận và tự nguyện lựa
chọn phương thức giao dịch (theo phương thức truyền thống hay giao dịch điện
tử), tự thỏa thuận về việc lựa chọn loại công nghệ thực hiện giao dịch và phải chịu
trách nhiệm về mọi hành vi của mình trong giao dịch điện tử. Không một công
nghệ nào được coi là duy nhất trong giao dịch điện tử.
Trong giao dịch điện tử, sự bình đẳng và an toàn phải được bảo đảm; quyền và lợi
ích hợp pháp của cơ quan, tổ chức, cá nhân, lợi ích của nhà nước, lợi ích công cộng
phải được bảo vệ.

Theo quy định tại Điều 9, các hành vi sau đây bị nghiêm cấm trong giao dịch điện

tử:

Cản trở việc lựa chọn sử dụng giao dịch điện tử.

Cản trở hoặc ngăn chặn trái phép quá trình truyền, gửi, nhận thông điệp dữ liệu.

Thay đổi, xoá, huỷ, giả mạo, sao chép, tiết lộ, hiển thị, di chuyển trái phép một
phần hoặc toàn bộ thông điệp dữ liệu.

Tạo ra hoặc phát tán chương trình phần mềm làm rối loạn, thay đổi, phá hoại hệ
thống điều hành hoặc có hành vi khác nhằm phá hoại hạ tầng công nghệ về giao
dịch điện tử.

Tạo ra thông điệp dữ liệu nhằm thực hiện hành vi trái pháp luật.

Gian lận, mạo nhận, chiếm đoạt hoặc sử dụng trái phép chữ ký điện tử của người
khác.

2) Chương II: Thông điệp dữ liệu

Thông điệp dữ liệu là thông tin được tạo ra, được gửi đi, được nhận và được lưu
trữ bằng phương tiện điện tử. Thông điệp dữ liệu được thể hiện dưới hình thức trao
đổi dữ liệu điện tử, chứng từ điện tử, thư điện tử, điện tín, điện báo, fax và các hình
thức tương tự khác.

Tinh thần xuyên suốt của chương này là pháp luật công nhận giá trị pháp lý của
thông điệp dữ liệu. Chương này có 2 mục: Mục 1 quy định về hình thức thể hiện
thông điệp dữ liệu; giá trị pháp lý của thông điệp dữ liệu; thông điệp dữ liệu có giá
trị như văn bản; thông điệp dữ liệu có giá trị như bản gốc; thông điệp dữ liệu có giá
trị làm chứng cứ; lưu trữ thông điệp dữ liệu. Mục 2 gồm quy định về người khởi
tạo thông điệp dữ liệu; thời điểm, địa điểm gửi thông điệp dữ liệu; nhận thông điệp
dữ liệu; thời điểm, địa điểm nhận thông điệp dữ liệu; gửi, nhận tự động thông điệp
dữ liệu.
Trong trường hợp pháp luật yêu cầu thông tin phải được thể hiện bằng văn bản thì
thông điệp dữ liệu được xem là đáp ứng yêu cầu này nếu thông tin chứa trong
thông điệp dữ liệu đó có thể truy cập và sử dụng được để tham chiếu khi cần thiết.

Thông điệp dữ liệu có giá trị như bản gốc (Điều 13) khi đáp ứng được các điều
kiện sau:

Nội dung của thông điệp dữ liệu được bảo đảm toàn vẹn kể từ khi được khởi tạo
lần đầu tiên dưới dạng một thông điệp dữ liệu hoàn chỉnh (nội dung thông điệp
chưa bị thay đổi, trừ những thay đổi về hình thức phát sinh trong quá trình gửi, lưu
trữ hoặc hiển thị thông điệp đó);

Nội dung của thông điệp dữ liệu có thể truy cập và sử dụng được dưới dạng
hoàn chỉnh khi cần thiết.

Thông điệp dữ liệu có giá trị làm chứng cứ (Điều 14). Giá trị chứng cứ của thông
điệp dữ liệu được xác định căn cứ vào độ tin cậy của cách thức khởi tạo, lưu trữ
hoặc truyền gửi thông điệp dữ liệu; cách thức bảo đảm và duy trì tính toàn vẹn của
thông điệp dữ liệu; cách thức xác định người khởi tạo và các yếu tố phù hợp khác.

3) Chương III: Chữ ký điện tử và chứng thực chữ ký điện tử

Chương này gồm 3 mục

Mục 1: Giá trị pháp lý của chữ ký điện tử, quy định về chữ ký điện tử; điều kiện
bảo đảm an toàn cho chữ ký điện tử; nguyên tắc sử dụng chữ ký điện tử; giá trị
pháp lý của chữ ký điện tử; nghĩa vụ của người ký chữ ký điện tử; nghĩa vụ của
bên chấp nhận chữ ký điện tử; thừa nhận chữ ký điện tử và chứng thư điện tử nước
ngoài.

Mục 2: Dịch vụ chứng thực điện tử, quy định về hoạt động dịch vụ chứng thực chữ
ký điện tử; nội dung của chứng thư điện tử; tổ chức cung cấp dịch vụ chứng thực
chữ ký điện tử; quyền và nghĩa vụ của tổ chức cung cấp dịch vụ chứng thực chữ ký
điện tử.

Mục 3: Quản lý dịch vụ chứng thực chữ ký điện tử quy định về các điều kiện để
được cung cấp dịch vụ chứng thực chữ ký điện tử.
Chữ ký điện tử là chữ ký được tạo lập dưới dạng từ, chữ, số, ký hiệu, âm thanh
hoặc các hình thức khác bằng phương tiện điện tử, gắn liền hoặc kết hợp một cách
lôgic với thông điệp dữ liệu. Chữ ký điện tử có giá trị xác nhận người ký thông
điệp dữ liệu và xác nhận sự chấp thuận của người đó đối với nội dung thông điệp
dữ liệu được ký.

Theo quy định của Điều 22 , chữ ký điện tử được xem là bảo đảm an toàn nếu
được kiểm chứng bằng một quy trình kiểm tra an toàn do các bên giao dịch thoả
thuận và đáp ứng được các điều kiện sau đây:

Dữ liệu tạo chữ ký điện tử chỉ gắn duy nhất với người ký trong bối cảnh dữ liệu

đó được sử dụng;

Dữ liệu tạo chữ ký điện tử chỉ thuộc sự kiểm soát của người ký tại thời điểm ký;

Mọi thay đổi đối với chữ ký điện tử sau thời điểm ký đều có thể bị phát hiện;

Mọi thay đổi đối với nội dung của thông điệp dữ liệu sau thời điểm ký đều có
thể bị phát hiện.

Về giá trị pháp lý của chữ ký điện tử, trong trường hợp pháp luật quy định văn bản
cần có chữ ký thì yêu cầu đó đối với một thông điệp dữ liệu được xem là đáp ứng
nếu chữ ký điện tử được sử dụng để ký thông điệp dữ liệu đó đáp ứng được các
điều kiện sau:

Phương pháp tạo chữ ký điện tử cho phép xác minh được người ký và chứng tỏ
được sự chấp thuận của người ký đối với nội dung thông điệp dữ liệu;

Phương pháp đó là đủ tin cậy và phù hợp với mục đích mà theo đó thông điệp
dữ liệu được tạo ra và gửi đi.

Giá trị pháp lý của chữ ký điện tử và chứng thư điện tử nước ngoài được nhà nước
công nhận nếu chữ ký điện tử hoặc chứng thư điện tử đó có độ tin cậy tương đương

với độ tin cậy của chữ ký điện tử và chứng thư điện tử theo quy định của pháp luật.
Việc xác định mức độ tin cậy của chữ ký điện tử và chứng thư điện tử nước ngoài
phải căn cứ vào các tiêu chuẩn quốc tế đã được thừa nhận, điều ước quốc tế mà
Cộng hòa xã hội chủ nghĩa Việt Nam là thành viên và các yếu tố có liên quan khác
(khoản 1 Điều 27).
Chứng thực chữ ký điện tử là việc xác nhận cá nhân, tổ chức được chứng thực là
người ký chữ ký điện tử. Dịch vụ chứng thực chữ ký điện tử bao gồm các hoạt
động:

Cấp, gia hạn, tạm đình chỉ, phục hồi, thu hồi chứng thư điện tử.

Cung cấp thông tin cần thiết để giúp chứng thực chữ ký điện tử của người ký
thông điệp dữ liệu.

Cung cấp các dịch vụ khác liên quan đến chữ ký điện tử và chứng thực chữ ký

điện tử theo quy định của pháp luật.

4) Chương IV: Giao kết và thực hiện hợp đồng điện tử

Nội dung cơ bản của chương này là công nhận giá trị pháp lý của hợp đồng điện tử,
quy định về hợp đồng điện tử; thừa nhận giá trị pháp lý của hợp đồng điện tử;
nguyên tắc giao kết và thực hiện hợp đồng điện tử; giao kết hợp đồng điện tử; việc
nhận, gửi, thời điểm nhận, gửi thông điệp dữ liệu trong giao kết và thực hiện hợp
đồng điện tử; giá trị pháp lý của thông báo trong giao kết và thực hiện hợp đồng
điện tử.

Hợp đồng điện tử là hợp đồng được thiết lập dưới dạng thông điệp dữ liệu theo quy
định của Luật này. Việc giao kết và thực hiện hợp đồng điện tử dựa trên các
nguyên tắc:

1. Các bên tham gia có quyền thỏa thuận sử dụng phương tiện điện tử trong giao
kết và thực hiện hợp đồng.

2. Việc giao kết và thực hiện hợp đồng điện tử phải tuân thủ các quy định của

Luật này và pháp luật về hợp đồng.

3. Khi giao kết và thực hiện hợp đồng điện tử, các bên có quyền thoả thuận về yêu
cầu kỹ thuật, chứng thực, các điều kiện bảo đảm tính toàn vẹn, bảo mật có liên
quan đến hợp đồng điện tử đó.

5) Chương V: Giao dịch điện tử của cơ quan Nhà nước

Chương này quy định về giao dịch điện tử của cơ quan Nhà nước (cả lập pháp,
hành pháp và tư pháp), quy định về các loại hình giao dịch điện tử của cơ quan
Nhà nước; nguyên tắc tiến hành giao dịch điện tử của cơ quan Nhà nước; bảo đảm
an toàn, bảo mật và lưu trữ thông tin điện tử trong cơ quan Nhà nước; trách nhiệm
của cơ quan Nhà nước trong trường hợp hệ thống thông tin điện tử bị lỗi; trách
nhiệm của tổ chức, cá nhân trong giao dịch điện tử với cơ quan Nhà nước.

Theo quy định tại Điều 39, các loại hình giao dịch điện tử của cơ quan Nhà nước
bao gồm: Giao dịch điện tử trong nội bộ cơ quan Nhà nước; giao dịch điện tử giữa
các cơ quan Nhà nước với nhau; giao dịch điện tử giữa cơ quan Nhà nước với tổ
chức, cá nhân.

6) Chương VI: An ninh, an toàn, bảo vệ, bảo mật trong giao dịch điện tử

Chương này quy định về bảo đảm an ninh, an toàn trong giao dịch điện tử; bảo vệ
thông điệp dữ liệu; bảo mật thông tin trong giao dịch điện tử; trách nhiệm của tổ
chức cung cấp dịch vụ mạng; trách nhiệm của cơ quan, tổ chức, cá nhân khi có yêu
cầu của cơ quan Nhà nước có thẩm quyền; quyền và trách nhiệm của cơ quan Nhà
nước có thẩm quyền.

Điều 46 quy định: cơ quan, tổ chức, cá nhân có quyền lựa chọn các biện pháp bảo
mật phù hợp với quy định của pháp luật khi tiến hành giao dịch điện tử; không
được sử dụng, cung cấp hoặc tiết lộ thông tin về bí mật đời tư hoặc thông tin của
cơ quan, tổ chức, cá nhân khác mà mình tiếp cận hoặc kiểm soát được trong giao
dịch điện tử nếu không được sự đồng ý của họ, trừ trường hợp pháp luật có quy
định khác.

Tổ chức cung cấp dịch vụ mạng có trách nhiệm phối hợp với các cơ quan hữu quan
xây dựng quy chế quản lý và các biện pháp kỹ thuật để phòng ngừa, ngăn chặn
việc sử dụng dịch vụ mạng nhằm phát tán các thông điệp dữ liệu có nội dung
không phù hợp với truyền thống văn hoá, đạo đức của dân tộc, gây phương hại đến
an ninh quốc gia, trật tự, an toàn xã hội hoặc vi phạm các quy định khác của pháp
luật; phải chịu trách nhiệm trước pháp luật nếu không kịp thời loại bỏ những thông
điệp dữ liệu đó khi đã nhận được thông báo của cơ quan nhà nước có thẩm quyền
(Điều 47).

7) Chương VII: Giải quyết tranh chấp và xử lý vi phạm

Chương này quy định có tính nguyên tắc về xử lý vi phạm pháp luật trong giao
dịch điện tử; tranh chấp trong giao dịch điện tử; giải quyết tranh chấp trong giao
dịch điện tử.

Theo quy định tại Điều 50, người có hành vi vi phạm pháp luật về giao dịch điện tử
thì tuỳ theo tính chất, mức độ vi phạm mà bị xử lý kỷ luật, xử phạt hành chính
hoặc bị truy cứu trách nhiệm hình sự, nếu gây thiệt hại thì phải bồi thường theo
quy định của pháp luật; Cơ quan, tổ chức có hành vi vi phạm pháp luật trong giao
dịch điện tử thì tuỳ theo tính chất, mức độ vi phạm mà bị xử phạt hành chính, đình
chỉ hoạt động, nếu gây thiệt hại thì phải bồi thường theo quy định của pháp luật.

Nhà nước khuyến khích các bên giải quyết tranh chấp phát sinh trong giao dịch
điện tử thông qua hoà giải. Trong trường hợp các bên không hoà giải được thì thẩm
quyền, trình tự, thủ tục giải quyết tranh chấp về giao dịch điện tử được thực hiện
theo quy định của pháp luật (Điều 52).

8) Chương VIII: Điều khoản thi hành

Chương này quy định về hiệu lực thi hành và hướng dẫn thi hành Luật Giao dịch

điện tử.

6.2.2. Nghị định 26/2007/NĐ-CP

Ngày 15/02/2007, Chính phủ đã ban hành Nghị định số 26/2007/NĐ-CP quy
định chi tiết thi hành Luật Giao dịch điện tử về chữ ký số và dịch vụ chứng thực
chữ ký số.

Theo đó, trong trường hợp pháp luật quy định văn bản cần có chữ ký thì yêu
cầu đối với một thông điệp dữ liệu được xem là đáp ứng nếu thông điệp dữ liệu đó
được ký bằng chữ ký số...

Trong trường hợp pháp luật quy định văn bản cần được đóng dấu của cơ
quan, tổ chức thì yêu cầu đó đối với một thông điệp dữ liệu được xem là đáp ứng
nếu thông điệp dữ liệu đó được ký bởi chữ ký số của người có thẩm quyền theo
quy định của pháp luật về quản lý và sử dụng con dấu và chữ ký số đó được bảo
đảm an toàn theo quy định.
 Chữ ký số và chứng thư số nước ngoài được công nhận có giá trị pháp lý và
hiệu lực như chữ ký số và chứng thư do tổ chức cung cấp dịch vụ chứng thực chữ
ký số công cộng của Việt Nam cấp...

6.3. XU HƯỚNG PHÁT TRIỂN

Một số khẳng định rằng PKI sẽ không tồn tại lâu, những người khác lại
nói rằng nó chỉ tạm lắng xuống; những người khác cảm thấy rằng nó đang sống
và thực ra đang phồn vinh. Nhưng không phụ thuộc vào bạn đang thuộc vào
tập người nào, không có tranh cãi rằng PKI có đạt được hay không những đỉnh
cao về tính phổ cập và phổ biến mà những người đề xướng mạnh nhất đã dự
báo trong những ngày đầu tiên. Cái gì đã xảy ra? Tại sao không có một năm là
“năm của PKI”?
Không nghi ngờ gì, có nhiều nguyên nhân. Không thể có một nguyên nhân
duy nhất tại sao một tầm nhìn cụ thể của tương lai không diễn ra theo đúng
cách mà đã được miêu tả bởi những người ủng họ nó: Có quá nhiều biến động
đang diễn ra; quá nhiều hoàn cảnh trong thế giới thực mà không thể tiên liệu
được. Tuy nhiên, chúng ta có thể đề xuất rằng có 2 nguyên nhân là chủ yếu.
Thứ nhất, với PKI có thể có một lỗ hổng tương đối lớn trong nhiều tình
huống giữa cái được “bán” và cái được “mua”. Đặc biệt, trong những ngày
đầu của nó, mô trường thương mại, các nhà phân tích, những người bán hàng
quá tích cực thường miêu tả PKI như là một cài đặt đơn giản và sẽ giải quyết
tất cả các vấn đề an toàn. Trong thực tế, nhiều nhà quản trị tìm thấy rằng công
nghệ mà họ yêu cầu là tương đối khó hoặc phức tạp để cài đặt và chỉ giải quyết
một số vấn đề về an ninh an toàn. Sự không trùng lặp này thông thường mang
lại sự không hài lòng, tiếp theo là sự vỡ mộng, sau đó là giận dữ, sau đó là phê
phán. Kết quả là PKI đã sai khi thực ra về bản chất và giá trị của công nghệ –
nó là cái gì và nó có thể làm được gì- đã được tuyên truyền và hiểu không
đúng.
Nguyên nhân thứ hai, tuy vậy, cũng quan trọng như nguyên nhân trên.
Một số người ủng hộ PKI nhấn mạnh khía cạnh hạ tầng cơ sở của công nghệ
này, sự kiện rằng nó là nền tảng nằm dưới cho an toàn sao cho nhiều dịch vụ
khác nhau có thể xây dựng lên trên và nhiều ứng dụng khác nhau có thể tích
hợp với. Nhưng một phần lớn, những người ủng hộ này không hình dung được
rằng đôi khi một hạ tầng cơ sở cũng cần một hạ tầng cơ sở. Điều đó đúng cho
PKI. Khó có thể được xây dựng và khai thác công nghệ này trên cư sở không
có gì cả và làm cho nó hoạt động; một hạ tầng cơ sở khác cần phải tồn tại
trước đó. Khi chúng ta nghĩ về PKI, chúng ta phát hiện ra rằng, nó cũng cần
một cơ sở hạ tầng xung quanh nó để nó có thể sống được. Nó cần:

1. Một tổ chức có quyền lực được công nhận. Ai thiết lập và làm cho PKI hoạt
động? Thế nào là một đại lý có khả năng vươn lên? Sẽ là tốt đối với Alice
khi tự thiết đặt mình như là một CA trên nền nhà hoặc gara của mình,
nhưng còn ai nữa coi cô ta như là nguồn gốc của thẩm quyền? Ai có lý do
nào để tin các chứng chỉ mà cô ta phát hành cho mục đích bất kỳ? Sẽ ít vấn
đề trong nội bộ một công ty hoặc tổ chức đóng khác bởi vì con người hoặc
một ban cụ thể có thể được công bố như là tổ chức có quyền lực; tất cả
người làm thuê sẽ công nhận tổ chức này bởi vì thông báo của công ty, các
khẳng định chính thức của các chính sách và các thủ tục của công ty sẽ đem
lại sự đảm bảo rằng tổ chức có quyền lực này là hợp pháp. Trên Internet,
không có một cơ chế đảm bảo tương tự để nhanh chóng thiết lập tính hợp
pháp; do đó, một tổ chức có quyền lực được công nhận là khó tạo ra. Khi
không có tổ chức này, PKI Internet toàn cầu là khó tồn tại.

2. Động lực. Mục đích của PKI là gì? Tại sao nó được khai thác? Khi không
có một động cơ nào hay cùng với các động cơ sai, PKI sẽ không chứng
minh được là có ích và do đó sẽ không sống sót.

3. Những người sử dụng. Ai là những người sử dụng của PKI, và họ sử dụng

nó như thế nào? Thông thường, các mô tả đề xuất rằng những người sử
dụng có thể là con người, nhưng đó chỉ là một mô hình khái niệm. Trong
thực tế, nó là phần mềm mà tương tác trực tiếp với PKI: các ứng dụng mà
sử dụng các dịch vụ mà PKI cung cấp. Cái gì là giao diện giữa các ứng
dụng và các dịch vụ? Giao diện này có tiện lợi và dễ hiểu cho các ứng dụng
này và đối với người cần phải quản trị nó?
PKI cần một hạ tầng cơ sở thích hợp để trong đó nó có thể phồn vinh.
Trong nhiều trường hợp, tuy nhiên, hạ tầng này không tồn tại trong các môi
trường mà ở đó PKI được khai thác và trong các trường hợp khác, hạ tầng chỉ
có được một phần. Một thành công của PKI sẽ được mang lại nhưng bị giới
hạn.
 Có thể bàn luận rằng theo tất cả 3 lĩnh vực được yêu cầu mà đã được mô
tả sơ lược ở trên, thế giới đang tiến hoá để thoả mãn các nhu cầu hạ tầng của
PKI. Không thể đề xuất rằng một dạng bất kỳ của nỗ lực chủ ý, có điều phối để
ảnh hưởng tới thay đổi này là đều tốt. Tuy nhiên, các điều kiện cần cho PKI
phồn vinh đang bắt đầu được thiết lập.

Tổ chức có quyền lực được công nhận

PKI cần một tổ chức để đẩy mạnh việc khai thác và sử dụng các chứng chỉ
khoá công khai. Tổ chức này cần phải được công nhận bởi tất cả như là một tổ
chức có quyền lực trong lĩnh vực này, việc công nhận được hỗ trợ bằng các cơ
chế bảo đảm của một số dạng khác nhau. Hơn thế nữa, việc cho các chứng chỉ
định danh tin cậy đòi hỏi một kiểu nào đó của bước khởi tạo (thông thường gặp
nhau vật lý), tổ chức này cần phải là một tổ chức mà có thể thiết lập kiểu đó
của thủ tục một cách thành công. Tất cả điều đó có thể dường như khó đạt
được, nhưng câu trả lời là không khó: các chính phủ trên toàn thế giới đang
trong các giai đoạn khác nhau của kế hoạch cung cấp các chứng chỉ khoá công
khai tới các công dân của họ. Chính phủ của một nước có chính xác các tài
nguyên và các đặc trưng được đòi hỏi để trở thành một tổ chức có quyền lực
được công nhận cho PKI. Các bài báo mới, các tạp chí quảng cáo, quảng cáo
trên ti vi, gửi thư đồng loạt, lời truyền miệng giữa các công dân – tất cả có thể
mang lại sự đảm bảo cho khẳng định của chính phủ là một vai như vậy. Hơn
thế nữa, người dân ở phần lớn (không phải tất cả) các nước là sẵn sàng quen
với việc làm cuộc viếng thăm vật lý tới văn phòng chính quyền địa phương để
nhận được những cái tương tự như hộ chiếu, bằng lái xe; một thủ tục tương tự
để nhận “hộ chiếu điện tử” - được ghi trên đĩa mềm, CD, hoặc thẻ phần cứng,
ví dụ, không được xem là không bình thường, ngạc nhiên hoặc gây khó chịu
cho bất kỳ ai.

Động lực
Đăng nhập một lập có thể không phải là một động lực mạnh duy nhất cho
PKI trong nhiều tình huống. Cho cả các môi trường cơ quan và Internet, khái
niệm của giải trình trách nhiệm (accountability) có thể là động lực cưỡng bách.
Không phụ thuộc vào việc người sử dụng là người làm công cho bạn hay một
ai đó lướt trang Web của bạn để đặt hàng một cái gì đó, bạn có thể muốn một
bảo đảm mạnh xem họ là ai sao cho nếu có gì xảy ra không đúng, bạn có thể
theo dõi họ và thông báo cho họ biết, hoặc phụ thuộc vào tình huống, truy cứu
họ về trách nhiệm. Trong nhiều trường hợp, việc định danh không được đòi hỏi
để phê chuẩn hoặc hoàn thiện giao dịch. Tuy nhiên, nó sẽ gần như chắc chắn
được yêu cầu nếu một cái gì đó đổ vỡ hoặc nếu tranh cãi hoặc có các câu hỏi
nảy sinh sau sự kiện. Việc nắm giữ các bên tham gia vào là giải trình trách
nhiệm được – hoặc đơn giản chắc chắn rằng họ có thể báo tin được- cần đến
một dạng nào đó của thông tin định dạng, đó chính là cái mà PKI được thiết kế
để mang lại một cách tin cậy.
Chúng ta đều thống nhất với nhau rằng Web là công cụ lớn và đắc lực
trong đời sống ngày nay. Nhưng đi kèm với Web thì có SSL mà SSL lại có sử
dụng chứng chỉ số. Như vậy cũng đủ thấy động lực đối với PKI trở nên mạnh
như thế nào.

Người sử dụng
Trước đây, điểm truy cập ứng dụng đến PKI chủ yếu thông qua API để tới
các công cụ. Có hai khó khăn có thể với phương pháp này. Thứ nhất, công
nghiệp an toàn thông tin có ít thành công trong việc cố gắng chuẩn hoá các
API cho mục đích này, điều đó có nghĩa rằng các ứng dụng cần được ghi lại
nếu nhà cung cấp PKI thay đổi. Mặc dù một số thành tích đã được làm về các
giao diện của các hàm mật mã (ví dụ, BSAFE, CAPI) và các dịch vụ (ví dụ,
GSS-API), các API cho các dịch vụ PKI nói chung không thu được sự công
nhận rộng rãi. Thứ hai, với mỗi khai thác lớn, việc nâng cấp phần mềm có thể
mang lại một gánh nặng quản trị đáng kể bởi vì phiên bản mới của công cụ cần
phải được cài đặt trên từng máy để bàn. Đối với một số môi trường, phương
pháp bộ công cụ có thể được ưu tiên chấp nhận; với các môi trường khác; một
dạng khác của tương tác với PKI dường như được ưu tiên hơn.
Gần đây, công nghiệp an toàn thông tin và các cộng đồng chuẩn đã bắt
đầu khảo sát các thay thế cho khái niệm của API đối với bộ công cụ trên máy
tính để bàn của người sử dụng. Trong nỗ lực chiến đấu với 2 khó khăn đã nhắc
tới ở trên, nhiều công việc đã được làm trong lĩnh vực chuẩn hoá các giao thức
đối với một máy chủ mà tương tác với phần còn lại của PKI. Nếu một thoả
thuận lớn có thể đạt được về khuôn dạng và chi tiết của giao thức, thì những
người phát triển ứng dụng sẽ có thể viết mã lệnh cho giao thức này mà không
sợ một thay đổi trong nhà cung cấp PKI sẽ yêu cầu các ứng dụng của họ phải
được sửa đổi. Hơn thế nữa, nếu một máy chủ là điểm chính của tương tác với
PKI, thì việc nâng cấp phần mềm PKI sẽ không cần các thay đổi bất kỳ đối với
thông tin máy để bàn của mỗi người sử dụng; việc nâng cấp sẽ chỉ ảnh hưởng
tới các thành phần máy chủ của môi trường.
Các nỗ lực chuẩn hoá trong hướng này bao gồm OCSP, phát hiện đường
dẫn uỷ quyền và xác nhận đường dẫn uỷ quyền thông qua Simple Certificate
Validation Protocol, xác nhận chữ ký số off-loaded thông qua giao thức
Delegated Signature Validation (DSV) trong IETF PKIX và các dịch vụ quản
lý khoá - cả dịch vụ đăng ký khoá (X-KRSS) và dịch vụ thông tin khoá (X-
KISS) trong W3C XKMS. Nhiều trong số các nỗ lực này dường như có sự hỗ
trợ tương đối rộng từ các nhà cung cấp cũng như các khách hàng có tiềm năng,
cho nên các khó khăn vấp phải trong một số môi trường đối với ứng
dụng/tương tác PKI có thể được nhanh chóng đề cập tới trong các sản phẩm
thương mại tương thích chuẩn.
 TÀI LIỆU THAM KHẢO

Lê Mỹ Tú, Trần Duy Lai, Giáo trình Chứng thực điện tử, Học viện Kỹ thuật Mật
Mã, 2006
[2] Nguyễn Nam Hải, Đào Thị Hồng Vân, Phạm Ngọc Thúy, Chứng thực điện tử
trong Thương mại điện tử, NXB Khoa học kỹ thuật , 2003.
[3] Suranjan Choudhury with Kartik Bhatnagar, Wasim Haque, &NIIT, Public
Key Infrastructure: Implementation and Design, ISBN978-0-7645-4879-6,
M&T Books, 2002
[4] Russ Housley, Tim Polk, Planning for PKI: Best practices Guide for
Deploying Public Key Infrastructure, ISBN 0471397024, Wiley, 2001
[5] Carlisle Adams, Steve Lloyd, Understanding PKI: Concepts, Standards, and
Deployment Considerations, Second Edition, ISBN 0672323915, Addison
Wesley, 2002