2 NHỮNG VẤN ĐỀ CƠ BẢN TRONG XÂY DỰNG HỆ THỐNG PKI
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.
Nhữ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á (adsbygoogle = window.adsbygoogle || []).push({});
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
thô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.
Dong Manh Quan Trang 32 23/08/2005
Phần 3
3 THẺ XÁC NHẬN THEO CHUẨN X.509
Thẻ xác nhận là thành phần cốt yếu của hệ thống PKI. Trong phần này, ta sẽ tìm hiểu cấu trúc của thẻ xác nhận trong hệ thống PKI, trong đó, cấu trúc của thẻ xác nhận được mô tả
có phiên bản 3.0. Ta sẽ tập trung mô tả cấu trúc của thẻ xác nhận này trong các dịch vụ
thưđiện tử, dịch vụ IPSEC, và các dịch vụ WWW. Các nội dung cần tìm hiểu bao gồm:
¾ Các trường cơ bản của thẻ xác nhận.
¾ Cấu trúc TBSCertificate
¾ Các phần mở rộng của thẻ xác nhận X.509
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 {
tbsCertificate TBSCertificate, -- Thẻ xác nhận sẽ được ký signatureAlgorithm AlgorithmIdentifier, -- Thuật toán tạo chữ ký số
signatureValue BIT STRING} -- Thẻ xác nhận sau khi ký
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 {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL}
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
Trườ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 đó. (adsbygoogle = window.adsbygoogle || []).push({});
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ó:
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] EXPLICIT Extensions OPTIONAL}
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.
Thẻ 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:
Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType, value AttributeValue } AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)), printableString PrintableString (SIZE (1..MAX)), universalString UniversalString (SIZE (1..MAX)), utf8String UTF8String (SIZE (1..MAX)), bmpString BMPString (SIZE (1..MAX)) }
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. (adsbygoogle = window.adsbygoogle || []).push({});
6. Tên thường gọi - common name. 7. Số hiệu - serial number.
Đâ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. 3. Họ - surname. 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
Thẻ 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ó (adsbygoogle = window.adsbygoogle || []).push({});
đượ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 [0] KeyIdentifier OPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL, authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL} KeyIdentifier ::= OCTET STRING
3.3.2. Phần mở rộng Subject Key Identifier