Xây dựng phân hệ Setup trong hệ thống an ninh dựa trên sinh trắc học BioPKI - OpenCA

ng ở những miền con có những yêu cầu khác nhau đối với người ở miền khác. - Có thể không có tổ chức nào tình nguyện vận hành CA đơn hoặc một số tổ chức lại có thể không tin tưởng vào những người vận hành CA này vì một vài lý do nào đó. - 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. - 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.4.2 Mô hình phân cấp Mô hình này tương ứng với cấu trúc phân cấp với CA gốc và các CA cấp dưới. 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. Hình 2.9: Mô hình phân cấp Mô hình phân cấp được minh hoạ như Hình 2.9 ở trên. Trong mô hình này, mỗi thực thể sẽ giữ bản sao khoá công khai của root CA và kiểm tra đường dẫn của chứng thư bắt đầu từ chữ ký của CA gốc. Đây là mô hình PKI tin cậy sớm nhất và được sử dụng trong PEM. * Ưu điểm của mô hình: - Mô hình này có thể dùng được trực tiếp cho những doanh nghiệp phân cấp và độc lập, cũng như những tổ chức chính phủ và quân đội. - Cho phép thực thi chính sách và chuẩn thông qua hạ tầng cơ sở. - Dễ vận hành giữa các tổ chức khác nhau. * Nhược điểm: - Có thể không thích hợp đối với môi trường mà mỗi miền khác nhau cần có chính sách và giải pháp PKI khác nhau. - Các tổ chức có thể không tự nguyện tin vào các tổ chức khác. - Có thể không thích hợp cho những mối quan hệ ngang hàng giữa chính phủ và doanh nghiệp. - 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. - Có thể gây ra sự trội hơn của sản phẩm đối với vấn đề về khả năng tương tác. - 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 khoá cá nhân của CA bị xâm phạm, khoá 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. Mặc dù có những nhược điểm, song mô hình này vẫn thích hợp với yêu cầu của các tổ chức chính phủ vì cấu trúc phân cấp tự nhiên sẵn có. 2.4.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. Trong cấu hình mắt lưới đầy đủ, tất cả các CA gốc xác nhận chéo lẫn nhau. Điều này yêu cầu n2 lần xác thực trong hạ tầng cơ sở. Hình 2.10 là minh hoạ biểu diễn bằng đồ thị mô hình này. Hình 2.10: Mô hình mắt lưới *Ưu điểm của mô hình: - Linh hoạt hơn và phù hợp với nhu cầu giao dịch hiện nay. - 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. - Cho phép cạnh tranh. - Không phải là mô hình phân cấp và 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ược điểm: - Phức tạp và khó để quản lý vì việc xác thực chéo. - Khó có khả năng thực hiện và có thể không hoạt động vì những lý do do giao tác. - Phần mềm người sử dụng có thể gặp phải một số vấn đề khi tìm chuỗi chứng thư. - Để tìm chuỗi chứng thư và CRLs với những mô hình khác thì việc sử dụng thư mục có thể trở nên khó hơn. Hiện nay, các tổ chức chính phủ và công ty đang thiết lập CA riêng theo yêu cầu PKI của mình. Khi có yêu cầu xử lý giao tiếp giữa các tổ chức khác nhau, những CA này sẽ tiến hành xác thực chéo độc lập với nhau dẫn đến sự phát triển của thế giới Internet sẽ diễn ra trong mô hình tin cậy theo các hướng khác nhau. 2.4.4 Mô hình Hub và Spoke (Bridge CA) 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.11. Hình 2.11: Mô hình Hub và Spoke (Bridge CA) 2.4.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. 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 thư. - 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.4.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 thư. 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 3 PHƯƠNG ÁN THIẾT KẾ XÂY DỰNG HỆ THỐNG BK-BIOPKI-OPENCA TRONG KHUÔN KHỔ ĐỀ TÀI KC.01.11 3.1 Giới thiệu 3.1.1 Đề tài KC.01.11 Hệ thống BK-BioPKI-OpenCA được xây dựng và phát triển trong khuôn khổ đề tài nghiên cứu khoa học công nghệ cấp nhà nước KC01.11/06-10 “Hệ thống an ninh thông tin dựa trên sinh trắc học sử dụng công nghệ nhúng BioPKI” của khoa CNTT nhằm nghiên cứu và thử nghiệm một số giải pháp tích hợp sinh trắc học vào hạ tầng cơ sở khóa công khai PKI. 3.1.2 Sinh trắc học a. Sinh trắc học là gì Sinh trắc (Biometric) là đặc tính hay thuộc tính vật lý hay sinh học mà có thể định lượng được [11]. Nó có thể được dùng là phương tiện chứng minh định danh của người dùng. Một vài đặc tính sinh trắc học như: chiều cao, cân nặng, mùi cơ thể, vân tay, mống mắt, khuôn mặt, hình dạnh bàn tay hay ngón tay, giọng nói, chữ kí… Hình 3.1: Các thuộc tính sinh trắc học khác nhau Các thuộc tính sinh trắc được phân loại thành các tập nhỏ hơn và không phải tất cả các thuộc tính này đều phù hợp cho mục đích nhận dạng, thẩm định. Các tiêu chuẩn để đánh giá một thuộc tính sinh trắc có thể đuợc sử dụng cho mục đích này hay không như sau [11]: Tính phổ dụng (Universality): Tất cả mọi người đều phải có đặc tính sinh trắc học này: như khuôn mặt, mống mắt, vân tay… Tính duy nhất (Uniqueness): Đặc trưng sinh trắc học này của từng người phải khác nhau và là duy nhất. Tính bền vững (Permanence): Những đặc trưng sinh trắc học phải khá ổn định trong suốt cuộc đời của con người. Tính khả dụng (Collectability): Đặc trưng sinh trắc học này phải được thu thập một cách dễ dàng và khá nhanh chóng cho mục đích nhận dạng. Tính hiệu quả (Performance): Mức độ chính xác phải khá cao sao cho các hệ thống có thể được triển khai tin cậy trong thực tế. Tính chấp nhận được (Acceptability): Các ứng dụng sinh trắc học sẽ không thể được triển khai trong thực tế nếu nó nhận được sự phản đối lâu dài và mạnh mẽ của con người. Tính an toàn (Resistance to Circumvention): Hệ thống có dễ dàng bị giả mạo hay không. Biomertric Phổ dụng Duy nhất Bền vững Khả dụng Hiệu quả Chấp nhận Bị giả mạo Face H L M H L H L Fingerprint M H H M H M H Hand geometry M M M H M M M Keystrokes L L L M L M M Hand veins M M M M M M H Iris H H H M H L H Retinal scan H H M L H L H Signature L L L H L H L Voice M L L M L H L Facial thermograph H H L H M H H Odor H H H L L M L DNA H H H L H L L Gait M L L H L H M Ear Canal M M H M M H M Hình 3.2: Bảng so sánh các đặc trưng sinh trắc học theo A. K. Jain [11] (H - cao, M - trung bình, L - thấp) b. Các giải pháp tích hợp sinh trắc để bảo vệ khoá cá nhân Vấn đề bảo vệ khóa cá nhân luôn được chú trọng vì khóa cá nhân đóng vai trò bảo mật trung tâm cho toàn bộ hoạt động khác. Nếu khóa cá nhân của người dùng bị mất trộm thì đương nhiên những tài liệu mật gửi cho anh ta sẽ không còn an toàn. Trong trường hợp khóa cá nhân của một CA bị mất thì toàn bộ các CA và người dùng cấp dưới của nó sẽ không đảm bảo độ tin cậy, vì người lấy được khóa cá nhân đó có thể cấp chứng thư số cho bất kỳ một CA hay người dùng giả mạo nào đó nhân danh CA này. Nếu CA gốc bị mất khóa cá nhân thì toàn bộ hệ thống PKI trở nên vô nghĩa và sụp đổ. Có thể thấy, vấn đề bảo vệ khóa cá nhân mang ý nghĩa rất lớn. Vấn đề xác thực và thẩm định chủ thể, điểm yếu của PKI, lại là điểm mạnh của sinh trắc học. Do đó xu thế kết hợp sinh trắc học với PKI thành BioPKI là xu thế tất yếu. Hệ thống BioPKI được xây dựng sẽ đảm bảo định danh chính xác người dùng, bảo vệ an toàn tuyệt đối khóa cá nhân, đồng thời mang lại sự tiện lợi cho người sử dụng. Sau đây ta sẽ trình bày về các hướng tiếp cận của hệ thống sinh trắc học vào PKI để tạo nên một hệ thống có tính an toàn cao, hệ thống BioPKI [12]. Hướng dùng sinh trắc để thẩm định người dùng Theo hướng này, người dùng mỗi khi sử dụng hệ thống PKI cần gửi kèm theo thông tin sinh trắc học để chứng minh bản thân. Nói cách khác, thông tin sinh trắc học đó chính là một dạng chứng nhận kèm theo chứng thư số anh ta được cấp. Hoạt động của hướng này có thể hình dung như sau: Alice muốn yêu cầu một chứng thư số tại CA. Trước hết, Alice phải có mẫu sinh trắc học lưu tại cơ sở dữ liệu trong hệ thống. Khi đăng ký chứng thư số, ngoài các thông tin thông thường Alice còn phải gửi kèm theo thông tin sinh trắc học của mình. Ngoài các thủ tục xác minh thông thường, hệ thống còn thực hiện thêm việc đối sánh thông tin sinh trắc học kèm theo đó với mẫu đã lưu. Alice chỉ được cấp chứng thư khi kết quả đối sánh là khẳng định. Một tình huống khác: Bob đang dùng khóa cá nhân B, hệ thống muốn kiểm tra tính hợp lệ, xem Bob có đúng là chủ của khóa cá nhân đó không. Lúc đó, hệ thống sẽ yêu cầu Bob gửi thông tin sinh trắc học đến để đối sánh với mẫu của chủ khóa cá nhân B đã lưu trong cơ sở dữ liệu. Kết quả đối sánh đúng hoặc sai sẽ quyết định Bob có quyền được sử dụng tiếp không hay phải dừng lại. Hướng này làm tăng tính tin cậy của hệ thống khá nhiều, nhưng lại vấp phải một số nhược điểm sau [12]: Mẫu sinh trắc học được lưu trữ tập trung, do vậy đặt ra vấn đề bảo đảm an toàn cho máy chủ lưu trữ. Thực hiện đối sánh sinh trắc học và quyết định quyền sử dụng dịch vụ là hai công việc tách rời nhau. Kết quả của đối sánh sinh trắc được gửi qua môi trường truyền thông, do vậy có nảy sinh nguy cơ bị tấn công vào kênh truyền thông nhằm làm sai lệch kết quả trả lời. Đặc trưng sinh trắc học được gửi từ người dùng tới máy chủ để đối sánh nên có thể bị mất trộm và dẫn đến tấn công giả mạo. Hướng dùng sinh trắc để sinh khóa cá nhân Theo hướng này, khóa cá nhân được sinh trực tiếp dựa trên đặc trưng sinh trắc học và được dùng để ký các dữ liệu. Ưu điểm lớn nhất của giải pháp này là nó không cần nơi để lưu trữ, do vậy loại bỏ nguy cơ tấn công khóa cá nhân. Mặt khác, hệ thống rất thuận tiện khi bản thân người dùng đã “mang” theo khóa cá nhân để sử dụng ở bất kỳ đâu, không cần thiết phải có đĩa lưu trữ hoặc smartcard. Khóa công khai sẽ được sinh tương ứng với khóa cá nhân này theo thuật toán DSA. Trong trường hợp người dùng có nhu cầu có nhiều khóa cá nhân để dùng trong các hệ thống khác nhau, ta sẽ dùng các hàm băm khác nhau để băm khóa cá nhân. Do tính chất của các hàm băm, mỗi giá trị băm ra có thể được coi là một khóa cá nhân mới để dùng cho các hệ thống khác. Giải pháp này gồm hai pha: Thu nhận mẫu đặc trưng sinh học có độ ổn định cao Sinh khóa cá nhân từ mẫu này. Khó khăn chính của quá trình này là sự đảm bảo tuyệt đối duy nhất của khóa từ mẫu sinh trắc học, trong khi mẫu này thường có đặc tính thiếu ổn định, có sai số. Chính vì nhược điểm này mà giải pháp này mặc dù rất tốt về mặt lý thuyết nhưng lại rất khó thực hiện được trong thực tế. Vì vậy phương pháp này vẫn chưa được triển khai trong thực tế. Hướng sinh khóa sinh trắc mã hóa bảo vệ khóa cá nhân Theo hướng này, khóa cá nhân sẽ được bảo vệ bởi khóa mã sinh ra từ mẫu sinh trắc học. Người dùng sẽ được lấy mẫu sinh trắc học, từ mẫu sinh trắc học này, hệ thống tạo ra một tập khóa mã, các khóa mã này sẽ được dùng để mã hóa khóa cá nhân, tập khóa cá nhân được mã hóa bởi các khóa mã khác nhau sẽ được lưu lại (trên Smartcard hay trong CSDL tập trung). Và, tập khóa mã cũng như khóa cá nhân sẽ được xóa bỏ sau quá trình mã hóa này, như vậy, ở giải pháp này, rõ ràng đã tránh được nhược điểm sợ mất cắp khóa cá nhân cũng như mất cắp các thông tin về đặc điểm người dùng (đặc trưng sinh trắc học). Khi người dùng muốn lấy khóa cá nhân, họ cũng sẽ phải cung cấp mẫu sinh trắc học và hệ thống cũng tạo ra tập khóa mã từ mẫu sinh trắc học đó, hệ thống sẽ lần lượt thử các khóa mã xem có giải mã được các khóa cá nhân đã được mã hóa. Nếu có khóa mã giải mã thành công, thì khóa cá nhân sẽ được lấy ra cho người dùng. Hệ thống BK-BioPKI-OpenCA sẽ tích hợp sinh trắc theo hai hướng đó là hướng dùng sinh trắc để thẩm định người dùng và hướng sinh khóa sinh trắc mã hóa bảo vệ khóa cá nhân. 3.1.3 Tổng quan về hệ thống OpenCA 3.1.3.1 Giới thiệu OpenCA là một hệ thống mã nguồn mở, được xây dựng và phát triển bởi rất nhiều nhà lập trình trên thế giới. OpenCA được xây dựng với mục đích tạo ra một hệ thống công cụ nhằm hỗ trợ cho các dự án về bảo mật.OpenCA hỗ trợ từ mức độ thấp như mã hoá dữ liệu,tạo chữ ký số cho đến các hệ thống an toàn dữ liệu cao cấp. Mã nguồn của OpenCA được cung cấp rộng rãi trên www.openca.org. Từ những đặc điểm như trên có thể thấy OpenCA chính là một công cụ rất hiệu quả để xây dựng những ứng dụng theo mô hình hạ tầng khoá công khai PKI. OpenCA hỗ trợ xây dựng tất cả các thủ tục lõi cho một ứng dụng PKI từ việc sinh khoá mã hoá giải mã dữ liệu cho tới các thủ tục cấp phát,thu hồi chứng thư,tạo chữ ký số…Với tất cả những cái đó,ta có thể xây dựng một ứng dụng theo mô hình PKI cơ sở, phần mở rộng còn lại sẽ được xây dựng tiếp theo định hướng của nhà phát triển. Các thành phần chính của OpenCA bao gồm 3 thành phần là hệ thống thư viện OpenSSL, cơ sở dữ liệu và giao diện web. Trong đó giao diện web được xây dựng bằng ngôn ngữ Perl. Thư viện OpenSSL thực hiện các tiến trình về mã hoá. [14] Hình 3.3: Các thành phần của hệ thống OpenCA 3.1.3.2 Đánh giá về hệ OpenCA a. Ưu điểm của hệ thống OpenCA được thiết kế và xây dựng theo nguyên lý của mô hình PKI và nó đảm bảo đầy đủ những chức năng cơ sở của một hệ PKI cần phải có: Cấp phát, gia hạn, thu hồi chứng thư số, đảm bảo tính xác thực, an toàn tin cậy. Với các kịch bản đã thử nghiệm trong thời gian dài hệ thống đã hoạt động khá ổn định và không xảy ra những lỗi nghiêm trọng dẫn đến từ chối dịch vụ. Hệ mã nguồn mở OpenCA hoàn toàn tương thích với môi trường Linux và không hề gây xung đột với các hệ thống khác cùng cài đặt trên một hệ điều hành. Hệ thống OpenCA sử dụng rất nhiều chuẩn công nghiệp( như các chuẩn về chứng thư số X509). Vì vậy nó được chấp nhận và sử dụng rất rộng rãi trong thực tế. b. Những điểm còn hạn chế của hệ thống Lỗi không xác định khi RA ký lên các yêu cầu gửi lên cho CA. Không làm việc được với các thiết bị sử dụng chuẩn USB 2.0 Khó khăn trong việc cài đặt và thay đổi 3.1.4 Mục đích của hệ thống BK BioPKI-OpenCA Như đã nói ở trên, hệ BK BioPKI-OpenCA đúng như cái tên của nó, được xây dựng với tiêu chí là tích hợp sinh trắc vào mô hình PKI xử dụng các chuẩn chứng thư số của hệ thống OpenCA cung cấp. Hệ thống là sự kết hợp giữa 3 yếu tố là sinh trắc, mô hình PKI và hệ thống OpenCA. Mỗi thành phần của hệ thống đều có những ưu điểm và nhược điểm, và các thành phần còn lại có khả năng bổ xung cho các nhược điểm đó. Điểm yếu của PKI là nguy cơ bị sâm hại khoá cá nhân, nhưng khi được tích hợp sinh trắc để bảo vệ thì hệ thống đã trở nên an toàn hơn rất nhiều. OpenCA cúa ưu điểm là nó được chấp nhận và sử dụng rất rộng rãi trên toàn thế giới, nhưng có nhược điểm là khó cài đặt và thay đổi, không có khả năng giao tiếp với các thiết bị nhúng sử dụng chuẩn USB 2.0. Khả năng tích hợp sinh trắc trực tiếp vào hệ thống OpenCA như nhóm đề tài đã nghiên cứu là không có. Nhưng khi có một hệ thống PKI xây dựng mới,có khả năng tích hợp sinh trắc đồng thời sử dụng những chứng thư số theo chuẩn của OpenCA thì vấn đề này có thể được giải quyết hoàn toàn, đảm bảo tính an toàn, tin cậy và khả năng triển khai thực tế. Chính vì thế nhóm làm đề tài quyết định triển khai xây dựng hệ thống BK-BioPKI-OpenCA. 3.2 Thư viện OpenSSL Hệ thống được phát triển kế thừa dựa trên hệ thống BK-BioPKI đã được xây dưng và thử nghiệm trên phòng thí nghiệm. Môi trường phát triển : hệ thống được viết trên môi trường VC++ 2005, cơ sở dữ liệu MySQL sử dụng các hàm C API, hệ thống thư viện OpenSSL. Hệ thống OpenCA được cài đặt trên máy chủ Linux chạy hệ điều hành Fedora 6. Khái quát chung về OpenSSL Dự án OpenSSL là một kết quả của sự cộng tác nhằm phát triển một kỹ thuật bảo mật dạng thương mại, đầy đủ các đặc trưng và là bộ công cụ mã nguồn mở thực thi các giao thức như Secure Sockets Layer (SSL v2/v3) và Transport Layer Security (TSL v1) với những thuật toán mã hóa phức tạp. Dự án được quản lý bởi hiệp hội những người tình nguyện trên thế giới, sử dụng Internet để trao đổi thông tin, lập kế hoạch và phát triển công cụ OpenSSL và các tài liệu liên quan khác.[13] SSL là giao thức đa mục đích được thiết kế để tạo ra các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước (socket 443) nhằm mã hoá toàn bộ thông tin đi/đến, mà ngày nay được sử dụng rộng rãi cho giao dịch điện tử như truyền số hiệu thẻ tín dụng, mật khẩu, số bí mật cá nhân (PIN) trên Internet. [13] Ngày nay giao thức Secure Socket Layer (SSL) đã được sử dụng rộng rãi trên World Wide Web trong việc xác thực và mã hoá thông tin giữa client và server. Tổ chức IETF (Internet Engineering Task Force ) đã chuẩn hoá SSL và đặt lại tên là TLS (Transport Layer Security). Mặc dù là có sự thay đổi về tên nhưng TSL chỉ là một phiên bản mới của SSL. Phiên bản TSL 1.0 tương đương với phiên bản SSL 3.1. Tuy nhiên SSL là thuật ngữ được sử dụng rộng rãi hơn. Tính mở của thư viện OpenSSL cho phép can thiệp tới quá trình tạo và quản lý chứng thư số, phù hợp với yêu cầu của đề tài. Do vậy đề tài lựa chọn xây dựng một hệ thống PKI trên nền tảng thư viện OpenSSL. OpenSSL là thư viện cho lập trình với ngôn ngữ C và có thể cài đặt trên nhiều môi trường thực hiện C khác nhau như Microsoft Visual C++. Borland C++ Builder… OpenSSL có thể được sử dụng trên nhiều hệ điều hành khác nhau từ các hệ thống UNIX đến Window. Cài đặt thư viện OpenSSL Để cài đặt thư viện OpenSSL trên hệ điều hành Window trước hết cần download phiên bản của thư viện này dành cho Window tại địa chỉ: Sau đó, chạy file install để cài đặt (giả sử vào thư mục C:\Openssl). Để sử dụng thư viện này với Microsoft Visual C++ cần làm các bước sau: Copy tất cả các file trong thư mục 'C:\OpenSSL\lib\VC' vào thư mục Visual C++ 'lib'. Thư mục này đôi khi được đăt ở địa chỉ 'C:\Program Files\Microsoft Visual Studio 8\VC\lib' or 'C:\Program Files\Microsoft Visual C++\lib'. Tiếp theo, copy tất cả trong thư mục 'C:\OpenSSL\include' tới thư mục Visual C++ 'include'. Quá trình cài đặt hoàn tất và có thể bắt đầu lập trình với thư viện OPENSSL. Thành phần của bộ thư viện OpenSSL bao gồm[13]: Thư viện về mã hóa: hầu hết các thuật toán phổ biến về mã hóa đối xứng, mã hóa công khai, hàm băm .. đều được hiện thực trên thư viện này. Thư viện có chức năng sinh số ngẫu nhiên lớn, và hỗ trợ nhiều định dang lưu trữ và quản lý khóa, chứng thư số. Ngoài ra, OpenSSL cho phép tích hợp với các bộ phần cứng tăng tốc mã hóa phổ biến trong phiên bản mới nhất là 0.9.8. Thư viện về giao thức SSL: tất cả các phiên bản của giao thức SSL đều được hỗ trợ, bao gồm cả giao thức mới nhất là TLS v1. Lập trình sử dụng OpenSSL Để sử dụng thư viện OpenSSL, cần cho các file khai báo đặc tả (file .h) sau vào file mã nguồn: #include #include #include #include #include #include Ngoài ra cần thêm file applink.c là file liên kết module khi biên dịch chương trình. File này chỉ sử dụng cho các phiên bản thư viện 0.9.8 trở về sau. Khi liên kết (link), cần đặt thông số cho thư viện cần thêm là libeay32.lib và ssleay32.lib. Khởi tạo thư viện Thư viện cần được khởi tạo trước khi sử dụng, bao gồm: Khởi tạo thông số cho sử dụng các hàm mã hóa và băm OpenSSL_add_all_algorithms(); OpenSSL_add_all_digests(); Khởi tạo quản lý bộ nhớ, nạp các hàm quản lý lỗi. CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON); CRYPTO_malloc_init(); ERR_load_crypto_strings(); Khởi tạo sử dụng thư viện SSL SSL_library_init(); SSL_load_error_strings(); Sử dụng Tập các hàm API của OpenSSL chia ra theo nhóm chức năng, mỗi nhóm chức năng bắt đầu tên hàm bằng một tiền tố. Ví dụ, các hàm về thư viện X.509 luôn có tên bắt đầu là X509_, các hàm giao tiếp vào ra có tiền tố của tên BIO_, các hàm mã hóa là EVP_, các hàm giao thức SSL là SSL_. Sử dụng các hàm mã hóa Quá trình thực hiện mã hóa như sau Tạo context chứa thông tin về mã hóa: lưu trong con trỏ kiểu EVP_CIPHER_CTX: EVP_CIPHER_CTX *x = NULL; x = (EVP_CIPHER_CTX*) malloc(sizeof(EVP_CIPHER_CTX)); EVP_CIPHER_CTX_init(x); Chỉ định thuật toán, khóa mã cho quá trình mã hóa/giải mã: dùng một trong các hàm sau: int EVP_EncryptInit(EVP_CIPHER_CTX *ctx,const EVP_CIPHER *type, unsigned char *key, unsigned char *iv); int EVP_DecryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type, unsigned char *key, unsigned char *iv); Thêm dữ liệu cần mã hóa: int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int*outl, unsigned char *in, int inl); Lấy ra dữ liệu đã mã hóa: int EVP_EncryptFinal(EVP_CIPHER_CTX *ctx, unsigned char *out, int*outl); Sử dụng giao thức SSL Tạo context cấu hình kết nối SSL: dùng các hàm SSL_CTX_ Tạo một kết nối vào ra thông thường: theo giao thức TCP/IP bằng các hàm BIO_: BIO_new_connect, BIO_do_connect… Tạo một socket SSL: dựa trên kết nối BIO và context cấu hình SSL: SSL_new, SSL_set_bio, SSL_connect… Đọc ghi dữ liệu qua socket SSL: bằng các hàm SSL_read, SSL_write. Đóng kết nối SSL và giải phóng context: SSL_close, SSL_CTX_free. Sử dụng thư viện X.509 Yêu cầu chứng thư số thể hiện bằng đối tượng X509_REQ. Trong đối tượng này bao gồm tên định danh của người đăng ký, được thể hiện bằng X509_NAME. Thành phần mở rộng của yêu cầu chứng thư là X509_EXTENSION. Các hàm của X.509 chia theo chức năng: X509_NAME_*: thao tác với đối tượng X509_NAME X509_PKEY* và X509_PUBKEY*: thao tác với khóa công khai/cá nhân. X509_REQ*: thao tác với yêu cầu chứng thư số. X509_CRL*: thao tác với danh sách CRL. X509_REVOKED*: thao tác với một chứng thư số bị hủy nằm trong danh sách CRL. Ngoài ra còn một số hàm khác. Các bước tạo yêu cầu chứng thư như sau: Tạo đối tượng tên định danh X509_NAME Tạo cặp khóa công khai/cá nhân, cho khóa công khai vào yêu cầu chứng thư số. Thêm các thành phần mở rộng nếu cần. Thực hiện ký chứng thực nội dung yêu cầu chứng thư. CA phát hành chứng thư số từ yêu cầu chứng thư: Lấy thông tin X509_NAME trong yêu cầu chứng thư và gán cho trường Subject của chứng thư số. Lấy thông tin X509_NAME trong chứng thư số gốc của CA và gán cho trường Issuer của chứng thư số. Dùng khóa công khai trong yêu cầu chứng thư số và kiểm tra chữ ký. Lấy khóa công khai cho vào chứng thư số. Thêm các thành phần mở rộng nếu cần Thực hiện ký chứng thư bằng khóa cá nhân của CA. Thư viện OpenSSL đang trong quá trình phát triển, tài liệu thư viện được liệt kê tại 3.3 Phương án thiết kế xây dựng hệ thống BK-BioPKI-OpenCA[15] 3.3.1 Mô hình hệ thống dự kiến Hình 3.4: Mô hình hệ thống BioPKI-OpenCA mức khung cảnh 3.3.2 Các thành phần và chức năng của hệ thống a. CA CA là nơi phát hành chứng thư (còn gọi là chứng thư số theo thuật ngữ bản pháp lý) CA gồm hai bộ phận: CA Operator (máy người điều hành CA) và OpenCA. CA Operator: Là một máy Window kết nối với máy chủ Linux-OpenCA, CA Operator là công cụ quản trị của người điều hành CA. Cung cấp ứng dụng cho phép người điều hành CA nhập thông tin yêu cầu vào cơ sở dữ liệu của OpenCA. Cung cấp ứng dụng để sản xuất ra thiết bị nhúng giao tiếp với PC qua cổng USB (gọi là Etoken). Thiết bị nhúng Etoken sẽ chứa chứng thư, khóa riêng, đặc trưng vân tay của người đăng ký. (thiết bị nhúng này có vai trò như thẻ giao dịch điên tử( OpenCA; Là một máy chủ Linux, Quản lý yêu cầu, quản lý và phát hành chứng thư. Cung cấp một giao diện web cho phép người điều hành CA quản trị được các yêu cầu từ đó phát hành chứng thư. b RA RA bao gồm 2 bộ phận: bộ phận phát hành chứng thư và bộ phận cung cấp các dịch vụ cho phép người dùng sử dụng chứng thư đối với các ứng dụng cụ thể. Bộ phận dịch vụ phát hành chứng thư : Cung cấp các dịch vụ về chứng thư Phát hành thiết bị nhúng Etoken chứa chứng thư (Phát hành chứng thư ) xử lý mất thiết bị nhúng Etoken (hủy chứng thư theo yêu cầu) xử lý cấp thiết bị nhúng Etoken (cấp mới chứng thư). Bộ phận dịch vụ chứng thư cung cấp các dịch vụ để sử dụng chứng thư tương ứng với từng ứng dụng cụ thể như chữ ký số, mã hóa thông điệp… Ví dụ: Dịch vụ xác thực chứng thư: kiểm tra thông tin, tính hợp lệ của chứng thư. Dịch vụ cung cấp chứng thư theo serial number… c. LRA LRA là nơi giao tiếp trực tiếp với người dùng các vấn đề về cấp thiết bị nhúng Etoken Phát hành thiết bị nhúng Etoken (chứng thư) mới: nơi tiếp nhận yêu cầu, mẫu sinh trắc, đồng thời là nơi trả thẻ cho khách hàng. Xử lý mất thiết bị nhúng Etoken (chứng thư): nơi khách hàng đến để yêu cầu hủy chứng thư trong trường hợp mất thẻ. Cấp mới thiết bị nhúng Etoken (chứng thư). c. User Application User Application là một ứng dụng cho phép người dùng truy cập đến trung tâm dịch vụ chứng thư của RA để sử dụng chứng thư của mình vào một số ứng dụng như chữ ký sô, mã hóa thông điệp… 3.3.3 Biểu đồ phân cấp chức năng Dựa vào các phân tích về yêu cầu và quy trình ở trên, ta có các biểu đồ phân rã chức năng cho từng khối thành phần hệ thống như sau: a. Biểu đồ phân cấp chức năng của CA Operator CA-Operator sẽ có các chức năng chính như biểu đồ dưới đây: Hình 3.5: Biểu đồ phân cấp chức năng của CA Operator Giao dịch với RA: Cấp chứng thư số mới: Nhận request từ RA, cấp chứng thư, ghi chứng thư và thẻ rồi trả lại cho RA Hủy chứng thư số: Nhận yêu cầu từ RA, đánh dấu hủy và cập nhật vào CSDL, trả lời lại cho RA Cấp lại chứng thư số: Hủy chứng thư số cũ, cấp lại chứng thư mới Giao tiếp với CA: Cấp mới chứng thư số: submit request lên CA, thông qua giao diện web của OpenCA issue chứng thư, lấy chứng thư từ CSDL của CA, ghi ra file và trả lại cho RA Hủy chứng thư số: Cập nhật vào CSDL hủy bỏ chứng thư số nào đó Cấp lại chứng thư số: trước tiên là hủy chứng thư cũ, rồi cấp lại một chứng thư mới Ghi Token: Nhận đặc trưng sinh trắc của người dùng do RA gửi lên, mã hóa với khóa cá nhân rồi ghi ra thiết bị nhúng (Token), trả token cùng với chứng thư cho RA b. Biểu đồ phân rã chức năng của RA RA sẽ có các chức năng chính như biểu đồ dưới đây: Hình 3.6: Biểu đồ phân cấp chức năng của RA Giao tiếp với LRA: Cấp chứng thư số mới: Nhận thông tin đăng kí xin cấp chứng thư số mới do LRA gửi lên, trả thẻ lại cho LRA để phát cho người dùng Hủy chứng thư số: Nhận yêu cầu hủy chứng thư số của một user từ LRA, kiểm tra thông tin user, chứng thư, token có đúng hay không, đánh dấu hủy chứng thư trong CSDL, trả lời lại cho LRA để thông báo kết quả đến người dùng Cấp lại chứng thư số: hủy chứng thư số cũ, cấp lại chứng thư mới Giao tiếp với CA Operator: Cấp chứng thư số mới: gửi thông tin xin cấp chứng thư lên cho CA Operator, nhận thẻ và chứng thư để trả lại cho LRA Hủy chứng thư số: tạo yêu cầu hủy chứng thư số, gửi lên cho CA Operator và nhận lại kết quả hủy từ CA Operator Cấp lại chứng thư số: bao gồm 2 thao tác hủy chứng thư cũ, cấp lại chứng thư mới Setup: Kết nối với LRA: kết nối, send test message để chứng tỏ thông với LRA Kết nối với CA Operator: offline, cần kí lên các thông tin gửi cho CA Operator và xác thực các thông tin nhận được từ CA Operator Kết nối với ứng dụng: Mở cổng cho các ứng dụng truy cập và sử dụng các dịch vụ chứng thư số Cung cấp dịch vụ sử dụng chứng thư số: Xác thực chứng thư số: Kiểm tra xem chứng thư đó có đúng của hệ thống và còn hiệu lực hay không Download chứng thư số: cho phép các ứng dụng download các chứng thư số của người dùng để thực hiện giao dịch điện tử c. Biểu đồ phân cấp chức năng của LRA LRA sẽ có các chức năng chính như biểu đồ dưới đây: Hình 3.7: Biểu đồ phân cấp chức năng của LRA Giao tiếp với người dùng: Cấp chứng thư mới: nhận thông tin đăng kí (bao gồm cả thông tin user nếu chưa là user của hệ thống), trả thẻ lại cho ngươid dùng nếu yêu cầu được chấp nhận và cấp chứng thư Hủy chứng thư số: Nhận yêu cầu hủy từ User, thông báo lại kết quả việc hủy Cấp lại chứng thư số: gồm 2 thao tác: hủy chứng thư cũ và cấp lại chứng thư mới Giao tiếp với RA: Cấp mới chứng thư: Gửi yêu cầu xin cấp mới chứng thư từ người dùng lên cho RA, nhận thẻ được trả về và phát lại cho user Hủy chứng thư số: Gửi yêu cầu hủy chứng thư số của user và nhanh kết quả việc hủy, thông báo lại cho user Cấp mới chứng thư Setup hệ thống: Xác thực chứng thư, kết nối đến RA để tiến hành các giao dịch 3.3.4 Xây dựng phương án về quy trình hệ thống BK-BioPKI-OpenCA a. Cấp phát chứng thư (1). Người dùng muốn có 1 chứng thư để sử dụng đến chi nhánh đăng ký chứng thư (LRA), điền thông tin vào mẫu đơn đăng ký xin cấp chứng thư (xem mẫu) nộp cho nhân viên chi nhánh. Các thông tin bao gồm: Họ và tên Giới tính Ngày sinh Nơi sinh Quốc tịch Số CMND/Hộ chiếu Ngày cấp Nơi cấp Địa chỉ thường trú Nơi công tác Điện thoại Fax Điện thoại di động (*) Email (*) Chức vụ Thời hạn đề nghị cấp (tối đa là 05 năm tính từ ngày cấp chứng thư số) (2). Nhân viên chi nhánh tiếp nhận đơn đăng ký, kiểm tra thông tin người dùng cung cấp. Nếu các thông tin chính xác, yêu cầu người dùng nhập mẫu sinh trắc đúng chuẩn. Mẫu sinh trắc được chuyển thành đặc trưng sinh trắc. Đặc trưng này được mã hóa với chứng thư chuyên dùng cho user của CA. (3). Lưu vào cơ sở dữ liệu quản lý thông tin sau: - Thông tin người dùng (cả đặc trưng sinh trắc đã mã hóa). - Ngày nhận đăng ký, ngày trả kết quả. - Sinh mã đăng ký: 3 ký tự đầu mã LRA, 6 ký tự sau phiên đăng ký (tự động tăng) - Lưu trạng thái yêu cầu: đã đăng ký. (4). Đưa giấy hẹn trả lời cho người dùng (có mã đăng ký). (5). LRA ký và gửi thông tin đăng ký xin cấp chứng thư cho RA: - Thông tin đăng ký. - Mã đăng ký. (6). RA nhận yêu cầu từ LRA, lọc lấy mã LRA, căn cứ vào mã LRA để kiểm tra chữ ký LRA, nếu kiểm tra thấy không đúng thông báo cho LRA , còn nếu đúng lưu vào cơ sơ dữ liệu: - Mã đăng ký. - Thông tin đăng ký - Trạng thái yêu cầu: đang xét duyệt tại RA. LRA nhận được trả lời từ RA thì cập nhật lại trạng thái yêu cầu (nếu cần) và hủy các thông tin sinh trắc của đăng ký tương ứng + Nếu trả lời chữ ký hợp lệ Đang chờ duyệt (7). RA duyệt yêu cầu, nếu không cấp nhận yêu cầu gửi thông báo không chấp nhận cho LRA, hủy đăng ký trong CSDL. Duyệt yêu cầu gồm: - Đã có chứng thư hay chưa… Nếu LRA nhận được thông báo không chấp nhận từ RA thì cập nhật trạng thái yêu cầu là Không hợp lệ (8). Nếu RA chấp nhận yêu cầu thì ký lên yêu cầu và gửi lên CA (kèm mã đăng ký), chuyển trạng thái yêu cầu thành đã gửi CA (offline). (9). CA operator kiểm chữ ký của RA trên dữ liệu đăng ký (sử dụng ứng dụng trên nền Windows). Nếu sai thì thông báo (offline), nếu đúng sử dụng application insert vào CSDL của CA. (10). CA phát hành chứng thư, - Ghi khóa riêng, chứng thư, đặc trưng sinh trắc vào thiết bị nhúng. - Chuyển thiết bị nhúng, chứng thư, và mã yêu cầu cho RA (11). RA nhận dữ liệu từ CA: - Insert chứng thư vào CSDL chứng thư của RA. - Căn cứ vào mã yêu cầu, update trạng thái yêu cầu: đã được cấp, điền mã thẻ vào yêu cầu tương ưng - Insert thông tin thiết bị nhúng vào CSDL: mã thiết bị, ID người dùng, serial number của chứng thư, trạng thái của thiết bị (delivered to LRA – false, delivered to User – false), mã yêu cầu tương ứng với thiết bị. (13). RA trả thiết bị nhúng cho LRA, mã yêu cầu, cập nhật lại trạng thái của thiết bị nhúng (Delivered to LRA – true.) (14). LRA nhận thiết bị nhúng từ RA kèm mã yêu cầu. Dựa vào mã yêu cầu, cập nhật trạng thái yêu cầu là đã có thẻ và điền mã thẻ vào yêu cầu tương ứng (15). Người đăng ký cầm giấy hẹn đến LRA để lấy chứng thư. LRA căn cứ vào mã đăng ký để lấy thiết bị nhúng trả cho người đăng ký và cập nhật trạng thái yêu cầu là đã trả thẻ. Đồng thời LRA thông báo cho RA người dùng đã nhận thẻ (kèm mã thẻ). (16). RA nhận được thông báo người đăng ký đã nhận thẻ. Dựa trên mã thẻ cập nhật lại trạng thái thẻ (Delivered to User – true.) b. Xử lý mất thiết bị nhúng Etoken (hủy chứng thư tức thời) (1). Người dùng đến LRA báo mất thẻ và yêu cầu hủy chứng thư. (2). LRA kiểm tra thông tin người dùng để xác minh nhân thân. (3). LRA gửi yêu cầu hủy chứng thư (chứa ID người dùng) cho RA (offline) và lưu yêu cầu vào cơ sở dữ liệu, trạng thái yêu cầu là đã gửi RA. (4). RA nhận yêu cầu từ LRA, lưu yêu cầu vào CSDL, căn cứ vào ID người dùng tìm các thẻ tương ứng và báo lại cho LRA (nếu cần). (5). Sau khi xác định chính xác mã thẻ cần hủy, dựa trên mã thẻ - Tìm serial number của chứng thư chứa trong thẻ. - Update trạng thái chứng thư: thu hồi. - Update trạng thái thẻ: đã hủy. - Thông báo lại cho LRA. (6). LRA nhận thông tin từ RA báo cho người dùng, update lại trạng thái yêu cầu đã xử lý. (7). Cuối ngày, RA tìm trong CSDL các yêu cầu hủy (chứa serial number của chứng thư) gửi cho CA. (8). CA nhận được thông tin từ RA, căn cứ vào các serial number để cập nhật lại trạng thái chứng thư. c. Sử dụng chứng thư (ứng dụng chữ ký số) (1). Quy trình ký - Đưa thiết bị nhúng vào ứng dụng (đã chứa đặc trưng sinh trắc) - User cung cấp số PIN để xác thực (1 lần) - Mỗi lần sử dụng, ứng dụng yêu cầu người dung cung cấp dấu hiệu sinh trắc - Thẩm định sinh trắc được thực hiện trên máy local : đọc dấu hiệu sinh trắc từ thiết bị nhúng, thẩm định dấu hiệu sinh trắc nhận được với dấu hiệu trong thiết bị nhúng - Nếu kết quả thẩm định tốt hiện giao diện cho phép sử dụng chứng thư (ký số) - Module ký số thực hiện (2). Quy trình xác thực chữ ký số: - Nhận dữ liệu đã được ký, SN của chứng thư - Tách chữ ký, SN của chứng thư - Gửi SN cho RA để lấy chứng thư của bên gửi - Xác thực chữ ký CHƯƠNG 4 PHÂN TÍCH THIẾT KẾ CÀI ĐẶT THÀNH PHẦN SETUP HỆ THỐNG BK-BIOPKI-OPENCA 4.1 Giới thiệu Hệ thống BK-BioPKI dựa trên OpenCA được thực hiện bởi nhóm sinh viên khoá 49, khoa công nghệ thông tin trường đại học Bách Khoa Hà Nội. Với sự phân công cụ thể như sau: Trần Anh Mỹ lớp TTM K49: Xây dựng thành phần CA Operator Nguyễn Thuý Hằng lớp TTM K49 : Xây dựng các thành phần RA Trần Hoàn Vũ lớp HTTT&TT KSCLC K49: Xây dựng module Setup hệ thống Nguyễn Đức Toàn lớpTTM K49: Xây dựng module giao tiếp giữa LRA và RA Nguyễn Văn Toàn lớp TTM K49: Xây dựng các thành phần của LRA và tích hợp sinh trắc vào hệ thống. Bùi Đức Khánh lớp TTM K49: Xây dựng các ứng dụng PKI như chữ ký số, mã hoá thông điệp. Đào Vũ Hiệp lớp TTM K49 và Nguyễn Tư Hoàn KSTN K49: Module sinh trắc học. Quyển đồ án này tập trung vào việc phân tích thiết kế cài đặt module setup hệ thống BioPKI OpenCA. 4.2 Phân tích yêu cầu Nhiệm vụ của đồ án là xây dựng module setup các thành phần của hệ thống cần phải hoàn thành những việc sau: Thiết lập RA Thiết lập LRA Thiết lập CA Operator Setup cho mỗi thành phần cần đảm bảo được những yêu cầu: Thiết lập cơ sở dữ liệu Thiết lập các thông tin xác thực Thiết lập cấu hình của hệ thống Thiết lập để tạo kênh SSL( Nếu có giao tiếp Online với thành phần khác) 4.3 Các chức năng cơ bản của Module Setup hệ thống Hình 4.1: Các chức năng của Module Setup Hệ Thống Setup CA Operator : Nhiệm vụ của Setup Operator là thiết lập các thông tin để kết nối với cơ sở dữ liệu của máy chủ OpenCA, thông tin về mật khẩu đăng nhập của CA Operator. Xác thực và thiết lập các thông tin chứng thư số của CA và các RA để phục vụ cho các quá trình cấp phát, thu hồi chứng thư sau này. Các chứng thư số được lưu trong cơ sở dữ liệu, các thông tin về cấu hình và đường dẫn hệ thống được lưu trong file XML. Setup RA: Setup RA thực hiện thiết lập các thông tin để kết nối với cơ sở dữ liệu RA, Các thông tin dùng cho việc đăng nhập của người quản trị RA. Thiết lập và xác thực các thông tin về chứng thư số của CA, CA Operator, RA và các LRA để phục vụ cho các quá trình giao dịch chứng thư số với CA Operator và các LRA, thiết lập kênh giao tiếp SSL cho RA Server. Setup LRA: Setup LRA tương tự như của RA, nhằm thiết lập kết nối cơ sở dữ liệu, nhập các chứng thư cần thiết để tạo kênh SSL cho LRA Client và xác thực trong các giao dịch. 4.4 Xây dựng kịch bản 4.4.1 Setup CA Operator Hình 4.2: Biểu đồ diễn tiến quá trình Setup CA Operator Kịch bản setup CAOperator (1) CAOperatorAdmin chọn setup CAOperator (2) CAOperatorAdmin được yêu cầu cung cấp các thông tin cấu hình cơ sở dữ liệu của OpenCA, thông tin về chứng thư số của CAOperator, chứng thư số của RA. (3) CAOperatorAdmin nhập các thông tin cần thiết (4) CAOperator tiến hành kiểm tra xác thực chứng thư và khóa cá nhân. (5) Nếu có lỗi, CAOperator yêu cầu người dùng nhập lại thông tin (6) Người dùng nhập lại các thông tin (7) CAOperator tiến hành kiểm tra kết nối tới cơ sở dữ liệu của OpenCA (8) Nếu kết nối thành công, thông báo thành công (9) CAOperator lưu lại các thông tin về cấu hình. 4.4.2 Setup RA Setup RA bao gồm 2 bước: Đăng ký 1 máy chủ RA với các thông tin đầu vào là: Thông tin kết nối đến cơ sở dữ liệu, thông tin đăng nhập, thông tin của RA Server, cặp khoá và chứng thư của RA Admin, chứng thư của CA và CA Operator. Đăng ký các máy LRA Client với đầu vào là chứng thư và mã LRA Hình là biểu đồ diễn tiến quá trình đăng ký RA Hình 4.3: Biểu đồ diễn tiến quá trình Setup RA (1) RA Admin chọn Setup RA (2) RASetup yêu cầu nhập thông tin cần thiết (3) RA Admin nhập thông tin (4) RA Setup xác thực thông tin: kiểm tra kết nối đến cơ sở dữ liệu, đọc khoá cá nhân của RA Admin (5) Nếu các thông tin chính xác, RASetup yêu cầu import chứng thư (6) RA Admin import chứng thư của CA, CA Operator, RA (7) RASetup xác thực các chứng thư đã nhập (8) Nếu xác nhận chứng thư thành công, lưu chứng thư vào cơ sở dữ liệu, khởi tạo SSL server (9) RAServer start để lắng nghe các Client (11) Server start thành công, RASetup lưu các thông tin cấu hình Sau khi đăng ký RA thành công, RA Admin chọn chức năng Register LRA để đăng ký các máy khách LRA sẽ giao dịch. Hình là biểu đồ diễn tiến quá trình đăng ký một LRA Client Hình 4.4: Biểu đồ diễn tiến quá trình đăng ký một LRA (1) RA Admin chọn đăng ký 1 LRA client (2) Register LRA yêu cầu nhập thông tin của LRA (3) RA Admin nhập mã và chứng thư của LRA cần đăng ký (4) Register LRA xác thực thông tin đăng ký (5) Nếu quá trình xác thực thành công lưu chứng thư và mã LRA tương ứng vào cơ sở dữ liệu 4.4.3 Setup LRA Hình 4.5: Biểu đồ diễn tiến quá trình setup LRA (1) LRA Admin chọn setup LRA (2 ) LRA Admin được yêu cầu cung cấp các thông tin cấu hình bao gồm: thông tin profile LRA, LRA code, thông tin CSDL, thông tin về RA chủ quản, các chứng thư (CA, RA, LRA), khóa cá nhân của LRA, mật khẩu đăng nhập của LRA Admin (có thể được thay thế bằng sinh trắc) (3) LRA Admin nhập các thông tin cần thiết (4) LRA Setup tiến hành kiểm tra, xác thực các chứng thư, khóa cá nhân (5) Nếu có lỗi xác thực, LRA Setup yêu cầu người dùng nhập lại (6) Người dùng nhập lại các thông tin chứng thư (7) LRA Setup thiết lập kênh SSL tới RA (8) RA trả lời kết nối đã được thiết lập (9) LRA Setup lưu các thông số cấu hình, import các chứng thư vào CSDL 4.4.4 Kịch bản khởi động Hình mô tả quá trình khởi động chung cho cả 3 thành phần CA Operator, RA và LRA. Việc chạy chương trình chính bắt đầu bằng quá trình đăng nhập hệ thống, hiện nay do chưa tích hợp sinh trắc nên việc đăng nhập mới chỉ dùng password, sau này khi đăng nhập chương trình có thêm một bước là kiểm tra đặc trưng sinh trắc của người dùng. Hình 4.6: Kịch bản khởi động cho các phân hệ trong hệ thống BioPKI CHƯƠNG 5 THỬ NGHIỆM KỊCH BẢN ỨNG DỤNG TRONG HỆ THỐNGBIOPKI-OPENCA Sau khi từng thành phần của hệ thống được xây dựng, ghép nối và chạy thử, cần thử nghiệm một kịch bản ứng dụng trong hệ thống BioPKI-OpenCA để kiểm tra, đánh giá hệ thống, xem xét các khối chương trình đã chạy đúng như yêu cầu hay chưa. Ứng dụng được thử nghiệm ở đây chính là kịch bản ứng dụng chữ kí số. Ứng dụng chữ kí số là một thành phần trong nhóm xây dựng các ứng dụng của hệ thống BioPKI-OpenCA. Hai chức năng chính hệ thống cung cấp liên quan tới ứng dụng này là chức năng kí và chức năng kiểm tra chữ kí. Trong phần dưới sẽ trình quá trình thử nghiệm kịch bản ứng dụng trong toàn bộ hệ thống BioPKI-OpenCA Ver.1, trong đó sẽ thử nghiệm và đánh giá kết quả của phân hệ phần mềm LRA của đồ án này trong hoạt động của hệ thống chung Hình 5.1: Biểu đồ usecase nhóm các chức năng liên quan tới ứng dụng trên nền PKI Trong phạm vi đề tài này, ứng dụng chữ kí số sẽ được xây dựng nhằm xác thực nội dung thông điệp và xác thực người dùng. Ứng dụng được xây dựng nằm thành phần user applications của hệ thống BioPKI-OpenCA. Mục tiêu của việc xác thực trong ứng dụng này là : Xác thực sự toàn vẹn thông điệp. Xác thực người kí thông điệp. Chống phủ nhận đối với người kí. 5.1 Thiết kế kịch bản thử nghiệm ứng dụng chữ kí số Hai người dùng của hệ thống tham gia vào một giao dịch thông điệp có sử dụng chữ kí số. Tạm gọi hai người đó là A và B. A gửi cho B thông điệp M ( là một file dữ liệu), A đồng thời dùng một chứng thư số của mình để tạo chữ kí số. Chính xác là A dùng khóa riêng PrA (ứng với chứng thư CertA của A đã được CA xác nhận) để kí lên M tạo thành chữ kí SA. Cả M, số Serial của CertA và SA được gắn lại và gửi cho B. Khi B nhận được file đã được kí và B muốn kiểm tra chữ kí có đúng không thì trước tiên, hệ thống sẽ tách nội dung file và các thông tin liên quan tới chữ kí ra. Tiếp theo B sẽ dùng dịch vụ do hệ thống cung cấp, connect đến bộ phận dịch vụ chứng thư số của RA để lấy chứng thư CertA và kiểm tra xem có đúng là chứng thư hợp lệ hay không. Sau đó nếu chứng thư hợp lệ thì B lấy khóa công khai PbA của A từ chứng thư. B dùng PbA để kiểm tra lại chữ kí và file M để xác thực xem có phải đúng là A đã kí chữ kí này không. Nếu chứng thư không hợp lệ hoặc nếu M không toàn vẹn hoặc không phải A kí chứng thư thì kết quả việc kiểm tra sẽ biết được ngay. Trái lại chữ kí là hợp lệ và file M không bị thay đổi trên đường truyền. Về cơ bản hoạt động kí và kiểm tra chữ kí diễn ra như minh họa trong hình biểu diễn ở chương 1. Điểm cẩn lưu ý ở đây là: cả A, B là người dùng của hệ thống BioPKI-OpenCA và mỗi bên đã được cấp một chứng thư số, tức mỗi bên đều đã có thẻ token. Bên A lúc kí muốn lấy được khóa cá nhân phải dùng token để xác thực, bên B khi connect tới RA cũng cần được xác thực và cần đến token. Hình 5.2: Biểu đồ diễn tiến quá trình kí Trong biểu đồ trên, khi cần lấy khóa cá nhân để kí, ứng dụng hỏi người dùng đường dẫn đến file khóa và password (passpharse). Nếu dùng thẻ token đã tích hợp sinh trắc để mã hóa khóa cá nhân thì hai lời gọi trên được thay thế bằng việc yêu cầu user đưa thẻ vào và ứng dụng tiến hành đọc thẻ, giải mã để lấy khóa cá nhân. Biểu đồ diễn tiến quá trình xác thực chữ kí: Hình 5.3: Biểu đồ diễn tiến quá trình xác thực chữ kí Trong biểu đồ trên, ứng dụng cần khóa riêng của user để thiết lập kênh SSL đến bộ phận cung cấp dịch vụ chứng thư số của RA, ứng dụng sẽ hỏi đường dẫn đến file private key và password (passpharse). Nếu hệ thống sử dụng thẻ nhúng, thì việc này sẽ được thay thế bằng các hành động: yêu cầu user đưa thẻ vào, đọc thẻ và giải mã để lấy khóa cá nhân Hình 5.4: Quá trình kí có thử nghiệm hoạt động tất cả các thành phần của hệ thống BioPKI-OpenCA Hình 5.5: Quá trình xác thực có thử nghiệm hoạt động tất cả các thành phần của hệ thống 5.2 Kết quả thử nghiệm Các thành phần hệ thống đều chạy đúng chức năng thiết kế, ứng dụng chữ kí số hoạt động tốt trên các nền tảng dịch vụ mà hệ thống cung cấp. Thành phần Setup hệ thống hoạt động đúng với yêu cầu, khởi tạo được đầy đủ các thông số ban đầu để hệ thống có thể hoạt động được. Hình 5.6: Kết thúc quá trình kí Hình 5.7: Kết thúc quá trình xác thực chữ kí KẾT LUẬN Đề tài “Xây dựng phân hệ Setup trong hệ thống an ninh dựa trên sinh trắc học BioPKI-OpenCA” nằm trong khuôn khổ đề tài nghiên cứu khoa học công nghệ cấp nhà nước KC01.11/06-10 “Hệ thống an ninh thông tin dựa trên sinh trắc học sử dụng công nghệ nhúng BioPKI”. Trong thời gian nghiên cứu, tìm hiểu, xây dựng ứng dụng đố án đã hoàn thành được các nhiệm vụ được đặt ra, cụ thể là: Về mặt lý thuyết: Đồ án đã trình bày được những khái niệm, đặc điểm cơ bản của một hệ thống PKI, tổng quan về OpenCA, trình bày được khái niệm sinh trắc học (biometric), các hướng tích hợp biometric vào một hệ PKI. Về mặt thiết kế: Đồ án đã đóng góp vào thiết kế tổng quan hệ thống BioPKI-OpenCA, thiết kế thành phần setup hệ thống, thiết kế các quy trình trong hệ thống. Về mặt cài đặt thực tế và kết quả thử nghiệm: Đã hoàn thành việc cài đặt module Setup, tích hợp module vào hệ thống BioPKI dựa trên OpenCA, tiến hành thử nghiệm thành công ứng dụng chữ ký số trên phòng thí nghiệm liên mạng Mặc dù đã hết sức cố gắng nhưng trình độ chuyên môn và thời gian thực hiện đồ án còn hạn hẹp, cũng như mức độ phức tạp của đề tài, nên kết quả đạt được còn gặp phải một số khiếm khuyết. Hướng phát triển đề tài: Tiếp tục hoàn thiện các chức năng, nhằm tăng hiệu quả và độ an toàn. Tích hợp module sinh trắc và quản lý thẻ eToken vào quá trình setup hệ thống, hoàn thiện hơn về giao diện để tăng tính chuyên nghiệp nhằm đáp ứng khả năng ứng dụng thực tế cho hệ thống Bio-PKI dựa trên OpenCA TÀI LIỆU THAM KHẢO [1] Phạm Huy Điển, Hà Huy Khoái (2003), Mã hoá thông tin cơ sở toán học và ứng dụng, Nhà xuất bản Đại học Quốc gia Hà nội. [2] Phan Đình Diệu (1999), Lý thuyết mật mã và an toàn thông tin, Đại học Quốc Gia Hà Nội, Hà Nội. [3] Trịnh Nhật Tiến (2004), Một số vấn đề về an toàn dữ liệu, Hà Nội. [4] Adams, C. (1999), Understanding Public Key Infrastructures, New Riders Publishing, Indianapolis. [5] Andrew Nash, William Duance, Celia Joseph, and Derek Brink (2001), PKI Implementing and managing E-Security, McGraw –Hill Co. [6] Fegghi, J.(1999), Digital Certificates and Applied Internet Security, Addison-Wesley Longman, Inc. [7] ITU-T Recommendation X.509 (2000), “The Directory: Public key and Attribute Certificates Framework”. [8] Rivest, R.L., A.Shamir, and L.M.Adleman (1978), “A method for obtaining digital signatures and public-key cryptosystems”, Communications of the ACM. [9] Housley, R. (1999), Internet X.509 Public Key Infrastrure Certificate and CRL Profile, RFC 2459. [10] Myers, M. (1999), X.509 Internet Public Key Infrastrure On-line Certificate Status Protocol, RFC 2560. [11] Jain, A. K. (28-30 April 2004), "Biometric recognition: how do I know who you are?", Signal Processing and Communications Applications Conference, 2004. Proceedings of the IEEE 12th. [12] Shapiro, Debra Lynn; Puri, Preeti. “Biometric Security For Advanced Traffic Management System”. ITS America. Meeting (12th : 2002 : Long Beach, Calif.). Securing our future : ITS America 12th Annual Meeting and Exposition 2002 : conference proceedings. [13] [14] [15] BioPKI-OpenCA- design 20-3-09 [16] Đồ án tốt nghiệp Bùi Thành Đạt [17] Đồ án tốt nghiệp Nguyễn Văn Toàn