You are on page 1of 102

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

1. Thông tin về sinh viên

Họ và tên sinh viên: Trần Hoàn Vũ

Điện thoại liên lạc: 0982.195.223 Email: tranhoanvu205@yahoo.com

Lớp: Hệ Thống Thông Tin và Truyền Thông Hệ đào tạo: Chính quy

Kỹ Sư Chất Lượng Cao – K49

Đồ án tốt nghiệp được thực hiện tại: Bộ môn Truyền thông và mạng máy tính

Thời gian làm ĐATN: Từ ngày 12/03/2009 đến 12/06/2009

2. Mục đích nội dung của ĐATN

Nhiệm vụ của đồ án là xây dựng thành phần Setup trong hệ thống BioPKI-OpenCA. Đây là một
hệ thống an ninh thông tin dựa trên sự kết hợp giữa sinh trắc học với hạ tầng khóa công khai PKI
dùng môi trường OpenCA có sử dụng thiết bị nhúng. Trọng tâm của đồ án là tập trung xây dựng
phân hệ Setup hệ thống BioPKI-OpenCA.

3. Các nhiệm vụ cụ thể của ĐATN

• Tìm hiểu lý thuyết về PKI, OpenCA, sinh trắc học, các giải pháp tích hợp sinh trắc với hạ
tầng khóa công khai để thành hệ BioPKI

• Tập trung xây dựng, phát triển phân hệ Setup hệ thống BioPKI-OpenCA

• Thử nghiệm một ứng dụng trên hệ thống BioPKI-OpenCA

4. Lời cam đoan của sinh viên:


1
Tôi –Trần Hoàn Vũ - cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự hướng
dẫn của PGS.TS. Nguyễn Thị Hoàng Lan.

Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công
trình nào khác.

Hà Nội, ngày 29 tháng 05 năm 2009

Tác giả ĐATN

Trần Hoàn Vũ

5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ:

Hà Nội, ngày tháng năm 2009

Giáo viên hướng dẫn

PGS.TS. Nguyễn Thị Hoàng Lan

2
M ỤC L ỤC

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP…………………………………………...1


LỜI CẢM ƠN…………………………………………………………………………………….6
TÓM TẮT ĐỒ ÁN……………………………………………………………………………….7
DANH MỤC TỪ VIẾT TẮT……………………………………………………………………8

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

CHƯƠNG 1 – LÝ THUYẾT TỔNG QUAN VỀ MẬT MÃ VÀ ỨNG DỤNG……………..11

1.1 Giới thiệu chung…………………………………………………………………………...11

1.2 Khái niệm hệ mật mã……………………………………………………………………...11

1.3 Hệ mật mã khoá đối xứng…………………………………………………………………12

1.4 Hệ mật mã khoá công khai………………………………………………………………...13

1.5 Chữ ký số………………………………………………………………………………….17

1.6 Hàm băm…………………………………………………………………………………..21

CHƯƠNG 2 - CHỨNG THƯ SỐ VÀ HẠ TẦNG MÃ KHOÁ CÔNG


KHAI........................24

2.1. Chứng thư số (digital certificates)………………………………………………………...25

2.1.1 Giới thiệu………………………………………………………………………………..25

2.1.2 Chứng thư khoá công khai X.509……………………………………………………….27

2.1.3 Thu hồi chứng thư……………………………………………………………………….31

2.1.4 Chính sách của chứng thư……………………………………………………………….32

2.1.5 Công bố và gửi thông báo thu hồi chứng thư…………………………………………...33

2.2 Các thành phần của PKI………………………………………………………………….36

2.2.1 Tổ chức chứng thực CA (Certification Authority)……………………………………...38

2.2.2 Trung tâm đăng ký RA (Registration Authorities)……………………………………...38


3
2.2.3 Thực thể cuối ( Người giữ chứng thư và Clients)………………………………………39

2.2.4 Hệ thống lưu trữ (Repositories)…………………………………………………………39

2.3 Chức năng cơ bản của PKI………………………………………………………………...40

2.3.1 Chứng thực (certification)………………………………………………………………40

2.3.2 Thẩm tra (validation)……………………………………………………………………40

2.3.3 Một số chức năng khác………………………………………………………………….41

2.4 Mô hình tin cậy cho PKI…………………………………………………………………...44

2.4.1 Mô hình CA đơn………………………………………………………………………..45

2.4.2 Mô hình phân cấp……………………………………………………………………….46

2.4.3 Mô hình mắt lưới (xác thực chéo)………………………………………………………47

2.4.4 Mô hình Hub và Spoke (Bridge CA)……………………………………………………49

2.4.5 Mô hình Web (Trust Lists)……………………………………………………………...49

2.4.6 Mô hình người sử dụng trung tâm (User Centric Model)………………………………51

CHƯƠNG 3 - PHƯƠNG ÁN THIẾT KẾ XÂY DỰNG HỆ THỐNG BIOPKI-OPENCA


TRONG KHUÔN KHỔ ĐỀ TÀI KC.01.11…………………………………………………...53

3.1 Giới thiệu……………………………………………………………………………………53

3.1.1 Đề tài KC.01.11…………………………………………………………………………53

3.1.2 Sinh trắc học…………………………………………………………………………….54

a. Sinh trắc học là gì……………………………………………………………………...54

b. Các giải pháp tích hợp sinh trắc để bảo vệ khoá cá nhân……………………………..56

3.1.3 Tổng quan về hệ thống OpenCA……………………………………………………….58

3.1.3.1 Giới thiệu………………………………………………………………………...58

3.1.3.2 Đánh giá về hệ OpenCA…………………………………………………………59

3.1.4 Mục đích của hệ thống BK BioPKI-OpenCA…………………………………………..59

3.2 Thư viện OpenSSL………………………………………………………………………….60

4
3.3 Phương án thiết kế xây dựng hệ thống BioPKI-OpenCA………………………………..65

3.3.1 Mô hình hệ thống dự kiến………………………………………………………………65

3.3.2 Các thành phần và chức năng của hệ thống…………………………………………….66

3.3.3 Biểu đồ phân cấp chức năng…………………………………………………………….68

3.3.4 Xây dựng phương án về quy trình hệ thống BK-BioPKI-OpenCA…………………….74

CHƯƠNG 4 -PHÂN TÍCH THIẾT KẾ CÀI ĐẶT THÀNH PHẦN SETUP HỆ THỐNG
BK-BIOPKI-OPENCA................................................................................................................78

4.1 Giới thiệu……………………………………………………………………………………78

4.2 Phân tích yêu cầu…………………………………………………………………………...78

4.3 Các chức năng cơ bản của Module Setup hệ thống……………………………………...79

4.4 Xây dựng kịch bản…………………………………………………………………………80

4.4.1 Setup CA Operator……………………………………………………………………..80

4.4.2 Setup RA……………………………………………………………………………….82

4.4.3 Setup LRA……………………………………………………………………………..85

4.4.4 Kịch bản khởi động……………………………………………………………………..86

CHƯƠNG 5 - THỬ NGHIỆM KỊCH BẢN ỨNG DỤNG TRONG HỆ THỐNG BIOPKI-
OPENCA………………………………………………………………………………………..88

5.1 Thiết kế kịch bản thử nghiệm ứng dụng chữ kí số……………………………………….89

5.2 Kết quả thử nghiệm………………………………………………………………………...94

KẾT LUẬN……………………………………………………………………………………..96

TÀI LIỆU THAM KHẢO……………………………………………………………………...97

LỜI CẢM ƠN
5
Tôi xin gửi lời cảm ơn chân thành nhất tới PGS TS Nguyễn Thị Hoàng Lan, người
thầy đã cho tôi những định hướng và những ý kiến rất quý báu để tôi hoàn thành được đồ
án tốt nghiệp này. Tôi xin tỏ lòng biết ơn sâu sắc tới các thầy cô, bạn bè cùng làm việc
trong khuôn khổ đề tài KC01.11/06-10 đã dìu dắt, giúp đỡ tôi tiến bộ trong suốt quá trình
làm đồ án tốt nghiệp. Xin cảm ơn gia đình và bè bạn, những người luôn khuyến khích và
giúp đỡ tôi trong mọi hoàn cảnh khó khăn. Tôi xin cảm ơn bộ môn Truyền Thông và
Mạng Máy Tính, khoa Công Nghệ Thông Tin trường Đại Học Bách Khoa Hà Nội đã hết
sức tạo điều kiện cho tôi trong quá trình học và làm đồ án này.

TÓM TẮT ĐỒ ÁN

6
Đồ án này có tên “Xây dựng phân hệ Setup trong hệ thống an ninh dựa trên sinh
trắc học BioPKI-OpenCA” nằm trong khuôn khổ đề tài nghiên cứu khoa học công nghệ
cấp nhà nước KC01.11/06-10 “Hệ thống an ninh thông tin dựa trên sinh trắc học sử
dụng công nghệ nhúng BioPKI”. Nội dung đồ án là nghiên cứu xây dựng nền tảng hệ
thống BioPKI-OpenCA trong đó tập trung xây dựng phân hệ setup hệ thống và thử
nghiệm một ứng dụng trên hệ thống BioPKI-OpenCA.

DANH MỤC TỪ VIẾT TẮT


APKI Architecture for Public-Key Infrastructure
7
CA Certificate Authority
CRL Certifiate Revocation List
DES Data Encrytion Standard
DSA Digital Signature Algorithm
DSS Digital Signature Standard
IETF Internet Engineering Task Force
LDAP Lightweight Directory Access Protocol
MD2, 4,5 Message Digest 2,4,5
NIST National Institute of Standards and Technology
NSA National Security Agency
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
RA Registration Authority
PKCS Public Key Cryptography Standards
PKI Public Key Infrastructure
PKIX Public Key Infrastructure X.509 group
RFC Request For Comments
RSA Rivest Shamir Adleman
SCEP Simple Certificate Enrollment Protocol
SET Secure Electronic Transactions
SHA Secure Hash Algorithm
SPKI Simple Public Key Infrastructure
SSL Secure Socket Layer
TSL Transport Layer Security

DANH MỤC HÌNH VẼ

Hình 1.1: Quá trình mã hoá và giải mã


8
Hình 1.2: Mã hoá thông điệp sử dụng khoá công khai P
Hình 1.3: Giải mã thông điệp sử dụng khoá cá nhân của người nhận
Hình 1.4: Sơ đồ hệ mật mã RSA
Hình 1.5: Mã hoá thông điệp sử dụng khoá cá nhân S để mã thông điệp và khoá
công khai P để mã khoá cá nhân S
Hình 1.6: Giải mã thông điệp sử dụng khoá cá nhân S để giải mã thông điệp và
khoá cá nhân P để giải mã khoá cá nhân S
Hình 1.7: Sơ đồ chữ ký RSA
Hình 1.8: Sơ đồ mô tả các công đoạn người A làm trước khi gửi thông điệp cho
người B (sử dụng hàm băm rồi ký số)
Hình 1.9: Sơ đồ mô tả các công đoạn kiểm tra chữ ký sau khi người B nhận
được thông điệp
Hình 1.10: Nhiều thông điệp nguồn cho cùng 1 kết quả đích sau mã hoá/ ký số
Hình 2.1: Chứng thư số
Hình 2.2: Khuôn dạng chứng chỉ X.509
Hình 2.3: Nội dung chi tiết của chứng chỉ
Hình 2.4: Khuôn dạng danh sách chứng chỉ bị thu hồi
Hình 2.5: Dịch vụ kiểm tra online
Hình 2.6: Các thành phần PKI
Hình 2.7: Đường dẫn chứng chỉ chéo
Hình 2.8: Mô hình CA đơn
Hình 2.9: Mô hình phân cấp
Hình 2.10: Mô hình mắt lưới
Hình 2.11: Mô hình Hub và Spoke (Bridge CA)
Hình 3.1: Các thuộc tính sinh trắc học khác nhau
9
Hình 3.2: Bảng so sánh các đặc trưng sinh trắc học theo A. K. Jain [2]
(H - cao, M - trung bình, L - thấp)
Hình 3.3: Các thành phần của hệ thống OpenCA
Hình 3.4: Mô hình hệ thống BioPKI-OpenCA mức khung cảnh
Hình 3.5: Biểu đồ phân cấp chức năng của CA Operator
Hình 3.6: Biểu đồ phân cấp chức năng của RA
Hình 3.7: Biểu đồ phân cấp chức năng của LRA
Hình 4.1: Các chức năng của Module Setup Hệ Thống
Hình 4.2: Biểu đồ diễn tiến quá trình Setup CA Operator
Hình 4.3: Biểu đồ diễn tiến quá trình Setup RA
Hình 4.4: Biểu đồ diễn tiến quá trình đăng ký một LRA
Hình 4.5: Biểu đồ diễn tiến quá trình setup LRA
Hình 4.6: Kịch bản khởi động cho các phân hệ trong hệ thống BioPKI
Hình 5.1: Biểu đồ usecase nhóm các chức năng liên quan tới ứng dụng trên nền
PKI
Hình 5.2: Biểu đồ diễn tiến quá trình kí
Hình 5.3: Biểu đồ diễn tiến quá trình xác thực chữ kí
Hình 5.4: Quá trình kí có thử nghiệm hoạt động tất cả các thành phần của hệ thống
BioPKI-OpenCA
Hình 5.5: Quá trình xác thực có thử nghiệm hoạt động tất cả các thành phần của hệ
thống

CHƯƠNG 1
LÝ THUYẾT TỔNG QUAN VỀ MẬT MÃ VÀ ỨNG DỤNG

10
1.1 Giới thiệu chung

Mật mã đã được con người sử dụng từ lâu đời. Các hình thức mật
mã sơ khai đã được tìm thấy từ khoảng bốn nghìn năm trước trong nền
văn minh Ai Cập cổ đại. Trải qua hàng nghìn năm lịch sử, mật mã đã
được sử dụng rộng rãi ở khắp nơi trên thế giới từ Đông sang Tây để giữ
bí mật cho việc giao lưu thông tin trong nhiều lĩnh vực hoạt động giữa
con người và các quốc gia, đặc biệt trong các lĩnh vực quân sự, chính
trị, ngoại giao. Mật mã trước hết là một loại hoạt động thực tiễn, nội
dung chính của nó là để giữ bí mật thông tin. Ví dụ muốn gửi một văn
bản từ một người gửi A đến một người nhận B, A phải tạo cho văn bản
đó một bản mã mật tương ứng và thay vì gửi văn bản rõ thì A chỉ gửi
cho B bản mã mật, B nhận được bản mã mật và khôi phục lại văn bản
rõ để hiểu được thông tin mà A muốn gửi cho mình. Do văn bản gửi đi
thường được chuyển qua các con đường công khai nên người ngoài có
thể “lấy trộm” được, nhưng vì đó là bản mật mã nên không đọc hiểu
được. Còn A có thể tạo ra bản mã mật và B có thể giải bản mã mật
thành bản rõ để hiểu được là do hai người đã có một thoả thuận về một
chìa khoá chung, chỉ với khoá chung này thì A mới tạo được bản mã
mật từ bản rõ và B mới khôi phục được bản rõ từ bản mã mật. Khoá
chung đó được gọi là khoá mật mã. Để thực hiện được một phép
mật mã, ta còn cần có một thuật toán biến bản rõ cùng với khoá mật
mã thành bản mã mật và một thuật toán ngược lại biến bản mật cùng
với khoá mật mã thành bản rõ. Các thuật toán đó được gọi tương ứng
là thuật toán lập mã và thuật toán giải mã. Các thuật toán này thường
không nhất thiết phải giữ bí mật, mà cái luôn cần được giữ bí mật là
khoá mật mã. Trong thực tiễn, có những hoạt động ngược lại với hoạt
động bảo mật là khám phá bí mật từ các bản mã “lấy trộm” được, hoạt
động này thường được gọi là mã thám hay phá khoá [2].

1.2 Khái niệm hệ mật mã

Hệ mật mã được định nghĩa là một bộ năm (P, C, K, E, D), trong


đó:
1. P là tập hữu hạn các các bản rõ có thể
2. C tập hữu hạn các bản mã có thể
3. K là tập hữu hạn các khoá có thể
4. E là tập các hàm lập mã
5. D là tập các hàm giải mã. Với mỗi k ∈ K, có một hàm lập mã
11
ek ∈ E, ek : P → C và một hàm giải mã dk∈ D, dk: C → P sao cho
dk(ek(x)) = x , ∀ x ∈ P

Hình 1.1: Quá trình mã hoá và giải mã

1.3 Hệ mật mã khoá đối xứng

Các phương pháp mật mã cổ điển đã được biết đến từ khoảng


4000 năm trước. Một số kỹ thuật đã được những người Ai Cập sử dụng
từ nhiều thế kỷ trước. Những kỹ thuật này chủ yếu sử dụng hai phương
pháp chính là: phép thay thế và phép chuyển dịch. Trong phép thay
thế, một chữ cái này được thay thế bởi chữ cái khác và trong phép
chuyển dịch, các chữ cái được sắp xếp theo một trật tự khác.

Hệ mã chuẩn DES được xây dựng tại Mỹ trong những năm 70


theo yêu cầu của Văn phòng quốc gia về chuẩn (NBS) và được sự thẩm
định của an ninh quốc gia là một ví dụ về mật mã cổ điển. DES kết hợp
cả hai phương pháp thay thế và chuyển dịch. DES thực hiện mã hoá
trên từng khối bản rõ là một xâu 64 bit, có khoá là một xâu 56 bit và
cho ra bản mã cũng là một xâu 64 bit. Hiện nay, DES và biến thể của
nó (3DES) vẫn được sử dụng thành công trong nhiều ứng dụng.

Trong các hệ mã đối xứng chỉ có một khoá được chia sẻ giữa các
bên tham gia liên lạc. Cứ mỗi lần truyền tin bảo mật, cả người gửi A và
người nhận B cùng thoả thuận trước với nhau một khoá chung K, sau
đó người gửi dùng eK để lập mã cho thông báo gửi đi và người nhận

12
dùng dK để giải mã bản mật mã nhận được. Người gửi và người nhận có
cùng một khoá chung K, được giữ bí mật dùng cho cả lập mã và giải
mã. Những hệ mật mã cổ điển với cách sử dụng trên được gọi là mật
mã khoá đối xứng hay còn gọi là mật mã khoá cá nhân.

Độ an toàn của hệ mật mã đối xứng phụ thuộc vào khoá. Nếu để
lộ khoá thì bất kỳ người nào cũng có thể mã hoá và giải mã thông điệp.

