Tài liệu HẠ TẦNG KHOÁ CÔNG KHAI - Đồ án tốt nghiệp docx

Mục lục HẠ TẦNG KHOÁ CÔNG KHAI
Dong Manh Quan Trang 1 23/08/2005
QMỤC LỤC
MỤC LỤC 1
CÁC THUẬT NGỮ 5
ĐẶT VẤN ĐỀ 7
1 TỔNG QUAN VỀ PKI 8
1.1. KHÁI QUÁT 8
1.2. CÁC DỊCH VỤ VÀ PHẠM VI ỨNG DỤNG CỦA PKI 8
1.2.1. Các yêu cầu cơ bản của an toàn an ninh thông tin 8
1.2.2. Khả năng đáp ứng của các dịch vụ sử dụng PKI 9
1.2.3. Các dịch vụ an toàn an ninh dựa trên hệ thống PKI 9
1.3. CÁC ĐỐI TƯỢNG CƠ BẢN CỦA HỆ THỐNG PKI 10
1.3.1. Chủ thể và các đối tượng sử dụng 10
1.3.2. Đối tượng quản lý thẻ xác nhận 11
1.3.3. Đối tượng quản lý đăng ký thẻ xác nhận 11
1.4. CÁC HOẠT ĐỘNG CƠ BẢN TRONG HỆ THỐNG PKI 12
1.4.1. Mô hình tổng quát của hệ thống PKI 12
1.4.2. Thiết lập các thẻ xác nhận 12
1.4.3. Khởi tạo các EE 12
1.4.4. Các hoạt động liên quan đến thẻ xác nhận 13
1.4.4.1. Đăng ký và xác nhận ban đầu 13
1.4.4.2. Cập nhật thông tin về cặp khoá 13
1.4.4.3. Cập nhật thông tin về thẻ xác nhận 13
1.4.4.4. Cập nhật thông tin về cặp khoá của CA 13
1.4.4.5. Yêu cầu xác nhận ngang hàng 14
1.4.4.6. Cập nhật thẻ xác nhận ngang hàng 14
1.4.5. Phát hành thẻ và danh sách thẻ bị huỷ bỏ 14
1.4.6. Các hoạt động phục hồi 14
1.4.7. Các hoạt động huỷ bỏ 15
1.5. CẤU TRÚC CỦA CÁC THÔNG ĐIỆP PKI 15

1.5.1. Giới thiệu về nguyên tắc giả mã 15
1.5.2. Cấu trúc tổng quát của thông điệp PKI 16
1.5.3. Trường PKIHeader 17
1.5.4. Trường PKIBody 18
1.5.4.1. Thông điệp yêu cầu khởi tạo 20
1.5.4.2. Thông điệp trả lời yêu cầu khởi tạo 20
1.5.4.3. Thông điệp yêu cầu đăng ký/yêu cầu thẻ xác nhận 20
1.5.4.4. Thông điệp trả lời yêu cầu đăng ký/yêu cầu thẻ xác nhận 20
1.5.4.5. Thông điệp yêu cầu cập nhật khoá 21
1.5.4.6. Thông điệp trả lời yêu cầu cập nhật khoá 21
1.5.4.7. Thông điệp yêu cầu khôi phục khoá 21
1.5.4.8. Thông điệp trả lời yêu cầu khôi phục khoá 21
1.5.4.9. Thông điệp yêu cầu huỷ bỏ 21
1.5.4.10. Thông điệp trả lời yêu cầu huỷ bỏ 21
1.5.4.11. Thông điệp yêu cầu thẻ xác nhận ngang hàng 22
1.5.4.12. Thông điệp trả lời yêu cầu xác nhận ngang hàng 22
1.5.4.13. Thông điệp công bố cập nhật khoá CA 22
1.5.4.14. Thông điệp công bố thẻ xác nhận 22
1.5.4.15. Thông điệp thông báo huỷ bỏ thẻ xác nhận 22
1.5.4.16. Thông điệp thông báo CRL 23
Mục lục HẠ TẦNG KHOÁ CÔNG KHAI
2
1.5.4.17. Thông điệp xác nhận 23
1.5.4.18. Thông điệp PKI đa mục đích 23
1.5.4.19. Thông điệp trả lời tổng quát 23
1.5.4.20. Thông điệp thông báo lỗi 23
2 NHỮNG VẤN ĐỀ CƠ BẢN TRONG XÂY DỰNG HỆ THỐNG PKI 24
2.1. CÁC MÔ HÌNH TRIỂN KHAI HỆ THỐNG PKI 24
2.1.1. Kiến trúc phân cấp 24
2.1.1.1. Những ưu điểm của kiến trúc PKI phân cấp 25

2.1.1.2. Những khuyết điểm của kiến trúc PKI phân cấp 25
2.1.2. Kiến trúc hệ thống PKI mạng lưới 26
2.1.2.1. Ưu điểm của kiến trúc PKI mạng lưới 26
2.1.2.2. Nhược điểm của mô hình PKI mạng lưới 27
2.1.3. Kiến trúc danh sách tin cậy 27
2.1.3.1. Ưu điểm của kiến trúc PKI danh sách tin cậy 27
2.1.3.2. Nhược điểm của kiến trúc PKI danh sách tin cậy 28
2.2. NHỮNG CHỨC NĂNG BẮT BUỘC TRONG QUẢN LÝ PKI 29
2.2.1. Khởi tạo CA gốc 29
2.2.2. Cập nhật khoá của CA gốc 29
2.2.3. Khởi tạo các CA thứ cấp 29
2.2.4. Tạo lập CRL 29
2.2.5. Yêu cầu về thông tin hệ thống PKI 30
2.2.6. Xác nhận ngang hàng 30
2.2.7. Khởi tạo các EE 30
2.2.7.1. Thu thập thông tin về hệ thống PKI 30
2.2.7.2. Kiểm tra khoá công khai của CA gốc 30
2.2.8. Yêu cầu xác nhận 30
2.2.9. Cập nhật khoá 30
3 THẺ XÁC NHẬN THEO CHUẨN X.509 32
3.1. CÁC TRƯỜNG CƠ BẢN CỦA THẺ XÁC NHẬN 32
3.1.1. Trường tbsCertificate 32
3.1.2. Trường signatureAlgorithm 32
3.1.3. Trường signatureValue 33
3.2. CẤU TRÚC TBSCERTIFICATE 33
3.2.1. Trường version 33
3.2.2. Trường serialNumber 33
3.2.3. Trường signature 34
3.2.4. Trường issuer 34
3.2.5. Trường validity 35

3.2.6. Trường subject 35
3.2.7. Trường subjectPublicKeyInfo 35
3.2.8. Trường uniqueIdentifiers 35
3.2.9. Trường extensions 36
3.3. CÁC PHẦN MỞ RỘNG CỦA THẺ XÁC NHẬN X.509 36
3.3.1. Phần mở rộng Authority Key Identifier 36
3.3.2. Phần mở rộng Subject Key Identifier 36
3.3.3. Phần mở rộng Key Usage 37
3.3.4. Phần mở rộng Private Key Usage Period 37
3.3.5. Phần mở rộng Certificate Policies 38
3.3.6. Phần mở rộng Policy Mappings 38
3.3.7. Phần mở rộng Subject Alternative Name 39
3.3.8. Phần mở rộng Issuer Alternative Names 40
Mục lục HẠ TẦNG KHOÁ CÔNG KHAI
3
3.3.9. Phần mở rộng Subject Directory Attributes 40
3.3.10. Phần mở rộng Basic Constraints 40
3.3.11. Phần mở rộng Name Constraints 40
3.3.12. Phần mở rộng Policy Constraints 41
3.3.13. Phần mở rộng Extended key usage field 41
3.3.14. Phần mở rộng CRL Distribution Points 42
4 QUÁ TRÌNH XÂY DỰNG HỆ THỐNG 43
4.1. MÔI TRƯỜNG, CÔNG CỤ, MÔ HÌNH, CHỨC NĂNG, DỮ LIỆU 43
4.1.1. Lựa chọn môi trường và công cụ 43
4.1.1.1. Môi trường phát triển 43
4.1.1.2. Công cụ phát triển 43
4.1.2. Lựa chọn mô hình hệ thống PKI 44
4.1.3. Lựa chọn cấu trúc dữ liệu 45
4.1.4. Lựa chọn các chức năng được thực hiện 45
4.2. PHÂN TÍCH THIẾT KẾ CHỨC NĂNG CHI TIẾT 46

4.2.1. Mô hình thiết lập và quản lý kết nối 46
4.2.1.1. Phân tích yêu cầu 46
4.2.1.2. Phương thức thực hiện 47
4.2.2. Sử dụng các dịch vụ bảo mật 47
4.2.2.1. Giới thiệu về các công cụ an toàn an ninh của hệ điều hành 47
4.2.2.2. Những đánh giá và giải pháp 48
4.2.2.3. Kết luận 49
4.2.3. Tạo và phân tích các cấu trúc dữ liệu cơ bản 49
4.2.3.1. Các thẻ xác nhận 49
4.2.3.2. Các thông điệp PKI 50
4.2.4. Các công cụ quản trị hệ thống 50
4.2.4.1. Công cụ quản lý người sử dụng 50
4.2.4.2. Công cụ tạo và quản lý chính sách 51
4.2.4.3. Công cụ quản lý danh sách thẻ xác nhận 51
4.2.4.4. Công cụ quản lý các sự kiện đối với hệ thống 52
4.2.5. Lưu trữ dữ liệu 52
4.2.5.1. Lưu thông tin quản lý đối tượng sử dụng chương trình 52
4.2.5.2. Lưu thông tin chính sách về thẻ xác nhận 52
4.2.5.3. Lưu trữ thông tin về thẻ xác nhận 53
4.2.6. Chức năng mã hoá dữ liệu 53
4.2.6.1. Sự cần thiết của chức năng 53
4.2.6.2. Định hướng xây dựng 53
4.2.6.3. Lưu đồ thuật toán thực hiện 54
4.2.7. Phân tích thiết kế chi tiết các chức năng hệ thống PKI 54
4.2.7.1. Khởi tạo CA 54
4.2.7.2. Khởi tạo EE 56
4.2.7.3. Cập nhật khoá của CA 58
4.2.7.4. Yêu cầu và cấp phát thẻ xác nhận 60
4.2.7.5. Yêu cầu và cấp thẻ xác nhận ngang hàng giữa các CA 61
4.2.7.6. Yêu cầu và trả lời những thông tin về trạng thái của CA 64

