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.6.2.1. Kh%i to CA gc
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 thực theo kiểu tự ký (self-signed). Các thẻ xác thực này được ký với khóa riêng của CA gốc đó và trường mô tả cho kiểu thẻ xác thực là NewWithNew. Nghĩa là, thẻ xác thực được cấp lần đầu cho các đối tượng trong hệ thống. Kiểu thẻ xác thực này cũng được dùng khi CA muốn gửi thẻ xác thực đến cho một đối tượng mới tham gia hệ thống. Thông điệp chứa thẻ xác thực này được gửi đi sau khi CA thực hiện công việc cập nhật khóa 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 thực 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 thực cần hủy bỏ (CRL) và lưu các thẻ xác thực đã gửi đi vào danh sách này. Đây chính là cơ sởđể CA hủy bỏ các khóa và thực hiện các phiên cập nhật khóa của mình.
2.6.2.2. Kh%i to các CA th cp
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.6.2.3. Cp nht khóa ca CA gc
Các khóa 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 khóa sẽ tùy 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 thực 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 thực cũ của CA (kiểu OldWithOld), khi nhận được các thẻ xác thực mới gửi đến từ CA, có thể chuyển sang các thẻ xác thực 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 thực kiểu
NewWithNew) có thể thu được thẻ xác thực 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 khóa công khai trong các thông điệp kiểu
OldWithOld)
2.6.2.4. To lp CRL
Trước khi phát hành và gửi đi các thẻ xác thực, 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 thực cần hủy 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 thực.
2.6.2.5. Yêu c"u v thông tin h thng 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.6.2.6. Xác thc ngang hàng
Trong giao thức của việc xác thực ngang hàng, CA yêu cầu sẽ là CA có tên trong trường subject của thẻ xác thực (CA được cấp phát thẻ xác thực). Trong khi đó, CA trả lời sẽ chính là CA đã phát hành thẻ xác thực này. Quá trình xác thực 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.6.2.7. Kh%i to 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:
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: Khóa công khai của CA gốc.
Nhánh xác thực 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). 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.
Kiểm tra khóa công khai của CA gốc
Một EE phải có được khóa 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 thực tự ký và được trao đổi qua các phương tiện out-of-band. Sau khi nhận được thẻ xác thực này từ CA gốc, các EE có thể sử dụng những thẻ xác thực này một cách an toàn.
2.6.2.8. Yêu c"u xác thc
Một EE sau khi khởi tạo có thể sẽ yêu cầu một thẻ xác thực 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 thực (CR). Nếu đối tượng đã có một cặp khóa để 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 (adsbygoogle = window.adsbygoogle || []).push({});
được chấp nhận, CA sẽ trả về cho đối tượng sử dụng một thẻ xác thực mới.
2.6.2.9. Cp nht khóa
Khi cặp khóa 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 khóa của mình bằng một cặp khóa 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 khóa (KUR). Nếu EE đã có một cặp khóa 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 khóa (KUP) có chứa một thẻ xác thực mới cho đối tượng.
2.7. THẺ XÁC NHẬN THEO CHUẨN X.509
Thẻ xác thực 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 thực trong hệ thống PKI, trong đó, cấu trúc của thẻ xác thực đượ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 thực 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 thực. Cấu trúc TBSCertificate
Các phần mở rộng của thẻ xác thực X.509
2.7.1. Khuôn Dạng Chứng Chỉ X.509
Bây giờ chúng ta đi sâu vào đặc tả cấu trúc chứng chỉ số theo chuẩn X.509, đựơc ban hành bởi tổ chức International Telecommunication Union - Telecommunication (ITU-T) và ISO/International Electrotechnical Commission(IEC)
ITU-T X.509 hay ISO/IEC 9594-8 định nghĩa chuẩn chứng chỉ X.509,
đựơc xuất bản năm 1988 là một phần của chuẩn thư mục X.500. Chuẩn chứng chỉđầu tiên này là phiên bản 1 (version 1). Khi chuẩn X.500 được thay đổi trong năm 1993, thì chứng chỉ số thêm hai trường mới, kết quả là tạo ra phiên bản 2 (version 2).
Các tài liệu RFC (Request For Comment) vềđặc tả bảo mật mail(Internet Privacy Enhanced Mail- PEM) công bố năm 1993, bao gồm các đặc tả cơ sở hạ
tầng bảo mật dựa trên nền tảng chứng chỉ X509 phiên bản 1 (RFC 1422). Tuy nhiên trong quá trình xây dựng hệ thống người ta thấy rằng dù sử dụng chứng chỉ x.509 version 2 thay cho version 1 thì hệ thống vẫn bị hạn chế trong một số
trường hợp cụ thể. Các trường mới được thêm vào chứng chỉ trong khi xây dựng hệ thống PEM, và điều này được thực tế chứng mình là cần thiết. Kết quả , ISO/IEC/ITU và ANSI X9 đã phát triển định dạng chứng chỉ X.509 phiên bản 3 (version 3).
Sự khác biệt giữa phiên bản 3 và phiên bản 2 là việc thêm các trường dữ
liệu mở rộng trong chứng chỉ. Trong số các trường thêm mới so với phiên bản 2, có một số trường được quy định và bắt buộc theo chuẩn, nhưng còn một số
trường đựơc phép lựa chọn và tùy thuộc từng hệ thống sử dụng.
Nhìn tổng thể Chứng chỉ X.509 bao gồm phần cơ sở và mở rộng. Tất cả được xác thực bằng chữ ký của nhà phát hành chứng chỉ.
2.7.2. Các trường cơ bản của thẻ xác thực
Một thẻ xác thực 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 thực sẽ được ký signatureAlgorithm AlgorithmIdentifier -- Thuật toán tạo chữ ký số
signatureValue BIT STRING} -- Thẻ xác thực 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 thực.
2.7.2.1. Trng tbsCertificate
Trường này chứa những thông tin cơ bản nhất của thẻ xác thực. 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 (adsbygoogle = window.adsbygoogle || []).push({});
2.7.2.2. Trng 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 thực. 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 được sử dụng là thuật toán DSA với hàm phân tách một chiều dsaWithSha1.
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 tùy thuộc vào từng loại thuật toán mã hoá
được sử dụng.
2.7.2.3. Trng 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 thực trước khi thực hiện phương thức chữ ký số với thẻ xác thực đó.
Bằng việc thực hiện phương thức chữ ký số với thẻ xác thực, CA có thể đảm bảo cho các trường thông tin có trong thẻ xác thực. 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à khóa 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 thực. 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.
2.7.3. 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 thực 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:
2.7.3.1. Trng version
Trường này chỉ ra phiên bản của thẻ xác thực đã được mã hoá. Trong trường hợp thẻ xác thực có dùng đến các trường mở rộng thì phiên bản của thẻ
xác thực 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 thực 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.
Version::= INTEGER { v1(0), v2(1), v3(2) }
Nếu chứng chỉ chỉ có các trường cơ sở thì phiên bản của chứng chỉ 1. Giá trị của trường đại diện cho ba phiên bản là 2,1,0. Giá trị mặc định của trường này là 0.
2.7.3.2. Trng serialNumber
CertificateSerialNumber::= INTEGER
Trường này mô tả số hiệu của chứng chỉ. Mỗi chứng chỉ có một số hiệu khác nhau, do CA cấp phát. Số này là một số nguyên dương phụ thuộc vào nhà phát hành chứng chỉ và chứng chỉ được cấp phát. Hai chứng chỉ khác nhau không thể có hai số hiệu trùng nhau, do đó giá trị của trường này có thể là rất lớn. Các hệ thống xử lý chứng chỉ phải có khả năng xử lý trường này với giá trị
có độ lớn là 20 con chữ số trong hệ số 16. Tuy nhiên trong thực tế thì chưa có CA nào cấp phát chứng chỉ với số lượng lớn như thế cả.
2.7.3.3. Trng 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 thực. 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. (adsbygoogle = window.adsbygoogle || []).push({});
2.7.3.4. Trng issuer
Trường này chỉ ra đối tượng nào đã tạo ra thẻ xác thực, tạo chữ ký sốứng với thẻ xác thực 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, tùy 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 thực, 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.
Đâ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").
2.7.3.5. Trng validity
Trường thông tin về thời gian hiệu lực của thẻ xác thực 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 thực đó. Trường này chứa hai biến lưu thời điểm thẻ xác thực 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.
Validity::= SEQUENCE { notBefore UTCTIME, notAfter UTCTIME }
Trường này bao gồm hai trường nhỏ là trường not before và not after. (adsbygoogle = window.adsbygoogle || []).push({});