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

otCA đó “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ột cặp chứng chỉ, một được cấp phát bởi BCA CHƯƠNG IV: XÂY DỰNG MÔ HÌNH PKI DỰA TRÊN MÃ NGUỒN MỞ OPENCA 4.1.Lịch sử phát triển OpenCA Cơ sở hạ tầng khoá công khai (PKI) là một trong những nhu cầu thiết yếu của tương lai. Nhưng vấn đề là hầu hết các ứng dụng có thể được đảm bảo an toàn bằng chứng chỉ và khoá nhưng lại rất khó và đắt đề cài đặt PKI, lý dó là phần mềm trung tâm tin cậy có tính linh hoạt thì lại rất đắt. Đây là điểm khởi đầu của OpenCA. Mục đích là sản phẩm của hệ thống trung tâm tin cậy nguồn mở để hỗ trợ cộng đồng với các giải pháp tốt, rẻ(chi phí hợp lý) và mang tính xu hướng trong tương lai Dự án OpenCA được bắt đầu vào năm 1998. Ý tưởng OpenCA ban đầu được phát triển bởi Massimiliano Pala. Mã nguồn ban đầu của dự án được viết với đoạn script rất dài. Khi phiên bản đầu tiên của phần mềm được xây dựng, thì dự án OpenSSL vẫn có tên là SSLeay . Rất nhiều chức năng vẫn còn lỗi và nhiều thứ khác nữa đều đang bị bỏ qua Việc cài đặt phần mềm ban đầu rất đơn giản và chỉ có một vài đoạn script khởi tạo CA. Để cài đặt nhanh chóng phần mềm, bạn chỉ cần giải nén gói đó, dùng lệnh cd để chuyển vào gói vừa giải nén đó và sử dụng lệnh “make install”, đoạn script sau đó sẽ chạy và tiến hành cài đặt phần mềm CA đơn giản và tạo ra chứng chỉ CA Một loạt các đoạn script được cung cấp sẽ giúp cho việc cài đặt và cấu hình cho hầu hết các phần của dự án. Mặc dù đơn giản như vậy, nhưng giải pháp này gây ra rất nhiều vấn đề với cộng đồng người dùng bởi vì các vấn đề nảy sinh từ việc nhu cầu cần phải tạo ra một gói đầy đủ và tốt hơn. Phiên bản đầu tiên của OpenCA rất đơn giản, nhiều chức năng được xây dựng chủ yếu chỉ được dùng để cấp phát chứng chỉ, CRL và các phương thức cài đặt thì khá đơn sơ, không có tính tiện dụng cho bất kỳ tiện ích cấu hình nào , đoạn script chỉ có thể tương thích với bash Các phiên bản tiếp theo được bổ sung thêm nhiều tính năng hơn cho dự án và do đó phiên bản 0.109 đã bao gồm giao diện cho server của CA, RA và Pub. Từ lúc bắt đầu dự án và từ phát hành phiên bản đầu tiên, đã có một lượng lớn sự tham gia của cộng đồng Internet đóng góp vào sự phát triển của dự án 4.2. CA Trong phần trước, em đã nêu ra khái niệm về CA, trong phần này, em xin phép được đề cập cụ thể hơn về CA 4.2.1.Chức năng của CA 4.2.1.1. Cấp phát chứng chỉ CA xác thực người dùng bằng cách cấp phát chứng chỉ số. Để có thể có được chứng chỉ số của CA, người dùng cần thực hiện các bước sau Tạo ra cặp khoá riêng/khoá công khai của mình Khi cặp khoá đã được tạo, người dùng cần phải đăng ký khoá công khai của mình với CA Người dùng gửi yêu cầu cấp chứng chỉ tới cho RA RA sẽ kiểm tra danh tính người dùng. Khi đã kiểm tra xong, RA sẽ chuyển yêu cầu đó cho CA CA ký chứng chỉ bằng khoá riêng của mình và gửi chứng chỉ cho RA. RA sẽ chuyển chứng chỉ mà đã nhận được từ CA cho người dùng đã đăng ký 4.2.1.2.Huỷ bỏ chứng chỉ Mỗi chứng chỉ đều có một giai đoạn hợp lệ. Tuy nhiên, trong một số trường hợp mà chứng chỉ có thể không hợp lệ trước giai đoạn hợp lệ là Có sự lộ khoá riêng của thực thể Có sự thay đổi thông tin thuộc tính của thực thể, ví dụ như tên thực thể hoặc mối quan hệ của thực thể với tổ chức Có sự lộ khóa của CA Do đó, cần phải có sự huỷ bỏ chứng chỉ Một vài các phương thức mà CA có thể sử dụng để huỷ bỏ chứng chỉ gồm Các cơ chế Cơ chế công bố định kỳ: Cơ chế này sử dụng danh sách huỷ bỏ chứng chỉ. Danh sách huỷ bỏ chứng chỉ là một danh sách Cơ chế truy vấn online: Cơ chế truy vấn online bao gồm có giao thức trạng thái chứng chỉ và giao thức xác định tính hợp lệ của các phiên giao dịch trực tuyến: OCSP được sử dụng để đưa ra các thông tin thu hồi chứng chỉ. Giao thức xác định tính hợp lệ của các phiên giao dịch trực tuyến được sử dụng để xác minh tính hợp lệ trực tuyến 4.2.1.3.Tạo lập chính sách chứng chỉ Chính sách chứng chỉ là một tập hợp các luật hay còn gọi là các quy tắc được tạo lập bởi CA để chỉ ra khả năng ứng dụng của chứng chỉ đối với một nhóm người cụ thể hoặc tập các ứng dụng Mục đích chính của các chính sách chứng chỉ là để xác định chính sách an toàn mà một tổ chức phải tuân theo 4.2.1.4.Hướng dẫn thực hiện chứng chỉ số (Certification Practice Statement) Hướng dẫn thực hành chứng chỉ số sẽ chỉ ra chứng thực sẽ được thực hiện như thế nào. Tài liệu này sẽ miêu tả các thủ tục, hoạt động mà đã được định nghĩa trong chính sách chứng chỉ sẽ được triển khai, thực hiện như thế nào CPS sẽ chỉ ra các chính sách và các thủ tục mà một công ty , tổ chức phải tuân theo để cấp phát và quản lý chứng chỉ CA có thể được xem như bên thứ ba tin cậy như VeriSign hoặc Thawte hoặc có thể là một thực thể bên trong của một tổ chức 4.2.2.Nhiệm vụ của CA Chấp nhận các yêu cầu cấp chứng chỉ từ người dùng, máy tính , ứng dụng hoặc thiết bị Xác thực định danh người dùng, máy tính, dịch vụ yêu cầu chứng chỉ Tạo chứng chỉ cho người yêu cầu Ký số chứng chỉ sử dụng khoá riêng của mình 4.2.3. Các loại CA Có hai loại CA cơ bản . Các loại CA được phân biệt bằng vị trí mà chúng lưu trữ chứng chỉ 4.2.3.1.Enterprise CA: Enterprise CA lưu trữ bản sao của chứng chỉ CA trong Active Directory. Loại CA này tận dụng các mẫu chứng chỉ để công bố chứng chỉ và danh sách thu hồi chứng chỉ. Enterprise CA sẽ hồi đáp tự động tới bất kỳ yêu cầu chứng chỉ nào. Điều này về cơ bản cho phép các client truy cập và lấy được chứng chỉ và lưu giữ chứng chỉ trong kho chứng chỉ cục bộ của mình. Chính vì đặc điểm này, nên EnterpriseCA không được sử dụng để cấp phát chứng chỉ cho các client bên ngoài tổ chức Enterprise CA được cấu hình như Domain Controller 4.2.3.2.Standalone CA Standalone CA lưu giữ cục bộ thông tin trên chứng chỉ , trong một folder chia sẻ mà ta có thể truy cập thông qua Web. Standalone CA phụ thuộc vào người quản trị có chấp thuận hay từ chối yêu cầu chứng chỉ. Standalone CA được sử dụng để cấp phát chứng chỉ cho người dùng bên ngoài tổ chức 4.2.4.Các cấp CA 4.2.4.1.Root CA(CA gốc) Root CA là CA mức cao nhất được xem như thẩm quyền đối với tất cả các CA phụ thuộc được đặt ở dưới nó. RootCA làm nhiệm vụ cấp chứng chỉ cho tất cả các CA phụ thuộc. RootCA khác với các CA khác là nó tự tạo chứng chỉ cho chính mình. Trong mô hình phân cấp, khi một client tin tưởng root CA, thì nó cũng phải tin tưởng các CA phụ thuộc được đặt ở dưới root CA 4.2.4.2.Subordinate CA(CA phụ thuộc): Subordinate CA (SubCA- CA con): là CA được chứng thực bởi CA cha. CA cha chứng thực CA con bằng cách cấp phát và ký chứng chỉ cho CA con. Có hai loại CA phụ thuộc trong kiến trúc phân cấp là Intermediate CA và Issuing CA Intermediate CA: Intermediate CA là CA phụ thuộc được đặt giữa root CA và các CA phụ thuộc khác. Chức năng của Intermediate CA là cấp phát chứng chỉ cho CA mức lá Issuing CA (CA mức lá): Issuing CA là CA ở mức thấp nhất. Chức năng của Issuing CA là cấp phát chứng chỉ cho các máy tính khác, người dùng, các thiết bị mạng, server và các dịch vụ yêu cầu CA Issuing CA luôn luôn ở chế độ online Hình 22: Sơ đồ minh họa rootCA và SubCA 4.3. Thiết kế chung của CA Ý tưởng đầu tiên của dự án bao gồm ba phần chính: Giao diện web bằng Perl, mã nguồn mở OpenSSL trong hoạt động mật mã và cơ sở dữ liệu. Khái niệm đơn giản này cho đến nay vẫn được coi là khẩu hiệu . Gần như tất cả các hoạt động có thể được thực hiện thông qua giao diện web. Chúng ta có sáu giao diện được cấu hình trước và có rất nhiều giao diện có thể tạo được từ chúng, tuỳ thuộc vào nhu cầu Hiện nay OpenCA hỗ trợ các nhân tố sau Giao diện Public (Public interface ) Giao diện LDAP (LDAP interface ) Giao diện RA (RA interface ) Giao diện CA (CA interface ) SCEP OCSP Lọc IP đối với các giao diện :(IP-filters for interfaces) Đăng nhập dựa vào cụm mật khẩu : (Passphrase based login) Đăng nhập dựa trên chứng chỉ (bao gồm thẻ thông minh): ( Certificate based login (including smartcards)) Huỷ bỏ chứng chỉ dựa trên số định danh cá nhân : (PIN based revocation) Huỷ bỏ chứng chỉ dựa trên chữ ký số : (Digital signature based revocation) CRL issuing OpenCA được thiết kế cho cơ sở hạ tầng phân tán. Nó không chỉ xử lý một CA offline và một RA online, mà sử dụng nó, chúng ta có thể xây dựng một phân cấp tổng thể với ba hoặc nhiều mức. OpenCA không chỉ là một giải pháp nhỏ cho các phương tiện nghiên cứu nhỏ và trung bình. Mục đích của nó là hỗ trợ tính linh hoạt lớn nhất có thể cho các tổ chức lớn như các trường đại học, các công ty đa quốc gia 4.3.1.Phân cấp cơ bản Ý tưởng cơ bản của mỗi PKI X.509 là một tổ chức phân cấp rõ rệt. Điều này sẽ hình thành nên một cây cơ sở dữ liệu nếu chúng ta cố gắng tạo ra kiến trúc PKI phân tán Figure 1.1. Database oriented view Trao đổi dữ liệu giữa các cơ sở dữ liệu cô lập như vậy có thể được thực hiện tự động nếu ta sử dụng hệ thống cơ sở dữ liệu phân tán , nhưng trong OpenCA thì hệ thống cơ sở dữ liệu phân tán chỉ có duy nhất một cơ sở dữ liệu trong cây . Nếu ta thực sự có một cơ sở dữ liệu cô lập (ví dụ một CA offline) thì ta phải có công nghệ để trao đổi dữ liệu và quản lý các node trong phân cấp. Chức năng quản lý này được gói gọn trong giao diện được gọi là node hay quản lý node. Do đó, thiết kế Open CA như sau Sơ đồ hình 2 Thông thường thì mỗi server trong cơ sở hạ tầng của trung tâm tin cậy đều có cơ sở dữ liệu của riêng nó nhằm mục đích an ninh. Sự phân cấp này là phần cốt lõi của trung tâm tin cậy 4.3.2.Các giao diện Sau khi ta biết được hạ tầng cơ bản của OpenCA, ta cũng có thể muốn biết CA, RA, LDAP và giao diện công khai hay còn gọi là cổng web là gì. OpenCA hỗ trợ tất cả các thành phần phần mềm thông quan giao diện web Sơ đồ hình 1.3: Tổng quan kỹ thuật hoàn chỉnh OpenCA hỗ trợ tất cả các giao diện sau Node (for node management) CA RA LDAP Pub SCEP 4.3.2.1.Node Giao diện này quản lý cơ sở dữ liệu và xử lý tất cả các chức năng xuất và nhập. Cơ sở dữ liệu có thể được bắt đầu theo phương thức mà OpenCA tạo ra tất cả các bảng nhưng bản thân OpenCA thì lại không thể tạo ra cơ sở dữ liệu cho chính nó bởi khác biệt của mỗi hãng sản xuất.Vì vậy chúng ta cần một cơ sở dữ liệu với các quyền truy cập đầy đủ và một cơ sở dữ liệu mới. Giao diện này bao gồm một vài các chức năng cho việc dự phòng và phục hồi nhưng chúng ta phải có một hệ thống dự phòng riêng biệt cho khoá riêng và chứng chỉ của CA. Đây không phải là cơ chế mặc định trong OpenCA để dự phòng khoá riêng. Chúng tôi không thực hiện nó bởi vì thứ nhất chúng tôi thấy rằng đây không phải là cách an toàn thông thường để dự phòng khoá riêng và thứ hai là hầu hết CA sử dụng HSMs và do đó bạn cần một chiến lược dự phòng đúng đắn và khác biệt Việc xuất và nhập cũng có thể được xử lý bằng giao diện này. Bạn có thể cấu hình các quy tắc khác nhau không đồng bộ với các node trên các mức cao hơn hoặc thấp hơn trong phân cấp. 4.3.2.2.CA Giao diện CA có tất cả các chức năng mà bạn cần có để tạo ra các chứng chỉ và danh sách huỷ bỏ chứng chỉ CA cũng bao gồm tất cả các chức năng ta có thể sử dụng để thay đổi cấu hình thông qua một giao diện web. Nhưng lại không thể thay đổi cấu hình thông qua giao diện web khác CA cũng là lớp ngoài của bộ xử lý lô. OpenCA bao gồm các bộ xử lý lô rất mạnh để tạo chứng chỉ. Những bộ xử lý lô này có thể được sử dụng để tạo ra chứng chỉ số tự động từ hệ thống ERP(Enterprise Resource Planning- Hệ thống họach định nguồn tài nguyên) ( ví dụ như SAP, HIS, NIS) 4.3.2.3.RA RA của OpenCA có khả năng xử lý tất cả các loại yêu cầu (request). Bao gồm có chọn lọc, chỉnh sửa yêu cầu, chấp thuận yêu cầu, tạo khoá riêng với thẻ thông minh, xoá các yêu cầu sai và gửi thư điện tử cho người dùng 4.3.2.4. LDAP Giao diện LDAP được xây dựng để phân tách hoàn toàn phần quản lý LDAP. Điều này là cần thiết bởi vì có rất nhiều chức năng mà thực sự là riêng biệt cho người quản trị LDAP, chỉ với một vài người sử dụng mới cần thiết tới chức năng này 4.3.2.5.Pub Giao diện Public bao gồm tất cả những chi tiết mà người dùng cần. Bao gồm Tạo ra các yêu cầu ký chứng chỉ cho Microsoft Internet Explorer Tạo ra các yêu cầu ký chứng chỉ cho Molilla 1.1 và Netscape Communitor và Navigato Tạo ra các yêu cầu độc lập cho các client và khoá riêng ( ví dụ cho người quản trị server người mà không biết làm thế nào để tạo ra yêu cầu và khoá riêng) Nhận PEM- định dạng theo PKCS #10 từ server Ký chứng chỉ Ký vào CRLs Hỗ trợ hai phương thức thu hồi chứng chỉ khác nhau Tìm kiếm chứng chỉ Kiểm tra chứng chỉ người dùng trong trình duyệt ( Microsoft Internet Explorer và Netscape Communicator và Navigator 4.7x) 4.4. Vòng đời của các đối tượng Vòng đời của các đối tượng Đôi khi có sự nhầm lẫn về trạng thái của các đối tượng OpenCA. Sơ đồ sau đây sẽ giúp bạn có thể kiểm tra vòng đời của tất cả các đối tượng OpenCA. Sơ đồ 1.4. Vòng đời của các chứng chỉ 4.5. Các lưu ý khi thiết kế PKI Chương này đưa ra rất nhiều lời gợi ý mà chúng ta nên lưu tâm nếu bạn thiết kế hệ thống PKI lần đầu tiên. . 4.5.1. Các vấn đề phần cứng 4.5.1.1.Thời gian Một trong những vấn đề lớn nhất của hệ thống PKI đó là thời gian. Có hai loại máy tính khác nhau đó là online và offline. Theo logic của người quản trị thông thường Khi máy tính kết nối vào mạng thì máy tính sẽ sử dụng máy chủ thời gian (time server). Một câu hỏi đặt ra là timeserver có đáng tin tưởng không không? Timeserver có thể làm nảy sinh ra hai vấn đề sau. Thứ nhất là tem thời gian thực sự từ timeserver và thứ hai là nguồn thời gian của timeserver có thực sự đáng tin không? Kết nối tới timeserver có thể được đảm bảo an toàn theo công nghệ đường hầm (tunnel) giống như IPSec nhưng vấn đề thực sự là nguồn thời gian. Hầu hết các timeserver đều sử dụng đồng hồ sóng radio, nhận tín hiệu thời gian được từ trạm truyền sóng radio. Tín hiệu này rất dễ bị giả mạo bởi vì nó rất yếu. Do đó nguồn thời gian của mạng là thực sự không được an toàn 4.5.1.2.Đĩa lỗi Các phần hỏng hóc về phần cứng phổ biến nhất thường liên quan tới bộ phận làm làm lạnh và các lỗi đĩa. Bạn nên dự phòng tất cả các dữ liệu quan trong, đặc biệt là các chứng chỉ đã được cấp phát ALL. Không bao giờ được đánh mất chứng chỉ hoặc là bạn phải thu hồi CA hoàn toàn. . 4.5.1.3.Theo dõi phần cứng Thông thường bạn có thể quan sát trực quan nếu laptop của bạn bị ngưng hoạt động. Một máy tính offline bị ngưng hoạt động cũng có thể được phát hiện bằng sự quan sát trực quan như vậy. Tuy nhiên, thành phần online của PKI bị ngưng hoạt động thì lại là một vấn để bởi vì các thông tin quan trọng không sẵn sàng, như là các chứng chỉ được cấp phát mới và danh sách huỷ bỏ chứng chỉ. Những tình huống như vậy cũng có thể làm giảm các dịch vụ của bạn như SCEP. Nếu giao diện công khai của cơ sở hạ tầng an toàn bị suy giảm, thì vấn đề tin cậy của bạn sẽ bị giảm đối với người dùng của bạn trong tương lai. 4.5.2.An toàn vật lý Nếu CA offline của bạn bao gồm một máy tính xác tay và bạn muốn đảm bảo sự kiểm soát kép và không có một điểm lỗi nào thì bạn cần phải tuân theo phương pháp sau : Sử dụng một “két “ module IT và hai két dữ liệu. Một két module IT có một UPC mà có cùng mức bảo vệ vật lý như một két sắt (ngăn ) Két này được sử dụng để cho phép máy tính xác tay đó không ngừng hoạt động, do đó giảm được thời gian và vấn đề về tính sẵn sàng. Tất cả ba két đó sẽ có hai khoá . Điều này đảm bảo rằng kiểm soát truy cập kép bằng chia sẻ khoá. Việc cài đặt cũng sẽ thực sự đơn giản và hiệu quả Tổ chức của các két là thực sự dễ dàng. Ta có thể phân tách passphrase CA thành hai phần là trước và sau. Tổ chức của dữ liệu và máy tính có thể như sau Két module IT bao gồm máy tính xách tay (với khoá riêng của CA) và phần trước của passphrase (cụm mật khẩu) Két dữ liệu đầu tiên bao gồm các phần dự phòng (bao gồm các phần dự phòng khoá riêng) và phần sau của cụm mật khẩu Ngăn dữ liệu thứ hai bao gồm cả phần trước và phần sau của cụm mật khẩu Sự tổ chức này đảm bẳo rằng nếu một ngăn dữ liệu bị phá thì cũng sẽ không làm hư hại tới cơ sở hạ tầng. Sự phân cấp như vậy cũng đảm bảo rằng nếu mất một ngăn dữ liệu thì cũng sẽ không làm ngừng hoạt động của bạn. Chúng ta cần hai ngăn tồn tại và mất một ngăn thì cũng có thể chấp nhận được ít nhất trong một thời gian ngắn Cần lưu lý rằng đây là ý tưởng cơ bản đối với những CA có mức rủi ro trung bình. Những CA có mức rủi ro cao nên sử dụng những lược đồ phức tạp hơn để có thể chấp nhận được nhiều hơn một ngăn bị phá hỏng. 4.5.3.Các vấn đề về mạng Một PKI mang đầy đủ chức năng nếu như tất cả các dịch vụ mà nó cung cấp đều hoàn toàn hoạt động. Nghĩa là không chỉ những thứ như OCSP và SCEP mà cả các gateway công cộng cũng như vậy. Rất nhiều người nghĩ rằng sẽ đủ nếu như OCSP và một CDP duy trì hoạt động nhưng thực ra đó là không đủ. Lý do đầu tiên là hầu hết các ứng dụng không hiểu OCSP. Vấn đề thứ hai là CDP đang hoạt động chỉ hỗ trợ LDAP, bất luận trên thực tế có rất nhiều ứng dụng chỉ hỗ trợ HTTP. PKI sẽ không hoạt động đầy đủ nếu chỉ có CDP đang hoạt động. Không ai có thể tải chứng chỉ mới hoặc chứng chỉ của người dùng đang tồn tại trong trạng thái như vậy. PKI sẽ chỉ được an toàn, nhưng nó không hoạt động đầy đủ 4.5.4.Vấn đề về chứng chỉ Phần này bao gồm hai nhóm vấn đề lớn là CDP và các vấn đề cụ thể về ứng dụng. Tuy nhiên thì các vấn đề cụ thể về ứng dụng sẽ được thảo luận trong phần khác trong hướng dẫn về CA 4.5.5.CDPs (Các điểm phân phối danh sách huỷ bỏ chứng chỉ (CDP)) Một vài PKI trước đây không có CDP hoặc chỉ có một CDP. Các ứng dụng an toàn phải xác minh trạng thái chứng chỉ được sử dụng. Những ứng dụng như thế sẽ kiểm tra trường CDP trong phần mở rộng của chứng chỉ để tìm ra nguồn xác minh có thể dùng được. Ngày nay, điểm phân phối danh sách huỷ bỏ chứng chỉ không được coi là một nguồn cho CRL. Nó có thể được xem là một responder OCSP (bên hồi đáp OCSP). CDP hiện nay là nhiều điểm trạng thái chứng chỉ Câu hỏi đầu tiên là các giao thức nào cần được hỗ trợ. Giao thức phổ biến nhất là LDAP và HTTP phải luôn được hỗ trợ. HTTP được hỗ trợ bởi gần như tất cả các thiết bị, nhưng một vài thiết bị chỉ hỗ trợ LDAP thay vì HPPT, đặc biệt trong một vài giải pháp mạng. Thêm vào đó còn có OCSP và HTTPS. OCSP là giao thức để xác minh trạng thái của một chứng chỉ . Giao thức này có hiệu suất tốt hơn rất nhiều so với các kết nối mạng chậm nếu bạn có một lượng lớn các cài đặt với nhiều chứng chỉ ( bị huỷ bỏ ). HTTPS chỉ đôi khi hỗ trợ bạn với một nguồn tin cậy Câu hỏi thứ hai là cần bao nhiêu CDP vật lý mà bạn cần. Nếu bạn thiết kế một hạ tầng khả chuyển thì phải có khả năng chấp nhận sẽ ngắt một vài dịch vụ của các thành phần như cable, router, switch, và server. Cách tốt nhất là nên có CDP cục bộ nếu chỉ có một bộ kểt nối tới mạng trung tâm. Tuy nhiên, không phải mọi chi nhánh đều cần CDP riêng, vì nếu các máy tính của họ (hệ thống mail, hệ thống file) là Offline không cần thiết phải có CDP online. 4.5.6.Các vấn đề cụ thể về ứng dụng 4.5.6.1.Mail Server Nếu bắt đầu nghĩ đến bảo mật Mail thì điểm bắt đầu là S/MIME hoặc PGP. Đầu tiên những nhà quản trị chỉ sử dụng IMAPS và POPS. Sau đó họ nghĩ về các máy chủ được bảo mật và cố gắng triển khai SMTP thông qua TLS. Các chứng chỉ được cấp bởi OpenCA có thể được sử dụng cho SMTP qua TLS bởi vì các chứng chỉ có thể đóng vai trò như chứng chỉ Client và chứng chỉ Server. Một SMTP Server có thể dùng 2 giao thức cho SMTP qua TLS. Nó có thể sử dụng một chứng chỉ đơn chứa phần mở rộng cho các Client và Server TLS, hoặc cũng có thể dùng 2 chứng chỉ: một cho Client, một cho Server. 4.5.6.2. Client Netscape Các Client Netscape cũ không tuân theo các chuẩn RFC. 4.5.6.3.OpenLDAP OpenLDAP là phần mềm mã nguồn mở, nhưng việc thực thi TLS của nó không phải là tốt nhất. Nó sẽ không kiểm tra tên tiếp theo của chủ thể mà nó sẽ kiểm tra tên chung của chủ thế mà phù hợp với tên DNS hoặc địa chỉ IP. Điều này sẽ gây ra lỗi nếu chủ thể của chứng chỉ sử dụng tên clients Netscape cũ. OpenLDAP không hỗ trợ những mở rộng chung Chương V: Đánh giá và hướng phát triển 5.1. Đánh giá Kết luận Nghiên cứu và xây dựng hệ thống PKI dựa trên mã nguồn OpenCA là một vấn đề còn mới mẻ và luôn cần được hoàn thiện. Mô hình PKI dựa trên mã nguồn OpenCA được xây dựng từ rất nhiều mã nguồn khác bao gồm Apache, OpenSSL, mod_ssl, perl và các module perl. Quá trình nghiên cứu, xây dựng và phát triển hệ thống PKI dựa trên mã nguồn OpenCA là một quá trình lâu dài và cần phải có sự chấp nhận của người sử dụng. Tỷ lệ người dùng sẽ được tăng khi các chuẩn về công nghệ trở nên hoàn thiện hơn, chứng minh được khả năng ứng dụng và hiện thực hoá là tính khả thi Hiện nay, việc áp dụng mật mã khoá công khai và dịch vụ chứng thực điện tử để đảm bảo an toàn thông tin trong các hoạt động giao dịch điện tử là giải pháp được nhiều quốc gia trên thế giới sử dụng. Ở Việt Nam, vấn đề trên tuy đã có sự tiến triển, nhưng còn gặp nhiều khó khăn. Một vài năm trở lại đây, một số đơn vị, cơ quan cũng đã có những hoạt động ban đầu nghiên cứu công nghệ, xây dựng hệ thống kỹ thuật, phát triển các ứng dụng và thử nghiệm cung cấp dịch vụ chứng thực điện tử . Việc triển khai các dịch vụ cung cấp chứng thực điện tử yêu cầu một sự đầu tư lâu dài và nghiêm túc mới mang lại kết quả như mong muốn. Phần khó khăn nhất trong triển khai dịch vụ này là ở khâu tổ chức thực hiện và thay đổi nhận thức của con người. Tính pháp lý của chữ ký số và dịch vụ chứng thực điện tử cũng là một vấn đề đang được đặt ra. Hiện nay, ở Việt Nam đã ban hành một số các điều luật trong lĩnh vực này như Luật công nghệ thông tin ban hành ngày 29/6/2006, Luật giao dịch điện tử ban hành ngày 29/11/2005, Luật nội dung chữ ký số ban hành ngày 15/2/2007..Các tổ chức, cá nhân cung cấp và sử dụng dịch vụ chứng thực điện tử cần phải được quản lý, đồng thời có quyền , nghĩa vụ nhất định. Ngoài ra nếu một cơ sở hạ tầng có công nghệ yếu thì sẽ không có sự tin tưởng và nhà cung cấp dịch vụ và những e ngại về tâm lý của người dùng này cũng là các trở ngại trong việc triển khai cơ sở hạ tầng an ninh rộng khắp PHỤ LỤC 1.Môi trường phát triển Phần mềm mã nguồn mở OpenCA không phải là một...Phần mềm nguồn mở OpenCA được dựa trên rất nhiều phần mềm nguồn mở khác bao gồm : Apache, OpenSSL, mod_ssl, perl, OpenLDAP và các module perl và. Phần này em xin phép được trình bày về các phần mềm nguồn mở được sử dụng để xây dựng nên OpenCA 1.1.Apache Apache HTTP SERVER PROJECT Dự án Apache HTTP Server là một sự nỗ lực để phát triển và duy trì một mã nguồn HTTP cho các máy chủ hiện đại dành cho các hệ điều hành hiện đại như Unix và Window NT. Mục đích của dự án này là cung cấp một máy chủ mở rộng, hiệu quả và an toàn làm nhiệm vụ cung cấp các dịch vụ http đồng bộ với các tiêu chuẩn HTTP hiện nay Dự án HTTP được quản lý chung bởi một nhóm những người tình nguyện trên khắp thế giới, những người sử dụng Internet và Web để truyền thông, xây dựng, phát triển máy chủ và các tài liệu có liên quan. Những người tình nguyện này được gọi là nhóm Apache (Apache Group). Hơn nữa, có hàng trăm người sử dụng cũng đóng góp ý tưởng, mã nguồn và tài liệu cho dự án. 1.2. OpenSSL OpenSSL là sự nỗ lực hợp tác nhằm phát triển bộ mã nguồn mở với đầy đủ tính năng, được triển khai trên giao thức SSL (version 2 và version 3) và giao thức TSL(version 1) được quản lý bởi cộng đồng những người tình nguyện trên toàn thế giới sử dụng Internet để kết nối và phát triển bộ OpenSSL và các tài liệu có liên quan Hầu hết các phần mềm như IMAP&POP, Samba, OpenLDAP, FTP, Apache và những phần mềm khác đều yêu cầu công việc kiểm tra tính xác thực của người sử dụng trước khi cho phép sử dụng các dịch vụ này. Nhưng mặc định việc truyền tải sự xác minh thông tin người sử dụng và mật khẩu (password) ở dạng văn bản thuần túy nên có thể được đọc hoặc thay đổi bởi một người khác. Kỹ thuật mã hóa như SSL sẽ đảm bảo tính an toàn và nguyên vẹn của dữ liệu, với kỹ thuật này thông tin truyền trên mạng ở dạng điểm nối điểm được mã hóa. Một khi OpenSSL đã được cài đặt trên Linux server chúng ta có thể sử dụng nó như một công cụ thứ ba cho phép các ứng dụng khác dùng tính năng SSL OpenSSL là một bộ công cụ mật mã triển khai trên giao thức mạng SSL và TLS và các chuẩn mật mã có liên quan Chương trình OpenSSL là một công cụ dòng lệnh để sử dụng các chức năng mật mã của các thư viện crypto của OpenSSL từ nhân. OpenSSL có các thư viện cung cấp các chức năng mật mã cho các ứng dụng như an toàn webserver 1.2.1.Công cụ dòng lệnh trong openssl 1.2.1.1.Các dòng lệnh chuẩn - asnlparse: phân tích chuỗi ASN.1 - ca: Quản lý CA - Ciphers: Miêu tả bộ mã hoá - cms: tiện tích (Cú pháp thông báo mật mã) - crl: Quản lý danh sách huỷ bỏ chứng chỉ (CRL) - crl2pkcs7: Chuyển đổi CRL thành PKCS37 - dgst: Tính toán bản tóm lược thông báo -dh: Quản lý cá tham số Diffie-Hellman - dhparam: Tạo và quản lý các tham số Diffie-Hellman -dsa: Quản lý dữ liệu DSA -dasparam: Tạo và quản lý tham số DSA -ec: Xử lý khoá (đường cong Elliptic) -ecparam: Tạo và thao tác tham số EC -enc: Mã hoá bằng mật mã -gendh: Tạo các tham số Diffie-Hellman -gendsa: Tạo khoá riêng từ các tham số -genpkey: Tạo khoá riêng hoặc các tham số -genrsa: Tạo khoá riêng RSA -ocsp: Tiện ích giao thức trạng thái chứng chỉ trực tuyến -passwd: Tạo các password được hash -pkcs12: Quản lý dữ liệu PKCS#12 -pkcs7: Quản lý dữ liệu PKCS#7 -pkey: Quản lý khoá riêng và khoá công khai -pkeyparam: Quản lý tham số thuật toán khoá công khai -pkeyutl: Tiện ích họat động mật mã thuật toán khoá công khai -rand: Tạo các bytes ngẫu nhiên -req: Quản lý yêu cầu ký chứng chỉ PKCS#10 X.509 -rsa: Quản lý khoá RSA -rsautl: Tiện ích RSA cho việc ký, xác minh, mã hoá và giải mã -s_time: Máy thời gian kết nối SSL -sess_id: Quản lý dữ liệu phiên SSL -smime: Xử lý mail S/MIME -speed: Đo tốc độ thuật toán -spkac: Tiện ích tạo và in SPKAC -ts: Công cụ cấp quyền tem thời gian -verify: Xác minh chứng chỉ X.509 -version:Thông tin phiên bản OpenSSL -x509: Quản lý dữ liệu chứng chỉ X.509 1.2.1.2.Các dòng lệnh tóm lược thông báo - md2: tóm lược MD2 -md5:Tóm lược MD5 -mdc2: tóm lược MDC2 -rmdl160: tóm lược RMD-160 -sha: Tóm lược SHA -sha1: Tóm lược SHA-1 -sha224 :Tóm lược SHA-224 -sha256 :Tóm lược SHA-256 -sha384 :Tóm lược SHA-384 -sha512: Tóm lược SHA-512 1.2.1.3. Các dòng lệnh về mã hoá base64: mã hoá Base 54 bf bf-cbc bf-cfb bf-ecb bf-ofb : Mã Blowfish cast cast-cbc : Mã CAST cast5-cbc cast5-cfb cast5-ecb cast5-ofb :Mã CAST5 des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ofb :Mã DES des3 desx des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb :Mã 3DES idea idea-cbc idea-cfb idea-ecb idea-ofb :Mã IDEA rc2 rc2-cbc rc2-cfb rc2-ecb rc2-ofb :Mã RC2 rc4 :Mã RC4 rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb :Mã RC5 1.2.2.Thư viện SSL/TLS trong OpenSL 1.2.2.1.Miêu tả Thư viện ssl trong OpenSSL triển khai giao thức SSL và TLS. Đầu tiên thư viện sẽ được khởi tạo Sau đó đối tượng SSL_CTX được tạo ra như một cơ cấu thiết lập kết nối TLS/SSL. Sẽ có rất nhiều tuỳ chọn liên quan tới chứng chỉ, thuật toán có thể được cài đặt trong đối tượng này Khi một kết nối mạng được tạo ra, nó có thể được gán cho đối tượng SSL. Sau khi đối tượng SSL được tạo ra từ SSL_new, SSL_set_fd hoặc SSL_set_bio, những thành phần này sẽ kết hợp một kết nối mạng với đối tượng Sau khi bắt tay TLS/SSL được thực hiện nhờ SSL_accept hoặc SSL_connect. SSL_read và SSL_write được sử dụng để đọc và ghi dữ liệu trên kết nối TLS/SSL. SSL_shutdow có thể được sử dụng để kết thúc kết nối TLS/SSL 1.2.2.2. Cấu trúc dữ liệu Chức năng hiện có của thư viện ssl trong OpenSSL giải quyết được cấu trúc dữ liệu sau SSL_METHOD Đây là một cấu trúc miêu tả chức năng/phương thức thư viện nội ssl nội bộ. Nó được sử dụng để tạo SSL_CTX SSL_CIPHER(SSL Cipher) Cấu trúc này nắm giữ thông tin thuật toán cho phép mã hoá đặc biệt mà là phần lõi của giao thức SSL/TLS. Các phép mã hoá sẵn có được cấu hình trên SSL_CTX SSL_CTX (SSL Context) Đây là một cấu trúc ngữ cảnh toàn cục được tạo bởi server hoặc client trong mỗi thời gian tồn tại chương trình và nó nắm giữa chủ yếu các giá trị mặc định của cấu trúc SSL, các giá trị mà được tạo cho khi kết nối sau đó SSL_SESSION (SSL Session) Đây là cấu trúc chứa chi tiết phiên TSL/SSL hiện có của kết nối: SSL_CIPHER, chứng chỉ client và server, khoá SSL (SSL Connection) Đây là cấu trúc SSL/TLS chính , được tạo bởi server hoặc client mỗi khi kết nối được thiết lập. Đây thực sự là phần cấu trúc cốt lõi trong SSL API. Mỗi khi chạy ứng dụng thường phân phối cấu trúc này tới các cấu trúc khác 1.2.2.3. Các file header Thư viện ssl trong OpenSSL cung cấp những file header C sau, có chứa các mẫu cho cấu trúc dữ liệu và chức năng ssl.h: Đây là file header chung cho SSL/TLS API, nó có chứa phần cốt lõi bên trong của SSL API ssl2.h: Đây là file header con chỉ có quan hệ với giao thức SSLv2 ssl3.h: Đây là file header con chỉ có quan hệ với giao thức SSLv3 ssl23.h: Đây là file header con chỉ có quan hệ với giao thức SSLv2 và SSLv3 tlsl.h: Đây là file header con chỉ có quan hệ với giao thức TLSv1 1.2.3. Thư viện mật mã trong OpenSSL 1.2.3.1. Miêu tả Thư viện mật mã trong OpenSSL cung cấp một số lượng lớn các thuật toán mật mã được sử dụng trong rất nhiều chuẩn của Internet. Các dịch vụ được cung cấp bởi thư viện này được sử dụng bởi các công cụ của SSL, TLS và S/MIME và chúng cũng được sử dụng để bổ sung cho SSH, OpenPGP và các chuẩn mật mã khác 1.2.3.2.Tổng quan Thư viện libcrypto bao gồm một số các thư viện con bổ sung cho các thuật toán riêng lẻ Tính năng này bao gồm mã hoá đối xứng, mật mã khoá công khai và sự thoả thuận khoá, xử lý chứng chỉ, hàm hash mật mã và tạo ra số ngẫu nhiên giả lập 1.2.4. Bộ công cụ OpenSSL Bộ công cụ OpenSSL bao gồm -libssl.a: Xây dựng trên SSLv2 và SSLv3 và các code được yêu cầu trên cả SSLv2 và SSLv3 và TLSv1 trong một server và client -libcrypto.a : Thư viện mã hóa chung. Trong thư viện này thông thường bao gồm +Mật mã libdes: Thư viện của des. Bao gồm 15 chế độ/biến thể của DES (các phiên bản khóa 1,2 và 3 của các chế độ ecb, cgc, cfb và ofb) Mã hóa RC4 Mã hóa RC2: Có 4 chế độ khác nhau là ecb, cbc, cfb và ofb Mã hóa Blowfish: Có 4 chế độ khác nhau là ecb, cbc, cfb và ofb Mã hóa IDEA: Có 4 chế độ khác nhau là ecb,cbc,cfb và ofb +Tóm lược thông báo Các thuật toán tóm lược thông báo MD5 và MD2, SHA và thuật toán tóm lược thông báo SHA-1 Tóm lược thông báo MDC2. + Khóa công khai Tạo/mã hóa/giải mã RSA Không có giới hạn số lượng bit Tạo/giải mã/mã hóa DSA Không có giới hạn số lượng bit Tạo/trao đổi khóa Diffie-Hellman Không có giới hạn về số lượng bit + Chứng chỉ X.509v3 Mã hóa/giải mã chứng chỉ X.509 thành/từ ASN1 nhị phân và PEM dựa trên mã hóa nhị phân ASCII hỗ trợ mã hóa bằng một khóa riêng. Chương trình để tạo ra các yêu cầu chứng chỉ RSA và DSA và để tạo ra chứng chỉ RSA và DSA 1.3.Mod_ssl Mod_ssl” kết hợp tính linh hoạtt của Apache và tính an toàn của openssl Mod_ssl cung cấp tính năng mật mã rất mạnh cho Apache 1.3 thông qua hai giao thức SSL và TLS bởi sự giúp đỡ của bộ OpenSSL và nguồn mở SSL/TLS, dựa trên SSLeay từ Eric A.Young và Tim J.Hudson Gói mod_ssl được tạo ra vào tháng 4/1998 bởi Ralf S. Engelschall và đầu tiên được được phát triển bởi Ben Laurie để sử dụng trong dự án Apache-SSL HTTP server 1.3.1.Các điểm nổi bật Các đặc điểm nổi bật của mod_ssl Là phần mềm mã nguồn mở Có thể sử dụng được cho cả mục đích thương mại và phi thương mại Tính năng mã hoá mạnh trên toàn thế giới Hỗ trợ các giao thức SSLv2 và SSLv3 và TLSv1 Hỗ trợ cho cả phép mã hoá RSA và Diffie-Hellman Hỗ trợ đầy đủ DSO Hỗ trợ cho OpenSSL và RSArefUS Nâng cao khả năng xử lý cụm mật khẩu đối với khoá riêng Chứng chỉ X.509 dựa vào xác thực cho cả phía client và server Hỗ trợ danh sách thu hồi chứng chỉ X.509 Hỗ trợ khả năng tái điều chỉnh đối với mỗi URL của các tham số bắt tay SSL Bổ sung biểu thức Boolean dựa trên phương tiện kiểm soát truy cập Các ứng dụng đơn giản và thiết thực đối với Apache Tích hợp đầy đủ trong các cơ chế cấu hình Apache 1.3 Bổ sung sự tích hợp trong giao diện kiểu tự cấu hình của Apache Hỗ trợ sự tạo chứng chỉ X.509v3 (cả RSA và DSA) 1.3.2.Kiến trúc gói mod_ssl Gói mod_ssl bao gồm module SSL và bộ nguồn Apache có bổ sung API mở rộng (EAPI) .Đây là điều kiện tiên quyết để có thể sử dụng mod_ssl. Hay nói cách khác, chúng ta chỉ có thể sử dụng mod_ssl khi phần cốt lõi của Apache có chứa API mở rộng. Nhưng bởi vì khi chúng ta áp dụng mod_ssl cho source Apache, phần API mở rộng cũng được tự động thêm vào. 1.3.3.Giao thức SSL Giao thức SSL ban đầu được phát triển bởi Netscape, SSL đã được chấp nhận rộng rãi trên toàn thế giới để xác thực và tạo lập kết nối mã hóa giữa client và server Giao thức SSL chạy trên giao thức TCP/IP và dưới giao thức mức ứng dụng như HTTP, IMAP . Nó cho phép một máy chủ hỗ trợ SSL xác thực chính nó với máy client hỗ trợ SSL, cho phép client xác thực chính nó với máy chủ, và cho phép cả hai máy thiết lập một kết nối mã hóa Giao thức SSL hỗ trợ sử dụng rất nhiều các thuật toán mật mã khác nhau, để sử dụng trong các hoạt động như xác thực server, xác thực client, truyền chứng chỉ và thiết lập các khóa phiên. Client và server có thể hỗ trợ các bộ mã hóa khác nhau, phụ thuộc vào các nhân tố như phiên bản SSL mà chúng hỗ trợ, chính sách công ty… Các thuật toán mật mã mà giao thức SSl hỗ trợ bao gồm : DES : Data Encryption Standard DSA: Digital Signature Algorithm KEA: Key Exchange Algorithm MD5: Message Digest Algorithm RC2 & RC4:Rivest encryption ciphers RSA: SHA-1:Secure Hash Algorithm Triple-DES Xác thực server Giao thức SSL là giao thức được đặt giữa giao thức tầng mạng hướng hướng kết nối (ví dụ TCP/IP) với giao thức tầng ứng dụng (ví dụ HTTP) . SSL cung cấp tính năng kết nối an toàn giữa client và server bằng các cho phép xác thực lẫn nhau, sử dụng chữ ký số để đảm bảo tính toàn vẹn, và mã hoá để đảm bảo tính bí mật Giao thức này được thiết kế để hỗ trợ các thuật toán cụ thể được sử dụng cho mật mã, tóm lược, và chữ ký số. 1.4. OpenLDAP Hiện nay, để xây dựng các hệ thống lớn, điều tối quan trọng là phải làm cách nào có thể tích hợp dữ liệu để từ đó có thể dùng chung giữa các hệ thống khác nhau. Trong đó, tích hợp tài khoản của người sử dụng là vấn đề cần thiết nhất trong những cái “tối quan trọng” trên Một hệ thống với khoảng 5 - 6 module khác nhau, mỗi module lại được thiết kế trên một nền tảng khác nhau ( có người dùngOracle + AS Portal, hoặc DB2 với WebSphere, hoặc MySQL với phpnuke, hoặc Wíndow, Linux, ), do đó cần có một hệ thống người dùng khác nhau. Vậy thì với mỗi module, người sử dụng cần phải có một User Name, một mật khẩu khác nhau, đó là điều gây nhiều bất tiện và khó khăn Làm cách nào để có thể tích hợp được người dùng giữa các hệ thống trên? Câu trả lời đó là LDAP LDAP (Lightweight Directory Access Protocol )- giao thức truy cập nhanh các dịch vụ thư mục -LÀ một giao thức tìm, truy cập các thông tin dạng thư mục trên server -Nó là giao thức dạng Client/Server dùng để truy nhập dịch vụ thư mục -LDAP chạy trên TCP/IP hoặc các dịch vụ hướng kết nối khác. -Là một mô hình thông tin cho phép xác định cấu trúc và đặc điểm của thông tin trong thư mục -Là một không gian tên cho phép xác định cách các thông tin được tham chiếu và tổ chức -Một mô hình các thao tác cho phép xác định các tham chiếu và phân bổ dữ liệu -Là một giao thức mở rộng - Là một mô hình thông tin mở rộng Ở đây chúng ta cần tránh hiểu nhầm từ "thư mục" như trên Windows là folder hay directory, đó là thư mục theo nghĩa hẹp để quản lý hệ thống tệp tin. Từ thư mục trong LDAP mang ý nghĩa rộng hơn, nó bao hàm các cấu trúc dữ liệu dạng liệt kê theo thư mục (hay mục lục) - một "từ khoá" của dân thư viện nhằm ám chỉ cách thức sắp xếp dữ liệu để tiện truy xuất nhấtMột cách tổng quát mà nói, LDAP thường phân chia theo O (Organisation - tổ chức) và các OU (Organisation Unit - phân bộ). Trong các OU có thể có những OU con và trong các OU có các CN (Common Name), những nhóm giá trị này thường được gọi là DN (Distinguished Name - tên gọi phân biệt). Mỗi giá trị chứa trong LDAP thuộc dạng tên:giá trị, thường được gọi là LDAP Attribute (viết tắt là attr, mỗi attr được nhận diện như một LDAP Object LDAP có tiêu chuẩn thống nhất giữa các ứng dụng phát triển LDAP. Đây là lý do LDAP được ưa chuộng cho Bản chất của LDAP là một phần của dịch vụ thư mục X.500. LDAP thực chất được thiết kế như một giao thức nhẹ nhàng, dùng như gateway trả lời những yêu cầu của X.500 server    X.500 thực tế là một tập các chuẩn. X500 được biết như là một heavyweight. Nó yêu cầu client và server liên lạc với nhau sử dụng theo mô hình OSI . Mô hình 7 tầng của OSI là một mô hình chuẩn phù hợp trong thiết kế với giao thức mạng, nhưng khi so sánh với chuẩn TCP/IP thì nó trở nên không còn hợp lý LDAP đóng vai trò rất quan trọng trong ứng dụng truy nhập đơn. Có nghĩa là một người đăng nhập vào một hệ thống, người ấy có thể truy cập tới các máy chủ, dịch vụ, tài nguyên mà không cần phải xác thực lại. Ngoài ra, LDAP được tạo ra đặc biệt cho hành động “đọc”. Bởi thế, xác thực người dùng bằng phương tiện “look up” LDAP nhanh, hiệu suất, ít tốn tài nguyên,đơn giản hơn là 1 truy vấn tài khoản người dùng trên cơ sở dữ liệu Dự án OpenLDAP là một sự nỗ lực hợp tác nhằm phát triển bộ mã nguồn mở LDAP của các ứng dụng và các công cụ phát triển được tích hợp đầy đủ các tính năng và Dự án được quản lý bởi cộng đồng những người tình nguyện trên thế giới, những người sử dụng Internet để truyền thông, phát triển bộ mã nguồn mở LDAP OpenLDAP 2.0 có các đặc điểm nổi bật sau Hỗ trợ LDAPv3: OpenLDAP 2.0 hỗ trợ lớp an toàn và xác thực đơn (Simple Authentication and Sercurity Layer-SASL), TSL và SSL Hỗ trợ IPv6: OpenLDAP hỗ trợ thế hệ tiếp theo của giao thức IPv6 LDAP trên IPC: OpenLDAP có thể truyền tin trong hệ thống sử dụng IPC (interprocess communication). Điều nay sẽ làm tăng cường tính năng an toàn bằng cách ngăn ngừa các yêu cầu truyền thông thông qua mạng Cập nhật C API: Cải thiện cách người lập trình có thể kết nối và sử dụng các máy chủ thư mục LDAP Củng cố cho server Stand-alone LDAP: Bao Cập nhật hệ thống kiểm soát truy cập Bộ thư viện và công cụ của OpenLDAp được chia thành các gói sau +openldap- Chức các thư viện cần thiết để vận hành máy chủ openLDAp và các ứng dụng client +openlda-clients: Chức các công cụ dòng lệnh để xem xét và điều chỉnh các thư mục trong LDAP server +openldap-servers: Chứa các tiện ích cần thiết để cấu hình và vận hành máy chủ LDAP 1.5. Các module perl Table 3.1. External Perl modules Module Version Comment Authen::SASL 2.04 Được yêu cầu bởi Net::LDAP để xác thực SASL authentication -Nếu bạn không sử dụng SASL thì bạn không cần tới nó CGI::Session 3.95 Được yêu cầu để xử lý phiên làm việc Convert::ASN1 0.18 ??? Digest::HMAC 1.01 Được yêu cầu bởi Authen::SASL Digest::MD5 2.24 Là thành phần của Perl Digest::SHA1 2.02 Được yêu cầu bởi chính OpenCA Encode::Unicode ??? Được yêu cầu bởi OpenCA dành cho người dùng nước ngoài IO::Socket::SSL 0.92 ??? IO::stringy 2.108 ??? MIME::Base64 2.20 Được yêu cầu cho mã hoá và gảii mã Base64 MIME::Lite 3.01 Được yêu cầu để xử lý mail OpenCA MIME-tools 5.411 Được yêu cầu để xử lý mail OpenCA MailTools 1.58 Được yêu cầu để xử lý mail OpenCA Net-Server 0.86 Được yêu cầu cho OpenCA daemon- Phiên bản này rất quan trọng Parse::RecDescent 1.94 Được yêu cầu bởi X500::DN URI 1.23 ??? X500::DN 0.28 Chúng tôi sử dụng phiên bản được chỉnh sửa ở đây XML::Twig 3.09 Được sử dụng cho XML Parsing libintl-perl 1.10 Đây là giao diện cho nhân viên i18n Perl-ldap 0.28 Giao diện LDAP của Perl 2.Các chuẩn mật mã PKCS là chuẩn mật mã khoá công khai do phòng thí nghiệm RSA phát triển. Chuẩn PKCS cung cấp những định nghĩa cơ bản về định dạng dữ liệu và thuật toán nền tảng để triển khai PKI PKCS#1(Encryption Standard) : Chuẩn mật mã RSA PKCS#2: Chuẩn này được liên kết thành chuẩn PKCS#1 PKCS#3 (Diffie-Hellman Key Agreement Standard): Chuẩn trao đổi khóa Diffie-Hellman. Miêu tả phương pháp thực hiện trao đổi khoá Diffie-Hellman PKCS#4: Chuẩn này được liên kết thành chuẩn PKCS#1 PKCS#5 (Password-based Encryption Standard): Chuẩn mã hoá dữ liệu dựa vào password. Chuẩn này mô tả phương pháp mã dạng xâu bát phân sử dụng khoá bí mật được tính từ password để sinh ra xâu bát phân được mã hoá. PKCS#5 có thể được sử dụng để mã hoá khoá riêng trong việc truyền khoá bí mật PKCS#6 (Extended Certificate Syntax Standard): Chuẩn cú pháp chứng chỉ mở rộng. Chuẩn này định nghĩa cú pháp chứng chỉ X.509 mở rộng PKCS#7 (Cryptographic Message Syntax Standard): Chuẩn cú pháp thông báo mật mã. Chuẩn này xác định cú pháp tổng thể dữ liệu được mã hoá ví dụ như chữ ký số. PKCS#7 cung cấp một số lựa chọn định dạng thông báo như thông báo không mã hoá hoặc ký số, thông báo được mã hoá, thông báo được ký số và thông báo có cả ký số và mã hoá PKCS#8 (Private Key Information Syntax Standard): Chuẩn cú pháp thông tin riêng. Chuẩn này định nghĩa cú pháp thông tin khoá riêng và cú pháp khoá riêng được mã hóa PKCS#9 (Selected Attribute Types):Những loại thuộc tính được lựa chọn. Chuẩn này định nghĩa những loại thuộc tính được lựa chọn sử dụng trong chứng chỉ mở rộng PKCS#6, thông điệp ký số PKCS#7, thông tin khoá riêng PKCS#8 và yêu cầu chứng chỉ PKCS#10. Những thuộc tính chứng chỉ được chỉ rõ ở đây gồm có địa chỉ thư , loại nội dung, bản tóm lược thông báo, thời gian ký, mật khẩu yêu cầu và những thuộc tính chứng chỉ mở rộng PKCS#10 (Certification Request Syntax Standard): Chuẩn cú pháp yêu cầu chứng chỉ. PKCS#10 định nghĩa cú pháp yêu cầu chứng chỉ. Yêu cầu chứng chỉ gồm có tên phân biệt, khoá công khai và tập các thuộc tính tuỳ chọn, chữ ký của thực thể yêu cầu chứng chỉ PKCS#11(Cryptographic Token Interface Standard): Chuẩn giao diện thẻ bài mật mã. Chuẩn này xác định giao diện lập trình ứng dụng (API) cho thiết bị người dùng chứa thông tin mã hoá và thực hiện chức năng mã hoá. PKCS#12 (Personal Information Exchange Syntax Standard): Chuẩn cú pháp trao đổi thông tin cá nhân. Chuẩn này định nghĩa dạng thông tin nhận diện cá nhân bao gồm khoá riêng, chứng chỉ, bí mật đặc tính khác nhau và mở rộng. Chuẩn PKCS#12 làm cho việc truyền chứng chỉ và khóa bí mật gắn kèm được thuận tiện, giúp người sử dụng có thể chuyển thông tin nhận diện cá nhân từ thiết bị này sang thiết bị khác PKCS#13 (Elliptic Curve Cryptography Standard): Chuẩn mã đường cong Elliptic. PKCS#13 bao gồm việc tạo tham số đường cong Elliptic và kiểm tra hiệu lực, tạo khoá và công nhận giá trị, chữ ký số và mã hoá khoá công khai cũng như thoả thuận khoá PKCS#14 (Pseudo-Random Number Generation Standard): Chuẩn tạo số giả ngẫu nhiên. Nhiều hàm mật mã cơ bản được sử dụng trong PKI như tạo khoá và thoả thuận khoá bí mật Diffie-Hellman sử dụng dữ liệu ngẫu nhiên. Tuy nhiên, nếu dữ liệu ngẫu nhiên lại không ngẫu nhiên mà được chọn từ tập giá trị có thể tiên đoán được thì hàm mật mã không bảo mật được đầy đủ. Do đó tạo số giả ngẫu nhiên an toàn là điều tối quan trọng trong bảo mật PKI PKCS#15: Chuẩn mẫu thông tin thẻ bài mật mã