* Ưu và nhược điểm của hệ mật mã khoá đối xứng

Ưu điểm nổi bật của các hệ mật mã khoá đối xứng là việc xây
dựng một hệ mật mã có độ bảo mật cao khá dễ dàng về mặt lý thuyết.
Nhưng như nếu không kể đến việc cần có một nguồn sinh khoá ngẫu
nhiên thì việc phân phối, lưu trữ bảo mật và thoả thuận khoá là một
vấn đề khó chấp nhận được trong mạng truyền thông ngày nay. Trong
một mạng có n người dùng, nếu cần khoá cho từng cặp thì cần
n(n+1)/2 khoá.

Để khắc phục hiện tượng không thể lưu trữ một khối lượng khoá
quá lớn đáp ứng được nhu cầu mã dịch, người ta xem xét đến việc sử
dụng các hệ mật mã khối với độ dài không lớn lắm như DES… hoặc các
hệ mật mã dòng mà khoá được sinh ra từ một nguồn giả ngẫu nhiên
bằng thuật toán.

Mặc dù đã thực hiện việc mã hoá và giải mã bằng các hệ mật mã


khối hay bằng thuật toán sinh khoá như đã nêu ở trên thì vấn đề phân
phối và thoả thuận khoá vẫn phải được thực hiện. Như vậy phân phối
và thoả thuận khoá là một vấn đề chưa thể được giải quyết trong các
hệ mật mã khoá đối xứng.

1.4 Hệ mật mã khoá công khai

Để giải quyết vấn đề phân phối và thoả thuận khoá của mật mã
khoá đối xứng, năm 1976 Diffie và Hellman đã đưa ra khái niệm về hệ
mật mã khoá công khai và một phương pháp trao đổi công khai để tạo
ra một khoá cá nhân chung mà tính an toàn được bảo đảm bởi độ khó
của một bài toán toán học cụ thể (là bài toán tính “logarit rời rạc”). Hệ
mật mã khoá công khai hay còn được gọi là hệ mật mã phi đối xứng sử
dụng một cặp khoá, khoá mã hoá còn gọi là khoá công khai (public
key) và khoá giải mã được gọi là khoá cá nhân hay khóa riêng (private
13
key). Trong hệ mật này, khoá mã hoá khác với khoá giải mã. Về mặt
toán học thì từ khoá công rất khó tính được khoá cá nhân. Biết được
khoá này không dễ dàng tìm được khoá kia. Khoá giải mã được giữ bí
mật trong khi khoá mã hoá được công bố công khai. Một người bất kỳ
có thể sử dụng khoá công khai để mã hoá tin tức, nhưng chỉ có người
nào có đúng khoá giải mã mới có khả năng xem được bản rõ.

Người gửi A sẽ mã hoá thông điệp bằng khóa công của người
nhận và người nhận B sẽ giải mã thông điệp với khoá cá nhân tương
ứng của mình.

Quá trình này được mô tả trong hình 1.2 và 1.3.

Hình 1.2: Mã hoá thông điệp sử dụng khoá công khai P

14
Hình 1.3: Giải mã thông điệp sử dụng khoá cá nhân của người
nhận

Có nhiều hệ thống khoá công khai được triển khai rộng rãi như hệ
RSA, hệ ElGamal sử dụng giao thức trao đổi khoá Diffie-Hellman và nổi
lên trong những năm gần đây là hệ đường cong Elliptic. Trong số các
hệ mật mã trên thì hệ RSA là hệ được cộng đồng chuẩn quốc tế và
công nghiệp chấp nhận rộng rãi trong việc thực thi mật mã khoá công
khai.
Hệ mật mã RSA, do Rivest, Shamir và Adleman [6] tìm ra, đã
được công bố lần đầu tiên vào tháng 8 năm 1977 trên tạp chí Scientific
American. Hệ mật mã RSA được sử dụng rộng rãi trong thực tiễn đặc
biệt cho mục đích bảo mật và xác thực dữ liệu số. Tính bảo mật và an
toàn của chúng được bảo đảm bằng độ phức tạp của một bài toán số
học nổi tiếng là bài toán phân tích số nguyên thành các thừa số
nguyên tố. Hệ mật mã RSA được mô tả như hình 1.4.

15
Hình 1.4: Sơ đồ hệ mật mã RSA

Việc phát minh ra phương pháp mã công khai tạo ra một cuộc
“cách mạng” trong công nghệ an toàn thông tin điện tử. Nhưng thực
tiễn triễn khai cho thấy tốc độ mã hoá khối dữ liệu lớn bằng các thuật
toán mã hoá công khai chậm hơn rất nhiều so với hệ mã hoá đối xứng.
Ví dụ, để đạt được độ an toàn như các hệ mã đối xứng mạnh cùng thời,
RSA đòi hỏi thời gian cho việc mã hoá một văn bản lâu hơn gấp hàng
ngàn lần. Do đó, thay bằng việc mã hoá văn bản có kích thước lớn
bằng lược đồ khoá công khai thì văn bản này sẽ được mã hoá bằng một
hệ mã đối xứng có tốc độ cao như DES, IDEA,…sau đó khoá được sử
dụng trong hệ mã đối xứng sẽ được mã hoá sử dụng mật mã khoá công
khai. Phương pháp này rất khả thi trong việc mã và giải mã những văn
bản có kích thước lớn như được mô tả trong hình 1.5 và 1.6.

16
Hình 1.5: Mã hoá thông điệp sử dụng khoá cá nhân S để mã
thông điệp và khoá công khai P để mã khoá cá nhân S

Hình 1.6: Giải mã thông điệp sử dụng khoá cá nhân S để giải


mã thông điệp và
khoá cá nhân P để giải mã khoá cá nhân S

* Ưu và nhược điểm của hệ mật mã khoá công khai


17
Vấn đề còn tồn đọng của hệ mật mã khoá đối xứng được giải
quyết nhờ hệ mật mã khoá công khai. Chính ưu điểm này đã thu hút
nhiều trí tuệ vào việc đề xuất, đánh giá các hệ mật mã công khai.
Nhưng do bản thân các hệ mật mã khoá công khai đều dựa vào các giả
thiết liên quan đến các bài toán khó nên đa số các hệ mật mã này đều
có tốc độ mã dịch không nhanh lắm. Chính nhược điểm này làm cho
các hệ mật mã khoá công khai khó được dùng một cách độc lập.

Một vấn đề nữa nảy sinh khi sử dụng các hệ mật mã khóa công
khai là việc xác thực mà trong mô hình hệ mật mã đối xứng không đặt
ra. Do các khoá mã công khai được công bố một cách công khai trên
mạng cho nên việc đảm bảo rằng “khoá được công bố có đúng là của
đối tượng cần liên lạc hay không?” là một kẽ hở có thể bị lợi dụng. Vấn
đề xác thực này được giải quyết cũng chính bằng các hệ mật mã khoá
công khai. Nhiều thủ tục xác thực đã được nghiên cứu và sử dụng như
Kerberos, X.509… Một ưu điểm nữa của các hệ mật mã khoá công khai
là các ứng dụng của nó trong lĩnh vực chữ ký số, cùng với các kết quả
về hàm băm, thủ tục ký để bảo đảm tính toàn vẹn của một văn bản
được giải quyết.

1.5 Chữ ký số

Mật mã khoá công khai có thể được sử dụng theo nhiều cách
khác nhau. Chữ ký số là một ví dụ minh chứng cho việc đảm bảo xác
thực người dùng và toàn vẹn dữ liệu. Nếu người gửi A mã hoá thông
điệp hay tài liệu với khoá cá nhân của mình thì bất kỳ ai cũng có thể
giải mã thông điệp với khoá công của A. Do đó, người nhận có thể chắc
chắn rằng thông điệp mình nhận chỉ có thể do A mã vì chỉ A mới có
khoá cá nhân của mình. Quá trình mã hoá thông điệp với khoá cá nhân
của người gửi gọi là quá trình “ký số”.

Trong thực tế, quá trình ký số thường khó hơn. Thay bằng việc
mã bản thông điệp gốc với khoá cá nhân của người gửi thì chỉ có bản
đại diện thông điệp (bản băm) có độ dài cố định được mã hoá với khoá
cá nhân của người gửi và bản băm đã được mã hoá này được gắn vào
với thông điệp gốc. Người nhận B sau khi nhận được thông điệp đầu
tiên sẽ giải mã bản băm với khoá công của người gửi, sau đó băm
thông điệp đi kèm bằng thuật toán băm tương ứng với thuật toán băm
người gửi đã sử dụng. B so sánh hai giá trị băm nếu giống nhau thì
chắc chắn rằng thông điệp A gửi cho B còn nguyên vẹn, đồng thời xác
thực được người gửi thông tin là ai.
18
Tính toàn vẹn của thông điệp được đảm bảo vì chỉ thay đổi một
bit trong thông điệp gửi đi thì kết quả hai giá trị băm sẽ khác nhau.
Tính xác thực của người gửi cũng được đảm bảo vì chỉ có người gửi A
mới có khoá cá nhân để mã bản băm. Chữ ký số cũng chứng minh được
tính chống chối bỏ bản gốc vì chỉ có A mới có khoá cá nhân dùng để ký
số.

Sơ đồ chữ ký được định nghĩa như sau:

Sơ đồ chữ ký là một bộ năm (P, A, K, S, V), trong đó:

1. P là một tập hữu hạn các văn bản có thể


2. A là một tập hữu hạn các chữ ký có thể
3. K là một tập hữu hạn các khoá có thể
4. S là tập các thuật toán ký
5. V là tập các thuật toán kiểm thử
6. Với mỗi k ∈ K, có một thuật toán ký sig k ∈ S, sig k: P → A và
một thuật
toán kiểm thử ver k ∈ V, ver k: P x A → {đúng, sai}, thoả mãn điều
kiện
sau đây với mọi x ∈ P, y ∈ A:

RSA cũng là thuật toán được dùng nhiều cho mục đích ký số. Sơ
đồ chữ ký RSA được mô tả như trong hình 1.7 [3]. Ngoài ra, còn có một
số thuật toán công khai khác được dùng để ký số, ví dụ như chuẩn chữ
ký số DSS.

Cho n = p*q với p,q là số nguyên tố lớn . Đặt P


= A = Zn
K = {(n, p, q, a, b)/ n = p*q, a*b ≡ 1 mod φ(n)}
trong đó (n,b) là công khai, (a, p, q) là bí
mật
Với mỗi K = (n, p, q, a, b), mỗi x ∈ P, ta định
nghĩa:
y = sigK (x) = xa mod n, y ∈ A
19
verK (x, y) = đúng ⇔ x ≡ yb mod n

Hình 1.7: Sơ đồ chữ ký RSA

Quá trình ký và kiểm tra chữ ký được mô tả trong hình 1.8 và


hình 1.9
Giả sử A muốn gửi cho B thông điệp x. A thực hiện các bước sau:

1. A băm thông điệp x (Hình 1.8 a), thu được bản đại diện z =
h(x) – có kích
thước cố định 128 bit hoặc 160 bit.

2. A ký số trên bản đại diện z (Hình 1.8 b), bằng khóa bí mật của
mình, thu
được bản ký số y = sigK (z).

3. A gửi (x, y) cho B (Hình 1.8 c).

Hình 1.8 a: Băm thông điệp.

20
Hình 1.8 b: Ký trên bản băm.

Hình 1.8 c: Truyền dữ liệu thông tin cần gửi.

Hình 1.8: Sơ đồ mô tả các công đoạn người A làm trước khi gửi
thông điệp
cho người B (sử dụng hàm băm rồi ký số)
Khi B nhận được (x, y). B thực hiện các bước sau:

1. B kiểm tra chữ ký số để xác minh xem thông điệp mà mình


nhận được có phải được gửi từ A hay không bằng cách giải mã
chữ ký số y, bằng khóa công khai của A, được z. (Hình 1.9 a)

2. B dùng một thuật toán băm – tương ứng với thuật toán băm
mà A dùng – để băm thông điệp x đi kèm, nhận được h(x).
(Hình 1.9 b)

3. B so sánh 2 giá trị băm z và h(x), nếu giống nhau thì chắc
chắn rằng thông điệp x – mà A muốn gửi cho B – còn nguyên
vẹn, bên cạnh đó cũng xác thực được người gửi thông tin là ai.
(Hình 1.9 c)
21
Hình 1.9 a: Xác minh chữ ký.

Hình 1.9 b: Tiến hành băm thông điệp x đi kèm.

Hình 1.9 c: Kiểm tra tính toàn vẹn của thông điệp

Hình 1.9: Sơ đồ mô tả các công đoạn kiểm tra chữ ký sau khi
người B nhận
được thông điệp

22
1.6 Hàm băm

Việc sử dụng các hệ mật mã và sơ đồ chữ ký số thường là mã hóa


và ký số trên từng bit của thông tin, thời gian để mã hóa và ký sẽ tỷ lệ
thuận với dung lượng của thông tin. Thêm vào đó có thể xảy ra trường
hợp: với nhiều bức thông điệp đầu vào khác nhau, sử dụng hệ mật mã,
sơ đồ ký số giống nhau (có thể khác nhau) thì cho ra kết quả bản mã,
bản ký số giống nhau (ánh xạ N-1: nhiều – một), như hình 1.10. Điều
này sẽ dẫn đến một số rắc rối về sau cho việc xác thực thông tin.

Hình 1.10: Nhiều thông điệp nguồn cho cùng 1 kết quả đích sau
mã hoá/ ký số

Các sơ đồ ký số thường chỉ được sử dụng để ký các bức thông


điệp (thông tin) có kích thước nhỏ và sau khi ký, bản ký số có kích
thước gấp đôi bản thông điệp gốc – ví dụ với sơ đồ chữ ký chuẩn DSS
ký trên các bức thông điệp có kích thước 160 bit, bản ký số sẽ có kích
thước 320 bit. Trong khi đó trên thực tế, ta cần phải ký các thông điệp
có kích thước lớn hơn nhiều, chẳng hạn vài chục MegaByte. Hơn nữa,
để đáp ứng yêu cầu xác thực sau khi thông tin đến người nhận, dữ liệu
truyền qua mạng không chỉ là bản thông điệp gốc, mà còn bao gồm cả
bản ký số (có dung lượng gấp đôi dung lượng bản thông điệp gốc). Một
cách đơn giản để giải quyết vấn đề trên (với thông điệp có kích thước
lớn) này là chặt thông điệp thành nhiều đoạn 160 bit, sau đó ký lên các
23
đoạn đó độc lập nhau. Nhưng, sử dụng biện pháp này sẽ có một số vấn
đề gặp phải trong việc tạo ra các chữ ký số:

- Thứ nhất: với một thông điệp có kích thước a, thì sau khi ký kích
thước của chữ ký sẽ là 2a (trong trường hợp sử dụng DSS).

- Thứ hai: với các chữ ký “an toàn” thì tốc độ chậm vì chúng dùng
nhiều phép tính số học phức tạp như số mũ modulo.

- Thứ ba: vấn đề nghiêm trọng hơn đó là kết quả sau khi ký, nội
dung của thông điệp có thể bị xáo trộn các đoạn với nhau, hoặc một số
đoạn trong chúng có thể bị mất mát, trong khi người nhận cần phải xác
minh lại thông điệp. Do đó, ta cần phải bảo đảm tính toàn vẹn của
thông điệp.

Giải pháp cho các vấn đề vướng mắc đến chữ ký số là dùng hàm
băm để trợ giúp cho việc ký số.

Hàm băm - hiểu theo một nghĩa đơn giản là hàm cho tương ứng một
mảng dữ liệu lớn với một mảng dữ liệu nhỏ hơn - được sử dụng rộng rãi
trong nhiều ứng dụng khác nhau của tin học, không chỉ thuộc phạm vi
mật mã học [1].

Hàm băm được đề cập đến trong phạm vi đồ án là hàm băm một
chiều, có tác dụng trợ giúp cho các sơ đồ ký số nhằm làm giảm dung
lượng của dữ liệu cần thiết để truyền qua mạng. Hàm băm ở đây được
hiểu là các thuật toán không sử dụng khoá để mã hóa (ở đây ta dùng
thuật ngữ “băm” thay cho “mã hoá”), nó có nhiệm vụ băm thông điệp
được đưa vào theo một thuật toán h một chiều nào đó, rồi đưa ra một
bản băm – văn bản đại diện – có kích thước cố định. Giá trị của hàm
băm là duy nhất và không thể suy ngược lại được nội dung thông điệp
từ giá trị băm này. Hàm băm một chiều h có một số đặc tính quan
trọng sau:

- Với thông điệp đầu vào x thu được bản băm z = h(x) là duy
nhất.

- Nếu dữ liệu trong thông điệp x thay đổi hay bị xóa để thành
thông điệp x’ thì h(x’) ≠ h(x). Cho dù chỉ là một sự thay đổi nhỏ hay
chỉ là xóa đi 1 bit dữ liệu của thông điệp thì giá trị băm cũng vẫn thay
đổi. Điều này có nghĩa là: hai thông điệp hoàn toàn khác nhau thì giá
trị hàm băm cũng khác nhau.
24
- Nội dung của thông điệp gốc không thể bị suy ra từ giá trị hàm
băm. Nghĩa là với thông điệp x thì dễ dàng tính được z = h(x), nhưng
lại không thể (thực chất là khó) suy ngược lại được x nếu chỉ biết giá trị
hàm băm h(x).

Một số thuật toán băm được biết đến nhiều là hàm băm dòng và
hàm băm chuẩn như: [MD2], [MD4], [MD5], [SHA-1]…

CHƯƠNG 2

CHỨNG CHỈ SỐ VÀ HẠ TẦNG KHOÁ CÔNG KHAI

Mật mã khoá công khai cho đến nay được xem là giải pháp tốt
nhất để đảm bảo được các yêu cầu về an toàn thông tin mạng: “bảo
mật”, “toàn vẹn”, “xác thực” và “chống chối bỏ”. Mặc dù vẫn còn mới
khi so sánh với các phương pháp mã cổ điển nhưng mật mã khoá công
khai đã nhận được sự tin cậy rộng rãi của thế giới Internet vì những
công cụ có khả năng phát triển cho vấn đề quản lý khoá. Như đã đề
cập ở trên, vấn đề chính của hệ mã khoá đối xứng là vấn đề quản lý
khoá và để giải quyết vấn đề này hệ mã khoá công khai đã được đưa ra
như một giải pháp. Trong hệ thống mật mã khoá công khai, khoá cá
nhân (khoá cá nhân) được người dùng giữ bí mật trong khi khoá công
khai với tên của người sở hữu tương ứng lại được công bố công khai.
Đối với hệ thống như thế này, ta cần xác định và trả lời một số câu hỏi
như:

