Đối với hoạt động của hạ tầng PKI thì dịch vụ công bố thông tin chứng thư số có tầm quan trọng đặc biệt. Các thuê bao cần phải biết chắc các thông tin tin cậy về bản thân các CTS của chính mình và các đối tác thuê bao khác, về trạng thái hiện hành của các CTS này mỗi khi sử dụng đến chúng trong các phiên làm việc. Các thông tin này thường là các chứng thư số và các danh sách chứng thư số bị gỡ bỏ CRL. Các thông tin này đều được ký số để đảm bảo tính toàn vẹn, tin cậy cần thiết.

Hạ tầng PKI công bố các thông tin này một cách công khai và rộng rãi thông qua nhiều phương tiện trực tuyến và phi trực tuyến trong đó có môi trường mạng Internet để các thuê bao đều có thể truy cập và sử dụng chúng thuận tiện. Các dịch vụ công bố thông tin CTS có thể phổ biến như FTP, HTTP, CSDL hay LDAP. Tuy vậy, dịch vụ công bố thông tin CTS kiểu thư mục tra cứu trực tuyến LDAP (Lightweight Directory Access Protocol) được sử dụng nhiều hơn cả trong các hạ tầng PKI hiện nay.

Dịch vụ tra cứu thư mục LDAP được thu gọn lại từ chuẩn tra cứu thư mục ISO/ITU X.500 DAP (1988) cho đơn giản, linh hoạt. LDAP là giao thức kiểu Client – Server không chỉ dành riêng cho hoạt động công bố thông tin CTS trong các hạ tầng PKI mà còn sử dụng trong nhiều dịch vụ khác.

LDAP được xây dựng đơn giản hơn so với X.500 DAP, nhưng vẫn đáp ứng được các dịch vụ tra cứu thư mục và cơ bản với mô hình thông tin và các dịch vụ chuẩn. Nó khác cơ bản với X.500 là khả năng hỗ trợ bộ giao thức TCP/IP để có thể được sử dụng rộng rãi trong môi trường Internet.

LDAP đã được sử dụng để hỗ trợ các hạ tầng PKI với các CTS vốn chủ yếu dựa trên chuẩn định dạng X.509, cho phép các cơ chế xác thực đối với các thư mục.

Các CTS X.509 được cấp phát bởi các Thẩm quyền chứng thực (CA) tại các hạ tầng PKI và là những tài liệu được công bố công khai. Các thư mục LDAP được sử dụng ở vai trò trung tâm trong hạ tầng PKI nơi mà các CTS và các danh sách chứng thư số bị gỡ bỏ CRL được lưu trữ và có thể được tải xuống bởi các phần mềm ứng dụng ràng buộc PKI cần đến chúng.

LDAP đã được sử dụng rộng rãi trong các hạ tầng PKI với các mục đích nêu trên, thay cho FTP, HTTP hay CSDL. Dịch vụ này vừa phát huy những lợi thế trong việc tra cứu thư mục của mình nhưng cũng có nhiều hạn chế đối với việc tìm kiếm, truy vấn thông tin và giá trị xác nhận tìm kiếm (Assertion Values) của các vùng khác. Tuy nhiên, LDAP không phù hợp cho mô hình phân tán kết nối nhiều hạ tầng PKI với nhiều LDAP Server để cung cấp dịch vụ tra cứu thông tin và xác thực người sử dụng như đối với X.500 DAP.

Những hạn chế trong tìm kiếm và truy vấn LDAP cũng như hoàn thiện việc quản lý các quá trình hoạt động và mức độ an toàn của hạ tầng PKI là vấn đề cần được giải quyết.

Ưu thế của dịch vụ LDAP đối với hạ tầng PKI

Các thư mục LDAP được sử dụng lưu giữ các CTS và các CRL để cung cấp khả năng phổ biến thông tin trong hạ tầng PKI. Các cơ chế khác có cùng khả năng như HTTP, FTP hay CSDL cũng có thể được sử dụng. Các cơ chế này đều có khả năng mở rộng và được chuẩn hóa nhưng LDAP là giải pháp được triển khai rộng rãi hơn cả, có rất nhiều tổ chức đã vận hành các thư mục này.

Công bố CTS và CRL

Thứ nhất, đề cập tới là khả năng lưu trữ thông tin công bố các CTS cho một người sử dụng. Thông tin trong LDAP được tổ chức phân cấp hình cây (Hình 1).

Hinh 1: Sơ đồ Cây thư mục LDAP đơn giản và điển hình

Ví dụ từ gốc c = DE phân ra hai nhánh o = OrgCA và o = Org. Xuống mức thấp hơn chúng ta có cn = MyCA và cn = Alice. Người sử dụng Alice sẽ có các thông tin cn = Alice, o = Org, c = DE và các giá trị giữa các dấu phảy tạo thành tên phân biệt tương đối RDN (Relative Distinguished Name). Giá trị toàn thể sẽ tạo thành tên phân biệt DN (Distinguished Name).