4.3. LẬP TRÌNH THỰC THI HỆ THỐNG PKI 65
4.3.1. Cụ thể hoá những yêu cầu của quá trình phân tích thiết kế 65
4.3.1.1. Các yêu cầu đối với CA 66
4.3.1.2. Các yêu cầu đối với EE 66
4.3.2. Các lớp đối tượng cơ bản 67
4.3.2.1. Lớp CCertificationAuthority 67
4.3.2.2. Lớp CEndEntity 67
4.3.2.3. Lớp CPKIMessage 68
4.3.2.4. Lớp CCertificate 68
Mục lục HẠ TẦNG KHOÁ CÔNG KHAI
4
4.3.2.5. Lớp CSessionSocket 68
4.3.2.6. Lớp CListeningSocket 68
4.3.2.7. Lớp CCryptoTools 68
4.3.3. Các đối tượng lưu trữ dữ liệu và phương thức quản lý 69
4.3.3.1. Quản lý file lưu trữ account 69
4.3.3.2. Quản lý file lưu trữ chính sách hệ thống PKI 69
4.3.3.3. Quản lý file lưu trữ thẻ xác nhận 70
5 KIỂM THỬ VÀ ĐÁNH GIÁ KẾT QUẢ 71
5.1. ĐÁNH GIÁ VỀ NHỮNG KẾT QUẢ NGHIÊN CỨU LÝ THUYẾT 71
5.2. ĐÁNH GIÁ VỀ NHỮNG CHỨC NĂNG ĐÃ XÂY DỰNG 71
5.2.1. Các chức năng đối với thẻ xác nhận 72
5.2.1.1. Chức năng tạo thẻ xác nhận 72
5.2.1.2. Chức năng đóng gói và lưu trữ thẻ xác nhận 73
5.2.1.3. Chức năng quản lý danh sách thẻ xác nhận 74
5.2.2. Các chức năng quản lý hệ thống PKI 74
5.2.2.1. Yêu cầu và đáp ứng thẻ xác nhận 74
5.2.2.2. Chức năng yêu cầu và đáp ứng thông tin hệ thống PKI 75
5.2.2.3. Chức năng khởi tạo hệ thống 75
5.2.2.4. Chức năng yêu cầu và đáp ứng thẻ xác nhận ngang hàng 75

5.2.3. Các chức năng quản lý kết nối 76
5.2.4. Các công cụ quản lý hệ thống 76
5.2.4.1. Quản lý người sử dụng hệ thống 76
5.2.4.2. Công cụ thiết lập và quản lý chính sách thẻ xác nhận 77
5.2.4.3. Công cụ quản lý các sự kiện đối với hệ thống 77
5.2.4.4. Chức năng mã hoá dữ liệu 78
TÀI LIỆU THAM KHẢO 79
Các thuật ngữ HẠ TẦNG KHOÁ CÔNG KHAI
Dong Manh Quan Trang 5 23/08/2005
CÁC THUẬT NGỮ
An toàn an ninh thông tin
(Information Security)
Là các biện pháp tác động lện hệ thống thông tin và bản
thân thông tin để đảm bảo thông tin không bị thay đổi, phá
huỷ. Đồng thời, kiểm soát được các đối tượng truyền và
nhận thông tin.
Bí mật thông tin
(Confidentiality)
Thông tin không được tiết lộ cho các đối tượng không được
cho phép.
CA cấp dưới
(Subordinate CA)
Là những CA mà trong một mô hình PKI phân cấp, thẻ xác
nhận của nó được xác nhận bởi một CA khác. Những hoạt
động của CA này chịu sự giám sát của chính CA đó.
CA cấp trên
(Superior CA)
Là những CA chứng nhận những thẻ xác nhận và giám sát
hoạt động của các CA khác.
CA gốc

(Root CA)
Trong một sơ đồ PKI phân cấp, đây là CA với khoá công
khai được tin tưởng ở mức độ cao nhất bởi các đối tượng
của một domain.
Cặp khoá
(Key Pair)
Hai khoá có liên quan đến nhau về mặt toán học với hai
thuộc tính: (i) Một khoá có thể được dùng để mã hoá và việc
giải mã chỉ được thực hiện khi có khoá còn lại. (ii) Khi biết
một trong hai khoá thì việc tính toán để tìm ra khoá còn lại là
không thể thực hiện được.
Chính sách thẻ xác nhận
(Certìicate Policy)
Là một dạng chính sách quản trị các giao tác điện tử được
thực hiện trong quá trình quản lý thẻ xác nhận. Chính sách
này đáp ứng tất cả các yêu cầu của quá trình tạo, phân phát,
thống kê, phục hồi và quản trị các thẻ xác nhận số.
Chữ ký số
(Digital Signature)
Là kết quả của phép chuyển đổi một thông điệp bằng một hệ
thống các phép mã hoá có sử dụng các khoá mà một đối
tượng nhận được thông tin có thể xác định được: (i) Dữ liệu
được gửi đến có phải được tạo ra với khoá riêng ứng với
khoá công khai trong thẻ xác nhận của đối tượng gửi hay
không. (ii) Thông tin nhận được có bị thay đổi sau khi phép
chuyển đổi được thự
c hiện không. Thông tin bị coi là đã thay
đổi nếu ta không thể kiểm chứng được chữ ký số với khoá
công khai tương ứng của đối tượng đã tạo chữ ký số.
Danh sách tin cậy

(Trust List)
Tập hợp các thẻ xác nhận đã được một đối tượng sử dụng
tin cậy và dùng để xác thực những thẻ xác nhận khác.
Danh sách thẻ xác nhận bị huỷ bỏ
(Certificate Revocation List - CRL)
Một danh sách do CA quản lý bao gồm các thẻ xác nhận bị
huỷ bỏ trước khi chúng hết hạn.
Dữ liệu chưa mã hóa
(Plaintext)
Dữ liệu ở đầu vào của một thủ tục mã hoá bảo mật
Dữ liệu đã mã hóa
(Ciphertext)
Dữ liệu ở đầu ra của một thủ tục mã hoá bảo mật.
Định danh đối tượng
(Object Identifier – OID)
Là một só có định dạng riêng và đã được đăng ký với một tổ
chức được công nhận trên phạm vi quốc tế.
Đối tượng quản lý đăng ký
(Registration Authority - RA)
Là đối tượng có vai trò phân biệt và xác thực các đối tượng
của thẻ xác nhận nhưng không ký và cấp các thẻ xác nhận.
Đối tượng quản lý xác nhận
(Certification Authority – CA)
Là đối tượng được tin cậy bởi một nhóm người sử dụng nhất
định với chức năng phát hành và quản lý các thẻ xác nhận
và danh sách thẻ xác nhận bị huỷ bỏ.
Các thuật ngữ HẠ TẦNG KHOÁ CÔNG KHAI
6
Hạ tầng khoá công khai
(Public Key Infrastructure - PKI)

Một tập các chính sách, các tiến trình xử lý, các máy chủ
dịch vụ, các máy trạm cùng với các phần mềm được sử
dụng để quản lý các thẻ xác nhận cùng với các cặp khoá
công khai/khoá riêng. Trong đó, các tính năng chính bao
gồm việc phát hành, duy trì và huỷ bỏ các thẻ xác nhận chứa
khoá công khai.
Kênh truyền thông riêng
(Out-of-band)
Quá trình truyền thông giữa các đối tượng thông qua các
phương tiện khác với các phương tiện được sử dụng để duy
trì liên lạc thông thường giữa các đối tượng trong hệ thống.
Khoá công khai
(Public Key)
(i) Khoá thuộc về một cặp khoá tạo chữ ký số được sử dụng
để kiểm chứng một chữ ký số. (ii) Khoá thuộc về một cặp
khoá mã hóa được sử dụng để mã hóa thông tin bí mật.
Trong cả hai trường hợp, khoá này thường được phổ biến
với các thẻ xác nhận.
Khoá riêng
(Private Key)
(i) Khoá thuộc về một cặp khóa được sử dụng để tạo chữ ký
số. (ii) Khoá thuộc về một cặp khoá mã hóa được sử dụng
để giải mã các thông tin bí mật. Trong cả hai trường hợp,
khoá này phải được giữ bí mật.
Không thể bác bỏ
(Non-repudiation)
Tính năng này đề cập tới việc: nếu một đối tượng có thể
kiểm chứng một chữ ký số bằng một khoá công khai nào đó
thì điều đó chứng tỏ đối tượng đang nắm giữ khoá riêng
tương ứng đã tạo ra chữ ký số này.

Mã hoá bảo mật
(Encrypt)
Quá trình biến đổi thông tin ban đầu thành thông tin có dạng
trực quan là ngẫu nhiên và vô nghĩa.
Mã hoá dữ liệu
(Encode)
Quá trình đóng gói thông tin thành các khuôn dạng phù hợp
để truyền thông hoặc lưu trữ.
Mã xác thực thông điệp
(Message Authentication Code -
MAC)
Là chuỗi các bit được tạo ra thông qua các thuật toán tạo mã
xác thực thông điệp dựa trên các hàm phân tách. Mã này
được sử dụng để giúp đối tượng nhận có thể đảm bảo mình
nhận được đúng thông tin mình cần.
Phương tiện lưu trữ
(Repository)
Một hệ thống với phần cốt lõi là cơ sở dữ liệu chứa thông tin
về thẻ xác nhận và danh sách thẻ xác nhận bị huỷ bỏ.
Tấn công phát lại gói tin
(Replay Attack)
Là hình thức tấn công dựa trên việc bắt gói tin truyền đến,
thực hiện các chỉnh sửa theo ý muốn và phát đi trong các
thời điểm sau này tới các đối tượng nhận.
Tin cậy
(Trust)
Là việc chấp nhận một hành động hoặc một thể hiện của đối
tượng nào đó là đúng.
Toàn vẹn dữ liệu
(Data Integerity)