- Ai sẽ tạo ra cặp khoá công khai – bí mật?

25
- Dữ liệu sẽ được lưu dưới định dạng như thế nào trong hệ thống
lưu trữ (khoá công, định danh của người sở hữu và các thông tin
khác)?
- Có cơ chế nào để giữ cho thông tin không bị thay đổi trên hệ
thống lưu trữ?
- Làm thế nào để đảm bảo việc gắn kết giữa khoá công và định
danh của thực thể yêu cầu có khoá công?
- Làm thế nào để người sử dụng có thể truy cập được đến nơi lưu
trữ?
- Làm thế nào người sử dụng nhận biết được có sự thay đổi trong
dữ liệu đang được lưu trên hệ thống lưu trữ?
- Điều gì sẽ xảy với khoá công khai nếu khoá cá nhân tương ứng
bị xâm hại?
- Có một chính sách nào cho tất cả những vấn đề nêu trên không?

Để trả lời cho những câu hỏi trên có một giải pháp là sử dụng hạ
tầng khoá công khai - PKI.

Cho đến nay có nhiều định nghĩa về PKI, nhưng chưa định nghĩa
nào được công nhận chính thức. Có một số định nghĩa về PKI như sau:

“PKI là một tập các 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ý, lưu trữ, phân phối và thu hồi
chứng thư khoá công khai dựa trên mật mã khoá công khai”[14].

“PKI là hạ tầng cơ sở có thể hỗ trợ quản lý khoá công khai để hỗ


trợ các dịch vụ xác thực, mã hoá, toàn vẹn hay chống chối bỏ” [7].

“PKI là hạ tầng cơ sở bảo mật có những dịch vụ được triển khai và


chuyển giao sử dụng công nghệ và khái niệm khoá công khai” [4].
Nhìn chung, PKI có thể được định nghĩa như một hạ tầng cơ sở sử
dụng công nghệ thông tin để cung cấp dịch vụ mã hoá khoá công khai
và chữ ký số. Một mục đích quan trọng khác của PKI là để quản lý khoá
và chứng thư được sử dụng trong hệ thống.

Chứng thư là cấu trúc dữ liệu đặc biệt, gắn kết khoá công khai với
chủ sở hữu của nó. Việc gắn kết này được đảm bảo bằng chữ ký số của
nơi được uỷ quyền cấp chứng thư.

2.1. Chứng thư số (digital certificates)

26
2.1.1 Giới thiệu

Như đã nói đến ở trên, mật mã khoá công khai sử dụng hai khoá
khác nhau (khoá công và khoá cá nhân) để đảm bảo yêu cầu “bí mật,
xác thực, toàn vẹn và chống chối bỏ ” của những dịch vụ an toàn. Một
đặc tính quan trọng khác của lược đồ khoá công khai là phần khoá
công khai được phân phối một cách tự do. Ngoài ra, trong hạ tầng mã
khoá công khai thì khoá công ngoài việc phải luôn sẵn có để mọi người
trong hệ thống có thể sử dụng còn phải được đảm bảo về tính toàn
vẹn.

Khoá công được đặt ở vị trí công khai trong một định dạng đặc
biệt. Định dạng này được gọi là chứng thư. Chứng thư (thực ra là chứng
thư khoá công – public key certificate (PKC)) là sự gắn kết giữa khoá
công của thực thể và một hoặc nhiều thuộc tính liên quan đến thực thể
[5]. Thực thể có thể là người, thiết bị phần cứng như máy tính, router
hay một phần mềm xử lý. Một chứng thư khoá công (PKC) được người
cấp ký bằng chữ ký có hiệu lực đưa ra một bảo bảm đầy đủ về sự gắn
kết giữa khoá công, thực thể sở hữu khoá công này và tập các thuộc
tính khác được viết trong chứng thư.

PKC còn được gọi là “digital certificate”- chứng thư số, “digital
ID”, hay đơn
giản là chứng thư.

Hình 2.1 minh hoạ một chứng thư số.

27
Hình 2.1: Chứng thư số

Chứng thư chứa những thông tin cần thiết như khóa công khai,
chủ thể (người sở hữu) khoá công, người cấp và một số thông tin khác.
Tính hợp lệ của các thông tin được đảm bảo bằng chữ ký số của người
cấp chứng thư. Người nào muốn sử dụng chứng thư trước hết sẽ kiểm
tra chữ ký số trong chứng thư. Nếu đó là chữ ký hợp lệ thì sau đó có
thể sử dụng chứng thư theo mục đích mong muốn.

Có nhiều loại chứng thư, một trong số đó là:


- Chứng thư khoá công khai X.509
- Chứng thư khoá công khai đơn giản (Simple Public Key
Certificates - SPKC)
- Chứng thư Pretty Good Privacy (PGP)
- Chứng thư thuộc tính (Attribute Certificates - AC)

28
Tất cả các loại chứng thư này đều có cấu trúc định dạng riêng.
Hiện nay chứng thư khoá công khai X.509 được sử dụng phổ biến trong
hầu hết các hệ thống PKI. Hệ thống chương trình cấp chứng thư số thử
nghiệm cũng sử dụng định dạng chứng thư theo X.509, nên đồ án này
tập trung vào xem xét chi tiết chứng thư công khai X.509. Trong đồ án,
thuật ngữ chứng thư “certificate” được sử dụng đồng nghĩa với chứng
thư khoá công khai X.509 v3.

2.1.2 Chứng thư khoá công khai X.509

Chứng thư X.509 v3 là định dạng chứng thư được sử dụng phổ
biến và được hầu hết các nhà cung cấp sản phẩm PKI triển khai.

Chứng thư khoá công khai X.509 được Hội viễn thông quốc tế
(ITU) đưa ra lần đầu tiên năm 1988 như là một bộ phận của dịch vụ thư
mục X.500.

Chứng thư gồm 2 phần. Phần đầu là những trường cơ bản cần
thiết phải có trong chứng thư. Phần thứ hai chứa thêm một số trường
phụ, những trường phụ này được gọi là trường mở rộng dùng để xác
định và đáp ứng những yêu cầu bổ sung của hệ thống. Khuôn dạng của
chứng thư X.509 được chỉ ra như trong hình 2.2.

29
Hình 2.2: Khuôn dạng chứng thư X.509

a. Những trường cơ bản của chứng thư X.509

- Version: xác định số phiên bản của chứng thư.


- Certificate Serial Number: do CA gán, là định danh duy nhất
của chứng thư.
- Signature Algorithm ID: chỉ ra thuật toán CA sử dụng để ký
số chứng thư. Có thể là thuật toán RSA hay DSA…
- Issuer: chỉ ra CA cấp và ký chứng thư.
- Validity Period: khoảng thời gian chứng thư có hiệu lực.
Trường này xác định thời gian chứng thư bắt đầu có hiệu lực và thời
điểm hết hạn.
- Subject: xác định thực thể mà khoá công khai của thực thể này
được xác nhận. Tên của subject phải duy nhất đối với mỗi thực thể CA
xác nhận.
30
- Subject public key information: chứa khoá công khai và
những tham số liên quan; xác định thuật toán (ví dụ RSA hay DSA)
được sử dụng cùng với khoá.
- Issuer Unique ID (Optional): là trường không bắt buộc,
trường này cho phép sử dụng lại tên người cấp. Trường này hiếm được
sử dụng trong triển khai thực tế.
- Subject Unique ID (Optional): là trường tuỳ chọn cho phép
sử dụng lại tên của subject khi quá hạn. Trường này cũng ít được sử
dụng.
- Extensions (Optional): chỉ có trong chứng thư v.3.
- Certification Authority’s Digital Signature: chữ ký số của
CA được tính từ những thông tin trên chứng thư với khoá cá nhân và
thuật toán ký số được chỉ ra trong trường Signature Algorithm Identifier
của chứng thư.

Tính toàn vẹn của chứng thư được đảm bảo bằng chữ ký số của
CA trên chứng thư. Khoá công khai của CA được phân phối đến người
sử dụng chứng thư theo một số cơ chế bảo mật trước khi thực hiện các
thao tác PKI. Người sử dụng kiểm tra hiệu lực của chứng thư được cấp
với chữ ký số của CA và khoá công khai của CA.

b. Những trường mở rộng của chứng thư X.509

Phần mở rộng là những thông tin về các thuộc tính cần thiết được
đưa vào để gắn những thuộc tính này với người sử dụng hay khoá
công. Những thông tin trong phần mở rộng thường được dùng để quản
lý xác thực phân cấp, chính sách chứng thư, thông tin về chứng thư bị
thu hồi…Nó cũng có thể được sử dụng để định nghĩa phần mở rộng
riêng chứa những thông tin đặc trưng cho cộng đồng nhất định. Mỗi
trường mở rộng trong chứng thư được thiết kế với cờ “critical” hoặc
“uncritical”.

- Authority Key Indentifier: chứa ID khoá công khai của CA, ID


này là duy nhất và được dùng để kiểm tra chữ ký số trên chứng thư. Nó
cũng được sử dụng để phân biệt giữa các cặp khoá do một CA sử dụng
(trong trường hợp nếu CA có nhiều hơn một khoá công khai). Trường
này được sử dụng cho tất cả các chứng thư tự ký số (CA - certificates).
- Subject Key Identifier: chứa ID khoá công khai có trong
chứng thư và được sử dụng để phân biệt giữa các khoá nếu như có
nhiều khoá được gắn vào trong cùng chứng thư của người sử dụng
(Nếu chủ thể có nhiều hơn một khoá công khai).
31
- Key Usage: chứa một chuỗi bit được sử dụng để xác định (hoặc
hạn chế) chức năng hoặc dịch vụ được hỗ trợ qua việc sử dụng khoá
công khai trong chứng thư.
- Extended Key Usage: chứa một hoặc nhiều OIDs (định danh
đối tượng – Object Identifier) để xác định cụ thể việc sử dụng khoá
công trong chứng thư. Các giá trị có thể là : (1) xác thực server TLS, (2)
xác thực client TLS, (3) Ký Mã, (4) bảo mật e-mail , (5) Tem thời gian.
- CRL Distribution Point: chỉ ra vị trí của CRL tức là nơi hiện có
thông tin thu hồi chứng thư. Nó có thể là URI (Uniform Resource
Indicator), địa chỉ của X.500 hoặc LDAP server.
- Private Key Usage Period: trường này cho biết thời gian sử
dụng của khoá cá nhân gắn với khóa công khai trong chứng thư.
- Certificate Policies: trường này chỉ ra dãy các chính sách OIDs
gắn với việc cấp và sử dụng chứng thư.
- Policy Mappings: trường này chỉ ra chính sách xác thực tương
đương giữa hai miền CA. Nó được sử dụng trong việc thiết lập xác thực
chéo và kiểm tra đường dẫn chứng thư. Trường này chỉ có trong chứng
thư CA.
- Subject Alternative Name: chỉ ra những dạng tên lựa chọn
gắn với người sở hữu chứng thư. Những giá trị có thể là: địa chỉ e-mail,
địa chỉ IP, địa chỉ URI…
- Issuer Alternative Name: chỉ ra những dạng tên lựa chọn gắn
với người cấp chứng thư.
- Subject Directory Attributes: trường này chỉ ra dãy các
thuộc tính gắn với người sở hữu chứng thư. Trường mở rộng này không
được sử dụng rộng rãi. Nó được dùng để chứa những thông tin liên
quan đến đặc quyền.
- Basic Constraints Field: trường này cho biết đây có phải là
chứng thư CA hay không bằng cách thiết lập giá trị logic (true). Trường
này chỉ có trong chứng thư CA. Chứng thư CA dùng để thực hiện một số
chức năng. Chứng thư này có thể ở một trong hai dạng. Nếu CA tạo ra
chứng thư để tự sử dụng, chứng thư này được gọi là chứng thư CA tự
ký. Khi một CA mới được thiết lập, CA tạo ra một chứng thư CA tự ký để
ký lên chứng thư của người sử dụng cuối trong hệ thống. Và dạng thứ
hai là CA cấp chứng thư cho những CA khác trong hệ thống.
- Path Length Constraint: trường này chỉ ra số độ dài tối đa của
đường dẫn chứng thư có thể được thiết lập. Giá trị “zero” chỉ ra rằng
CA chỉ có thể cấp chứng thư cho thực thể cuối , không cấp chứng thư
cho những CA khác. (Trường này chỉ có trong chứng thư của CA).
- Name Constrainsts: được dùng để bao gồm hoặc loại trừ các
nhánh trong những miền khác nhau trong khi thiết lập môi trường tin
tưởng giữa các miền PKI.
32
- Policy Constraints: được dùng để bao gồm hoặc loại trừ một
số chính sách chứng thư trong khi thiết lập môi trường tin tưởng giữa
các miền PKI.

Hình 2.3 là nội dung chi tiết một chứng thư do hệ thống OpenCA
cấp.

33
Hình 2.3: Nội dung chi tiết của chứng thư

2.1.3 Thu hồi chứng thư

Trong một số trường hợp như khoá bị xâm hại, hoặc người sở hữu
chứng thư thay đổi vị trí, cơ quan…thì chứng thư đã được cấp không có
hiệu lực. Do đó, cần phải có một cơ chế cho phép người sử dụng chứng
thư kiểm tra được trạng thái thu hồi chứng thư. X.509 cho phép kiểm
tra chứng thư trong các trường hợp sau:

- Chứng thư không bị thu hồi


- Chứng thư đã bị CA cấp thu hồi
- Chứng thư do một tổ chức có thẩm quyền mà CA uỷ thác có
trách nhiệm thu hồi chứng thư thu hồi

34
Cơ chế thu hồi X.509 xác định là sử dụng danh sách thu hồi
chứng thư (CRLs). X.509 đưa ra sự phân biệt giữa ngày, thời gian chứng
thư bị CA thu hồi và ngày, thời gian trạng thái thu hồi được công bố
đầu tiên. Ngày thu hồi thực sự được ghi cùng với đầu vào chứng thư
trong CRL. Ngày thông báo thu hồi được xác định trong header của CRL
khi nó được công bố. Vị trí của thông tin thu hồi có thể khác nhau tuỳ
theo CA khác nhau. Bản thân chứng thư có thể chứa con trỏ đến nơi
thông tin thu hồi được xác định vị trí. Người sử dụng chứng thư có thể
biết thư mục, kho lưu trữ hay cơ chế để lấy được thông tin thu hồi dựa
trên những thông tin cấu hình được thiết lập trong quá trình khởi sinh.

Để duy trì tính nhất quán và khả năng kiểm tra, CA yêu cầu:
- Duy trì bản ghi kiểm tra chứng thư thu hồi
- Cung cấp thông tin trạng thái thu hồi
- Công bố CRLs khi CRL là danh sách trống
2.1.4 Chính sách của chứng thư

Như được giới thiệu trong phần trên, một số mở rộng liên quan
đến chính sách có trong chứng thư. Những mở rộng liên quan đến
chính sách này được sử dụng trong khi thiết lập xác thực chéo giữa các
miền PKI. Một chính sách chứng thư trong X.509 được định nghĩa là
“tên của tập các qui tắc chỉ ra khả năng có thể sử dụng của chứng thư
cho một tập thể đặc thù và một lớp ứng dụng với những yêu cầu bảo
mật chung” [7].

Chính sách có định danh duy nhất (được biết đến như định danh
đối tượng hay OID) và định danh này được đăng ký để người cấp và
người sử dụng chứng thư có thể nhận ra và tham chiếu đến. Một chứng
thư có thể được cấp theo nhiều chính sách. Một số có thể là thủ tục và
mô tả mức đảm bảo gắn với việc tạo và quản lý chứng thư. Những
chính sách khác có thể là kỹ thuật và mô tả mức đảm bảo gắn với an
toàn của hệ thống được sử dụng để tạo chứng thư hay nơi lưu trữ khoá
[6].

Một chính sách chứng thư cũng có thể được hiểu là việc giải thích
những yêu cầu và giới hạn liên quan đến việc sử dụng chứng thư được
công bố theo những chính sách này. Chính sách chứng thư - Certificate
Policies (CP) được chứa trong trường mở rộng chuẩn của chứng thư
X.509. Bằng việc kiểm tra trường này trong chứng thư, hệ thống sử

35
dụng chứng thư có thể xác định được một chứng thư cụ thể có thích
hợp cho mục đích sử dụng hay không.

Một thuật ngữ chuyên môn khác “Certificate Practice Statement


(CPS)” được sử dụng để mô tả chi tiết những thủ tục hoạt động bên
trong của CA và PKI cấp chứng thư với chính sách chứng thư đã qui
định.

Chính sách chứng thư đặc biệt quan trọng khi đưa ra quyết định
để xác nhận chéo hai PKI khác nhau.

2.1.5 Công bố và gửi thông báo thu hồi chứng thư

Thông thường chứng thư sẽ hợp lệ trong khoảng thời gian có hiệu
lực. Nhưng trong một số trường hợp chứng thư lại không hợp lệ trước
thời gian hết hạn, ví dụ như:

- Khoá cá nhân của chủ thể bị xâm phạm .


- Thông tin chứa trong chứng thư bị thay đổi
- Khoá cá nhân của CA cấp chứng thư bị xâm phạm
Trong những trường hợp này cần có một cơ chế để thông báo đến
những người sử dụng khác Một trong những phương pháp để thông báo
đến người sử dụng về trạng thái của chứng thư là công bố CRLs định kỳ
hoặc khi cần thiết. Ngoài ra, có một số cách lựa chọn khác để thông
báo đến người sử dụng như dùng phương pháp trực tuyến Online
Certificate Status Protocol [10].

a. Certificate Revocation Lists (CRLs)

CRLs là cấu trúc dữ liệu được ký như chứng thư người sử dụng.
CRLs chứa danh sách các chứng thư đã bị thu hồi và những thông tin
cần thiết khác của người sử dụng. CRL thường do một CA cấp. Tuy
nhiên CRL cũng có thể được sử dụng để cung cấp thông tin cho nhiều
CA nếu nó được định nghĩa như một CRL gián tiếp. Những thông tin này
được chứa trong trường mở rộng CRL Scope.

