Bao Cao Datn-tran Hoan Vu

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP 1. Thông tin về sinh viên Họ và tên sinh viên: Trần Hoàn Vũ Điện thoại liên lạc: 0982.195.223

Email: [email protected]

Lớp: Hệ Thống Thông Tin và Truyền Thông

Hệ đào tạo: Chính quy

Kỹ Sư Chất Lượng Cao – K49 Đồ án tốt nghiệp được thực hiện tại: Bộ môn Truyền thông và mạng máy tính Thời gian làm ĐATN: Từ ngày 12/03/2009 đến

12/06/2009

2. Mục đích nội dung của ĐATN Nhiệm vụ của đồ án là xây dựng thành phần Setup trong hệ thống BioPKI-OpenCA. Đây là một hệ thống an ninh thông tin dựa trên sự kết hợp giữa sinh trắc học với hạ tầng khóa công khai PKI dùng môi trường OpenCA có sử dụng thiết bị nhúng. Trọng tâm của đồ án là tập trung xây dựng phân hệ Setup hệ thống BioPKI-OpenCA.

3. Các nhiệm vụ cụ thể của ĐATN •

Tìm hiểu lý thuyết về PKI, OpenCA, sinh trắc học, các giải pháp tích hợp sinh trắc với hạ tầng khóa công khai để thành hệ BioPKI

•

Tập trung xây dựng, phát triển phân hệ Setup hệ thống BioPKI-OpenCA

•

Thử nghiệm một ứng dụng trên hệ thống BioPKI-OpenCA

4. Lời cam đoan của sinh viên: 1

Tôi –Trần Hoàn Vũ - cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của PGS.TS. Nguyễn Thị Hoàng Lan. Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công trình nào khác.

Hà Nội, ngày 29 tháng 05 năm 2009 Tác giả ĐATN Trần Hoàn Vũ

5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ:

Hà Nội, ngày

tháng năm 2009

Giáo viên hướng dẫn

PGS.TS. Nguyễn Thị Hoàng Lan

2

M ỤC L ỤC

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP…………………………………………...1 LỜI CẢM ƠN…………………………………………………………………………………….6 TÓM TẮT ĐỒ ÁN……………………………………………………………………………….7 DANH MỤC TỪ VIẾT TẮT……………………………………………………………………8 DANH MỤC HÌNH VẼ………………………………………………………………………….9 CHƯƠNG 1 – LÝ THUYẾT TỔNG QUAN VỀ MẬT MÃ VÀ ỨNG DỤNG……………..11 1.1 Giới thiệu chung…………………………………………………………………………...11 1.2 Khái niệm hệ mật mã……………………………………………………………………...11 1.3 Hệ mật mã khoá đối xứng…………………………………………………………………12 1.4 Hệ mật mã khoá công khai………………………………………………………………...13 1.5 Chữ ký số………………………………………………………………………………….17 1.6 Hàm băm…………………………………………………………………………………..21 CHƯƠNG 2 - CHỨNG KHAI........................24

THƯ

SỐ

VÀ

HẠ

TẦNG

MÃ

KHOÁ

CÔNG

2.1. Chứng thư số (digital certificates)………………………………………………………...25 2.1.1 Giới thiệu………………………………………………………………………………..25 2.1.2 Chứng thư khoá công khai X.509……………………………………………………….27 2.1.3 Thu hồi chứng thư……………………………………………………………………….31 2.1.4 Chính sách của chứng thư……………………………………………………………….32 2.1.5 Công bố và gửi thông báo thu hồi chứng thư…………………………………………...33 2.2 Các thành phần của PKI………………………………………………………………….36 2.2.1 Tổ chức chứng thực CA (Certification Authority)……………………………………...38 2.2.2 Trung tâm đăng ký RA (Registration Authorities)……………………………………...38 3

2.2.3 Thực thể cuối ( Người giữ chứng thư và Clients)………………………………………39 2.2.4 Hệ thống lưu trữ (Repositories)…………………………………………………………39 2.3 Chức năng cơ bản của PKI………………………………………………………………...40 2.3.1 Chứng thực (certification)………………………………………………………………40 2.3.2 Thẩm tra (validation)……………………………………………………………………40 2.3.3 Một số chức năng khác………………………………………………………………….41 2.4 Mô hình tin cậy cho PKI…………………………………………………………………...44 2.4.1 Mô hình CA đơn………………………………………………………………………..45 2.4.2 Mô hình phân cấp……………………………………………………………………….46 2.4.3 Mô hình mắt lưới (xác thực chéo)………………………………………………………47 2.4.4 Mô hình Hub và Spoke (Bridge CA)……………………………………………………49 2.4.5 Mô hình Web (Trust Lists)……………………………………………………………...49 2.4.6 Mô hình người sử dụng trung tâm (User Centric Model)………………………………51 CHƯƠNG 3 - PHƯƠNG ÁN THIẾT KẾ XÂY DỰNG HỆ THỐNG BIOPKI-OPENCA TRONG KHUÔN KHỔ ĐỀ TÀI KC.01.11…………………………………………………...53 3.1 Giới thiệu……………………………………………………………………………………53 3.1.1 Đề tài KC.01.11…………………………………………………………………………53 3.1.2 Sinh trắc học…………………………………………………………………………….54 a. Sinh trắc học là gì……………………………………………………………………...54 b. Các giải pháp tích hợp sinh trắc để bảo vệ khoá cá nhân……………………………..56 3.1.3 Tổng quan về hệ thống OpenCA……………………………………………………….58 3.1.3.1 Giới thiệu………………………………………………………………………...58 3.1.3.2 Đánh giá về hệ OpenCA…………………………………………………………59 3.1.4 Mục đích của hệ thống BK BioPKI-OpenCA…………………………………………..59 3.2 Thư viện OpenSSL………………………………………………………………………….60 4

3.3 Phương án thiết kế xây dựng hệ thống BioPKI-OpenCA………………………………..65 3.3.1 Mô hình hệ thống dự kiến………………………………………………………………65 3.3.2 Các thành phần và chức năng của hệ thống…………………………………………….66 3.3.3 Biểu đồ phân cấp chức năng…………………………………………………………….68 3.3.4 Xây dựng phương án về quy trình hệ thống BK-BioPKI-OpenCA…………………….74 CHƯƠNG 4 -PHÂN TÍCH THIẾT KẾ CÀI ĐẶT THÀNH PHẦN SETUP HỆ THỐNG BK-BIOPKI-OPENCA................................................................................................................78 4.1 Giới thiệu……………………………………………………………………………………78 4.2 Phân tích yêu cầu…………………………………………………………………………...78 4.3 Các chức năng cơ bản của Module Setup hệ thống……………………………………...79 4.4 Xây dựng kịch bản…………………………………………………………………………80 4.4.1 Setup CA Operator……………………………………………………………………..80 4.4.2 Setup RA……………………………………………………………………………….82 4.4.3 Setup LRA……………………………………………………………………………..85 4.4.4 Kịch bản khởi động……………………………………………………………………..86 CHƯƠNG 5 - THỬ NGHIỆM KỊCH BẢN ỨNG DỤNG TRONG HỆ THỐNG BIOPKIOPENCA………………………………………………………………………………………..88 5.1 Thiết kế kịch bản thử nghiệm ứng dụng chữ kí số……………………………………….89 5.2 Kết quả thử nghiệm………………………………………………………………………...94 KẾT LUẬN……………………………………………………………………………………..96 TÀI LIỆU THAM KHẢO……………………………………………………………………...97

LỜI CẢM ƠN 5

Tôi xin gửi lời cảm ơn chân thành nhất tới PGS TS Nguyễn Thị Hoàng Lan, người thầy đã cho tôi những định hướng và những ý kiến rất quý báu để tôi hoàn thành được đồ án tốt nghiệp này. Tôi xin tỏ lòng biết ơn sâu sắc tới các thầy cô, bạn bè cùng làm việc trong khuôn khổ đề tài KC01.11/06-10 đã dìu dắt, giúp đỡ tôi tiến bộ trong suốt quá trình làm đồ án tốt nghiệp. Xin cảm ơn gia đình và bè bạn, những người luôn khuyến khích và giúp đỡ tôi trong mọi hoàn cảnh khó khăn. Tôi xin cảm ơn bộ môn Truyền Thông và Mạng Máy Tính, khoa Công Nghệ Thông Tin trường Đại Học Bách Khoa Hà Nội đã hết sức tạo điều kiện cho tôi trong quá trình học và làm đồ án này.

TÓM TẮT ĐỒ ÁN 6

Đồ án này có tên “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”. Nội dung đồ án là nghiên cứu xây dựng nền tảng hệ thống BioPKI-OpenCA trong đó tập trung xây dựng phân hệ setup hệ thống và thử nghiệm một ứng dụng trên hệ thống BioPKI-OpenCA.

DANH MỤC TỪ VIẾT TẮT APKI

Architecture for Public-Key Infrastructure 7

CA

Certificate Authority

CRL

Certifiate Revocation List

DES

Data Encrytion Standard

DSA

Digital Signature Algorithm

DSS

Digital Signature Standard

IETF

Internet Engineering Task Force

LDAP

Lightweight Directory Access Protocol

MD2, 4,5

Message Digest 2,4,5

NIST

National Institute of Standards and Technology

NSA

National Security Agency

PEM

Privacy Enhanced Mail

PGP

Pretty Good Privacy

RA

Registration Authority

PKCS

Public Key Cryptography Standards

PKI

Public Key Infrastructure

PKIX

Public Key Infrastructure X.509 group

RFC

Request For Comments

RSA

Rivest Shamir Adleman

SCEP

Simple Certificate Enrollment Protocol

SET

Secure Electronic Transactions

SHA

Secure Hash Algorithm

SPKI

Simple Public Key Infrastructure

SSL

Secure Socket Layer

TSL

Transport Layer Security

DANH MỤC HÌNH VẼ

Hình 1.1: Quá trình mã hoá và giải mã 8

