Xây dựng module đăng ký người dùng trên nền web-Based trong hệ thống an ninh thông tin BK - BioPKI

Hình 1.6 Kiến trúc đơn Kiến trúc phân cấp (Hierarchical architecture) Hình 1.7 Kiến trúc phân cấp Kiến trúc lưới (Mesh architecture) Hình 1.8 Kiến trúc lưới Kiến trúc lai (Hybird architecture) Kiến trúc lai được chia làm 3 loại chính [7]: Kiến trúc danh sách điểm tin cậy mở rộng (Extended Trust List): mỗi phần tử trong danh sách có thể là CA của bất cứ kiến trúc nào. Đây là loại hình phổ biến được các trình duyệt sử dụng. Kiến trúc PKI chứng nhận chéo (Cross-certified PKI): kết hợp các hệ thống PKI cấp thấp nhằm thành lập mô hình lưới PKI cao hơn. Kiến trúc CA bắc cầu (Bride CA architecture): khi số lượng các PKI trong mô hình chứng nhận chéo lớn à số lượng chứng chỉ số tăng lên à tạo ra một CA làm trung gian khi thực hiện xác thực giữa hai hệ thống PKI. CA này không được coi là một điểm tin cậy. Mỗi kiến trúc đều có các ưu và nhược điểm riêng. Việc lựa chọn kiến trúc nào để áp dụng cho một hệ thống PKI là tùy thuộc vào nhu cầu của tổ chức thực thi hệ thống PKI đó. 1.4. Các hoạt động chính trong hệ thống PKI Một hệ thống PKI bao gồm các hoạt động chính sau [8] 1.4.1. Cấp phát chứng chỉ Quá trình cấp phát chứng chỉ được chia thành hai bước: Người dùng gửi yêu cầu xin cấp phát chửng chỉ cho CA thông qua RA. Thông thường yêu cầu có các thông tin như: tên của CA, khóa công khai của người dùng, thuật toán tương ứng, chữ ký số của người dùng được tạo ra từ khóa cá nhân (theo chuẩn PKCS#10 thông dụng hiện nay). Thông điệp yêu cầu được gửi qua thư điện tử, sử dụng định dạng PEM (Privacy Enhanced Mail), hoặc bằng giao thức SSL. CA ủy quyền trả lời cho RA. Sau khi xác minh yêu cầu thành công. RA chuyển yêu cầu này cho CA. CA tiến hành tạo chứng chỉ số dựa trên các thông tin có trong yêu cầu phát hành. Tiếp đến, CA dùng khóa cá nhân ký lên chứng chỉ số, đảm bảo tính toàn vẹn nội dung và khẳng định sự tin cậy của CA đối với chứng chỉ số. CA gửi lại cho RA, RA gửi lại chứng chỉ này cho người dùng. Chứng chỉ số sau khi phát hành cần được công bố rộng rãi cho bất kỳ ai có nhu cầu trao đối thông tin với chủ thể của chứng chỉ số đó. 1.4.2. Phân phối chứng chỉ PKI thường dùng một số phương pháp công bố chứng chỉ số như sau: Dịch vụ thư mục: Phương pháp này dành cho các chứng chỉ số theo chuẩn X.509. Dịch vụ thư mục dành cho PKI phổ biến là X.500/LDAP theo chuẩn của IETF. Trang web: các chứng chỉ số được đưa lên trang web để mọi người có thể truy cập. Các phương tiện khác như email .. 1.4.3. Thu hồi chứng chỉ Các chứng chỉ số bị thu hồi khi hết thời gian sử dụng, CA chứng thực cho chứng chỉ đó không còn tin cậy hoặc chứng chỉ số đó không còn được dùng nữa Chỉ có CA mới có quyền thu hồi chứng chỉ. Sau khi thu hồi phải công bố rộng rãi. Có hai cách công bố là: đưa thông báo lên một máy chủ để cảnh báo mọi người hoặc đưa chứng chỉ số bị hủy bỏ vào một danh sách chứng chỉ hết hiệu lực (Certificate Revocation Lists - CRL) và sau đó sẽ được xóa bỏ. 1.4.4. Quản lý khóa cá nhân Khóa cá nhân ở đây bao gồm cả khóa cá nhân của người dùng và khóa cá nhân của CA. Việc quản lý gồm 3 hoạt động như sau: Bảo vệ khóa cá nhân: khóa cá nhân được lưu trong phương tiện lưu trữ an toàn như smart card hay file đã mã hóa. Truy cập tới khóa cá nhân cần phải có thông tin xác thực như PIN, mật khẩu hay đặc trưng sinh trắc học Cập nhật khóa: Do người sử dụng đã được định danh từ trước nên quá trình này đơn giản chỉ là tạo thêm một chứng chỉ số và cặp khóa mới. Để cập nhật chứng chỉ số cho CA gốc, quá trình sẽ phức tạp hơn, vì một số người dùng vẫn có thể đang tin cậy chứng chỉ số cũ trong khi một số chuyển sang tin cậy chứng chỉ số mới. Giải pháp cho vấn đề này là tạo ra và phát hành ba chứng chỉ số chuyển tiếp tạm thời như sau: Một chứng chỉ số có chứa khóa công khai cũ của CA, được ký bằng khóa cá nhân mới của CA. Thời gian hoạt động của chứng chỉ số này tính từ ngày tạo cho tới ngày hết hạn của chứng chỉ số cũ. Một chứng chỉ số có chứa khóa công khai mới của CA, được ký bằng khóa cá nhân cũ của CA. Chứng chỉ số này có hiệu lực từ ngày ký cho tới ngày hết hạn của chứng chỉ số cũ. Một chứng chỉ số có chứa khóa công khai mới của CA, được ký bằng khóa cá nhân mới của CA. Đây là chứng chỉ số có tính ổn định, hoạt động cho tới khi cần phải cập nhật khóa cho CA lần tiếp theo. Sao lưu/phục hồi: Chức năng này cho phép người dùng lấy lại khóa cá nhân trong trường hợp bị mất. Việc sao lưu và phục hồi khóa phải được tiến hành bằng một đối tác tin tưởng (như một CA), có trách nhiệm giữ bí mật các khóa cá nhân. 1.6. Một số vấn đề an toàn của hệ thống PKI Hệ thống PKI được xây dựng với mục đích chính là để cung cấp các dịch vụ an toàn, tuy nhiên như bất cứ một hệ thống nào PKI cũng tồn tại một sô vấn đề an toàn [1]. 1.6.1. Lộ khóa cá nhân Vấn đề đầu tiên được nhắc tới của hệ thống PKI chính là việc lộ khóa cá nhân của người dùng. Khóa cá nhân của người dùng được lưu trữ trên các phương tiện khác nhau mà các phương tiện này thông thường chỉ được bảo vệ bởi một password nên khả năng mất an toàn là rất cao. Vấn đề này có thể được giải quyết khi áp dụng sinh trắc học để bảo vệ khóa riêng. 1.6.2. Giả mạo khóa công khai Trường hợp khóa này được bảo vệ bằng chữ ký của CA, tức là kiểm tra được bằng khóa công khai của CA, có nguy cơ kẻ tấn công thay thế khóa của CA trên máy người dùng, sau đó tiến hành thay thế khóa công khai của người dùng bằng khóa giả. 1.7. Tổng quan về OpenCA 1.7.1. Định nghĩa OpenCA là một mô hình PKI mã nguồn mở, được viết bằng Perl, sử dụng phần nhân là OpenSSL và được viết bởi PKI Lab. Hệ thống này được xây dựng với mục đích cung cấp một hạ tầng cơ sở khóa công khai mã nguồn mở với đầy đủ các chức năng quản lý chứng chỉ bao gồm cấp phát, thu hồi, gia hạn chứng chỉ cho người dùng. Phiên bản mới nhất tính đến thời điểm hiện nay (tháng 5 năm 2009) là OpenCA PKI v1.0.2 (ten-ten2) . 1.7.2. Các thành phần cơ bản của OpenCA Hình 1.9 Các thành phần cơ bản của OpenCA Các thành phần cơ bản của OpenCA gồm: 1.7.2.1. Module Pub Module Pub trong OpenCA là giao diện trực tiếp với người sử dụng thực hiện các chức năng sau : Tiếp nhận yêu cầu cấp và thu hồi chứng chỉ của người dùng : để thực hiện chức năng này, Pub thực hiện thu thập các thông tin cơ bản của người dùng đặc biệt là 1 số PIN dùng cho việc xác thực yêu cầu của người dùng. Sau đó gửi yêu cầu đó cho RA. Pub cũng là nơi thực hiện việc cấp các chứng chỉ do CA duyệt thông qua trả về cho người dùng. Pub cung cấp 1 số tiện ích như kiểm tra các chứng chỉ, quản lý các yêu cầu cấp và thu hồi chứng chỉ cho người dùng. Điểm còn hạn chế của module Pub trong OpenCA là chưa có một hệ thống quản lý người dùng hoàn chỉnh. Đồng thời Pub được truy nhập , tiếp nhận yêu cầu và cấp chứng chỉ tự do tuy nhiên với một hệ thống nguồn mở thì đây vẫn còn là một điều chấp nhận được. 1.7.2.2. Module RA Module RA trong OpenCA được sử dụng để thực hiện việc quản lý các yêu cầu cấp và thu hồi các chứng chỉ dùng cho quản trị RA. Chức năng chính của RA : Quản lý và xét duyệt các yêu cầu về cấp và thu hồi chứng chỉ từ Pub rồi gửi lên cho CA : chức năng này cho phép quản trị RA biên soạn lại các yêu cầu cấp chứng chỉ, xác thực thông tin người dùng sử dụng mã PIN của người dùng đó. Duyệt các chứng chỉ do CA trả về cho người dùng. Một chức năng quan trọng của RA là thực hiện việc sinh khóa riêng cho người dùng sau đó sử dụng mã PIN để mã hóa bảo vệ và khóa riêng và gửi lên cho CA. Trong mô hình PKI phổ biến thì RA thường đứng ở vai trò giao tiếp với người dùng. Nhưng trong OpenCA thì module Pub cộng với RA mới tạo thành một RA đúng nghĩa. Việc phân thành hai lớp quản lý như vậy tạo ra sự linh hoạt và mềm dẻo trong việc quản lý quy trình cấp chứng chỉ. 1.7.2.3. Module CA Module CA trong OpenCA thực hiện các chức năng quản lý việc cấp và thu hồi các chứng chỉ. Chức năng chính của CA: Quản lý các yêu cầu cấp phát và thu hồi chứng chỉ do RA gửi lên : ở chức năng này CA hỗ trợ việc duyệt các yêu cầu cấp chứng chỉ đồng thời thực hiện các chức năng như cấp và thu hồi chứng chỉ cho người dùng. Quản lý các danh sách chứng chỉ bị thu hồi. 1.8. Tổng quan về Sinh trắc học 1.8.1. Khái niệm 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. 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ạng bàn tay hay ngón tay, giọng nói, chữ ký Hình 1.10 Các thuộc tính sinh trắc học 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ể được sử dụng cho mục đích này hay không như sau: 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ư: mống mắt, vân tay, khuôn mặt 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ề vững (Permanence): Những đặc tính sinh trắc học phải khá ổn định trong suốt cuộc đời 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 đặc trưng sinh trắc học này phải được con người chấp nhận trên thực tế. Tính an toàn (Resistance to Circumvention): Hệ thống có dễ dàng bị giả mạo hay không. 1.8.2. Các giải pháp tích hợp sinh trắc vào hệ thống PKI 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 chỉ 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 [6]. 1.8.2.1. 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 chỉ 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 chỉ 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 chỉ 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 chỉ 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 [6]: 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. 1.8.2.2. 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ế. 1.8.2.3. 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 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. CHƯƠNG 2: HỆ THỐNG BK-BioPKI VÀ GIẢI PHÁP TÍCH HỢP SINH TRẮC 1.Khái quát hệ thống BK-BioPKI 1.1.Mô hình thiết kế tổng thể hệ thống BK-BioPKI Hệ thống BK-BioPKI thuộc đề tài nghiên cứu cấp nhà nước KC01110 của khoa công nghệ thông tin nhằm nghiên cứu thử nghiệm một số giải pháp tích hợp sinh trắc học vào hệ thống PKI. Hệ thống được xây dựng dựa trên nền tảng OpenCA. Đây là hệ thống được phát triển tiếp theo hệ thống BK-BioPKI trong môi trường OpenSSL của đề tài theo Nghị định thư hợp tác với Malaysia 2008. Mục đích của hệ thống BK-BioPKI là tạo một môi trường cơ sở hạ tầng khóa công khai trong phòng thí nghiệm với mạng cục bộ từ đó phát triển thử nghiệm tích hợp sinh trắc học vào PKI để nghiên cứu một số vấn đề về an toàn an ninh dựa trên sinh trắc học. Mô hình hệ thống BioPKI dựa trên môi trường OpenCA thuộc về công trình của đề tài KC0111 nghiên cứu và xây dựng, phiên bản hệ thống hiện nay đang được thiết kế triển khai bởi nhóm sinh viên K49, bao gồm các bạn: Nguyễn Văn Toàn, Nguyễn Đức Toàn, Bùi Đức Khánh, Trần Anh Mỹ, Nguyễn Thúy Hằng, Trần Hoàn Vũ Hiệp, Ngô Xuân Tùng, Nguyễn Tư Hoàn. Sơ đồ về mô hình hệ thống BK-BioPKI được trình bày trong hình dưới đây Hình 2.1 Mô hình thiết kế tổng thể hệ thống BK-BioPKI. Trong mô hình này, yếu tố sinh trắc sẽ được sử dụng trong các hoạt động : cấp chứng chỉ và sử dụng chứng chỉ. 1.2. Các thành phần của hệ thống BKBio-PKI dựa trên OpenCA Theo phân tích của nhóm đề tài KC0111, hệ thống BK-BioPKI gồm có các thành phần và chức năng của chúng như sau: 1.2.1. CA CA là nơi cấp phát chứng chỉ (hay còn gọi là chứng thư số). Các chứng chỉ này tuân theo chuẩn X509 đã trình bày ở trên. Theo sơ đồ trên, CA gồm có hai bộ phận: CA Operator là máy của người điều hành CA, và máy Linux-OpenCA. 1.2.1.1.CA Operator Là một máy Windows kết nối với một máy chủ Linux-OpenCA. CA Operator là một công cụ quản trị cho người điều hành CA. CA Operator 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 CA Operator cung cấp ứng dụng để có thể 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 chỉ, khóa riêng, đặc trưng vân tay của người đăng ký (đã mã hóa) (thiết bị nhúng này có vai trò như thẻ giao dịch điên tử). 1.2.1.2. Linux-OpenCA Là một máy chủ Linux. Quản lý yêu cầu, phát hành chứng chỉ. 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 chỉ. 1.2.2. RA RA giao dịch với CA offline. RA bao gồm 2 bộ phận: bộ phận phát hành chứng chỉ và bộ phận cung cấp các dịch vụ cho phép người dùng sử dụng chứng chỉ đối với các ứng dụng cụ thể. 1.2.2.1.Bộ phận dịch vụ phát hành chứng chỉ Cung cấp các dịch vụ về chứng chỉ. Bộ phận này bao gồm các chức năng : Phát hành thiết bị nhúng Etoken chứa chứng chỉ (Phát hành chứng chỉ ) xử lý mất thiết bị nhúng Etoken (hủy chứng chỉ theo yêu cầu) xử lý cấp thiết bị nhúng Etoken (cấp mới chứng chỉ). 1.2.2.2.Bộ phận dịch vụ chứng chỉ Cung cấp các dịch vụ để sử dụng chứng chỉ tương ứng với từng ứng dụng cụ thể như chữ ký số, mã hóa thông điệp... Chẳng hạn: Dịch vụ xác thực chứng chỉ: kiểm tra thông tin, tính hợp lệ của chứng chỉ. Dịch vụ cung cấp chứng chỉ theo serial number 1.2.3.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, bao gồm các chức năng sau: Phát hành thiết bị nhúng Etoken (chứng chỉ) 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 chỉ): nơi khách hàng đến để yêu cầu hủy chứng chỉ trong trường hợp mất thẻ. Cấp mới thiết bị nhúng Etoken (chứng chỉ). 1.2.4.User Applications User Application là các ứng dụng cho phép người dùng truy cập đến trung tâm dịch vụ chứng chỉ của RA để sử dụng chứng chỉ của mình vào một số ứng dụng như chữ ký sô, mã hóa thông điệp 1.3. Xây dựng phương án về quy trình hệ thống BK-BioPKI 1.3.1. Cấp phát chứng chỉ Quy trình để cấp phát mới một chứng chỉ cho một người dùng gồm có: Khi một người dùng muốn có một chứng chỉ để sử dụng, anh ta sẽ đến chi nhánh đăng ký chứng chỉ (LRA), điền thông tin vào mẫu đơn đăng ký xin cấp chứng chỉ (xem mẫu) nộp cho nhân viên chi nhánh. Các thông tin bao gồm: họ 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, email, chức vụ, thời hạn đề nghị cấp. 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 chỉ chuyên dùng cho user của CA. 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ý Đưa giấy hẹn trả lời cho người dùng (có mã đăng ký). LRA ký và gửi thông tin đăng ký xin cấp chứng chỉ cho RA gồm các thông tin sau: Thông tin đăng ký. Mã đăng ký. 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 những thông tin sau 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ệ thì cập nhật trạng thái: Đang chờ duyệt. RA duyệt yêu cầu, nếu không chấ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 chỉ 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ệ 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). 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. CA phát hành chứng chỉ, bao gồm các công việc sau: Ghi khóa riêng, chứng chỉ, đặc trưng sinh trắc vào thiết bị nhúng. Chuyển thiết bị nhúng, chứng chỉ, và mã yêu cầu cho RA RA nhận dữ liệu từ CA, sau đó làm các công việc sau: Insert chứng chỉ vào CSDL chứng chỉ 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 chỉ, 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ị. 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). 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. Người đăng ký cầm giấy hẹn đến LRA để lấy chứng chỉ. 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ẻ). 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). 1.3.2.Hủy chứng chỉ tức thời Vì một lý do nào đó, người dùng bị mất Etoken, khi đó anh ta phải đến trung tâm dịch vụ thẻ để báo cho giao dịch viên để hủy chứng chỉ tức thời. Quy trình gồm có các bước sau: Người dùng đến LRA báo mất thẻ và yêu cầu hủy chứng chỉ. LRA kiểm tra thông tin người dùng để xác minh nhân thân. LRA gửi yêu cầu hủy chứng chỉ (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. 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). Sau khi xác định chính xác mã thẻ cần hủy, dựa trên mã thẻ, RA sẽ làm các công việc sau: Tìm serial number của chứng chỉ chứa trong thẻ. Update trạng thái chứng chỉ: thu hồi. Update trạng thái thẻ: đã hủy. Thông báo lại cho LRA. 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ý. 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 chỉ) gửi cho CA. 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 chỉ. 1.3.3.Sử dụng chứng chỉ Ở đây, ta sẽ đề cập đến hai ứng dụng của chứng chỉ là kí và xác thực chữ kí. Quy trình của chúng như sau: 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 dùng 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 chỉ (ký số) Module ký số thực hiện. Quy trình xác thực chữ ký số: Nhận dữ liệu đã được ký, SN của chứng chỉ Tách chữ ký, SN của chứng chỉ Gửi SN cho RA để lấy chứng chỉ của bên gửi Xác thực chữ ký. 2. Thiết kế tích hợp mã hóa sinh trắc bảo vệ khóa cá nhân vào hệ thống BK-BioPKI Trong các qui trình hoạt động của hệ thống đã nêu trên, nhiệm vụ của đồ án tập trung vào phát triển mô đun xác thực sinh trắc vân tay sống, trực tuyến để bảo vệ khóa cá nhân người dùng. Mô đun sinh trắc sẽ được tích hợp vào trong các qui trình hoạt động “cấp phát chứng chỉ”, “Sử dụng chứng chỉ” và “Hủy bỏ chứng chỉ”. Trong phân dưới đây sẽ tập trung trình bày về phân tích xây dựng giải pháp tích hợp mô đun xác thực sinh trắc vân tay vào hạ tầng hệ thống BK-BioPKI, tuy nhiên trên thực tế, hạ tầng hệ thống BioPKI hiện nay còn đang phát triển, chưa hoàn thiện, nên trong phân tích dưới đây có sử dụng các phương án kịch bản với giả thiết khi hệ thống đã được xây dựng xong. 2.1.Phân tích yêu cầu Yêu cầu tích hợp mã hóa sinh trắc vào hệ thống BK-BioPKI bao gồm vào các thành phần sau: Cấp phát chứng chỉ và sử dụng chứng chỉ có tích hợp sinh trắc vân tay để bảo vệ khóa cá nhân trong các giao dịch và ứng dụng. 2.2.Phân tích thiết kế 2.2.1.Phân hệ sinh trắc sinh khóa bảo vệ khóa cá nhân Đầu vào của phân hệ sinh trắc sinh khóa bảo vệ khóa là vân tay được lấy sống của người dùng. Người dùng cho vân tay vào thiết bị quét vân tay, ảnh vân tay được thu nhận và xử lý, sau đó đặc trưng vân tay của người dùng sẽ được trích chọn. Đặc trưng vân tay sẽ được dùng để mã hóa khóa cá nhân, riêng khóa cá nhân được băm, tất cả được lưu vào cơ sở dữ liệu. Trong pha thẩm định, đặc trưng vân tay cũng được trích chọn, các đặc trưng này sẽ được dùng để giải mã khóa cá nhân, sau đó băm kết quả, nó sẽ được so sánh với khóa đã băm lưu trong cơ sở dữ liệu. Từ đó đưa ra kết quả thẩm định. Giải pháp cụ thể của phân hệ này được trình bày trong chương “Phân tích thiết kế hệ thống”. Sau đây là mô hình chung của phân hệ đó: Hình 2.2 Phân hệ mã hóa sinh trắc bảo vệ khóa cá nhân. 2.2.2.Thiết kế tích hợp Phân hệ mã hóa sinh trắc tích hợp vào hệ thống được chia làm hai thành phần: thành phần quét vân tay, xử lý trích chọn đặc trưng và thành phần mã hóa khóa cá nhân bao gồm mã hóa, giải mã khóa, và đối sánh. Quá trình đăng kí sẽ được tích hợp vào phần xin cấp chứng chỉ, quá trình thẩm định sẽ được tích hợp vào phần sử dụng chứng chỉ của hệ thống. Kết quả của quá trình thẩm định sẽ là khóa cá nhân nếu quá trình giải mã khóa là thành công, ngược lại sẽ là NULL. 2.2.2.1.Kịch bản xin cấp chứng chỉ Sau đây là kịch bản quá trình xin cấp chứng chỉ có tích hợp phân hệ mã hóa sinh trắc. Hình 2.3 Kịch bản quá trình xin cấp chứng chỉ. Khi người dùng yêu cầu xin cấp chứng chỉ, quá trình xin cấp chứng chỉ được thực hiện. Yêu cầu cấp chứng được chuyển tới đối tượng giao tiếp với cơ sở dữ liệu. Yêu cầu cấp chứng chỉ được lưu vào cơ sở dữ liệu. Người dùng được yêu cầu quét vân tay. Xử lý trích chọn đặc trưng sinh trắc vân tay. Lấy khóa mật từ đối tượng Request Creator. Khóa mật được truyền cho đối tượng mã hóa khóa. Mã hóa khóa mật bằng đặc trưng sinh trắc trích được từ bước 5. Chuyển khóa mật đã mã hóa cho đối tượng giao tiếp CSDL. Lưu khóa đã mã hóa vào CSDL. 2.2.2.2.Kịch bản sử dụng chứng chỉ Sau đây là kịch bản quá trình sử dụng chứng chỉ có tích hợp phân hệ mã hóa sinh trắc. Các quá trình sử dụng chứng chỉ có thể xảy ra trong: ứng dụng chữ kí số, ứng dụng truy cập từ xa và ứng dụng mã hóa thông điệp. Hình 2.4 Kịch bản quá trình sử dụng chứng chỉ. Người dùng chọn chứng chỉ sẽ sử dụng từ giao diện của một trong các ứng dụng trên. Serial number của chứng chỉ được chọn được gửi đến đối tượng giao tiếp cơ sở dữ liệu (Database access). Dựa vào serial number, khóa được mã hóa tương ứng được truy vấn từ cơ sở dữ liệu. Đối tượng giao tiếp CSDL gửi khóa đã băm cho đối tượng so sánh. Đối tượng giao tiếp CSDL gửi khóa cá nhân đã mã hóa cho đối tượng giải mã. Người dùng được yêu cầu quét vân tay. Xử lý trích chọn đặc trưng sinh trắc vân tay. Đặc trưng vân tay được gửi cho đối tượng giải mã khóa mật. Khóa mật đã được giải mã được gửi cho đối tượng so sánh. Khóa mật được băm và đem so sánh với khóa đã băm lưu trong CSDL. Nếu kết quả so sánh là khẳng định, khóa mật được tìm ra. Khóa cá nhân được gửi đến ứng dụng cần sử dụng. CHƯƠNG 3: KHẢO SÁT VÀ PHÂN TÍCH XÂY DỰNG ỨNG DỤNG TRÊN NỀN WEB-BASED 1. Giới thiệu công nghệ Web Trước tiên, chúng ta không thể phủ nhận tầm quan trọng của các ứng dụng desktop. Với các ứng dụng desktop, chúng ta có thể thực hiện được các chương trình lớn, đòi hỏi việc sử dụng tài nguyên lớn của hệ thống: yêu cầu về tốc độ xử lý hay yêu cầu về bộ nhớ lớn, làm việc với các dữ liệu lớn. Tuy nhiên đối với những nhiệm vụ không đòi hỏi việc sử dụng tài nguyên của hệ thống lớn, mà lại đề cao những yếu tố khác như tính phổ dụng, thuận tiện khi sử dụngthì các ứng dụng web là một lựa chọn giải pháp rất tốt và thực tế ngày càng phát triển nhất là vào thời kỳ hoàng kim của Internet như hiện nay. Có thể đưa ra một số thuận tiện của công nghệ web như sau: Đầu tiên là việc chúng ta có thể truy cập vào chương trình và dữ liệu bất cứ lúc nào (ngày hay đêm), bất cứ nơi đâu (ở nhà, cơ quan hay bất cứ đâu có máy tính nối mạng Internet). Chúng ta cũng không phải tiến hành cài đặt bất cứ thứ gì. Thứ hai, chúng ta có thể tiết kiệm được chi phí do không phải đầu tư một hệ thống mạnh hay yêu cầu cấu hình cao. Việc cập nhật và nâng cấp là tức thì, tự động và hơn hết là đều miễn phí. Ngoài ra, chúng ta không còn phải cài đặt chương trình phần mềm trên mọi máy làm việc. Các ứng dụng web cũng không có nguy cơ xung đột với các ứng dụng desktop trên máy. Thứ ba là về vấn đề an toàn an ninh. Ngày nay với việc sử dụng kênh truyền SSL ngày càng rộng rãi thì việc truyền dữ liệu trên Internet đã an toàn hơn nhiều. Tất nhiên không có gì trên thế giới là an toàn 100% , nhưng các chuyên gia về an ninh đã đồng ý rằng các ứng dụng web là một giải pháp an toàn hơn. 2. Phân tích và lựa chọn giải pháp công nghệ xây dựng ứng dụng Trong đề tài KC-0111, hệ thống an ninh sinh trắc BK-bioPKI được phân thành các module nhỏ và hiện được xây dựng trên nền application-based. Tuy nhiên, xét thấy để có thể triển khai hệ thống một cách rộng rãi ra thực tế, em đã nghiên cứu đưa công nghệ web vào hệ thống, bước đầu là xây dựng ứng dụng người dùng module đăng ký trên nền web-based. 2.1. Phân tích yêu cầu ứng dụng Việc đưa ra các phân tích về yêu cầu của ứng dụng giúp xác định và lựa chọn các giải pháp công nghệ dùng để xây dựng ứng dụng. Ngoài các yêu cầu thông thường của một ứng dụng web như: yêu cầu về tốc độ,dễ sử dụng, hỗ trợ nhiều loại trình duyệt,.. ứng dụng này còn có thêm các yêu cầu riêng biệt sau: Ứng dụng web cho phép người dùng truy cập vào một file bất kỳ trên máy local thông qua trình duyệt web.(đó là lấy file ảnh để làm một nội dung đăng ký và truy cập vào file chứa private key để ký vào dữ liệu). Ứng dụng web cho phép ghi file dữ liệu xuống máy local. Về đặc điểm sinh trắc, lúc đầu ứng dụng chọn giải pháp quét vân tay người dùng. Song do việc giao tiếp với thiết bị quét vân tay trên nền web gặp nhiều khó khăn, chưa phổ dụng, nên em đã chọn ảnh khuôn mặt làm đặc điểm sinh trắc. Ứng dụng cho phép người dùng có thể chụp ảnh trực tiếp trên trình duyệt. Tức là gọi trực tiếp webcam trên máy local để chụp ảnh trên trình duyệt (không cần cài chương trình chụp ảnh trên máy local). Ứng dụng sử dụng chữ ký số để đảm bảo an toàn cho dữ liệu trước khi truyền đi. Do đó công nghệ được lựa chọn phải hỗ trợ tốt các vấn đề về an ninh, mã hóa, bảo mật. Dữ liệu sau phải sau đã được ký thì mới được gửi lên server, và dữ liệu đó bao gồm dữ liệu ban đầu và chữ ký. Ứng dụng sử dụng kênh truyền SSL (Https) để truyền dữ liệu lên server để đảm bảo an toàn an ninh. Biểu đồ phân rã chức năng của ứng dụng Hệ thống đăng ký LRA (Web browser) RA server Đóng gói dữ liệu Nhập thông tin Lấy ảnh mặt Ký dữ liệu Kiểm tra chữ ký LRA Thiết lập kênh SSL Nhận dữ liệu Gửi dữ liệu Báo lại và lưu vào CSDL Lưu Hình 3.1. Biểu đồ phần dã chức năng ứng dụng 2.2. Giới thiệu một số giải pháp công nghệ web hiện nay Ngày nay, các ứng dụng web được dùng rất phổ biến và đem lại hiệu quả cao. Ngày càng có nhiều công nghệ web mới ra đời nhằm làm tăng sức mạnh và hiệu quả hơn nữa cho các ứng dụng web. Có thể giới thiệu qua ở đây một số công nghệ mà sự ra đời của nó đã mở ra một cái nhìn hoàn toàn mới cho các ứng dụng web. 2.2.1. Web plug-in Một web plug-in là một chương trình máy tính tương tác với một ứng dụng máy chủ (như một trình duyệt web hay một email client) để cung cấp những chức năng riêng biệt. Các ứng dụng máy chủ cung cấp các dịch vụ mà plug-in có thể sử dụng bao gồm cách thức mà plug-in đăng ký với ứng dụng máy chủ và giao thức trao đổi dữ liệu với nhau. Các plug-in bản thân nó không tự hoạt động mà phụ thuộc vào các dịch vụ cung cấp bởi ứng dụng máy chủ. Hình 3.2. Mô hình hoạt động plug-in Các plug-in được sử dụng với nhiều mục đích như cho phép các bên phát triển thứ ba có thể mở rộng các ứng dụng (ví dụ như các add-ons cho trình duyệt firefox, hay các plug-in hỗ trợ định dạng file nhạc cho các chương trình chơi nhạc), hay chúng được sử dụng để giảm kích thước cho các ứng dụng,Các web plug-in giúp tăng sức mạnh cho trình duyệt. Các trình duyệt web sử dụng các plug-in để chơi video và các định dạng trình diễn khác như: Flash, QuickTime, Silver Light,..và còn nhiều tiện ích khác nữa. 2.2.2. Web Service Web service là các ứng dụng đơn giản chạy trên web, được xây dựng xung quanh các chuẩn trình duyệt web. Web service thực chất là các đoạn code của các chương trình được nhúng vào các trang web. Khi được trình duyệt gọi đến, nó sẽ được thực thi trên máy chủ và kết quả sẽ trả về trình duyệt. Web service sử dụng XML để mã hóa và giải mã dữ liệu, và dùng SOAP để vận chuyển dữ liệu. 2.2.3. Java Applet Java Applet là một mẫu chương trình nhỏ nhúng vào trang web có khả năng lập trình được. Khả năng lập trình và tương tác không thua gì các ứng dụng Desktop. Nói chung tất cả những gì lập trình được cho ứng dụng truyền thống đều có thể đưa vào lập trình trên Applet, gắn nó vào trang web và gửi đi. Ngày nay hầu hết các trình duyệt đều hỗ trợ Applet, các trình duyệt nổi tiếng như: Internet Explorer, Firefox Các Applet được thiết kế có kích thước thật nhỏ gọn và tải chạy được trên môi trường phân tán Internet. Hơn nữa, Applet được dùng để thiết kế giao diện rất hiệu quả. 2.3. Lựa chọn giải pháp công nghệ Dựa vào các phân tích yêu cầu của ứng dụng như trên, em đã chọn Java Applet là công nghệ nền tảng cho việc triển khai xây dựng ứng dụng của mình. Các Java Applet hoàn toàn đáp ứng được các yêu cầu trên của ứng dụng: Công nghệ Applet của Java hỗ trợ rất tốt cho các hành động như: truy cập file, ghi file, truy cập các thiết bị (các thiết bị media) trên máy local từ trình duyệt. Để hỗ trợ cho việc giao tiếp và xử lý đối với các thiết bị media như video hay sound, Java hỗ trợ một framework rất mạnh đó là Java Media Framework (JMF). JMF là một API toàn diện cho phép các nhà phát triển Java xử lý media theo nhiều cách khác nhau. Sử dụng JMF API, người lập trình có thể tạo các ứng dụng Java chơi, chỉnh sửa, tạo luồng hay chụp rất nhiều dạng media phổ biến hiện nay như .avi, .swf, .spl, .mp3, .mov, .au, .mpeg, .mpg,.wav, .gsm, aiff, .mid, .jpg, JMF cũng hỗ trợ media từ các thiết bị như microphone, camera kỹ thuật số, và hiện nay nó cũng hỗ trợ phát hiện ra được rất nhiều các thiết bị media từ nhiều nhà sản xuất khác nhau. Platform Java hỗ trợ rất mạnh về bảo mật bao gồm sự an toàn của ngôn ngữ, mật mã, cơ sở hạ tầng khóa công khai (PKI), xác thực, bảo mật giao tiếp và điều khiển truy cập. Java Crytography Architecture (JCA) là một thành phần chính hỗ trợ sự bảo mật này. Nó chứa tập các API phục vụ cho các thao tác về chữ ký số (digital signature), các bản tóm lược (message digest), chứng chỉ và xác thực chứng chỉ, mã hóa (đối xứng, bất đối xứng, mã hóa luồng), sinh và quản lý khóa. Việc tạo chữ ký vào dữ liệu và xác thực chữ ký theo như yêu cầu của ứng dụng được thực hiện dễ dàng nhờ kiến trúc này. Việc sử dụng kênh truyền bảo mật SSL hiện nay được hầu hết các trình chủ web hỗ trợ, các trình chủ nổi tiếng như IIS của Micorsoft, hay Apache. Ở đây, em sử dụng công nghệ Java kết hợp với trình chủ Apache Tomcat. 2.4. Triển khai sử dụng công nghệ Phần này giới thiệu các bước thiết lập môi trường để phục vụ cho việc xây dựng ứng dụng. Bao gồm: Cài đặt Java. Cài đặt gói công cụ Java Development Kit bản JDK6update13. Gói này download miễn phí tại trang chủ của Sun: Cài đặt server. Ở đây em sử dụng trình chủ Apache Tomcat bản 6.0. Công cụ phát triển. Sử dụng IDE Eclipse và JCreatorPro. Ngoài ra cài đặt thêm bộ framework JMF 2.1.1.e cho việc xử lý multimedia. 2.5. Mô hình ứng dụng Qua việc phân tích lựa chọn công nghệ xây dựng ứng dụng ở trên, em xin đưa ra mô hình của ứng dụng web đăng ký người dùng nằm trong hệ thống BK-BioPKI như sau: LRA (trình duyệt) RA (Tomcat server) CSDL LRA Operator Đăng ký online User Trả thẻ offline Hình 3.3. Mô hình module đăng ký người dùng trên nền web-based 2.5. Một số điểm cần chú ý Trong quá trình tìm hiểu và nghiên cứu xây dựng ứng dụng bằng công nghệ Java, em xin ra đưa ra một số điểm cần lưu ý về mặt công nghệ như sau: Ứng dụng đòi hỏi sau khi điền các thông tin đăng ký, thì dữ liệu phải được ký trước khi gửi đến server. Ở đây, giao diện form đăng kí không thể dùng form hay các thẻ khác của HTML được. Bởi vì khi sử dụng nút “Submit” theo phương thức “POST” thì dữ liệu đã được đóng gói vào file xml và chuyển luôn đến server mà chưa được kí. Do đó, phần giao diện phải được xây dựng hoàn toàn bằng các Applet. Khi sử dụng Applet thì việc truy cập vào file hay thiết bị, hoặc ghi file trên máy local đòi hỏi phải cấu hình sử dụng file policy của java và phải ký vào các applet. Việc thực hiện vấn đề này là khá phức tạp và cần phải lưu ý. Chương sau sẽ đi vào chi tiết thiết kế ứng dụng. CHƯƠNG 4: THIẾT KẾ CHI TIẾT MODULE ĐĂNG KÝ TRÊN WEB 1.Thiết kế kịch bản ứng dụng Ứng dụng được xây dựng trên kịch bản chi tiết theo quy trình đăng ký như sau: 1. Người dùng đến đăng ký điền vào mẫu đơn đăng ký (form giấy) với LRA Operator. 2. Sau khi kiểm tra thông tin người dùng đăng ký, LRA Operator tiến hành nhập thông tin từ mẫu đơn đăng ký vào trình duyệt trên máy LRA. 3. LRA Operator lấy ảnh của người dùng (một giải pháp sinh trắc) vào form đăng ký. Ở đây có 2 lựa chọn: Lấy ảnh từ một file ảnh đã có sẵn của người đến đăng ký. Chụp ảnh trực tiếp khuôn mặt người dùng bằng webcam tại máy LRA (gọi applet chụp ảnh). 4. Dữ liệu người dùng (bao gồm cả ảnh) sau đó được ghi ra 1 file xuống máy LRA. 5. LRA Operator chọn file PKCS#12 được lưu trên máy LRA để chuẩn bị cho việc kí dữ liệu. 6. Ký dữ liệu (dữ liệu đã được “băm” ra trước khi ký để đảm bảo độ dài chữ ký không lớn), đồng thời ghi dữ liệu (bao gồm thông tin người dùng và chữ ký số) ra 1 file trên máy LRA. Khi có người mới đến đăng ký chứng chỉ, file thông tin của người gần nhất sẽ mất đi (bị ghi đè tự động) nên ở đây đưa ra 2 lựa chọn: Nếu cần lưu trữ các file thông tin này thì sau mỗi lần đăng ký, lưu file ra một thư mục riêng. Nếu không cần lưu trữ thì xóa bằng tay hoặc không cần làm gì. 7. LRA Operator bấm nút “Gửi lên RA”. Lúc này, đọc file thông tin vừa ghi ra, tạo một đối tượng mới bao gồm hai trường: một trường là đối tượng chứa thông tin đăng ký, một trường là chữ ký số. Khi nhận được yêu cầu gửi file, RA server thiết lập kênh truyền bảo mật SSL. Khi đó dữ liệu sẽ được gửi lên server RA qua SSL. 8.Server nhận dữ liệu gửi lên, kiểm tra chữ ký của LRA Operator : Nếu chữ ký hợp lệ, lưu dữ liệu vào cơ sở dữ liệu và gửi lại thông báo đăng ký thành công cho LRA. Nếu chữ ký không hợp lệ, hủy bỏ dữ liệu và gửi lại thông báo đăng ký lỗi cho LRA. Kịch bản được mô tả chi tiết theo sơ đồ: Hình 4.1. Kịch bản đăng ký người dùng 2. Thiết kế chi tiết ứng dụng 2.1. Xây dựng form đăng ký Trên form này, LRA Operator sẽ nhập các thông tin của người dùng từ form giấy lên. 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à 5 năm tính từ ngày cấp). Ngoài ra, trên form đăng ký còn có mục lấy ảnh người dùng. Ở đây có 2 lựa chọn: Lấy từ một file ảnh có sẵn. Lấy bằng cách chụp ảnh trực tiếp. (Tuy nhiên, phần này vẫn đang trong quá trình xây dựng). Lưu đồ của form nhập dữ liệu như sau: Hình 4.2. Nhập dữ liệu Một số giao diện nhập dữ liệu của ứng dụng: Hình 4.3. Form đăng ký Hình 4.4. Lấy ảnh từ camera Hình 4.5. Bắt sự kiện bỏ trống trường chưa nhập Hình 4.6. Bắt sự kiện nhập không đúng Hình 4.7. Form nhập đầy đủ 2.2. Xây dựng form ký dữ liệu Trên form này, cho phép LRA Operator chọn file chứng chỉ PKCS#12 (file chứa khóa riêng để ký dữ liệu) do CA cấp và được lưu ở máy LRA. Cụ thể, form này có những nhiệm vụ: Đọc lại file thông tin người dùng vừa ghi ra ở form trước và hiển thị cho người dùng review. Chọn file PKCS#12 để ký dữ liệu. Sau khi có file PKCS#12, tiến hành lấy private key, sử dụng hàm readprvKey public static PrivateKey readprvKey(String pathname,char[] passphrase) throws FileNotFoundException, KeyStoreException, IOException, NoSuchAlgorithmException, CertificateException,UnrecoverableKeyException { PrivateKey p=null; KeyStore ks=KeyStore.getInstance("PKCS12"); ks.load(new FileInputStream(pathname),passphrase); Enumeration en=ks.aliases(); String alias=""; Vector vctAlias=new Vector(); while(en.hasMoreElements()){ vctAlias.add(en.nextElement()); } String[] aliases=(String[])(vctAlias.toArray(new String[0])); for(int i=0;i<aliases.length;i++) if(ks.isKeyEntry(aliases[i])){ alias=aliases[i]; break; } p=(PrivateKey)ks.getKey(alias,passphrase); return p; } Hình 4.8. Lấy khóa riêng Chuyển file thông tin sang mảng byte. Tạo bản tin tóm lược cho file thông tin để chuẩn bị ký: Ký vào bản tin tóm lược vừa tạo. Tạo một đối tượng bao gồm thông tin người dùng và chữ ký điện tử ở trên. Ghi đối tượng đó ra một file xuống máy LRA. Đây chính là file cần chuyển đến RA Server. Lưu đồ của form ký dữ liệu như sau: Hình 4.9. Form ký và gửi dữ liệu 2.3. Ký vào Applet [10] Như đã trình bày ở trên, để Applet có thể đọc hay ghi file trên máy local thì các Applet đó cần phải được ký và được người dùng chấp nhận khi load Applet đó. Thông thường chứng chỉ chứa khóa riêng để ký applet do một bên đáng tin thứ ba cung cấp, và phải trả tiền cho chứng chỉ đó. Một số trang chuyên cung cấp chứng chỉ phổ biến trên thế giới và Việt Nam hiện nay như: verisign.com, chungchiso.com,.. Tuy nhiên trong giới hạn nghiên cứu làm đồ án, em sử dụng keytool của Java để tự tạo chứng chỉ. Các bước cụ thể như sau: Tạo file jar. Biên dịch Applet class cần chạy (bao gồm cả các class liên quan khác). Hình 4.10. Tạo file jar Tạo file key. Hình 4.11. Tạo file key Câu lệnh trên sinh ra 1 cặp khóa với tên bí danh là signFiles, với password truy nhập khóa riêng chứa trong cặp khóa vừa sinh ra là –keypass abcabc. Cặp khóa sinh ra được lưu trong keystore file: bienstore (-keystore bienstore), password truy cập bienstore là –storepass defdef. Ký vào file jar Hình 4.12. Ký vào file jar /* AUTOMATICALLY GENERATED ON Mon Sep 14 09:55:03 PDT 1998*/ /* DO NOT EDIT */ keystore "BienNLstore"; grant signedBy "bien" { permission java.security.AllPermission; permission java.util.PropertyPermission "user.home", "read"; permission java.io.FilePermission "${user.home}", "read,write"; permission java.io.FilePermission ">", "read,write";}; Tạo file policy (.jp) cho phép đọc ghi file lên máy local Hình 4.13. File policy Gắn Applet đã ký vào file HTML. <applet code = "sign.class" archive="Ssign.jar" width = "600" height = "700" > Hình 4.14. Thẻ Như vậy, chúng ta đã ký thành công Applet. Khi chạy trên trình duyệt lần đầu tiên, chúng ta sẽ được hỏi xem có tin tưởng vào chứng chỉ dùng để ký vào applet không. Hình 4.15. Lần đầu gọi Applet 2.4. RA Server xác thực chữ ký của LRA Để RA server xác thực chữ ký thì LRA phải gửi cho RA server dữ liệu, chữ ký số và khóa công khai tương ứng với khóa riêng mà LRA dùng để ký dữ liệu. Ở bước này, RA server đã nhận được file chứa đối tượng bao gồm thông tin người đăng ký và chữ ký số của LRA. RA server sẽ đọc tách phần chữ ký số của LRA ra và tiến hành xác thực. Nếu chữ ký hợp lệ, RA server sẽ gửi thông báo đăng ký thành công lại cho LRA và lưu thông tin vào trong CSDL của mình. Nếu chữ ký không hợp lệ, RA server gửi thông báo “chữ ký không hợp lệ, đăng ký thất bại” cho LRA và sẽ hủy thông tin vừa nhận được. Hình 4.16. Xử lý tại server Giao diện trả về như sau: Hình 4.17. Server báo về Success 2.5.Cấu hình SSL cho Tomcat server[11] Server Tomcat khi không dùng kênh bảo mật SSL sẽ có dạng như sau Hình 4.18. Tomcat server Việc thiết lập kênh truyền SSL cho trình chủ Tomcat, gồm những bước sau: Tạo chứng chỉ keystore Hình 4.19. Tạo chứng chỉ. Copy file chứng chỉ .keystore vừa tạo vào thư mục conf của Apache. Sửa file server.xml, đoạn sửa như sau: <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile=".keystore" keystorePass="changeit"/> Hình 4.20. Enable SSL in Tomcat Khởi động lại server, và truy cập vào địa chỉ https://localhost:8443/ Hình 4.21. Khởi động SSL 2.6. Cơ sở dữ liệu ở Server Ứng dụng sử dụng hệ quản trịn CSDL mySQL. Bảng thông tin người dùng như sau: Hình 4.22. Bảng personinfo Nhằm giảm kích thước CSDL của ứng dụng, sau khi nhận dữ liệu người dùng, server sẽ lưu file ảnh ra một thư mục riêng trên máy chủ, và lưu vào CSDL đường dẫn của thư ảnh đó. KẾT LUẬN Đề tài “Xây dựng module đăng ký người dùng trên nền web-based” nằm trong khuôn khổ đề tài nghiên cứu cấp nhà nước KC0111 “Hệ thống an ninh sinh trắc học BK-BioPKI” của khoa CNTT. 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ụ: Về lý thuyết: Đồ án đã trình bày được những khái niệm, những cơ sở lý thuyết của hệ thống PKI, OpenCA như các công nghệ mã hóa, chữ ký điện tử, chứng thư số; mô hình và hoạt động của hệ thống. Đưa ra được những hiểu biết cơ bản về sinh trắc học và đưa ra các giải pháp tích hợp sinh trắc biometric vào một hệ thống PKI. Về sản phẩm: đồ án đã phân tích được những yêu cầu của ứng dụng và đưa ra giải pháp lựa chọn công nghệ. Xây dựng được trang web đăng ký người dùng với các chức năng cơ bản là điền thông tin đăng ký, tích hợp ảnh khuôn mặt người dùng, tích hợp chữ ký số và xác thực tại server, và truyền dữ liệu qua kênh bảo mật SSL. Tuy nhiên đồ án này còn những tồn tại sau: Ứng dụng xây dựng mới đưa được ảnh có sẵn vào thông tin đăng ký mà vẫn chưa đưa được tính năng chụp ảnh trực tiếp người dùng trên web vào. Ứng dụng mới chỉ được xây dựng qua mô hình client-server trên một máy (bao gồm cả server và trình duyệt web), chưa triển khai tích hợp được ứng dụng vào hệ thống lớn của đề tài KC01111 là BK-BioPKI do các bạn khác xây dựng. Qua quá trình tìm hiểu nghiên cứu làm đồ án, em thấy việc đưa công nghệ web vào một số module của hệ thống BK-BioPKI là hoàn toàn khả thi. Em xin đề xuất một số hướng phát triển đề tài như sau: Tiếp tục nghiên cứu việc giao tiếp với các thiết bị như quét vân tay và chụp ảnh trên nền web. Cụ thể hơn là nghiên cứu đưa được các ứng dụng như quét vân tay và chụp ảnh lên Applet. Một giải pháp nữa cũng cần lưu ý đó là sử dụng công nghệ flash. Nghiên cứu giải pháp chích chọn đặc trưng sinh trắc sau khi có ảnh của đặc điểm sinh trắc. Tuy nhiên, do việc chích chọn sử dụng thuật toán tính toán phức tạp, thư viện hỗ trợ khá lớn, nên đưa lên web là một vấn đề khó. Sau khi nghiên cứu xây dựng module đăng ký người dùng, em thấy hoàn toàn có thể phát triển thêm module đăng nhập người dùng sau khi đã đăng ký. Có ba kịch bản như sau: Người dùng đến đăng ký mới. LRA Operator vào mục tìm kiếm của ứng dụng, nhập vào tên người dùng kèm theo số CMND (hoặc một trường nào đó để làm rõ thêm thông tin tìm kiếm). Nếu đã có thì báo lại với người dùng. Nếu không có thì chuyển sang module đăng ký để đăng ký mới cho người dùng. Người dùng đến thông báo hủy chứng chỉ. LRA Operator vào mục tìm kiếm của ứng dụng, nhập vào tên người dùng kèm theo số CMND (hoặc mã thẻ,để làm rõ thêm thông tin tìm kiếm). Sau đó LRA Operator đánh dấu hủy chứng chỉ của người này, báo lại cho server. Người dùng đến xin cấp gia hạn chứng chỉ. Cũng tương tự như trường hợp người dùng đến xin hủy chứng chỉ, chỉ khác là LRA sẽ báo lại cho Server là gia hạn thêm cho chứng chỉ của người dùng kèm theo thời hạn mà người dùng sẽ chọn trong mục thời hạn xin gia thêm. Em thấy đây là một đề tài rất hay. Mặc dù đã được thầy giáo hướng dẫn nhiệt tình giúp đỡ và chỉ bảo cộng với sự nỗ lực bản thân, xong do kiến thức bản thân còn hạn chế nên đồ án không thể tránh khỏi nhiều thiếu xót. Em xin tiếp tục cố gắng để có thể hoàn thiện hơn đề tài sau này cũng như tiếp tục nghiên cứu đi theo các hướng phát triển đề tài đã đề ra. Em xin chân thành cảm ơn! TÀI LIỆU THAM KHẢO [1]. Carl Ellison, Bruce Scheneier. “Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure”. Computer Security Journal. Volume XVI, Number 1, 2000. [2]. JavaTM Cryptography Architecture (JCA) Reference Guide. [3]. RFC 2510. Internet X509 Public key infrastructure Certificate Management Protocols. Network working group. [4]. RFC 2828. Internet Security Glossar. [5]. Đồ án tốt nghiệp Bùi Thành Đạt, lớp TTM, K48. [6]. Bùi Trọng Tùng, chuyên đề 1.5.1. [7]. Suranjan Choudhury, Kartik Bhatnagar, Wasim Haque. "PKI Implementation & Design".Wiley 2002. [8]. S.Xenitellis, “The Open-source PKI book”, Open CA Team, 2000. [9]. [10]. [11]. Marty Hall, Larry Brown, Yaakov Chaikin. “Core Servlets and JavaServer Pages”. Volume 2: Advanced Technologies, 2nd edition.