36
Hình 2.4 là khuôn dạng danh sách chứng thư bị thu hồi.

37
Hình 2.4: Khuôn dạng danh sách chứng thư bị thu hồi

Trong đó:
- Version number: chỉ ra phiên bản của CRL.
- Signature: nhận biết loại hàm băm và thuật toán ký được sử
dụng để ký
danh sách thu hồi CRL.
- Issuer: tên của thực thể cấp và ký CRL.
- This Update: chỉ ra ngày và thời gian CRL được công bố.
- Next Update: chỉ ra ngày và thời gian danh sách thu hồi kế
tiếp được cấp.

38
- List of revoked certificates: chứa danh sách cùng với serial
của những chứng thư bị thu hồi.

Những chứng thư đã bị CA thu hồi được ghi vào danh sách theo
thứ tự của revoked Certificates. Mỗi đầu vào nhận biết chứng thư thông
qua số serial và ngày thu hồi trên đó có ghi rõ thời gian và ngày khi
chứng thư bị CA thu hồi.

b. Authority Revocation List (ARLs)

ARL là một CRL đặc biệt chứa thông tin thu hồi về chứng thư CA.
ARLs không chứa chứng thư của người sử dụng cuối. Những thay đổi
thông thường trong ARL thường hiếm khi xảy ra bởi vì chứng thư của
CA chỉ bị thu hồi khi khoá cá nhân của CA bị xâm hại và đó lại là trường
hợp không thường xảy ra. Nếu chứng thư chéo bị thu hồi thì người cấp
chứng thư chéo này sẽ công bố một ARL mới để thông báo với tất cả
các thực thể khác về tình huống này. ARLs được sử dụng chủ yếu trong
quá trình thẩm tra đường dẫn chứng thư nếu môi trường tin cậy bao
gồm CA có chứng thư xác thực chéo.

c. Cơ chế truy vấn On-line (On-line Query Mechanisms)

CRLs và ARLs giúp người sử dụng cuối nhận biết được về tình
trạng thu hồi chứng thư. Nhưng có một vấn đề nảy sinh là điều gì sẽ
xảy ra nếu CA thu hồi chứng thư ngay sau khi vừa công bố CRL. Không
có người sử dụng nào nhận biết được về việc thu hồi này đến khi một
CRL mới được thông báo.

Một lược đồ khác để kiểm soát được trạng thái của chứng thư do
IETF phát triển là OCSP (Online Certificate Status Protocol). Lược đồ
này dựa trên cơ chế truy vấn trực tiếp hơn việc công bố định kỳ CRLs
và ARLs. OCSP là giao thức yêu cầu/ trả lời đưa ra cơ chế để nhận được
thông tin thu hồi trực tuyến từ thực thể tin cậy là “OCSP Responder”.
Người sử dụng cuối thực hiện yêu cầu với “OCSP Request” với một
danh sách các chứng thư cần được kiểm tra, OCSP Responder trả lời
yêu cầu “OCSP Reply” với trạng thái của mỗi chứng thư. Chứng thư có
thể ở một trong ba trạng thái sau: “good”, “revoked” và “unknown”.

Sử dụng dịch vụ online có một số ưu điểm sau:


- Trả lời thường xuyên và luôn có tính chất mới
- Thời gian trả lời nhanh
39
- Giảm thiểu việc sử dụng băng thông mạng sẵn có
- Tổng phí xử lý phía client thấp

Tuy nhiên dịch vụ online có hạn chế trong trường hợp cần kiểm
tra trạng thái thu hồi nhưng không online .Vấn đề về bảo mật cũng
được đặt ra khi sử dụng dịch vụ này. Hình 2.5 là dịch vụ kiểm tra online
với OCSP Responder là dịch vụ khác nhau.

Hình 2.5: Dịch vụ kiểm tra online

2.2 Các thành phần của PKI

Một hệ thống PKI gồm 4 thành phần sau:

- Certification Authorities (CA)


♦Cấp và thu hồi chứng thư.
- Registration Authorities (RA)
♦Gắn kết giữa khoá công khai và định danh của người giữ
chứng thư.
- Clients
♦Người sử dụng chứng thư PKI hay theo cách khác được xác
định như
40
những thực thể cuối.
♦Người sử dụng cuối hoặc hệ thống là chủ thể của chứng
thư PKI.
- Repository
♦Hệ thống (có thể phân tán) lưu trữ chứng thư và danh
sách các
chứng thư bị thu hồi.
♦Cung cấp cơ chế phân phối chứng thư và CRLs đến các
thực thể cuối.

Các thành phần PKI và các mối quan hệ giữa chúng được chỉ ra
như trong hình 2.6. Đây là mô hình kiến trúc PKI do PKIX đưa ra [7].

Hình 2.6: Các thành phần PKI

41
2.2.1 Tổ chức chứng thực (Certification Authority)

Trong hạ tầng cơ sở khoá công khai, chứng thư có vai trò gắn kết
giữa định danh với khoá công. Sự gắn kết này thể hiện trong dạng cấu
trúc dữ liệu được ký số được đề cập đến như chứng thư đã được thảo
luận ở phần trước. Một certificate authority (CA) là một thực thể PKI có
trách nhiệm cấp chứng thư cho các thực thể khác trong hệ thống.

Tổ chức chứng thực - CA cũng được gọi là bên thứ ba được tin
tưởng vì người sử dụng cuối tin tưởng vào chữ ký số của CA trên chứng
thư trong khi thực hiện những hoạt động mã hoá khoá công khai cần
thiết. Tổ chức cung cấp dịch vụ chứng thực – Certification Service
Provider (CSP) là một thuật ngữ khác nhắc đến CA được sử dụng trong
đồ án.

Thông thường, CA thực hiện chức năng xác thực bằng cách cấp
chứng thư cho các CA khác và cho thực thể cuối (người giữ chứng thư)
trong hệ thống. Nếu CA nằm ở đỉnh của mô hình phân cấp PKI và chỉ
cấp chứng thư cho những CA ở mức thấp hơn thì chứng thư này được
gọi là chứng thư gốc “root certificate”.

2.2.2 Trung tâm đăng ký (Registration Authorities)

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.

42
- Kiểm tra xem chủ thể có thực sự sở hữu khoá cá nhân đ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á cá nhân /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á cá nhân.
- 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á
cá nhân.

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ảnlý 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.

2.2.3 Thực thể cuối ( Người giữ chứng thư và Clients)

Thực thể cuối trong PKI có thể là con người, thiết bị, và thậm chí
là một chương trình phần mềm nhưng thường là người sử dụng hệ
thống. Thực thể cuối sẽ thực hiện những chức năng mật mã (mã hoá,
giải mã và ký số).

2.2.4 Hệ thống lưu trữ (Repositories)

Chứng thư (khoá công) và thông tin thu hồi chứng thư phải được
phân phối sao cho những người cần đến chứng thư đều có thể truy cập
và lấy được. Có 2 phương pháp phân phối chứng thư:

a. Phân phối cá nhân

43
Phân phối cá nhân là cách phân phối cơ bản nhất. Trong phương
pháp này thì mỗi cá nhân sẽ trực tiếp đưa chứng thư của họ cho người
dùng khác. Việc này có thể thực hiện theo một số cơ chế khác nhau.
Chuyển giao bằng tay chứng thư được lưu trong đĩa mềm hay trong
một số các môi trường lưu trữ khác. Cũng có thể phân phối bằng cách
gắn chứng thư trong e-mail để gửi cho người khác.

Cách này thực hiện tốt trong một nhóm ít người dùng nhưng khi
số lượng người dùng tăng lên thì có thể xảy ra vấn đề về quản lý.

b. Phân phối công khai

Một phương pháp khác phổ biến hơn để phân phối chứng thư (và
thông tin thu hồi chứng thư) là công bố các chứng thư rộng rãi, các
chứng thư này có thể sử dụng một cách công khai và được đặt ở vị trí
có thể truy cập dễ dàng. Những vị trí này được gọi là cơ sở dữ liệu.
Dưới đây là ví dụ về một số hệ thống lưu trữ:
- X.500 Directory System Agents (DSAs)
- Lightweight Directory Access Protocol (LDAP ) Server
- Online Certificate Status Protocol (OCSP) Responders
- Domain name System (DNS) và Web servers
- File Transfer Protocol (FTP) Servers và Corporate Databases

2.3 Chức năng cơ bản của PKI

Những hệ thống cho phép PKI có những chức năng khác nhau.
Nhưng nhìn chung có hai chức năng chính là: chứng thực và thẩm tra.

2.3.1 Chứng thực (certification)

Chứng thực là chức năng quan trọng nhất của hệ thống PKI. Đây
là quá trình ràng buộc khoá công khai với định danh của thực thể. CA là
thực thể PKI thực hiện chức năng chứng thực. Có hai phương pháp
chứng thực:
- Tổ chức chứng thực (CA) tạo ra cặp khoá công khai / khoá cá
nhân và tạo ra chứng thư cho phần khoá công của cặp khoá.

44
- Người sử dụng tự tạo cặp khoá và đưa khoá công cho CA để CA
tạo chứng thư cho khoá công đó. Chứng thư đảm bảo tính toàn vẹn của
khoá công khai và các thông tin gắn cùng.

2.3.2 Thẩm tra (validation)

Quá trình xác định liệu chứng thư đã đưa ra có thể được sử dụng
đúng mục đích thích hợp hay không được xem như là quá trình kiểm
tra tính hiệu lực của chứng thư. Quá trình này bao gồm một số bước
sau:
- Kiểm tra xem liệu có đúng là CA được tin tưởng đã ký số lên
chứng thư hay không (xử lý theo đường dẫn chứng thư).
- Kiểm tra chữ ký số của CA trên chứng thư để kiểm tra tính toàn
vẹn.
- Xác định xem chứng thư còn ở trong thời gian có hiệu lực hay
không.
- Xác định xem chứng thư đã bị thu hồi hay chưa.
- Xác định xem chứng thư đang được sử dụng có đúng mục đích,
chính sách, giới hạn hay không (bằng cách kiểm tra những trường mở
rộng cụ thể như mở rộng chính sách chứng thư hay mở rộng việc sử
dụng khoá).

2.3.3 Một số chức năng khác

Hệ thống PKI thực hiện chức năng chứng thực, thẩm tra cùng với
một số chức năng phụ trợ khác. Dưới đây là một số chức năng và dịch
vụ được hầu hết các hệ thống PKI cung cấp. Một số những chức năng
khác có thể được định nghĩa tuỳ theo yêu cầu cụ thể của các hệ thống
PKI.

a. Đăng ký

Đăng ký là quá trình đến hoặc liên lạc với các tổ chức, trung tâm
tin cậy để đăng ký các thông tin và xin cấp chứng thư. RA và CA là
những thực thể trong quá trình đăng ký. Quá trình đăng ký phụ thuộc
vào chính sách của tổ chức. Nếu chứng thư được cung cấp với mục đích
dùng cho những hoạt động bí mật thì sử dụng phương pháp gặp mặt
trực tiếp. Nếu chứng thư chỉ được sử dụng cho những mục đích, hoạt
động thường thì có thể đăng ký qua những ứng dụng viết sẵn hoặc ứng
dụng điện tử.

45
b. Khởi tạo ban đầu

Khi hệ thống trạm của chủ thể nhận được các thông tin cần thiết
để liên lạc với CA thì quá trình khởi tạo bắt đầu. Những thông tin này
có thể là khoá công của CA, chứng thư của CA, cặp khóa công /bí mật
của chủ thể.

Một số hệ thống khác sử dụng cơ chế dựa trên password trong


giai đoạn khởi tạo. Người dùng cuối liên lạc với CA khi nhận được
password và sau đó thiết lập một kênh bảo mật để truyền những thông
tin cần thiết. Giai đoạn khởi tạo thường tiếp tục với quá trình chứng
thực.

c. Khôi phục cặp khoá

Hầu hết hệ thống PKI tạo ra hai cặp khoá cho người sử dụng cuối,
một để ký số và một để mã hoá. Lý do để tạo hai cặp khoá khác nhau
xuất phát từ yêu cầu khôi phục và sao lưu dự phòng khoá.

Tuỳ theo chính sách của tổ chức, bộ khoá mã (mã và giải mã) và
những thông tin liên quan đến khoá của người sử dụng phải được sao
lưu để có thể lấy lại được dữ liệu khi người sử dụng mất khoá cá nhân
hay rời khỏi đơn vị.

Còn khoá để ký số được sử dụng tuỳ theo mục đích cá nhân nên
không được sao lưu. Riêng khoá cá nhân của CA thì được lưu giữ dự
phòng trong một thời gian dài để giải quyết những vấn đề nhầm lẫn có
thể xảy ra trong tương lai. Hệ thống PKI có những công cụ để thực hiện
chức năng sao lưu và khôi phục khoá.

d. Tạo khoá

Cặp khoá công khai/bí mật có thể được tạo ở nhiều nơi. Chúng có
thể được tạo ra bằng phần mềm phía client và được gửi đến CA để
chứng thực.

CA cũng có thể tạo ra cặp khoá trước khi chứng thực. Trong
trường hợp này, CA tự tạo cặp khoá và gửi khoá cá nhân này cho người
sử dụng theo một cách an toàn. Nếu khoá do bên thứ ba tạo ra thì
những khoá này phải được CA tin cậy trong miền xác nhận trước khi sử
dụng.

46
e. Hạn sử dụng và cập nhật khoá

Một trong những thuộc tính của chứng thư là thời gian hiệu lực.
Thời gian hiệu lực của mỗi cặp khoá được xác định theo chính sách sử
dụng. Các cặp khoá của người sử dụng nên được cập nhật khi có thông
báo về ngày hết hạn. Hệ thống sẽ thông báo về tình huống này trong
một thời gian nhất định. Chứng thư mới sẽ được người cấp công bố tự
động sau thời gian hết hạn.

f. Xâm hại khoá

Đây là trường hợp không bình thường nhưng nếu xảy ra thì khoá
mới sẽ được công bố và tất cả người sử dụng trong hệ thống sẽ nhận
thấy điều này. Xâm hại đến khoá của CA là một trường hợp đặc biệt.
Và trong trường hợp này thì CA sẽ công bố lại tất cả các chứng thư với
CA-certificate mới của mình

g. Thu hồi

Chứng thư được công bố sẽ được sử dụng trong khoảng thời gian
có hiệu lực. Nhưng trong trường hợp khoá bị xâm hại hay có sự thay đổi
trong thông tin của chứng thư thì chứng thư mới sẽ được công bố,
chứng thư cũ sẽ bị thu hồi.

h. Công bố và gửi thông báo thu hồi chứng thư

Một chứng thư được cấp cho người sử dụng cuối sẽ được gửi đến
cho người nắm giữ và hệ thống lưu trữ để có thể truy cập công khai.
Khi một chứng thư bị thu hồi vì một lý do nào đó, tất cả người sử dụng
trong hệ thống sẽ được thông báo về việc này. Phương thức để công bố
và gửi những thông báo thu hồi đã được đề cập chi tiết trong nội dung
về chứng thư số ở phần trên.

i. Xác thực chéo

Xác thực chéo là một trong những đặc tính quan trọng nhất của
hệ thống PKI. Chức năng này được sử dụng để nối hai miền PKI khác
nhau. Xác thực chéo là cách để thiết lập môi trường tin cậy giữa hai CA
dưới những điều kiện nhất định.

Những điều kiện này được xác định theo yêu cầu của người sử
dụng. Những người sử dụng ở các miền khác nhau chỉ có thể giao tiếp
47
an toàn với người khác sau khi việc xác thực chéo giữa các CA thành
công.

Xác thực chéo được thiết lập bằng cách tạo chứng thư CA xác
thực lẫn nhau. Nếu CA-1 và CA-2 muốn thiết lập xác thực chéo thì cần
thực hiện một số bước sau:

- CA-1 công bố CA – certificate cho CA-2.


- CA-2 công bố CA – certificate cho CA-1.
- CA-1 và CA-2 sẽ sử dụng những trường mở rộng xác định trong
chứng thư để đặt những giới hạn cần thiết trong CA-certificate.

Việc xác thực chéo đòi hỏi phải có sự kiểm tra cẩn thận các chính
sách PKI. Nếu cả hai đều có cùng hoặc tương tự chính sách của nhau
thì việc xác thực chéo sẽ có ý nghĩa. Ngược lại, sẽ có những tình huống
không mong muốn xuất hiện trong trường hợp chính sách PKI của một
miền trở thành một phần của miền khác.

Trường mở rộng “Policy mapping”, “name constraints” và “policy


constraints” của chứng thư X.509 chuẩn được sử dụng trong xác thực
chéo để đưa ra một số giới hạn trong môi trường tin cậy.

Hình 2.7 dưới đây minh hoạ đường dẫn cấp chứng thư được xây
dựng giữa 2 CA (2 CA này đã thiết lập mối quan hệ tin cậy sử dụng xác
thực chéo ngang hàng). Mô hình chỉ ra chứng thư chéo được cấp giữa
mỗi CA và chứng thư thực thể cuối được CA cấp. Người cấp của một
chứng thư là chủ thể của chứng thư khác. Khoá công khai được xác
nhận trong một chứng thư tương ứng với khoá cá nhân được sử dụng
để ký chứng thư khác.

48
Hình 2.7: Đường dẫn chứng thư chéo

2.4 Mô hình tin cậy cho PKI

X.509 định nghĩa sự tin cậy như sau: “Một thực thể có thể được
nói là tin cậy với một thực thể thứ hai nếu nó (thực thể đầu tiên ) tạo ra
sự đảm bảo rằng thực thể thứ hai sẽ thực hiện chính xác như thực thể
thứ nhất mong đợi” [7].

Định nghĩa này có thể được diễn đạt lại về mặt PKI như sau: một
thực thể cuối tin cậy một CA khi thực thể cuối cho rằng CA sẽ thiết lập
và duy trì sự gắn kết các thuộc tính của khoá công một cách chính xác.

49
Có một số mô hình tin cậy có thể được áp dụng hoặc được đề
xuất để sử dụng trong hạ tầng mã khoá công khai - PKI dựa trên X.509:

- Single CA Model (mô hình CA đơn )


- Hierarchical Model (Mô hình phân cấp )
- Mesh Model (Mô hình mắt lưới – mô hình xác thực chéo)
- Hub and Spoke (Bridge CA) Model (Mô hình cầu CA)
- Web Model (Trust Lists) (Mô hình web)
- User Centric Model (Mô hình người sử dụng trung tâm )