Hình 1.2: Mã hoá thông điệp sử dụng khoá công khai P Hình 1.3: Giải mã thông điệp sử dụng khoá cá nhân của người nhận Hình 1.4: Sơ đồ hệ mật mã RSA Hình 1.5: Mã hoá thông điệp sử dụng khoá cá nhân S để mã thông điệp và khoá công khai P để mã khoá cá nhân S Hình 1.6: Giải mã thông điệp sử dụng khoá cá nhân S để giải mã thông điệp và khoá cá nhân P để giải mã khoá cá nhân S Hình 1.7: Sơ đồ chữ ký RSA Hình 1.8: Sơ đồ mô tả các công đoạn người A làm trước khi gửi thông điệp cho người B (sử dụng hàm băm rồi ký số) Hình 1.9: Sơ đồ mô tả các công đoạn kiểm tra chữ ký sau khi người B nhận được thông điệp Hình 1.10: Nhiều thông điệp nguồn cho cùng 1 kết quả đích sau mã hoá/ ký số Hình 2.1: Chứng thư số Hình 2.2: Khuôn dạng chứng chỉ X.509 Hình 2.3: Nội dung chi tiết của chứng chỉ Hình 2.4: Khuôn dạng danh sách chứng chỉ bị thu hồi Hình 2.5: Dịch vụ kiểm tra online Hình 2.6: Các thành phần PKI Hình 2.7: Đường dẫn chứng chỉ chéo Hình 2.8: Mô hình CA đơn Hình 2.9: Mô hình phân cấp Hình 2.10: Mô hình mắt lưới Hình 2.11: Mô hình Hub và Spoke (Bridge CA) Hình 3.1: Các thuộc tính sinh trắc học khác nhau 9

Hình 3.2: Bảng so sánh các đặc trưng sinh trắc học theo A. K. Jain [2] (H - cao, M - trung bình, L - thấp) Hình 3.3: Các thành phần của hệ thống OpenCA Hình 3.4: Mô hình hệ thống BioPKI-OpenCA mức khung cảnh Hình 3.5: Biểu đồ phân cấp chức năng của CA Operator Hình 3.6: Biểu đồ phân cấp chức năng của RA Hình 3.7: Biểu đồ phân cấp chức năng của LRA Hình 4.1: Các chức năng của Module Setup Hệ Thống Hình 4.2: Biểu đồ diễn tiến quá trình Setup CA Operator Hình 4.3: Biểu đồ diễn tiến quá trình Setup RA Hình 4.4: Biểu đồ diễn tiến quá trình đăng ký một LRA Hình 4.5: Biểu đồ diễn tiến quá trình setup LRA Hình 4.6: Kịch bản khởi động cho các phân hệ trong hệ thống BioPKI 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 Hình 5.2: Biểu đồ diễn tiến quá trình kí Hình 5.3: Biểu đồ diễn tiến quá trình xác thực chữ kí 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

CHƯƠNG 1 LÝ THUYẾT TỔNG QUAN VỀ MẬT MÃ VÀ ỨNG DỤNG 10

1.1 Giới thiệu chung Mật mã đã được con người sử dụng từ lâu đời. Các hình thức mật mã sơ khai đã được tìm thấy từ khoảng bốn nghìn năm trước trong nền văn minh Ai Cập cổ đại. Trải qua hàng nghìn năm lịch sử, mật mã đã được sử dụng rộng rãi ở khắp nơi trên thế giới từ Đông sang Tây để giữ bí mật cho việc giao lưu thông tin trong nhiều lĩnh vực hoạt động giữa con người và các quốc gia, đặc biệt trong các lĩnh vực quân sự, chính trị, ngoại giao. Mật mã trước hết là một loại hoạt động thực tiễn, nội dung chính của nó là để giữ bí mật thông tin. Ví dụ muốn gửi một văn bản từ một người gửi A đến một người nhận B, A phải tạo cho văn bản đó một bản mã mật tương ứng và thay vì gửi văn bản rõ thì A chỉ gửi cho B bản mã mật, B nhận được bản mã mật và khôi phục lại văn bản rõ để hiểu được thông tin mà A muốn gửi cho mình. Do văn bản gửi đi thường được chuyển qua các con đường công khai nên người ngoài có thể “lấy trộm” được, nhưng vì đó là bản mật mã nên không đọc hiểu được. Còn A có thể tạo ra bản mã mật và B có thể giải bản mã mật thành bản rõ để hiểu được là do hai người đã có một thoả thuận về một chìa khoá chung, chỉ với khoá chung này thì A mới tạo được bản mã mật từ bản rõ và B mới khôi phục được bản rõ từ bản mã mật. Khoá chung đó được gọi là khoá mật mã. Để thực hiện được một phép mật mã, ta còn cần có một thuật toán biến bản rõ cùng với khoá mật mã thành bản mã mật và một thuật toán ngược lại biến bản mật cùng với khoá mật mã thành bản rõ. Các thuật toán đó được gọi tương ứng là thuật toán lập mã và thuật toán giải mã. Các thuật toán này thường không nhất thiết phải giữ bí mật, mà cái luôn cần được giữ bí mật là khoá mật mã. Trong thực tiễn, có những hoạt động ngược lại với hoạt động bảo mật là khám phá bí mật từ các bản mã “lấy trộm” được, hoạt động này thường được gọi là mã thám hay phá khoá [2].

1.2 Khái niệm hệ mật mã Hệ mật mã được định nghĩa là một bộ năm (P, C, K, E, D), trong đó: 1. P là tập hữu hạn các các bản rõ có thể 2. C tập hữu hạn các bản mã có thể 3. K là tập hữu hạn các khoá có thể 4. E là tập các hàm lập mã 5. D là tập các hàm giải mã. Với mỗi k ∈ K, có một hàm lập mã 11

ek ∈ E, ek : P → C và một hàm giải mã dk∈ D, dk: C → P sao cho dk(ek(x)) = x , ∀ x ∈ P

Hình 1.1: Quá trình mã hoá và giải mã

1.3 Hệ mật mã khoá đối xứng Các phương pháp mật mã cổ điển đã được biết đến từ khoảng 4000 năm trước. Một số kỹ thuật đã được những người Ai Cập sử dụng từ nhiều thế kỷ trước. Những kỹ thuật này chủ yếu sử dụng hai phương pháp chính là: phép thay thế và phép chuyển dịch. Trong phép thay thế, một chữ cái này được thay thế bởi chữ cái khác và trong phép chuyển dịch, các chữ cái được sắp xếp theo một trật tự khác. Hệ mã chuẩn DES được xây dựng tại Mỹ trong những năm 70 theo yêu cầu của Văn phòng quốc gia về chuẩn (NBS) và được sự thẩm định của an ninh quốc gia là một ví dụ về mật mã cổ điển. DES kết hợp cả hai phương pháp thay thế và chuyển dịch. DES thực hiện mã hoá trên từng khối bản rõ là một xâu 64 bit, có khoá là một xâu 56 bit và cho ra bản mã cũng là một xâu 64 bit. Hiện nay, DES và biến thể của nó (3DES) vẫn được sử dụng thành công trong nhiều ứng dụng. Trong các hệ mã đối xứng chỉ có một khoá được chia sẻ giữa các bên tham gia liên lạc. Cứ mỗi lần truyền tin bảo mật, cả người gửi A và người nhận B cùng thoả thuận trước với nhau một khoá chung K, sau đó người gửi dùng eK để lập mã cho thông báo gửi đi và người nhận 12

dùng dK để giải mã bản mật mã nhận được. Người gửi và người nhận có cùng một khoá chung K, được giữ bí mật dùng cho cả lập mã và giải mã. Những hệ mật mã cổ điển với cách sử dụng trên được gọi là mật mã khoá đối xứng hay còn gọi là mật mã khoá cá nhân. Độ an toàn của hệ mật mã đối xứng phụ thuộc vào khoá. Nếu để lộ khoá thì bất kỳ người nào cũng có thể mã hoá và giải mã thông điệp.

* Ưu và nhược điểm của hệ mật mã khoá đối xứng Ưu điểm nổi bật của các hệ mật mã khoá đối xứng là việc xây dựng một hệ mật mã có độ bảo mật cao khá dễ dàng về mặt lý thuyết. Nhưng như nếu không kể đến việc cần có một nguồn sinh khoá ngẫu nhiên thì việc phân phối, lưu trữ bảo mật và thoả thuận khoá là một vấn đề khó chấp nhận được trong mạng truyền thông ngày nay. Trong một mạng có n người dùng, nếu cần khoá cho từng cặp thì cần n(n+1)/2 khoá. Để khắc phục hiện tượng không thể lưu trữ một khối lượng khoá quá lớn đáp ứng được nhu cầu mã dịch, người ta xem xét đến việc sử dụng các hệ mật mã khối với độ dài không lớn lắm như DES… hoặc các hệ mật mã dòng mà khoá được sinh ra từ một nguồn giả ngẫu nhiên bằng thuật toán. Mặc dù đã thực hiện việc mã hoá và giải mã bằng các hệ mật mã khối hay bằng thuật toán sinh khoá như đã nêu ở trên thì vấn đề phân phối và thoả thuận khoá vẫn phải được thực hiện. Như vậy phân phối và thoả thuận khoá là một vấn đề chưa thể được giải quyết trong các hệ mật mã khoá đối xứng.

1.4 Hệ mật mã khoá công khai Để giải quyết vấn đề phân phối và thoả thuận khoá của mật mã khoá đối xứng, năm 1976 Diffie và Hellman đã đưa ra khái niệm về hệ mật mã khoá công khai và một phương pháp trao đổi công khai để tạo ra một khoá cá nhân chung mà tính an toàn được bảo đảm bởi độ khó của một bài toán toán học cụ thể (là bài toán tính “logarit rời rạc”). Hệ mật mã khoá công khai hay còn được gọi là hệ mật mã phi đối xứng sử dụng một cặp khoá, khoá mã hoá còn gọi là khoá công khai (public key) và khoá giải mã được gọi là khoá cá nhân hay khóa riêng (private 13

key). Trong hệ mật này, khoá mã hoá khác với khoá giải mã. Về mặt toán học thì từ khoá công rất khó tính được khoá cá nhân. Biết được khoá này không dễ dàng tìm được khoá kia. Khoá giải mã được giữ bí mật trong khi khoá mã hoá được công bố công khai. Một người bất kỳ có thể sử dụng khoá công khai để mã hoá tin tức, nhưng chỉ có người nào có đúng khoá giải mã mới có khả năng xem được bản rõ. Người gửi A sẽ mã hoá thông điệp bằng khóa công của người nhận và người nhận B sẽ giải mã thông điệp với khoá cá nhân tương ứng của mình. Quá trình này được mô tả trong hình 1.2 và 1.3.

