Trước khi các thực thể đầu cuối có thể tham gia vào các dịch vụ được hỗ trợ bởi PKI, chúng cần phải được khởi tạo vào PKI. Việc khởi tạo bao gồm: đăng ký thực thể đầu cuối, sinh cặp khoá, tạo chứng chỉ và phân phối khoá/chứng chỉ, phát tán chứng chỉ và sao lưu khoá (nếu áp dụng được).
Quá trình đăng ký có thể đạt được theo nhiều cách. Hình sau minh họa một kịch bản có thể khi đó việc khởi tạo thực thể đầu cuối bao gồm cả RA và CA. Chú ý rằng các kịch bản khác cũng có thể. Ví dụ, tất cả các giao dịch có thể cần đến RA, hoặc thành phần RA có thể không tồn tại nói chung, và tất cả các giao dịch sẽ chạy trực tiếp giữa thực thể đầu cuối và CA.
Hình 3.4: Kịch bản khởi tạo thực thể đầu cuối
Đăng ký thực thể đầu cuối (End-entity registration)
Đăng ký thực thể đầu cuối là quá trình trong đó định danh của người sử dụng cá thể hoặc quá trình được thiết lập và kiểm tra. Mức độ kiểm tra tương ứng với việc đánh giá định danh của một thực thể đầu cuối đã cho phụ thuộc vào Chính sách
Thực thể đầu cuối RA CA 2. Phúc đáp mẫu đăng ký 3. Đệ trình mẫu đăng ký
1. Yêu cầu mẫu đăng ký
4. Yêu cầu thiết lập đăng ký 5. Các kết quả thiết lập đăng ký 6. Các kết quả đăng ký 7. Yêu cầu chứng chỉ 8. Trả lời chứng chỉ
chứng chỉ (CP) và/hoặc Tuyên bố thực hành chứng thực (CPS) mà áp dụng vào phạm vi an toàn của thực thể đầu cuối cụ thể.
Trong hình 3.4, việc đăng ký thực thể đầu cuối được tiến hành trực tuyến, như được minh hoạ bởi việc trao đổi mẫu đăng ký. Quá trình đăng ký trực tuyến này cần phải được xác thực và bảo vệ. Các yêu cầu đăng ký thực sự sẽ thay đổi dựa trên môi trường cũng như các đặc quyền tương ứng được hàm ý bởi việc phát hành của chứng chỉ đã cho.
Ví dụ, quá trình đăng ký cho người sử dụng đầu cuối được cấp phép để công nhận các giao dịch nhiều triệu đôla bao gồm (1) hiện diện vật lý tại RA hoặc CA thích hợp, (2) một số dạng của nhận dạng ảnh giống như hộ chiếu và thẻ căn cước của người lao động và (3) các dạng giấy phép cần thiết bất kỳ.
Sinh cặp khoá (Key pair generation)
Sinh cặp khoá tức là sinh cặp khoá bí mật/công khai. Các khoá có thể được sinh trước quá trình đăng ký thực thể đầu cuối hoặc trong trả lời trực tiếp cho quá trình đăng ký thực thể đầu cuối.
Trong mô hình PKI toàn diện, có thể sinh các khoá trong hệ thống máy trạm của thực thể đầu cuối (ví dụ, trong một trình duyệt), trong RA hoặc trong CA. Một cách khác, khả năng sinh khoá bởi bên thứ ba tin cậy có thể thích hợp trong các môi trường nào đó. Địa điểm của việc sinh cặp khoá là xem xét quan trọng và nó thường là chủ đề của một cuộc tranh cãi nào đó. Các nhân tố mà có thể có ảnh hưởng đối với địa điểm này bao gồm khả năng, hiệu suất, tính đảm bảo, phân nhánh pháp lý và cách sử dụng khoá được định sẵn.
Nhiều tranh luận tương ứng với địa điểm của hàm sinh cặp khoá tập trung xung quanh cách sử dụng khoá. Đặc biệt, nhiều cặp khoá cho một thực thể có thể được sử dụng để hỗ trợ các dịch vụ phân tách và khác nhau. Ví dụ, một cặp khoá có thể được sử dụng để hỗ trợ các dịch vụ không chối bỏ trong khi cặp khoá khác có thể được sử dụng để hỗ trợ tính bí mật hoặc các chức năng quản lý khoá.
Mặc dù không thống nhất hoàn toàn, một cách hợp lý, có thể ủng hộ rằng địa điểm của việc sinh khoá cần phải ở nội bộ trong hệ thống khách nếu các khoá được
sử dụng cho các mục đích không chối bỏ. Đó là do khẳng định rằng việc nắm giữ khoá bí mật để ký bởi thực thể khác bất kỳ làm cho việc chống chối bỏ khó đạt được hơn. Mặt khác, có thể xem rằng CA là thực thể tin cậy nhất trong PKI, cho nên việc biết các khoá bí mật để ký của những người sử dụng cụ thể không làm tổn hại khả năng hỗ trợ chống chối bỏ cũng như nguyên liệu khoá được bảo vệ bởi CA là đủ.
Không phụ thuộc vào mức độ tin cậy mà thực thể PKI đã cho đặt vào CA (và vào người vận hành CA), sự hỗ trợ thực sự của PKI cho chống chối bỏ đòi hỏi CA- hoặc thiết bị lưu trữ khoá khác có thể- chứng minh để thoả mãn bên thứ ba rằng khoá bí mật không thể được sử dụng bởi ai khác ngoại trừ chính người chủ của khoá bí mật. Trong thực tế, điều này là rất khó đạt được. Cho nên, đối với các khoá mà có thể được sử dụng để xác thực các giao dịch mà được chủ ý có tính chất chống chối bỏ, người ta khuyến cáo rằng các khoá cần được sinh bởi “người chủ” của khoá công khai và các khoá bí mật không bao giờ được cho bất kỳ ai khác được biết (bao gồm cả bên thứ ba tin cậy).
Khái niệm của việc dùng các cặp khoá khác nhau để phân tách các dịch vụ chống chối bỏ với các dịch vụ bảo mật được coi như mô hình hai cặp khoá (two key pair model). Định hướng này đã tồn tại từ khi những hệ thống PKI sớm nhất ra đời, và bây giờ là một kiểu mẫu được công nhận rộng rãi và được hỗ trợ trong PKI toàn diện bất kỳ.
Trong định hướng 2 cặp khoá, khoá bí mật được sử dụng để hỗ trợ các chữ ký số được coi như khoá bí mật để ký (signing private key) và chứng chỉ tương ứng được coi như là chứng chỉ kiểm tra (verification certificate). Một cách tương tự, chứng chỉ được sử dụng cho các mục đích mã được coi như là chứng chỉ mã (encryption certificate), và khoá bí mật tương ứng được coi như là khoá bí mật để mã (decryption private key).
Một nhân tố khác mà có thể ảnh hưởng tới địa điểm của việc sinh khoá là hiệu suất, mặc dù nó trở nên ít quan trọng do các tiến bộ trong công nghệ đang xảy ra. Ví dụ, bất cứ ai yêu cầu chứng chỉ mà sử dụng công nghệ trình duyệt Web chuẩn trên
máy PC cũ (trước thế hệ Pentium) hoặc máy xách tay biết rằng quá trình sinh khoá tại chỗ là chậm. Tuy nhiên, chúng ta thấy có những tiến bộ nhận thấy với các PC hoặc máy xách tay mới hơn, nên hiện nay điều đó không trở thành vấn đề nữa. Tuy vậy, một số người đề xuất rằng có ý nghĩa hơn để chuyển việc sinh khoá tới các hệ thống mạnh hơn, chẳng hạn như CA. Điều này đặc biệt đúng khi các hệ thống khách hàng là các thiết bị bị giới hạn thực sự chẳng hạn như điện thoại di động hay một cái gì đó tương tự. Một cách khác, lập luận chống lại có thể nói rằng việc sinh khoá được tập trung hoá sẽ không có tính mở rộng bởi vì một thành phần (hoặc một số các thành phần) sẽ bị yêu cầu để thực hiện việc sinh khoá khai thác CPU nhiều cho một số lớn các thực thể đầu cuối. Như đã bàn tới trước đây, chúng tôi khuyến cáo rằng các cặp khoá được sử dụng để hỗ trợ việc tạo và kiểm tra chữ ký số nên được sinh bằng hệ thống máy khách mỗi khi có thể.
Một nhân tố khác có thể ảnh hưởng tới địa điểm của việc sinh khoá có liên quan tới tính bảo đảm. Có thể có yêu cầu, ví dụ, cần một module mật mã được đánh giá một cách độc lập và tin cậy để sinh ra các khoá. Đó là cách trả lời cho yêu cầu rằng các khoá cần phải được sinh ra theo các hướng dẫn mật mã đặc thù. Đặc biệt, module phần cứng hay phần mềm mà được sử dụng để sinh ra các khoá có thể được yêu cầu nhằm thoả mãn một tập tối thiểu nào đó các tiêu chuẩn để cung cấp đủ mức bảo đảm rằng các khoá được sinh ra đúng. Chuẩn xử lý thông tin liên bang FIPS 140-1 là một ví dụ của tiêu chuẩn đánh giá cho các module mật mã.
Một xem xét khác dựa trên các phân chia trách nhiệm và pháp lý. Ví dụ, có thể có yêu cầu nhằm xác nhận một lượng nào đó về tính tin cậy trong quá trình sinh khoá. Một thực thể PKI có thể không có khả năng đáp ứng tiêu chuẩn tối thiểu tương ứng với yêu cầu này, hoặc nó sẽ không sẵn lòng nhận trách nhiệm cho một trọng trách như vậy.
Như đã thấy, một loạt các nhân tố có thể có ảnh hưởng tới nơi mà các cặp khoá được sinh ra. Kết luận sau là hợp lý: mỗi thành phần (CA, RA hay hệ thống khách) nên có khả năng sinh ra các khoá và các giao thức cần phải sẵn sàng để vận chuyển
an toàn các khoá giữa các hệ thống này khi cần thiết. Định hướng này được phản ánh trong các giao thức quản lý vòng sống chứng chỉ toàn diện mà sẽ được định ra.
Tạo chứng chỉ và Phân phối khoá/chứng chỉ
(Certification Creation and Key/Certificate Distribution)
Không phụ thuộc vào việc sinh khoá xảy ra ở đâu, trách nhiệm của việc tạo chứng chỉ chỉ nằm ở CA được cấp phép. Nếu khoá công khai được sinh bởi thực thể khác CA, thì khoá công khai đó cần phải được chuyển an toàn tới CA sao cho nó có thể được đặt vào trong chứng chỉ.
Một khi các khoá và chứng chỉ liên quan đã được sinh ra, nó cần được phân phối một cách thích hợp. Các yêu cầu phân phối khoá và chứng chỉ cụ thể phụ thuộc vào nhiều yếu tố, bao gồm nơi mà các khoá được sinh ra, mục đích sử dụng của chứng chỉ, và các xem xét khác chẳng hạn như các ràng buộc về chức năng hay về chính sách. Ví dụ, một chứng chỉ đã có có thể được phân phối trực tiếp tới người chủ, hoặc tới kho ở xa, hoặc cả hai; điều này sẽ phụ thuộc vào cách sử dụng khoá được dự kiến và các xem xét hoạt động. Hơn nữa, các yêu cầu phân phối tương ứng với các khoá bí mật phụ thuộc vào địa điểm nơi các khoá được sinh ra và việc sao lưu khoá có được yêu cầu hay không. Nếu các khoá được sinh ra ở hệ thống khách hàng, thì các khoá bí mật đã được lưu ở chỗ người chủ của nó, việc phân phối khoá sau đó không được yêu cầu, trừ khi cần sao lưu khoá. Tuy nhiên, nếu các khoá đã được sinh ở chỗ khác, khoá bí mật cần phải được phân phối an toàn tới người chủ của khoá đó. Các cơ chế khác nhau có thể được sử dụng để hoàn thành việc này, trong đó có RFC2510.
Các quy tắc để yêu cầu chứng chỉ và nhận chứng chỉ (và khoá bí mật tương ứng, nếu áp dụng được) xuất phát từ việc một thực thể được tin cậy (tức là, CA) yêu cầu định nghĩa của một cơ chế giao thức an toàn. Nhóm công tác IETF PKIX có một cặp các đặc tả theo các chuẩn mà đề cập đến quy tắc này trong cả hai chế độ trực tuyến và không trực tuyến như sau:
Các giao thức quản lý chứng chỉ (Certificate Management Protocols- CMP) cho Internet X.509 PKI (RFC2510)
Khuôn dạng thông điệp yêu cầu chứng chỉ (Certificate Request Message Format – CRMF) cho Internet X.509 PKI (RFC2511)
Đối với một số môi trường, các cơ chế khác, chẳng hạn như Các chuẩn mật mã khoá công khai (Public Key Cryptography Standards – PKCS) 7 (RFC2315) và 10 (RFC2986) là các thay thế thông dụng. Các giao thức khác, chẳng hạn như Certificate Management Messages over CMS (CMC) (RFC2797) và Simple Certificate Enrollment Protocol (giao thức kết nạp chứng chỉ đơn giản) của Cisco được xây dựng trên các cấu trúc PKCS 7/10 cơ sở này. CMP kết hợp với CRMF là giao thức quản lý vòng đời toàn diện nhất so với các thay thế khác, mặc dù CMC cũng hỗ trợ phần lớn các chức năng quản lý.
Phổ biến chứng chỉ (Certificate Dissemination)
Một khi khoá bí mật và chứng chỉ khoá công khai tương ứng đã được phân phối, một hoặc nhiều phương pháp để chuyển chứng chỉ tới các thực thể đầu cuối khác là có thể. Các phương pháp có thể để phổ biến thông tin này bao gồm:
Phân phối thủ công (phổ biến các chứng chỉ tới các thực thể đầu cuối sử dụng các kỹ thuật không điện tử chẳng hạn như vận chuyển vật lý)
Đặt các chứng chỉ trong các kho công cộng hoặc cơ sở dữ liệu để hỗ trợ việc tải về trực tuyến và theo yêu cầu.
Cái nào trong số các lựa chọn đó là thích hợp nhất phụ thuộc vào một số các nhân tố, bao gồm các hạn chế cách sử dụng khoá, các vấn đề riêng tư, tính mở rộng và các xem xét hoạt động khác. Một vài trong số các phương pháp thông dụng hơn sẽ được bàn tới sau này trong mục Lấy chứng chỉ (Certificate Retrieval).
Điểm quan trọng là các chứng chỉ cần phải sẵn sàng để hiện thực hoá đầy đủ các lợi ích của mật mã khoá công khai. Khi chứng chỉ số được kiểm tra, chứng chỉ dùng để kiểm tra mà tương ứng với khoá bí mật để ký đã được sử dụng để tạo ra chữ ký số cần phải có thể để kiểm chứng tính xác thực của chữ ký này. Tương tự, khi người gửi thông điệp mã thông điệp thư điện tử được gửi cho một hay nhiều người nhận, chứng chỉ dùng để mã cho mỗi người nhận cần phải sẵn sàng sao cho
khoá đối xứng dùng một lần để mã thông điệp thư điện tử có thể được mã cho mỗi người nhận.
Trong nhiều trường hợp, các chứng chỉ được sử dụng cho các mục đích kiểm tra chữ ký số được phổ biến tự động tới những người nhận được dự kiến. Nói một cách khác, các văn bản được ký số chẳng hạn như thông điệp thư điện tử thông thường bao gồm cả chứng chỉ cần thiết để kiểm tra chữ ký số. Điều này làm cho những người nhận không bị phiền toái phải tải về chứng chỉ dùng để kiểm tra được yêu cầu từ kho. Mặt khác, các chứng chỉ được sử dụng cho các mục đích đảm bảo bí mật cần phải đã sẵn sàng đối với người gửi để hỗ trợ quản lý khoá mở rộng được. Cho nên, các chứng chỉ mã hướng tới được đặt trong một dạng kho nào đó.
Sao lƣu khoá (Key Backup)
Nếu cặp khoá bí mật/công khai được sử dụng cho đảm bảo bí mật, giai đoạn khởi tạo cũng có thể bao gồm việc sao lưu khoá và chứng chỉ bởi bên tin cậy thứ ba (trừ các khoá bí mật được thiết kế cho các mục đích ký số để hỗ trợ dịch vụ chống chối bỏ). Bên tin cậy thứ ba có sao lưu cặp khoá đã cho hay không là được xác định bởi chính sách điều hành cho môi trường đang được xem xét. Cũng có thể nên chỉ ra rằng việc sao lưu có được mong muốn hay không trong quá trình khởi tạo.
Vị trí của thiết bị sao lưu có thể thay đổi tuỳ thuộc vào lĩnh vực PKI. Các nhân tố mà có ảnh hưởng tới lựa chọn cụ thể bao gồm các lệnh của chính sách an toàn cai trị và mô hình trách nhiệm tương ứng với mỗi thành phần PKI. Đặc biệt, CA mà phát hành chứng chỉ tương ứng cần thực hiện chức năng sao lưu khoá, hoặc nó được hỗ trợ bởi một thiết bị sao lưu-khôi phục khoá riêng biệt.