Tên phân biệt tương đối RDN thường ở dạng attribute = value, nhưng cũng có thể được biểu diễn dưới dạng nhiều giá trị như attribute1 = value1 + attribute2 = value2.

Cách biểu diễn này có khả năng tạo ra tên phân biệt tương đối RDN duy nhất trong các nhánh cây của thư mục. Trong trường hợp với các CTS thì tên của nhà cấp phát và số serial sẽ tạo thành biểu diễn duy nhất và biểu diễn này có thể được LDAP sử dụng để tạo ra các mục nhập (Entry) duy nhất dưới dạng tên phân biệt tương đối RDN nhiều giá trị.

Mỗi mục nhập LDAP có các thuộc tính và mỗi thuộc tính có một giá trị hoặc nhiều giá trị. Tất cả các mục nhập có thuộc tính gọi là objectclass mô tả kiểu mục nhập LDAP. Dựa trên các giá trị thuộc tính objectclass, mục nhập có thể có các thuộc tính khác nhau. Các thuộc tính khác nhau có thể được áp dụng cho một mục nhập bằng cách mở rộng các giá trị của objectclass.

Thông thường tên phân biệt chủ thể (Subject) chứa trong CTS của mục nhập trùng khớp với tên phân biệt của mục nhập trong thư mục. Mục nhập của người sử dụng cuối có thuộc tính person và chứa thuộc tính userCertificate. Thuộc tính này chứa CTS dưới dạng nhị phân trong thư mục. Một mục nhập người sử dụng cuối có thể chứa nhiều CTS như cần thiết. Mỗi mục nhập cho một người dùng đầu cuối khác nhau.

Để tìm kiếm đúng CTS, bắt buộc người tra cứu phải biết mục nhập có thể là từ việc tìm kiếm địa chỉ email hay tên phân biệt của chủ thể. Sau đó anh ta tải CTS về và dịch nó thành dạng hiểu được và kiểm tra xem đó có đúng là CTS muốn tìm kiếm hay không.

Tính tin cậy của thông tin chứa trong LDAP Server cũng cần được đề cập. Nếu thông tin này không được ký số thì nó có thể bị kẻ tấn công sửa đổi. Mỗi người sử dụng phải kiểm tra CKS trên CTS và CRL để đảm bảo tính toàn vẹn của dữ liệu. Bản thân LDAP cũng có một số đặc tính an toàn bổ sung để đảm bảo không có sự thay đổi trái phép bên trong thư mục.

Thứ hai là công bố danh sách chứng thư số bị gỡ bỏ CRL. Các CRL được lưu trữ trong thuộc tính đặc biệt gọi là certificateRevocationList. Có 3 objectclass cho phép thuộc tính này là certificateAuthority, pkiCA và cRLDistributionPoint. Objectclass thứ nhất không thể được sử dụng khi các CRL không trực tiếp được vận dụng vì rằng mục nhập thư mục không phải là CA và không có CTS cho CA cần phải được công bố. Hai objectclass kia cho phép thuộc tính certificateRevocationList mà không bắt buộc thuộc tính này hay các thuộc tính khác.

Objectclass cRLDistributionPoint không bắt buộc thuộc tính cn cho phép khả năng xây dựng mục nhập LDAP với “nốt” cn. Giải pháp tốt nhất là sử dụng hỗn hợp, khi cả hai objectclass đều có mặt. thuộc tính pkiCA được sử dụng để công bố CA và các CTS xác thực chéo còn cRLDistributionPoint để công bố thông tin gỡ bỏ bất kỳ.

Trong CTS chuẩn X.509 có khả năng ghi về việc tìm thông tin gỡ bỏ ở đâu tại phần mở rộng đặc biệt gọi là các cRLDistributionPoint. Đó có thể là một địa chỉ URL của LDAP hay/và một địa chỉ URL của HTTP hoặc các cơ chế khác để đạt được CRL.

Delta CRL cũng có thể được công bố trong thư mục LDAP. Thuộc tính tương ứng sẽ là deltaRevocationList và một objectclass bổ sung có thể chứa thuộc tính này là deltaCRL. Objectclass cRLDistributionPoint cũng có thể chứa các CRL. Mỗi khi delta CRL được công bố thì CRL đầy đủ cũng phải được công bố.

Cơ chế an toàn của LDAP

LDAP có một số lợi thế về cơ chế an toàn và cung cấp các cách thức xác thực khác nhau. Cách đơn giản nhất là xác thực sử dụng mật khẩu, hoặc kết hợp với lớp an toàn và xác thực đơn giản SASL dựa trên giá trị tóm lược thông báo.