Hình 1.2: Mã hoá thông điệp sử dụng khoá công khai P

14

Hình 1.3: Giải mã thông điệp sử dụng khoá cá nhân của người nhận

Có nhiều hệ thống khoá công khai được triển khai rộng rãi như hệ RSA, hệ ElGamal sử dụng giao thức trao đổi khoá Diffie-Hellman và nổi lên trong những năm gần đây là hệ đường cong Elliptic. Trong số các hệ mật mã trên thì hệ RSA là hệ được cộng đồng chuẩn quốc tế và công nghiệp chấp nhận rộng rãi trong việc thực thi mật mã khoá công khai. Hệ mật mã RSA, do Rivest, Shamir và Adleman [6] tìm ra, đã được công bố lần đầu tiên vào tháng 8 năm 1977 trên tạp chí Scientific American. Hệ mật mã RSA được sử dụng rộng rãi trong thực tiễn đặc biệt cho mục đích bảo mật và xác thực dữ liệu số. Tính bảo mật và an toàn của chúng được bảo đảm bằng độ phức tạp của một bài toán số học nổi tiếng là bài toán phân tích số nguyên thành các thừa số nguyên tố. Hệ mật mã RSA được mô tả như hình 1.4.

15

Hình 1.4: Sơ đồ hệ mật mã RSA Việc phát minh ra phương pháp mã công khai tạo ra một cuộc “cách mạng” trong công nghệ an toàn thông tin điện tử. Nhưng thực tiễn triễn khai cho thấy tốc độ mã hoá khối dữ liệu lớn bằng các thuật toán mã hoá công khai chậm hơn rất nhiều so với hệ mã hoá đối xứng. Ví dụ, để đạt được độ an toàn như các hệ mã đối xứng mạnh cùng thời, RSA đòi hỏi thời gian cho việc mã hoá một văn bản lâu hơn gấp hàng ngàn lần. Do đó, thay bằng việc mã hoá văn bản có kích thước lớn bằng lược đồ khoá công khai thì văn bản này sẽ được mã hoá bằng một hệ mã đối xứng có tốc độ cao như DES, IDEA,…sau đó khoá được sử dụng trong hệ mã đối xứng sẽ được mã hoá sử dụng mật mã khoá công khai. Phương pháp này rất khả thi trong việc mã và giải mã những văn bản có kích thước lớn như được mô tả trong hình 1.5 và 1.6.

16

Hình 1.5: Mã hoá thông điệp sử dụng khoá cá nhân S để mã thông điệp và khoá công khai P để mã khoá cá nhân S

Hình 1.6: Giải mã thông điệp sử dụng khoá cá nhân S để giải mã thông điệp và khoá cá nhân P để giải mã khoá cá nhân S

* Ưu và nhược điểm của hệ mật mã khoá công khai 17

Vấn đề còn tồn đọng của hệ mật mã khoá đối xứng được giải quyết nhờ hệ mật mã khoá công khai. Chính ưu điểm này đã thu hút nhiều trí tuệ vào việc đề xuất, đánh giá các hệ mật mã công khai. Nhưng do bản thân các hệ mật mã khoá công khai đều dựa vào các giả thiết liên quan đến các bài toán khó nên đa số các hệ mật mã này đều có tốc độ mã dịch không nhanh lắm. Chính nhược điểm này làm cho các hệ mật mã khoá công khai khó được dùng một cách độc lập. Một vấn đề nữa nảy sinh khi sử dụng các hệ mật mã khóa công khai là việc xác thực mà trong mô hình hệ mật mã đối xứng không đặt ra. Do các khoá mã công khai được công bố một cách công khai trên mạng cho nên việc đảm bảo rằng “khoá được công bố có đúng là của đối tượng cần liên lạc hay không?” là một kẽ hở có thể bị lợi dụng. Vấn đề xác thực này được giải quyết cũng chính bằng các hệ mật mã khoá công khai. Nhiều thủ tục xác thực đã được nghiên cứu và sử dụng như Kerberos, X.509… Một ưu điểm nữa của các hệ mật mã khoá công khai là các ứng dụng của nó trong lĩnh vực chữ ký số, cùng với các kết quả về hàm băm, thủ tục ký để bảo đảm tính toàn vẹn của một văn bản được giải quyết.

1.5 Chữ ký số Mật mã khoá công khai có thể được sử dụng theo nhiều cách khác nhau. Chữ ký số là một ví dụ minh chứng cho việc đảm bảo xác thực người dùng và toàn vẹn dữ liệu. Nếu người gửi A mã hoá thông điệp hay tài liệu với khoá cá nhân của mình thì bất kỳ ai cũng có thể giải mã thông điệp với khoá công của A. Do đó, người nhận có thể chắc chắn rằng thông điệp mình nhận chỉ có thể do A mã vì chỉ A mới có khoá cá nhân của mình. Quá trình mã hoá thông điệp với khoá cá nhân của người gửi gọi là quá trình “ký số”. Trong thực tế, quá trình ký số thường khó hơn. Thay bằng việc mã bản thông điệp gốc với khoá cá nhân của người gửi thì chỉ có bản đại diện thông điệp (bản băm) có độ dài cố định được mã hoá với khoá cá nhân của người gửi và bản băm đã được mã hoá này được gắn vào với thông điệp gốc. Người nhận B sau khi nhận được thông điệp đầu tiên sẽ giải mã bản băm với khoá công của người gửi, sau đó băm thông điệp đi kèm bằng thuật toán băm tương ứng với thuật toán băm người gửi đã sử dụng. B so sánh hai giá trị băm nếu giống nhau thì chắc chắn rằng thông điệp A gửi cho B còn nguyên vẹn, đồng thời xác thực được người gửi thông tin là ai. 18

Tính toàn vẹn của thông điệp được đảm bảo vì chỉ thay đổi một bit trong thông điệp gửi đi thì kết quả hai giá trị băm sẽ khác nhau. Tính xác thực của người gửi cũng được đảm bảo vì chỉ có người gửi A mới có khoá cá nhân để mã bản băm. Chữ ký số cũng chứng minh được tính chống chối bỏ bản gốc vì chỉ có A mới có khoá cá nhân dùng để ký số. Sơ đồ chữ ký được định nghĩa như sau: Sơ đồ chữ ký là một bộ năm (P, A, K, S, V), trong đó: 1. P là một tập hữu hạn các văn bản có thể 2. A là một tập hữu hạn các chữ ký có thể 3. K là một tập hữu hạn các khoá có thể 4. S là tập các thuật toán ký 5. V là tập các thuật toán kiểm thử 6. Với mỗi k ∈ K, có một thuật toán ký sig k ∈ S, sig k: P → A và một thuật toán kiểm thử ver k ∈ V, ver k: P x A → {đúng, sai}, thoả mãn điều kiện sau đây với mọi x ∈ P, y ∈ A:

RSA cũng là thuật toán được dùng nhiều cho mục đích ký số. Sơ đồ chữ ký RSA được mô tả như trong hình 1.7 [3]. Ngoài ra, còn có một số thuật toán công khai khác được dùng để ký số, ví dụ như chuẩn chữ ký số DSS. Cho n = p*q với p,q là số nguyên tố lớn . Đặt P = A = Zn K = {(n, p, q, a, b)/ n = p*q, a*b ≡ 1 mod φ(n)} trong đó (n,b) là công khai, (a, p, q) là bí mật Với mỗi K = (n, p, q, a, b), mỗi x ∈ P, ta định nghĩa: y = sigK (x) = xa mod n, y ∈ A 19

verK (x, y) = đúng ⇔ x ≡ yb mod n

Hình 1.7: Sơ đồ chữ ký RSA Quá trình ký và kiểm tra chữ ký được mô tả trong hình 1.8 và hình 1.9 Giả sử A muốn gửi cho B thông điệp x. A thực hiện các bước sau: 1. A băm thông điệp x (Hình 1.8 a), thu được bản đại diện z = h(x) – có kích thước cố định 128 bit hoặc 160 bit. 2. A ký số trên bản đại diện z (Hình 1.8 b), bằng khóa bí mật của mình, thu được bản ký số y = sigK (z). 3. A gửi (x, y) cho B (Hình 1.8 c).

Hình 1.8 a: Băm thông điệp.

20

Hình 1.8 b: Ký trên bản băm.

Hình 1.8 c: Truyền dữ liệu thông tin cần gửi. Hình 1.8: Sơ đồ mô tả các công đoạn người A làm trước khi gửi thông điệp cho người B (sử dụng hàm băm rồi ký số) Khi B nhận được (x, y). B thực hiện các bước sau: 1. B kiểm tra chữ ký số để xác minh xem thông điệp mà mình nhận được có phải được gửi từ A hay không bằng cách giải mã chữ ký số y, bằng khóa công khai của A, được z. (Hình 1.9 a) 2. B dùng một thuật toán băm – tương ứng với thuật toán băm mà A dùng – để băm thông điệp x đi kèm, nhận được h(x). (Hình 1.9 b) 3. B so sánh 2 giá trị băm z và h(x), nếu giống nhau thì chắc chắn rằng thông điệp x – mà A muốn gửi cho B – còn nguyên vẹn, bên cạnh đó cũng xác thực được người gửi thông tin là ai. (Hình 1.9 c) 21

Hình 1.9 a: Xác minh chữ ký.

Hình 1.9 b: Tiến hành băm thông điệp x đi kèm.

Hình 1.9 c: Kiểm tra tính toàn vẹn của thông điệp Hình 1.9: Sơ đồ mô tả các công đoạn kiểm tra chữ ký sau khi người B nhận được thông điệp 22

