Một Certificate Authority (CA) là một thực thể PKI có trách nhiệm cấp chứng chỉ cho các thực thể khác trong hệ thống. Nó đóng vai trò là bên thứ ba để hỗ trợ cho quá trình trao đổi thông tin an toàn. Thông thƣờng, CA thực hiện chức năng xác thực bằng cách cấp chứng chỉ cho các CA khác và cho thực thể cuối ( ngƣời giữ chứng chỉ) trong hệ thống. Nếu CA nằm ở đỉnh của mô hình phân cấp PKI và chỉ cấp chứng chỉ cho những CA ở mức thấp hơn thì CA này đƣợc gọi là “ Root CA ”.
Có một số mô hình CA tin cậy có thể đƣợc á p dụng trong hạ tầng mã khóa công khai - PKI dựa trên X.509 nhƣ:
* Single CA Model ( Mô hình CA đơn ) * Hierarchical Model ( Mô hình phân cấp )
* Mesh Model ( Mô hình mắt lƣới – Mô hình xác thực chéo ) * Bridge CA Model ( Mô hình cầu CA )
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
* Web Model ( Trust Lists ) ( Mô hình web )
* User Centric Model ( Mô hình ngƣời sử dụng trung tâm )
2.3.1. Chức năng của CA 2.3.1.1. Cấp phát chứng chỉ số
Ngƣời sử dụng chọn một trong hai cách sau để tạo cặp khóa :
* Cặp khóa công khai / khóa bí mật do Tổ chức chứng thực (CA) tạo ra.
* Ngƣời sử dụng tự tạo cặp khóa và đƣa khóa công khai cho CA để CA tạo chứng chỉ cho khóa công đó.
Hình 2.10 minh họa quá trình cấp chứng chỉ số của CA nhƣng với khóa công khai là do ngƣời sử dụng tự tạo.
Hình 2.10 : Quá trình cấp chứng chỉ số với khóa công khai do người dùng tạo
Hình 2.11 minh họa quá trình cấp chứng chỉ số cho ngƣời sử dụng nhƣng cặp khóa bí mật và công khai do CA tạo ra.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
Hình 2.11 : Quá trình cấp chứng chỉ với cặp khóa do CA tạo ra
Quy trình CA cấp chứng chỉ như sau :
* Ngƣời sử dụng cung cấp thông tin về bản thân và khóa công khai của mình cho hệ thống có thẩm quyền cấp phép ( CA ) hoặc nếu ngƣời sử dụng hoàn toàn tin tƣởng vào CA thì CA sẽ sinh cặp khóa cho ngƣời dùng.
* CA sẽ thực hiện kiểm tra thông tin của ngƣời dùng có hợp lệ không. Nếu hợp lệ, CA sẽ dùng khóa bí mật của mình để mã hóa tổ hợp khóa công khai và thông tin tạo ra chứng chỉ số cấp cho ngƣời sử dụng.
* CA đƣa chứng chỉ này vào kho lƣu trữ để ngƣời khác có thể truy nhập đƣợc.
2.3.1.2. Chứng thực khóa công khai
Chức năng này của CA cho phép kiểm tra một chứng chỉ của ngƣời dùng là giả hay thật. Hình 2.12 minh họa quá trình CA chứng thực khóa công khai của Bob. Quá trình này đƣợc mô tả nhƣ sau :
Để xác thực xem giấy phép của Bob có đích thực do hệ thống cung cấp hay là một giấy phép giả. CA sẽ dùng khóa công khai của mình để giải mã giấy phép. Nếu giải mã đƣợc thì giấy phép là thật.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
Hình 2.12 : Quá trình chứng thực khóa công khai
Ngoài ra CA còn có các chức năng khác nhƣ cấp lại và huỷ bỏ chứng chỉ.
2.3.2. Các mô hình CA 2.3.2.1. Mô hình CA đơn
Đây là mô hình tổ chức CA cơ bản và đơn giản nhất. Trong mô hình CA đơn chỉ có một CA xác nhận tất cả các thực thể cuối trong miền PKI. Mỗi ngƣời sử dụng trong miền nhận khóa công khai của CA gốc (root CA) theo một số cơ chế nào đó. Trong mô hình này không có yêu cầu xác thực chéo. Chỉ có một điểm để tất cả ngƣời sử dụng có thể kiểm tra trạng thái thu hồi của chứng chỉ đã đƣợc cấp. Mô hình này có thể đƣợc mở rộng bằng cách có thêm các RA ở xa CA nhƣng ở gần các nhóm ngƣời dùng cụ thể.
Mô hình này đƣợc minh hoạ trong hình 2.12.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
Mô hình này dễ triển khai nhƣng nó có một số nhƣợc điểm sau:
* Việc quản trị và khối lƣợng công việc kỹ thuật của việc vận hành CA đơn sẽ rất cao trong cộng đồng PKI lớn.
* Không thích hợp cho miền PKI lớn. Chỉ có một CA sẽ gây ra thiếu khả năng hoạt động và CA này có thể trở thành mục tiêu tấn công.
2.3.2.2. Mô hình phân cấp
Trong mô hình này, CA gốc xác nhận các CA cấp dƣới, các CA này lại xác nhận các CA cấp thấp hơn. Các CA cấp dƣới không cần xác nhận các CA cấp trên. Mô hình phân cấp đƣợc mô tả trong hình 2.13
Hình 2.13 : Mô hình phân cấp
Trong mô hình này, mỗi thực thể sẽ giữ bản sao khóa công khai của Root CA và kiểm tra đƣờng dẫn của chứng chỉ bắt đầu từ chữ ký của CA gốc.
Mô hình này có thể dùng đƣợc cho những doanh nghiệp phân cấp và độc lập .Tuy nhiên, mô hình phân cấp có một số nhƣợc điểm nhƣ:
*Các tổ chức có thể không tự nguyện tin vào các tổ chức khác.
* Những tổ chức thiết lập CA trƣớc có thể không muốn trở thành một phần của mô hình.
* Chỉ có một CA gốc nên có thể gây ra một số vấn đề nhƣ thiếu khả năng hoạt động. Thêm vào đó, trong trƣờng hợp khóa bí mật của CA bị
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
xâm phạm, khóa công khai mới của CA gốc phải đƣợc phân phối đến tất cả các ngƣời sử dụng cuối trong hệ thống theo một số cơ chế khác nhau.
2.3.2.3. Mô hình mắt lưới ( xác thực chéo )
Mô hình mắt lƣới là mô hình đƣa ra sự tin tƣởng giữa hai hoặc nhiều CA. Mỗi CA có thể ở trong mô hình phân cấp hoặc trong mô hình mắt lƣới khác. Trong mô hình này không chỉ có một CA gốc mà có nhiều hơn một CA gốc phân phối sự tin cậy giữa các CA với nhau. Thông qua việc xác thực chéo giữa các CA gốc, các CA có thể tin tƣởng lẫn nhau. Xác thực chéo liê n kết các miền khác nhau bằng việc sử dụng thuộc tính BasicConstraints, Name Constraints, PolicyMapping và PolicyConstraints của X.509 v3 mở rộng.
Hình 2.15 : Mô hình mắt lưới
Ƣu điểm của mô hình:
* Cho phép những nhóm ngƣời sử dụng khác nhau có thể tự do phát triển và thực thi những chính sách và chuẩn khác nhau.
* Phù hợp với nhu cầu giao dịch hiện nay.
* Khắc phục đƣợc những nhƣợc điểm của mô hình phân cấp tin cậy ở trên.
Nhƣng mô hình này có nhƣợc điểm là phức tạp và khó để quản lý vì việc xác thực chéo.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
2.3.2.4. Mô hình Bridge CA
Trong mô hình Bridge CA, 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à bridge CA. 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ữ khóa công khai của CA cục bộ, không có khóa của CA trung tâm. Mô hình này 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 Bridge CA đƣợc thể hiện trong hình 2.15
Hình 2.15 : Mô hình Bridge CA
2.3.2.5. Mô hình Web ( Trust Lists )
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 khóa công khai của một số root CA phổ biến. Mô hình này thiết lập một mô hình tin tƣởng tự động giữa các root CA mà
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
khóa của các CA này đƣợc gắn trong trình duyệt và ngƣời sử dụng.
Hình 2.16 chỉ ra danh sách các root CA đƣợc gắn trong trình duyệt của IE
Hình 2.16 : Danh sách các Root CA tin cậy trong Internet Explorer
Ƣ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 nhƣ Internet Explorer…và tiện ích e-mail nhƣ Outlook Express…
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.
* Không thể thông báo đến tất cả trình duyệt của ngƣời sử dụng nếu khóa công khai của một CA nào đó bị xâm hại.
2.3.2.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 giữ một khóa vòng và khóa này đóng vai trò nhƣ CA của họ. Khóa vòng chứa khóa công khai đƣợc tin
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
cậy của những ngƣời sử dụng khác trong cộng đồng. Mô hình này có nhƣợc điểm là khó để đặt mức độ tin cậy đối với khóa công khai đƣợc lấy từ ngƣời khác.
2.3.3. Một số chứng chỉ số do CA phát hành 2.3.3.1. Chứng chỉ số cá nhân
Email đóng một vai trò khá quan trọng trong trao đổi thông tin hàng ngày của chúng ta vì ƣu điểm nhanh, rẻ và dễ sử dụng. Những thông điệp có thể gửi đi nhanh chóng, qua Internet, đến những khách hàng, đồng nghiệp, nhà cung cấp và các đối tác. Tuy nhiên, email rất dễ bị tổn thƣơng bởi các hacker. Những thông điệp có thể bị đọc hay bị giả mạo trƣớc khi đến ngƣời nhận.
Bằng việc sử dụng chứng chỉ số cá nhâ n, sẽ ngăn ngừa đƣợc các nguy cơ này mà vẫn không làm giảm những lợi thế của email. Với chứng chỉ số cá nhân, bạn có thể tạo thêm một chữ ký điện tử vào email nhƣ một bằng chứng xác nhận của mình.
Ngoài ra, chứng chỉ số cá nhân còn cho phép ngƣời dùng có thể chứng thực mình với một web server thông qua giao thức bảo mật SSL. Phƣơng pháp chứng thực dựa trên chứng chỉ số đƣợc đánh giá là tốt, an toàn và bảo mật hơn phƣơng pháp chứng thực truyền thống dựa trên mật khẩu.
2.3.3.2. Chứng chỉ số SSL Server
Khi Website sử dụng cho mục đích thƣơng mại điện tử hay cho những mục đích quan trọng khác, những thông tin trao đổi giữa doanh nghiệp và khách hàng có thể bị lộ. Để tránh nguy cơ này, doanh nghiệp có thể dùng chứng chỉ số SSL Server để bảo mật cho Website của mình.
Chứng chỉ số SSL Server sẽ cho phép doanh nghiệp lập cấu hình Website của mình theo giao thức bảo mật SSL (Secure Sockets Layer). Loại chứng chỉ số này sẽ cung cấp cho Website của bạn một định danh duy
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
nhất nhằm đảm bảo với khách hàng về tính xác thực và tính hợp pháp của Website. Chứng chỉ số SSL Server cũng cho phép trao đổi thông tin an toàn và bảo mật giữa Website với khách hàng, nhân viên và đối tác thông qua công nghệ SSL mà nổi bật là các tính năng:
* Thực hiện mua bán bằng thẻ tín dụng.
* Bảo vệ những thông tin cá nhân nhạy cảm của khách hàng. * Đảm bảo hacker không thể dò tìm đƣợc mật khẩu.
2.3.3.3. Chứng chỉ số nhà phát triển phần mềm
Một nhà sản xuất phần mềm, luôn cần những ''con tem chống hàng giả'' cho sản phẩm của mình. Đây là một công cụ không thể thiếu trong việc á p dụng hình thức sở hữu bản quyền. Chứng chỉ số Nhà phát triển phần mềm sẽ cho phép nhà phát triển phần mềm ký vào các applet, script, Java software, ActiveX control, các file dạng EXE, CAB, DLL... Nhƣ vậy, thông qua chứng chỉ số, nhà phát triển phần mềm sẽ đảm bảo tính hợp pháp cũng nhƣ nguồn gốc xuất xứ của sản phẩm. Hơn nữa ngƣời dùng sản phẩm có thể xác thực đƣợc nhà cung cấp, phát hiện đƣợc sự thay đổi của chƣơng trình (do vô tình hỏng hay do virus phá, bị crack và bán lậu...).
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
CHƢƠNG 3
CÀI ĐẶT HỆ THỐNG CHỨNG CHỈ SỐ THỬ NGHIỆM 3.1 Tổng quan về hệ thống chứng chỉ số thử nghiệm tại Trƣờng Dự bị Đại học Dân tộc Sầm Sơn (phát biểu bài toán, mô hình hệ thống).
3.1.1 Phát biểu bài toán
Sơ đồ tổ chức trƣờng Dự bị Đại học Dân tộc Sầm Sơn
Số đơn vị trong trƣờng Dự bị Đại học Dân tộc Sầm Sơn:
Ban Giám hiệu: 1 Phòng Tài chính – Quản trị (TC - QT) 1 Phòng Tổ chức – Hành chính (TC - HC) 1 Phòng Công tác HSSV (CT HSSV) 1
Phòng Giáo vụ 1
Ban Khoa học Tự nhiên ( Ban KHTN) 1 Ban Khoa học Xã hội ( Ban KHXH) 1 Đảng ủy: 1 Công đoàn: 1
Đoàn thanh niên: 1 Ban giám hiệu
Phòng TC – HC Phòng TC - QT Phòng Giáo vụ Phòng CT HSSV Ban KHXH Ban KHTN Đơn vị đoàn thể
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
3.1.1.2 Nhu cầu về Ký và Xác thực các văn bản hành chính tại Trường Dự bị Đại học Dân tộc Sầm Sơn
3.1.1.2.1 Tại Phòng Tổ chức – Hành chính
+ Gần 9 tháng của năm 2011 (khoảng 300 ngày), số “công văn đi” tại Phòng Tổ chức – Hành chính là 2000. Nhƣ vậy trung bình mỗi ngày có khoảng 2000 / 270 ngày = 7,5 “công văn đi” xấp xỉ 8 “công văn”.
+ Mỗi công văn này, lại phải đƣợc ký “tƣơi” thành nhiều bản để gửi đi các đơn vị phòng ban trong hay ngoài Trƣờng Dự bị Đại học dân tộc sầm sơn.
+ Số “công văn đến” cần “Xác thực chữ ký” cũng tƣơng đƣơng với số “công văn” đến.
+ Riêng Trƣờng Dự bị Đại học Dân tộc Sầm sơn có 6 đơn vị tƣơng đƣơng cần đƣợc gửi công văn, ít nhất mỗi công văn phải đƣợc ký “tƣơi” thành 06 bản để gửi đi và 01 bản để lƣu. Nhƣ vậy trung bình mỗi ngày có khoảng 8 x 10 = 80 “công văn đi”.
+ Mỗi “công văn đi” thƣờng có ít nhất 2 “chữ ký” (1 ký “nháy”), Nhƣ vậy trung bình mỗi ngày, Trƣờng Dự bị Đại học Dân tộc Sầm Sơn cần khoảng khoảng 160 “Chữ ký”.
3.1.1.2.2. Tại Phòng Tài chính – Quản trị
1/. Dạng 1: Các loại phiếu thu, phiếu chi, bảng lƣơng, giấy đề nghị thanh
toán, giấy đề nghị tạm ứng. Số lượng khoảng 4 phiếu/01 ngày.
2/. Dạng 2: Văn bản có số dạng văn bản này gồm có hợp đồng, thanh
lý hợp đồng, thuê mƣớn sửa chữa nhà cửa, trang thiết bị trong Trƣờng. Số lượng khoảng 03 văn bản/01 ngày.
3/. Dạng 3: Văn bản không có số bao gồm có giấy mời họp, chƣơng trình họp, nội dung họp, … Số lƣợng khoảng 01 văn bản/01 ngày.
+ Gần 9 tháng năm 2011 (khoảng 270 ngày), số công văn, văn bản, tài liệu tại Phòng Tài chính – Quản trị (Có ghi số hay không ghi số) là cũng khoảng 2000.
Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc-tnu.edu.vn
+ Ít nhất mỗi công văn phải đƣợc ký “tƣơi” thành 04 bản để gửi đi và lƣu. Nhƣ vậy trung bình mỗi ngày có khoảng 4 x 8 = 32 “công văn”.
+ Mỗi “công văn” thƣờng có ít nhất 3 “chữ ký”. Nhƣ vậy trung bình mỗi ngày Phòng Tài chính – Quản trị cần khoảng 96 “Chữ ký”.
3.1.1.2.3. Tại Phòng Công tác HSSV
+ Gồm các văn bản về việc kỷ luật học sinh vi phạm quy chế, lịch trực quản lý học sinh, quyết định cho học sinh nghỉ học, tờ trình đề nghị sửa chữa cơ sở vật chất khu ký túc xá … Gần 9 tháng năm 2011 (khoảng 270 ngày), số công văn, văn bản, tài liệu tại Phòng Công tác HSSV (Có ghi số cũng nhƣ ghi số) là khoảng 3000.
+ Ít nhất mỗi “công văn” phải đƣợc ký “tƣơi” thành 04 bản để gửi đi và lƣu. Nhƣ vậy mỗi ngày trung bình có khoảng 3000/270 x 4 = 44 “công văn” cần ký
+ Mỗi “công văn” thƣờng có ít nhất 3 “chữ ký”. Nhƣ vậy trung bình mỗi ngày Ban Khoa học Tự nhiên cần khoảng 44 x 3 = 132 “chữ ký”.
3.1.1.2.4. Tại Phòng Giáo vụ
+ Gồm các văn bản về kết quả học tập của học sinh, bảng theo dõi nề nếp, quyết định cử học sinh học, giấy đề nghị sửa chữa cơ sở vật chất khu giảng đƣờng… Gần 9 tháng năm 2011 (khoảng 270 ngày), số công văn, văn bản, tài liệu tại Phòng giáo vụ (Có ghi số cũng nhƣ không ghi số) là khoảng 3500.
+ Ít nhất mỗi “công văn” phải đƣợc ký “tƣơi” thành 02 bản để gửi đi và