TLS cũng có thể được sử dụng để đảm bảo an toàn lưu lượng mạng đi đến LDAP Server. Vì vậy, các ứng dụng người sử dụng cũng cần xác thực LDAP Server trước khi tiến hành phiên làm việc. TLS có thể được sử dụng để bảo vệ mật khẩu nếu nó được lưu thông dưới dạng rõ trong phiên làm việc.

Các cơ chế kiểm soát truy cập cũng được áp dụng cho LDAP. Người quản trị thư mục có thể thiết lập các danh sách kiểm soát truy cập ACL để cho phép các hành động nào đó đối với những người sử dụng và những phần cụ thể trong thư mục. Đây là lược đồ mạnh cho phép kiểm soát mức độ cao đến người sử dụng cũng như các hành động và dữ liệu trong thư mục. Nó cho phép thẩm quyền gỡ bỏ chỉ có thể công bố các CRL. Trong khi đó thẩm quyền chứng thực chỉ có thể công bố được các CTS. Các cơ chế này cũng ngăn chặn khả năng thay thế các CRL bằng những CRL cũ hơn hay thậm chí là xóa bỏ các CTS đang được công bố.

Sử dụng TLS thì LDAP Server cũng có thể tự xác thực. Bởi vậy, những người sử dụng muốn công bố thông tin có thể kiểm tra xem họ có công bố thông tin lên đúng LDAP Server hay không. Điều này khẳng định các CTS và CRL được công bố tại đúng chỗ cần thiết.

Đối với LDAP thì tra cứu thông tin thư mục cho một hạ tầng PKI là rất thuận tiện, hiệu quả và có khả năng an toàn nhất định. Đối với mô hình nhiều hạ tầng PKI và cần đến các chức năng tìm kiếm và truy vấn để trả về các kết quả mong muốn cho người sử dụng thì LDAP lại có rất nhiều hạn chế vì chức năng tự nhiên của nó không hướng đến các dịch vụ này.

Hạn chế của dịch vụ LDAP đối với hạ tầng PKI

Tuy được sử dụng phổ biến trong các hạ tầng PKI để công bố thông tin CTS nhưng LDAP lại có những nhược điểm so với các cách thức khác sử dụng CSDL quan hệ có cấu trúc.

LDAP là phiên bản đơn giản hóa của X.500 DAP nên nhiều đặc tính của X.500 DAP đã bị lược bỏ kể cả khả năng hỗ trợ đầy đủ các hạ tầng PKI. Đặc biệt là trong khi X.500 DAP có thể hỗ trợ tìm kiếm truy vấn và phục hồi trả về kết quả truy vấn của các khóa công khai dựa vào nội dung của chúng thì LDAP lại không có khả năng này. LDAP cũng không có khả năng tìm kiếm khóa lập mã công khai đối với người sử dụng có địa chỉ Email cụ thể. Hơn nữa, LDAPv2 không có cách thức chính xác để mã hóa các CTS hay các CRL để lưu trữ và phục hồi. Nó cũng không có khả năng sử dụng các tiện ích tìm kiếm tốt của các CSDL quan hệ và có khả năng chuyển các yêu cầu tìm kiếm của người sử dụng đến các CSDL đầu cuối.

LDAPv3 được bổ sung để điều chỉnh nhiều hạn chế trong LDAP các phiên bản trước, cho phép LDAP Server lưu trữ và phục hồi chính xác các thuộc tính X.509, nhưng khả năng tìm kiếm vẫn chưa thực hiện được. Điều đó là vì các trường của giao thức thuộc tính X.509 chỉ được vận chuyển và lưu trữ dưới dạng các khối nhị phân bởi LDAPv3 mà Server không nhận biết về cấu trúc và các nội dung của chúng.

LDAP cần khắc phục các hạn chế để có khả năng tìm kiếm đối với các thuộc tính X.509 bằng cách định nghĩa phép mã hóa LDAP chuẩn đối với các trường giao thức chứa các thuộc tính X.509.

Một hạn chế nữa cũng cần nhận thấy là trong các cơ chế ứng dụng LDAP tại các hạ tầng PKI khác nhau, không phải bao giờ giải pháp này cũng được cài đặt và do đó các hạ tầng PKI sử dụng LDAP có thể sẽ không hợp tác cùng nhau trong công việc này.

Những lưu ý khi ứng dụng LDAP

Thứ nhất là nếu phía LDAP Client cần có các truy vấn tìm kiếm, thì phía LDAP Server chưa sẵn sàng hiểu và xử lý các truy vấn này một cách tự nhiên. Kể cả việc chuyển các câu truy vấn từ LDAP Client đến LDAP Server và chuyển ngược lại các kết quả truy vấn cũng chưa được hỗ trợ theo cách thông thường mà đòi hỏi phải dịch các thông tin này dưới dạng mã ASCII để vận chuyển trên mạng.