1.6 Hàm băm Việc sử dụng các hệ mật mã và sơ đồ chữ ký số thường là mã hóa và ký số trên từng bit của thông tin, thời gian để mã hóa và ký sẽ tỷ lệ thuận với dung lượng của thông tin. Thêm vào đó có thể xảy ra trường hợp: với nhiều bức thông điệp đầu vào khác nhau, sử dụng hệ mật mã, sơ đồ ký số giống nhau (có thể khác nhau) thì cho ra kết quả bản mã, bản ký số giống nhau (ánh xạ N-1: nhiều – một), như hình 1.10. Điều này sẽ dẫn đến một số rắc rối về sau cho việc xác thực thông tin.

Hình 1.10: Nhiều thông điệp nguồn cho cùng 1 kết quả đích sau mã hoá/ ký số Các sơ đồ ký số thường chỉ được sử dụng để ký các bức thông điệp (thông tin) có kích thước nhỏ và sau khi ký, bản ký số có kích thước gấp đôi bản thông điệp gốc – ví dụ với sơ đồ chữ ký chuẩn DSS ký trên các bức thông điệp có kích thước 160 bit, bản ký số sẽ có kích thước 320 bit. Trong khi đó trên thực tế, ta cần phải ký các thông điệp có kích thước lớn hơn nhiều, chẳng hạn vài chục MegaByte. Hơn nữa, để đáp ứng yêu cầu xác thực sau khi thông tin đến người nhận, dữ liệu truyền qua mạng không chỉ là bản thông điệp gốc, mà còn bao gồm cả bản ký số (có dung lượng gấp đôi dung lượng bản thông điệp gốc). Một cách đơn giản để giải quyết vấn đề trên (với thông điệp có kích thước lớn) này là chặt thông điệp thành nhiều đoạn 160 bit, sau đó ký lên các 23

đoạn đó độc lập nhau. Nhưng, sử dụng biện pháp này sẽ có một số vấn đề gặp phải trong việc tạo ra các chữ ký số: - Thứ nhất: với một thông điệp có kích thước a, thì sau khi ký kích thước của chữ ký sẽ là 2a (trong trường hợp sử dụng DSS). - Thứ hai: với các chữ ký “an toàn” thì tốc độ chậm vì chúng dùng nhiều phép tính số học phức tạp như số mũ modulo. - Thứ ba: vấn đề nghiêm trọng hơn đó là kết quả sau khi ký, nội dung của thông điệp có thể bị xáo trộn các đoạn với nhau, hoặc một số đoạn trong chúng có thể bị mất mát, trong khi người nhận cần phải xác minh lại thông điệp. Do đó, ta cần phải bảo đảm tính toàn vẹn của thông điệp. Giải pháp cho các vấn đề vướng mắc đến chữ ký số là dùng hàm băm để trợ giúp cho việc ký số. Hàm băm - hiểu theo một nghĩa đơn giản là hàm cho tương ứng một mảng dữ liệu lớn với một mảng dữ liệu nhỏ hơn - được sử dụng rộng rãi trong nhiều ứng dụng khác nhau của tin học, không chỉ thuộc phạm vi mật mã học [1]. Hàm băm được đề cập đến trong phạm vi đồ án là hàm băm một chiều, có tác dụng trợ giúp cho các sơ đồ ký số nhằm làm giảm dung lượng của dữ liệu cần thiết để truyền qua mạng. Hàm băm ở đây được hiểu là các thuật toán không sử dụng khoá để mã hóa (ở đây ta dùng thuật ngữ “băm” thay cho “mã hoá”), nó có nhiệm vụ băm thông điệp được đưa vào theo một thuật toán h một chiều nào đó, rồi đưa ra một bản băm – văn bản đại diện – có kích thước cố định. Giá trị của hàm băm là duy nhất và không thể suy ngược lại được nội dung thông điệp từ giá trị băm này. Hàm băm một chiều h có một số đặc tính quan trọng sau: nhất.

- Với thông điệp đầu vào x thu được bản băm z = h(x) là duy

- Nếu dữ liệu trong thông điệp x thay đổi hay bị xóa để thành thông điệp x’ thì h(x’) ≠ h(x). Cho dù chỉ là một sự thay đổi nhỏ hay chỉ là xóa đi 1 bit dữ liệu của thông điệp thì giá trị băm cũng vẫn thay đổi. Điều này có nghĩa là: hai thông điệp hoàn toàn khác nhau thì giá trị hàm băm cũng khác nhau. 24

- Nội dung của thông điệp gốc không thể bị suy ra từ giá trị hàm băm. Nghĩa là với thông điệp x thì dễ dàng tính được z = h(x), nhưng lại không thể (thực chất là khó) suy ngược lại được x nếu chỉ biết giá trị hàm băm h(x). Một số thuật toán băm được biết đến nhiều là hàm băm dòng và hàm băm chuẩn như: [MD2], [MD4], [MD5], [SHA-1]…

CHƯƠNG 2 CHỨNG CHỈ SỐ VÀ HẠ TẦNG KHOÁ CÔNG KHAI Mật mã khoá công khai cho đến nay được xem là giải pháp tốt nhất để đảm bảo được các yêu cầu về an toàn thông tin mạng: “bảo mật”, “toàn vẹn”, “xác thực” và “chống chối bỏ”. Mặc dù vẫn còn mới khi so sánh với các phương pháp mã cổ điển nhưng mật mã khoá công khai đã nhận được sự tin cậy rộng rãi của thế giới Internet vì những công cụ có khả năng phát triển cho vấn đề quản lý khoá. Như đã đề cập ở trên, vấn đề chính của hệ mã khoá đối xứng là vấn đề quản lý khoá và để giải quyết vấn đề này hệ mã khoá công khai đã được đưa ra như một giải pháp. Trong hệ thống mật mã khoá công khai, khoá cá nhân (khoá cá nhân) được người dùng giữ bí mật trong khi khoá công khai với tên của người sở hữu tương ứng lại được công bố công khai. Đối với hệ thống như thế này, ta cần xác định và trả lời một số câu hỏi như: - Ai sẽ tạo ra cặp khoá công khai – bí mật?

25

- Dữ liệu sẽ được lưu dưới định dạng như thế nào trong hệ thống lưu trữ (khoá công, định danh của người sở hữu và các thông tin khác)? - Có cơ chế nào để giữ cho thông tin không bị thay đổi trên hệ thống lưu trữ? - Làm thế nào để đảm bảo việc gắn kết giữa khoá công và định danh của thực thể yêu cầu có khoá công? - Làm thế nào để người sử dụng có thể truy cập được đến nơi lưu trữ? - Làm thế nào người sử dụng nhận biết được có sự thay đổi trong dữ liệu đang được lưu trên hệ thống lưu trữ? - Điều gì sẽ xảy với khoá công khai nếu khoá cá nhân tương ứng bị xâm hại? - Có một chính sách nào cho tất cả những vấn đề nêu trên không? Để trả lời cho những câu hỏi trên có một giải pháp là sử dụng hạ tầng khoá công khai - PKI. Cho đến nay có nhiều định nghĩa về PKI, nhưng chưa định nghĩa nào được công nhận chính thức. Có một số định nghĩa về PKI như sau: “PKI là một tập các phần cứng, phần mềm, con người, chính sách và các thủ tục cần thiết để tạo, quản lý, lưu trữ, phân phối và thu hồi chứng thư khoá công khai dựa trên mật mã khoá công khai”[14]. “PKI là hạ tầng cơ sở có thể hỗ trợ quản lý khoá công khai để hỗ trợ các dịch vụ xác thực, mã hoá, toàn vẹn hay chống chối bỏ” [7]. “PKI là hạ tầng cơ sở bảo mật có những dịch vụ được triển khai và chuyển giao sử dụng công nghệ và khái niệm khoá công khai” [4]. Nhìn chung, PKI có thể được định nghĩa như một hạ tầng cơ sở sử dụng công nghệ thông tin để cung cấp dịch vụ mã hoá khoá công khai và chữ ký số. Một mục đích quan trọng khác của PKI là để quản lý khoá và chứng thư được sử dụng trong hệ thống. Chứng thư là cấu trúc dữ liệu đặc biệt, gắn kết khoá công khai với chủ sở hữu của nó. Việc gắn kết này được đảm bảo bằng chữ ký số của nơi được uỷ quyền cấp chứng thư.

2.1. Chứng thư số (digital certificates) 26

2.1.1 Giới thiệu Như đã nói đến ở trên, mật mã khoá công khai sử dụng hai khoá khác nhau (khoá công và khoá cá nhân) để đảm bảo yêu cầu “bí mật, xác thực, toàn vẹn và chống chối bỏ ” của những dịch vụ an toàn. Một đặc tính quan trọng khác của lược đồ khoá công khai là phần khoá công khai được phân phối một cách tự do. Ngoài ra, trong hạ tầng mã khoá công khai thì khoá công ngoài việc phải luôn sẵn có để mọi người trong hệ thống có thể sử dụng còn phải được đảm bảo về tính toàn vẹn. Khoá công được đặt ở vị trí công khai trong một định dạng đặc biệt. Định dạng này được gọi là chứng thư. Chứng thư (thực ra là chứng thư khoá công – public key certificate (PKC)) là sự gắn kết giữa khoá công của thực thể và một hoặc nhiều thuộc tính liên quan đến thực thể [5]. Thực thể có thể là người, thiết bị phần cứng như máy tính, router hay một phần mềm xử lý. Một chứng thư khoá công (PKC) được người cấp ký bằng chữ ký có hiệu lực đưa ra một bảo bảm đầy đủ về sự gắn kết giữa khoá công, thực thể sở hữu khoá công này và tập các thuộc tính khác được viết trong chứng thư. PKC còn được gọi là “digital certificate”- chứng thư số, “digital ID”, hay đơn giản là chứng thư. Hình 2.1 minh hoạ một chứng thư số.

27

Hình 2.1: Chứng thư số Chứng thư chứa những thông tin cần thiết như khóa công khai, chủ thể (người sở hữu) khoá công, người cấp và một số thông tin khác. Tính hợp lệ của các thông tin được đảm bảo bằng chữ ký số của người cấp chứng thư. Người nào muốn sử dụng chứng thư trước hết sẽ kiểm tra chữ ký số trong chứng thư. Nếu đó là chữ ký hợp lệ thì sau đó có thể sử dụng chứng thư theo mục đích mong muốn. Có nhiều loại chứng thư, một trong số đó là: - Chứng thư khoá công khai X.509 - Chứng thư khoá công khai đơn giản (Simple Public Key Certificates - SPKC) - Chứng thư Pretty Good Privacy (PGP) - Chứng thư thuộc tính (Attribute Certificates - AC) 28

