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 đượ
Trang 1QMỤ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ÁIQUÁT 8
1.2.CÁCDỊCHVỤVÀPHẠMVIỨNGDỤNGCỦAPKI 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ĐỐITƯỢNGCƠBẢNCỦAHỆTHỐNGPKI 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ÁCHOẠTĐỘNGCƠBẢNTRONGHỆTHỐNGPKI 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ẤUTRÚCCỦACÁCTHÔNGĐIỆPPKI 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
Trang 2Mụ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ÁCMÔHÌNHTRIỂNKHAIHỆTHỐNGPKI 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ỮNGCHỨCNĂNGBẮTBUỘCTRONGQUẢNLÝ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ÁCTRƯỜNGCƠBẢNCỦATHẺXÁCNHẬ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ẤUTRÚCTBSCERTIFICATE 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ÁCPHẦNMỞRỘNGCỦATHẺXÁCNHẬNX.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
Trang 33.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ÔITRƯỜNG,CÔNGCỤ,MÔHÌNH,CHỨCNĂ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ÂNTÍCHTHIẾTKẾCHỨCNĂNGCHITIẾ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ẬPTRÌNHTHỰCTHIHỆTHỐNGPKI 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
Trang 4Mụ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.ĐÁNHGIÁVỀNHỮNGKẾTQUẢNGHIÊNCỨULÝTHUYẾT 71
5.2.ĐÁNHGIÁVỀ NHỮNG CHỨCNĂNGĐÃXÂYDỰ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
Trang 5CÁ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 đó
(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ỏ
Trang 6Cá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
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
(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
Trang 7ĐẶ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
Trang 8Dong Manh Quan Trang 8 23/08/2005
Phần 1
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:
Trang 91 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
Trang 10Tổ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
Trang 114 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
Trang 12Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
12
RA có thể được coi là một thành phần không bắt buộc Tuy nhiên, khi RA đứng độc lập
thì CA phải đảm nhận những chức năng trên Nghĩa là các chức năng mà CA có được
cho các đối tượng phải giống như trong trường hợp CA và RA đứng độc lập
Về bản chất, RA cũng là một đối tượng sử dụng Tất cả các RA đều được xác nhận và có
các khoá riêng dùng trong việc tạo chữ ký số cho các thông tin mà nó cấp phát Trong
một số trường hợp, các đối tượng sử dụng có thể liên hệ trực tiếp với CA quản lý mình
mặc dù trong hệ thống vẫn có mặt RA Ví dụ, trong các thủ tục đăng ký và xác nhận ban
đầu, nó phải liên hệ trực tiếp với CA để cập nhật thông tin về thẻ xác nhận của mình
1.4 CÁC HOẠT ĐỘNG CƠ BẢN TRONG HỆ THỐNG PKI
1.4.1 Mô hình tổng quát của hệ thống PKI
Trong sơ đồ dưới đây là các đối tượng của hệ thống PKI và mối quan hệ giữa chúng trên
cơ sở các hoạt động quản lý PKI Mối liên hệ được thể hiện bằng các thông điệp được
truyền đi giữa các đối tượng trong hệ thống
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 lưu tr÷
CA1
CA2
Hình 1-2 Các đối tượng và hoạt động cơ bản trong hệ thống PKI
Dựa trên các thông điệp được định nghĩa (sẽ được trình bày chi tiết trong các phần sau)
và xét ở một mức khái quát, các hoạt động của hệ thống quản lý PKI có thể được phân
thành các nhóm sau:
1.4.2 Thiết lập các thẻ xác nhận
Các thẻ xác nhận được tạo ra trên cơ sở một số thông tin cơ bản (đối tượng phát hành,
đối tượng sử dụng, thuật toán tạo chữ ký số, thời hạn lưu hành …) và một số thông tin
mở rộng Song song với quá trình tạo ra một thẻ xác nhận mới, ta cũng cần tiến hành một
số bước phụ trợ Ta có thể kể đến việc tạo lập hoặc cập nhật danh sách các thẻ bị huỷ
bỏ, việc đăng tải thông tin về khoá công khai của CA, lưu thẻ xác nhận vừa tạo được…
1.4.3 Khởi tạo các EE
Quá trình này đòi hỏi một số bước cơ bản như sau: Trước tiên, đối tượng này phải thu
thập được thông tin về khoá công khai của CA gốc Điều này giúp cho các thông điệp
Trang 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
Trang 14Tổ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ố
Trang 15phươ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 }
Trang 16Tổ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
Trang 17trườ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,
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
Trang 18Tổ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
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 {
Nội dung tuỳ thuộc vào loại khoá được sử dụng
OPTIONAL}
Trang 19Các thông tin liên quan đến quá trình phát hành
CertTemplate ::= SEQUENCE {
OptionalValidity ::= SEQUENCE {
Ít nhất một trong hai trường phải tồn tại
Controls ::= SEQUENCE SIZE(1 MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
Tập các bit được sử dụng để tăng độ an toàn cho thông điệp
Số hiệu của thuật toán phân tách một chiều (thường là SHA-1)
Trang 20Tổng quan về PKI HẠ TẦNG KHOÁ CÔNG KHAI
20
POPOPrivKey ::= CHOICE {
Thông điệp minh chứng cho sự sở hữu đối với một khoá riêng nào đó
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
Đượ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
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á
Trang 211.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,
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ỏ
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,
Trang 22Tổ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ỏ
Các CRL có liên quan
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:
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:
Thông tin chi tiết về các CRL
Trang 23CA 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,
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
Trang 24Dong Manh Quan Trang 24 23/08/2005
¾ 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
EE
EE (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 CA4 cấp, do vậy A kiểm tra thẻ xác nhận của CA4; thẻ xác nhận của CA4 lại do
Trang 25CA2 cung cấp nên A lại kiểm tra thẻ xác nhận của CA2; thẻ xác nhận của CA2 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
Trang 26Những vấn đề cơ bản trong xây dựng hệ thống PKI HẠ TẦNG KHOÁ CÔNG KHAI
26
2.1.2 Kiến trúc hệ thống PKI mạng lưới
Trong kiến trúc này, việc các CA thực hiện xác nhận ngang hàng đã tạo nên một mạng
lưới các mối quan hệ tin cậy lẫn nhau giữa các CA ngang hàng Các đối tượng nắm được
khoá công khai của CA nằm “gần” mình nhất Thông thường, đây là CA cấp cho đối
tượng đó thẻ xác nhận Các đối tượng kiểm chứng một thẻ xác nhận bằng cách kiểm tra
quá trình xác nhận với đích là CA đã phát hành thẻ xác nhận đó
Các CA sẽ xác nhận ngang hàng bằng cách phát hành cho nhau những thẻ xác nhận,
những cặp thẻ xác nhận này được kết hợp và lưu trong một cấu trúc dữ liệu có tên:
CrossCertificatePair Trong sơ đồ dưới đây, A có thể xác nhận B theo nhiều nhánh khác
nhau Theo nhánh ngắn nhất, B được CA4 cấp thẻ xác nhận nên nó được xác nhận bở
CA4 CA4 được xác nhận ngang hàng bởi CA5 và CA5 lại được xác nhận ngang hàng bởi
CA3 A được CA3 cấp phát thẻ xác nhận và biết được khoá công khai của CA3 nên nó có
EE (A)
EE
EE EE EE (B)
EE
EE
Hình 2-2 Kiến trúc PKI mạng lưới 2.1.2.1 Ưu điểm của kiến trúc PKI mạng lưới
1 Đây là một kiến trúc linh động, nó thích hợp với các mối liên hệ và mối quan hệ tin
cậy lẫn nhau trong thực tế của công việc kinh doanh
2 Một đối tượng sử dụng ít nhất phải tin cậy CA cấp phát thẻ xác nhận cho nó Có
thể coi đây là cơ sở để tạo nên tất cả các mối quan hệ tin tưởng lẫn nhau
3 Các CA có thể xa nhau trong mô hình tổ chức nhưng những đối tượng sử dụng
của nó lại làm việc cùng nhau với mức ưu tiên cao có thể xác nhận ngang hàng
theo một cách thức có độ ưu tiên cao Độ ưu tiên này chỉ được giới hạn trong
phạm vi của các CA này
4 Kiến trúc này cho phép các CA có thể xác nhận ngang hàng một cách trực tiếp
trong trường hợp các đối tượng sử dụng của chúng liên lạc với nhau thường
xuyên để giảm tải lượng đường truyền và thao tác xử lý
Trang 275 Việc khôi phục hệ thống do khoá riêng của một CA bị tiết lộ sẽ chỉ gồm việc phân
phát một cách an toàn khoá công khai mới của CA đến các đối tượng mà CA này
cấp phát thẻ xác nhận
2.1.2.2 Nhược điểm của mô hình PKI mạng lưới
1 Do cấu trúc của mạng có thể rất phức tạp nên việc tìm kiếm các đối tượng rất khó
khăn Trong trường hợp có nhiều đường truyền đến một đối tượng khác thì bài
toán tìm đường đi ngắn nhất đến đối tượng đó có thể rất phức tạp
2 Một đối tượng không thể đưa ra một nhánh xác nhận duy nhất mà có thể đảm bảo
tất cả các đối tượng khác trong hệ thống có thể thực hiện được
2.1.3 Kiến trúc danh sách tin cậy
Đây là kiến trúc được áp dụng rộng rãi đối với dịch vụ Web Trong đó, các trình duyệt và
các máy chủ là những đối tượng sử dụng tiêu biểu nhất Trong mô hình này, các trình
duyệt đều lưu một file riêng chứa các thẻ xác nhận gốc của các CA được tin cậy File này
tồn tại ngay khi trình duyệt được cài đặt Việc quản lý file này có thể được thực hiện bởi
các cá nhân sử dụng trình duyệt Các tổ chức cũng có thể cấp quyền cho việc tải hoặc
quản lý các thông tin từ một máy chủ của tổ chức Đối với mỗi file này, người sử dụng có
thể bổ sung hoặc xóa bớt những thẻ xác nhận khỏi danh sách Tuy nhiên, khả năng xử lý
cách nhánh xác nhận của các ứng dụng hiện còn khá hạn chế
Các trình duyệt có thể sử dụng các cặp khóa công khai/khoá riêng để ký, để kiểm chứng,
giải mã hoặc mã hoá các thư điện tử theo chuẩn S/MIME Với các thẻ xác nhận, các trình
duyệt cũng có thể thiết lập các phiên truyền thông an toàn SSL (Secure Sockets Layer)
SSL là một giao thức xác thực và mã hoá ở tầng chuyển vận Trong một phiên truyền
thông SSL, người dùng có thể gửi đi một mẫu biểu hoặc nhận về các thông tin từ một
máy chủ dưới hình thức được mã hoá và xác thực Mặt khác, các trình duyệt còn có thể
kiểm chứng các chữ ký số được áp dụng đối với thông tin được truyền đi
Hình 2-3 Kiến trúc PKI danh sách tin cậy
Như vậy, ta có thể coi kiến trúc PKI danh sách tin cậy là một mô hình hướng trình duyệt
2.1.3.1 Ưu điểm của kiến trúc PKI danh sách tin cậy
1 Đây là kiến trúc đơn giản, quá trình truyền thông và xác nhận theo một hướng duy
nhất, hơn nữa, mô hình này có thể được triển khai khá dễ dàng
Trang 28Những vấn đề cơ bản trong xây dựng hệ thống PKI HẠ TẦNG KHOÁ CÔNG KHAI
28
2 Trong kiến trúc này này, các đối tượng sử dụng có toàn quyền quản lý file lưu trữ
danh sách thẻ xác nhận của các CA mà mình tin cậy
3 Kiến trúc này có thể làm việc rất tốt với giao thức quản lý trạng thái thẻ xác nhận
trực tiếp do các nhánh xác thực khá đơn giản Hơn nữa, những yêu cầu về trạng
thái thẻ xác nhận chỉ được gửi tới các CA ở trong danh sách các CA được tin cậy
2.1.3.2 Nhược điểm của kiến trúc PKI danh sách tin cậy
1 Người sử dụng có toàn quyền nội dung của file chứa thẻ xác nhận của các CA mà
nó tin cậy Do vậy việc quản lý danh sách các CA được tin cậy của một tổ chức là
rất khó khăn
2 Việc khởi tạo danh sách mặc địch các CA được tin cậy khi cài đặt một trình duyệt
sẽ dẫn đến việc khó đảm bảo tính xác thực trong quá trình khởi tạo thông tin về
khoá công khai của các CA này Đây có thể là một kẽ hở để các đối tượng tấn
công lợi dụng
3 Không phải tất cả những người sử dụng đều có khả năng quản lý tốt một file chứa
quá nhiều thẻ xác nhận của các CA mà mình tin cậy
4 Cấu trúc thẻ xác nhận không có nhiều hỗ trợ cho việc tìm ra các nhánh xác nhận
5 Không có những hỗ trợ trực tiếp đối với các cặp thẻ xác nhận ngang hàng Do
vậy, nó hạn chế khả năng của CA trong quản lý sự tin cậy của mình đối với các
Tóm lại, ưu điểm đáng kể nhất của kiến trúc danh sách tin cậy là khả năng hỗ trợ đối với
định dạng dữ liệu S/MIME và các phiên truyền thông SSL đối với các trình duyệt hiện nay
Dịch vụ World Wide Web và các trình duyệt là những đối tượng cơ bản trong công nghệ
mạng hiện nay, nó cũng là nền tảng để phát triển các trình ứng dụng phân tán
Hiện nay, các máy chủ Web đều hỗ trợ kiến trúc PKI theo danh sách tin cậy, bất kể ai
muốn phát triển các ứng dụng PKI cho một lượng lớn đối tượng sử dụng đều phải ý thức
được điều này Hơn nữa, công nghệ Web hiện đang là một hướng lựa chọn phổ biến cho
các ứng dụng trong phạm vi các mạng cục bộ Như vậy, với sự hiện diện của các trình
duyệt ở khắp mọi nơi và một vị trí quan trọng của chúng để xây dựng các ứng dụng
mạng, đây thực sự là một kiến trúc quan trọng trong số các kiến trúc được áp dụng để
xây dựng các hệ thống PKI
Trang 292.2 NHỮNG CHỨC NĂNG BẮT BUỘC TRONG QUẢN LÝ PKI
Các hoạt động của hệ thống quản lý PKI đã được mô tả trong phần tổng quan về PKI
Trong phạm trù triển khai hệ thống PKI, ta cần tìm hiểu những chức năng mà hệ quản lý
PKI bắt buộc phải có Mặt khác, để đề ra những phần công việc cần lập trình thực thi
trong đồ án thực tập này, ta sẽ lấy những chức năng này làm cơ sở để lập trình thực thi
một hệ thống PKI (gồm CA và EE) với các chức năng tối thiểu Những chức năng bắt
buộc đối với hệ thống quản lý PKI gồm có:
2.2.1 Khởi tạo CA gốc
Khi một CA mới tham gia vào hệ thống PKI, nó phải tạo ra các thẻ xác nhận theo kiểu tự
ký (self-signed) Các thẻ xác nhận này được ký với khoá riêng của CA gốc đó và trường
mô tả cho kiểu thẻ xác nhận là NewWithNew Nghĩa là, thẻ xác nhận được cấp lần đầu
cho các đối tượng trong hệ thống Kiểu thẻ xác nhận này cũng được dùng khi CA muốn
gửi thẻ xác nhận đến cho một đối tượng mới tham gia hệ thống Thông điệp chứa thẻ xác
nhận này được gửi đi sau khi CA thực hiện công việc cập nhật khoá công khai của mình
Đồng thời với việc tạo và gửi đi các thẻ xác nhận của mình đến cho các đối tượng trong
hệ thống, CA gốc cũng phải tạo danh sách các thẻ xác nhận cần huỷ bỏ (CRL) và lưu các
thẻ xác nhận đã gửi đi vào danh sách này Đây chính là cơ sở để CA huỷ bỏ các khoá và
thực hiện các phiên cập nhật khoá của mình
2.2.2 Cập nhật khoá của CA gốc
Các khoá của CA đều có thời gian hiệu lực nhất định nên chúng cần phải được cập nhật
theo định kỳ Thời gian hiệu lực của khoá sẽ tuỳ thuộc vào các chính sách được thiết lập
đối với hệ thống PKI Các thẻ xác nhận theo kiểu NewWithNew, NewWithOld, và
OldWithNew được CA phát hành và gửi đến cho các đối tượng sử dụng đã có mặt trong
hệ thống Những đối tượng này đang nắm giữ thẻ xác nhận cũ của CA (kiểu OldWithOld),
khi nhận được các thẻ xác nhận mới gửi đến từ CA, có thể chuyển sang các thẻ xác nhận
mới theo kiểu NewWithNew một cách an toàn Ngoài ra, hoạt động này của CA gốc còn
giúp cho các đối tượng sử dụng mới (những đối tượng sẽ nhận được thẻ xác nhận kiểu
NewWithNew) có thể thu được thẻ xác nhận kiểu OldWithOld một cách an toàn, điều này
sẽ giúp cho đối tượng sử dụng mới có thể kiểm tra các dữ liệu đã có (dữ liệu có thể được
kiểm tra bởi khoá công khai trong các thông điệp kiểu OldWithOld)
2.2.3 Khởi tạo các CA thứ cấp
Nếu xét trên phương diện các giao thức quản lý, việc khởi tạo một CA thứ cấp cũng giống
với việc khởi tạo một EE Điểm khác biệt duy nhất là các CA thứ cấp cũng phải khởi tạo
một CRL của mình
2.2.4 Tạo lập CRL
Trước khi phát hành và gửi đi các thẻ xác nhận, một CA mới được khởi tạo phải tạo ra
các CRL trống để chuẩn bị cho việc bổ sung các thẻ xác nhận cần huỷ bỏ Các CRL này
cũng sẽ được cập nhật thông tin định kỳ theo thời gian hiệu lực của các thẻ xác nhận
Trang 30Những vấn đề cơ bản trong xây dựng hệ thống PKI HẠ TẦNG KHOÁ CÔNG KHAI
30
2.2.5 Yêu cầu về thông tin hệ thống PKI
Khi một đối tượng trong hệ thống PKI (CA, RA hoặc EE) muốn có được thông tin trạng
thái của một CA nào đó, đối tượng này có thể gửi cho CA đo một yêu cầu về các thông tin
trên CA nhận được yêu cầu phải trả lời bằng việc cung cấp ít nhất là các thông tin đã
được yêu cầu Nếu có một số trường thông tin nào đó không thể được đáp ứng thì phải
có một thông điệp báo lỗi gửi về cho đối tượng yêu cầu
2.2.6 Xác nhận ngang hàng
Trong giao thức của việc xác nhận ngang hàng, CA yêu cầu sẽ là CA có tên trong trường
subject của thẻ xác nhận (CA được cấp phát thẻ xác nhận) Trong khi đó, CA trả lời sẽ
chính là CA đã phát hành thẻ xác nhận này Quá trình xác nhận ngang hàng là cần thiết
khi các CA muốn trao đổi thông tin với nhau vì nó giúp các CA biết chắc mình đang trao
đổi thông tin với đối tượng nào
2.2.7 Khởi tạo các EE
Cũng giống như các CA, những EE cũng phải được khởi tạo khi tham gia vào hệ thống
PKI Quá trình khởi tạo cho các đối tượng này bao gồm ít nhất 2 bước sau:
2.2.7.1 Thu thập thông tin về hệ thống PKI
Trong thủ tục này, ta cần có những thông tin sau đây:
1 Khoá công khai của CA gốc
2 Nhánh xác nhận từ CA gốc đến CA đang quản lý đối tượng này cùng với các CRL
có liên quan (trường hợp CA quản lý đối tượng không phải là CA gốc)
3 Những thuật toán và các tham số của thuật toán mà CA quản lý hỗ trợ trong các
mục đích sử dụng có liên quan
2.2.7.2 Kiểm tra khoá công khai của CA gốc
Một EE phải có được khoá công khai của CA gốc một cách an toàn Một trong số các
phương thức hiệu quả để đảm bảo yêu cầu này là việc sử dụng các thẻ xác nhận tự ký và
được trao đổi qua các phương tiện out-of-band Sau khi nhận được thẻ xác nhận này từ
CA gốc, các EE có thể sử dụng những thẻ xác nhận này một cách an toàn
2.2.8 Yêu cầu xác nhận
Một EE sau khi khởi tạo có thể sẽ yêu cầu một thẻ xác nhận vào bất kỳ thời điểm nào
Yêu cầu này được truyền tải bởi thông điệp yêu cầu thẻ xác nhận (CR) Nếu đối tượng đã
có một cặp khoá để tạo chữ ký thì thông điệp yêu cầu sẽ được bảo vệ bằng cách thực
hiện phương thức chữ ký số đối với nó Nếu yêu cầu được chấp nhận, CA sẽ trả về cho
đối tượng sử dụng một thẻ xác nhận mới
2.2.9 Cập nhật khoá
Khi cặp khoá của một EE không còn hiệu lực nữa, đối tượng này có thể yêu cầu được
cập nhật cặp khoá của mình bằng một cặp khoá mới Yêu cầu này được truyền tải bởi
Trang 31thông điệp yêu cầu cập nhật khoá (KUR) Nếu EE đã có một cặp khoá tạo chữ ký thì
thông điệp yêu cầu này sẽ được bảo vệ thông qua phương thức chữ ký số Nếu yêu cầu
được chấp thuận thì CA sẽ trả về một thông điệp trả lời yêu cầu cập nhật khoá (KUP) có
chứa một thẻ xác nhận mới cho đối tượng
Trang 32Dong Manh Quan Trang 32 23/08/2005
3.1 CÁC TRƯỜNG CƠ BẢN CỦA THẺ XÁC NHẬN
Một thẻ xác nhận theo chuẩn X.509 phiên bản 3.0 là một dãy các cấu trúc gồm có 3 trường được mô tả như sau:
Certificate ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier, Thuật toán tạo chữ ký số
Sau đây, ta sẽ tìm hiểu cấu trúc và vai trò của từng trường cơ bản trên của thẻ xác nhận
3.1.1 Trường tbsCertificate
Trường này chứa những thông tin cơ bản nhất của thẻ xác nhận Trong đó, ta có thể kể đến tên của đối tượng phát hành, tên của đối tượng sử dụng, thời hạn hiệu lực và những thông tin khác có liên quan Trong các phần sau, ta sẽ tìm hiểu kỹ hơn về các trường thông tin này
3.1.2 Trường signatureAlgorithm
Trường này chứa tên của thuật toán mã hoá mà CA sử dụng để thức hiện phương thức chữ ký số đối với thẻ xác nhận Trong thực tế, ta thường sử dụng một số thuật toán tạo chữ ký số phổ biến như: RSA, DSS Theo chuẩn ASN.1, cấu trúc định danh cho một thuật toán mã hoá được mô tả như sau:
AlgorithmIdentifier ::= SEQUENCE {
Trong cấu trúc này, trường algorithm được sử dụng để lưu số hiệu của thuật toán được
sử dụng Trong thực tế, đây là một chuỗi các số theo quy định để mô tả tên các thuật toán Ta có một ví dụ như sau: “1.2.840.10040.4.3”, đây là một chuỗi chỉ ra thuật toán
được sử dụng là thuật toán DSA với hàm phân tách một chiều dsaWithSha1
Trang 33Trường parameters được sử dụng để lưu các tham số cho các thuật toán mã hoá Nội
dụng của trường này tuỳ thuộc vào từng loại thuật toán mã hoá được sử dụng
3.1.3 Trường signatureValue
Đây là trường được tạo ra sau khi CA thực hiện phương thức chữ ký số đối với trường
tbsCertificate Trong thực tế, ta phải đóng gói thẻ xác nhận trước khi thực hiện phương
thức chữ ký số với thẻ xác nhận đó
Bằng việc thực hiện phương thức chữ ký số với thẻ xác nhận, CA có thể đảm bảo cho
các trường thông tin có trong thẻ xác nhận Cụ thể hơn, CA đã đảm bảo cho mối ràng
buộc giữa đối tượng sở hữu thẻ và khoá chung đi kèm với thẻ đó Đây chính là yêu cầu
lớn nhất đối với thẻ xác nhận Sau đây, ta sẽ tìm hiểu các cấu trúc của các trường cơ bản
đã nêu trên
3.2 CẤU TRÚC TBSCERTIFICATE
Cấu trúc này cho phép ta lưu các thông tin liên quan đến đối tượng sử dụng và đối tượng
phát hành thẻ xác nhận như đã nói ở trên Các trường của cấu trúc này gồm có:
Các trường của cấu trúc TBSCertificate được mô tả như sau:
3.2.1 Trường version
Trường này chỉ ra phiên bản của thẻ xác nhận đã được mã hoá Trong trường hợp thẻ
xác nhận có dùng đến các trường mở rộng thì phiên bản của thẻ xác nhận bắt buộc phải
là 3 (giá trị là 2) Nếu không có các trường mở rộng nhưng lại có những trường định danh
cho đối tượng sử dụng và đối tượng phát hành thì phiên bản của thẻ xác nhận có thể là 2
(giá trị là 1) Tuy nhiên, trong trường hợp này ta vẫn có thể sử dụng phiên bản 3
3.2.2 Trường serialNumber
Trường này bắt buộc phải là một số nguyên dương Nó được CA gán cho mỗi thẻ xác
nhận khi CA tạo và thực hiện phương thức chữ ký số đối với thẻ vừa tạo được CA phải
đảm bảo số hiệu này phải là duy nhất đối với mỗi thẻ xác nhận được tạo ra Để đảm bảo
yêu cầu về tính duy nhất của số hiệu thẻ xác nhận, trường biểu diễn số hiệu này có thể là
các số nguyên lớn Chuỗi số biểu diễn có thể có độ dài lên tới 20 byte
Trang 34Thẻ xác nhận theo chuẩn X.509 HẠ TẦNG KHOÁ CÔNG KHAI
34
3.2.3 Trường signature
Trường này chứa định danh của thuật toán mã hoá mà CA sử dụng để tạo chữ ký số cho
thẻ xác nhận Số hiệu của thuật toán lưu trong trường này phải giống với số hiệu của
thuật toán lưu trong trường signatureAlgorithm
3.2.4 Trường issuer
Trường này chỉ ra đối tượng nào đã tạo ra thẻ xác nhận, tạo chữ ký số ứng với thẻ xác
nhận và phát hành nó Trường này bắt buộc phải mang tên CA đã phát hành ra nó
Trường này có cấu trúc như sau:
RelativeDistinguishedName ::= SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
Như vậy, trường issuer được biểu diễn bởi một đối tượng có tên Name Đối tượng này
biểu diễn tên theo các mức dựa trên các thuộc tính Ví dụ, tên nước ta có giá trị là
Vietnam Giá trị của thành phần AttributeValue được quyết định bởi AttributeType và nó
thường có giá trị kiểu DirectoryString Kiểu dữ liệu này có thể có nhiều lựa chọn khác
nhau, tuỳ theo trường hợp cụ thể mà ta có lựa chọn phù hợp Hiện nay, trong các ứng
dụng mail và WWW, ta thường sử dụng kiểu UTF8String
Trong biểu diễn phân cấp đối với các đối tượng sử dụng và đối tượng phát hành thẻ xác
nhận, ta có một số giá trị thuộc tính chuẩn như sau:
1 Tên nước - country
2 Tên tổ chức - organization
3 Tên đơn vị - organizational-unit
4 Cấp bậc - distinguished name qualifier
5 Tên tỉnh hoặc bang - state or province name
6 Tên thường gọi - common name
7 Số hiệu - serial number
Trang 35Đây là những trường chuẩn và đã được sử dụng rộng rãi như những thể hiện của chuẩn
về tổ chức thư mục X.500 Ngoài ra, ta cũng cần lưu ý để đảm bảo hệ thống PKI có thể
bao hàm một số thuộc tính sau:
1 Nơi cư trú - locality
2 Chức danh - title
4 Tên - given name
5 Các chữ cái đầu của tên - initials
6 Biệt danh - pseudonym
7 Thế hệ - generation qualifier (Ví dụ, "Jr.", "3rd", hay "IV")
3.2.5 Trường validity
Trường thông tin về thời gian hiệu lực của thẻ xác nhận là trường đánh dấu khoảng thời
gian mà trong đó CA đảm bảo việc cập nhật thông tin về thẻ xác nhận đó Trường này
chứa hai biến lưu thời điểm thẻ xác nhận bắt đầu có hiệu lực và thời điểm thẻ hết hiệu
lực Cả hai thời hạn đều có cùng kiểu dữ liệu là UTCTime nếu biểu diễn thời gian đến
trước năm 2049, nếu thời gian biểu diễn là từ năm 2050 trở đi thì ta phải dùng kiểu
GeneralizedTime
3.2.6 Trường subject
Trường subject chỉ ra đối tượng tương ứng với khoá công khai được lưu trong thẻ xác
nhận này Nói cách khác, nó chỉ ra đối tượng sử dụng của thẻ xác nhận Tên của đối
tượng sử dụng có thể được nêu ngay trong trường subject mà cũng có thể được nêu
trong trường mở rộng subjectAltName
Nếu đối tượng sử dụng là một CA thì tên được nêu trong trường subject phải giống với
tên được nêu trong trường issuer của tất cả các thẻ xác nhận mà CA này phát hành
Ngoài ra, nếu CA này đảm nhận việc phát hành và quản lý danh sách các thẻ sẽ bị huỷ
bỏ thì trường thông tin issuer trong các danh sách mà CA phát hành cũng phải giống với
tên trong trường subject này
3.2.7 Trường subjectPublicKeyInfo
Trường này được sử dụng để lưu trữ khoá công khai và thuật toán sử dụng khoá này
(RSA, DSA, Diffie-Hellman) Thuật toán được xác định thông qua cấu trúc
AlgorithmIdentifier đã nêu trên
3.2.8 Trường uniqueIdentifiers
Trường này chỉ bắt buộc phải tồn tại khi thông điệp có phiên bản là 2 hoặc 3 Ta không
được phép sử dụng khi phiên bản là 1 Định danh đơn nhất của các đối tượng sử dụng
và các đối tượng phát hành cho phép ta xử lý được các trường hợp dùng lại các tên của
đối tượng trong hệ thống qua những khoảng thời gian khác nhau
Trang 36Thẻ xác nhận theo chuẩn X.509 HẠ TẦNG KHOÁ CÔNG KHAI
36
3.2.9 Trường extensions
Trường này chỉ có trong các thẻ xác nhận phiên bản thứ 3 trở đi Nếu tồn tại thì trường
này sẽ chứa một dãy các trường mở rộng của thẻ xác nhận Trong phần sau đây, ta sẽ
nghiên cứu về cấu trúc và đặc điểm của từng trường mở rộng
3.3 CÁC PHẦN MỞ RỘNG CỦA THẺ XÁC NHẬN X.509
Các phần mở rộng của thẻ xác nhận theo chuẩn X.509 phiên bản 3 được định ra nhằm
bổ sung thêm một số thuộc tính đối với các đối tượng sử dụng cùng với khoá chung của
mình Đồng thời, nó cũng hỗ trợ thêm cho quá trình xác nhận theo mô hình phân cấp
Định dạng của thẻ xác nhận X.509 cũng cho phép từng nhóm đối tượng truyền thông định
ra các phần mở rộng riêng cho phạm vi của nhóm
Mỗi phần mở rộng của thẻ xác nhận sẽ được đánh dấu là critical hay non-critical tùy
thuộc vào nội dung mà trường đó lưu trữ Ví dụ, một đối tượng sử dụng sẽ không chấp
nhận một thẻ xác nhận mà trong phần mở rộng của thẻ lại không có một trường mở rộng
bắt buộc nào đó Mỗi phần mở rộng đều có một số hiệu riêng Số hiệu này được định ra
theo chuẩn ASN.1 Sau đây ta sẽ nghiên cứu từng trường mở rộng cụ thể
3.3.1 Phần mở rộng Authority Key Identifier
Phần mở rộng này cho phép ta xác định được khoá công khai của một đối tượng dựa trên
khoá riêng mà đối tượng này đã sử dụng để tạo chữ ký số đối với các thẻ xác nhận Nó
được sử dụng khi một đối tượng có nhiều cặp khoá để tạo chữ ký số Để có thể xác định
được khoá công khai của một đối tượng có thể phải sử dụng đến số hiệu khoá, tên của
đối tượng sở hữu khoá và số seri của thẻ xác nhận được ký bằng khoá đó
Trong một hệ thống được triển khai với khả năng xác định khoá công khai của các đối
tượng, phần này nên được sử dụng Tuy nhiên, trong phần thông tin về các trường thì ta
không được phép đánh dấu phần này là critical Cấu trúc của và định danh của phần mở
rộng này được mộ tả như sau:
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
KeyIdentifier ::= OCTET STRING
3.3.2 Phần mở rộng Subject Key Identifier
Trường này cho phép ta tìm ra những thẻ xác nhận chứa một khoá công khai nào đó Đối
với thẻ xác nhận của các EE, trường này cho phép ta định ra được những thẻ xác nhận
có chứa một khoá công khai được sử dụng trong một trình ứng dụng nào đó Trong
trường hợp đối tượng sử dụng thu nhận được nhiều thẻ xác nhận từ nhiều CA khác nhau
thì trường thông tin này cho phép ta nhanh chóng tìm ra được một tập các thẻ xác nhận
có chứa khoá công khai nhất định
Để hỗ trợ các trình ứng dụng trong việc định ra một thẻ xác nhận nào đó của đối tượng
sử dụng, trường này nên được sử dụng trong tất cả các thẻ xác nhận Việc định ra giá trị
Trang 37cho trường thông tin này thường được dựa trên khoá công khai tương ứng và các hàm
phân tách một chiều Cấu trúc của trường này được mô tả như sau:
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
3.3.3 Phần mở rộng Key Usage
Trường này cho ta biết được mục đích của khoá được lưu trong thẻ xác nhận Những
hạn chế trong việc sử dụng có thể được thực hiện khi ta không muốn một khoá có thể
được sử dụng trong nhiều hoạt động khác nhau Ví dụ, một khoá RSA chỉ nên được sử
dụng trong việc kiểm định chữ ký đối với các thẻ xác nhận hay danh sách các thẻ xác
nhận bị huỷ bỏ
Trường này phải được sử dụng nếu khoá công khai trong thẻ xác nhận được sử dụng để
kiểm định chữ ký số được thực hiện với các thẻ xác nhận khác Khi được sử dụng,
trường này cần được đánh dấu là critical Cấu trúc của trường này với các dạng thông tin
được mô tả như sau:
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
3.3.4 Phần mở rộng Private Key Usage Period
Trường mở rộng này cho phép đối tượng phát hành thẻ xác nhận định ra khoảng thời
gian hợp lệ của một khoá riêng khác với thời gian hợp lệ của thẻ xác nhận tương ứng
Trường mở rộng này được tạo ra để phục vụ cho các khoá của dịch vụ chữ ký số Cũng
giống như trường định ra khoảng thời gian hợp lệ của thẻ xác nhận, phần mở rộng này
cũng gồm hai thành phần định ra thời điểm bắt đầu và thời điểm kết thúc của khoảng thời
gian hợp lệ Nghĩa là, khoá riêng ứng với thẻ xác nhận sẽ không được phép dùng để tạo
các chữ ký số trước và sau khoảng thời gian này
Khi được sử dụng, phần mở rộng này được biểu diễn dưới dạng GeneralizedTime
(YYYYMMDDHHMMSSZ) Tuy nhiên, phần mở rộng này thường không được sử dụng
trong hệ thống PKI ở phạm vi Internet Trong trường hợp được sử dụng, các CA tạo thẻ
xác nhận không được phép đánh dấu phần này là critical Định danh và cấu trúc của phần
mở rộng này được biểu diễn như sau:
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
PrivateKeyUsagePeriod ::= SEQUENCE {
Trang 38Thẻ xác nhận theo chuẩn X.509 HẠ TẦNG KHOÁ CÔNG KHAI
38
3.3.5 Phần mở rộng Certificate Policies
Phần mở rộng này chứa một hoặc một tập hợp các điều khoản của thông tin về chính
sách đối với thẻ xác nhận Trong một thẻ xác nhận của đối tượng sử dụng, các điều
khoản của thông tin chính sách được dùng để nêu rõ thẻ xác nhận đã được tạo ra trong
hoàn cảnh nào và thẻ xác nhận sẽ được sử dụng trong những mục đích gì Trong một thẻ
xác nhận của CA, những điều khoản này sẽ giới hạn các nhánh xác nhận được lưu trong
thẻ xác nhận này Trong trường hợp CA không muốn có một giới hạn nào đối với các
nhánh xác nhận thì nó có thể gán cho phần mở rộng này một chính sách đặc biệt gọi là
anyPolicy, với giá trị “2.5.29.32.0”
Mỗi trình ứng dụng đều cần phải có một danh mục các chính sách mà nó chấp nhận;
đồng thời, nó phải có khả năng đối chiếu số hiệu của các chính sách trong một thẻ xác
nhận nào đó với các số hiệu của những chính sách trong danh mục này Nếu được sử
dụng và được đánh dấu là critical thì trình ứng dụng bắt buộc phải hiểu được thông tin
của phần mở rộng này, nếu không, phải loại bỏ thẻ xác nhận tương ứng
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
certificatePolicies ::= SEQUENCE SIZE (1 MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyQualifiers SEQUENCE SIZE (1 MAX) OF PolicyQualifierInfo OPTIONAL}
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
Số hiệu các chính sách áp dụng cho Internet
PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
DisplayText ::= CHOICE {
3.3.6 Phần mở rộng Policy Mappings
Phần mở rộng này được dùng trong các thẻ xác nhận của các CA Nó được dùng để ánh
xạ thông tin về các chính sách trong trường hợp CA phát hành và CA sử dụng thuộc hai
Trang 39domain khác nhau (Inter-Domain) Việc ánh xạ được thực hiện thông qua số hiệu của các
chính sách ở hai CA
Các đối tượng sử dụng của CA phát hành thẻ xác nhận sẽ chấp nhận một số chính sách
do CA này đề ra (issuerDomainPolicy) trong một số trình ứng dụng nhất định Việc ánh xạ
chính sách sẽ định ra danh mục các chính sách ở phía CA sử dụng thẻ xác nhận cũng
được chấp nhận tương đương với các chính sách thuộc issuerDomainPolicy
Phần mở rộng này có thể được hỗ trợ bởi các trình ứng dụng hoặc các CA Khi được sử
dụng, nó phải được đánh dấu là non-critical Số hiệu và cấu trúc của phần mở rộng này
được mô tả như sau:
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE (1 MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
3.3.7 Phần mở rộng Subject Alternative Name
Phần mở rộng này cho phép gắn thêm những định danh cho đối tượng sử dụng của thẻ
xác nhận Các loại định danh này được dùng trong cấc loại dịch vụ khác nhau và có định
dạng phù hợp với mỗi loại dịch vụ ấy Do những tên khác nhau của đối tượng sử dụng
được coi là có liên hệ chặt chẽ với khoá công khai của thẻ nên tất cả các tên này phải
được kiểm chứng bới CA cấp phát thẻ xác nhận
Trong trường hợp đối tượng sử dụng không được nêu ra trong trường subject của thẻ
xác nhận thì phần mở rộng này bắt buộc phải được sử dụng Và khi đó, ta phải đánh dấu
trường này là critical Sau đây, ta có phần mô tả định danh và cấu trúc của phần mở rộng
OtherName ::= SEQUENCE {
EDIPartyName ::= SEQUENCE {
