Đồ án Nghiên cứu xây dựng hệ thống PKI dựa trên bộ phần mềm mã nguồn mở OpenCA

au đó gửi chứng chỉ cho thực thể Thiết lập và xác nhận danh tính của thực thể trong giai đoạn khởi tạo Phân phối các bí mật dùng chung tới người sử dụng cuối để xác thực tuần tự trong suốt giai đoạn khởi tạo trực tuyến Khởi tạo quá trình chứng thực với CA đại diện cho người dùng cuối Thực hiện chức năng quản lý vòng đời của khoá/chứng chỉ, chú ý rằng RA không bao giờ được phép cấp chứng chỉ hoặc thu hồi chứng chỉ. Chức năng này chỉ có ở CA 3.1.2.2.Thành phần của RA RA bao gồm 3 thành phần sau 3.1.2.2.1.RA Console RA console là một máy chủ (server) được cài đặt cho RA officer để đưa các yêu cầu chứng chỉ. Nó có thể kết nối với CA. Server này xử lý các yêu cầu chứng chỉ số trong quá trình chứng thực 3.1.2.2.2.RA Officer RA Officer là một cá nhân thực hiện các tác vụ như đăng ký chứng chỉ số, làm mới hoặc thu hồi chứng chỉ. Sau khi RA Officer xác minh và chấp thuận yêu cầu, nó sẽ chuyển trực tiếp các yêu cầu này lên CA server. Sau khi CA server xử lý yêu cầu và cấp chứng chỉ. RA Officer sẽ phân phối chứng chỉ 3.1.2.2.3.RA Manager RA Manager là một cá nhân làm nhiệm vụ quản lý RA Officer và đảm bảo rằng toàn bộ thủ tục ứng dụng chứng thực được thực hiện mà không có sự lừa đảo của con người. RA Manager sẽ cần phải chấp thuận tất cả các yêu cầu được xử lý bởi RA Officer trước khi đưa các ứng dụng chứng thực tới cho CA 3.1.3. Certificate-Enabled Client: Bên được cấp phát chứng chỉ Bên được cấp phát chứng chỉ (hay còn gọi là PKI client) thường yêu cầu CA hoặc RA cấp phát chứng chỉ. Để có được chứng chỉ từ CA, PKI client thực hiện các bước sau Gửi yêu cầu tạo cặp khoá công khai/khóa riêng. CA hoặc client có thể thực hiện nhiệm vụ này. Cặp khóa chứa chi tiết của client Sau khi cặp khoá được tạo ra, client gửi yêu cầu cho CA yêu cầu chứng chỉ. Sau khi client nhận được chứng chỉ từ CA, nó có thể sử dụng chứng chỉ để chứng minh danh tính của chính nó và được xem như một người sở hữu chứng chỉ đã được xác thực Tất cả các kết nối giữa client và CA đều được giữ an toàn. Hơn nữa, client chịu trách nhiệm đảm bảo an toàn cho khoá riêng Ví dụ VPN Client, trình duyệt Làm nhiệm vụ ký và mã hoá 3.1.4. Data Recipient : Bên nhận dữ liệu Ví dụ Web Server, VPN Gateway Làm nhiệm vụ xác minh và giải mã 3.1.5. Kho lưu trữ/thu hồi chứng chỉ Để làm thuận tiện quá trình phân phối, chứng chỉ có thể được công bố trong kho chứng chỉ. Kho chứng chỉ phân phối chứng chỉ tới người dùng và các tổ chức . Kho chứng chỉ có chứa chứng chỉ, danh sách huỷ bỏ chứng chỉ, danh sách huỷ bỏ thẩm quyền và một số thứ khác có liên quan tới đối tượng , ví dụ như chính sách của các đối tượng. Chứng chỉ có thể được phân phối bởi chính người dùng hoặc được phân phối bằng một máy chủ thư mục mà sử dụng LDAP để truy vấn thông tin người dùng. Hệ thống phân phối chứng chỉ được sử dụng để thực hiện các nhiệm vụ sau Tạo và cấp phát cặp khoá Chứng thực tính hợp lệ của khoá công khai bằng cách ký vào khoá công khai Thu hồi các khoá đã hết hạn Công bố khoá công khai trong máy chủ dịch vụ thư mục 3.1.6.Chuỗi chứng chỉ hoạt động như thế nào Khi ta nhận được chứng chỉ từ một thực thể khác, ta sẽ cần phải sử dụng chuỗi chứng chỉ để thu được chứng chỉ của root CA. Chuỗi chứng chỉ, hay còn được gọi là đường dẫn chứng chỉ, là một danh sách các chứng chỉ được sử dụng để xác thực thực thể. Chuỗi chứng chỉ sẽ bắt đầu với chứng chỉ của thực thể đó, và mỗi chứng chỉ trong chuỗi sẽ được ký bởi thực thể đã được xác định bởi chứng chỉ kế tiếp trong chuỗi. Chứng chỉ kết thúc là chứng chỉ của rootCA. Chứng chỉ của root CA luôn luôn được ký bởi chính nó. Chữ ký của tất cả các chứng chỉ trong chuỗi phải được xác minh cho tới chứng chỉ của root CA. Sơ đồ sau minh họa đường dẫn chứng chỉ từ người sở hữu chứng chỉ tới rootCA, nơi chuỗi tin cậy bắt đầu Hình 10: Chuỗi chứng chỉ 3.2. Cách thức làm việc của PKI Các hoạt động của PKI bao gồm - Khởi tạo thực thể cuối - Tạo cặp khoá - Áp dụng chữ ký số để xác định danh tính người gửi - Mã hoá thông báo - Truyền khoá đối xứng - Kiểm tra định danh người gửi thông qua một CA - Giải mã thông báo và kiểm tra nội dung của nó 3.2.1. Khởi tạo thực thể cuối Trước khi các thực thể cuối có thể tham gia và các dịch vụ được hỗ trợ bởi PKI, các thực thể này cần phải được khởi tạo trong PKI. Đăng ký thực thể cuối là một quá trình mà trong đó danh tính của cá nhân được xác minh. Quá trình đăng ký thực thể cuối được thực hiện trực tuyến. Quá trình đăng ký trực tuyến cần phải được xác thực và được bảo vệ 3.2.2. Tạo cặp khoá công khai/khoá riêng Người dùng muốn mã hoá và gửi thông báo đầu tiên phải tạo ra một cặp khoá công khai/khoá riêng. Cặp khoá này là duy nhât đối với mỗi người dùng trong PKI Trong mô hình PKI toàn diện, có thể tạo khoá trong hệ thống máy trạm của người dùng cuối hoặc trong hệ thống của CA. Vị trí tạo cặp khoá được xem là quan trọng. Các nhân tố có tác động tới vị trí tạo cặp khoá bao gồm khả năng, hiệu suất, tính đảm bảo, sự phân nhánh hợp pháp và cách sử dụng khoá theo chủ định Cho dù là vị trí tạo khoá ở đâu thì trách nhiệm đối với việc tạo chứng chỉ chỉ dựa vào CA được cấp quyền. Nếu khoá công khai được tạo bởi thực thể, thì khoá công khai đó phải được chuyển tới CA một cách an toàn Một khi khoá và chứng chỉ có liên quan được tạo ra, chúng phải được phân phối một cách thích hợp. Việc phân phối chứng chỉ và khoá yêu cầu dựa trên một vài nhân tố, bao gồm cả vị trí tạo khoá, mục đích sử dụng và các mối quan tâm khác như là những ràng buộc về chức năng, chính sách. Chứng chỉ được tạo ra có thể được phân phối trực tiếp tới người sở hữu, hoặc tới kho chứng chỉ ở xa hoặc cả hai. Điều này sẽ phụ thuộc vào mục đích sử dụng khoá và các mối quan tâm về chức năng. Nếu khoá được tạo ở hệ thống máy khách, thì khoá riêng đã được lưu trữ bởi người sở hữu khoá riêng, và không cần có yêu cầu phân phối khoá (không áp dụng với dự phòng khoá). Tuy nhiên, nếu khoá được tạo ra ở một nơi khác, thì khoá riêng phải được phân phối một cách an toàn tới người sở hữu khoá đó. Có rất nhiều cơ chế có thể được sử dụng để thực hiện điều này. Cũng cần phải chú ý rằng, nếu khoá được tạo ra được dùng cho mục đích chống chối bỏ thì khoá đó cần được tạo tại vị trí máy khách của thực thể 3.2.3. Áp dụng chữ ký số để định danh người gửi. Một chữ ký số được đính kèm với thông báo để xác định danh tính người gửi thông báo đó. Để tạo ra một chữ ký số và đính kèm nó đến thông báo cần thực hiện như sau: 1. Biến đổi thông báo ban đầu thành một chuỗi có độ dài cố định bằng cách áp dụng hàm băm trên thông báo. Quá trình này có thể gọi là băm thông báo, chuỗi có độ dài cố định được xem gọi là bản tóm lược thông báo 2. Mã hóa bản tóm lược thông báo bằng khóa riêng của người gửi. Kết quả của tóm lược thông báo đã mã hóa là chữ ký số. 3. Đính kèm chữ ký số với thông báo ban đầu 3.2.4. Mã hóa thông báo Sau khi áp dụng chữ ký số lên thông báo ban đầu, để bảo vệ nó ta sẽ mã hóa. Để mã hóa thông báo và chữ ký số, sử dụng mật mã khóa đối xứng. Khóa đối xứng này được thỏa thuận trước giữa người gửi và người nhận thông báo và chỉ được sử dụng một lần cho việc mã hóa và giải mã. 3.2.5. Truyền khóa đối xứng. Sau khi mã hóa thông báo và chữ ký số, khóa đối xứng mà được sử dụng để mã hóa cần truyền đến người nhận. Bản thân khóa đối xứng cũng được mã hóa vì lý do an toàn, nếu bị lộ thì bất kỳ người nào cũng có thể giải mã thông báo. Do đó, khoá đối xứng sẽ được mã hoá bằng khoá công khai của người nhận. Chỉ có người nhận mới có thể giải mã được khóa đối xứng bằng việc sử dụng khóa riêng tương ứng. Sau khi đã được mã hóa, khóa phiên và thông báo sẽ được chuyển đến người nhận thông báo. 3.2.6. Kiểm tra danh tính người gửi thông qua một CA CA đóng vai trò là một bên thứ 3 tin cậy để xác minh danh tính của các thực thể đang tham gia trong quá trình giao dịch. Khi người nhận nhận một bản mã, người nhận có thể yêu cầu CA kiểm tra chữ ký số đính kèm theo thông báo đó. Dựa trên yêu cầu đó, CA kiểm tra chữ ký số của người gửi thông báo. 3.2.7. Giải mã thông báo và kiểm tra nội dung thông báo. Sau khi nhận thông báo đã được mã hoá, người nhận cần giải mã. Bản mã chỉ có thể được giải mã bằng khóa đối xứng đã được mã hoá. Vì vậy, trước khi giải mã thông báo, khóa đối xứng phải được giải mã bằng khóa riêng của người nhận. Sau khi đã giải mã khoá đối xứng, khoá đối xứng sẽ được dùng để giải mã thông báo.Chữ ký số đính kèm với thông báo được giải mã bằng khóa công khai của người gửi và bản tóm lược thông báo được bóc tách ra từ nó. Người nhận sau đó sẽ tạo ra một bản tóm lược thông báo thứ hai. Cả hai thông báo băm sau đó được so sánh để kiểm tra xem có bất kỳ sự giả mạo của thông báo xảy ra trong quá trình truyền tin không. Nếu hai thông báo băm trùng khít nhau chứng tỏ thông báo không bị giả mạo trong khi truyền. Các tiêu chí cơ bản của một giao dịch điện tử: Chống chối bỏ: Tất cả các thực thể liên quan trong giao dịch không thể từ chối mình là một phần của giao dịch đó. Truyền tin an toàn: Đây là một cơ chế đúng đắn để đảm bảo an toàn thông báo trong truyền tin. Bất kỳ sự giả mạo hoặc thay đổi được làm trên thông báo phải được phát hiện dễ dàng. Tính riêng tư: Bất kỳ sự truy nhập bất hợp pháp đến thông báo đều bị từ chối. Sự xác thực: Để định danh các thực thể đang là một phần liên lạc trong quá trình giao dịch thì cân phải biết đến cả hai thực thể. Tính ràng buộc: Giao dịch nên được kiểm tra và được ký bởi các bên liên quan. PKI đảm bảo rằng tất cả các giao dịch có thể đáp ứng các yêu cầu hợp pháp bằng cách cung cấp cơ sở hạ tầng và môi trường cần thiết . 3.3. Các tiến trình trong PKI Các ứng dụng có thể đạt được các chức năng an toàn khi sử dụng PKI. Các chức năng an toàn đó là tính bí mật, tính toàn vẹn, tính xác thực và tính chống chối bỏ Mỗi một tiến trình trong PKI sẽ thực hiện các yêu cầu an toàn đã được đề cập ở trên. 3.3.1. Yêu cầu chứng chỉ Để có được chứng chỉ số từ CA, người dùng cần gửi yêu cầu chứng chỉ. Có rất nhiều chuẩn để gửi yêu cầu chứng chỉ và chuẩn phổ biến nhất đó là PKCS#10. Yêu cầu chứng chỉ chứa các trường sau Tên phân biệt của CA Khoá công khai của người dùng Tên thuật toán Chữ ký số của người dùng Người dùng gửi yêu cầu chứng chỉ PKCS tới cho CA thông qua một kênh an toàn. Nếu kênh này không được đảm bảo an toàn, thì người dùng tải khoá công khai của CA và mã hoá yêu cầu này bằng khoá công khai của CA 3.3.1.1. Gửi yêu cầu Yêu cầu chứng chỉ được gửi cho tới CA bằng một thư điện tử, sử dụng PEM (Privacy). Yêu cầu chứng chỉ phải được gửi trong định dạng PEM bởi vì yêu cầu ban đầu được tạo ra bằng mã nhị phân. Mã nhị phân này không thể được truyền bằng email. Với chữ ký số trong yêu cầu chứng chỉ, CA có thể chắc chắn rằng người gửi có một khoá riêng tương ứng với khoá công khai. Do đó, người gửi được chứng minh sở hữu Client cũng có thể đưa ra yêu cầu khoá thông qua trình duyệt Web. Trong trường hợp này, PKCS#10 được sử dụng cùng với SSL. Client thực hiện một kết nối SSL với máy chủ chứng chỉ và sau đó truyền yêu cầu chứng chỉ thông qua một kênh an toàn 3.3.1.2. Các chính sách Chính sách an toàn định nghĩa một hướng dẫn cho tổ chức để đảm bảo an toàn thông tin, các tiến trình và các nguyên tắc sử dụng mật mã. Chính sách định nghĩa tổ chức đó quản lý khoá công khai, khoá riêng và các thông tin khác như mức kiểm soát được yêu cầu để quản lý các nhân tố gây mất an toàn như thế nào Một vài hệ thống PKI được vận hành bởi bên thứ ba tin cậy được gọi là thẩm quyền chứng thực thương mại (Commercial Certificate Authorites) và do đó sẽ yêu cầu một CPS (Certification Pratice Statement). CPS định nghĩa các chính sách sẽ được triển khai và hỗ trợ như thễ nào, chứng chỉ sẽ được cấp phát, được chấp nhận và bị thu hồi như thế nào và khoá công khai sẽ được tạo, được đăng ký và được chứng thực như thế nào. CPS cũng định nghĩa vị trí của những khoá này 3.3.2. Huỷ bỏ chứng chỉ Mỗi chứng chỉ đều có một giai đoạn hợp lệ. Giai đoạn hợp lệ của chứng chỉ được tính từ thời gian chứng chỉ được cấp phát tới khi chứng chỉ hết hạn. Tuy nhiên, có những trường hợp, chứng chỉ bị mất tính hợp lệ trước khoảng thời gian hết hạn. Trong trường hợp này, chứng chỉ cũng được phép tiếp tục sử dụng. Tình huống này nảy sinh khi độ an toàn của chứng chỉ không còn (ví dụ như lộ khoá). Khi chứng chỉ bị mất tính hợp lệ của nó trước thời hạn, thì được gọi là huỷ bỏ chứng chỉ. Chứng chỉ bị huỷ bỏ sẽ phải được công khai . Thông tin về chứng chỉ bị huỷ bỏ sẽ được công bố trên máy chủ chứng chỉ sao cho người dùng có thể được cảnh báo những chứng chỉ đó. Một cách thông thường khác cũng hay được sử dụng đó là sử dụng danh sách hủy bỏ chứng chỉ. 3.4. Các mô hình PKI 3.4.1. Mô hình phân cấp CA chặt chẽ (strict hierarchy of CAs) Trong mô hình này, có 1 CA đóng vai trò là CA gốc ở trên cùng, phía dưới là các nhánh mở rộng và các lá ở cuối cùng RootCA đóng vai trò như là gốc tin cậy (hay còn gọi là “nguồn tin cậy”) cho toàn bộ miền của các thực thể PKI dưới nó. Ở dưới root CA có thể không có hoặc có một vài lớp intermediate CA (hay còn gọi là subCA) Hình 11: Mô hình phân cấp CA chặt chẽ RootCA không đơn giản là điểm khởi đầu của một mạng, hay các kết nối, nó còn là điểm khởi đầu của sự tin cậy. Tất cả các thực thể trong miền đều nắm giữ khoá công khai của CA Trong mô hình này, tất cả các thực thể trong kiến trúc tin cậy rootCA. Sự phân cấp được thiết lập như sau RootCA được xây dựng, và tự cấp chứng chỉ cho mình (hay tự ký cho mình) RootCA sẽ chứng thực (tạo và ký chứng chỉ) cho các CA trực tiếp dưới nó Mỗi một CA như trên lại chứng thực cho CA trực tiếp dưới nó Tại mức gần cuối cùng, CA sẽ chứng thực thực thể cuối Mỗi thực thể trong phân cấp phải được cung cấp bản sao khoá công khai của root CA. Quá trình tạo khoá công khai này là cơ sở cho quá trình chứng thực tất cả các kết nối sau đó, do đó, quá trình này phải được thực hiện trên một cách an toàn Chú ý rằng trong mô hình phân cấp chặt chẽ đa mức (multilevel strict hierarchy), các thực thể cuối được chứng thực (nghĩa là được cấp chứng chỉ) bởi CA trực tiếp ngay trên nó, nhưng gốc tin cậy thì lại là rootCA. 3.4.2.Mô hình phân cấp CA không chặt chẽ (loose hierarchy of CAs) Trong mô hình phân cấp CA không chặt chẽ các bên được chứng thực bởi cùng một CA để giải quyết vấn đề đường dẫn tin cậy mà không liên quan tới bất kỳ CA mức cao hơn, bao gồm cả root CA. Nghĩa là nếu hai thực thể (ví dụ thực thể A và thực thể B) được chứng thực bởi cùng một CA, thì thực thể A và thực thể B có thể kiếm tra tính hợp lệ của nhau mà không cần phải tạo một đường dẫn chứng thực tới root CA. Về cơ bản, thực thể A và thực thể B cùng thuộc về phân cấp chủ thể tin cậy của cả hai. Tuy nhiên, giả sử rằng có một thực thể C nào đó được chứng thực bởi một CA khác (không phải CA chứng thực cho A và B) thì thực thể A và B phải thực hiện một đường dẫn chứng thực hoàn toàn thông qua rootCA trước khi tin cậy chứng chỉ của C 3.4.3.Mô hình kiến trúc tin cậy phân tán (distributed trust architecture) Kiến trúc tin cậy phân tán sẽ phân phối sự tin cậy giữa hai hay nhiều CA. Nghĩa là thực thể 1 có thể giữ bản sao khoá công khai của CA1 như nguồn tin cậy của mình, thực thể 2 có thể giữ bản sao khoá công khai của CA2 như nguồn tin cậy của mình. Bởi vì những khoá công khai của những CA này đóng vai trò như nguồn tin cậy (CA1 là gốc(root) của hệ thống phân cấp chứa thực thể 1, CA2 là gốc của hệ thống phân cấp có chứa thực thể 2) Nếu mỗi kiến trúc phân cấp này là kiến trúc phân cấp không chặt chẽ, thì cấu hình của kiến trúc đó được gọi là kiến trúc được chia điểm (peered architeture) bởi vì tất cả các CA đều là những điểm hoàn toàn độc lập (Không có SubCA trong kiến trúc). Trái lại, nếu kiến trúc đó là phân cấp đa mức, thì kiến trúc đó được gọi là kiến trúc hình cây (treed architeture) (chú ý rằng các root CA là các điểm so với các CA khác nhưng mỗi root lại đóng vai trò như CA cấp cao đối với một hoặc nhiều SubCA) Hình 12: Mô hình kiến trúc tin cậy phân tán Thông thường thì kiến trúc được chia điểm thường được xây dựng trong một miền của một tổ chức (ví dụ trong một công ty), trái lại, kiến trúc hình cây và kiến trúc lai (hybrid architeture) được hình thành từ các miền của các tổ chức khác nhau Quá trình của việc tạo kết nối mỗi root CA thông thường được gọi là chứng thực chéo (cross-certification) 3.4.4. Mô hình 4 bên (four-corner model) Hình 13: Mô hình bốn bên Trong mô hình này minh họa bốn góc của mô hình tin cậy là người thuê bao (subscriber), bên tin cậy (relying party), thuê bao của CA (subscriber’s CA) và bên tin cậy của CA (relying party’s CA) Mô hình tin cậy 4 bên này thường được triển khai trong các giao dịch thanh toán điện tử Trong mô hình này , thuê bao sử dụng chứng chỉ được cấp bởi CA của nó Thuê bao và bên tin cậy tương tác và ràng buộc nhau trong các giao dịch điện tử Bên tin cậy tương tác với miền CA (CA domain) của nó để xác thực cho mỗi phiên giao dịch Miền CA tương tác khi có yêu cầu xác minh tính hợp lệ/cấp quyền phiên giao dịch 3.4.5. Mô hình Web (web model) Mô hình Web – đúng như tên gọi của nó, phụ thuộc vào các trình duyệt Web phổ biến như Netscape Navigator và Microsoft Internet Explorer. Trong mô hình này, số lượng khoá công khai của CA sẽ được cài đặt sẵn vào một số các trình duyệt. Các khoá này sẽ định nghĩa tập hợp các CA mà trình người dùng trình duyệt ban đầu sẽ tin tưởng và xem như các root cho việc xác minh chứng chỉ Hình 14: Mô hình Web Mỗi nhà cung cấp trình duyệt đều có root của riêng mình, và nó sẽ chứng thực root CA mà được nhúng trong trình duyệt. Mô hình Web có những ưu điểm rõ rệt để thuận tiện và đơn giản khả năng liên kết. Tuy nhiên, có một vài sự vấn đề an toàn cần được quan tâm trong mô hình này khi quyết định triển khai. Ví dụ, bởi vì người dùng trình duyệt tự động tin tưởng vào tập hợp các khoá đã được cài sẵn trong trình duyệt, nên an toàn sẽ có thể bị mất nếu một trong số các rootCA đó “rơi vào tình trạng nguy hiểm” Một vấn đề an toàn nữa cũng cần phải được quan tâm đó là trong mô hình Web, không có cơ chế thực thế nào có thể thu hồi bấy kỳ khoá của root đã được nhúng trong trình duyệt. Nếu chúng ta phát hiện ra một trong những CA “đang trong tình trạng nguy hiểm” hoặc khoá riêng tương ứng với bất kỳ khoá công khai của root bị lộ, thì hiển nhiên là không thể tiếp tục sử dụng khoá đó trong hàng triệu các trình duyệt web trên thế giới 3.4.6.Mô hình tin cậy lấy người dùng làm trung tâm (user-centric trust) Trong mô hình tin cậy lấy người dùng làm trung tâm, mỗi người dùng sẽ phải chịu trách nhiệm trực tiếp và toàn bộ để quyết định xem sẽ sử dụng chứng chỉ nào và từ chối chứng chỉ nào. Mỗi người dùng sẽ giữ một vòng khoá và vòng khoá này đóng vai trò như CA của họ. Vòng khoá này chứa các khoá công khai được tin cậy của những người sử dụng khác trong cộng đồng. Mô hình này được Zimmerman phát triển để sử dụng trong chương trình phát triển phần mềm bảo mật PGP Quyết định này có thể chịu ảnh hưởng của một số các nhân tố, mặc dù ban đầu tập hợp các khoá được tin cậy thông thường bao gồm các nhân tố là bạn bè, gia đình, đồng nghiệp … Hình 15: Mô hình tin cậy lấy người dùng làm trung tâm Mô hình này được sử dụng rộng rãi trong phần mềm an ninh nổi tiếng là Pretty Good Privacy (PGP) [Zimm95, Garf95]. Trong PGP, người dùng xây dựng mạng lưới tín nhiệm (web of trust) đóng vai trò là CA (ký lên khoá công khai cho các thực thể khác) Do sự tín nhiệm của người dùng trong các họat động và các quyết định, nên mô hình tin cậy lấy người dùng làm trung tâm có thể họat động được trong cộng đồng đòi hỏi kỹ thuật và sự quan tâm cao độ, nhưng nó không thực tế đối với cộng đồng chung (cộng đồng mà trong đó nhiều người dùng chỉ có một chút hoặc không có sự hiểu biết về các khái niệm PKI hay khái niệm an toàn). Hơn nữa, một mô hình như vậy thông thường không phù hợp với các môi trường của công ty, tổ chức tài chính hoặc chính phủ 3.5.Các kiểu kiến trúc PKI Có một vài kiểu kiến trúc mà PKI có thể triển khai để cung cấp “chuỗi tin cậy” từ một khoá công khai đã biết nhằm xác thực thông qua khoá công khai cụ thể của người dùng. Ví dụ khi người dùng xác thực họ với các ứng dụng của với e-Government, thì phần mềm ứng dụng mật mã sẽ xác minh chữ ký trong chứng chỉ của người dùng bằng cách sử dụng khoá công khai của CA mà tạo ra chứng chỉ đó. Nếu khoá của CA không phải là khoá của root, thì chứng chỉ chứa nó cũng sẽ phải được xác minh tính hợp lệ bằng khoá công khai mà ký chứng chỉ đó. Và tiếp tục đến khi nào chứng chỉ trong “chuỗi tin cậy” có thể được xác minh bằng khóa của root. Chuỗi xác minh tính hợp lệ có nghĩa là sẽ xác thực tất cả các chứng chỉ,bao gồm cả chứng chỉ của người dùng cuối Hình 16: Chuỗi tin cậy 3.5.1. Kiến trúc kiểu Web of Trust Đối với kiểu kiến trúc này, mỗi người dùng sẽ tạo và ký chứng chỉ cho người mà mình đã biết. Do đó, không cần phát triển phải có hạ tầng trung tâm Hình 17: Kiến trúc kiểu Web of Trust Mô hình này hoạt động rất hiệu quả đối với tổ chức nhỏ, có sự tồn tại mối quan hệ trước đó, nhưng nó không hiệu quả đối với tổ chức lớn hoặc nơi mà cần phải có sự đảm bảo (ví dụ phải xác thực được yêu cầu trước khi chứng chỉ được cấp phát). Sự giao tiếp của trạng thái chứng chỉ đối với các bên tin cậy (ví dụ như chứng chỉ bị thu hồi) cũng là rất khó với mô hình này 3.5.2.Kiến trúc kiểu CA đơn (Single CA) Dạng kiến trúc đơn giản nhất là single CA. Kiến trúc này cấp chứng chỉ và cung cấp thông tin trạng thái chứng chỉ cho mỗi người dùng. Khoá công khai của CA là điểm tin cậy cơ bản , hay còn gọi là nguồn tin cậy, được dùng để đánh giá khả năng chấp nhận chứng chỉ. Người dùng có mối quan hệ trực tiếp với CA, vì vậy họ biết những ứng dụng nào mà chứng chỉ cần được sử dụng. Trong một vài tổ chức chỉ yêu cầu các dịch vụ PKI cơ bản. Điển hình, đó là các tổ chức với hơn 3000 tài khoản của user trong dịch vụ thư mục. Thay vì triển khai CA nhiều mức, thì thông thường người ta sẽ triển khai một CA , được cài đặt và đóng vai trò là enterprise root CA.Enterprise root CA không thể được di chuyển trong mạng, thay vào đó, sẽ có một máy tính là thành viên của miền và luôn luôn sẵn sàng cấp phát chứng chỉ đối với các yêu cầu cấp phát của máy tính, người dùng, các dịch vụ và các thiết bị mạng Kiểu kiến trúc single CA dễ quản lý bởi vì nó việc quản trị chỉ liên quan tới một CA root. Tuy nhiên, nếu CA bị lỗi, thì dịch vụ chứng chỉ sẽ không sẵn sàng để xử lý các yêu cầu chứng chỉ, các yêu cầu làm mới chứng chỉ hay danh sách thu hồi chứng chỉ cho tới khi CA khôi phục lại được dịch vụ Kiến trúc phân cấp single CA thông thường chỉ được sử dụng khi việc quản trị là đơn giản, giá thành thấp Hình 18: Kiến trúc CA đơn Dạng mở rộng của kiểu kiến trúc CA này là kết nối các CA để hỗ trợ các cộng đồng người dùng khác nhau. Các tổ chức có thể kết nối các CA cô lập thành các PKI lớn sử dụng mối quan hệ điểm -điểm 3.5.3. Kiến trúc CA phân cấp Kiến trúc mô hình CA phân cấp bao gồm có một root CA ở trên đỉnh, phía dưới là một hay hai lớp CA (khoá công khai của các CA này được ký bởi root CA) và sau đó là các thuê bao và các RA ở phía dưới. Mỗi khoá được tin tưởng nhất của người dùng là khoá công khai của root CA. Mô hình này cho phép sự thi hành các chính sách và các chuẩn thông qua hạ tầng, tạo ra mức đảm bảo tổng thể cao hơn là các kiến trúc đa CA khác. Hình 19: Kiến trúc CA phân cấp Trong mô hình này, root CA sẽ cấp chứng chỉ cho các sub CA nhưng không cấp chứng chỉ cho người dùng. Các subCA này lại cấp chứng chỉ cho các subCA khác hoặc cho người dùng 3.5.4. Kiến trúc kiểu chứng thực chéo (Cross-certificate) Trong mô hình này, mỗi CA tạo ra các chứng chỉ cho các CA mà đã xác minh là đã “đủ mạnh” để sở hữu chứng chỉ. Trong mô hình phân cấp, mỗi người chỉ có một khoá công khai của root, nhưng trong mô hình này, khoá đó lại là khoá của CA cục bộ của chúng chứ không phải là khoá của rootCA. Hình 20: Kiến trúc kiểu chứng thực chéo Một vấn đề của mô hình này là khó khăn với ứng dụng người dùng để xác định chuỗi chứng chỉ giữa người dùng sở hữu CA không có đường liên kết chứng thực chéo Mô hình này phải đối mặt với vấn đề “ai là root CA” (không ai/ hoặc là tất cả các CA), cho phép các CA trở thành cấu trúc điểm thay vì phân cấp, nhưng cũng giống như mô hình Web of Trust, chứng thực chéo sẽ tạo ra mức bảo đảm đồng nhất cho toàn hệ thống 3.5.5. Kiến trúc Bridge CA(BCA) Bridge CA được thiết kế để giải quyết các thiếu sót trong các kiến trúc PKI cơ bản và tạo kết nối các PKI khác nhau. Bridge CA không cấp chứng chỉ cho người dùng và chúng không phải là nguồn tin cậy. Thay vào đó, Bridge CA sẽ thiết lập mối quan hệ tin cậy peer to peer (P2P) giữa các cộng đồng người dùng khác nhau và làm giảm nhẹ vấn đề cấp phát chứng chỉ giữa các tổ chức trong khi đó lại cho phép người dùng giữ được nguồn tin cậy Hình 21: Kiến trúc Bridge CA Trong kiểu kiến trúc này, Bridge CA sẽ cung cấp một cái cầu tin cậy (thông qua cặp chứng thực chéo) giữa các cơ sở hạ tầng khoá công khai phân cấp và cơ sở hạ tầng khoá công khai chứng thực chéo. Độ phức tạp của mô hình này khá cao và có thể phải điều chỉnh các module PKI của người dùng cuối. Mỗi một mối quan hệ tin cậy Bridge CA được thể hiện bằng m