Là việc đảm bảo thông tin không bị thay đổi mà không bị
phát hiện trong quá trình truyền từ đối tượng tạo thông tin
đến đối tượng nhận.
Thẻ xác nhận
(Certificate)
Là hình thức biểu diễn thông tin dưới dạng số với các thông
tin tối thiểu sau: (i) CA phát hành thẻ này. (ii) Định danh của
đối tượng sử dụng. (iii) Khoá công khai của đối tượng sử
dụng. (iv) Thời gian hiệu lực của thẻ. Thẻ này phải được ký
bởi CA tạo ra nó.
Thẻ xác nhận ngang hàng
(Cross-Certificate)
Là thẻ xác nhận được dùng để thiết lập mối quan hệ tin cậy
giữa các CA.
Trao đổi khoá
(Key Exchange)
Là quá trình trao đổi các khoá để có thể thiết lập một kênh
liên lạc an toàn.
Xác thực
(Authenticate)
Khẳng định những thông tin về định danh của một đối tượng
khi đối tượng đó trình diện.
Đặt vấn đề HẠ TẦNG KHOÁ CÔNG KHAI
Dong Manh Quan Trang 7 23/08/2005
ĐẶT VẤN ĐỀ
Kể từ khi ra đời gần ba mươi năm trước đây, phương thức mã hoá bảo mật với khoá
công khai đã tạo nên một hướng phát triển mới cho các dịch vụ an toàn và an ninh thông
tin. Tư tưởng cốt lõi của phương thức mã hoá bảo mật với khoá công khai là việc sử
dụng cặp khoá công khai và khoá riêng. Mỗi đối tượng truyền thông đều có một cặp khoá
công khai và khoá riêng. Khoá công khai của một đối tượng được thông báo cho tất cả

các đối tượng tham gia truyền thông, còn khoá riêng chỉ do đối tượng đó nắm giữ.
Đối tượng truyền sẽ mã hoá thông tin cần truyền với khoá công khai của đối tượng nhận.
Sau đó, thông tin đã mã hoá sẽ được truyền đến cho đối tượng nhận. Sau khi nhận được
thông tin truyền đến, đối tượng nhận sẽ giải mã thông tin truyền đến với khoá riêng của
mình.
Khi các dịch vụ an toàn sử dụng khoá công khai được phát triển r
ộng rãi thì việc quản lý
đối tượng cùng với khoá công khai trở nên phức tạp và phải đối mặt với nhiều vấn đề về
an toàn và an ninh thông tin. Mặt khác, do phạm vi ứng dụng của các thông tin về khoá
công khai là rất rộng lớn (có thể là trong phạm vi quốc gia hoặc xuyên quốc gia) nên phải
có được sự thống nhất về các khoá công khai để đảm bảo các đối tượng có thể tham gia
truyền thông ở nhiều phạm vi khác nhau với nhiề
u dịch vụ an toàn và an ninh khác nhau.
Trong những năm gần đây, một hướng giải quyết đã được nghiên cứu và triển khai, đó là
Hạ Tầng Khoá Công Khai (Public Key Infrastructure - PKI). PKI là dịch vụ ở mức nền, nó
đảm bảo về việc tạo lập, quản lý và phân phát các khoá công khai của những đối tượng
tham gia vào các dịch vụ an toàn, an ninh (dựa trên phương thức mã hoá với khoá công
khai) thông qua các thẻ xác nhận. PKI có thể được triển khai trên nhiều phạm vi khác
nhau; do vậy, nó có th
ể giải quyết những khó khăn mà các ứng dụng an toàn an ninh gặp
phải khi phải triển khai trên phạm vi rộng và đối tượng sử dụng đa dạng.
Việc nghiên cứu và triển khai hệ thống PKI trong phạm vi một doanh nghiệp hay ở tầm cỡ
một quốc gia đều đòi hỏi phải có những nghiên cứu kỹ lưỡng và một tầm nhìn chiến lược.
Theo nhiều ý kiến nhận định, PKI có tiề
m năng phát triển và ứng dụng rất lớn. Nó sẽ
được ứng dụng rộng rãi trong các việc đảm bảo an toàn và an ninh cho các hệ thống
thông tin, trong thương mại điện tử, trong các kênh liên lạc an toàn. Nói chung, PKI là cần
thiết cho hầu hết các ứng dụng sử dụng phương thức mã hoá bảo mật với khoá công
khai.
Với mục tiêu tìm hiểu và nghiên cứu những đặc trưng và các hoạt động cơ bản của hệ

thống PKI, trong phạm vi đồ án này, ta sẽ tìm hiểu những khái niệm cơ bản, những cấu
trúc dữ liệu đặc trưng, những mô hình hoạt động và những chức năng cơ bản của hệ
thống. Trên cơ sở kết quả nghiên cứu, ta sẽ triển khai một hệ thống PKI đơn giản nhằm
minh hoạ quá trình hoạt động của hệ thống trong thực tế. Đây cũ
ng là cách để ta hiểu sâu
hơn về hệ thống PKI, về những yêu cầu của quá trình triển khai hệ thống và những lợi ích
mà hệ thống này có thể mang lại.

Dong Manh Quan Trang 8 23/08/2005
Phần 1
1 TỔNG QUAN VỀ PKI
Trong phần này, ta sẽ tìm hiểu những vấn đề cơ bản của hệ thống PKI. Những nội dung
được trình bày trong phần này sẽ cho ta một cái nhìn tổng quan về các mô hình hệ thống
PKI. Ta cũng hiểu rõ hơn về các đối tượng của hệ thống và các hoạt động cơ bản cần
thực hiện để quản lý hệ thống PKI. Song song với quá trình tìm hiểu các nội dung này, ta
sẽ có các định nghĩa, các khái niệm và thuậ
t ngữ được sử dụng đối với hệ thống PKI.
¾ Khái quát về hệ thống PKI.
¾ Các dịch vụ và phạm vi ứng dụng của PKI.
¾ Các đối tượng cơ bản của hệ thống PKI.
¾ Các hoạt động cơ bản của việc quản lý hệ thống PKI.
¾ Cấu trúc các thông điệp PKI.
1.1. KHÁI QUÁT
Thành phần cốt lõi của hệ thống PKI là các thẻ xác nhận. Mỗi thẻ xác nhận có hai thành
phần thông tin cơ bản là định danh và khoá công khai của đối tượng sử dụng. Các thẻ
xác nhận này do đối tượng quản lý thẻ xác nhận tạo ra và ký với phương thức chữ ký số.
Trong một số hệ thống, đối tượng quản lý đăng ký được tách riêng ra khỏi CA. Đối tượng
này không tạo ra các thẻ xác nhận. Nó có nhiệm v
ụ xác minh đối tượng truyền thông cho
một CA sẽ cấp phát thẻ xác nhận cho đối tượng đó. Nghĩa là, quá trình xác thực khi một

đối tượng yêu cầu một thẻ xác nhận của CA sẽ do RA đảm nhận.
Đúng như tên gọi của nó, PKI là một dịch vụ nền cho các dịch vụ an toàn an ninh dựa
trên các thẻ xác nhận. Trong các hệ thống này, PKI đảm nhận vai trò tạo lập, quản lý và
phân phát các thẻ xác nhận cho các đối tượng truy
ền thông. Nói tóm lại, tất cả các chức
năng quản lý của hệ thống PKI đều hướng tới một yêu cầu duy nhất: Quản lý các đối
tượng sử dụng trong hệ thống với khoá công khai của các đối tượng đó.
1.2. CÁC DỊCH VỤ VÀ PHẠM VI ỨNG DỤNG CỦA PKI
Trong phần này, ta hãy tìm hiểu những yêu cầu cơ bản nhất của an toàn an ninh thông
tin. Từ đó, xem xét những dịch vụ mà hệ thống PKI cung cấp để đáp ứng những yêu cầu
đã nêu và đánh giá phạm vi ứng dụng của hệ thống này.
1.2.1. Các yêu cầu cơ bản của an toàn an ninh thông tin
An toàn an ninh thông tin bao hàm nhiều vấn đề khác nhau, trong đó, nếu nói đến các
biện pháp an toàn an ninh có sử dụng các phương pháp mã hoá (với khoá công khai), ta
có thể kể đến 4 yêu cầu cơ bản sau đây:
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
9
1. Toàn vẹn dữ liệu: Toàn vẹn dữ liệu đảm bảo cho thông tin không bị thay đổi bởi
những đối tượng không được cấp thẩm quyền.
2. Không thể bác bỏ: Các đối tượng không thể bác bỏ những hành động mà mình đã
thực hiện.
3. Xác thực đối tượng: Khả năng xác thực đối tượng cho các đối tượng truyền tin biết
chắc mình đang giao tiếp với
đối tượng nào.
4. Bí mật thông tin: Bí mật thông tin là yêu cầu trong việc đảm bảo rằng nếu A muốn
truyền thông tin cho B thì chỉ có B có thể đọc được thông tin này.
1.2.2. Khả năng đáp ứng của các dịch vụ sử dụng PKI
Trong phần này, ta sẽ lấy những ví dụ để minh hoạ khả năng đảm bảo các yêu cầu về an
toàn an ninh mà các dịch vụ sử dụng PKI (thực chất là các dịch vụ sử dụng phương thức
mã hoá với khoá công khai) có thể đáp ứng. Để tiện minh hoạ, ta lấy phương thức chữ ký