Tất cả các loại chứng thư này đều có cấu trúc định dạng riêng. Hiện nay chứng thư khoá công khai X.509 được sử dụng phổ biến trong hầu hết các hệ thống PKI. Hệ thống chương trình cấp chứng thư số thử nghiệm cũng sử dụng định dạng chứng thư theo X.509, nên đồ án này tập trung vào xem xét chi tiết chứng thư công khai X.509. Trong đồ án, thuật ngữ chứng thư “certificate” được sử dụng đồng nghĩa với chứng thư khoá công khai X.509 v3. 2.1.2 Chứng thư khoá công khai X.509 Chứng thư X.509 v3 là định dạng chứng thư được sử dụng phổ biến và được hầu hết các nhà cung cấp sản phẩm PKI triển khai. Chứng thư khoá công khai X.509 được Hội viễn thông quốc tế (ITU) đưa ra lần đầu tiên năm 1988 như là một bộ phận của dịch vụ thư mục X.500. Chứng thư gồm 2 phần. Phần đầu là những trường cơ bản cần thiết phải có trong chứng thư. Phần thứ hai chứa thêm một số trường phụ, những trường phụ này được gọi là trường mở rộng dùng để xác định và đáp ứng những yêu cầu bổ sung của hệ thống. Khuôn dạng của chứng thư X.509 được chỉ ra như trong hình 2.2.

29

Hình 2.2: Khuôn dạng chứng thư X.509 a. Những trường cơ bản của chứng thư X.509

- Version: xác định số phiên bản của chứng thư. - Certificate Serial Number: do CA gán, là định danh duy nhất của chứng thư. - Signature Algorithm ID: chỉ ra thuật toán CA sử dụng để ký số chứng thư. Có thể là thuật toán RSA hay DSA… - Issuer: chỉ ra CA cấp và ký chứng thư. - Validity Period: khoảng thời gian chứng thư có hiệu lực. Trường này xác định thời gian chứng thư bắt đầu có hiệu lực và thời điểm hết hạn. - Subject: xác định thực thể mà khoá công khai của thực thể này được xác nhận. Tên của subject phải duy nhất đối với mỗi thực thể CA xác nhận. 30

- Subject public key information: chứa khoá công khai và

những tham số liên quan; xác định thuật toán (ví dụ RSA hay DSA) được sử dụng cùng với khoá. - Issuer Unique ID (Optional): là trường không bắt buộc, trường này cho phép sử dụng lại tên người cấp. Trường này hiếm được sử dụng trong triển khai thực tế. - Subject Unique ID (Optional): là trường tuỳ chọn cho phép sử dụng lại tên của subject khi quá hạn. Trường này cũng ít được sử dụng. - Extensions (Optional): chỉ có trong chứng thư v.3. - Certification Authority’s Digital Signature: chữ ký số của CA được tính từ những thông tin trên chứng thư với khoá cá nhân và thuật toán ký số được chỉ ra trong trường Signature Algorithm Identifier của chứng thư. Tính toàn vẹn của chứng thư được đảm bảo bằng chữ ký số của CA trên chứng thư. Khoá công khai của CA được phân phối đến người sử dụng chứng thư theo một số cơ chế bảo mật trước khi thực hiện các thao tác PKI. Người sử dụng kiểm tra hiệu lực của chứng thư được cấp với chữ ký số của CA và khoá công khai của CA. b. Những trường mở rộng của chứng thư X.509 Phần mở rộng là những thông tin về các thuộc tính cần thiết được đưa vào để gắn những thuộc tính này với người sử dụng hay khoá công. Những thông tin trong phần mở rộng thường được dùng để quản lý xác thực phân cấp, chính sách chứng thư, thông tin về chứng thư bị thu hồi…Nó cũng có thể được sử dụng để định nghĩa phần mở rộng riêng chứa những thông tin đặc trưng cho cộng đồng nhất định. Mỗi trường mở rộng trong chứng thư được thiết kế với cờ “critical” hoặc “uncritical”. - Authority Key Indentifier: chứa ID khoá công khai của CA, ID này là duy nhất và được dùng để kiểm tra chữ ký số trên chứng thư. Nó cũng được sử dụng để phân biệt giữa các cặp khoá do một CA sử dụng (trong trường hợp nếu CA có nhiều hơn một khoá công khai). Trường này được sử dụng cho tất cả các chứng thư tự ký số (CA - certificates). - Subject Key Identifier: chứa ID khoá công khai có trong chứng thư và được sử dụng để phân biệt giữa các khoá nếu như có nhiều khoá được gắn vào trong cùng chứng thư của người sử dụng (Nếu chủ thể có nhiều hơn một khoá công khai). 31

- Key Usage: chứa một chuỗi bit được sử dụng để xác định (hoặc hạn chế) chức năng hoặc dịch vụ được hỗ trợ qua việc sử dụng khoá công khai trong chứng thư. - Extended Key Usage: chứa một hoặc nhiều OIDs (định danh đối tượng – Object Identifier) để xác định cụ thể việc sử dụng khoá công trong chứng thư. Các giá trị có thể là : (1) xác thực server TLS, (2) xác thực client TLS, (3) Ký Mã, (4) bảo mật e-mail , (5) Tem thời gian. - CRL Distribution Point: chỉ ra vị trí của CRL tức là nơi hiện có thông tin thu hồi chứng thư. Nó có thể là URI (Uniform Resource Indicator), địa chỉ của X.500 hoặc LDAP server. - Private Key Usage Period: trường này cho biết thời gian sử dụng của khoá cá nhân gắn với khóa công khai trong chứng thư. - Certificate Policies: trường này chỉ ra dãy các chính sách OIDs gắn với việc cấp và sử dụng chứng thư. - Policy Mappings: trường này chỉ ra chính sách xác thực tương đương giữa hai miền CA. Nó được sử dụng trong việc thiết lập xác thực chéo và kiểm tra đường dẫn chứng thư. Trường này chỉ có trong chứng thư CA. - Subject Alternative Name: chỉ ra những dạng tên lựa chọn gắn với người sở hữu chứng thư. Những giá trị có thể là: địa chỉ e-mail, địa chỉ IP, địa chỉ URI… - Issuer Alternative Name: chỉ ra những dạng tên lựa chọn gắn với người cấp chứng thư. - Subject Directory Attributes: trường này chỉ ra dãy các thuộc tính gắn với người sở hữu chứng thư. Trường mở rộng này không được sử dụng rộng rãi. Nó được dùng để chứa những thông tin liên quan đến đặc quyền. - Basic Constraints Field: trường này cho biết đây có phải là chứng thư CA hay không bằng cách thiết lập giá trị logic (true). Trường này chỉ có trong chứng thư CA. Chứng thư CA dùng để thực hiện một số chức năng. Chứng thư này có thể ở một trong hai dạng. Nếu CA tạo ra chứng thư để tự sử dụng, chứng thư này được gọi là chứng thư CA tự ký. Khi một CA mới được thiết lập, CA tạo ra một chứng thư CA tự ký để ký lên chứng thư của người sử dụng cuối trong hệ thống. Và dạng thứ hai là CA cấp chứng thư cho những CA khác trong hệ thống. - Path Length Constraint: trường này chỉ ra số độ dài tối đa của đường dẫn chứng thư có thể được thiết lập. Giá trị “zero” chỉ ra rằng CA chỉ có thể cấp chứng thư cho thực thể cuối , không cấp chứng thư cho những CA khác. (Trường này chỉ có trong chứng thư của CA). - Name Constrainsts: được dùng để bao gồm hoặc loại trừ các nhánh trong những miền khác nhau trong khi thiết lập môi trường tin tưởng giữa các miền PKI. 32

- Policy Constraints: được dùng để bao gồm hoặc loại trừ một số chính sách chứng thư trong khi thiết lập môi trường tin tưởng giữa các miền PKI.

Hình 2.3 là nội dung chi tiết một chứng thư do hệ thống OpenCA cấp.

33

Hình 2.3: Nội dung chi tiết của chứng thư 2.1.3 Thu hồi chứng thư Trong một số trường hợp như khoá bị xâm hại, hoặc người sở hữu chứng thư thay đổi vị trí, cơ quan…thì chứng thư đã được cấp không có hiệu lực. Do đó, cần phải có một cơ chế cho phép người sử dụng chứng thư kiểm tra được trạng thái thu hồi chứng thư. X.509 cho phép kiểm tra chứng thư trong các trường hợp sau:

- Chứng thư không bị thu hồi - Chứng thư đã bị CA cấp thu hồi - Chứng thư do một tổ chức có thẩm quyền mà CA uỷ thác có

trách nhiệm thu hồi chứng thư thu hồi

34

