Trong mô hình Hub và Spoke, thay bằng việc thiết lập xác thực chéo giữa các CA, mỗi CA gốc thiết lập xác thực chéo với CA trung tâm. CA trung tâm này làm cho việc giao tiếp ựược thuận lợi hơn. CA trung tâm ựược gọi là hub (hoặc bridge) CA . động cơ thúc ựẩy mô hình này là giảm số xác thực chéo từ n2 xuống n. Một ựiểm quan trọng khác với cấu hình này là CA trung tâm không tạo ra sự phân cấp. Tất cả các thực thể trong cấu hình ựều giữ khoá công khai của CA cục bộ, không có khoá
của CA trung tâm. Như vậy, rõ ràng mô hình này giảm ựi nhược ựiểm của mô hình mạng nhưng lại gặp phải khó khăn trong việc thiết lập bridge CA làm việc với các CA khác trong hạ tầng cơ sở ựể các CA này có thể hoạt ựộng ựược với nhau.
Mô hình này do US Federal PKI phát triển ựầu tiên. Nó mở rộng PKIs qua một số tổ chức lớn chia sẻ những chắnh sách có khả năng tương thắch một cách ựặc biệt và có những CA ựã ựược thiết lập trước ựây. Minh hoạ biểu diễn cho mô hình hub và spoke ựược thể hiện trong hình 2.16.
Hình 2.16: Mô hình Hub và Spoke (Bridge CA) 2.7.5. Mô hình Web (Trust Lists)
Khái niệm về mô hình web ựược lấy ra từ tên của nó (www). Trong mô hình này, mỗi nhà cung cấp trình duyệt gắn vào trình duyệt một hoặc nhiều khoá công khai của một số root CA phổ biến hoặc nổi tiếng. Mô hình này thiết lập một mô hình tin tưởng tự ựộng giữa các các root CA mà khoá của các CA này ựược gắn trong trình duyệt và người sử dụng.
Hình 2.17: Danh sách các CA tin cậy trong Microsoft Explorer
Danh sách tin cậy phần lớn ựược sử dụng ựể xác thực web server mà những web server này ựược CA xác nhận trong danh sách trình duyệt client. Quá trình này ựược thực hiện một cách tự ựộng với giao thức SSL.
* Ưu ựiểm:
- Dễ ựể triển khai vì danh sách ựã có sẵn trong trình duyệt
- Không cần thay ựổi khi làm việc với trình duyệt web (Internet Explorer, Netscape Navigator) và tiện ắch e-mail (Outlook Express, Microsoft Outlook, Netscape Navigator).
* Nhược ựiểm:
- Về mặt công nghệ thì có thể thêm hay sửa ựổi một root CA mới nhưng hầu hết người dùng trình duyệt lại không quen thuộc với công nghệ PKI và phụ thuộc vào những CA ở trong trình duyệt này
- Người sử dụng phải tin tưởng vào danh sách CA trong trình duyệt. Nhưng một câu hỏi ựặt ra là làm thế nào ựể có thể ựảm bảo chắc chắn về tắnh chất tin cậy của CA? Các kết quả nghiên cứu cho thấy rằng hiện nay chưa có cách nào ựể phân biệt mức ựộ xác thực giữa các chứng chỉ.
- Không thể thông báo ựến tất cả trình duyệt của người sử dụng nếu khoá công khai của một CA nào ựó bị xâm hại.
Mô hình này ựơn giản trong việc thực thi và ựối với người dùng. Do ựó có khả năng ựể triển khai nhanh và sử dụng với các giải pháp COST (Commercial of the Shelf) sẵn có.
Mô hình này ựặc biệt thắch hợp cho yêu cầu PKI của những ứng dụng dựa trên Web.
2.7.6. Mô hình người sử dụng trung tâm (User Centric Model)
Trong mô hình này, mỗi người sử dụng trực tiếp và hoàn toàn có trách nhiệm trong việc quyết ựịnh tin tưởng hay từ chối chứng chỉ. Mỗi người sử dụng giữ một khoá vòng và khoá này ựóng vai trò như CA của họ. Khoá vòng chứa 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ần mềm bảo mật PGP.
Mô hình này có một số hạn chế sau:
- Không có khả năng mở rộng và thắch hợp với những miền lớn.
- Khó ựể ựặt mức ựộ tin cậy ựối với khoá công ựược lấy từ người khác. Không có
sự nhất quán của quá trình xác thực vì nó phụ thuộc vào người sử dụng
- Người sử dụng phải quản lý PKI và cần phải hiểu sâu về nó. Mặc dù có những nhược ựiểm song mô hình này vẫn thắch hợp cho việc sử dụng cá nhân trên Internet.
Mỗi mô hình ựều có ưu và nhược ựiểm riêng. Việc lựa chọn mô hình nào tuỳ thuộc vào những yêu cầu mục ựắch của cộng ựồng người dùng, tổng chi phắ, thời gian triển khai, nhân lực quản lý, công nghệ hỗ trợ và một số vấn ựề liên quan khác.
CHƯƠNG III: TRIỂN KHAI VÀ ỨNG DỤNG CHỨNG CHỈ SỐ TRONG MỘT SỐ GIAO DỊCH đIỆN TỬ
để có thể triển khai ựược dịch vụ chứng thực số, cần xây dựng một server ựảm nhiệm việc cấp phát, thu hồi chứng thực số.
Trong ựề tài này, tác giả sử dụng phần mềm Certificate Authority trên nền tảng Windows Server 2003 ựể cung cấp chứng chỉ số cho các dịch vụ.
Một số dịch vụ ựiển hình trong các giao dịch trên Internet có thể sử dụng chứng chỉ số nhằm nâng cao tắnh bảo mật cho các giao dịch:
Chữ ký ựiện tử: Sử dụng ựể xác nhân người gửi thông ựiệp, file hoặc dữ
liệu khác. Chữ ký ựiện tử không hỗ trợ bảo vệ dữ liệu khi truyền.
Chứng thực internet: Có thể sử dụng PKI ựể chứng thực client và server
ựược thiết lập nối kết trên internet, vì vây server có thể nhân dạng máy client nối kết ựen nó và client có thể xác nhân ựã nối kết ựúng server.
Bảo mật IP ( IP Security - IPSec): mở rộng IPSec cho phép mã hóa và
truyền chữ ký số, nhằm ngăn chặn dữ liệu bị lộ khi truyền trên mạng. Triển khai IPSec trên Windows Server 2003 không phải dùng PKI ựể có ựược khóa mã hóa của nó, nhưng có thể dùng PKI với mục ựắch này.
Secure e-mail: Giao thức e-mail trên internet truyền thông ựiệp mail ở che
ựộ bản rõ, vì vây nội dung mail dễ dàng ựọc ựược khi truyền. Với PKI, người gửi có thể bảo mât e-mail khi truyền bằng cách mã hóa nội dung mail dùng khóa công khai của người nhân. Ngoài ra, người gửi có thể ký lên thông ựiệp bằng khóa riêng của mình.
Smart card logon: Smart card là một loại thẻ tắn dụng. Windows Server
2003 có thể dùng smart card như là một thiết bị chứng thực. Smart card chứa chứng chỉ của user và khóa riêng, cho phép người dùng logon tới bất kỳ máy nào trong doanh nghiệp với ựộ an toàn cao.
Software code signing: Kỹ thuật Authenticode của Microsoft dùng chứng
chỉ ựể chứng thực những phần mềm người dùng download và cài ựặt chắnh xác là của tác giả và không ựược chỉnh sửa.
Wireless network authentication: Khi cài ựặt một LAN wireless, phải chắc
chắn rằng chỉ người dùng chứng thực ựúng thì mới ựược nối kết mạng và không có ai có thể nghe lén khi giao tiếp trên wireless. Có thể sử dụng Windows Server 2003 PKI ựể bảo vệ mạng wireless bằng cách nhân dạng và chứng thực người dùng trước khi họ truy cập mạng.
2.1. Cài ựặt dịch vụ và Quản lý Certificate Authority (CA) 3.1.1. Cài ựặt CA trên Windows Server 2003 3.1.1. Cài ựặt CA trên Windows Server 2003
đăng nhập vào Windows Server 2003 với quyền Administrator.
1. Click vào Start -> Control Panel -> Add Or Remove Programs. Hộp thoại Add Or Remove Programs xuất hiện.
2. Click Add/Remove Windows Components. Hộp thoại Add/Remove Windows Components xuất hiện -> chọn Certificate Services.
3. Click chọn -> chọn Details. Hộp thoại Certificate Services xuất hiện.
4. Hộp thoại cảnh báo về thành viên domain và ràng buộc ựổi tên máy tắnh xuất hiện - > click Yes.
6. Trên trang thông tin nhân ra CA, trong hộp Common name, ựánh tên của server -> click next.
7. Trên trang Certificate Database Settings, ựể ựường dẫn mặc ựịnh trong hộp Certificate database box và Certificate database log -> click Next.
8. Lời nhắc dừng Internet Information Services xuất hiện -> click Yes. 9. Enable Active Server Pages (ASPs) -> click Yes.
Như vậy, về cơ bản ta ựã hoàn thành việc cài ựặt một server cung cấp dịch vụ Certificate Serivices.
3.1.2. Quản lý dịch vụ trên CA
3.1.2.1. Sử dụng Certificates Snap-in:
Certificate Snap-in là một công cụ dùng ựể xem và quản lý chứng chỉ của một user hoặc computer cụ thể. Màn hình chắnh của snap-in bao gồm nhiều thư mục chứa tất cả hạng mục chứng chỉ số ựược chỉ ựịnh cho user hoặc computer. Neu tổ chức của người dùng sử dụng enterprise CAs, Certificate Snap-in cũng cho phép người dùng yêu cầu và thay ựổi chứng chỉ số bằng cách dùng Certificate Request Wizard và Certificate Renewal Wizard.
3.1.2.2. Yêu cầu cấp phát thông qua Web (Web Enrollment)
Khi bạn cài ựặt Certificate Services trên máy tắnh chạy Windows Server 2003, người dùng có thể chọn cài ựặt module Certificate Services Web Enrollment Support. đe hoạt ựộng một cách ựúng ựắn, module này yêu cầu người dùng phải cài ựặt IIS trên máy tắnh trước. Chọn module này trong quá trình cài ựặt Certificate Services tạo ra trang Web trên máy tắnh chạy CA, những trang Web này cho phép người dùng gửi yêu cầu cấp chứng chỉ số yêu cầu mà họ chọn.
Giao diện Web Enrollment Support ựược dùng cho người sử dụng bên ngoài hoặc bên trong mạng truy xuất ựen stand-alone CAs. Vì stand-alone server không dùng mẫu chứng chỉ so, client gửi yêu cầu bao gồm tất cả các thông tin cần thiết về chứng chỉ số và thông tin về người sử dụng chứng chỉ số.
Khi client yêu cầu chứng chỉ số dùng giao diện Web Enrollment Support, chúng có thể chọn từ danh sách loại chứng chỉ ựã ựược ựịnh nghĩa trước hoặc tạo ra chứng chỉ cao cấp bằng cách chỉ rõ tất cả các thông tin yêu cầu trong form Web-based.
3.1.2.3. Thu hồi chứng chỉ số
Có vài nguyên nhân cảnh báo cho người quản trị thu hồi chứng chỉ. Nếu như khóa riêng (private key) bị lộ, hoặc người dùng trái phép lợi dụng truy xuất ựen CA, thâm
chắ nếu bạn muốn cấp phát chứng chỉ dùng tham số khác như là khóa dài hơn, bạn phải ựược thu hồi chứng chỉ trước ựó.
Một CA duy trì một CRL (Certificate Revocation List). Enterprise CAs xuất bản CRLs của chúng trong cơ sở dữ liệu Active Directory, vì vây client có thể truy xuất chúng dùng giao thức truyền thông Active directory chuẩn, gọi là Lightweight Directory Access Protocol (LDAP).
Một stand-alone CA lưu trữ CRL của nó như là một file trên ựĩa cục bộ của server, vì vây client truy xuất dùng giao thức truyền thông Internet như Hypertext Transfer Protocol (HTTP) or File Transfer Protocol (FTP).
Mỗi chứng chỉ số chứa ựường dẫn tới ựiểm phân phối của CA cho CRLs. Có thể sửa ựổi ựường dẫn này trong Certification Authority console bằng cách hiển thị hộp thoại Properties cho CA, click vào tab Extension.
Khi một ứng dụng chứng thực client ựang dùng chứng chỉ số, nó kiểm tra ựiểm phân phối CRL ựã ựịnh rõ trong chứng chỉ số, ựể chắc chắn rằng chứng chỉ số không bị thu hoi. Nếu CRL không có tại ựiểm phân phối ựã ựịnh rõ của nó, ứng dụng từ chối chứng chỉ.
Bằng cách chọn thư mục Revoked Certificates trong Certification Authority console và sau ựó hiển thị hộp thoại Properties của nó, bạn có thể chỉ rõ bao lâu thì CA nên xuất bản một CRL mới, và cũng cấu hình CA ựể xuất bản delta CRLs.Một delta CRL là một danh sách tất cả các chứng chỉ ựã thu hồi từ khi CRL cuối cùng xuất bản. Trong tổ chức với số lượng chứng chỉ số lớn, sử dụng CRLs thay vì CRLs cơ bản có thể lưu một số lớn.
3.2.Triển khai một số dịch vụ mạng sử dụng CA
3.2.1. Dịch vụ Web sử dụng SSL
SSL-Sercue Socket Layer, là một giao thức mã hóa cung cấp sự truyền thông an toàn trên Internet như web browsing, e-mail.SSL cung cấp sự chứng thực tại các ựiểm cuối của kết nối, kênh truyền thông riêng tư trên Internet bằng cách mã hóa. Thông thường chỉ có Server là ựược chứng thực, có nghĩa là chỉ có người dùng cuối (người sử dụng, ứng dụng, ...) biết rõ mình ựang Ộnói chuyệnỢ với ai. Ở mức ựộ bảo mật cao hơn, cả hai phắa ựều phải biết nhau, chứng thực lẫn nhau. Chứng thực lẫn nhau yêu cầu dùng hạ tầng khóa công khai-PKI.
Máy Web Server ựược cấu hình dịch vụ web sử dụng SSL bằng cách nhân chứng chỉ từ CA service.
Cấu hình dịch vụ:
Tại Web server yêu cầu cấp phát chứng chỉ:
Bước 1: Mở IIS, click chuột phải vào website cần cấu hình SSL, chọn tab Directory Security, chọn Server Certificate
Nhấn Next, chọn Prepare for Request now, but send it later và lưu yêu cầu cấp phát xuống file
Bước 3: Mở Internet Explorer, gõ vào ựịc chỉ của CA Service ựể yêu cầu cấp phát chứng chỉ qua web
Chọn Request a Certificate và chọn Submit a certificate request by using a base-
64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64- encodedPKCS #7file:
Mở file yêu cầu ở trên và copy nội dung và dán vào ô Saved Request:
Nếu CA Service không cấp phát tự ựộng thì vào máy CA ựể cấp phát(Issue) cho chứng chỉ vửa yêu cầu. Vào lại trang web yêu cầu CA, chọn Download Certificate ựể tải chứng chỉ vừa ựược cấp phát về.
Bước 4: Quay trở lại IIS, chọn Process the pending request and install the
certificate ựể Import chứng chỉ vừa có ựược ở trên.
Chọn Edit, chọn Require secure channel(SSL) ựể cấu hình cho web site dùng SSL khi có yêu cầu kết nối.
Khi không dùng SSL, nếu dùng các công cụ bắt gói dữ liệu ta có thể xem ựược nội dung, còn khi dùng SSL dữ liệu sẽ ựược mã hóa và không xem ựược dù bắt ựược gói tin.
3.2.2. Dịch vụ IPSec
IPSec-Intemet Protocol Security, là một giao thức ựược thiết ke ựể bảo vệ dữ liệu bằng chữ kắ ựiện tử và mã hóa trước khi truyền ựi.IPSec mã hóa các thông tin trong gói tin IP theo cách ựóng gói nó, nên ngay cả khi bắt ựược các gói tin sẽ không ựọc ựược nội dung bên trong.
Do IPSec hoạt ựộng ở tầng mạng nên IPSec tạo một kênh mã hóa liên tục giữa các ựiểm kết nối(end-to-end), nghĩa là khi dữ liệu ựược mã hóa ở máy gửi thì chỉ ựược giải mã khi tới máy nhân.
IPSec Protocol:
- IP Authentication Header-AH: không mã hóa dữ liệu trong gói tin IP, mà chỉ mã hóa phần header. AH cung cấp các dịch vụ bảo mật cơ bản, dữ liệu có thể ựọc ựược khi bắt gói tin, nhưng nội dung thì không thể thay ựổi
- IP Encapsulating Security Payload-ESP: mã hóa toàn bộ nội dung gói tin IP, ngăn không cho người nghe lén có thể ựọc ựược nội dung khi gói tin di chuyển trên mạng. ESP cung cấp các dịch vụ chứng thực, ựảm bảo toàn vẹn và mã hóa dữ liêu.
Mô hình dịch vụ:
Trong mô hình trên, FTP server là máy tắnh cung cấp các dịch vụ truyền file trong mạng, client sẽ kết nối vào server này ựể download và upload các file dữ liệu.Trước khi các client tạo kết nối thì phải qua một quá trình chứng thực, ựể ựảm bảo an toàn trong quá trình này, cũng như cho nội dung của các file dữ liệu, ta sẽ tắch hợp với dịch vụ CA.Máy CA Service sẽ cung cấp các chứng chỉ ựể thực hiện chứng thực giữa FTP server và các client.
để làm ựược ựiều này thì máy cung cấp dịch vụ CA cũng ựóng vai trò là Domain Controler, cấp các chứng chỉ tự ựộng cho các máy khi có yêu cầu.
Triển khai dịch vụ:
Phần này trình bày một số bước ựể thiết lập chắnh sách IPSec có sử dụng CA cho mô hình bên trên. Chắnh sách này tạo tại mỗi máy có yêu cầu truyền thông bằng IPSec.
Bước 1: Trong cửa sổ chương trình IP Security Policy, tạo một chắnh sách mới
Bước 2: Chọn Next ựể thêm một luật mới, trong tab Rule chọn Add ựể thêm một danh sách các yêu cầu lọc trên giao thức IP(IP Filter List)
Bước 3: Chọn Add ựể thêm các luật theo yêu cầu cần lọc. Giả sử ở ựây ta thiết lập