số để mô tả trong các ví dụ dưới đây. Chữ ký số là một trong số những dịch vụ
tiêu biểu
nhất dựa trên phương thức mã hoá với khoá công khai. Trong quá trình hoạt động,
phương thức này được kết hợp chặt chẽ với hệ thống PKI.
Đối với khả năng bảo vệ tính toàn vẹn dữ liệu, khi một thông điệp đã được mã hoá (tạo
chữ ký số cho thông điệp), mọi thay đổi đối với chữ ký số được tạo ra đều làm cho nó
không thể được ki
ểm chứng bởi đối tượng nhận. Do vậy, nếu đối tượng nhận không thể
kiểm chứng được chữ ký số tạo bởi đối tượng truyền thì chứng tỏ thông tin truyền đi đã bị
thay đổi hoặc có sai sót.
Với vấn đề đảm bảo tính không thể bác bỏ, khi một đối tượng muốn tạo chữ ký số cho
một thông điệp, do chỉ đố
i tượng đó biết được khoá riêng của mình nên nếu ta có thể
kiểm chứng được một chữ ký số với khoá công khai của đối tượng nào đó thì chứng tỏ
đối tượng đó đã tạo ra chữ ký số với khoá riêng tương ứng. Nghĩa là, tính không thể bác
bỏ gắn các đối tượng với những hành động mà đối tượng đó đã thực hiện.
Với yêu cầu xác thực đố
i tượng, khi một đối tượng A muốn xác thực định danh của đối
tượng B, nó gửi một thông điệp với một số thông tin nhất định dưới dạng mã xác thực
đến cho B. B tạo chữ ký số đối với thông điệp nhận được bằng khoá riêng của mình và
truyền lại cho A. A thực hiện kiểm chứng ký số của B trên thông điệp vừa nhận được
bằng khoá công khai củ
a B. Nếu thông thông điệp được kiểm chứng thì A biết chắc mình
đang liên lạc với B.
Với việc đảm bảo tính bí mật của thông tin, khi A muốn trao đổi thông tin với B, A mã hoá
thông tin cần truyền với khoá công khai của B rồi truyền cho B. Chỉ B biết khoá riêng của
mình nên chỉ có B mới có thể giải mã và đọc được thông tin.
1.2.3. Các dịch vụ an toàn an ninh dựa trên hệ thống PKI
Trong sơ đồ dưới đây ta có thể có một cái nhìn khái quát về các dịch vụ an toàn an ninh
sử dụng các thẻ xác nhận trên cơ sở PKI.

Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
10

Hình 1-1 Các ứng dụng dựa trên hệ thống PKI
1.3. CÁC ĐỐI TƯỢNG CƠ BẢN CỦA HỆ THỐNG PKI
Dưới góc độ các hoạt động quản lý hệ thống PKI, những đối tượng tham gia vào hệ thống
PKI bao gồm: các đối tượng sử dụng (EE), các đối tượng quản lý thẻ xác nhận (CA) và
các đối tượng quản lý đăng ký (RA) và các hệ thống lưu trữ.
1.3.1. Chủ thể và các đối tượng sử dụng
Khái niệm chủ thể được sử dụng để chỉ đối tượng được ghi tên trong trường subject của
một thẻ xác nhận. Tuy nhiên, để tránh nhầm lẫn chủ thể với tên một trường của thẻ xác
nhận, ta nên dùng cụm từ đối tượng sử dụng. Ta cần lưu ý: Một chủ thể có thể là một CA
hoặc một EE, đây là do đặc tính của quá trình cấp phát thẻ
xác nhận. Thẻ xác nhận có
thể được cấp cho CA hoặc EE. Tuy nhiên, ta chỉ gọi các EE là đối tượng sử dụng vì chỉ
những thẻ cấp cho đối tượng loại này mới được sử dụng trực tiếp trong các dịch vụ an
toàn an ninh. Thẻ xác nhận cấp cho các CA chủ yếu được dùng để hình thành mối tin cậy
giữa chúng.
Có một điều quan trọng mà ta cần lưu ý là khái niệm đối tượng sử
dụng không chỉ bao
hàm những người sử dụng các dịch vụ mà còn là chính bản thân các dịch vụ đó. Đây là
một điều hiển nhiên bởi vì các trình ứng dụng an toàn an ninh được đề cập đến ở đây là
những dịch vụ dựa trên thẻ xác nhận. Điều này sẽ ảnh hưởng đến những giao thức mà
các hoạt động của hệ thống PKI sử dụng. Ví dụ, m
ột phần mềm ứng dụng có thể biết
chắc những trường mở rộng nào của một thẻ xác nhận là cần thiết trong khi một người
sử dụng phần mềm đó thì lại hầu như không biết về những thông tin này. Trong một số
trường hợp cho phép, ta có thể coi các đối tượng sử dụng là những đối tượng không
thuộc loại các đối tượng quản lý hệ
thống PKI.

Tất cả các đối tượng sử dụng ít nhất phải có khả năng quản lý và truy cập một cách an
toàn đến các thông tin sau:
1. Tên của chính đối tượng đó.
2. Khoá riêng của đối tượng đó.
3. Tên của CA được chính đối tượng này tin tưởng (trusted CA).
QUẢN LÝ THẺ
XÁC NHẬN PKI
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
11
4. Khoá công khai của CA này.
Trong quá trình triển khai, các đối tượng sử dụng những phương tiện lưu trữ an toàn để
lưu các thông tin ngoài những thông tin tối thiểu kể trên (thẻ xác nhận của đối tượng, các
thông tin cho các dịch vụ cụ thể). Việc lưu trữ thông tin dưới hình thức như trên được gọi
là môi trường an toàn cá nhân.
1.3.2. Đối tượng quản lý thẻ xác nhận
Đối tượng quản lý thẻ xác nhận (CA) không nhất thiết phải là một bên thứ ba thực sự nếu
xét dưới góc độ của các đối tượng trong một tổ chức. Nghĩa là, CA thực chất lại thuộc về
cùng một tổ chức chứa các đối tượng sử dụng mà nó hỗ trợ. Ngoài ra, ta cũng sử dụng
khái niệm CA để chỉ đối tượng được nêu tên trong trường issuer của th
ẻ xác nhận.
Khi cần phân biệt phần mềm hoặc các công cụ phần cứng được sử dụng bởi CA ta sử
dụng khái nhiệm công cụ của CA. Khái niệm này bao hàm các thành phần làm việc theo
cả chế độ off-line lẫn on-line. Trong đó, chỉ có thành phần off-line là biết được khoá riêng
của CA.
Ta sử dụng khái niệm CA gốc để chỉ một CA được một đối tượng sử dụng nào đó
được
tin cậy một cách trực tiếp. Ta hiểu khái niệm trực tiếp có nghĩa là việc tin cậy có thể được
đảm bảo mà không cần thêm một CA nào nữa. Nói cách khác, đây là CA cuối cùng trên
nhánh xác nhận. Khi đó, việc lấy thông tin về khoá công khai của CA gốc cần phải được
thực hiện thông qua những phương thức riêng, nghĩa là viêc trao đổi thông tin không

được thực hiện trên đường truyền thông dùng để truyền các thẻ xác nhận. Ở
đây có thể
sử dụng những phương pháp phân phát thông tin dựa trên giấy tờ và thư tín. Ta cũng
cần lưu ý một điều là CA gốc không nhất thiết phải nằm trên đỉnh của một cây phân cấp
biểu diễn hệ thống. Điều cần quan tâm là CA gốc được tin cậy trực tiếp bởi một hoặc một
số đối tượng sử dụng.
Một CA thứ
cấp nếu xét trên phương diện của các đối tượng sử dụng thì là bất kỳ CA nào
khác với CA gốc. Thông thường, một CA thứ cấp sẽ không là CA gốc của bất kỳ đối
tượng sử dụng nào. Tuy nhiên, điều này không phải là hoàn toàn bắt buộc.
1.3.3. Đối tượng quản lý đăng ký thẻ xác nhận
Trong nhiều môi trường hoạt động, việc tách riêng RA khỏi CA là một việc cần thiết. Chức
năng của RA trong các trường hợp khác nhau cũng khác nhau. Tuy nhiên, RA có thể có
môt số chức năng như sau:
1. Xác thực cá nhân.
2. Phân phát các thẻ xác nhận.
3. Thông báo huỷ bỏ.
4. Gán tên cho các đối tượng.
5. Sinh khoá.
6. Lưu trữ các cặp khóa riêng và khoá công khai.
Tng quan v PKI H TNG KHO CễNG KHAI
12
RA cú th c coi l mt thnh phn khụng bt buc. Tuy nhiờn, khi RA ng c lp
thỡ CA phi m nhn nhng chc nng trờn. Ngha l cỏc chc nng m CA cú c
cho cỏc i tng phi ging nh trong trng hp CA v RA ng c lp.
V bn cht, RA cng l mt i tng s dng. Tt c cỏc RA u c xỏc nhn v cú
cỏc khoỏ riờng dựng trong vic to ch ký s cho cỏc thụng tin m nú cp phỏt. Trong
mt s trng hp, cỏc i tng s dng cú th liờn h trc tip vi CA qun lý mỡnh
mc dự trong h thng vn cú mt RA. Vớ d, trong cỏc th tc ng ký v xỏc nhn ban
u, nú phi liờn h trc tip vi CA cp nht thụng tin v th xỏc nhn ca mỡnh.