2.4.1 Mô hình CA đơn

Đây là mô hình tổ chức CA cơ bản và đơn giản nhất. Trong mô


hình CA đơn chỉ có một CA xác nhận tất cả các thực thể cuối trong
miền PKI. Mỗi người sử dụng trong miền nhận khoá công khai của CA
gốc (root CA) theo một số cơ chế nào đó. Trong mô hình này không có
yêu cầu xác thực chéo. Chỉ có một điểm để tất cả người sử dụng có thể
kiểm tra trạng thái thu hồi của chứng thư đã được cấp. Mô hình này có
thể được mở rộng bằng cách có thêm các RA ở xa CA nhưng ở gần các
nhóm người dùng cụ thể.

Mô hình này được minh hoạ trong hình 2.8.

Hình 2.8: Mô hình CA đơn

50
Mô hình này dễ để triển khai và giảm tối thiểu được những vấn đề
về khả năng tương tác. Nhưng mô hình này có một số nhược điểm sau:

- Không thích hợp cho miền PKI lớn vì một số người sử dụng ở
những miền con có những yêu cầu khác nhau đối với người ở miền
khác.
- Có thể không có tổ chức nào tình nguyện vận hành CA đơn hoặc
một số tổ chức lại có thể không tin tưởng vào những người vận hành
CA này vì một vài lý do nào đó.
- Việc quản trị và khối lượng công việc kỹ thuật của việc vận
hành CA đơn sẽ rất cao trong cộng đồng PKI lớn.
- Chỉ có một CA sẽ gây ra thiếu khả năng hoạt động và CA này có
thể trở thành mục tiêu tấn công.

2.4.2 Mô hình phân cấp

Mô hình này tương ứng với cấu trúc phân cấp với CA gốc và các
CA cấp dưới. CA gốc xác nhận các CA cấp dưới, các CA này lại xác nhận
các CA cấp thấp hơn. Các CA cấp dưới không cần xác nhận các CA cấp
trên.

51
Hình 2.9: Mô hình phân cấp

Mô hình phân cấp được minh hoạ như Hình 2.9 ở trên.

Trong mô hình này, mỗi thực thể sẽ giữ bản sao khoá công khai
của root CA và kiểm tra đường dẫn của chứng thư bắt đầu từ chữ ký
của CA gốc. Đây là mô hình PKI tin cậy sớm nhất và được sử dụng
trong PEM.

* Ưu điểm của mô hình:

- Mô hình này có thể dùng được trực tiếp cho những doanh nghiệp
phân cấp
và độc lập, cũng như những tổ chức chính phủ và quân đội.
- Cho phép thực thi chính sách và chuẩn thông qua hạ tầng cơ sở.
- Dễ vận hành giữa các tổ chức khác nhau.

* Nhược điểm:

- Có thể không thích hợp đối với môi trường mà mỗi miền khác
nhau cần có chính sách và giải pháp PKI khác nhau.
52
- Các tổ chức có thể không tự nguyện tin vào các tổ chức khác.
- Có thể không thích hợp cho những mối quan hệ ngang hàng
giữa chính phủ
và doanh nghiệp.
- Những tổ chức thiết lập CA trước có thể không muốn trở thành
một phần
của mô hình.
- Có thể gây ra sự trội hơn của sản phẩm đối với vấn đề về khả
năng tương tác.
- Chỉ có một CA gốc nên có thể gây ra một số vấn đề như thiếu
khả năng hoạt động. Thêm vào đó, trong trường hợp khoá cá nhân của
CA bị xâm phạm, khoá công khai mới của CA gốc phải được phân phối
đến tất cả các người sử dụng cuối trong hệ thống theo một số cơ chế
khác nhau.

Mặc dù có những nhược điểm, song mô hình này vẫn thích hợp
với yêu cầu của các tổ chức chính phủ vì cấu trúc phân cấp tự nhiên
sẵn có.

2.4.3 Mô hình mắt lưới (xác thực chéo)

Mô hình mắt lưới là mô hình đưa ra sự tin tưởng giữa hai hoặc
nhiều CA. Mỗi CA có thể ở trong mô hình phân cấp hoặc trong mô hình
mắt lưới khác. Trong mô hình này không chỉ có một CA gốc mà có
nhiều hơn một CA gốc phân phối sự tin cậy giữa các CA với nhau.
Thông qua việc xác thực chéo giữa các CA gốc, các CA có thể tin tưởng
lẫn nhau. Xác thực chéo liên kết các miền khác nhau bằng việc sử
dụng thuộc tính BasicConstraints, Name Constraints, PolicyMapping và
PolicyConstraints của X.509 v3 mở rộng.

Trong cấu hình mắt lưới đầy đủ, tất cả các CA gốc xác nhận chéo
lẫn nhau. Điều này yêu cầu n2 lần xác thực trong hạ tầng cơ sở. Hình
2.10 là minh hoạ biểu diễn bằng đồ thị mô hình này.

53
Hình 2.10: Mô hình mắt lưới

*Ưu điểm của mô hình:

- Linh hoạt hơn và phù hợp với nhu cầu giao dịch hiện nay.
- Cho phép những nhóm người sử dụng khác nhau có thể tự do
phát triển và thực thi những chính sách và chuẩn khác nhau.
- Cho phép cạnh tranh.
- Không phải là mô hình phân cấp và khắc phục được những
nhược điểm của mô hình phân cấp tin cậy ở trên.

* Nhược điểm:

- Phức tạp và khó để quản lý vì việc xác thực chéo.


- Khó có khả năng thực hiện và có thể không hoạt động vì những
lý do do
giao tác.
- Phần mềm người sử dụng có thể gặp phải một số vấn đề khi tìm
chuỗi
chứng thư.
- Để tìm chuỗi chứng thư và CRLs với những mô hình khác thì việc
sử dụng
thư mục có thể trở nên khó hơn.

54
Hiện nay, các tổ chức chính phủ và công ty đang thiết lập CA
riêng theo yêu cầu PKI của mình. Khi có yêu cầu xử lý giao tiếp giữa
các tổ chức khác nhau, những CA này sẽ tiến hành xác thực chéo độc
lập với nhau dẫn đến sự phát triển của thế giới Internet sẽ diễn ra
trong mô hình tin cậy theo các hướng khác nhau.

2.4.4 Mô hình Hub và Spoke (Bridge CA)

Trong mô hình Hub và Spoke, thay bằng việc thiết lập xác thực
chéo giữa các CA, mỗi CA gốc thiết lập xác thực chéo với CA trung tâm.
CA trung tâm này làm cho việc giao tiếp được thuận lợi hơn. CA trung
tâm được gọi là hub (hoặc bridge) CA . Động cơ thúc đẩy mô hình này
là giảm số xác thực chéo từ n2 xuống n.

Một điểm quan trọng khác với cấu hình này là CA trung tâm
không tạo ra sự phân cấp. Tất cả các thực thể trong cấu hình đều giữ
khoá công khai của CA cục bộ, không có khoá của CA trung tâm. Như
vậy, rõ ràng mô hình này giảm đi nhược điểm của mô hình mạng
nhưng lại gặp phải khó khăn trong việc thiết lập bridge CA làm việc với
các CA khác trong hạ tầng cơ sở để các CA này có thể hoạt động được
với nhau.

Mô hình này do US Federal PKI phát triển đầu tiên. Nó mở rộng


PKIs qua một số tổ chức lớn chia sẻ những chính sách có khả năng
tương thích một cách đặc biệt và có những CA đã được thiết lập trước
đây. Minh hoạ biểu diễn cho mô hình hub và spoke được thể hiện trong
hình 2.11.

55
Hình 2.11: Mô hình Hub và Spoke (Bridge CA)

2.4.5 Mô hình Web (Trust Lists)

Khái niệm về mô hình web được lấy ra từ tên của nó (www).


Trong mô hình này, mỗi nhà cung cấp trình duyệt gắn vào trình duyệt
một hoặc nhiều khoá công khai của một số root CA phổ biến hoặc nổi
tiếng. Mô hình này thiết lập một mô hình tin tưởng tự động giữa các
các root CA mà khoá của các CA này được gắn trong trình duyệt và
người sử dụng.

Danh sách tin cậy phần lớn được sử dụng để xác thực web server
mà những web server này được CA xác nhận trong danh sách trình
duyệt client. Quá trình này được thực hiện một cách tự động với giao
thức SSL.

* Ưu điểm:
- Dễ để triển khai vì danh sách đã có sẵn trong trình duyệt

56
- Không cần thay đổi khi làm việc với trình duyệt web (Internet
Explorer, Netscape Navigator) và tiện ích e-mail (Outlook Express,
Microsoft Outlook, Netscape Navigator).

* Nhược điểm:

- Về mặt công nghệ thì có thể thêm hay sửa đổi một root CA mới
nhưng hầu hết người dùng trình duyệt lại không quen thuộc với công
nghệ PKI và phụ thuộc vào những CA ở trong trình duyệt này
- Người sử dụng phải tin tưởng vào danh sách CA trong trình
duyệt. Nhưng một câu hỏi đặt ra là làm thế nào để có thể đảm bảo
chắc chắn về tính chất tin cậy của CA? Các kết quả nghiên cứu cho
thấy rằng hiện nay chưa có cách nào để phân biệt mức độ xác thực
giữa các chứng thư.
- Không thể thông báo đến tất cả trình duyệt của người sử dụng
nếu khoá công khai của một CA nào đó bị xâm hại.

Mô hình này đơn giản trong việc thực thi và đối với người dùng.
Do đó có khả năng để triển khai nhanh và sử dụng với các giải pháp
COST (Commercial of the Shelf) sẵn có.
Mô hình này đặc biệt thích hợp cho yêu cầu PKI của những ứng
dụng dựa trên Web.

2.4.6 Mô hình người sử dụng trung tâm (User Centric Model)

Trong mô hình này, mỗi người sử dụng trực tiếp và hoàn toàn có
trách nhiệm trong việc quyết định tin tưởng hay từ chối chứng thư. Mỗi
người sử dụng giữ một khoá vòng và khoá này đóng vai trò như CA của
họ. Khoá vòng chứa khoá công khai được tin cậy của những người sử
dụng khác trong cộng đồng. Mô hình này được Zimmerman phát triển
để sử dụng trong chương trình phần mềm bảo mật PGP.

Mô hình này có một số hạn chế sau:


- Không có khả năng mở rộng và thích hợp với những miền lớn.
- Khó để đặt mức độ tin cậy đối với khoá công được lấy từ người
khác. Không có sự nhất quán của quá trình xác thực vì nó phụ thuộc
vào người sử dụng.
- Người sử dụng phải quản lý PKI và cần phải hiểu sâu về nó.
Mặc dù có những nhược điểm song mô hình này vẫn thích hợp
cho việc sử dụng cá nhân trên Internet.
57
Mỗi mô hình đều có ưu và nhược điểm riêng. Việc lựa chọn mô
hình nào tuỳ thuộc vào những yêu cầu mục đích của cộng đồng người
dùng, tổng chi phí, thời gian triển khai, nhân lực quản lý, công nghệ hỗ
trợ và một số vấn đề liên quan khác.

58
CHƯƠNG 3

PHƯƠNG ÁN THIẾT KẾ XÂY DỰNG HỆ THỐNG


BK-BIOPKI-OPENCA TRONG KHUÔN KHỔ ĐỀ TÀI KC.01.11

3.1 Giới thiệu

3.1.1 Đề tài KC.01.11

Hệ thống BK-BioPKI-OpenCA được xây dựng và phát triển trong khuôn khổ đề
tài nghiên cứu khoa học công nghệ cấp nhà nước KC01.11/06-10 “Hệ thống an ninh
thông tin dựa trên sinh trắc học sử dụng công nghệ nhúng BioPKI” của khoa CNTT nhằm
nghiên cứu và thử nghiệm một số giải pháp tích hợp sinh trắc học vào hạ tầng cơ sở khóa
công khai PKI.

59
3.1.2 Sinh trắc học

a. Sinh trắc học là gì

Sinh trắc (Biometric) là đặc tính hay thuộc tính vật lý hay sinh học mà có thể định
lượng được [11]. Nó có thể được dùng là phương tiện chứng minh định danh của người
dùng. Một vài đặc tính sinh trắc học như: chiều cao, cân nặng, mùi cơ thể, vân tay, mống
mắt, khuôn mặt, hình dạnh bàn tay hay ngón tay, giọng nói, chữ kí…

Hình 3.1: Các thuộc tính sinh trắc học khác nhau

Các thuộc tính sinh trắc được phân loại thành các tập nhỏ hơn và không phải tất cả
các thuộc tính này đều phù hợp cho mục đích nhận dạng, thẩm định. Các tiêu chuẩn để
đánh giá một thuộc tính sinh trắc có thể đuợc sử dụng cho mục đích này hay không như
sau [11]:
• Tính phổ dụng (Universality): Tất cả mọi người đều phải có đặc tính sinh trắc học
này: như khuôn mặt, mống mắt, vân tay…

• Tính duy nhất (Uniqueness): Đặc trưng sinh trắc học này của từng người phải khác
nhau và là duy nhất.

• Tính bền vững (Permanence): Những đặc trưng sinh trắc học phải khá ổn định
trong suốt cuộc đời của con người.

60
• Tính khả dụng (Collectability): Đặc trưng sinh trắc học này phải được thu thập
một cách dễ dàng và khá nhanh chóng cho mục đích nhận dạng.

• Tính hiệu quả (Performance): Mức độ chính xác phải khá cao sao cho các hệ thống
có thể được triển khai tin cậy trong thực tế.

• Tính chấp nhận được (Acceptability): Các ứng dụng sinh trắc học sẽ không thể
được triển khai trong thực tế nếu nó nhận được sự phản đối lâu dài và mạnh mẽ
của con người.

• Tính an toàn (Resistance to Circumvention): Hệ thống có dễ dàng bị giả mạo hay


không.

Biomertric Phổ Duy Bền Khả Hiệu Chấp Bị giả


dụng nhất vững dụng quả nhận mạo
Face H L M H L H L
Fingerprint M H H M H M H
Hand M M M H M M M
geometry
Keystrokes L L L M L M M
Hand veins M M M M M M H
Iris H H H M H L H
Retinal scan H H M L H L H
Signature L L L H L H L
Voice M L L M L H L
Facial H H L H M H H
thermograph
Odor H H H L L M L
DNA H H H L H L L
Gait M L L H L H M
Ear Canal M M H M M H M

Hình 3.2: Bảng so sánh các đặc trưng sinh trắc học theo A. K. Jain [11]
(H - cao, M - trung bình, L - thấp)

61
b. Các giải pháp tích hợp sinh trắc để bảo vệ khoá cá nhân

Vấn đề bảo vệ khóa cá nhân luôn được chú trọng vì khóa cá nhân đóng vai trò bảo
mật trung tâm cho toàn bộ hoạt động khác. Nếu khóa cá nhân của người dùng bị mất trộm
thì đương nhiên những tài liệu mật gửi cho anh ta sẽ không còn an toàn. Trong trường
hợp khóa cá nhân của một CA bị mất thì toàn bộ các CA và người dùng cấp dưới của nó
sẽ không đảm bảo độ tin cậy, vì người lấy được khóa cá nhân đó có thể cấp chứng thư số
cho bất kỳ một CA hay người dùng giả mạo nào đó nhân danh CA này. Nếu CA gốc bị
mất khóa cá nhân thì toàn bộ hệ thống PKI trở nên vô nghĩa và sụp đổ. Có thể thấy, vấn
đề bảo vệ khóa cá nhân mang ý nghĩa rất lớn.

Vấn đề xác thực và thẩm định chủ thể, điểm yếu của PKI, lại là điểm mạnh của
sinh trắc học. Do đó xu thế kết hợp sinh trắc học với PKI thành BioPKI là xu thế tất yếu.
Hệ thống BioPKI được xây dựng sẽ đảm bảo định danh chính xác người dùng, bảo vệ an
toàn tuyệt đối khóa cá nhân, đồng thời mang lại sự tiện lợi cho người sử dụng.

Sau đây ta sẽ trình bày về các hướng tiếp cận của hệ thống sinh trắc học vào PKI
để tạo nên một hệ thống có tính an toàn cao, hệ thống BioPKI [12].

 Hướng dùng sinh trắc để thẩm định người dùng

Theo hướng này, người dùng mỗi khi sử dụng hệ thống PKI cần gửi kèm theo
thông tin sinh trắc học để chứng minh bản thân. Nói cách khác, thông tin sinh trắc học đó
chính là một dạng chứng nhận kèm theo chứng thư số anh ta được cấp. Hoạt động của
hướng này có thể hình dung như sau: Alice muốn yêu cầu một chứng thư số tại CA.
Trước hết, Alice phải có mẫu sinh trắc học lưu tại cơ sở dữ liệu trong hệ thống. Khi đăng
ký chứng thư số, ngoài các thông tin thông thường Alice còn phải gửi kèm theo thông tin
sinh trắc học của mình. Ngoài các thủ tục xác minh thông thường, hệ thống còn thực hiện
thêm việc đối sánh thông tin sinh trắc học kèm theo đó với mẫu đã lưu. Alice chỉ được
cấp chứng thư khi kết quả đối sánh là khẳng định. Một tình huống khác: Bob đang dùng
khóa cá nhân B, hệ thống muốn kiểm tra tính hợp lệ, xem Bob có đúng là chủ của khóa
cá nhân đó không. Lúc đó, hệ thống sẽ yêu cầu Bob gửi thông tin sinh trắc học đến để đối
sánh với mẫu của chủ khóa cá nhân B đã lưu trong cơ sở dữ liệu. Kết quả đối sánh đúng
hoặc sai sẽ quyết định Bob có quyền được sử dụng tiếp không hay phải dừng lại. Hướng
này làm tăng tính tin cậy của hệ thống khá nhiều, nhưng lại vấp phải một số nhược điểm
sau [12]:

• Mẫu sinh trắc học được lưu trữ tập trung, do vậy đặt ra vấn đề bảo đảm an toàn
cho máy chủ lưu trữ.

62
• Thực hiện đối sánh sinh trắc học và quyết định quyền sử dụng dịch vụ là hai công
việc tách rời nhau. Kết quả của đối sánh sinh trắc được gửi qua môi trường truyền
thông, do vậy có nảy sinh nguy cơ bị tấn công vào kênh truyền thông nhằm làm
sai lệch kết quả trả lời.