Cơ chế thu hồi X.509 xác định là sử dụng danh sách thu hồi chứng thư (CRLs). X.509 đưa ra sự phân biệt giữa ngày, thời gian chứng thư bị CA thu hồi và ngày, thời gian trạng thái thu hồi được công bố đầu tiên. Ngày thu hồi thực sự được ghi cùng với đầu vào chứng thư trong CRL. Ngày thông báo thu hồi được xác định trong header của CRL khi nó được công bố. Vị trí của thông tin thu hồi có thể khác nhau tuỳ theo CA khác nhau. Bản thân chứng thư có thể chứa con trỏ đến nơi thông tin thu hồi được xác định vị trí. Người sử dụng chứng thư có thể biết thư mục, kho lưu trữ hay cơ chế để lấy được thông tin thu hồi dựa trên những thông tin cấu hình được thiết lập trong quá trình khởi sinh. Để duy trì tính nhất quán và khả năng kiểm tra, CA yêu cầu: - Duy trì bản ghi kiểm tra chứng thư thu hồi - Cung cấp thông tin trạng thái thu hồi - Công bố CRLs khi CRL là danh sách trống 2.1.4 Chính sách của chứng thư Như được giới thiệu trong phần trên, một số mở rộng liên quan đến chính sách có trong chứng thư. Những mở rộng liên quan đến chính sách này được sử dụng trong khi thiết lập xác thực chéo giữa các miền PKI. Một chính sách chứng thư trong X.509 được định nghĩa là “tên của tập các qui tắc chỉ ra khả năng có thể sử dụng của chứng thư cho một tập thể đặc thù và một lớp ứng dụng với những yêu cầu bảo mật chung” [7]. Chính sách có định danh duy nhất (được biết đến như định danh đối tượng hay OID) và định danh này được đăng ký để người cấp và người sử dụng chứng thư có thể nhận ra và tham chiếu đến. Một chứng thư có thể được cấp theo nhiều chính sách. Một số có thể là thủ tục và mô tả mức đảm bảo gắn với việc tạo và quản lý chứng thư. Những chính sách khác có thể là kỹ thuật và mô tả mức đảm bảo gắn với an toàn của hệ thống được sử dụng để tạo chứng thư hay nơi lưu trữ khoá [6]. Một chính sách chứng thư cũng có thể được hiểu là việc giải thích những yêu cầu và giới hạn liên quan đến việc sử dụng chứng thư được công bố theo những chính sách này. Chính sách chứng thư - Certificate Policies (CP) được chứa trong trường mở rộng chuẩn của chứng thư X.509. Bằng việc kiểm tra trường này trong chứng thư, hệ thống sử 35

dụng chứng thư có thể xác định được một chứng thư cụ thể có thích hợp cho mục đích sử dụng hay không. Một thuật ngữ chuyên môn khác “Certificate Practice Statement (CPS)” được sử dụng để mô tả chi tiết những thủ tục hoạt động bên trong của CA và PKI cấp chứng thư với chính sách chứng thư đã qui định. Chính sách chứng thư đặc biệt quan trọng khi đưa ra quyết định để xác nhận chéo hai PKI khác nhau. 2.1.5 Công bố và gửi thông báo thu hồi chứng thư Thông thường chứng thư sẽ hợp lệ trong khoảng thời gian có hiệu lực. Nhưng trong một số trường hợp chứng thư lại không hợp lệ trước thời gian hết hạn, ví dụ như:

- Khoá cá nhân của chủ thể bị xâm phạm . - Thông tin chứa trong chứng thư bị thay đổi - Khoá cá nhân của CA cấp chứng thư bị xâm phạm Trong những trường hợp này cần có một cơ chế để thông báo đến những người sử dụng khác Một trong những phương pháp để thông báo đến người sử dụng về trạng thái của chứng thư là công bố CRLs định kỳ hoặc khi cần thiết. Ngoài ra, có một số cách lựa chọn khác để thông báo đến người sử dụng như dùng phương pháp trực tuyến Online Certificate Status Protocol [10]. a. Certificate Revocation Lists (CRLs) CRLs là cấu trúc dữ liệu được ký như chứng thư người sử dụng. CRLs chứa danh sách các chứng thư đã bị thu hồi và những thông tin cần thiết khác của người sử dụng. CRL thường do một CA cấp. Tuy nhiên CRL cũng có thể được sử dụng để cung cấp thông tin cho nhiều CA nếu nó được định nghĩa như một CRL gián tiếp. Những thông tin này được chứa trong trường mở rộng CRL Scope.

36

Hình 2.4 là khuôn dạng danh sách chứng thư bị thu hồi.

37

Hình 2.4: Khuôn dạng danh sách chứng thư bị thu hồi Trong đó: - Version number: chỉ ra phiên bản của CRL. - Signature: nhận biết loại hàm băm và thuật toán ký được sử dụng để ký danh sách thu hồi CRL. - Issuer: tên của thực thể cấp và ký CRL. - This Update: chỉ ra ngày và thời gian CRL được công bố. - Next Update: chỉ ra ngày và thời gian danh sách thu hồi kế tiếp được cấp. 38

- List of revoked certificates: chứa danh sách cùng với serial

của những chứng thư bị thu hồi.

Những chứng thư đã bị CA thu hồi được ghi vào danh sách theo thứ tự của revoked Certificates. Mỗi đầu vào nhận biết chứng thư thông qua số serial và ngày thu hồi trên đó có ghi rõ thời gian và ngày khi chứng thư bị CA thu hồi. b. Authority Revocation List (ARLs) ARL là một CRL đặc biệt chứa thông tin thu hồi về chứng thư CA. ARLs không chứa chứng thư của người sử dụng cuối. Những thay đổi thông thường trong ARL thường hiếm khi xảy ra bởi vì chứng thư của CA chỉ bị thu hồi khi khoá cá nhân của CA bị xâm hại và đó lại là trường hợp không thường xảy ra. Nếu chứng thư chéo bị thu hồi thì người cấp chứng thư chéo này sẽ công bố một ARL mới để thông báo với tất cả các thực thể khác về tình huống này. ARLs được sử dụng chủ yếu trong quá trình thẩm tra đường dẫn chứng thư nếu môi trường tin cậy bao gồm CA có chứng thư xác thực chéo. c. Cơ chế truy vấn On-line (On-line Query Mechanisms) CRLs và ARLs giúp người sử dụng cuối nhận biết được về tình trạng thu hồi chứng thư. Nhưng có một vấn đề nảy sinh là điều gì sẽ xảy ra nếu CA thu hồi chứng thư ngay sau khi vừa công bố CRL. Không có người sử dụng nào nhận biết được về việc thu hồi này đến khi một CRL mới được thông báo. Một lược đồ khác để kiểm soát được trạng thái của chứng thư do IETF phát triển là OCSP (Online Certificate Status Protocol). Lược đồ này dựa trên cơ chế truy vấn trực tiếp hơn việc công bố định kỳ CRLs và ARLs. OCSP là giao thức yêu cầu/ trả lời đưa ra cơ chế để nhận được thông tin thu hồi trực tuyến từ thực thể tin cậy là “OCSP Responder”. Người sử dụng cuối thực hiện yêu cầu với “OCSP Request” với một danh sách các chứng thư cần được kiểm tra, OCSP Responder trả lời yêu cầu “OCSP Reply” với trạng thái của mỗi chứng thư. Chứng thư có thể ở một trong ba trạng thái sau: “good”, “revoked” và “unknown”. Sử dụng dịch vụ online có một số ưu điểm sau: - Trả lời thường xuyên và luôn có tính chất mới - Thời gian trả lời nhanh 39

- Giảm thiểu việc sử dụng băng thông mạng sẵn có - Tổng phí xử lý phía client thấp

Tuy nhiên dịch vụ online có hạn chế trong trường hợp cần kiểm tra trạng thái thu hồi nhưng không online .Vấn đề về bảo mật cũng được đặt ra khi sử dụng dịch vụ này. Hình 2.5 là dịch vụ kiểm tra online với OCSP Responder là dịch vụ khác nhau.

Hình 2.5: Dịch vụ kiểm tra online

2.2 Các thành phần của PKI Một hệ thống PKI gồm 4 thành phần sau: - Certification Authorities (CA) ♦Cấp và thu hồi chứng thư. - Registration Authorities (RA) ♦Gắn kết giữa khoá công khai và định danh của người giữ chứng thư. - Clients ♦Người sử dụng chứng thư PKI hay theo cách khác được xác định như 40

những thực thể cuối. ♦Người sử dụng cuối hoặc hệ thống là chủ thể của chứng thư PKI. - Repository ♦Hệ thống (có thể phân tán) lưu trữ chứng thư và danh sách các chứng thư bị thu hồi. ♦Cung cấp cơ chế phân phối chứng thư và CRLs đến các thực thể cuối.

Các thành phần PKI và các mối quan hệ giữa chúng được chỉ ra như trong hình 2.6. Đây là mô hình kiến trúc PKI do PKIX đưa ra [7].

Hình 2.6: Các thành phần PKI

41

2.2.1 Tổ chức chứng thực (Certification Authority) Trong hạ tầng cơ sở khoá công khai, chứng thư có vai trò gắn kết giữa định danh với khoá công. Sự gắn kết này thể hiện trong dạng cấu trúc dữ liệu được ký số được đề cập đến như chứng thư đã được thảo luận ở phần trước. Một certificate authority (CA) là một thực thể PKI có trách nhiệm cấp chứng thư cho các thực thể khác trong hệ thống. Tổ chức chứng thực - CA cũng được gọi là bên thứ ba được tin tưởng vì người sử dụng cuối tin tưởng vào chữ ký số của CA trên chứng thư trong khi thực hiện những hoạt động mã hoá khoá công khai cần thiết. Tổ chức cung cấp dịch vụ chứng thực – Certification Service Provider (CSP) là một thuật ngữ khác nhắc đến CA được sử dụng trong đồ án. Thông thường, CA thực hiện chức năng xác thực bằng cách cấp chứng thư cho các CA khác và cho thực thể cuối (người giữ chứng thư) trong hệ thống. Nếu CA nằm ở đỉnh của mô hình phân cấp PKI và chỉ cấp chứng thư cho những CA ở mức thấp hơn thì chứng thư này được gọi là chứng thư gốc “root certificate”. 2.2.2 Trung tâm đăng ký (Registration Authorities) Mặc dù CA có thể thực hiện những chức năng đăng ký cần thiết, nhưng đôi khi cần có thực thể độc lập thực hiện chức năng này. Thực thể này được gọi là “registration authority” - trung tâm đăng ký. Ví dụ khi số lượng thực thể cuối trong miền PKI tăng lên và số thực thể cuối này được phân tán khắp nơi về mặt địa lý thì việc đăng ký tại một CA trung tâm trở thành vấn đề khó giải quyết. Để giải quyết vấn đề này cần thiết phải có một hoặc nhiều RAs (trung tâm đăng ký địa phương). Mục đích chính của RA là để giảm tải công việc của CA. Chức năng thực hiện của một RA cụ thể sẽ khác nhau tuỳ theo nhu cầu triển khai PKI nhưng chủ yếu bao gồm những chức năng sau:

- Xác thực cá nhân chủ thể đăng ký chứng thư. - Kiểm tra tính hợp lệ của thông tin do chủ thể cung cấp. - Xác nhận quyền của chủ thể đối với những thuộc tính chứng thư

được yêu cầu.