1.4. CC HOT NG C BN TRONG H THNG PKI
1.4.1. Mụ hỡnh tng quỏt ca h thng PKI
Trong s di õy l cỏc i tng ca h thng PKI v mi quan h gia chỳng trờn
c s cỏc hot ng qun lý PKI. Mi liờn h c th hin bng cỏc thụng ip c
truyn i gia cỏc i tng trong h thng.
RA
Đăng tải thẻ xác nhận
Thu thập thông
tin
"out-of-band"
Đăng ký/xác thực ban đầu
Khôi phục cặp khoá
Cập nhật cặp khoá
Cập nhật thẻ xác nhận
Yêu cầu huỷ bỏ
Phát hành thẻ xác nhận
Phát hành danh sách thẻ cần huỷ bỏ
Phát hành thẻ
xác nhận
Phát hành thông
tin
"out-of-band"
Xác nhận ngang hàng
Cập nhật thẻ xác nhận ngang hàng
Đối tợng
sử dụng
Hệ thống
lu trữ
CA1
CA2

Hỡnh 1-2 Cỏc i tng v hot ng c bn trong h thng PKI
Da trờn cỏc thụng ip c nh ngha (s c trỡnh by chi tit trong cỏc phn sau)
v xột mt mc khỏi quỏt, cỏc hot ng ca h thng qun lý PKI cú th c phõn
thnh cỏc nhúm sau:
1.4.2. Thit lp cỏc th xỏc nhn
Cỏc th xỏc nhn c to ra trờn c s mt s thụng tin c bn (i tng phỏt hnh,
i tng s dng, thut toỏn to ch ký s, thi hn lu hnh ) v mt s thụng tin
m rng. Song song vi quỏ trỡnh to ra mt th xỏc nhn mi, ta cng cn tin hnh mt
s bc ph tr. Ta cú th k n vic to lp hoc cp nh
t danh sỏch cỏc th b hu
b, vic ng ti thụng tin v khoỏ cụng khai ca CA, lu th xỏc nhn va to c.
1.4.3. Khi to cỏc EE
Quỏ trỡnh ny ũi hi mt s bc c bn nh sau: Trc tiờn, i tng ny phi thu
thp c thụng tin v khoỏ cụng khai ca CA gc. iu ny giỳp cho cỏc thụng ip
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
13
được truyền đi giữa đối tượng đó và CA gốc được đảm bảo an toàn và cũng là một
phương thức để xác thực EE Sau đó, EE phải thu thập thông tin về các tuỳ chọn được hỗ
trợ bởi đối tượng quản lý PKI. Điều này rất quan trọng vì nó ảnh hưởng đến giao thức
hoạt động và các thông điệp mà EE truyền đi hay nhận về.
1.4.4. Các hoạt động liên quan đến thẻ xác nhận
Có nhiều hoạt động liên quan tới thẻ xác nhận, các hoạt động đó được phân thành:
1.4.4.1. Đăng ký và xác nhận ban đầu
Trong quá trình này, trước tiên, EE phải thông báo cho CA hoặc RA biết về sự hiện diện
của mình trong hệ thống. Đối tượng được thông báo có quyền ưu tiên cao hơn là CA sẽ
cấp phát cho EE này một thẻ xác nhận khi nó chấp nhận yêu cầu. Kết quả của quá trình
này là một CA sẽ tạo ra một thẻ xác nhận cho EE ứng với khoá công khai mà EE này
cung cấp khi đăng ký. Đồng thời, CA này cũng gửi thẻ xác nhận này đến cho hệ thống
lư

u trữ. Trong một hệ PKI lớn, hệ thống lưu trữ có vai trò quan trọng và có tính độc lập
cao đối với CA.
Nếu xét một cách chi tiết, giai đoạn này gồm nhiều bước nhỏ hơn. Có thể, nó sẽ bao gồm
cả công đoạn khởi tạo các công cụ của EE. Ví dụ, để có thể được sử dụng trong công
đoạn kiểm chứng đường dẫn đến các thẻ xác nhận, các công cụ
của EE phải được khởi
tạo một cách an toàn với khoá công khai của một CA nào đó. Ngoài ra, một EE còn cần
phải được khởi tạo với cặp khoá của chính nó.
1.4.4.2. Cập nhật thông tin về cặp khoá
Mỗi đối tượng tham gia vào hệ thống PKI đều phải có một cặp khoá gồm khoá công khai
và khoá riêng. Tất cả các cặp khoá này cần phải được cập nhật một cách thường xuyên
vì các cặp khoá này có thể được thay bằng cặp khoá mới. Việc thay đổi thông tin của các
cặp khoá này có thể là do chúng đã hết hạn sự dụng hoặc đã bị lộ.
Như vậy, để đảm bảo tất cả các đối t
ượng có liên quan nắm được thông tin mới nhất về
cặp khoá của mình, đối tượng sở hữu cặp khoá phải tạo các thông điệp cập nhật cặp
khoá để gửi đến cho các đối tượng có liên quan.
1.4.4.3. Cập nhật thông tin về thẻ xác nhận
Mỗi thẻ xác nhận được cấp phát cho các đối tượng sử dụng chỉ có tác dụng trong một
khoảng thời gian đã định. Khi các thẻ xác nhận này hết hạn và đối tượng sử dụng muốn
tiếp tục có được thẻ xác nhận của mình thì CA quản lý đối tượng ấy sẽ tạo ra một thẻ xác
nhận mới cho đối tượng và phải làm nhiệm vụ cập nhật thông tin về
thẻ xác nhận này.
Trong trường hợp không có sự thay đổi nào về các tham số môi trường của hệ thống PKI,
các CA có thể chỉ cần “làm tươi” các thẻ xác nhận này.
1.4.4.4. Cập nhật thông tin về cặp khoá của CA
Cũng giống như đối với các EE, cặp khoá của CA cũng cần được cập nhật thường xuyên.
Tuy nhiên, do vai trò và các mối liên hệ của CA trong hệ thống có nhiều khác biệt và phức
tạp hơn nên ta cần phải có những cơ chế thích hợp để thực hiện công việc này. Ví dụ, CA
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI

14
phải gửi được thông tin về cặp khoá công khai của mình tới tất cả các EE mà nó quản lý
theo kiểu multicast. Ngoài ra, nó còn phải gửi thông tin này đến các CA khác có liên quan.
1.4.4.5. Yêu cầu xác nhận ngang hàng
Khi diễn ra quá trình trao đổi thông tin giữa các CA ngang hàng, một CA có thể sẽ yêu
cầu CA còn lại gửi cho mình một thẻ xác nhận ngang hàng. Thẻ xác nhận ngang hàng
này về bản chất cũng giống với các thẻ xác nhận dành cho các EE. Trường subject của
thẻ xác nhận ngang hàng dùng để chỉ CA được cấp thẻ còn trường issuer được dùng để
chỉ CA cấp phát thẻ.
Trong các loại thẻ xác nhận ngang hàng, ta phân ra làm hai loại như sau: Nếu hai CA
thuộc về vùng qu
ản lý khác nhau, ta có thẻ xác nhận ngang hàng liên miền. Nếu hai CA
thuộc cùng một vùng quản lý thì ta gọi đó là thẻ xác nhận ngang hàng nội miền.
Đối với các thẻ xác nhận ngang hàng, ta có một số chú ý sau:
1. Trong nhiều hệ thống PKI, nếu không có những định nghĩa chi tiết hơn, các thẻ
xác nhận ngang hàng thường được hiểu là thẻ xác nhận ngang hàng liên miền.
2. Việc phát hành các thẻ xác nhận ngang hàng không nhất thiết phải được tiến
hành ở c
ả hai CA. Nghĩa là có cả trường hợp một CA được xác nhận bởi một CA
khác mà không có theo chiều ngược lại.
1.4.4.6. Cập nhật thẻ xác nhận ngang hàng
Việc cập nhật thẻ xác nhận ngang hàng cũng giống với việc cập nhật thẻ xác nhận cho
các đối tượng sử dụng. Tuy nhiên, các đối tượng có liên quan đến quá trình này chỉ là
các CA.
1.4.5. Phát hành thẻ và danh sách thẻ bị huỷ bỏ
Có những hoạt động của hệ thống quản lý PKI sẽ dẫn đến việc tạo ra các thẻ xác nhận
hoặc danh sách các thẻ xác nhận bị huỷ bỏ. Ta có hai hoạt động tiểu biểu thuộc loại này
là: phát hành thẻ xác nhận và phát hành danh sách thẻ xác nhận bị huỷ bỏ.
Khi CA phát hành một thẻ xác nhận, trước tiên, nó cần phải dựa trên định dạng của thẻ
xác nhận cần cấp. Sau khi có được các thông tin v

ề chính sách quản trị, CA sẽ tổ chức
chúng theo định dạng đã biết, khi đó, thẻ xác nhận đã hoàn thiện. Tuy nhiên, việc phát
hành thẻ xác nhận chỉ hoàn tất sau khi CA gửi thông tin về thẻ xác nhận này đến đối
tượng sử dụng và lưu thẻ này vào hệ thống lưu trữ.
Việc phát hành danh sách thẻ xác nhận bị huỷ bỏ cũng được tiến hành như với danh
sách thẻ xác nhận. Tuy nhiên, thông tin v
ề danh sách này chỉ được truyền cho hệ thống
lưu trữ.
1.4.6. Các hoạt động phục hồi
Các hoạt động phục hồi được thực hiện khi các đối tượng sử dụng đánh mất thông tin mà
nó lưu trữ. Ví dụ, như đã nêu ở phần trên, các đối tượng sử dụng có thể có một số
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
15
phương tiện lưu trữ an toàn cá nhân; khi phương tiện lưu trữ này bị hỏng thì nó cần phải
nhờ đến CA để phục hồi các thông tin bị mất.
Việc phục hồi thông tin chủ yếu được tập trung vào việc phục hồi các cặp khoá. Đối với
các CA và RA, việc lưu trữ thông tin backup về khoá của các đối tượng là không bắt
buộc. Khi các đối tượng sử dụng cần phục hồi các c
ặp khoá của mình, ta cần phải có
thêm một số giao thức chuyển đổi để hỗ trợ việc phục hồi khoá. Trong phạm vi đồ án, ta
sẽ không đề cập đến các giao thức này.
1.4.7. Các hoạt động huỷ bỏ
Có một số hoạt động quản lý hệ thống PKI dẫn đến việc tạo một danh sách thẻ xác nhận
sẽ được huỷ bỏ hoặc bổ sung những thẻ cần được hủy bỏ vào danh sách này. Ví dụ, một
đối tượng đã được phân quyền trong hệ thống có thể thông báo cho CA về một trạng thái
không bình thường và cần phải có một số yêu cầu hủy bỏ thẻ xác nh
ận. Cụ thể, nếu ta
phát hiện được một đối tượng đã đăng ký để lấy thẻ xác nhận có những biểu hiện không
bình thường hoặc những thông tin do đối tượng này có một số bất hợp lý thì ta có thể báo
cho CA biết và huỷ bỏ thẻ xác nhận đã cấp cho đối tượng sử dụng đó.