Thứ hai là tại phía LDAP Server do các CTS được lưu dưới định dạng nhị phân ASN.1 DER được che giấu cấu trúc nội dung nên không hỗ trợ các tìm kiếm hay truy vấn tìm kiếm nội dung đòi hỏi phải có các giải pháp hoặc phiên dịch câu truy vấn thành định dạng phù hợp với định dạng ASN.1 DER. Sau đó tiến hành tìm kiếm và kết quả trả về lại được phiên dịch ngược lại để LDAP Client hiểu được hoặc phiên dịch các thuộc tính bên trong định dạng ASN.1 DER ra thành các thuộc tính gắn trên các nốt của cây thư mục, để hỗ trợ tìm kiếm theo cây thư mục các thông tin cần thiết về CTS và CRL.

Cả hai cách tiếp cận đều cần đến các giải pháp điều chỉnh và sau đó là các cài đặt thích hợp đòi hỏi phải tùy biến các sản phẩm phần mềm LDAP. Đối với sản phẩm phần mềm mã nguồn mở OpenLDAP chúng ta hoàn toàn có thể thực thi các tùy biến của mình.

Trong mô hình các hạ tầng PKI kết nối theo các phân cấp CA, xác thực chéo hay các CA bắc cầu, thì những người sử dụng CA sẽ cần truy cập đến các CTS và các CRL được chứa trong các dịch vụ thư mục PKI. Một cách lý tưởng là người ta cần đến dịch vụ thư mục phân tán được tạo thành từ tất cả các thư mục LDAP PKI riêng rẽ.

Đối với kiểu dịch vụ này thì chỉ có các thư mục phân tán dựa trên giao thức X.500 DAP là sẵn sàng, còn các LDAP Server thì không như vậy. Lý do cơ bản là LDAP Server cục bộ nơi mà người sử dụng truy cập đến trực tiếp chỉ đóng vai trò đại diện Proxy cho LDAP Server từ xa để xử lý yêu cầu người sử dụng thay vì sử dụng giao thức hệ thống thư mục DSP (Directory System Protocol) để móc xích yêu cầu trong vận hành LDAP phân tán.

LDAP cũng không có cách chuẩn hóa để thực hiện xác thực phân tán mà sử dụng đặc tính đại diện của lớp an toàn và xác thực đơn giản (SASL) để LDAP Client có thể làm đại diện cho người sử dụng hợp pháp.

Kết luận

Giao thức truy cập thư mục hạng nhẹ LDAP đã được cài đặt trong nhiều sản phẩm ứng dụng kiểu Client – Server trên nền TCP/IP và đáp ứng tốt cho nhiều loại ứng dụng, trong đó có ứng dụng công bố thông tin CTS trong các hạ tầng PKI. Do xuất phát từ giao thức truy cập thư mục X.500 DAP được thu gọn và hỗ trợ bộ giao thức TCP/IP, nên nó hướng đến sử dụng tốt trên mạng Internet và làm cho các dịch vụ truy cập thư mục được mở rộng.

Để giao thức LDAP có thể hỗ trợ cả tìm kiếm và truy vấn nội dung thông tin CTS và CRL, nhà phát triển phải xây dựng các cơ chế tìm kiếm và truy vấn nội dung rồi cài đặt chúng vào trong các sản phẩm ứng dụng có hỗ trợ giao thức LDAP ở cả phía LDAP Client và LDAP Server. Công việc này đòi hỏi phải đầu tư nghiên cứu và tìm giải pháp tích hợp vào các ứng dụng phần mềm có hoặc không có mã nguồn mở.

Với các ưu điểm và tính thuận lợi, người ta hiện nghiêng về phía sử dụng giao thức LDAP để công bố các thông tin CTS và CRL, kể cả việc tích hợp các khả năng tìm kiếm và truy vấn nội dung thông qua việc tích hợp các giải pháp thích hợp và hiệu quả.

Điều chỉnh giao thức LDAP để đáp ứng tốt các yêu cầu của thành phần công bố thông tin CTS và CRL trong hạ tầng PKI tiếp tục là một hướng nghiên cứu ứng dụng hứa hẹn và quan trọng đối với hoạt động của hạ tầng PKI hiện đại.

Tài liệu tham khảo

1.Vangelis Karatsiolis, Marcus Lippert, Alexander Wiesmaier. Planning for Directory Services in Public Key Infrastructures. Proceedings of “Sicherheit 2005, April 2005, pp. 349-360.

2. D. W. Chadwick et als. Modifying LDAP to Support X.509 – based PKIs IFIP, Volume 142, 2004, pp. 205-214.

3. D. W. Chadwick. Deficiencies in LDAP when used to support Public Key Infrastructures. Communications of the ACM, Volume 46 Issue 3, March 2003, pp. 99-104.