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.1 Đặc tả yêu cầu cho thẻ
Có ba vấn đề quan trọng khi làm việc với thẻ thông minh, đó là: Cấu trúc dữ liệu được tổ chức trong thẻ, tập giao thức truyền thông giữa thẻ với các thiết bị đọc/ ghi và bảo mật truy cập dữ liệu trong thẻ.
3.1.1.1 Cấu trúc dữ liệu cho thẻ
Để các thẻ với tổ chức phần cứng khác nhau vẫn làm việc được trong các hệ thống khác nhau, thì cấu trúc dữ liệu lưu trữ trong mỗi thẻ và giao thức giữa thẻ đó với đầu đọc thẻ trong hệ thống phải tuân theo những tiêu chuẩn do ICAO ban hành. Do vậy phần đặc tả yêu cầu cho thẻ chỉ đề cập tới cấu trúc dữ liệu mức logic LDS(Logical Data Structure) được tổ chức trong bộ nhớ của thẻ.
LDS là cần thiết, nó cho phép khả năng tương tác toàn cầu hóa cho các loại máy đọc thẻ. Theo tiêu chuẩn ICAO, LDS cần đáp ứng một số yêu cầu bắt buộc như sau:
Bảo đảm tính hiệu quả và tối ưu khi sử dụng bởi chủ thẻ
Bảo đảm tính bảo mật cho các thông tin ghi trong thẻ
Cho phép trao đổi dữ liệu toàn cầu và khả năng mở rộng dựa trên việc sử dụng một LDS đơn chung cho tất cả MRTD.
Cung cấp khả năng mở rộng theo nhu cầu người dùng.
Hỗ trợ nhiều tùy chọn bảo vệ dữ liệu.
Hỗ trợ cập nhật các đề mục trong thẻ bởi nhà nước phát hành hoặc tổ chức ủy quyền.
Hỗ trợ bổ xung các đề mục bởi sự tiếp nhận của nhà nước hoặc các tổ chức ủy quyền nhận phê duyệt, đồng thời duy trì tính xác thực và toàn vẹn của dữ liệu được tạo ra do nhà nước phát hành.
Sử dụng các tiêu chuẩn quốc tế hiện hành đến mức tối đa có thể, đặc biệt là một số tiêu chuẩn quốc tế mới về sinh trắc học.
Dữ liệu lưu trữ trong bộ nhớ EEPROM của thẻ được tổ chức dưới dạng một cây các tệp (hay file) dữ liệu. Gốc cây là file MF( Master File), MF có thể chứa các file DF (Dedicated File - tệp chuyên dụng) hoặc EF (Elementary File - tệp thường). Các DF lại có thể chứa các DF khác hoặc EF.
Từng thông tin cá nhân của chủ sở hữu thẻ cũng như những thông tin bổ xung về bảo mật có thể lưu trữ trong một phần tử dữ liệu DE (Data Element), tập hợp các DE liên quan với nhau được nhóm lại thành một nhóm dữ liệu DG (Data Group). Mỗi Data Group được ghi thành một file kiểu EF và thường có tên EF.DGx (với x [1..16]). Tên gọi và ý nghĩa các Data Group theo qui định chuẩn ICAO được tham khảo ở phụ lục A & B.
Hình 3.1 – Cấu trúc dữ liệu tổ chức trong thẻ Yêu cầu cho Data group:
DG1: Bao gồm 14 Data Elements, chứa thông tin bắt buộc của người dùng trong vùng MRZ.
DG2: Chứa Data Element lưu trữ thông tin nhận dạng khuôn mặt đã được mã hóa.
DG3: Tương tự như DG2 nhưng mang thông tin về dấu vân tay
DG4: Như DG2 và DG3, mang thông tin về mống mắt. Cả3 Data Group (DG2 –DG4) nằm trong vùng dữ liệu mã đặc điểm nhận dạng.
DG5-6-7Lưu trữ các ảnh hiển thị như chân dung (Portrait), dự trữ cho việc sử dụng trong tương lai (Future Use), đặc điểm nhận dạng (Usual Mark) và chữ kí (Signature).
DG8-9-10 Lưu trữ đặc điểm mã hóa an ninh gồm có: Các đặc điểm về dữ liệu (Data Feature), các đặc điểm cấu trúc (Structure Feature) và các đặc điểm căn bản (Substance Feature).
Yêu cầu cho Data element: Các DE sẽ chứa chuỗi kí tự với độ dài cố định hoặc thay đổi nhưng không vượt quá một giới hạn cho trước. Với mỗi DE khác nhau có thể chứa tập kí tự cho phép theo một khuôn dạng được qui định trước theo tiêu chuẩn ICAO. Chi tiết tham khảo phụ lục C.
Để quản lý toàn bộ dữ liệu trong bộ nhớ cần phần header, cho ta chính xác vị trí các Data group cũng như Data element. Để làm được điều này về mặt lập trình chúng ta có thể tạo ra một chuỗi byte lưu thông tin (tên gọi, vị trí byte đầu trong bộ nhớ, kích thước…) từng DF và EF và được ghi vào một file như theo mẫu ví dụ sau:
byte[] fileStructure = { -1, // DF
0x3F, 0x00, // FID, MF -1, // no parent
2, 7, 12, // two children at indexes 7 and 12 0, // EF
0x2F, 0x00, // FID, EF.DIR
0, 0x1E, // parent at index 0, SFI is 1E -1, // DF
0x50, 0x15, // FID, DF.CIA 0, // parent at index 0
9, 26, 31, 36, 41, 46, 51, 56, 61, 66, // 9 children
0, // EF
0x50, 0x32, // FID, EF.CIAInfo
12, 0x12, // parent at index 12, SFI is 12 0, 0x50, 0x31, 12, 0x11, // EF.OD 0, 0x42, 0x00, 12, 0x00, // EF.AOD 0, 0x40, 0x00, 12, 0x00, // EF.PrKD 0, 0x41, 0x00, 12, 0x00, // EF.CD 0, 0x41, 0x01, 12, 0x00, // EF.CACert 0, 0x41, 0x02, 12, 0x00, // EF.UserCert1 0, 0x41, 0x03, 12, 0x00, // EF.UserCert2 0, 0x41, 0x04, 12, 0x00, // EF.UserCert3 };
Trong ví dụ này chuỗi fileStructure đóng vai trò như file header.
Phần Header bao gồm các thành phần sau:
Định danh cho ứng dụng (ApplicationIdentifier).
Số phiên bản LDS (LDS Versionnumber): Trường này có dạng “aabb”, với
“aa”=number[01-99] cho biết phiên bản nhận dạng của LDS và
“bb”=number[01-99] cho biết bản nhận dạng cập nhật của LDS.
Số phiên bản bộ mã kí tự (Unicode versionnumber): Có dạng “aabbcc”, với
“aa” cho biết số nhận dạng phiên bản chính Unicode chuẩn, “bb” cho biết số nhận dạng phiên bản phụ và “cc” cho biết số nhận dạng phiên bản cập nhật của Unicode.
Trong phụ lục A thấy rằng trong các DG có cả những DG là tùy chọn lẫn những DG bắt buộc. Điều này cũng sảy ra tương tự với các DE của một DG. Để nhận biết được điều này cần bổ xung thêm các thành phầnData Group Presence Map và Data Element Presence Map. Trong những phần đó có chứa dãy bit, với mỗi bit đại diện cho sự có mặt của DG hay DE. Ví dụ ta có 16 DG, nhưng phần lớn các trường hợp ta chỉ sử dụng các DG như: DG1-2-14-16. Với ý nghĩa bit ‘1’ đại diện cho sự có mặt DG và bit ‘0’ thì ngược lại, trong trường hợp này có chuỗi bit là ‘1100.0000.0000.0101’ .
Hình 3.2 – Cấu trúc logic của DataGroup
Mỗi Data Group lại quản lý các Data Element của mình và để nhận biết DE nào được sử dụng thì trong phần Data Element Presence Map cần chứa chuỗi bit với số bit tương ứng số DE nó chứa. Mỗi bit sẽ đại diện cho sự có mặt tương ứng của DE.
Hình 3.3 – Cấu trúc logic của Data Element
Các DG và DE được coi là các đối tượng dữ liệu và được bọc trong các thẻ (Tag) với mã tương ứng.Thẻđược dùng để bao bọc các khối thông tin, mã thẻ là một mã có tính chất duy nhất và tường minh cho biết chuỗi thông tin nó bao bọc có ý nghĩa thế nào. Các thẻ có thể bao bọc lẫn nhau, có nghĩa là trường giá trị của thẻ có thể là một thẻ khác. Cấu trúc một Tag gồm 3 trường: Mã thẻ, độ dài trường dữ liệu tính theo đ.v byte và dữ liệu:
Tag code L (Length) Value
Ví dụ: Để lưu thông tin LDS version 1.7 sử dụng Unicode version 4.0.0 có các DG1-2-4-12. Đối chiếu bảng cho ở trên có DG1(Tag ‘61’), DG2(Tag ‘75’), DG4(Tag
‘76’) và DG12(Tag ‘6C’). Các thông tin này lưu trong file EF.COM (Tag ‘60’).
‘60’ ‘16’
‘5F01’ ‘04’ ‘0107’
‘5F36’ ‘06’ ‘040000’
‘5C’ ‘04’ ‘6175766C’
Giảithích: EF.COM có thẻ (Tag) ‘60’ ,thông tin về phiên bản sử dụng LDS và Unicode lần lượt được đặt trong các thẻ với mã tương ứng ‘5F01’, ‘5F36’. Danh sách
các DG1-2-4-12 trở thành danh sách các thẻ tương ứng ‘60’-‘75’-‘76’-‘6C’. Sử dụng thẻ ‘5C’ gói thông tin này.
Hay dưới dạng mã Unicode cho trường hợp giá trị:
‘60’ ‘16’
‘5F01’ ‘04’ ‘30313037’
‘5F36’ ‘06’ ‘303430303030’
‘5C’ ‘04’ ‘6175766C’
Để quản lý các DG và DE dễ dàng (như tìm kiếm), mỗi DG và DE được gắn một mã đại diện (mã định danh) thường được gọi là FID, FID cũng như mã Tag cũng là mã duy nhất . Tham khảo mục lục D để biết chi tiết các mã Tag và FIDcho các DG và DE theo tiêu chuẩn ICAO ban hành.
Hình 3.4 – Cấu trúc hệ thống file 3.1.1.2 Giao thức truyền thông APDU
Trong phần này ta gọi ICC (Integrated Circuit Card) là phần thẻ, IFD (InterFace Device) là phần đầu đọc thẻ. Như đã biết hệ thống xây dựng bao gồm: Phần thẻ, đầu đọc thẻ, host computer…Truyền thông giữa ba thành phần này là truyền thông bằng giao thức APDU ( Application Protocol Data Unit) [15] tuân theo chuẩn ISO 14443 type A or B.
Hình3.5 – Truyền thông giữa Thẻ, thiết bị đọc và Host Computer
Giao tiếp giữa IFD với ICC và IFD với Host Computer sử dụng một giao thức chung APDU, sau đây ta chỉ cần xét việc truyền nhận thông điệp giữa IFD với ICC.
Hình 3.6 – Định dạng thông điệp lệnh truyền giữa Thẻ và thiết bị đọc/ ghi Trong sơ đồ trên thông điệp lệnh có định dạng:
Với ý nghĩa từng thành phần như sau:
CLA: Instruction Class
INS: Instruction Code (e.g: read memory)
P1: Instruction code qualifier (e.g: memory address) – Thành phần tham số
P2: Additional INS code qualifier – Thành phần tham số
P3: Thân thông điệp, cụ thể nó bao gồm các thành phần: Le, Lc và Data in CLA INS P1 P2 P3
Định dạng thông điệp lệnh dạng chi tiết như sau:
Phần đầu thông điệp lệnh dài 4 bytes (Bao gồm CLA, INS, P1, P2), như vậy mỗi thành phần chứa 1 byte. Chi tiết cho từng phần được chỉ ra trong phụ lục E & F.
Có 2 bytes trạng thái được gửi đi ngay sau khi kết thúc việc gửi dữ liệu được yêu cầu từ ICC tới IFD, đó là SW1 và SW2. Nếu mọi việc diễn ra tốt đẹp thì thông điệp kết quả trả về sẽ kèm theo các tham số SW1, SW2 = 90hex, 00hex .
Khi SW1 = 6X hoặc 9X có nghĩa là đã có lỗi sảy ra. Chuẩn ISO 7816-3 định nghĩa 5 lỗi như sau:
SW1 = 6E: Cho biết thẻ không hỗ trợ thông điệp lệnh có CLA đã gửi.
SW1 = 6D: Cho biết mã INS không hợp lệ
SW1 = 6B: Cho biết liên kết không đúng
SW1 = 67: Cho biết độ dài không đúng
SW1 = 6F: No particular diagnosis.
3.1.1.3 Bảo mật truy cập dữ liệu
Có hai cơ chế cho việc bảo mật điều khiển truy cập dữ liệu trên thẻ thông minh, đó là Basic Access Control (BAC) [15-17] và Extend Access Control (EAC) [20].
Luận văn này chọn BAC để xây dựng cơ chế truy cập an toàn cho thẻ. Nội dung chính như sau:
Trước khi quá trình trao đổi dữ liệu giữa thẻ và đầu đọc thẻ diễn ra thì cần xác thực rằng đầu đọc thẻ đó có quyền được đọc thông tin trong thẻ. Trong quá trình thực hiện BAC cả đầu đọc thẻ và thẻ phải sử dụng hai khóa KENC và KMAC, hai khóa này được tạo ra qua một loạt vòng băm dữ liệu sử dụng thuật toán SHA-1. Trước tiên trích 3 trường thông tin từ vùng MRZ ( Machine Readable Zone) đó là: Passport No, Date of birth và Date of expiry, sau đó 3 trường này sẽ được nối thành một chuỗi làm đầu vào cho vòng tạo khóa. Toàn bộ quá trình tạo 2 khóa trên được minh họa qua sơ đồ dưới đây:
Đầu tiên là quá trình trích rút các trường thông tin Passport No, Date of birth và Date of expiry.Kết thúc giai đoạn này ta thu đượcchuỗi ghép, ví dụ S=1220000016D6408125F1110078. Sau đó sẽ tiến hành băm SHA-1 để được khóa KSEED phục vụ cho quá trình tiếp theo.
CLA INS P1 P2 Lc Data in Le
Hình 3.7 – Tạo khóa KSEED
Trong sơ đồ hình vẽ trên có:
Passport No: 1220000016D
Date of birth: 6408125F
Date of expiry: 1110078
Tiếp theo bước trên, ghép khóa KSEED lần lượt với hai tham số C0 = 00 00 00 01và C1 = 00 00 00 02 làm giá trị đầu vào cho hai quá trình tạo khóa tương ứng KENC
và KMAC. Cụ thể theo sơ đồ dưới đây:
Hình 3.8 – Tạo cặp khóa KENC và KMAC
Hai khóa KENC và KMAC với 8 bytes cao được gọi là Ka và 8 bytes tiếp theo gọi là Kb. Cặp (Ka, Kb) được sử dụng trong mã hóa và giải mã TDES (Triple DES).
Cơ chế BAC thực hiện qua các bước sau:
Tại IFD:
B1. Đầu đọc thẻ gửi lệnh Get Challenge (Yêu cầu gửi RND.ICC) tới thẻ, nếu không gặp lỗi thì đầu đọc thẻ nhận về RND.ICC từ thẻ.
B2. Sinh cặp khóa (RND.IFD{0,1}64, KIFD{0,1}128) ngẫu nhiên, sau đó ghép thành chuỗi S = RND.IFD||RND.ICC||KIFD
B3. Tính toán mã hóa E_IFD = E[KENC](S) và tạo CheckSum M_IFD = MAC[KMAC](E_IFD).
B4. Gửi chuỗi E_IFD||M_IFD tới thẻ (Mutual Authenticate)
B5. Sau quá trình xử lý tương tự từ thẻ, đầu đọc nhận chuỗi E_ICC||M_ICC được gửi từ thẻ.
B6. Kiểm tra CheckSum M_ICC của E_ICC, sau đó giải mã R = De[KENC](E_ICC) rút KICC và RND.ICC từ R.
B7. Tính KSEED = KIFDKICC
Tại ICC:
B1. Sau khi nhận được thông điệp lệnh Get Challenge từ đầu đọc thẻ, nó tạo ra khóa ngẫu nhiên RND.ICC{0,1}64 và gửi lại cho đầu đọc thẻ.
B2. Sau khi nhận được thông điệp lệnh Mutual Authenticate từ đầu đọc, kiểm tra CheckSum M_IFD = MAC[KMAC](E_IFD)
B3. Giải mã S = De[KENC](E_IFD) rút KIFD và RND.IFD từ S B4. Tạo khóa ngẫu nhiên KICC{0,1}128
B5. Tạo chuỗi R = RND.ICC||RND.IFD||KICC
B6. Tính toán mã E_ICC = E[K_ENC](R ) và tạo Checksum M_ICC = MAC[KMAC]( E_ICC), sau đó gửi chuỗi E_ICC||M_ICC cho Reader B7. Tính KSEED = KIFDKICC
Sau quá trình này một khóa KSEED chung sẽ được thiết lập cho cả hai bên (IFD và ICC), trong mọi giao dịch sau này mỗi khi bên gửi gửi thông điệp lệnh hoặc bên nhận xử lý thông điệp lệnh nhận được đều tự động tăng giá trị KSEED lên 1 đơn vị. Điều này có thể chống được tấn công khóa chung KSEEDbằng thống kê.