Đối với tất cả các hoạt động đã nêu trên, ta có một số l
ưu ý sau: Các giao thức làm việc
theo chế độ on-line không phải là giải pháp duy nhất để thực hiện các hoạt động trên. Đối
với tất cả các giao thức hoạt động theo chế độ on-line, ta đều có một phương thức hoạt
động theo chế độ off-line cho kết quả tương đương.
1.5. CẤU TRÚC CỦA CÁC THÔNG ĐIỆP PKI
Tất cả các quá trình trao đổi thông tin giữa các đối tượng trong hệ thống PKI đều được
thực hiện thông qua việc trao đổi các thông điệp được định nghĩa riêng cho hệ thống. Các
thông điệp này được tạo ra trên cơ sở các chức hoạt động cơ bản của hệ thống PKI đã
được nêu trong phần trước. Sau đây ta sẽ tìm hiểu chi tiết về các thông điệp được sử
dụ
ng trong hệ thống PKI.
1.5.1. Giới thiệu về nguyên tắc giả mã
Trong phần này, để tiện mô tả các cấu trúc thông điệp, ta sử dụng kiểu ngôn ngữ giả lập
trình C. Trong phần dưới đây, ta có đoạn mã mô tả cấu trúc chung của một thông điệp
PKI và những giải thích cho nguyên tắc giả mã của toàn bộ tài liệu.Tất cả các thông điệp
được sử dụng trong việc quản lý hệ thống PKI có cấu trúc chung như sau:


PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE(1 MAX) OF Certificate OPTIONAL }




1 2
3

4 5 6
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
16
Trong hình trên, ta có một minh hoạ tiêu biểu cho một cấu trúc dữ liệu được viết dưới
dạng giả mã. Với các trường thông tin được đánh số như trên, ta thấy một đoạn giả mã
có các thành phần và ý nghĩa của chúng như sau:
1. Tên của cấu trúc: Phần này được thể hiện đầu tiên trong đoạn giả mã. Nó cho ta
biết cấu trúc thông tin nào được định nghĩa.
2. Kiểu tập hợp cấu trúc
: Phần này cho ta biết cấu trúc được định nghĩa là một mảng
của tập các thành phần (
SEQUENCE), là chọn lựa một trong số các thành phần
(
CHOICE) hay chỉ đơn thuần bao gồm các thành phần đó.
3. Tên các trường: Đây là tên của các trường tạo nên cấu trúc cần định nghĩa. Như
vậy, phần này cho ta biết cấu trúc được định nghĩa gồm những trường nào.
4. Số thứ tự các trường tuỳ chọn: Thành phần thông tin này chỉ xuất hiện khi nào
trong cấu trúc định nghĩa có các thành phần tuỳ chọn. Thành phần này có nhiệm
vụ đ
ánh số thứ tự các trường thông tin không bắt buộc trong cấu trúc.
5. Kiểu của các trường: Trường này cho ta biết kiểu ứng với tên các trường trong
cấu trúc. Kiểu của các trường có thể là các kiểu dữ liệu cơ bản hay có thể là các
kiểu dữ liệu có cấu trúc khác.
6. Dấu hiệu báo tuỳ chọn: Trường này chỉ xuất hiện khi nào cấu trúc cần định nghĩa
có các thành phần tuỳ chọ
n. Nếu trường này xuất hiện (OPTIONAL) thì trường thông
tin nằm trên cùng dòng với dấu hiệu này được hiểu là tuỳ chọn.
1.5.2. Cấu trúc tổng quát của thông điệp PKI
Hình mô tả nguyên tắc giả mã trong phần trước có chứa đoạn mã định nghĩa cấu trúc
chung của thông điệp PKI. Ta nhận thấy trong một thông điệp sẽ có hai trường cơ bản và

hai trường tuỳ chọn. Hai trường cơ bản là:
1. Trường header: Trường này cho ta biết các thông tin liên quan đến các đối tượng
truyền và nhận trong hệ thống PKI. Trong hầu hết các thông điệp PKI, trường
header có định dạng giố
ng nhau. Trường này bắt buộc phải tồn tại trong mọi
thông điệp PKI và không được phép là rỗng.
2. Trường body: Trường này chứa nội dung mà thông điệp PKI cần truyền tải. Phần
này của thông điệp có cấu trúc không xác định. Định dạng của trường body trong
thông điệp sẽ tuỳ thuộc vào đối tượng tạo ra nó, vào thông tin nó truyền tải và nó
được tạo ra bởi chức năng nào của hệ th
ống. Trong những trường hợp đặc biệt,
trường body có thể là rỗng.
3. Trường protection: Trường này đóng vai trò bảo vệ cho thông tin được truyền đi.
Về nguyên tắc, các thông tin cần được bảo về thường được mã hoá và chứa
trong phần thân của thông điệp. Trường protection có vai trò bảo vệ ở lớp ngoài
cho cả thông điệp PKI. Thông thường, đây là những bit được tạo ra nhờ một số
thuật toán mã hoá bảo mật được hệ thống PKI hỗ trợ. Tuy nhiên, đây là một
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
17
trường tùy chọn và trong thực tế ta ít sử dụng đến trường này. Trong phần mô tả
chi tiết, ta cũng sẽ không đề cập sâu hơn tới trường này.
4. Trường extraCerts: Đây là trường chứa mảng các thẻ xác nhận bổ sung. Các thẻ
xác nhận này thường có tác dụng giúp cho đối tượng nhận kiểm chứng thông tin
nhận được và xác thực đối tượng. Trường này cũng được đánh dấu là tuỳ chọn
và ta sẽ không mô tả chi tiết hơn nữa về nó trong các phần sau vì nó không
thường xuyên được sử dụng.
1.5.3. Trường PKIHeader
Tất cả các thông điệp PKI đều phải chứa phần thông tin header để xác định địa chỉ và
thực hiện các giao tác. Khi các thông điệp PKI được bảo vệ (sử dụng các phương thức
mã hoá) thì trường thông tin này cũng được mã hoá. Các trường thông tin có trong phần

header của thông điệp gồm có:
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
recipient GeneralName,
messageTime [0] GeneralizedTime OPTIONAL,
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
transactionID [4] OCTET STRING OPTIONAL,
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1 MAX) OF InfoTypeAndValue OPTIONAL}
PKIFreeText ::= SEQUENCE SIZE (1 MAX) OF UTF8String
1. pvno: Trường này có kiểu số nguyên, nó định ra phiên bản của thông điệp PKI;
hiện tại, trường này có giá trị cao nhất là 2, ứng với phiên bản thứ 3.
2. sender: Trường này chứa tên của đối tượng gửi thông điệp PKI. Khi được sử
dụng với trường senderKID, nó cho phép ta kiểm tra khả năng bảo vệ thông điệp.
3. recipient: Trường này chứa tên của đối tượng nhận thông đi
ệp PKI. Khi được sử
dụng với trường recipKID, nó cho phép ta kiểm tra khả năng bảo vệ thông điệp.
4. protectionAlg: Trường này định ra thuật toán mã hóa được sử dụng để bảo vệ
thông điệp. Trường này phụ thuộc vào bit PKIProtection, nếu bit này báo hiệu
thông điệp không được bảo vệ thì trường này sẽ bị bỏ qua. Nếu bit này báo hiệu
là thông điệp được bảo vệ thì tr
ường protectionAlg phải có trong thông điệp.
5. senderKID và recipKID: Là những trường được sử dụng để định ra xem những
khoá nào được sử dụng để bảo vệ thông điệp PKI.
6. transactionID: Trường này cho phép đối tượng nhận đối sánh thông điệp nhận

được với thông điệp yêu cầu của mình trước đó.
7. senderNonce và recipNonce: Là những trường được sử dụng để bả
o vệ thông
điệp trước hình thức tấn công phát lại gói tin.
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
18
8. messageTime: Là trường cho ta biết thời điểm người gửi tạo ra thông điệp. Điều
này giúp cho các đối tượng sử dụng có thể đồng bộ thời gian của mình với thời
gian của hệ thống quản lý.
9. freeText: Là trường được sử dụng để gửi một số thông điệp đến cho người nhận.
Có một điều cần phải đảm là ng
ười nhận phải đọc được thông tin trong trường
này. Điều đó có nghĩa là phía gửi và phía nhận phải thống nhất về phương thức
biểu diễn thông tin.
10. generalInfo: Là trường được sử dụng để lưu những dữ liệu bổ sung mà hệ thống
thiết bị của người nhận có thể xử lý được.
1.5.4. Trường PKIBody
Dưới đây là mô tả về phần thân của thông điệp quản lý PKI.
PKIBody ::= CHOICE {
ir [0] CertReqMessages,
ip [1] CertRepMessage,
cr [2] CertReqMessages,
cp [3] CertRepMessage,
p10cr [4] CertificationRequest,
popdecc [5] POPODecKeyChallContent,
popdecr [6] POPODecKeyRespContent,
kur [7] CertReqMessages,
kup [8] CertRepMessage,
krr [9] CertReqMessages,
krp [10] KeyRecRepContent,

rr [11] RevReqContent,
rp [12] RevRepContent,
ccr [13] CertReqMessages,
ccp [14] CertRepMessage,
ckuann [15] CAKeyUpdAnnContent,
cann [16] CertAnnContent,
rann [17] RevAnnContent,
crlann [18] CRLAnnContent,
conf [19] PKIConfirmContent,
nested [20] NestedMessageContent,
genm [21] GenMsgContent,
genp [22] GenRepContent,
error [23] ErrorMsgContent }
Như vậy, phần thân của thông điệp PKI có thể có 23 dạng khác nhau. Các dạng này tuỳ
thuộc vào từng hoạt động, chức năng và đối tượng phát ra thông điệp. Ta cũng nhận thấy
một số thông điệp sẽ có định dạng cơ bản giống nhau và ta coi chúng như thuộc vào một
nhóm. Dưới đây là một số khuôn dạng dữ liệu chung cho một số thông điệp được sử