42

- Kiểm tra xem chủ thể có thực sự sở hữu khoá cá nhân đang

được đăng ký hay không - điều này thường được đề cập đến như sự chứng minh sở hữu (proof of possession - POP). - Tạo cặp khoá cá nhân /công khai. - Phân phối bí mật được chia sẻ đến thực thể cuối (ví dụ : khoá công của CA). - Thay mặt chủ thể thực thể cuối khởi tạo quá trình đăng ký với CA. - Lưu trữ khoá cá nhân. - Khởi sinh qúa trình khôi phục khoá. - Phân phối thẻ bài vật lý (ví dụ như thẻ thông minh) chứa khoá cá nhân. Nhìn chung, RA xử lý việc trao đổi (thường liên quan đến tương tác người dùng) giữa chủ thể thực thể cuối và quá trình đăng ký, phân phối chứng thư và quảnlý vòng đời chứng thư/khoá. Tuy nhiên, trong bất kỳ trường hợp nào thì RA cũng chỉ đưa ra những khai báo tin cậy ban đầu về chủ thể. Chỉ CA mới có thể cấp chứng thư hay đưa ra thông tin trạng thái thu hồi chứng thư như CRL.

2.2.3 Thực thể cuối ( Người giữ chứng thư và Clients) Thực thể cuối trong PKI có thể là con người, thiết bị, và thậm chí là một chương trình phần mềm nhưng thường là người sử dụng hệ thống. Thực thể cuối sẽ thực hiện những chức năng mật mã (mã hoá, giải mã và ký số). 2.2.4 Hệ thống lưu trữ (Repositories) Chứng thư (khoá công) và thông tin thu hồi chứng thư phải được phân phối sao cho những người cần đến chứng thư đều có thể truy cập và lấy được. Có 2 phương pháp phân phối chứng thư: a. Phân phối cá nhân 43

Phân phối cá nhân là cách phân phối cơ bản nhất. Trong phương pháp này thì mỗi cá nhân sẽ trực tiếp đưa chứng thư của họ cho người dùng khác. Việc này có thể thực hiện theo một số cơ chế khác nhau. Chuyển giao bằng tay chứng thư được lưu trong đĩa mềm hay trong một số các môi trường lưu trữ khác. Cũng có thể phân phối bằng cách gắn chứng thư trong e-mail để gửi cho người khác. Cách này thực hiện tốt trong một nhóm ít người dùng nhưng khi số lượng người dùng tăng lên thì có thể xảy ra vấn đề về quản lý. b. Phân phối công khai Một phương pháp khác phổ biến hơn để phân phối chứng thư (và thông tin thu hồi chứng thư) là công bố các chứng thư rộng rãi, các chứng thư này có thể sử dụng một cách công khai và được đặt ở vị trí có thể truy cập dễ dàng. Những vị trí này được gọi là cơ sở dữ liệu. Dưới đây là ví dụ về một số hệ thống lưu trữ: - X.500 Directory System Agents (DSAs) - Lightweight Directory Access Protocol (LDAP ) Server - Online Certificate Status Protocol (OCSP) Responders - Domain name System (DNS) và Web servers - File Transfer Protocol (FTP) Servers và Corporate Databases

2.3 Chức năng cơ bản của PKI Những hệ thống cho phép PKI có những chức năng khác nhau. Nhưng nhìn chung có hai chức năng chính là: chứng thực và thẩm tra. 2.3.1 Chứng thực (certification) Chứng thực là chức năng quan trọng nhất của hệ thống PKI. Đây là quá trình ràng buộc khoá công khai với định danh của thực thể. CA là thực thể PKI thực hiện chức năng chứng thực. Có hai phương pháp chứng thực: - Tổ chức chứng thực (CA) tạo ra cặp khoá công khai / khoá cá nhân và tạo ra chứng thư cho phần khoá công của cặp khoá. 44

- Người sử dụng tự tạo cặp khoá và đưa khoá công cho CA để CA

tạo chứng thư cho khoá công đó. Chứng thư đảm bảo tính toàn vẹn của khoá công khai và các thông tin gắn cùng. 2.3.2 Thẩm tra (validation) Quá trình xác định liệu chứng thư đã đưa ra có thể được sử dụng đúng mục đích thích hợp hay không được xem như là quá trình kiểm tra tính hiệu lực của chứng thư. Quá trình này bao gồm một số bước sau: - Kiểm tra xem liệu có đúng là CA được tin tưởng đã ký số lên chứng thư hay không (xử lý theo đường dẫn chứng thư). - Kiểm tra chữ ký số của CA trên chứng thư để kiểm tra tính toàn vẹn. - Xác định xem chứng thư còn ở trong thời gian có hiệu lực hay không. - Xác định xem chứng thư đã bị thu hồi hay chưa. - Xác định xem chứng thư đang được sử dụng có đúng mục đích, chính sách, giới hạn hay không (bằng cách kiểm tra những trường mở rộng cụ thể như mở rộng chính sách chứng thư hay mở rộng việc sử dụng khoá). 2.3.3 Một số chức năng khác Hệ thống PKI thực hiện chức năng chứng thực, thẩm tra cùng với một số chức năng phụ trợ khác. Dưới đây là một số chức năng và dịch vụ được hầu hết các hệ thống PKI cung cấp. Một số những chức năng khác có thể được định nghĩa tuỳ theo yêu cầu cụ thể của các hệ thống PKI. a. Đăng ký Đăng ký là quá trình đến hoặc liên lạc với các tổ chức, trung tâm tin cậy để đăng ký các thông tin và xin cấp chứng thư. RA và CA là những thực thể trong quá trình đăng ký. Quá trình đăng ký phụ thuộc vào chính sách của tổ chức. Nếu chứng thư được cung cấp với mục đích dùng cho những hoạt động bí mật thì sử dụng phương pháp gặp mặt trực tiếp. Nếu chứng thư chỉ được sử dụng cho những mục đích, hoạt động thường thì có thể đăng ký qua những ứng dụng viết sẵn hoặc ứng dụng điện tử. 45

b. Khởi tạo ban đầu Khi hệ thống trạm của chủ thể nhận được các thông tin cần thiết để liên lạc với CA thì quá trình khởi tạo bắt đầu. Những thông tin này có thể là khoá công của CA, chứng thư của CA, cặp khóa công /bí mật của chủ thể. Một số hệ thống khác sử dụng cơ chế dựa trên password trong giai đoạn khởi tạo. Người dùng cuối liên lạc với CA khi nhận được password và sau đó thiết lập một kênh bảo mật để truyền những thông tin cần thiết. Giai đoạn khởi tạo thường tiếp tục với quá trình chứng thực. c. Khôi phục cặp khoá Hầu hết hệ thống PKI tạo ra hai cặp khoá cho người sử dụng cuối, một để ký số và một để mã hoá. Lý do để tạo hai cặp khoá khác nhau xuất phát từ yêu cầu khôi phục và sao lưu dự phòng khoá. Tuỳ theo chính sách của tổ chức, bộ khoá mã (mã và giải mã) và những thông tin liên quan đến khoá của người sử dụng phải được sao lưu để có thể lấy lại được dữ liệu khi người sử dụng mất khoá cá nhân hay rời khỏi đơn vị. Còn khoá để ký số được sử dụng tuỳ theo mục đích cá nhân nên không được sao lưu. Riêng khoá cá nhân của CA thì được lưu giữ dự phòng trong một thời gian dài để giải quyết những vấn đề nhầm lẫn có thể xảy ra trong tương lai. Hệ thống PKI có những công cụ để thực hiện chức năng sao lưu và khôi phục khoá. d. Tạo khoá Cặp khoá công khai/bí mật có thể được tạo ở nhiều nơi. Chúng có thể được tạo ra bằng phần mềm phía client và được gửi đến CA để chứng thực. CA cũng có thể tạo ra cặp khoá trước khi chứng thực. Trong trường hợp này, CA tự tạo cặp khoá và gửi khoá cá nhân này cho người sử dụng theo một cách an toàn. Nếu khoá do bên thứ ba tạo ra thì những khoá này phải được CA tin cậy trong miền xác nhận trước khi sử dụng. 46

e. Hạn sử dụng và cập nhật khoá Một trong những thuộc tính của chứng thư là thời gian hiệu lực. Thời gian hiệu lực của mỗi cặp khoá được xác định theo chính sách sử dụng. Các cặp khoá của người sử dụng nên được cập nhật khi có thông báo về ngày hết hạn. Hệ thống sẽ thông báo về tình huống này trong một thời gian nhất định. Chứng thư mới sẽ được người cấp công bố tự động sau thời gian hết hạn. f. Xâm hại khoá Đây là trường hợp không bình thường nhưng nếu xảy ra thì khoá mới sẽ được công bố và tất cả người sử dụng trong hệ thống sẽ nhận thấy điều này. Xâm hại đến khoá của CA là một trường hợp đặc biệt. Và trong trường hợp này thì CA sẽ công bố lại tất cả các chứng thư với CA-certificate mới của mình g. Thu hồi Chứng thư được công bố sẽ được sử dụng trong khoảng thời gian có hiệu lực. Nhưng trong trường hợp khoá bị xâm hại hay có sự thay đổi trong thông tin của chứng thư thì chứng thư mới sẽ được công bố, chứng thư cũ sẽ bị thu hồi. h. Công bố và gửi thông báo thu hồi chứng thư Một chứng thư được cấp cho người sử dụng cuối sẽ được gửi đến cho người nắm giữ và hệ thống lưu trữ để có thể truy cập công khai. Khi một chứng thư bị thu hồi vì một lý do nào đó, tất cả người sử dụng trong hệ thống sẽ được thông báo về việc này. Phương thức để công bố và gửi những thông báo thu hồi đã được đề cập chi tiết trong nội dung về chứng thư số ở phần trên. i. Xác thực chéo Xác thực chéo là một trong những đặc tính quan trọng nhất của hệ thống PKI. Chức năng này được sử dụng để nối hai miền PKI khác nhau. Xác thực chéo là cách để thiết lập môi trường tin cậy giữa hai CA dưới những điều kiện nhất định. Những điều kiện này được xác định theo yêu cầu của người sử dụng. Những người sử dụng ở các miền khác nhau chỉ có thể giao tiếp 47

