3.2 Quản lý khoá và chứng chỉ
3.2.3 Giai đoạn huỷ bỏ (Cancellation Phase)
Quản lý vòng sống của khoá/chứng chỉ kết thúc bằng giai đoạn huỷ bỏ. Giai đoạn này bao gồm:
Hết hạn chứng chỉ là việc hết hạn tự nhiên của chứng chỉ
Huỷ bỏ chứng chỉ là khẳng định rằng một chứng chỉ (và khoá bí mật tương ứng) không còn hợp lệ nữa.
Lịch sử khoá là duy trì bản ghi về các khoá có liên quan (thông thường với thực thể đầu cuối) sao cho dữ liệu được mã bởi các khoá mà sau đó bị hết hạn có thể giải mã được.
Lưu trữ khoá là lưu giữ các khoá an toàn bởi bên thứ ba để khôi phục lịch sử khoá, kiểm toán và các mục đích giải quyết tranh chấp.
Các chứng chỉ được gán một thời gian sống cố định tại thời điểm phát hành (như đã được chỉ ra bởi thời gian/ngày tháng Not Valid After bên trong chứng chỉ). Dần dần, thời hạn hợp lệ đã được thiết lập của chứng chỉ đã cho sẽ hết hạn.
Khi một chứng chỉ hết hạn, 3 sự kiện sau có thể xảy ra với thực thể đầu cuối tương ứng với chứng chỉ đó:
Không có việc gì xảy ra nếu thực thể đầu cuối không tiếp tục tham gia vào PKI
Việc đổi mới chứng chỉ xảy ra khi cùng khoá công khai được đặt vào trong chứng chỉ mới với thời hạn hợp lệ mới
Việc cập nhật chứng chỉ xảy ra nếu cặp khoá bí mật/công khai mới được sinh ra và chứng chỉ mới được phát hành (mặc dù bước này nên xảy ra trước khi chứng chỉ hết hạn như đã bàn luận ở trên)
Huỷ bỏ chứng chỉ (Certificate Revocation)
Huỷ bỏ chứng chỉ có liên quan đến việc huỷ bỏ đúng lúc một chứng chỉ đã cho trước khi nó hết hạn một cách tự nhiên. Yêu cầu để huỷ bỏ một chứng chỉ có thể xuất phát từ một số các nhân tố, bao gồm việc nghi ngờ khóa bí mật bị thỏa hiệp, sự thay đổi trong trạng thái công việc hoặc kết thúc thuê mướn. Các mã lý do cụ thể được định nghĩa trong Khuyến cáo X.509 và sẽ được đề cập tới ở phần sau của chương này.
Dưới một số hoàn cảnh, người sử dụng đầu cuối có thể cá nhân khởi tạo việc huỷ bỏ chứng chỉ của riêng mình (ví dụ, do tổn thương được nghi ngờ của khóa bí mật tương ứng). Một yêu cầu như vậy có thể được khởi tạo trực tuyến trực tiếp với RA hoặc CA. Cách khác, người sử dụng đầu cuối có thể cần giao tác với RA hoặc CA thông qua các phương tiện khác nào đó (thông qua điện thoại hoặc có mặt vật lý). Ví dụ, điều đó sẽ cần thiết khi máy xách tay hoặc thẻ thông minh của người sử dụng bị mất hoặc bị đánh cắp. (Trong trường hợp như vậy, RA có thể được sử dụng để khởi tạo việc huỷ bỏ chứng chỉ thay mặt cho người sử dụng đầu cuối. (Chức năng của RA không bị giới hạn bởi việc đăng ký). Hình 3.5 minh hoạ 2 kịch bản. Tất nhiên, những người quản trị được cấp phép cũng sẽ có khả năng huỷ bỏ các
chứng chỉ của thực thể đầu cuối khi các hoàn cảnh được bảo đảm.
Hình 3.5: Các kịch bản huỷ bỏ chứng chỉ
Lịch sử khoá (Key History)
Bởi vì các chứng chỉ được phát hành với thời gian sống cố định, các khoá mã dần dần hết hạn. Tuy nhiên, điều đó không có nghĩa rằng tất cả dữ liệu mà đã được mã hoá bằng khoá đó sẽ không thể khôi phục lại được. Cho nên cần lưu giữ an toàn và tin cậy các khoá cần thiết để giải mã ngay cả khi chứng chỉ để mã tương ứng đã hết hạn. Những nguyên liệu ấy được coi là lịch sử khoá.
Yêu cầu cho dịch vụ này chủ yếu cho các khoá để bảo mật. Đặc biệt, các khoá bí mật được sử dụng cho giải mã cần được lưu trữ sao cho dữ liệu mà đã được mã hoá nhờ khoá công khai để mã tương ứng có thể khôi phục được trong tương lai. Người ta cũng có thể tranh cãi rằng lịch sử khoá cũng áp dụng đối với các khoá được sử dụng cho các mục đích chữ ký số, mặc dù điều đó được thoả mãn một cách thích hợp hơn thông qua lưu trữ khoá.
Thông tin lịch sử khoá thông thường được lưu trữ cục bộ đối với người chủ để dễ lấy lại khi cần thiết. Tuy nhiên, nó cũng có thể được lưu giữ bởi CA hay một bên
Thực thể đầu cuối
CA 1. Yêu cầu huỷ bỏ chứng chỉ
2. Phúc đáp huỷ bỏ chứng chỉ
RA Yêu cầu
out-of-band
1. Yêu cầu huỷ bỏ chứng chỉ 2. Phúc đáp huỷ bỏ chứng chỉ
tin cậy khác, giả thiết rằng cơ chế tự động hoá là có thể để lấy lại một cách an toàn các khoá cần thiết khi cần thiết.
Lƣu trữ khoá (Key Archive)
Lưu trữ khoá là cất giữ các khoá trong thời hạn lâu dài (bao gồm các chứng chỉ để mã và kiểm tra), thông thường được hỗ trợ bởi CA hoặc bên tin cậy khác. Lưu trữ khoá khác với lịch sử khoá theo nghĩa rằng lưu trữ có thể được sử dụng cho cả các mục đích kiểm toán và để giúp đỡ giải quyết tranh chấp, đặc biệt khi được kèm với tem thời gian tin cậy và các dịch vụ công chứng.
Lịch sử khoá thông thường đi kèm trực tiếp với thực thể đầu cuối để cung cấp truy cập dễ tới các khoá để giải mã của thực thể đầu cuối này khi cố gắng truy cập dữ liệu mà đã được mã hoá bằng khoá mà đã hết hạn. Lưu trữ khoá là dịch vụ thông thường được cung cấp bởi bên thứ ba, nó bao gồm việc lưu giữ các khoá tương ứng với nhiều thực thể đầu cuối. Các dịch vụ được cung cấp bởi lưu trữ khoá có thể bao gồm (hoặc đi cùng với) các dịch vụ công chứng hoặc tem thời gian, các vết kiểm toán, và/hoặc khôi phục lịch sử khoá của thực thể đầu cuối. Dịch vụ sau là cần thiết khi lịch sử khoá cục bộ của thực thể đầu cuối bị mất hoặc bị huỷ. Lịch sử khoá của thực thể đầu cuối đã cho có thể được khôi phục bởi thiết bị lưu trữ khoá trong một phúc đáp cho một yêu cầu từ (1) người chủ của lịch sử khoá hoặc (2) một ai đó được cấp phép để truy cập các khoá khi vắng mặt thực thể đầu cuối (ví dụ, nhân viên an ninh của công ty).
Cuối cùng, thiết bị lưu trữ khoá có thể cần thiết khi cố gắng nhằm kiểm tra một chữ ký số được tạo ra bởi các khoá mà bây giờ đã hết hạn. Việc lấy lại chứng chỉ khoá công khai đã hết hạn sẽ được yêu cầu trong trường hợp này (giả sử rằng chứng chỉ khoá công khai là không đi kèm với dữ liệu đã được ký số). Nó cũng có thể đi kèm với dịch vụ công chứng và có thể được sử dụng để chứng minh rằng khoá bí mật để ký là hợp lệ tại thời điểm chữ ký số được tạo ra (ngay cả khi khoá đó đã hết hạn).
3.3 Huỷ bỏ chứng chỉ 3.3.1 Mở đầu 3.3.1 Mở đầu
Như đã thảo luận ở trên, các chứng chỉ được sử dụng để gắn một tên với khoá công khai tương ứng của nó. Bình thường, việc gắn này là hợp lệ cho toàn bộ thời gian sống của chứng chỉ đã được ban hành. Tuy nhiên, nhiều tình huống nảy sinh khi chứng chỉ đã được phát hành không được xem là tiếp tục hợp lệ nữa, ngay cả khi chứng chỉ chưa hết hạn. Các lý do để huỷ bỏ là khác nhau, nhưng chúng có thể bao gồm bất kỳ một cái gì từ sự thay đổi trong trạng thái công việc tới việc nghi ngờ khoá bí mật bị lộ. Cho nên, một phương pháp hiệu quả và tin cậy cần phải được cung cấp để huỷ bỏ một chứng chỉ khoá công khai trước khi nó hết hạn một cách tự nhiên.
Các chứng chỉ cần phải trải qua một quá trình kiểm chứng được thiết lập rõ ràng trước khi chúng có thể được sử dụng. Một phần của quá trình kiểm chứng bao gồm việc đảm bảo rằng chứng chỉ cần đánh giá chưa bị huỷ. Thực ra, CA có trách nhiệm niêm yết thông tin huỷ bỏ ở một dạng này hay một dạng khác. Các bên tin tưởng vào chứng chỉ (nhắc lại rằng bên tin tưởng là người sử dụng chứng chỉ cho một mục đích nào đó) cần phải có một cơ chế để hoặc tải thông tin huỷ bỏ về một cách trực tiếp hoặc chuyển tiếp tới bên tin cậy thứ ba nhằm giải quyết yêu cầu theo ý muốn của họ[1,7]. Hình 3.6 sau minh hoạ các khái niệm này.
Hình 3.6: Mô hình huỷ bỏ chứng chỉ
Huỷ bỏ chứng chỉ có thể được cài đặt theo nhiều cách. Một phương pháp là sử dụng các cơ chế công bố định kỳ như Các danh sách huỷ bỏ chứng chỉ (Certificate Revocation Lists-CRLs), nó có thể được thể chế hoá trong một loạt các biến dạng khác nhau. Cũng có các cơ chế truy vấn trực tuyến khác chẳng hạn như Giao thức trạng thái chứng chỉ trực tuyến (Online Certificate Status Protocol- OCSP) (RFC2560). Ở đây không đề cập đến những cơ chế hoặc giao thức lấy thông tin cụ thể trừ khi chúng là những phần hiện của chính phương pháp huỷ bỏ (như trong trường hợp của OCSP). Nhìn chung, một loạt các giao thức có thể được sử dụng để lấy thông tin huỷ bỏ, chẳng hạn như Giao thức truy cập thư mục trọng lượng nhẹ (Lightweight Directory Access Protocol- LDAP), Giao thức truyền tệp (File
CA
Người đăng ký
Bên tin tưởng
Thông tin huỷ bỏ
Kiểm tra
chứng chỉ ?
Phát hành chứng chỉ
Transfer Protocol – FTP), Giao thức truyền siêu văn bản (Hypertext Transfer Protocol – HTTP).
Tần số mà với nó thông tin huỷ bỏ được cập nhật và niêm yết là một xem xét rất quan trọng. Độ trễ được chấp nhận tương ứng với việc biết rằng một chứng chỉ cần phải được huỷ bỏ và thực sự phát tán thông tin này tới các bên tin tưởng (người mà xử lý chứng chỉ này) cần được thiết lập. Trong một số trường hợp, độ trễ này có thể rộng rãi tương đối (ví dụ, theo giờ hoặc thậm chí theo ngày). Trong các môi trường khác, ngay cả độ trễ tối thiểu cũng có thể xem là không chịu được. Độ trễ chấp nhận được giữa việc phát hiện rằng chứng chỉ cần phải được huỷ bỏ và việc niêm yết thực sự thông tin huỷ bỏ ở dạng có thể được kéo về bởi bên tin tưởng cần phải được chỉ ra như một phần của Chính sách chứng thực điều hành, và các kỹ thuật huỷ bỏ được sử dụng trong một lĩnh vực đã cho cần phải được kết dính với chính sách này.
3.3.2 Các kỹ thuật công bố định kỳ
Các kỹ thuật công bố định kỳ bao gồm:
CRL đầy đủ (complete CRLs)
Các danh sách huỷ bỏ thẩm quyền chứng thực (Certification Authority Revocation Lists- CARLs)
Các danh sách huỷ bỏ chứng chỉ khoá công khai thực thể đầu cuối (End-entity Public-key Certificate Revocation Lists –EPRLs)
Các điểm phân phối CRL (hay còn gọi là CRL được phân chia) (CRL Distribution Points hay Partitioned CRLs)
Delta CRLs (CRLs bổ sung) và Indirect Delta CRLs (CRLs bổ sung không trực tiếp)
CRLs không trực tiếp (Indirect CRLs)
CRLs chuyển hướng (Redirect CRLs)
Các cây huỷ bỏ chứng chỉ (Certificate Revocation Trees- CRTs).
được đặc trưng bởi việc phát hành thông tin huỷ bỏ trên cơ sở định kỳ trong một khuôn dạng của cấu trúc dữ liệu được ký. Trừ ra Các cây huỷ bỏ chứng chỉ, tất cả các kỹ thuật này được định nghĩa trong phiên bản năm 2000 của X.509, và chúng dựa trên cùng một cấu trúc dữ liệu ASN.1 cơ sở được nói tới như là CRL. Cấu trúc CRL cơ sở sẽ được bàn tới ngay sau đây.
CRL cơ sở
Được khẳng định một cách đơn giản, các CRL là các cấu trúc dữ liệu được ký mà chứa một danh sách các chứng chỉ đã được huỷ bỏ. Chữ ký số được thêm vào CRL cung cấp tính toàn vẹn và tính xác thực của CRL. Người ký vào CRL thông thường chính là thực thể mà đã ký các chứng chỉ đã được ban hành mà đã được liệt kê trong CRL. Tuy nhiên, CRL có thể được ký bởi một thực thể khác với người phát hành chứng chỉ.
Các CRL có thể được lưu (cache) để tăng hiệu suất. Việc lưu các CRL cũng làm cho thuận tiện khả năng kiểm định chứng chỉ khi làm việc không trực tuyến. Tất nhiên, khả năng lưu các CRL và niềm tin được đặt vào trong các CRL được lưu cần phải tương ứng với các Chính sách chứng chỉ được áp dụng.
Hiện tại, có hai phiên bản khác nhau về CRL đã được định nghĩa. Phiên bản 1 đã được định nghĩa trong các đặc tả X.509 ban đầu (khoảng 1988). Chú ý rằng các CRL phiên bản 1 là có lỗi một cách tiềm ẩn vì một số lý do sau:
Chúng có các vấn đề về tính mở rộng (tức là, kích thước của CRL phiên bản 1 là dễ dàng vượt lên so với các giới hạn chấp nhận được).
Chúng có các giới hạn về chức năng, đặc biệt liên quan tới khả năng không thể mở rộng CRL cùng với đặc tính thêm khi cần thiết.
Chúng là đối tượng của các tấn công thay thế CRL (tức là, có thể thay thế một cách có hại một CRL này bởi một CRL khác mà không bị phát hiện).
Các CRL phiên bản 2 giải quyết các vấn đề này bằng cách đưa vào khái niệm của các mở rộng, cũng nhiều như đưa ra các mở rộng vào các chứng chỉ khoá công khai X.509 phiên bản 3. Một số mở rộng được định nghĩa trên cơ sở theo từng mục
chứng chỉ được huỷ bỏ (per-revoked-certificate-entry), và các mở rộng khác được định nghĩa trên cơ sở theo CRL, như được mô tả trong các mục sau. Như với các mở rộng chứng chỉ, các mở rộng CRL này cần phải được mô tả sơ lược trong một môi trường đã cho.
Mặc dù X.509 định nghĩa một số yêu cầu tương ứng với các trường chuẩn và mở rộng của một chứng chỉ, việc định rõ các chi tiết thêm là thường cần thiết. Như được bàn đến sau này, đó là do nhiều chuẩn hướng tới tổng quát về bản chất, và các mức thêm của việc chỉ rõ được đòi hỏi để hiện thực hoá tính tương tác lẫn nhau.
Nhóm làm việc về Cơ sở hạ tầng khoá công khai PKIX (Public Key Infrastructure X.509 Working Group) của IETF (Internet Engineering Task Force) đã đưa ra một mô tả sở lược về CRL và chứng chỉ dùng cho Internet vào tháng giêng năm 1999 cùng với việc công bố RFC2459. Nó đã được thay bằng RFC3280 vào tháng Tư năm 2002[10]. RFC3280 phản ánh nhiều cải tiến đã được đưa vào phiên bản năm 2000 của X.509.
Chú ý rằng các mở rộng có thể được đánh dấu là quan trọng và không quan trọng. Một mở rộng được đánh dấu quan trọng cần phải được xử lý và hiểu bởi bên tin tưởng, mặc dù X.509 đảm bảo một mức độ mềm dẻo nào đó mà có thể được áp dụng dưới một số tình huống. Ít nhất, bên tin tưởng giả thiết rằng các chứng chỉ có ở trên danh sách thì cần bị huỷ bỏ, ngay cả khi một số mở rộng không được hiểu. Tuy nhiên, nếu một mở rộng theo CRL là không được hiểu, thì không thể giả thiết rằng một danh sách của các chứng chỉ được huỷ bỏ là đầy đủ. Các mở rộng không quan trọng có thể được bỏ qua nếu bên tin tưởng không hiểu chúng (tức là, các mở rộng có thể được bỏ qua mà không cần thêm một hành động nào về phía bên tin tưởng).
Cấu trúc tổng quát của CRL phiên bản 2 được trình bày ở hình 3.7. Các trường được trình bày trong hình này được định nghĩa như sau:
Version (phiên bản) chỉ ra phiên bản của CRL (giá trị hoặc là Version 2, hoặc không được chỉ ra thì ứng với Version 1).
Signature (chữ ký) chỉ ra định danh đối tượng (object identifier – OID) của thuật toán đã được sử dụng để tính chữ ký số trên CRL. Ví dụ, OID cho MD5 cùng với RSA có thể được trình ra, điều đó chỉ ra rằng chữ ký số là giá trị băm MD5 đã được mã hoá bằng RSA.
Issue (người phát hành) là một tên phân biệt (Distinguished Name- DN) của người phát hành CRL (tức là, người ký của CRL) và cần phải luôn có và duy nhất.
This Update (cập nhật lần này) là thời gian mà CRL này đã được phát hành, nó có thể được biểu diễn theo thời gian UTC hoặc Generalized Time.
Next Update (cập nhật lần sau), đây là một trường lựa chọn, đó là thời