dụng cho các hoạt động quản lý hệ thống PKI:
CertReqMessages ::= SEQUENCE SIZE (1 MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
Nội dung tuỳ thuộc vào loại khoá được sử dụng
regInfo SEQUENCE SIZE(1 MAX) OF AttributeTypeAndValue
OPTIONAL}
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
19
CertRequest ::= SEQUENCE {
Số hiệu để ghép cặp thông điệp yêu cầu và thông điệp trả lời

certReqId INTEGER,
Các trường đã chọn của thẻ xác nhận được phát hành
certTemplate CertTemplate,
Các thông tin liên quan đến quá trình phát hành
controls Controls OPTIONAL}
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL}
OptionalValidity ::= SEQUENCE {
Ít nhất một trong hai trường phải tồn tại
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL}
Controls ::= SEQUENCE SIZE(1 MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
Được sử dụng nếu CA biết đối tượng yêu cầu đã có một khoá riêng
raVerified [0] NULL,
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }

POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
Chỉ được sử dụng nếu đối tượng nhận đã có một định danh được xác thực
publicKeyMAC PKMACValue },
Sử dụng nếu không có định danh nào của đối tượng gửi được xác thực
publicKey SubjectPublicKeyInfo }
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING }
PBMParameter ::= SEQUENCE {
Tập các bit được sử dụng để tăng độ an toàn cho thông điệp
salt OCTET STRING,
Số hiệu của thuật toán phân tách một chiều (thường là SHA-1)
owf AlgorithmIdentifier,
Số lần hàm phân tách một chiều được sử dụng
iterationCount INTEGER,
Số hiệu của thuật toán tạo mã xác thực thông điệp MAC
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
20
mac AlgorithmIdentifier }
POPOPrivKey ::= CHOICE {
Thông điệp minh chứng cho sự sở hữu đối với một khoá riêng nào đó
thisMessage [0] BIT STRING,
Các thông điệp thứ cấp minh chứng cho sự sở hữu đối với một khoá riêng
subsequentMessage [1] SubsequentMessage,

Được sử dụng trong quá trình thoả thuận khoá
dhMAC [2] BIT STRING }
SubsequentMessage ::= INTEGER {
Báo xem các thẻ xác nhận được lưu trong thông điệp có được mã hoá không
encrCert (0),
Báo hiệu CA phải tham gia vào một phiên hỏi đáp với một EE để chứng minh
sự sở hữu đối với khoá riêng mà nó nắm giữ
challengeResp (1) }
1.5.4.1. Thông điệp yêu cầu khởi tạo
Như mô tả trong phần giả mã lập trình, thông điệp yêu cầu khởi tạo (Initialization Request
– IR) có cấu trúc dữ liệu kiểu CertReqMessages. Thông điệp này chỉ ra thẻ xác nhận
được yêu cầu. Thông điệp này được sử dụng khi một EE lần đầu tiên được khởi tạo trong
hệ thống PKI.
1.5.4.2. Thông điệp trả lời yêu cầu khởi tạo
Thông điệp trả lời yêu cầu khởi tạo (Initialization Response - IP) là thông điệp có khuôn
dạng dữ liệu kiểu CertRepMessage. Nó được dùng để trả lời các thông điệp yêu cầu
thông tin về trạng thái của hệ thống PKI (PKIStatusInfo), về các đối tượng sử dụng hoặc
có thể là một khoá riêng. Thông thường, các thông tin trả về được mã hoá với một khoá
phiên đã định. Chính khoá phiên này lại được mã hoá bởi khoá được sử d
ụng trong giao
thức quản lý PKI (protocolEncKey).
1.5.4.3. Thông điệp yêu cầu đăng ký/yêu cầu thẻ xác nhận
Thông điệp yêu cầu đăng ký (Registration Request - RR) và thông điệp yêu cầu thẻ xác
nhận (Certificate Request - CR) là các thông điệp có cấu trúc kiểu CerReqMessages. Các
thông điệp này định ra những thẻ xác nhận được yêu cầu và được sử dụng khi một đối
tượng sử dụng muốn có thêm các thẻ xác nhận.
Trong trường hợp này, định dạng dữ liệu có thể là kiểu CertificationRequest nếu như các
thông điệp yêu cầu thẻ
xác nhận đối với các cặp khoá tạo chữ ký số khi hợp tác với các
hệ thống khác là cần thiết.

1.5.4.4. Thông điệp trả lời yêu cầu đăng ký/yêu cầu thẻ xác nhận
Thông điệp trả lời yêu cầu đăng ký (Registration Reply - RR) có khuôn dạng
CertRepMessage. Thông điệp này mang một giá trị trạng thái của mỗi thẻ xác nhận được
yêu cầu. Ngoài ra, có thể có khoá công khai của CA, các thông tin về yêu cầu không
được chấp nhận, một thẻ xác nhận của đối tượng hoặc một khoá riêng đã được mã hoá.
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
21
1.5.4.5. Thông điệp yêu cầu cập nhật khoá
Thông điệp yêu cầu cập nhật khoá (Key Update Request - KUR) có khuôn dạng
CertReqMessages. Đối với mỗi khoá cần được cập nhật, thông điệp này phải cung cấp
các trường thông tin như: subjectPublicKeyInfo, keyId, validity. Thông thường, thông điệp
này được sử dụng để cập nhật thông tin cho các thẻ xác nhận đã tồn tại.
1.5.4.6. Thông điệp trả lời yêu cầu cập nhật khoá
Thông điệp trả lời yêu cầu cập nhật khoá (Key Update Response - KUP) có khuôn dạng
CertRepMessage. Thông điệp này giống với thông điệp trả lời yêu cầu khởi tạo.
1.5.4.7. Thông điệp yêu cầu khôi phục khoá
Thông điệp yêu cầu khôi phục khoá (Key Recovery Request - KRR) giống với thông điệp
yêu cầu khởi tạo. Trong thông điệp này, ta phải cung cấp thông tin cho trường
subjectPublickKeyInfo và trường keyID để lấy ra được khoá công khai ứng với thẻ xác
nhận được yêu cầu.
1.5.4.8. Thông điệp trả lời yêu cầu khôi phục khoá
Trong thông điệp trả lời yêu cầu khôi phục khoá (Key Recovery Response - KRP), ngoại
trừ một số giá trị trạng thái, không còn trường tuỳ chọn nào được sử dụng. Thông điệp
này có khuôn dạng như sau:
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert Certificate OPTIONAL,
caCerts EQUENCE SIZE (1 MAX) OF Certificate OPTIONAL,
keyPairHist EQUENCE SIZE (1 MAX) OF CertifiedKeyPair OPTIONAL}
1.5.4.9. Thông điệp yêu cầu huỷ bỏ

Khi cần gửi một thông điệp yêu cầu huỷ bỏ thẻ xác nhận (Revocation Request - RR), ta
sử dụng cấu trúc thông điệp như trong phần mô tả dưới đây. Tên của đối tượng gửi thông
điệp yêu cầu nằm trong phần header của thông điệp.
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
Cho phép đối tuong yeu cau mo ta chi tiet ve the xac nhan no muon huy bo
certDetails CertTemplate,
Lý do của yêu cầu huỷ bỏ
revocationReason ReasonFlags OPTIONAL,
badSinceDate GeneralizedTime OPTIONAL,
EntryDetails Extensions OPTIONAL}
1.5.4.10. Thông điệp trả lời yêu cầu huỷ bỏ
Khi chấp nhận một yêu cầu huỷ bỏ (Revocation Response - RP), thông điệp sau đây
được gửi về cho đối tượng yêu cầu huỷ bỏ:
RevRepContent ::= SEQUENCE {
Thông báo trạng thái xử lý của CA đối với yêu cầu gửi đến
status SEQUENCE SIZE (1 MAX) OF PKIStatusInfo,
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
22
Số hiệu thẻ xác nhận bị yêu cầu huỷ bỏ
revCerts [0] SEQUENCE SIZE (1 MAX) OF CertId OPTIONAL,
Các CRL có liên quan
crls [1] SEQUENCE SIZE (1 MAX) OF CertificateList OPTIONAL}
1.5.4.11. Thông điệp yêu cầu thẻ xác nhận ngang hàng
Việc yêu cầu thẻ xác nhận ngang hàng giữa (Cross-Cert. Request - CCR) các CA cũng
sử dụng cùng một kiểu thông điệp như khi các đối tượng sử dụng yêu cầu thẻ xác nhận
từ CA. Tuy nhiên, có một điểm ràng buộc là cặp khoá sử dụng để mã hoá thông điệp
chứa thẻ xác nhận phải do phía CA yêu cầu thẻ xác nhận tạo ra từ trước. Đồng thời,
khoá riêng trong cặp khoá này bắt buộc phải không được g
ửi đến cho CA trả lời.

