Chương 3 PHÂN TÍCH THIẾT KẾ VÀ XÂY DỰNG HỆ THỐNG
3.1 Đặc tả yêu cầu cho hệ thống
3.1.2 Đặc tả yêu cầu cho module tạo thẻ
Module tạo thẻ cần có các chức năng cơ bản sau đây:
Ghi dữ liệu lên thẻ thông minh không tiếp xúc (Bảo vệ bằng mật khẩu).
Tạo chữ ký số trên trường dữ liệu cần ghi.
Tạo MRZcode.
Cài đặt chứng thư số và khóa riêng trong hệ thống của mình, phục vụ việc tạo thẻ thông minh.
Theo như phần trên, dữ liệu trong thẻ thông minh được tổ chức theo các Data group theo những định dạng nhất định. Vì vậy thông tin cá nhân người dùng trước khi ghi lên thẻ cũng cần tổ chức thành các nhóm dữ liệu (data group) với định dạng đã được qui định.
Sau khi tạo xong các nhóm dữ liệu, để tạo chữ ký số cho thẻ việc đầu tiên là tạo dữ liệu băm (hashdata) cho từng nhóm dữ liệu theo một thuận toán băm nào đó, thông thường là SHA-1. Tập hợp các dữ liệu băm này lại được băm một lần nữa để tạo chữ ký cho thẻ, thực chất của viê này là mã hóa một giá trị băm vừa thu được theo một thuật toán mã hóa RSA với khóa riêng chứa trong chứng thư CDS.
3.1.2.1 Tạo chữ ký số lên dữ liệu của thẻ
Chữ ký số là thông tin đi kèm theo dữ liệu chứa trong thẻ (thông tin cá nhân thông thường, dữ liệu ảnh sinh trắc nhận dạng…) nhằm mục đích xác định người chủ của dữ liệu đó.
Để sử dụng chữ ký số đầu tiên dữ liệu cần phải được mã hóa bằng hàm băm (dữ liệu được “băm” ra thành chuỗi, thường có độ dài cố định và ngắn hơn văn bản đầu vào) sau đó dùng khóa bí mật của Document Signer để mã hóa, khi đó ta được chữ ký số. Thông thường giải thuật băm được sử dụng trong hệ thống là SHA-1, và giải thuật tạo chữ ký số là RSA.
3.1.2.2 Ghi dữ liệu lên thẻ
Các Datagroup cần tạo cho thẻ bao gồm:
DG1 (Datagroup 1): Chứa các thông tin cá nhân chủ thẻ như: Họ và Tên, năm sinh, nơi sinh, quốc tích…
DG2 (Datagroup 2): Chứa mã hóa dữ liệu sinh trắc học khuôn mặt chủ nhân thẻ.
DG3 (Datagroup 3): Chứa mã hóa dữ liệu sinh trắc học dấu vân tay.
Cặp khóa KENC và KMAC
DG_SOD (DG Security Oject Data) chứa các giá trị băm các Datagroup trên, và một chữ ký số đi kèm.
3.1.2.3 Tạo MRZcode
Mã MRZ (Machine Readable Zone) [15-17] được ghép từ hai phần dài 44 kí tự:
MRZCode A và MRZCode B.
Phần MRZCode A được tạo thành từ những trường thông tin: Document type, Issuing State or organization và Name of holder. Cụ thể:
Document type: Mặc định có giá trị P<
Issuing State or organization: Mã 3 kí tự của nước phát hành.
Name of holder: Thay kí tự (“_” hoặc “,”) phân cách giữa tên và họ bằng chuỗi “<<”, phân cách giữa tên chính và tên đệm bằng chuỗi “<”. Cuối cùng bổ xung thêm các kí tự “<” vào cuối chuỗi tên vừa thu được để đạt đủ 44 kí tự.
Ví dụ: Issuing State or organization = “ATA”, Name of holder = “Smith, John Bob” thì MRZCode A “P<ATASmith<<John<Bob<<<….<<”
Phần MRZCode B được tạo thành từ các trường thông tin: Document number, Check digit-document number, Nationality, Date of birth, Check digit-Date of birth, Sex, Date of Expiry, Check digit – Date of expiry, Optional data, Check digit-Optional data và Check digit-Composite.Cụ thể như sau:
Document number: Giữ nguyên
Check digit-document number:Tính toán Checkdigit cho Document number.
Nationality: Giữ nguyên
Date of birth: Đưa về định dạng yymmdd
Check digit –Date of birth: Tính toán Checkdigit cho Date of birth
Sex: “F”, “M” hoặc “<”.
Date of Expiry: Đưa về định dạng yymmdd
Check digit – Date of expiry: Tính toán Checkdigit cho trường Date of Expiry.
Optional data: Bổ xungchuỗi bao gồm các kí tự “<” tạo thành chuỗi mới dài 14 kí tự.
Check digit – Optional data: Tạo checkdigit cho trường Optional data
Checkdigit – Composite: Lược bỏ mã nước phát hành và kí tự giới tính từ chuỗi đang có để tính checkdigit.
3.1.3 Đặc tả yêu cầu cho moduel xác thực thẻ
Module xác thực thẻ có các chức năng cơ bản sau đây:
Xác thực quyền truy cập dữ liệu BAC.
Xác thực tính toàn vẹn dữ liệu trên thẻ theo cơ chế PA.
Tải chứng thư số khóa công CDS và CCSCA từ thư mục chứa khóa công PKD, dựa trên tên tổ chức phát hành hoặc serial của chứng thư cần lấy về.
Truy cập sử dụng dịch vụ Online Responder Service để kiểm tra trạng thái thu hồi chứng thư số được chỉ định.
Xác thực chủ sở hữu thẻ hộ chiếu thông qua nhận dạng sinh trắc học.
Sau đây ta đi vào chi tiết cho từng yêu cầu một.
3.1.3.1 Bảo mật truy cập thẻ bằng BAC
Quá trình thiết lập bảo mật truy cập dữ liệu thẻ bằng BAC là quá trình bắt tay 7 bước để đạt được một khóa chung thống nhất Kseed. Khóa này sẽ được dùng để mã hóa cũng như giải mã thông điệp lệnh xuyên suốt trong các giao dịch truy nhập dữ liệu thẻ.
Chi tiết về các bước xác lập khóa Kseed xin tham khảo ở phần trên.
3.1.3.2 Bảo mật dữ liệu thẻ bằng PA
Tương tự như quá trình xác thực truy cập thẻ, xác thực toàn vẹn dữ liệu đối với dữ liệu thẻ cũng có hai cơ chế: Active Authority (AA) và Passive Authority (PA).
Quá trình xác thực thẻ thông qua cơ chế này được thực hiện qua các bước sau:
B1. Dữ liệu ghi trong file SOD (Document Security Object) (Tùy chọn chứa Document Signer Certificate- CDS ) được đọc từ thẻ.
B2. Document Signer (DS) được đọc từ SOD
B3. Chữ ký số của SOD được xác thực bởi hệ thống sử dụng khóa KPuDS (Document Signer Public Key). CDS cho khóa này được lưu trữ trong hệ thống kiểm tra được tải từ ICAO PKD hoặc có thể được lưu trữ trong SOD của thẻ.
B4. Hệ thống kiểm tra đọc các DG thích hợp từ LDS.
B5. Băm nội dung SOD và so sánh với giá trị băm tương ứng trong SOD, điều này đảm bảo rằng nội dung các DG trong LDS là xác thực.
3.1.3.3 Bảo mật chứng thư số trong quá trình truyền thông a. Giao thức SSL/TLS
Việc kết nối giữa thực thể CSCA, Internal Service, PKD với các thực thể DS, IS để trao đổi các chứng thư số thông qua môi trường mạng đều phải đi qua rất nhiều các hệ thống độc lập mà không có bất kỳ sự bảo vệ nào với các thông tin trên đường truyền. Để bảo vệ những chứng thư số nói riêng và những thông tin mật nói chung trên mạng Internet hay bất kỳ mạng TCP/IP nào, SSL (Secure Socket Layer)[14,19] đã kết hợp những yếu tố sau để thiết lập được một giao dịch an toàn:
Xác thực: Đảm bảo tính xác thực thực thể mà ta đang làm việc ở đầu kia của kết nối. (thông thường sẽ xác thực CSCA). Cũng như vậy, các thực thể đó cũng có thể yêu cầu kiểm tra tính xác thực của đối tượng sử dụng dịch vụ nếu thấy cần thiết.
Mã hóa: Đảm bảo thông tin không thể bị truy cập bởi đối tượng thứ ba. Để loại trừ việc nghe trộm những thông tin “nhạy cảm” khi nó truyền qua Internet, dữ liệu phải được mã hóa để không thể bị đọc được bởi những đối tượng khác ngoài đối tượng gửi và đối tượng nhận.
Toàn vẹn dữ liệu: Đảm bảo thông tin không bị sai lệch và nó phải thể hiện chính xác thông tin gốc gửi đến.
Giao thức SSL được phát triển bởi Netcape, ngày nay giao thức SSL đã được sử dụng rộng rãi trong việc xác thực và mã hóa thông tin giữa Client-Server. Tổ chức IETF(Internet Engineering Task Force) đã chuẩn hóa SSL và đặt tên lại là TLS (Transport Layer Security)[14,19]. Mặc dù là có sự thay đổi về tên nhưng TLS chỉ là một phiên bản mới của SSL. Phiên bản TLS 1.0 tương đương với phiên bản SSL 3.1.
Giao thức TLS v1.0 được chọn sử dụng trong quyển luận văn này.
Giao thức SSL (SSLv3.0 hoặc TLS v1.0) bao gồm 2 giao thức con: giao thức SSL record và giao thức SSL handshake. Giao thức SSL record xác định các định dạng dùng để truyền dữ liệu. Giao thức SSL handshake sẽ sử dụng SSL record protocol để trao đổi một số thông tin giữa server và client vào lần đầu tiên thiết lập kết nối SSL.
b. SSL Handshake
Giao thức SSL sử dụng kết hợp 2 loại mã hóa đối xứng và công khai. Sử dụng mã hóa đối xứng nhanh hơn rất nhiều so với mã hóa công khai khi truyền dữ liệu, nhưng mã hóa công khai lại là giải pháp tốt nhất trong quá trình xác thực. Một giao dịch SSL thường bắt đầu bởi quá trình “bắt tay” giữa hai bên (SSL handshake). Các bước trong quá trình “bắt tay” được thực hiện qua các bước chính sau:
B1. Client gửi cho server số phiên bản SSL đang dùng, các tham số của thuật toán mã hóa, dữ liệu được tạo ra ngẫu nhiên (đó chính là digital signature) và một số thông tin khác mà server cần để thiết lập kết nối với client.
B2. Server gửi cho client số phiên bản SSL đang dùng, các tham số của thuật toán mã hoá, dữ liệu được tạo ra ngẫu nhiên và một số thông tin khác mà client cần để thiết lập kết nối với server. Ngoài ra server cũng gửi certificate của nó đến client, và yêu cầu certificate của client nếu cần.
B3. Client sử dụng một số thông tin mà server gửi đến để xác thực server. Nếu như server không được xác thực thì người sử dụng sẽ được cảnh báo và kết nối không được thiết lập. Còn nếu như xác thực được server thì phía client sẽ thực hiện tiếp bước 4.
B4. Sử dụng tất cả các thông tin được tạo ra trong giai đoạn bắt tay ở trên, client (cùng với sự cộng tác của server và phụ thuộc vào thuật toán được sử dụng) sẽ tạo ra premaster secret cho phiên làm việc, mã hoá bằng khoá công khai (public key) mà server gửi đến trong certificate ở bước 2, và gửi đến server.
B5. Nếu server có yêu cầu xác thực client, thì phía client sẽ đánh dấu vào phần thông tin riêng chỉ liên quan đến quá trình “bắt tay” này mà hai bên đều biết.
Trong trường hợp này, client sẽ gửi cả thông tin được đánh dấu và certificate của mình cùng với premaster secret đã được mã hoá tới server.
B6. Server sẽ xác thực client. Trường hợp client không được xác thực, phiên làm việc sẽ bị ngắt. Còn nếu client được xác thực thành công, server sẽ sử dụng khoá bí mật (private key) để giải mã premaster secret, sau đó thực hiện một số bước để tạo ra master secret.
B7. Client và server sẽ sử dụng master secret để tạo ra các session key, đó chính là các khoá đối xứng được sử dụng để mã hoá và giải mã các thông tin trong phiên làm việc và kiểm tra tính toàn vẹn dữ liệu.
B8. Client sẽ gửi một lời nhắn đến server thông báo rằng các message tiếp theo sẽ được mã hoá bằng session key. Sau đó nó gửi một lời nhắn đã được mã hoá để thông báo rằng phía client đã kết thúc giai đoạn “bắt tay”.
B9. Server cũng gửi một lời nhắn đến client thông báo rằng các message tiếp theo sẽ được mã hoá bằng session key. Sau đó nó gửi một lời nhắn đã được mã hoá để thông báo rằng server đã kết thúc giai đoạn “bắt tay”.
B10. Lúc này giai đoạn “bắt tay” đã hoàn thành, và phiên làm việc SSL bắt đầu. Cả hai phía client và server sẽ sử dụng các session key để mã hoá và giải mã thông tin trao đổi giữa hai bên, và kiểm tra tính toàn vẹn dữ liệu
Hình 3.9 – SSL Handshake c. Thuật toán mã hóa dùng trong SSL/TLS
Các thuật toán mã hóa (cryptographic algorithm hay còn gọi là cipher) là các hàm toán học được sử dụng để mã hóa và giải mã thông tin. Giao thức SSL hỗ trợ rất nhiều các thuật toán mã hóa, được sử dụng để thực hiện các công việc trong quá trình xác thực server và client, truyền tải các chứng thư số và thiết lập các khóa của từng phiên giao dịch (session key). Client và server có thể hỗ trợ các bộ mật mã khác nhau tùy thuộc vào yếu tố như phiên bản SSL đang dùng, chích sách của hệ thống về độ dài khóa mà hệ thống chấp nhận được, điều này liên quan đến mức độ bảo mật của thông tin.
Các bộ mật mã thường dùng trong quá trình giao dịch SSL/TLS là:
DES (Data Encryption Standard) là một thuật toán mã hóa có chiều dài khóa là 56 bits.
3-DES (Triple-DES) là thuật toán mã hóa có độ dài khóa gấp 3 lần độ dài khóa trong mã hóa DES.
KEA (Key Exchange Algorithm) là một thuật toán trao đổi khóa đang được chính phủ Mỹ sử dụng.
MD5 (Message Digest Algorithm) được phát triển bởi Rivest.
RSA
RSA key exchange: Là thuật toán trao đổi khóa dùng trong SSL dựa trên thuật toán RSA.
RC2 và RC4: Là thuật toán mã hóa được phát triển bởi Rivest dùng cho RSA Data Security.
SHA-1(Secure Hash Algorithm) là một thuật toán băm đang được chính phủ Mỹ sử dụng.
Các thuật toán trao đổi khóa như KEA, RSA key exchange được sử dụng để hai bên client-server xác lập khóa đối xứng mà họ sẽ sử dụng trogn suốt phiên giao dịch SSL. Thuật toán sử dụng để trao đổi khóa trong luận văn là RSA key exchange.
d. Cấu trúc thông điệp SSL/TLS
Trong phần này, để tiện mô tả các cấu trúc thông điệp, ta sử dụng kiểu ngôn ngữ giả lập trình C. Tất cả các thông điệp được sử dụng trong giao thức SSL có cấu trúc chung như sau:
struct { /* handshake type*/
/*bytes in message */
} Handshake;
Ý nghĩa của các trường được đánh số trong cấu trúc trên, như sau:
1. Kiểu của giao thức: Phần này cho biết giao thức này thuộc kiểu nào, kiểu là một số nguyên 1 byte được định danh duy nhất, nó thuộc kiểu tập hợp enum như chỉ ra dưới đây:
enum{
Hello_request(0), client_hello(1), server_hello(2), certificate(11),
Server_key_exchange(12), certificate_request(13),server_hello_done(14), Certificate_verity(15), client_key_exchange(16), finished(20), (255) } HandshakeType;
2. Độ dài của thông điệp (tính theo byte): Cho biết thông điệp này có phần thân chiếm bao nhiêu byte.
3. Phần thân thông điệp: Tùy thuộc giá trị phần HandshakeType mà phần thân sẽ có kiểu thích hợp. Ví dụ nếu msg_typecó giá trị là client_key_exchange thì phần body thuộc kiểu ClientKeyExchange
Ngay sau đây sẽ chỉ ra chi tiết cấu trúc cho trường hợp body có kiểu làClientKeyExchange, thuộc một trong số các kiểu thân thông điệp. Các phần khác hoàn toàn tự và có thể tham khảo trong tài liệu “The TLS Protocol Version 1.0” chuẩn RFC2246 do tổ chức IETF ban hành.
HandshakeTyemsg_type;
uint24length;
select (HandshakeType) {
casehello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
2
3 1
Cấu trúc kiểu ClientKeyExchange:
struct {
select (KeyExchangeAlgorthm) { case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Trong đó kiểu giải thuật trao đổi khóa được định nghĩa như sau:
enum {rsa, diffie_hellman } KeyExchangeAlgorithm;
Kiểu EncryptedPreMassterSecret:
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
Trường “public-key-encrypted” chỉ ra rằng cần mã hóa RSA đối với trường
“pre_master_secret”.
Tiếp tục ta làm việc với kiểu PreMasterSecret
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
Và kiểu ProtocolVersion:
struct {
uint8 major, minor;
} ProtocolVersion;
Tiếp theo là kiểu giải thuật Diffie-Hellman
struct {
select (PublicValueEncoding) { case implicit: struct {};
case explicit: opaque dh_Yc<1..2^16 -1>;
} dh_public;
} ClientDiffieHellmanPublic;
Trong đó kiểu PublicValueEncoding được định nghĩa là:
enum {implicit, explicit} PublicValueEncoding;
3.1.3.4 Truy cập dịch vụ Online Responder Service
Dịch vụ này là một thành phần trong cơ sở hạ tầng PKI, nhưng nó chạy như một dịch vụ độc lập. Tại đây, nó cung cấp các thông tin về trạng thái thu hồi của toàn bộ các chứng thư số trong thư mục công cộng PKI.