2 NHỮNG VẤN ĐỀ CƠ BẢN TRONG XÂY DỰNG HỆ THỐNG PKI
3.3.8. Phần mở rộng Issuer Alternative Names
Cũng giống như phần trước, phần mở rộng này cũng được dùng để biểu diễn những định danh khác của đối1 tượng theo định dạng phù hợp với các ứng dụng Internet. Các đối tượng được đề cập ởđây là các CA phát hành thẻ xác nhận. Có một điểm khác biệt là khi phần mở rộng này được sử dụng thì ta không nên đánh dấu nó là critical. Do có cấu trúc và định dạng giống những kiểu tên trong phần trước nên ta có thể mô tả các kiểu tên thay thế cho đối tượng phát hành thẻ xác nhận như sau:
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } IssuerAltName ::= GeneralNames
3.3.9. Phần mở rộng Subject Directory Attributes
Phần mở rộng này được sử dụng để biểu diễn các thuộc tính định danh của đối tượng sử
dụng thẻ xác nhận. Nó được cấu thành bởi một hoặc một dãy các thuộc tính định danh có liên quan đến đối tượng. Trong trường hợp được sử dụng, phần mở rộng này cần được
đánh dấu là non-critical. Biểu diễn của phần mở rộng này như sau:
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
3.3.10. Phần mở rộng Basic Constraints
Phần mở rộng này cho ta biết đối tượng sử dụng thẻ xác nhận có phải là một CA hay không. Ngoài ra, nó còn cho ta biết độ sâu cực đại của một nhánh xác nhận hợp lệ có một nút là thẻ xác nhận này. Tuy nhiên, thành phần biểu diễn độ sâu cực đại này chỉ có ý nghĩa khi đối tượng sử dụng thẻ là một CA.
Trong trường hợp khoá công khai của thẻ xác nhận tương ứng được sử dụng chỉ cho mục đích tạo chữ ký số thì phần mở rộng này cần được đánh dấu là critical. Ngược lại, nếu khoá đó được sử dụng cho các mục đích khác thì phần mở rộng này có thểđược
đánh dấu là critical hoặc non-critical. Ta có biểu diễn vềđịnh danh và cấu trúc của phần này như sau:
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL}
3.3.11. Phần mở rộng Name Constraints
Phần mở rộng này chỉđược sử dụng trong các thẻ xác nhận dành cho CA. Nó định ra tập các tên của các đối tượng sử dụng cấp dưới trong nhánh xác nhận có sử dụng đến thẻ
xác nhận tương ứng. Những giới hạn do phần này định ra được áp dụng với cả tên đối tượng trong trường subject lẫn những tên thay thế cho đối tượng trong phần mở rộng đã nêu trên.
Ta cần lưu ý là những giới hạn do phần này định ra chỉ có hiệu lực khi những dạng tên tương ứng tồn tại (subject hoặc subject alternative names). Trong trường hợp được sử
dụng, phần mở rộng này phải được đánh dấu là critical. Định danh và cấu trúc của nó
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL} GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
Base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL} BaseDistance ::= INTEGER (0..MAX)
3.3.12. Phần mở rộng Policy Constraints
Phần này chỉ được sử dụng đối với các thẻ xác nhận được cấp cho các CA. Nó có thể được sử dụng để ràng buộc quá trình xác nhận theo hai chiều. Ngoài ra, nó có thểđược sử dụng để ngăn việc ánh xạ các chính sách và yêu cầu mỗi thẻ xác nhận trên một nhánh xác nhận phải chứa số hiệu của một chính sách được chấp nhận.
Khi phần này được sử dụng, các CA không được phép để trống thông tin. Do được tổ
chức dưới dạng tập hợp các ràng buộc nên trong thực tế, tập hợp này không được là tập rỗng. Phần này có thểđược đánh dấu là critical hoặc non-critical. Cấu trúc của phần mở
rộng này được mô tả như sau:
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL, inhibitPolicyMapping [1] SkipCerts OPTIONAL} SkipCerts ::= INTEGER (0..MAX)
3.3.13. Phần mở rộng Extended key usage field
Phần này cho ta biết thêm những mục đích sử dụng của khoá công khai mang trong thẻ
xác nhận tương ứng so với những gì đã nêu trong trường keyUsage cơ bản. Thông thường, phần mở rộng này chỉđược sử dụng cho các thẻ xác nhận cấp cho đối tượng sử
dụng. Khi đó, nó có thểđược đánh dấu là critical hay non-critical. Cấu trúc của phần này
được mô tả như sau:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER
Với cấu trúc như trên, ta có một số một số mục đích sử dụng mở rộng của khoá công khai như sau:
anyExtendedKeyUsage ::= { id-ce-extKeyUsage 0 } id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-- Sử dụng trong xác thực các WWW server. Các bit mô tả công dụng khoá: -- digitalSignature, keyEncipherment hay keyAgreement
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- Sử dụng trong xác thực các WWW client. Các bit mô tả công dụng khoá: -- digitalSignature và/hoặc keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- Sử dụng để tạo chữ ký số với mã chương trình. Các bit mô tả công dụng khoá: -- digitalSignature
Thẻ xác nhận theo chuẩn X.509 HẠ TẦNG KHOÁ CÔNG KHAI
42
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } -- Sử dụng trong bảo vệ email. Các bit mô tả công dụng khoá:
-- digitalSignature nonRepudiation, va/hoac (keyEncipherment hoac keyAgreement) id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- Gắn gt phân tách của đối tượng với thời gian. Các bit mô tả công dụng khoá: -- digitalSignature và/hoặc nonRepudiation
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Sử dụng để tạo chữ ký số với thông điệp OCSP. Các bit mô tả công dụng khoá: -- digitalSignature va/hoac nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
3.3.14. Phần mở rộng CRL Distribution Points
Phần này định ra cách thức để thu thập các thông tin về CRL. Các trình ứng dụng và các CA cần có khả năng hỗ trợ phần mở rộng này. Khi được sử dụng, nó cần được đánh dấu là non-critical. Ta có định danh và cấu trúc của phần này được mô tả như sau:
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint DistributionPoint ::= SEQUENCE {
DistributionPoint [0] DistributionPointName OPTIONAL, Reasons [1] ReasonFlags OPTIONAL, CRLIssuer [2] GeneralNames OPTIONAL} DistributionPointName ::= CHOICE {
FullName [0] GeneralNames,
NameRelativeToCRLIssuer [1] RelativeDistinguishedName } ReasonFlags ::= BIT STRING {
Unused (0), KeyCompromise (1), CACompromise (2), AffiliationChanged (3), Superseded (4), CessationOfOperation (5), CertificateHold (6), PrivilegeWithdrawn (7), AACompromise (8) }
Phần 4
4 QUÁ TRÌNH XÂY DỰNG HỆ THỐNG
Trong phần này, ta sẽ tìm hiểu từng bước của quá trình thực thi hệ thống. Quá trình này mang những đặc trưng của đối tượng thực thi và những yêu cầu cụ thểđối với hệ thống cần xây dựng. Tuy nhiên, các bước triển khai của quá trình này đều giống nhau, kết quả
của nó là một hệ thống PKI với các đối tượng và hoạt động của nó. Ở mức tối thiểu, việc thực thi cũng phải cho ta một hệ thống với các đối tượng cơ bản và những những chức năng tối thiểu của hệ thống. Các bước của quá trình này gồm có:
¾ Lựa chọn môi trường, công cụ, mô hình, chức năng và dữ liệu.
¾ Phân tích thiết kế chi tiết cho các đối tượng và chức năng đã chọn.
¾ Lập trình thực thi.
4.1. MÔI TRƯỜNG, CÔNG CỤ, MÔ HÌNH, CHỨC NĂNG, DỮ LIỆU
Đây là phần đầu tiên của quá trình thực thi hầu hết các hệ thống trong thực tế. Kết quả
của phần này nhằm trả lời câu hỏi: Hệ thống sẽ chạy trên môi trường hệđiều hành nào,
được phát triển bằng công cụ lập trình nào, những đối tượng và chức năng của hệ thống là gì. Sau khi trả lời các câu hỏi trên, ta sẽ có những chọn lựa phù hợp cho cấu trúc dữ
liệu phục vụ hệ thống.
4.1.1. Lựa chọn môi trường và công cụ
Việc lựa chọn môi trường và công cụ phát triển sẽ trả lời câu hỏi: Hệ thống được xây dựng sẽ hoạt động trong điều kiện nào và ta được trang bị những gì để xây dựng hệ
thống đó.
4.1.1.1. Môi trường phát triển
Một hệ thống PKI trong thực tế sẽ bao gồm cả con người và máy móc. Phạm vi ứng dụng và các tình huống xảy ra trong hệ thống cũng rất đa dạng. Tuy nhiên, trong phạm vi báo cáo này, ta coi những đối tượng trong hệ thống là các máy tính với một hệđiều hành nào
đó. Cụ thể, hệ thống PKI được triển khai trên hệđiều hành Windows 2000 và Windows XP trên các máy PC. Mặc dù vậy, việc đảm bảo sự tương thích tối đa đối với các phiên bản sớm hơn của Windows sẽ luôn được chú trọng.
Lý do của việc chọn các hệđiều hành này là vì chúng hỗ trợ khá mạnh những hàm và cấu trúc dự liệu cho việc triển khai hệ thống PKI. Hơn nữa, đây cũng là một dòng hệđiều hành phổ biến, dễ phát triển và kiểm thử các ứng dụng.
4.1.1.2. Công cụ phát triển
Ngôn ngữ lập trình để xây dựng hệ thống PKI là C++ và công cụ phát triển là bộ Visual C++ 6.0. Những hỗ trợ về các hàm và cấu trúc dữ liệu của Windows được thể hiện rõ nét
Quá trình xây dựng hệ thống HẠ TẦNG KHOÁ CÔNG KHAI
44
trong công cụ phát triển này. Hơn nữa, C++ cũng là ngôn ngữ phổ biến, có thể dữ xử lý dữ liệu ở nhiều mức khác nhau. Các ứng dụng sẽ được phát triển theo kiểu ứng dụng MFC nhằm đảm bảo sự hỗ trợ về các thư viện và các lớp đối tượng ở cấp thấp.
Hiện nay, bộ công cụ phát triển Visual Studio .NET đã được phát hành, bộ công cụ này hỗ trợ rất tốt các thuật toán mã hoá, giải mã cũng nhưđóng gói dữ liệu phục vụ hệ thống PKI. Tuy nhiên, bộ công cụ này tạo ra các ứng dụng cần nhiều thư viện liên kết động (DLL) mà nhiều khi người phát triển phải mang theo khi cài đặt hệ thống. Đây là một trở
ngại lớn vì các hệ điều hành khác nhau có thể có những thành phần thư viện liên kết
động không giống nhau.
Việc sử dụng bộ công cụ Visual C++ 6.0 cũng không hoàn toàn thuận lợi khi ta cần thực hiện các thủ tục mã hoá hay đóng gói dữ liệu. Thư viện các cấu trúc dữ liệu và các hàm cơ bản mà ta có thể sử dụng được mô tả trong file wincrypt.h của thư mục system32 của hệđiều hành. Theo như định nghĩa của file thì cả phiên bản mới nhất của họ Windows là Windows XP cũng không sử dụng được thư viện này. Tuy nhiên, nếu ta chỉ cần chỉnh sửa file này để nó hỗ trợ các phiên bản của Windows thì vẫn có thể sử dụng các thư viện này. Hệ thống cần triển khai sẽ phải sử thường xuyên các thủ tục đóng gói và lưu trữ dữ liệu. Những thủ tục này đều có các hàm thư viện hỗ trợ song không phải bao giờ chúng cũng hoạt động tốt. Ví dụ, việc đóng gói thông tin vềđịnh danh và khoá thường được thực hiện rất tốt, tuy nhiên, đối với các thẻ xác nhận thì ta chỉ có thể đóng gói được dữ liệu mà không thể nào lấy lại được thông tin đã đóng gói. Kết luận này được rút ra với cả các thủ
tục mẫu, các thủ tục tự viết và trên nhiều máy khác nhau. Trong khi đó, thẻ xác nhận là cấu trúc dữ liệu cơ bản nhất cần được đóng gói. Đây chính là hạn chế lớn nhất của các hàm thư viện.
Từđó, yêu cầu đặt ra của việc triển khai hệ thống là phải đảm nhận được khâu đóng gói dữ liệu. Ta vẫn giữ nguyên những cấu trúc dữ liệu mà thư viện cung cấp, song sẽ tự thực hiện các thủ tục đóng gói và lấy lại thông tin. Đây chính là những thủ tục quan trong nhất của việc triển khai hệ thống PKI trong phạm vi muc tiêu đã đề ra.
4.1.2. Lựa chọn mô hình hệ thống PKI
Như trong phần về các mô hình triển khai hệ thống PKI đã nêu, ta có 3 mô hình triển khai cơ bản. Việc đánh giá ưu điểm và nhược điểm của chúng cũng đã được nêu ra song điều
đó chỉđúng và thích hợp khi ta triển khai hệ thống đúng như mô hình đã định.
Mục tiêu của quá trình thực thi là minh hoạ khái quát về các đối tượng cơ bản nhất cũng như những chức năng cơ bản của hệ thống. Nghĩa là, việc thực thi hệ thống sẽ nhằm trả
lời câu hỏi: Những đối tượng cơ bản của hệ thống là gì và ít nhất chúng phải làm gì để
thực hiện vai trò của mình.
Như vậy, với những yêu cầu nêu trên, ta nhận thấy việc triển khai hệ thống theo một mô hình nào đó một cách đầy đủ sẽ không thể thực hiện được trong một khoảng thời gian hạn chế. Để thực hiện việc trao đổi thông tin giữa các đối tượng trong hệ thống, ta sẽ căn cứ vào những tình huống cụ thểđể triển khai. Ví dụ, việc tương tác giữa CA và EE có thể được coi là một phiên làm việc theo mô hình client/server thuần tuý. Trong khi đó, việc tương tác giữa hai CA có thểđược thực hiện theo mô hình danh sách tin cậy.
Như vậy, hệ thống được triển khai sẽ gồm có hai đối tượng cơ bản là CA và EE, quá trình
đăng ký thẻ xác nhận sẽđược giản lược. Nghĩa là, CA không đảm nhận chức năng của một RA trong hệ thống này. Ngoài ra, ra còn dùng đến các bộ phận lưu trữ thông tin đơn giản dưới dạng các file dữ liệu. Mô hình hoạt động cơ bản sẽ dựa trên kiến trúc danh sách tin cậy, trong các tình huống cụ thể sẽ có những chỉnh sửa phù hợp.
4.1.3. Lựa chọn cấu trúc dữ liệu
Cấu trúc dữ liệu cơ bản nhất trong hệ thống là cấu thẻ xác nhận theo chuẩn X.509. Cấu trúc này đã được mô tảở phần trên cùng với các trường mở rộng của nó. Song song với cấu trúc của chuẩn X.509 theo tài liệu rfc 2459 của tổ chức IETF mà ta sử dụng, hệđiều hành Windows cũng hỗ trợ định dạng của thẻ theo chuẩn này. Mặc dù có một sốđiểm khác biệt giữa hai cấu trúc nhưng về cơ bản là giống nhau và cấu trúc đó có thể hỗ trợ tối
đa những khả năng triển khai hệ thống PKI.
Vì vậy, trong quá trình triển khai hệ thống, ta sẽ dựa trên những cấu trúc dữ liệu đã được
định sẵn mà Windows hỗ trợ trong bộ công cụ phát triển phần mềm (SDK) của mình. Với những yêu cầu cơ bản nhất của hệ thống thì ta không cần có chỉnh sửa và bổ sung gì vì hầu hết các cấu trúc đều giống với những gì đã mô tảở phần trên.
Hệ thống PKI được triển khai có thể sử dụng đến danh sách thẻ xác nhận đã bị huỷ bỏ
(CRL). Tuy nhiên, với những chức năng đã nêu của hệ thống thì cấu trúc này chưa cần thiết. Mặc dù vậy, nếu ta triển khai thêm một số chức năng hoặc triển khai toàn bộ hệ
thống PKI trong thực tế thì đây là một thành phần hết sức quan trọng. Nếu không được quản lý tốt, đây có thể là một kẽ hở dễ bị lợi dụng để tấn công hệ thống PKI.
Là những thành phần của thẻ xác nhận nhưng khoá và định danh các đối tượng có thể đứng riêng như những thành phần thông tin độc lập. Trong thực tế khi phát triển hệ
thống, có những lúc ta chỉ dùng đến thông tin về khoá hay vềđịnh danh một cách độc lập với thẻ xác nhận. Tiêu biểu nhất là trong các pha khởi tạo khi đối tượng chưa có thẻ xác nhận ứng với khoá và định danh của mình. Trong hai thành phần kể trên, định danh đối tượng là thành phần mà đối tượng sử dụng cần biết thông tin chi tiết khi đăng nhập vào một hệ thống. Trong khi đó, thông tin về cặp khoá của đối tượng sử dụng có thể không cần được biết cụ thể là gì. Ta chỉ cần đảm bảo một điều là: chỉđối tượng đó mới nắm giữ