• Đặc trưng sinh trắc học được gửi từ người dùng tới máy chủ để đối sánh nên có
thể bị mất trộm và dẫn đến tấn công giả mạo.

 Hướng dùng sinh trắc để sinh khóa cá nhân

Theo hướng này, khóa cá nhân được sinh trực tiếp dựa trên đặc trưng sinh trắc học
và được dùng để ký các dữ liệu. Ưu điểm lớn nhất của giải pháp này là nó không cần nơi
để lưu trữ, do vậy loại bỏ nguy cơ tấn công khóa cá nhân. Mặt khác, hệ thống rất thuận
tiện khi bản thân người dùng đã “mang” theo khóa cá nhân để sử dụng ở bất kỳ đâu,
không cần thiết phải có đĩa lưu trữ hoặc smartcard. Khóa công khai sẽ được sinh tương
ứng với khóa cá nhân này theo thuật toán DSA.

Trong trường hợp người dùng có nhu cầu có nhiều khóa cá nhân để dùng trong các
hệ thống khác nhau, ta sẽ dùng các hàm băm khác nhau để băm khóa cá nhân. Do tính
chất của các hàm băm, mỗi giá trị băm ra có thể được coi là một khóa cá nhân mới để
dùng cho các hệ thống khác. Giải pháp này gồm hai pha:

• Thu nhận mẫu đặc trưng sinh học có độ ổn định cao


• Sinh khóa cá nhân từ mẫu này.

Khó khăn chính của quá trình này là sự đảm bảo tuyệt đối duy nhất của khóa từ
mẫu sinh trắc học, trong khi mẫu này thường có đặc tính thiếu ổn định, có sai số. Chính
vì nhược điểm này mà giải pháp này mặc dù rất tốt về mặt lý thuyết nhưng lại rất khó
thực hiện được trong thực tế. Vì vậy phương pháp này vẫn chưa được triển khai trong
thực tế.

 Hướng sinh khóa sinh trắc mã hóa bảo vệ khóa cá nhân

Theo hướng này, khóa cá nhân sẽ được bảo vệ bởi khóa mã sinh ra từ mẫu sinh
trắc học. Người dùng sẽ được lấy mẫu sinh trắc học, từ mẫu sinh trắc học này, hệ thống
tạo ra một tập khóa mã, các khóa mã này sẽ được dùng để mã hóa khóa cá nhân, tập khóa
cá nhân được mã hóa bởi các khóa mã khác nhau sẽ được lưu lại (trên Smartcard hay
trong CSDL tập trung). Và, tập khóa mã cũng như khóa cá nhân sẽ được xóa bỏ sau quá
trình mã hóa này, như vậy, ở giải pháp này, rõ ràng đã tránh được nhược điểm sợ mất cắp
khóa cá nhân cũng như mất cắp các thông tin về đặc điểm người dùng (đặc trưng sinh
trắc học). Khi người dùng muốn lấy khóa cá nhân, họ cũng sẽ phải cung cấp mẫu sinh
63
trắc học và hệ thống cũng tạo ra tập khóa mã từ mẫu sinh trắc học đó, hệ thống sẽ lần lượt
thử các khóa mã xem có giải mã được các khóa cá nhân đã được mã hóa. Nếu có khóa mã
giải mã thành công, thì khóa cá nhân sẽ được lấy ra cho người dùng.

Hệ thống BK-BioPKI-OpenCA sẽ tích hợp sinh trắc theo hai hướng đó là hướng
dùng sinh trắc để thẩm định người dùng và hướng sinh khóa sinh trắc mã hóa bảo vệ
khóa cá nhân.

3.1.3 Tổng quan về hệ thống OpenCA

3.1.3.1 Giới thiệu


OpenCA là một hệ thống mã nguồn mở, được xây dựng và phát
triển bởi rất nhiều nhà lập trình trên thế giới. OpenCA được xây dựng
với mục đích tạo ra một hệ thống công cụ nhằm hỗ trợ cho các dự án
về bảo mật.OpenCA hỗ trợ từ mức độ thấp như mã hoá dữ liệu,tạo chữ
ký số cho đến các hệ thống an toàn dữ liệu cao cấp. Mã nguồn của
OpenCA được cung cấp rộng rãi trên www.openca.org.
Từ những đặc điểm như trên có thể thấy OpenCA chính là một công cụ rất hiệu
quả để xây dựng những ứng dụng theo mô hình hạ tầng khoá công khai PKI. OpenCA hỗ
trợ xây dựng tất cả các thủ tục lõi cho một ứng dụng PKI từ việc sinh khoá mã hoá giải
mã dữ liệu cho tới các thủ tục cấp phát,thu hồi chứng thư,tạo chữ ký số…Với tất cả
những cái đó,ta có thể xây dựng một ứng dụng theo mô hình PKI cơ sở, phần mở rộng
còn lại sẽ được xây dựng tiếp theo định hướng của nhà phát triển.
Các thành phần chính của OpenCA bao gồm 3 thành phần là hệ thống thư viện
OpenSSL, cơ sở dữ liệu và giao diện web. Trong đó giao diện web được xây dựng bằng
ngôn ngữ Perl. Thư viện OpenSSL thực hiện các tiến trình về mã hoá. [14]

64
Hình 3.3: Các thành phần của hệ thống OpenCA

3.1.3.2 Đánh giá về hệ OpenCA

a. Ưu điểm của hệ thống

 OpenCA được thiết kế và xây dựng theo nguyên lý của mô hình PKI và nó đảm
bảo đầy đủ những chức năng cơ sở của một hệ PKI cần phải có: Cấp phát, gia
hạn, thu hồi chứng thư số, đảm bảo tính xác thực, an toàn tin cậy.
 Với các kịch bản đã thử nghiệm trong thời gian dài hệ thống đã hoạt động khá ổn
định và không xảy ra những lỗi nghiêm trọng dẫn đến từ chối dịch vụ.
 Hệ mã nguồn mở OpenCA hoàn toàn tương thích với môi trường Linux và không
hề gây xung đột với các hệ thống khác cùng cài đặt trên một hệ điều hành.
 Hệ thống OpenCA sử dụng rất nhiều chuẩn công nghiệp( như các chuẩn về chứng
thư số X509). Vì vậy nó được chấp nhận và sử dụng rất rộng rãi trong thực tế.

b. Những điểm còn hạn chế của hệ thống

 Lỗi không xác định khi RA ký lên các yêu cầu gửi lên cho CA.
 Không làm việc được với các thiết bị sử dụng chuẩn USB 2.0
 Khó khăn trong việc cài đặt và thay đổi

3.1.4 Mục đích của hệ thống BK BioPKI-OpenCA

Như đã nói ở trên, hệ BK BioPKI-OpenCA đúng như cái tên của nó, được xây
dựng với tiêu chí là tích hợp sinh trắc vào mô hình PKI xử dụng các chuẩn chứng thư số
của hệ thống OpenCA cung cấp. Hệ thống là sự kết hợp giữa 3 yếu tố là sinh trắc, mô
hình PKI và hệ thống OpenCA. Mỗi thành phần của hệ thống đều có những ưu điểm và
nhược điểm, và các thành phần còn lại có khả năng bổ xung cho các nhược điểm đó.
Điểm yếu của PKI là nguy cơ bị sâm hại khoá cá nhân, nhưng khi được tích hợp sinh trắc
để bảo vệ thì hệ thống đã trở nên an toàn hơn rất nhiều. OpenCA cúa ưu điểm là nó được
chấp nhận và sử dụng rất rộng rãi trên toàn thế giới, nhưng có nhược điểm là khó cài đặt
và thay đổi, không có khả năng giao tiếp với các thiết bị nhúng sử dụng chuẩn USB 2.0.
Khả năng tích hợp sinh trắc trực tiếp vào hệ thống OpenCA như nhóm đề tài đã nghiên
cứu là không có. Nhưng khi có một hệ thống PKI xây dựng mới,có khả năng tích hợp
sinh trắc đồng thời sử dụng những chứng thư số theo chuẩn của OpenCA thì vấn đề này
có thể được giải quyết hoàn toàn, đảm bảo tính an toàn, tin cậy và khả năng triển khai
thực tế. Chính vì thế nhóm làm đề tài quyết định triển khai xây dựng hệ thống BK-
BioPKI-OpenCA.

65
3.2 Thư viện OpenSSL

Hệ thống được phát triển kế thừa dựa trên hệ thống BK-BioPKI đã được xây dưng
và thử nghiệm trên phòng thí nghiệm.

Môi trường phát triển : hệ thống được viết trên môi trường VC++ 2005, cơ sở dữ
liệu MySQL sử dụng các hàm C API, hệ thống thư viện OpenSSL. Hệ thống OpenCA
được cài đặt trên máy chủ Linux chạy hệ điều hành Fedora 6.

• Khái quát chung về OpenSSL

Dự án OpenSSL là một kết quả của sự cộng tác nhằm phát triển một kỹ thuật bảo
mật dạng thương mại, đầy đủ các đặc trưng và là bộ công cụ mã nguồn mở thực thi các
giao thức như Secure Sockets Layer (SSL v2/v3) và Transport Layer Security (TSL v1)
với những thuật toán mã hóa phức tạp. Dự án được quản lý bởi hiệp hội những người tình
nguyện trên thế giới, sử dụng Internet để trao đổi thông tin, lập kế hoạch và phát triển
công cụ OpenSSL và các tài liệu liên quan khác.[13]

SSL là giao thức đa mục đích được thiết kế để tạo ra các giao tiếp giữa hai chương
trình ứng dụng trên một cổng định trước (socket 443) nhằm mã hoá toàn bộ thông tin
đi/đến, mà ngày nay được sử dụng rộng rãi cho giao dịch điện tử như truyền số hiệu thẻ
tín dụng, mật khẩu, số bí mật cá nhân (PIN) trên Internet. [13]

Ngày nay giao thức Secure Socket Layer (SSL) đã được sử dụng rộng rãi trên
World Wide Web trong việc xác thực và mã hoá thông tin giữa client và server. Tổ chức
IETF (Internet Engineering Task Force ) đã chuẩn hoá SSL và đặt lại tên là TLS
(Transport Layer Security). Mặc dù là có sự thay đổi về tên nhưng TSL chỉ là một phiên
bản mới của SSL. Phiên bản TSL 1.0 tương đương với phiên bản SSL 3.1. Tuy nhiên
SSL là thuật ngữ được sử dụng rộng rãi hơn.

Tính mở của thư viện OpenSSL cho phép can thiệp tới quá trình tạo và quản lý
chứng thư số, phù hợp với yêu cầu của đề tài. Do vậy đề tài lựa chọn xây dựng một hệ
thống PKI trên nền tảng thư viện OpenSSL.

OpenSSL là thư viện cho lập trình với ngôn ngữ C và có thể cài đặt trên nhiều môi
trường thực hiện C khác nhau như Microsoft Visual C++. Borland C++ Builder…
OpenSSL có thể được sử dụng trên nhiều hệ điều hành khác nhau từ các hệ thống
UNIX đến Window.

66
• Cài đặt thư viện OpenSSL

Để cài đặt thư viện OpenSSL trên hệ điều hành Window trước hết cần download
phiên bản của thư viện này dành cho Window tại địa chỉ:
http://www.slproweb.com/products/Win32OpenSSL.html
Sau đó, chạy file install để cài đặt (giả sử vào thư mục C:\Openssl). Để sử dụng
thư viện này với Microsoft Visual C++ cần làm các bước sau:
Copy tất cả các file trong thư mục 'C:\OpenSSL\lib\VC' vào thư mục Visual C++
'lib'. Thư mục này đôi khi được đăt ở địa chỉ 'C:\Program Files\Microsoft Visual Studio
8\VC\lib' or 'C:\Program Files\Microsoft Visual C++\lib'.
Tiếp theo, copy tất cả trong thư mục 'C:\OpenSSL\include' tới thư mục Visual C+
+ 'include'.

Quá trình cài đặt hoàn tất và có thể bắt đầu lập trình với thư viện OPENSSL.

Thành phần của bộ thư viện OpenSSL bao gồm[13]:


 Thư viện về mã hóa: hầu hết các thuật toán phổ biến về mã hóa đối xứng, mã hóa
công khai, hàm băm .. đều được hiện thực trên thư viện này. Thư viện có chức
năng sinh số ngẫu nhiên lớn, và hỗ trợ nhiều định dang lưu trữ và quản lý khóa,
chứng thư số. Ngoài ra, OpenSSL cho phép tích hợp với các bộ phần cứng tăng tốc
mã hóa phổ biến trong phiên bản mới nhất là 0.9.8.
 Thư viện về giao thức SSL: tất cả các phiên bản của giao thức SSL đều được hỗ
trợ, bao gồm cả giao thức mới nhất là TLS v1.

• Lập trình sử dụng OpenSSL

Để sử dụng thư viện OpenSSL, cần cho các file khai báo đặc tả (file .h) sau vào
file mã nguồn:
#include <openssl/bio.h>
#include <openssl/err.h>
#include <openssl/rand.h>
#include <openssl/ssl.h>
#include <openssl/x509.h>
#include <openssl/x509v3.h>

Ngoài ra cần thêm file applink.c là file liên kết module khi biên dịch chương trình.
File này chỉ sử dụng cho các phiên bản thư viện 0.9.8 trở về sau. Khi liên kết (link), cần
đặt thông số cho thư viện cần thêm là libeay32.lib và ssleay32.lib.
67
Khởi tạo thư viện

Thư viện cần được khởi tạo trước khi sử dụng, bao gồm:
• Khởi tạo thông số cho sử dụng các hàm mã hóa và băm
OpenSSL_add_all_algorithms();
OpenSSL_add_all_digests();

• Khởi tạo quản lý bộ nhớ, nạp các hàm quản lý lỗi.


CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
CRYPTO_malloc_init();
ERR_load_crypto_strings();
• Khởi tạo sử dụng thư viện SSL
SSL_library_init();
SSL_load_error_strings();

Sử dụng

Tập các hàm API của OpenSSL chia ra theo nhóm chức năng, mỗi nhóm chức năng bắt
đầu tên hàm bằng một tiền tố. Ví dụ, các hàm về thư viện X.509 luôn có tên bắt đầu là
X509_, các hàm giao tiếp vào ra có tiền tố của tên BIO_, các hàm mã hóa là EVP_, các
hàm giao thức SSL là SSL_.

 Sử dụng các hàm mã hóa


Quá trình thực hiện mã hóa như sau

- Tạo context chứa thông tin về mã hóa: lưu trong con trỏ kiểu
EVP_CIPHER_CTX:
EVP_CIPHER_CTX *x = NULL;
x = (EVP_CIPHER_CTX*) malloc(sizeof(EVP_CIPHER_CTX));
EVP_CIPHER_CTX_init(x);

- Chỉ định thuật toán, khóa mã cho quá trình mã hóa/giải mã: dùng một trong
các hàm sau:
int EVP_EncryptInit(EVP_CIPHER_CTX *ctx,const EVP_CIPHER *type,
unsigned char *key, unsigned char *iv);
int EVP_DecryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER
*type, unsigned char *key, unsigned char *iv);

68
- Thêm dữ liệu cần mã hóa:
int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
int*outl, unsigned char *in, int inl);
- Lấy ra dữ liệu đã mã hóa:
int EVP_EncryptFinal(EVP_CIPHER_CTX *ctx, unsigned char *out,
int*outl);
• Sử dụng giao thức SSL
- Tạo context cấu hình kết nối SSL: dùng các hàm SSL_CTX_
- Tạo một kết nối vào ra thông thường: theo giao thức TCP/IP bằng các hàm
BIO_: BIO_new_connect, BIO_do_connect…
- Tạo một socket SSL: dựa trên kết nối BIO và context cấu hình SSL: SSL_new,
- SSL_set_bio, SSL_connect…
- Đọc ghi dữ liệu qua socket SSL: bằng các hàm SSL_read, SSL_write.
- Đóng kết nối SSL và giải phóng context: SSL_close, SSL_CTX_free.
• Sử dụng thư viện X.509
Yêu cầu chứng thư số thể hiện bằng đối tượng X509_REQ. Trong đối tượng này
bao gồm tên định danh của người đăng ký, được thể hiện bằng X509_NAME.
Thành phần mở rộng của yêu cầu chứng thư là X509_EXTENSION.
Các hàm của X.509 chia theo chức năng:
- X509_NAME_*: thao tác với đối tượng X509_NAME
- X509_PKEY* và X509_PUBKEY*: thao tác với khóa công khai/cá nhân.
- X509_REQ*: thao tác với yêu cầu chứng thư số.
- X509_CRL*: thao tác với danh sách CRL.
- X509_REVOKED*: thao tác với một chứng thư số bị hủy nằm trong danh sách
CRL.
Ngoài ra còn một số hàm khác.
Các bước tạo yêu cầu chứng thư như sau:
- Tạo đối tượng tên định danh X509_NAME
- Tạo cặp khóa công khai/cá nhân, cho khóa công khai vào yêu cầu chứng
thư số.
- Thêm các thành phần mở rộng nếu cần.
-Thực hiện ký chứng thực nội dung yêu cầu chứng thư.
CA phát hành chứng thư số từ yêu cầu chứng thư:
- Lấy thông tin X509_NAME trong yêu cầu chứng thư và gán cho trường
Subject của chứng thư số.
69
- Lấy thông tin X509_NAME trong chứng thư số gốc của CA và gán cho
trường Issuer của chứng thư số.
- Dùng khóa công khai trong yêu cầu chứng thư số và kiểm tra chữ ký. Lấy
khóa công khai cho vào chứng thư số.
- Thêm các thành phần mở rộng nếu cần
- Thực hiện ký chứng thư bằng khóa cá nhân của CA.

Thư viện OpenSSL đang trong quá trình phát triển, tài liệu thư viện được liệt kê tại
http://www.openssl.org/docs/.

3.3 Phương án thiết kế xây dựng hệ thống BK-BioPKI-OpenCA[15]

3.3.1 Mô hình hệ thống dự kiến

70
Database

CA Operator OpenCA

CA

Offline

Database

Trung tâm dịch Trung tâm dịch


vụ thẻ vụ chứng chỉ
RA

Offline Offline

Database Database

LRA LRA User Application User Application User Application


Offline
Offline

Người sử dụng Người sử dụng


Người sử dụng
Người đăng kí Chứng chỉ Chứng chỉ
Người đăng kí Chứng chỉ
Chứng chỉ
Chứng chỉ