1.5.4.12. Thông điệp trả lời yêu cầu xác nhận ngang hàng
Thông điệp trả lời yêu cầu xác nhận ngang hàng (Cross-Cert. Response - CCP) cũng
giống với thông điệp trả lời yêu cầu xác nhận. Tuy nhiên, có một ràng buộc là không được
phép gửi khoá riêng (kể cả đã được mã hoá) cho CA yêu cầu. Điều này xuất phát từ
nguyên tắc: chỉ thành phần off-line mới biết được khoá riêng của đối tượng.
1.5.4.13. Thông điệp công bố cập nhật khoá CA
Khi CA cập nhật cặp khoá (CA Key Update Announcement - CKUANN) của chính mình,
cấu trúc dữ liệu sau được sử dụng để thông báo về sự thay đổi này:
CAKeyUpdAnnContent ::= SEQUENCE {
Thẻ chứa khoá công khai cũ được ký với khoá riêng mới
oldWithNew Certificate,
Thẻ chứa khoá công khai mới được ký với khoá riêng cũ
newWithOld Certificate,
Thẻ chứa khoá công khai mới được ký với khoá riêng mới
newWithNew Certificate }
1.5.4.14. Thông điệp công bố thẻ xác nhận
Thông điệp công bố thẻ xác nhận (Certificate Announcement - CANN) được sử dụng để
thông báo về sự tồn tại của một thẻ xác nhận. Ta cần lưu ý là phương pháp sử dụng
thông điệp này chỉ được sử dụng trong trường hợp không tồn tại một phương pháp phát
hành thẻ xác nhận nào khác. Ví dụ, nếu có một phương thức phát hành thẻ theo chuẩn
X.500 thì phương pháp này sẽ không được sử dụng.
CertAnnContent ::= Certificate
1.5.4.15. Thông điệp thông báo huỷ bỏ thẻ xác nhận
Khi một thẻ xác nhận bị huỷ bỏ (Revocation Announcement - RANN) hoặc sắp bị huỷ bỏ
bởi CA, nó sẽ đưa ra thông báo về sự kiện này. Thông báo có khuôn dạng như sau:
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,

Thông tin chi tiết về các CRL
crlDetails Extensions OPTIONAL}
Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
23
CA có thể sử dụng thông báo kiểu này để báo với chủ thể sở hữu thẻ xác nhận biết rằng
thẻ xác nhận mà đối tượng ấy nắm giữ sẽ hoặc đã bị huỷ bỏ. Nó chủ yếu được sử dụng
trong trường hợp đối tượng nắm giữ thẻ xác nhận không gửi yêu cầu huỷ bỏ. Nghĩa là
CA chủ động huỷ bỏ
một thẻ xác nhận. Trường willBeRevokedAt được dùng để xác định
thời điểm mà một chỉ mục mới ứng với thẻ xác nhận này được bổ sung vào danh sách
những thẻ xác nhận bị huỷ bỏ.
1.5.4.16. Thông điệp thông báo CRL
Khi một CA phát hành một hoặc một tập các CRL mới (CRL Announcement - CRLANN),
nó sẽ gửi đi thông điệp sau đây để thông báo về sự kiện này:
CRLAnnContent ::= SEQUENCE OF CertificateList
1.5.4.17. Thông điệp xác nhận
Thông điệp xác nhận (Confirmation - CONF) được sử dụng trong các hoạt động của giao
thức quản lý PKI theo kiểu yêu cầu - trả lời - xác nhận. Nội dung của thông điệp này giống
nhau trong tất cả các trường hợp vì bản thân phần header của thông điệp đã mang tất cả
các thông tin cần thiết.
PKIConfirmContent ::= NULL
1.5.4.18. Thông điệp PKI đa mục đích
Thông điệp PKI đa mục đích (General Message - GENM) được sử dụng trong một số
trường hợp truyền thông tin cho các thiết bị hoặc các trình ứng dụng của các đối tượng
sử dụng trong hệ thống. Khuôn dạng dữ liệu của thông điệp này như sau:
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
1.5.4.19. Thông điệp trả lời tổng quát

Thông điệp trả lời tổng quát (General Response - GENP) có cấu trúc như sau:
Đối tượng nhận có thể tự do bỏ qua những định danh mà nó không biết
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
1.5.4.20. Thông điệp thông báo lỗi
Thông điệp báo lỗi (Error Message - ERROR) được sử dụng trong trường hợp khi có lỗi
nào đó trong các hoạt động của giao thức PKI. Đi kèm với thông tin về lỗi là những thông
tin về trạng thái của hệ thống.

Dong Manh Quan Trang 24 23/08/2005
Phần 2
2 NHỮNG VẤN ĐỀ CƠ BẢN TRONG
XÂY DỰNG HỆ THỐNG PKI
Trong phần này, ta sẽ tìm hiểu những vấn đề liên quan tới việc triển khai hệ thống PKI
trong thực tế. Các vấn đề được đề cập bao gồm:
¾ Các mô hình triển khai hệ thống PKI.
¾ Những chức năng bắt buộc trong triển khai hệ thống PKI.
Việc tìm hiểu hai nội dung trên là cơ sở để ta thực hiện công đoạn phân tích thiết kế chi
tiết trong khi triển khai hệ thống PKI. Sau đ
ây, ta sẽ tìm hiểu hai nội dung trên.
2.1. CÁC MÔ HÌNH TRIỂN KHAI HỆ THỐNG PKI
Hệ thống PKI khi được triển khai ở bất kỳ phạm vi nào đều cần có một kiến trúc phù hợp.
Thông thường, ta dựa trên đặc điểm tổ chức của hệ thống các dịch vụ sử dụng PKI để
định ra kiến trúc phù hợp. Sau đây, ta sẽ tìm hiểu những kiến trúc hệ thống PKI tiêu biểu.
2.1.1. Kiến trúc phân cấp
Trong kiến trúc này, các CA đều nằm dưới một CA gốc. CA gốc cấp các thẻ xác nhận cho
những CA thứ cấp hay các EE. Đến lượt các CA này lại cấp các thẻ xác nhận cho những
CA ở mức thấp hơn hoặc cho các EE.
CA gèc
CA 3
EE

CA 2
EE EE (A)
CA 5
EE
EE
EEEEEEEE (B)
CA 4

Hình 2-1 Kiến trúc PKI phân cấp
Trong mô hình này, tất cả các đối tượng trong hệ thống đều phải biết khoá công khai của
CA gốc. Tất cả các thẻ xác nhận đều có thể được kiểm chứng bằng cách kiểm tra đường
dẫn của thẻ xác nhận đó đến CA gốc. Ví dụ, khi A muốn kiểm chứng thẻ xác nhận của B,
thẻ này do CA
4
cấp, do vậy A kiểm tra thẻ xác nhận của CA
4
; thẻ xác nhận của CA
4
lại do
Những vấn đề cơ bản trong xây dựng hệ thống PKI HẠ TẦNG KHOÁ CÔNG KHAI
25
CA
2
cung cấp nên A lại kiểm tra thẻ xác nhận của CA
2
; thẻ xác nhận của CA
2
là do CA
gốc cung cấp. Vì A biết khoá công khai của CA gốc nên nó có thể kiểm chứng trực tiếp.
Như vậy, trong kiến trúc của hệ thống PKI này, tất cả các đối tượng đều dựa trên sự tin

cậy đối với CA gốc duy nhất. Khoá công khai của CA gốc phải được phân phát cho các
đối tượng đã được xác thực để đảm bảo sự tin cậy trong hệ thống. Sự tin cậy này được
hình thành theo các cấp t
ừ CA gốc đến các CA thứ cấp và đến các đối tượng sử dụng.
Ta có một số đánh giá về kiến trúc hệ thống PKI phân cấp như sau:
2.1.1.1. Những ưu điểm của kiến trúc PKI phân cấp
1. Cấu trúc hệ thống quản lý của hầu hết các tổ chức đều có dạng phân cấp. Các
mối quan hệ trong mô hình phân cấp cũng khá giống với các quan hệ trong các tổ
chức. Vì vậy, ta có thể coi các nhánh của quá trình xác nhận đối tượng giống với
các nhánh trong cấu trúc của tổ chức.
2. Kiến trúc phân cấp này cũng gần giống với hình thức phân cấp trong việc tổ chức
thư mục. Do vậy, ta có thể
dễ dàng làm quen hơn.
3. Cách thức tìm ra một nhánh xác nhận là theo một hướng nhất định, không có hiện
tượng vòng lặp. Do vậy, quá trình xác nhận được thực hiện đơn giản và nhanh
chóng.
4. Tất cả các đối tượng sử dụng đều có nhánh xác nhận hướng về CA gốc, do vậy,
nêu một đối tượng sử dụng A cung cấp cho B thông tin về nhánh xác nhận của
mình thì B cũng có thể thực hiện xác nhận theo hướng đó vì B c
ũng biết khoá
công khai của CA gốc.
2.1.1.2. Những khuyết điểm của kiến trúc PKI phân cấp
Nếu ta áp dụng một mô hình phân cấp một cách cứng nhắc thì vẫn có một số nhược
điểm như sau:
1. Trên một phạm vi lớn, không thể chỉ có một CA duy nhất để đảm nhận tất cả các
quá trình xác nhận.
2. Các quan hệ kinh doanh, thương mại không phải lúc nào cũng có dạng phân cấp.
3. Khi khoá riêng của CA gốc bị tiết lộ thì toàn bộ hệ thống sẽ bị nguy hiểm. Nếu có
khắc phụ
c bằng cách thay cặp khoá mới thì thông tin về khoá công khai của CA

gốc phải được truyền đến cho tất cả các đối tượng trong hệ thống. Điều này đòi
hỏi thời gian và một lưu lượng truyền thông rất lớn.
Trong các hệ thống ban đầu được triển khai, mô hình phân cấp đã được ưu tiên sử dụng.
Tuy nhiên, phiên bản 3.0 của các thẻ xác nhận đã có những phần mở rộng hỗ tr
ợ quá
trình xác nhận không theo mô hình phân cấp. Do vậy, mô hình phân cấp ngày càng ít
được sử dụng.