an toàn với người khác sau khi việc xác thực chéo giữa các CA thành công. Xác thực chéo được thiết lập bằng cách tạo chứng thư CA xác thực lẫn nhau. Nếu CA-1 và CA-2 muốn thiết lập xác thực chéo thì cần thực hiện một số bước sau:

- CA-1 công bố CA – certificate cho CA-2. - CA-2 công bố CA – certificate cho CA-1. - CA-1 và CA-2 sẽ sử dụng những trường mở rộng xác định trong chứng thư để đặt những giới hạn cần thiết trong CA-certificate. Việc xác thực chéo đòi hỏi phải có sự kiểm tra cẩn thận các chính sách PKI. Nếu cả hai đều có cùng hoặc tương tự chính sách của nhau thì việc xác thực chéo sẽ có ý nghĩa. Ngược lại, sẽ có những tình huống không mong muốn xuất hiện trong trường hợp chính sách PKI của một miền trở thành một phần của miền khác. Trường mở rộng “Policy mapping”, “name constraints” và “policy constraints” của chứng thư X.509 chuẩn được sử dụng trong xác thực chéo để đưa ra một số giới hạn trong môi trường tin cậy. Hình 2.7 dưới đây minh hoạ đường dẫn cấp chứng thư được xây dựng giữa 2 CA (2 CA này đã thiết lập mối quan hệ tin cậy sử dụng xác thực chéo ngang hàng). Mô hình chỉ ra chứng thư chéo được cấp giữa mỗi CA và chứng thư thực thể cuối được CA cấp. Người cấp của một chứng thư là chủ thể của chứng thư khác. Khoá công khai được xác nhận trong một chứng thư tương ứng với khoá cá nhân được sử dụng để ký chứng thư khác.

48

Hình 2.7: Đường dẫn chứng thư chéo

2.4 Mô hình tin cậy cho PKI X.509 định nghĩa sự tin cậy như sau: “Một thực thể có thể được nói là tin cậy với một thực thể thứ hai nếu nó (thực thể đầu tiên ) tạo ra sự đảm bảo rằng thực thể thứ hai sẽ thực hiện chính xác như thực thể thứ nhất mong đợi” [7]. Định nghĩa này có thể được diễn đạt lại về mặt PKI như sau: một thực thể cuối tin cậy một CA khi thực thể cuối cho rằng CA sẽ thiết lập và duy trì sự gắn kết các thuộc tính của khoá công một cách chính xác. 49

Có một số mô hình tin cậy có thể được áp dụng hoặc được đề xuất để sử dụng trong hạ tầng mã khoá công khai - PKI dựa trên X.509:

-

Single CA Model (mô hình CA đơn ) Hierarchical Model (Mô hình phân cấp ) Mesh Model (Mô hình mắt lưới – mô hình xác thực chéo) Hub and Spoke (Bridge CA) Model (Mô hình cầu CA) Web Model (Trust Lists) (Mô hình web) User Centric Model (Mô hình người sử dụng trung tâm )

2.4.1 Mô hình CA đơn Đây là mô hình tổ chức CA cơ bản và đơn giản nhất. Trong mô hình CA đơn chỉ có một CA xác nhận tất cả các thực thể cuối trong miền PKI. Mỗi người sử dụng trong miền nhận khoá công khai của CA gốc (root CA) theo một số cơ chế nào đó. Trong mô hình này không có yêu cầu xác thực chéo. Chỉ có một điểm để tất cả người sử dụng có thể kiểm tra trạng thái thu hồi của chứng thư đã được cấp. Mô hình này có thể được mở rộng bằng cách có thêm các RA ở xa CA nhưng ở gần các nhóm người dùng cụ thể. Mô hình này được minh hoạ trong hình 2.8.

Hình 2.8: Mô hình CA đơn 50

Mô hình này dễ để triển khai và giảm tối thiểu được những vấn đề về khả năng tương tác. Nhưng mô hình này có một số nhược điểm sau:

- Không thích hợp cho miền PKI lớn vì một số người sử dụ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.

51

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. 52

- 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.

53

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. 54

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.

55

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 56

- 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. 57

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.

58

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.

59

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. 60

• 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 Face Fingerprint Hand geometry Keystrokes Hand veins Iris Retinal scan Signature Voice Facial thermograph Odor DNA Gait Ear Canal

Phổ dụng H M M

Duy nhất L H M

Bền vững M H M

Khả dụng H M H

Hiệu quả L H M

Chấp nhận H M M

Bị giả mạo L H M

L M H H L M H

L M H H L L H

L M H M L L L

M M M L H M H

L M H H L L M

M M L L H H H

M H H H L L H

H H M M

H H L M

H H L H

L L H M

L H L M

M L H H

L L M 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)

61

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ữ. 62

• 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 63

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]

64

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 BKBioPKI-OpenCA. 65

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.

66

• 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ỉ: http://www.slproweb.com/products/Win32OpenSSL.html 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. 67

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); 68

- 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ố. -

69

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 http://www.openssl.org/docs/.

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

70

Database

CA Operator

OpenCA

CA

Offline

Database

Trung tâm dịch vụ thẻ

Trung tâm dịch vụ chứng chỉ

RA

Offline

Offline

Database

Database

LRA

LRA

User Application

User Application

Người sử dụng Chứng chỉ

Người sử dụng Chứng chỉ

User Application

Offline Offline

Người đăng kí Chứng chỉ

Người đăng kí Chứng chỉ

Người sử dụng Chứng chỉ

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ý) 71

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

72

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: 73

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: CA Operator

Giao dịch với RA

Giao dịch với CA

Cấp chứng thư số mới

Cấp chứng thư số mới Submit request

Nhận request

Trả thẻ, chứng chỉ

Ghi Token

Nhận đặc trưng sinh trắc

Mã hóa khóa và ghi ra token

Lấy chứng thư từ CSDL

Hủy chứng thư số

Hủy chứng thư số

Nhận yêu cầu

Cập nhật vào CSDL

Trả lời Cấp lại chứng thư số

Cấp lại chứng thư số

Hủy chứng thư Hủy chứng số cũ trong thưHình số cũ 1.5: Biểu đồ phân cấp chức năng của CA Operator CSDL

• Giao dịchCấp vớilạiRA: chứng

Cấp lại chứng thư số mới

thư số mới

 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 74

 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

75

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 2.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: 76

 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: 77

 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 78

- 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ý. 79

- 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ị.

80

(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ư. 81

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 82

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

83

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 84

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

OpenCA DB

CAOperator Setup

: CA_Operator_Admin 1 : Select setup() 2 : Query information() 3 : Enter information()

4 : Verify certificates()

5 [failed] : Requery certificates() 6 : Re-enter certificates() 7 : Connect to DB()

8 : Connect OK() 9 : Save configs()

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

85

(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: 86

•

Đă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 87

(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

88

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 89

RA

LRA Setup

: LRA_Admin 1 : Select setup LRA() 2 : Query information() 3 : Enter information()

4 : Verify certificates() 5 [failed] : Requery certificates() 6 : Re-enter certificates() 7 : Connect to RA()

8 : Connect OK() 9 : Save configs()

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 90

(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.

91

Hình 4.6: Kịch bản khởi động cho các phân hệ trong hệ thống BioPKI

92

CHƯƠNG 5 THỬ NGHIỆM KỊCH BẢN ỨNG DỤNG TRONG HỆ THỐNG BIOPKI-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

Application Digital Signature

Sign <<extend>>

<<extend>>

Verify Signature

User Remote Authentication Encrypt Message

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à : 93

•

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 Pb A 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.

94

Digital signature app : User 1 : Request sign a file() 2 : Dialogselect file() 3 : Choose file() 4 : Private key file path() 5 : Choose file() 6 : Password() 7 : Enter password()

8 : Sign file() 9 : Signed file 10 : Send file()

11 : Connect to partner and send file()

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.

95

Biểu đồ diễn tiến quá trình xác thực chữ kí:

Digital signatureapp

RA

: User 1: Verify afile() 2: Select afile() 3: Choosefile()

4: Extract signatureinfo() 5: Privatekey filepath() 6: choosefile() 7: Requirepassword() 8: Enter password() 9: Connect()

10: ConnectOK 11: Get cert() 12: Partner cert 13: Get publickey()

14: Verify()

Hình Biểu đồ diễn tiến quá trình xác thực chữ kí 15: Se5.3: ndverify result() 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

96

LRA

Digital signature app

RA

CA Operator

CA

: User 1 : request new cert() 2 : New request file() 3 : send request() 4 : New request file() 5 : Send request() 6 : Submit()

7 : I ssue cert() 8 : New Cert() 9 : CreateToken()

10 : Export cert to file()

11 : Send new token() 13 : Send new token()

12 : Send new token()

14 : Sign a file() 15 : Get private key() 16 : I nput token() 17 : Decrypt, get priv key()

18 : Sign file() 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

97

LRA

D ig ita l s ig n a tu re a p p

RA

C A O p e ra to r

CA

: Us er 1 : re q u e s t n e w c e rt() 2 : N e w re q u e s t file () 3 : s e n d re q u e s t() 4 : N e w re q u e s t file () 5 : Se n d re q u e s t() 6 : Su b mit() 7 : Is s u e c e rt() 8 : N e w C e rt() 9 : C re a te T o ke n ()

10 : Exp o rt c e rt to file ()

11 : Se n d n e w to ke n () 13 : S e n d n e w to ke n ()

12 : S e n d n e w to ke n ()

14 : Ve rify a file () 15 : Ge t p riv a te ke y () 16 : In p u t to ke n () 17 : D ec ry p t, g e t p riv ke y () 18 : C o n n e ct () 19 : C o n n e c tO K 20 : Ge t Ce rt() 21 : Pa rt n e rCe rt 22 : Ge tP u b lic K e y () 23 : Ve rify ()

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 24 : Se n d v e rify re s u lt()

5.2 Kết quả thử nghiệm 98

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í 99

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

100

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.). 101

Securing our future : ITS America 12th Annual Meeting and Exposition 2002 : conference proceedings. [13] http://www.openssl.org. [14] http://www.openca.org [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

102