Hình 3.4: Mô hình hệ thống BioPKI-OpenCA mức khung cảnh

3.3.2 Các thành phần và chức năng của hệ thống

a. CA

CA là nơi phát hành chứng thư (còn gọi là chứng thư số theo thuật ngữ bản pháp lý)
71
CA gồm hai bộ phận: CA Operator (máy người điều hành CA) và OpenCA.
CA Operator:
- Là một máy Window kết nối với máy chủ Linux-OpenCA,
- CA Operator là công cụ quản trị của người điều hành CA.
- Cung cấp ứng dụng cho phép người điều hành CA nhập thông tin yêu cầu vào
cơ sở dữ liệu của OpenCA.
- Cung cấp ứng dụng để sản xuất ra thiết bị nhúng giao tiếp với PC qua cổng
USB (gọi là Etoken). Thiết bị nhúng Etoken sẽ chứa chứng thư, khóa riêng,
đặc trưng vân tay của người đăng ký.
(thiết bị nhúng này có vai trò như thẻ giao dịch điên tử(
OpenCA;
- Là một máy chủ Linux,
- Quản lý yêu cầu, quản lý và phát hành chứng thư.
- Cung cấp một giao diện web cho phép người điều hành CA quản trị được các
yêu cầu từ đó phát hành chứng thư.

b RA

RA bao gồm 2 bộ phận: bộ phận phát hành chứng thư và bộ phận cung cấp các dịch vụ
cho phép người dùng sử dụng chứng thư đối với các ứng dụng cụ thể.
Bộ phận dịch vụ phát hành chứng thư : Cung cấp các dịch vụ về chứng thư
- Phát hành thiết bị nhúng Etoken chứa chứng thư (Phát hành chứng thư )
- xử lý mất thiết bị nhúng Etoken (hủy chứng thư theo yêu cầu)
- xử lý cấp thiết bị nhúng Etoken (cấp mới chứng thư).

Bộ phận dịch vụ chứng thư cung cấp các dịch vụ để sử dụng chứng thư tương ứng với
từng ứng dụng cụ thể như chữ ký số, mã hóa thông điệp… Ví dụ:
- Dịch vụ xác thực chứng thư: kiểm tra thông tin, tính hợp lệ của chứng thư.
- Dịch vụ cung cấp chứng thư theo serial number…

c. LRA

LRA là nơi giao tiếp trực tiếp với người dùng các vấn đề về cấp thiết bị nhúng Etoken
- Phát hành thiết bị nhúng Etoken (chứng thư) mới: nơi tiếp nhận yêu cầu, mẫu
sinh trắc, đồng thời là nơi trả thẻ cho khách hàng.
- Xử lý mất thiết bị nhúng Etoken (chứng thư): nơi khách hàng đến để yêu cầu
hủy chứng thư trong trường hợp mất thẻ.
- Cấp mới thiết bị nhúng Etoken (chứng thư).

c. User Application

72
User Application là một ứng dụng cho phép người dùng truy cập đến trung tâm dịch vụ
chứng thư của RA để sử dụng chứng thư của mình vào một số ứng dụng như chữ ký sô,
mã hóa thông điệp…

3.3.3 Biểu đồ phân cấp chức năng

Dựa vào các phân tích về yêu cầu và quy trình ở trên, ta có các biểu đồ phân rã
chức năng cho từng khối thành phần hệ thống như sau:

73
a. Biểu đồ phân cấp chức năng của CA Operator
CA-Operator sẽ có các chức năng chính như biểu đồ dưới đây:

CA Operator

Giao dịch với RA Giao dịch với CA Ghi Token

Cấp chứng thư số Cấp chứng thư số


Nhận đặc trưng
mới mới sinh trắc

Nhận request Submit


request
Mã hóa khóa và
ghi ra token
Trả thẻ, Lấy chứng
chứng chỉ thư từ CSDL

Hủy chứng thư số Hủy chứng thư số

Nhận yêu Cập nhật vào


cầu CSDL

Trả lời

Cấp lại chứng thư Cấp lại chứng thư


số số

Hủy chứng Hủy chứng thư


số cũ trong
thưHình
số cũ 1.5: Biểu đồ phân cấp chức năng của CA Operator
CSDL

• Giao dịchCấp
vớilạiRA:
chứng Cấp lại chứng
thư số mới thư số mới
 Cấp chứng thư số mới: Nhận request từ RA, cấp chứng thư, ghi chứng thư và thẻ
rồi trả lại cho RA

74
 Hủy chứng thư số: Nhận yêu cầu từ RA, đánh dấu hủy và cập nhật vào CSDL, trả
lời lại cho RA

 Cấp lại chứng thư số: Hủy chứng thư số cũ, cấp lại chứng thư mới

• Giao tiếp với CA:


 Cấp mới chứng thư số: submit request lên CA, thông qua giao diện web của
OpenCA issue chứng thư, lấy chứng thư từ CSDL của CA, ghi ra file và trả lại cho
RA
 Hủy chứng thư số: Cập nhật vào CSDL hủy bỏ chứng thư số nào đó
 Cấp lại chứng thư số: trước tiên là hủy chứng thư cũ, rồi cấp lại một chứng thư
mới
• Ghi Token:
 Nhận đặc trưng sinh trắc của người dùng do RA gửi lên, mã hóa với khóa cá nhân
rồi ghi ra thiết bị nhúng (Token), trả token cùng với chứng thư cho RA

75
b. Biểu đồ phân rã chức năng của RA

RA sẽ có các chức năng chính như biểu đồ dưới đây:

Hình 2.6: Biểu đồ phân cấp chức năng của RA

• Giao tiếp với LRA:

 Cấp chứng thư số mới: Nhận thông tin đăng kí xin cấp chứng thư số mới do LRA
gửi lên, trả thẻ lại cho LRA để phát cho người dùng

 Hủy chứng thư số: Nhận yêu cầu hủy chứng thư số của một user từ LRA, kiểm tra
thông tin user, chứng thư, token có đúng hay không, đánh dấu hủy chứng thư trong
CSDL, trả lời lại cho LRA để thông báo kết quả đến người dùng

 Cấp lại chứng thư số: hủy chứng thư số cũ, cấp lại chứng thư mới

• Giao tiếp với CA Operator:


76
 Cấp chứng thư số mới: gửi thông tin xin cấp chứng thư lên cho CA Operator, nhận
thẻ và chứng thư để trả lại cho LRA

 Hủy chứng thư số: tạo yêu cầu hủy chứng thư số, gửi lên cho CA Operator và
nhận lại kết quả hủy từ CA Operator

 Cấp lại chứng thư số: bao gồm 2 thao tác hủy chứng thư cũ, cấp lại chứng thư mới

• Setup:

 Kết nối với LRA: kết nối, send test message để chứng tỏ thông với LRA

 Kết nối với CA Operator: offline, cần kí lên các thông tin gửi cho CA Operator và
xác thực các thông tin nhận được từ CA Operator

 Kết nối với ứng dụng: Mở cổng cho các ứng dụng truy cập và sử dụng các dịch vụ
chứng thư số

• Cung cấp dịch vụ sử dụng chứng thư số:

 Xác thực chứng thư số: Kiểm tra xem chứng thư đó có đúng của hệ thống và còn
hiệu lực hay không

 Download chứng thư số: cho phép các ứng dụng download các chứng thư số của
người dùng để thực hiện giao dịch điện tử

c. Biểu đồ phân cấp chức năng của LRA


LRA sẽ có các chức năng chính như biểu đồ dưới đây:

Hình 3.7: Biểu đồ phân cấp chức năng của LRA

• Giao tiếp với người dùng:


77
 Cấp chứng thư mới: nhận thông tin đăng kí (bao gồm cả thông tin user nếu chưa là
user của hệ thống), trả thẻ lại cho ngươid dùng nếu yêu cầu được chấp nhận và cấp
chứng thư

 Hủy chứng thư số: Nhận yêu cầu hủy từ User, thông báo lại kết quả việc hủy

 Cấp lại chứng thư số: gồm 2 thao tác: hủy chứng thư cũ và cấp lại chứng thư mới

• Giao tiếp với RA:

 Cấp mới chứng thư: Gửi yêu cầu xin cấp mới chứng thư từ người dùng lên cho
RA, nhận thẻ được trả về và phát lại cho user

 Hủy chứng thư số: Gửi yêu cầu hủy chứng thư số của user và nhanh kết quả việc
hủy, thông báo lại cho user

 Cấp mới chứng thư

• Setup hệ thống: Xác thực chứng thư, kết nối đến RA để tiến hành các giao dịch

3.3.4 Xây dựng phương án về quy trình hệ thống BK-BioPKI-OpenCA

a. Cấp phát chứng thư

(1). Người dùng muốn có 1 chứng thư để sử dụng đến chi nhánh đăng ký chứng
thư (LRA), điền thông tin vào mẫu đơn đăng ký xin cấp chứng thư (xem mẫu) nộp
cho nhân viên chi nhánh. Các thông tin bao gồm:

- Họ và tên
- Giới tính
- Ngày sinh
- Nơi sinh
- Quốc tịch
- Số CMND/Hộ chiếu
- Ngày cấp
78
- Nơi cấp
- Địa chỉ thường trú
- Nơi công tác
- Điện thoại
- Fax
- Điện thoại di động (*)
- Email (*)
- Chức vụ
- Thời hạn đề nghị cấp (tối đa là 05 năm tính từ ngày cấp chứng thư số)

(2). Nhân viên chi nhánh tiếp nhận đơn đăng ký, kiểm tra thông tin người dùng
cung cấp. Nếu các thông tin chính xác, yêu cầu người dùng nhập mẫu sinh trắc
đúng chuẩn. Mẫu sinh trắc được chuyển thành đặc trưng sinh trắc. Đặc trưng này
được mã hóa với chứng thư chuyên dùng cho user của CA.

(3). Lưu vào cơ sở dữ liệu quản lý thông tin sau:

- Thông tin người dùng (cả đặc trưng sinh trắc đã mã hóa).

- Ngày nhận đăng ký, ngày trả kết quả.

- Sinh mã đăng ký: 3 ký tự đầu mã LRA, 6 ký tự sau phiên đăng ký (tự


động tăng)

- Lưu trạng thái yêu cầu: đã đăng ký.

(4). Đưa giấy hẹn trả lời cho người dùng (có mã đăng ký).

(5). LRA ký và gửi thông tin đăng ký xin cấp chứng thư cho RA:

- Thông tin đăng ký.

- Mã đăng ký.

(6). RA nhận yêu cầu từ LRA, lọc lấy mã LRA, căn cứ vào mã LRA để kiểm tra
chữ ký LRA, nếu kiểm tra thấy không đúng thông báo cho LRA , còn nếu đúng
lưu vào cơ sơ dữ liệu:

- Mã đăng ký.
79
- Thông tin đăng ký

- Trạng thái yêu cầu: đang xét duyệt tại RA.

LRA nhận được trả lời từ RA thì cập nhật lại trạng thái yêu cầu (nếu cần) và hủy
các thông tin sinh trắc của đăng ký tương ứng

+ Nếu trả lời chữ ký hợp lệ Đang chờ duyệt

(7). RA duyệt yêu cầu, nếu không cấp nhận yêu cầu gửi thông báo không chấp
nhận cho LRA, hủy đăng ký trong CSDL. Duyệt yêu cầu gồm:

- Đã có chứng thư hay chưa…

Nếu LRA nhận được thông báo không chấp nhận từ RA thì cập nhật trạng thái yêu
cầu là Không hợp lệ

(8). Nếu RA chấp nhận yêu cầu thì ký lên yêu cầu và gửi lên CA (kèm mã đăng
ký), chuyển trạng thái yêu cầu thành đã gửi CA (offline).

(9). CA operator kiểm chữ ký của RA trên dữ liệu đăng ký (sử dụng ứng dụng trên
nền Windows). Nếu sai thì thông báo (offline), nếu đúng sử dụng application
insert vào CSDL của CA.

(10). CA phát hành chứng thư,

- Ghi khóa riêng, chứng thư, đặc trưng sinh trắc vào thiết bị nhúng.

- Chuyển thiết bị nhúng, chứng thư, và mã yêu cầu cho RA

(11). RA nhận dữ liệu từ CA:

- Insert chứng thư vào CSDL chứng thư của RA.

- Căn cứ vào mã yêu cầu, update trạng thái yêu cầu: đã được cấp, điền mã
thẻ vào yêu cầu tương ưng

- Insert thông tin thiết bị nhúng vào CSDL: mã thiết bị, ID người dùng,
serial number của chứng thư, trạng thái của thiết bị (delivered to LRA –
false, delivered to User – false), mã yêu cầu tương ứng với thiết bị.

80
(13). RA trả thiết bị nhúng cho LRA, mã yêu cầu, cập nhật lại trạng thái của thiết
bị nhúng (Delivered to LRA – true.)

(14). LRA nhận thiết bị nhúng từ RA kèm mã yêu cầu. Dựa vào mã yêu cầu, cập
nhật trạng thái yêu cầu là đã có thẻ và điền mã thẻ vào yêu cầu tương ứng

(15). Người đăng ký cầm giấy hẹn đến LRA để lấy chứng thư. LRA căn cứ vào mã
đăng ký để lấy thiết bị nhúng trả cho người đăng ký và cập nhật trạng thái yêu cầu
là đã trả thẻ. Đồng thời LRA thông báo cho RA người dùng đã nhận thẻ (kèm mã
thẻ).

(16). RA nhận được thông báo người đăng ký đã nhận thẻ. Dựa trên mã thẻ cập
nhật lại trạng thái thẻ (Delivered to User – true.)

b. Xử lý mất thiết bị nhúng Etoken (hủy chứng thư tức thời)

(1). Người dùng đến LRA báo mất thẻ và yêu cầu hủy chứng thư.

(2). LRA kiểm tra thông tin người dùng để xác minh nhân thân.

(3). LRA gửi yêu cầu hủy chứng thư (chứa ID người dùng) cho RA (offline) và lưu yêu
cầu vào cơ sở dữ liệu, trạng thái yêu cầu là đã gửi RA.

(4). RA nhận yêu cầu từ LRA, lưu yêu cầu vào CSDL, căn cứ vào ID người dùng tìm các
thẻ tương ứng và báo lại cho LRA (nếu cần).

(5). Sau khi xác định chính xác mã thẻ cần hủy, dựa trên mã thẻ

- Tìm serial number của chứng thư chứa trong thẻ.

- Update trạng thái chứng thư: thu hồi.

- Update trạng thái thẻ: đã hủy.

- Thông báo lại cho LRA.

(6). LRA nhận thông tin từ RA báo cho người dùng, update lại trạng thái yêu cầu đã xử
lý.

(7). Cuối ngày, RA tìm trong CSDL các yêu cầu hủy (chứa serial number của chứng thư)
gửi cho CA.

(8). CA nhận được thông tin từ RA, căn cứ vào các serial number để cập nhật lại trạng
thái chứng thư.
81
c. Sử dụng chứng thư (ứng dụng chữ ký số)

(1). Quy trình ký

- Đưa thiết bị nhúng vào ứng dụng (đã chứa đặc trưng sinh trắc)

- User cung cấp số PIN để xác thực (1 lần)

- Mỗi lần sử dụng, ứng dụng yêu cầu người dung cung cấp dấu hiệu sinh trắc

- Thẩm định sinh trắc được thực hiện trên máy local : đọc dấu hiệu sinh trắc từ thiết bị
nhúng, thẩm định dấu hiệu sinh trắc nhận được với dấu hiệu trong thiết bị nhúng

- Nếu kết quả thẩm định tốt hiện giao diện cho phép sử dụng chứng thư (ký số)

- Module ký số thực hiện

(2). Quy trình xác thực chữ ký số:

- Nhận dữ liệu đã được ký, SN của chứng thư

- Tách chữ ký, SN của chứng thư

- Gửi SN cho RA để lấy chứng thư của bên gửi

- Xác thực chữ ký

CHƯƠNG 4
PHÂN TÍCH THIẾT KẾ CÀI ĐẶT THÀNH PHẦN SETUP
HỆ THỐNG BK-BIOPKI-OPENCA

4.1 Giới thiệu

Hệ thống BK-BioPKI dựa trên OpenCA được thực hiện bởi nhóm sinh viên khoá
49, khoa công nghệ thông tin trường đại học Bách Khoa Hà Nội. Với sự phân công cụ thể
như sau:
• Trần Anh Mỹ lớp TTM K49: Xây dựng thành phần CA Operator
• Nguyễn Thuý Hằng lớp TTM K49 : Xây dựng các thành phần RA
• Trần Hoàn Vũ lớp HTTT&TT KSCLC K49: Xây dựng module Setup hệ thống
• Nguyễn Đức Toàn lớpTTM K49: Xây dựng module giao tiếp giữa LRA và RA
82
• Nguyễn Văn Toàn lớp TTM K49: Xây dựng các thành phần của LRA và tích hợp
sinh trắc vào hệ thống.
• Bùi Đức Khánh lớp TTM K49: Xây dựng các ứng dụng PKI như chữ ký số, mã
hoá thông điệp.
• Đào Vũ Hiệp lớp TTM K49 và Nguyễn Tư Hoàn KSTN K49: Module sinh trắc
học.

Quyển đồ án này tập trung vào việc phân tích thiết kế cài đặt module setup hệ
thống BioPKI OpenCA.

4.2 Phân tích yêu cầu

Nhiệm vụ của đồ án là xây dựng module setup các thành phần của hệ thống cần
phải hoàn thành những việc sau:

• Thiết lập RA
• Thiết lập LRA
• Thiết lập CA Operator

Setup cho mỗi thành phần cần đảm bảo được những yêu cầu:
• Thiết lập cơ sở dữ liệu
• Thiết lập các thông tin xác thực
• Thiết lập cấu hình của hệ thống
• Thiết lập để tạo kênh SSL( Nếu có giao tiếp Online với thành phần khác)

4.3 Các chức năng cơ bản của Module Setup hệ thống

83
Hình 4.1: Các chức năng của Module Setup Hệ Thống

• Setup CA Operator : Nhiệm vụ của Setup Operator là thiết lập các thông tin để
kết nối với cơ sở dữ liệu của máy chủ OpenCA, thông tin về mật khẩu đăng nhập
của CA Operator. Xác thực và thiết lập các thông tin chứng thư số của CA và các
RA để phục vụ cho các quá trình cấp phát, thu hồi chứng thư sau này. Các chứng

84
thư số được lưu trong cơ sở dữ liệu, các thông tin về cấu hình và đường dẫn hệ
thống được lưu trong file XML.
• Setup RA: Setup RA thực hiện thiết lập các thông tin để kết nối với cơ sở dữ liệu
RA, Các thông tin dùng cho việc đăng nhập của người quản trị RA. Thiết lập và
xác thực các thông tin về chứng thư số của CA, CA Operator, RA và các LRA để
phục vụ cho các quá trình giao dịch chứng thư số với CA Operator và các LRA,
thiết lập kênh giao tiếp SSL cho RA Server.
• Setup LRA: Setup LRA tương tự như của RA, nhằm thiết lập kết nối cơ sở dữ
liệu, nhập các chứng thư cần thiết để tạo kênh SSL cho LRA Client và xác thực
trong các giao dịch.

4.4 Xây dựng kịch bản


4.4.1 Setup CA Operator

CAOperator Setup OpenCA DB

: CA_Operator_Admin
1 : Select setup()

2 : Query information()

3 : Enter information()

4 : Verify certificates()

5 [failed] : Requery certificates()


6 : Re-enter certificates()

7 : Connect to DB()

8 : Connect OK()

9 : Save configs()

Hình 4.2: Biểu đồ diễn tiến quá trình Setup CA Operator


Kịch bản setup CAOperator
(1) CAOperatorAdmin chọn setup CAOperator

85
(2) CAOperatorAdmin được yêu cầu cung cấp các thông tin cấu hình cơ sở dữ
liệu của OpenCA, thông tin về chứng thư số của CAOperator, chứng thư số của
RA.
(3) CAOperatorAdmin nhập các thông tin cần thiết
(4) CAOperator tiến hành kiểm tra xác thực chứng thư và khóa cá nhân.
(5) Nếu có lỗi, CAOperator yêu cầu người dùng nhập lại thông tin
(6) Người dùng nhập lại các thông tin
(7) CAOperator tiến hành kiểm tra kết nối tới cơ sở dữ liệu của OpenCA
(8) Nếu kết nối thành công, thông báo thành công
(9) CAOperator lưu lại các thông tin về cấu hình.

4.4.2 Setup RA
Setup RA bao gồm 2 bước:

86
• Đăng ký 1 máy chủ RA với các thông tin đầu vào là: Thông tin kết nối đến
cơ sở dữ liệu, thông tin đăng nhập, thông tin của RA Server, cặp khoá và
chứng thư của RA Admin, chứng thư của CA và CA Operator.
• Đăng ký các máy LRA Client với đầu vào là chứng thư và mã LRA
Hình là biểu đồ diễn tiến quá trình đăng ký RA

Hình 4.3: Biểu đồ diễn tiến quá trình Setup RA


(1) RA Admin chọn Setup RA
(2) RASetup yêu cầu nhập thông tin cần thiết

87
(3) RA Admin nhập thông tin
(4) RA Setup xác thực thông tin: kiểm tra kết nối đến cơ sở dữ liệu, đọc khoá cá
nhân của RA Admin
(5) Nếu các thông tin chính xác, RASetup yêu cầu import chứng thư
(6) RA Admin import chứng thư của CA, CA Operator, RA
(7) RASetup xác thực các chứng thư đã nhập
(8) Nếu xác nhận chứng thư thành công, lưu chứng thư vào cơ sở dữ liệu, khởi tạo
SSL server
(9) RAServer start để lắng nghe các Client
(11) Server start thành công, RASetup lưu các thông tin cấu hình

Sau khi đăng ký RA thành công, RA Admin chọn chức năng Register LRA để
đăng ký các máy khách LRA sẽ giao dịch.

Hình là biểu đồ diễn tiến quá trình đăng ký một LRA Client

88
Hình 4.4: Biểu đồ diễn tiến quá trình đăng ký một LRA
(1) RA Admin chọn đăng ký 1 LRA client
(2) Register LRA yêu cầu nhập thông tin của LRA
(3) RA Admin nhập mã và chứng thư của LRA cần đăng ký
(4) Register LRA xác thực thông tin đăng ký
(5) Nếu quá trình xác thực thành công lưu chứng thư và mã LRA tương ứng vào
cơ sở dữ liệu

4.4.3 Setup LRA

89
LRA Setup RA

: LRA_Admin
1 : Select setup LRA()

2 : Query information()

3 : Enter information()

4 : Verify certificates()

5 [failed] : Requery certificates()


6 : Re-enter certificates()

7 : Connect to RA()

8 : Connect OK()

9 : Save configs()

Hình 4.5: Biểu đồ diễn tiến quá trình setup LRA

(1) LRA Admin chọn setup LRA


(2 ) LRA Admin được yêu cầu cung cấp các thông tin cấu hình bao gồm: thông tin
profile LRA, LRA code, thông tin CSDL, thông tin về RA chủ quản, các chứng
thư (CA, RA, LRA), khóa cá nhân của LRA, mật khẩu đăng nhập của LRA Admin
(có thể được thay thế bằng sinh trắc)
(3) LRA Admin nhập các thông tin cần thiết
(4) LRA Setup tiến hành kiểm tra, xác thực các chứng thư, khóa cá nhân
(5) Nếu có lỗi xác thực, LRA Setup yêu cầu người dùng nhập lại
(6) Người dùng nhập lại các thông tin chứng thư
(7) LRA Setup thiết lập kênh SSL tới RA
90
(8) RA trả lời kết nối đã được thiết lập
(9) LRA Setup lưu các thông số cấu hình, import các chứng thư vào CSDL

4.4.4 Kịch bản khởi động


Hình mô tả quá trình khởi động chung cho cả 3 thành phần CA Operator, RA và
LRA. Việc chạy chương trình chính bắt đầu bằng quá trình đăng nhập hệ thống, hiện nay
do chưa tích hợp sinh trắc nên việc đăng nhập mới chỉ dùng password, sau này khi đăng
nhập chương trình có thêm một bước là kiểm tra đặc trưng sinh trắc của người dùng.

91
Hình 4.6: Kịch bản khởi động cho các phân hệ trong hệ thống BioPKI

92
CHƯƠNG 5

THỬ NGHIỆM KỊCH BẢN ỨNG DỤNG TRONG HỆ THỐNG


BIOPKI-OPENCA

Sau khi từng thành phần của hệ thống được xây dựng, ghép nối và chạy thử, cần
thử nghiệm một kịch bản ứng dụng trong hệ thống BioPKI-OpenCA để kiểm tra, đánh
giá hệ thống, xem xét các khối chương trình đã chạy đúng như yêu cầu hay chưa. Ứng
dụng được thử nghiệm ở đây chính là kịch bản ứng dụng chữ kí số.
Ứng dụng chữ kí số là một thành phần trong nhóm xây dựng các ứng dụng của hệ
thống BioPKI-OpenCA. Hai chức năng chính hệ thống cung cấp liên quan tới ứng dụng
này là chức năng kí và chức năng kiểm tra chữ kí.
Trong phần dưới sẽ trình quá trình thử nghiệm kịch bản ứng dụng trong toàn bộ hệ
thống BioPKI-OpenCA Ver.1, trong đó sẽ thử nghiệm và đánh giá kết quả của phân hệ
phần mềm LRA của đồ án này trong hoạt động của hệ thống chung

Application

Digital Signature Sign


<<extend>>

<<extend>>
Verify Signature

User

Remote Authentication

Encrypt Message

Hình 5.1: Biểu đồ usecase nhóm các chức năng liên quan tới ứng dụng trên
nền PKI
Trong phạm vi đề tài này, ứng dụng chữ kí số sẽ được xây dựng nhằm xác thực nội dung
thông điệp và xác thực người dùng. Ứng dụng được xây dựng nằm thành phần user
applications của hệ thống BioPKI-OpenCA. Mục tiêu của việc xác thực trong ứng dụng
này là :
93
• Xác thực sự toàn vẹn thông điệp.
• Xác thực người kí thông điệp.
• Chống phủ nhận đối với người kí.

5.1 Thiết kế kịch bản thử nghiệm ứng dụng chữ kí số


Hai người dùng của hệ thống tham gia vào một giao dịch thông điệp có sử dụng
chữ kí số. Tạm gọi hai người đó là A và B. A gửi cho B thông điệp M ( là một file dữ
liệu), A đồng thời dùng một chứng thư số của mình để tạo chữ kí số. Chính xác là A dùng
khóa riêng PrA (ứng với chứng thư CertA của A đã được CA xác nhận) để kí lên M tạo
thành chữ kí SA. Cả M, số Serial của CertA và SA được gắn lại và gửi cho B.

Khi B nhận được file đã được kí và B muốn kiểm tra chữ kí có đúng không thì
trước tiên, hệ thống sẽ tách nội dung file và các thông tin liên quan tới chữ kí ra.

Tiếp theo B sẽ dùng dịch vụ do hệ thống cung cấp, connect đến bộ phận dịch vụ
chứng thư số của RA để lấy chứng thư CertA và kiểm tra xem có đúng là chứng thư hợp
lệ hay không. Sau đó nếu chứng thư hợp lệ thì B lấy khóa công khai Pb A của A từ chứng
thư. B dùng PbA để kiểm tra lại chữ kí và file M để xác thực xem có phải đúng là A đã kí
chữ kí này không.

Nếu chứng thư không hợp lệ hoặc nếu M không toàn vẹn hoặc không phải A kí
chứng thư thì kết quả việc kiểm tra sẽ biết được ngay. Trái lại chữ kí là hợp lệ và file M
không bị thay đổi trên đường truyền.

Về cơ bản hoạt động kí và kiểm tra chữ kí diễn ra như minh họa trong hình biểu diễn ở
chương 1.

Điểm cẩn lưu ý ở đây là: cả A, B là người dùng của hệ thống BioPKI-OpenCA và mỗi
bên đã được cấp một chứng thư số, tức mỗi bên đều đã có thẻ token. Bên A lúc kí muốn
lấy được khóa cá nhân phải dùng token để xác thực, bên B khi connect tới RA cũng cần
được xác thực và cần đến token.

94
Digital signature app

: User
1 : Request sign a file()

2 : Dialogselect file()

3 : Choose file()

4 : Private key file path()

5 : Choose file()

6 : Password()

7 : Enter password()

8 : Sign file()

9 : Signed file

10 : Send file()

11 : Connect to partner and send file()

Hình 5.2: Biểu đồ diễn tiến quá trình kí


Trong biểu đồ trên, khi cần lấy khóa cá nhân để kí, ứng dụng hỏi người dùng
đường dẫn đến file khóa và password (passpharse). Nếu dùng thẻ token đã tích hợp sinh
trắc để mã hóa khóa cá nhân thì hai lời gọi trên được thay thế bằng việc yêu cầu user đưa
thẻ vào và ứng dụng tiến hành đọc thẻ, giải mã để lấy khóa cá nhân.

95
Biểu đồ diễn tiến quá trình xác thực chữ kí:

Digital signatureapp RA

: User

1: Verify afile()

2: Select afile()

3: Choosefile()

4: Extract signatureinfo()
5: Privatekey filepath()

6: choosefile()

7: Requirepassword()

8: Enter password()

9: Connect()

10: ConnectOK

11: Get cert()

12: Partner cert

13: Get publickey()

14: Verify()

Hình
15: Se5.3: Biểu
ndverify đồ diễn tiến quá trình xác thực chữ kí
result()

Trong biểu đồ trên, ứng dụng cần khóa riêng của user để thiết lập kênh SSL đến
bộ phận cung cấp dịch vụ chứng thư số của RA, ứng dụng sẽ hỏi đường dẫn đến file
private key và password (passpharse). Nếu hệ thống sử dụng thẻ nhúng, thì việc này sẽ
được thay thế bằng các hành động: yêu cầu user đưa thẻ vào, đọc thẻ và giải mã để lấy
khóa cá nhân

96
LRA Digital signature app RA CA Operator CA

: User
1 : request new cert()

2 : New request file()

3 : send request()

4 : New request file()

5 : Send request()

6 : Submit()

7 : I ssue cert()

8 : New Cert()

9 : CreateToken()

10 : Export cert to file()

11 : Send new token()

13 : Send new token() 12 : Send new token()

14 : Sign a file()

15 : Get private key()

16 : I nput token()

17 : Decrypt, get priv key()

Hình 5.4: Quá trình kí có thử nghiệm hoạt động tất cả các thành phần của hệ
18 : Sign file()

thống BioPKI-OpenCA

97
LRA D ig ita l s ig n a tu re a p p RA C A O p e ra to r CA

: Us er
1 : re q u e s t n e w c e rt()

2 : N e w re q u e s t file ()

3 : s e n d re q u e s t()

4 : N e w re q u e s t file ()

5 : Se n d re q u e s t()

6 : Su b mit()

7 : Is s u e c e rt()

8 : N e w C e rt()

9 : C re a te T o ke n ()

10 : Exp o rt c e rt to file ()

11 : Se n d n e w to ke n ()

13 : S e n d n e w to ke n () 12 : S e n d n e w to ke n ()

14 : Ve rify a file ()
15 : Ge t p riv a te ke y ()

16 : In p u t to ke n ()

17 : D ec ry p t, g e t p riv ke y ()

18 : C o n n e ct ()

19 : C o n n e c tO K

20 : Ge t Ce rt()

21 : Pa rt n e rCe rt

22 : Ge tP u b lic K e y ()

23 : Ve rify ()
Hình 5.5: Quá trình xác thực có thử nghiệm hoạt động tất cả các thành phần
của hệ thống
24 : Se n d v e rify re s u lt()

5.2 Kết quả thử nghiệm


98
Các thành phần hệ thống đều chạy đúng chức năng thiết kế, ứng dụng chữ kí số
hoạt động tốt trên các nền tảng dịch vụ mà hệ thống cung cấp. Thành phần Setup hệ
thống hoạt động đúng với yêu cầu, khởi tạo được đầy đủ các thông số ban đầu để hệ
thống có thể hoạt động được.

Hình 5.6: Kết thúc quá trình kí

Hình 5.7: Kết thúc quá trình xác thực chữ kí

99
KẾT LUẬN

Đề tài “Xây dựng phân hệ Setup trong hệ thống an ninh dựa trên sinh trắc học
BioPKI-OpenCA” nằm trong khuôn khổ đề tài nghiên cứu khoa học công nghệ cấp nhà
nước KC01.11/06-10 “Hệ thống an ninh thông tin dựa trên sinh trắc học sử dụng công
nghệ nhúng BioPKI”. Trong thời gian nghiên cứu, tìm hiểu, xây dựng ứng dụng đố án đã
hoàn thành được các nhiệm vụ được đặt ra, cụ thể là:
• Về mặt lý thuyết: Đồ án đã trình bày được những khái niệm, đặc điểm cơ bản của một
hệ thống PKI, tổng quan về OpenCA, trình bày được khái niệm sinh trắc học
(biometric), các hướng tích hợp biometric vào một hệ PKI.
• Về mặt thiết kế: Đồ án đã đóng góp vào thiết kế tổng quan hệ thống BioPKI-OpenCA,
thiết kế thành phần setup hệ thống, thiết kế các quy trình trong hệ thống.
• Về mặt cài đặt thực tế và kết quả thử nghiệm: Đã hoàn thành việc cài đặt module
Setup, tích hợp module vào hệ thống BioPKI dựa trên OpenCA, tiến hành thử nghiệm
thành công ứng dụng chữ ký số trên phòng thí nghiệm liên mạng

Mặc dù đã hết sức cố gắng nhưng trình độ chuyên môn và thời gian thực hiện đồ
án còn hạn hẹp, cũng như mức độ phức tạp của đề tài, nên kết quả đạt được còn gặp phải
một số khiếm khuyết.

Hướng phát triển đề tài: Tiếp tục hoàn thiện các chức năng, nhằm tăng hiệu quả và
độ an toàn. Tích hợp module sinh trắc và quản lý thẻ eToken vào quá trình setup hệ
thống, hoàn thiện hơn về giao diện để tăng tính chuyên nghiệp nhằm đáp ứng khả năng
ứng dụng thực tế cho hệ thống Bio-PKI dựa trên OpenCA

100
TÀI LIỆU THAM KHẢO

[1] Phạm Huy Điển, Hà Huy Khoái (2003), Mã hoá thông tin cơ sở
toán học và
ứng dụng, Nhà xuất bản Đại học Quốc gia Hà nội.
[2] Phan Đình Diệu (1999), Lý thuyết mật mã và an toàn thông tin,
Đại học
Quốc Gia Hà Nội, Hà Nội.
[3] Trịnh Nhật Tiến (2004), Một số vấn đề về an toàn dữ liệu, Hà Nội.
[4] Adams, C. (1999), Understanding Public Key Infrastructures, New
Riders
Publishing, Indianapolis.
[5] Andrew Nash, William Duance, Celia Joseph, and Derek
Brink (2001), PKI
Implementing and managing E-Security, McGraw –Hill Co.
[6] Fegghi, J.(1999), Digital Certificates and Applied Internet Security,
Addison-Wesley Longman, Inc.
[7] ITU-T Recommendation X.509 (2000), “The Directory: Public key
and
Attribute Certificates Framework”.
[8] Rivest, R.L., A.Shamir, and L.M.Adleman (1978), “A method for
obtaining
digital signatures and public-key cryptosystems”, Communications of
the
ACM.
[9] Housley, R. (1999), Internet X.509 Public Key Infrastrure
Certificate and
CRL Profile, RFC 2459.
[10] Myers, M. (1999), X.509 Internet Public Key Infrastrure On-line
Certificate
Status Protocol, RFC 2560.
[11] Jain, A. K. (28-30 April 2004), "Biometric recognition: how do I know who you
are?", Signal Processing and Communications Applications Conference, 2004.
Proceedings of the IEEE 12th.
[12] Shapiro, Debra Lynn; Puri, Preeti. “Biometric Security For Advanced Traffic
Management System”. ITS America. Meeting (12th : 2002 : Long Beach, Calif.).
101
Securing our future : ITS America 12th Annual Meeting and Exposition 2002 :
conference proceedings.
[13] http://www.openssl.org.
[14] http://www.openca.org
[15] BioPKI-OpenCA- design 20-3-09
[16] Đồ án tốt nghiệp Bùi Thành Đạt
[17] Đồ án tốt nghiệp Nguyễn Văn Toàn

102

You might also like