3.3.1. Yêu cầu Hệ thống
Sẵn sàng hoạt động và tích hợp đƣợc với nhiều các sản phẩm khác nhau nhƣ Firewall, E-mail, Web Server,…
Khả năng phục vụ nhiều ngƣời dùng, ở các vị trí địa lý khác nhau.
Có thể kết nối nhiều CSDL về ngƣời dùng khác nhau, bao gồm từ CSDL ngƣời dùng của Windows NT, CSDL ngƣời dùng đặt trên LDAP Server, CSDL ngƣời dùng thẻ thông minh, các CSDL ngƣời dùng đặt trên các hệ quản trị CSDL.
Thao tác dễ dàng, ngƣời dùng chỉ phải đăng nhập qua một cửa (bằng cách sử dụng thẻ thông minh hay username/password của Windows NT,…) để xin cấp chứng chỉ.
Kiểm soát toàn bộ quá trình truy nhập các nguồn tài nguyên khác nhau, chỉ cần đăng nhập một lần là có thể truy nhập đƣợc tất cả tài nguyên đƣợc phép.
3.3.2. Chứng thực điện tử
Chứng thực điện tử là hoạt động chứng thực danh tính của ngƣời tham gia vào việc gửi và nhận thông tin qua mạng, đồng thời, cung cấp cho họ những công cụ, những dịch vụ cần thiết để thực hiện việc bảo mật thông tin, chứng thực nguồn gốc và nội dung thông tin.
Hạ tầng công nghệ của chứng thực điện tử hiện nay là cơ sở hạ tầng khoá công khai (PKI) với nền tảng là mật mã khoá công khai và chữ ký số.
Ngƣời dùng dịch vụ chứng thực điện tử sẽ đƣợc các cơ quan CA cấp chứng chỉ số, phải đƣợc gán cặp khoá (khoá bí mật và khoá công khai), để có thể sử dụng chứng thực điện tử trong các ứng dụng mà mình tham gia.
Nội dung của dịch vụ chứng thực điện tử:
+ Tạo cặp khoá bao gồm khoá công khai và khoá bí mật cho thuê bao. + Cấp, gia hạn, tạm đình chỉ, phục hồi và thu hồi chứng chỉ điện tử.
+ Cung cấp thông tin cần thiết để thực hiện chứng thực chữ ký điện tử của ngƣời ký thông điệp. Duy trì trực tuyến cơ sở dữ liệu về chứng thƣ số.
Nội dung của chứng chỉ điện tử:
+ Tên của tổ chức cung cấp dịch vụ chứng thực chữ ký số. + Tên của thuê bao.
+ Số hiệu của chứng thƣ số.
+ Thời hạn có hiệu lực của chứng thƣ số. + Khoá công khai của thuê bao.
+ Chữ ký số của tổ chức cung cấp dịch vụ chứng thực chữ ký số. + Các hạn chế về mục đích, phạm vi sử dụng của chứng thƣ số.
+ Các hạn chế về trách nhiệm pháp lý của tổ chức cung cấp dịch vụ chứng thực chữ ký số.
+ Các nội dung cần thiết khác theo quy định của Bộ Bƣu chính, Viễn thông.
Quyền và nghĩa vụ của nhà cung cấp dịch vụ chứng chỉ điện tử:
+ Tuân thủ các quy định của pháp luật về việc thành lập, tổ chức và hoạt động đối với loại hình dịch vụ chứng chỉ điện tử.
+ Sử dụng hệ thống thiết bị kỹ thuật, quy trình và nguồn lực tin cậy để thực hiện các công việc của mình
+ Bảo đảm tính chính xác và toàn vẹn của các nội dung cơ bản trong chứng chỉ điện tử do mình cấp
+ Công khai thông tin về các chứng chỉ điện tử đã cấp, đƣợc gia hạn, tạm đình chỉ, phục hồi hoặc bị thu hồi.
+ Cung cấp phƣơng tiện thích hợp cho phép các bên tin vào chữ ký điện tử, cơ quan quản lý nhà nƣớc có thẩm quyền có thể dựa vào chứng chỉ điện tử để xác định chính xác nguồn gốc của thông điệp và chữ ký điện tử.
+ Thông báo cho các bên liên quan trong trƣờng hợp xảy ra sự cố ảnh hƣởng đến việc chứng thực chữ ký điện tử.
Quyền và nghĩa vụ cụ thể của nhà cung cấp dịch vụ được quy định tại mục 1, chương IV và điều 47 của [7].
3.3.3. Một số mô hình kiến trúc của CA [19]
Kiến trúc phân cấp
Thông thƣờng các CA đƣợc tổ chức thành ba cấp. Cấp cao nhất là Root CA, bên
dƣới là các Primary CA và cấp dƣới cùng là subordinate CA.
Khoá công khai của CA cấp dƣới sẽ do CA cấp trên ký. Mô hình kiến trúc phân cấp nhƣ sau:
Kiến trúc ngang hàng (peer-to-peer)
Trong kiến trúc này, hai hay nhiều CA có vai trò ngang bằng nhau. Ngƣời dùng có thể liên lạc với bất kỳ CA nào để yêu cầu chứng chỉ số. Ƣu điểm của kiến trúc này là uyển chuyển, dễ thay đổi.
Mô hình kiến trúc nhƣ sau:
Hình 3.3: Kiến trúc ngang hàng Hình 3.2: Kiến trúc phân cấp
Kiến trúc hỗn hợp (Hybrid)
Là sự kết hợp giữa hai kiến trúc phân cấp và ngang hàng nhằm tận dụng ƣu điểm của cả hai loại kiến trúc. Trong thực tế ngƣời ta thƣờng sử dụng kiến trúc này.
Hình 3.4: Kiến trúc hỗn hợp
3.3.4. Đề xuất Mô hình kiến trúc hệ thống của CA [19]
Xây dựng mô hình kiến trúc hệ thống của CA nhằm thực hiện việc cấp phát, quản lý và xác nhận chứng chỉ số. Mô hình có tích hợp máy chủ quản trị hệ thống (administration server), máy chủ đăng ký (enrollment server), máy chủ thƣ mục và máy chủ theo dõi truy cập (directory và logging server).
Administration server:
Hỗ trợ ngƣời quản trị hệ thống điều khiển toàn bộ hệ thống. Ngƣời quản trị hệ thống sử dụng giao diện web thông qua giao thức https://, để truy cập các chức năng của Administration server.
Enrollment server:
Nhằm phục vụ ngƣời sử dụng đăng ký cấp chứng chỉ số. Directory server:
Lƣu trữ dữ liệu về chứng chỉ số, yêu cầu cấp chứng chỉ số của ngƣời sử dụng, Access Control Lists (ACLs), system events,…
Các loại dữ liệu này đƣợc bảo vệ bằng các công nghệ mã hoá, chữ ký số,… Các ứng dụng bên ngoài chỉ có thể đƣợc phân quyền đọc các dữ liệu này, chỉ có Enrollment và Administration server mới đƣợc quyền ghi thông qua giao thức SSL- LDAP (giao thức LDAP dùng công nghệ SSL thay vì trực tiếp sử dụng dịch vụ của giao thức TCP).
Logging server:
Đƣợc cấu hình để ghi lại mọi hành động của ngƣời quản trị hệ thống, ngƣời yêu cầu cấp phát/ huỷ chứng chỉ số ở các cấp độ khác nhau.
OCSP server:
Đáp ứng yêu cầu truy vấn tình trạng của các chứng chỉ số. SCEP server:
Đáp ứng yêu cầu cấp phát chứng chỉ số một cách tự động thông qua mạng riêng ảo (VPN) tƣơng thích giao thức với SCEP.
Tất cả các server liệt kê trên đều có thể nằm trên một máy chủ duy nhất và hoạt động nhƣ một CA bình thƣờng. Tuy nhiên để tăng cƣờng hiệu năng cũng nhƣ tính bảo mật của hệ thống, các thành phần bổ sung thƣờng đƣợc sử dụng kết hợp.
Hình 3.6: Các thành phần bổ sung của một CA Registration Authority Registration Authority Server WebSentry Certificate Authority Recovery Module
Registration Authority (RA):
Làm trung gian giữa ngƣời dùng với CA. Hệ thống nhận ra các yêu cầu từ ngƣời dùng (xin cấp phát hay huỷ chứng chỉ số), kiểm tra, phê duyệt sau đó chuyển cho CA để xử lý.
Kết quả CA trả lại sẽ đƣợc RA chuyển cho ngƣời dùng. RA trong hệ thống thay thế nhiệm vụ của Enrollment server trong mô hình hệ thống giúp giảm tải của CA.
Hơn nữa trong mô hình này RA có thể bố trí ở các vị trí địa lý khác nhau, giúp mở rộng diện phục vụ của hệ thống đến ngƣời dùng ở mọi nơi.
Kiến trúc của RA trong hệ thống này tƣơng tự kiến trúc của CA nhƣ sau:
Hình 3.7: Mô hình kiến trúc của RA
Recovery module:
Cung cấp giải pháp an toàn để sinh, lƣu khoá. Khi cần module này có thể đƣợc sử dụng để khôi phục lại khoá bí mật của ngƣời dùng bất kỳ trong trƣờng hợp bị thất lạc hoặc ngƣời dùng dừng tham gia hệ thống.
Để khôi phục khoá bí mật cần có sự phối hợp của một số ngƣời có thẩm quyền. WebSentry:
Là một plug-in cho máy chủ Web, giúp chúng tƣơng tác tốt hơn với chứng chỉ số và quản lý truy cập đến tài nguyên trên máy chủ web.
S e c ur e D ir e ct ory S er ve r L oggi ng S er ve r S CE P S er ve r A dm in is tr a ti on S er ve r E nr ol lm e n t S er ve r SSL-LDAP SSL-LDAP SSL Web Server https https Administrator User
3.3.5. Mô hình tích hợp hệ thống ứng dụng với kiến trúc CA
Cấu hình hệ thống cấp phát chứng chỉ số
Để bảo vệ hệ thống khỏi sự xâm nhập từ bên ngoài, ngoài cơ chế tự bảo vệ của giải pháp và hệ điều hành, cần phải cài đặt Firewall và phần mềm phòng chống - phát hiện đột nhập (IDS).
Đối với IDS, có thể sử dụng phần mềm mã nguồn mở SnorthTM hoặc Synmatec Host IDS của hãng Synmatec [19].
Hình 3.8: Topo mạng của hệ thống cấp phát chứng chỉ
Máy chủ thứ nhất cài đặt hệ thống quản lý cấp phát và thu hồi chứng chỉ (CA Server) và Web server.
Máy chủ thứ hai là máy chủ RA (RA Server) và Web server.
Máy chủ thứ 3 và thứ 4 làm kho dữ liệu cho hệ thống. Dịch vụ thƣ mục Microsoft Active Directory đƣợc dùng để lƣu dữ liệu. Máy chủ thứ 4 có nhiệm vụ backup dữ liệu từ máy chủ thứ 3. Khi dữ liệu cập nhật vào máy chủ thứ 3, sẽ đƣợc tự động cập nhật sang máy chủ thứ 4 (Replication).
Internet Administrator Administrator Application & secureID Passage LDAP Server
Replicated LDAP Server
High Speed
LAN Router Router/RAS
PSTN WAN Application & secureID Passage SmartCard SmartCard RA & Webserver CA & Webserver
Nguyên lý vận hành và quản trị hệ thống cấp phát chứng chỉ số
Ngƣời quản trị hệ thống truy cập Administration server trên CA Server và RA Server thông qua giao diện Web và dùng giao thức https. Để truy nhập chức năng quản trị hệ thống, quá trình chứng thực hai bên giữa ngƣời quản trị hệ thống và hệ thống phải thành công. Qua giao diện web, ngƣời quản trị có thể quản trị và thay đổi cấu hình toàn bộ hệ thống.
Tích hợp vào các ứng dụng hệ thống
Hệ thống phải sẵn sàng tích hợp đƣợc với nhiều ứng dụng phổ biến khác nhau nhƣ Firewall, Email, Directory Service, Web, truy nhập từ xa, mạng riêng ảo (VPN),… Việc tích hợp này mang lại lợi ích lớn cho ngƣời sử dụng các dịch vụ an toàn và bảo mật thông tin.
Tích hợp vào các ứng dụng nghiệp vụ
Đối với các đối tƣợng dùng thẻ thông minh, việc tích hợp các chức năng mã hoá, tạo chữ ký số,… sẽ tƣơng đối dễ dàng và an toàn do chúng ta có thể tích hợp để thẻ thông minh trực tiếp thực hiện chức năng đó.
Khi xây dựng hệ thống cần tuân theo các chuẩn mở nhƣ JavaCard và PKCS#11. Điều này sẽ làm đơn giản việc xây dựng các module phần mềm truy xuất, khai thác các tài nguyên và chức năng trên thẻ thông minh bằng nhiều ngôn ngữ lập trình khác nhau.
Đối với đối tƣợng không dùng thẻ thông minh, việc xây dựng các module phần mềm thực hiện các chức năng mã hoá, tạo chữ ký số, kiểm tra chữ ký số để tích hợp với hệ thống có thể dựa trên các chuẩn mở X.509, LDAP, OCSP, PKCS#11.
Nếu lựa chọn giải pháp mua công nghệ sẵn có, chúng ta phải xây dựng các module chƣơng trình, các thƣ viện liên kết động (DLL) để gọi các chức năng ký, kiểm tra chữ ký, xác thực ngƣời ký, ghi/ đọc các thiết bị lƣu chữ ký căn cứ trên các hàm API, cụ thể:
Đối với các ứng dụng phát triển bằng JSP, cần xây dựng các module giao diện nhƣ Applets, JavaBean,…
Đối với các ứng dụng phát triển trên nền công nghệ .Net, cần phải xây dựng các thƣ viện liên kết động (DLL).
Đối với các ứng dụng phát triển trên nền Oracal, cần xây dựng các module trên ngôn ngữ PL/SQL nhằm đảm bảo độ tƣơng thích tối đa.
3.3.6. Khả năng mở rộng của hệ thống
Cần xây dựng hệ thống có khả năng mở rộng. Để làm đƣợc điều này cần xây dựng hệ thống theo cả 3 kiến trúc CA đã trình bày ở trên. Ngƣời quản trị chỉ cần các thao tác đơn giản để thực hiện thay đổi kiến trúc.
Ví dụ: Hai CA | A và B đang ở kiến trúc ngang hàng, để A trở thành Root CA và
B trở thành Subordinate CA, ngƣời quản trị hệ thống chỉ cần thay đổi chữ ký số lên
khoá công khai của B thành chữ ký khoá công khai của A, trong khi vẫn giữ nguyên chữ ký lên khoá công khai của A, vẫn là chữ ký số của chính A.
Có thể mở rộng phạm vi ngƣời dùng của hệ thống bằng cách phân tán vị trí địa lý của hệ thống.
Hình 3.9: Triển khai hệ thống cấp phát chứng chỉ số phân tán
Registr CA RA RA RA RA RA RA Web Administrator
3.4. MÔ HÌNH KỸ THUẬT 3.4.1. Giải pháp kỹ thuật cơ bản 3.4.1. Giải pháp kỹ thuật cơ bản
Mã hoá: Dùng các hệ mã hoá RSA, Elgamal, DES. Ký số: Dùng các sơ đồ ký DSA, RSA, Elgamal. Chứng chỉ số: X.509
Giao thức truyền tin an toàn tầng DataLink:
Bảo vệ ARP bằng việc ký số, đƣa chứng chỉ vào việc xác thực các IP cho các máy với địa chỉ MAC.
Giao thức truyền tin tầng ứng dụng:
Trao đổi hồ sơ, văn bản dựa trên giao thức S/MIME. Công cụ phát triển: Dựa trên phần mềm mã nguồn mở.
3.4.2. Mô hình kiến trúc kỹ thuật cho CA
Trong đó, chính sách chứng chỉ tuân theo các quy định sau:
Bảng I: Giao diện CA-CA
Bảng II: Giao diện CA-EE
Bảng III: Giao diện hồi đáp EE và giao diện hồi đáp VA
Nội dung Giao diện
Giao thức truy nhập EE-VA Tuỳ chọn. Vai trò của VA
Certificate Validation Server (Path Construction, Path Validation)
Bảng IV: Giao diện EE-VA
Nội dung Giao diện
Chính sách chứng chỉ X.509(97) v3[x509], RFC3280[3280] Định dạng mã hoá chứng chỉ DER[x690]
Chính sách CRL X.509(97) v3, RFC3280
Định dạng mã hoá CRL DER
Định dạng yêu cầu chứng chỉ chéo PKCS#10[p10] Định dạng hồi đáp chứng chỉ. X.509/DER Phƣơng pháp gửi che dấu thông tin E-Mail
POP (proof of possession) Xác minh chữ ký trên chứng chỉ
Nội dung Giao diện
Định dạng chứng chỉ EE PKCS#12[p12]
(Bao gồm cả khoá bí mật)
Nội dung Giao diện
Giao thức truy nhập
Nội dung Giao diện
Phƣơng thức hợp lệ hoá đƣờng dẫn
chứng chỉ RFC3280
Thực thể xác minh chứng chỉ VA, EE
Bảng V: Giao diện EE-EE
Ghi chú:
+ Giao diện CA-CA: Giao diện trao đổi giữa hai cơ quan chứng thực.
+ Giao diện CA-EE: Giao diện giữa cơ quan chứng thực và ngƣời dùng cuối. + Giao diện hồi đáp EE: Giao diện các thông tin phản hồi lại ngƣời dùng cuối. + Giao diện hồi đáp VA: Giao diện các thông tin phản hồi lại các hệ thống chứng thực mở rộng.
+ Giao diện EE-VA: Giao diện giữa ngƣời dùng cuối và hệ thống chứng thực mở rộng.
+ Giao diện EE-EE: Giao diện giữa các đối tƣợng dùng cuối với nhau (có thể giữa các modun phần mềm với nhau hoặc giữa ngƣời dùng cuối với các đối tƣợng/ thiết bị dùng cuối).
3.4.3. Giới thiệu công nghệ OpenCA
OpenCA là dự án nhằm xây dựng PKI hoàn chỉnh, chuyên nghiệp cho các đơn vị cỡ vừa và lớn. OpenCA đƣợc phát triển liên tục từ năm 1999 đến nay, từ năm 2001, OpenCA đã bắt đầu đƣợc sử dụng trong thực tế.
OpenCA dùng giao diện web, hỗ trợ hầu hết các web browser chính, khác với sản phẩm thƣơng mại, không hỗ trợ sản phẩm mã nguồn mở, vì sợ bị cạnh tranh.
OpenCA bao gồm các module:
Giao tiếp công cộng: Giao diện web để ngƣời dùng truy cập qua internet.
Ngƣời dùng có thể đăng kí xin cấp chứng chỉ trực tiếp qua module này. Giao tiếp LDAP: Danh bạ công bố khoá công khai, ngƣời dùng thƣờng lấy
khoá công khai từ module này để thực hiện việc mã hoá trƣớc khi gửi thƣ đến đơn vị dùng OpenCA.
Giao tiếp RA: Đơn vị điều hành RA dùng module này để nhập các thông tin
xác thực cá nhân của ngƣời xin cấp chứng chỉ.
Giao tiếp OCSP: Module hỗ trợ kiểm tra chứng chỉ còn hiệu lực hay không.
Công nghệ OCSP có tác dụng nhƣ việc công bố CRL, nhƣng tính năng ƣu
