Hạn chế chung
Để triển khai được Hộ chiếu điện tử tại Việt Nam thì các cơ quan có thẩm quyền phải giải quyết các vấn đề cơ bản sau:
- Hộ chiếu không phải do một cơ quan cấp mà hộ chiếu công vụ thì do Bộ ngoại giao cấp, hộ chiếu phổ thông thì do Bộ công an cấp. Vì vậy chúng ta phải thống nhất quản lý nó như thế nào.
- Cấp và kiểm soát Hộ chiếu điện tử tại các cửa khẩu lớn như Hà Nội, Thành phố Hồ Chí Minh thì không gặp nhiều khó khăn nhưng đối vói các cửa khẩu ở các tỉnh lẻ thì gặp rất nhiều khó khăn cả về công nghệ lẫn chi phí thực hiện.
- Việt Nam có dân số đông nên số lượng làm hộ chiếu cũng rất lớn. Vậy nên việc quản lý sẽ gặp nhiều khó khăn.
- Chi phí thực hiện rất lớn.
- Quản lý các dữ liệu sinh trắc như thế nào?
Từ những lý do nêu trên, luận văn sẽ đưa ra mô hình đề xuất hộ chiếu điện tử phù hợp với điều kiện thực tế của Việt Nam. Bước đầu thì mô hình này chỉ áp dụng cho công dân Việt Nam và sử dụng PKI riêng nhưng vẫn tuân theo các tiêu chuẩn của ICAO.
Quá trình cấp Hộ chiếu điện tử
Quá trình cấp phát hộ chiếu điện tử trải qua các bước sau:
Bước 1: Đăng ký cấp hộ chiếu theo mẫu do cơ quan cấp phát, quản lý hộ chiếu phát hành.
Bước 2: Kiểm tra nhân thân.
Bước 3: Thu nhận thông tin sinh trắc học gồm có ảnh khuôn mặt, ảnh vân tay, ảnh mống mắt. Tuy nhiên tùy thuộc vào ngữ cảnh và đối tượng tương ứng mà thu nhận các đặc điểm sinh trắc này.
Bước 4: Ghi thông tin vào chip RFID, in hộ chiếu.
-Ghi thông tin cơ bản như trên trang hộ chiếu giấy vào DG1.
-Ghi ảnh khuôn mặt vào DG2;
-Ghi ảnh hai vân tay vào DG3;
-Ghi hai ảnh hai mống mắt vào DG4.
-Ghi các thông tin khác khóa công khai PKRFIC phục vụ quá trình Chip
Authentication vào DG14, khóa bí mật SKRFIC phục vụ quá trình Chip
Authentication.
-Khóa công khai PKCVCA dùng cho quá trình Terminal Authentication vào bộ
nhớ bí mật.
-Ghi SOD tạo giá trị băm các nhóm thông tin theo thuật toán SHA. Tập tất cả
quan cấp hộ chiếu ta được chữ ký trên SOLDS ký hiệu là SOD.Signature. Cấu trúc của SOD là (SOLDS, SOD, .... , SOD.cert) trong đó SOD.cert là các chứng thư số, CDS
là các chứng thư số của cơ quan ký hộ chiếu. Phần thông tin này phục vụ Passive Authentication.
Quá trình xác thực hộ chiếu điện tử
Quá trình kiểm tra, xác thực hộ chiếu điện tử tại các cửa khẩu được thực hiện theo các bước sau:
Bước 1: Người mang hộ chiếu xuất trình hộ chiếu cho cơ quan kiểm tra, cơ quan tiến hành thu nhận các đặc tính sinh trắc học từ người xuất trình hộ chiếu.
Bước 2: Kiểm tra các đặc tính bảo mật trên trang hộ chiếu giấy thông qua các đặc điểm an ninh truyền thống: thủy ấn, dải quang học, hoặc lớp bảo vệ ảnh.
Bước 3: Hệ thống FRIC thực hiện quá trình BAC, sau khi BAC thành công hệ thống có thể đọc các thông tin trong chip. Mọi thông tin trao đổi giữa đầu đọc và chip được truyền thông qua mã hóa sau đó là xác thực theo cặp khóa.
Bước 4: Thực hiện xác thực bị động Passive Authentication để kiểm tra tính xác thực và toàn vẹn của các thông tin lưu trong chip thông qua kiểm tra chữ ký trong SOD bằng khoá công khai của cơ quan cấp hộ chiếu.
Bước 5: Quá trình Terminal Authentication chứng minh quyền truy cập thông tin của hệ thống đến thông tin sinh trắc học. Chỉ thực hiện đối với những cơ quan kiểm tra hộ chiếu triển khai EAC. Sau khi Terminal Authentication thành công, đầu đọc có thể truy cập thông tin theo quyền thể hiện trong chứng thư số.
Bước 6: Hệ thống thực hiện so sánh thông tin sinh trắc học thu nhận được trực tiếp từ người xuất trình hộ chiếu với thông tin sinh trắc học lưu trong chip.
Bước 7: Nếu quá trình so sánh thành công và kết hợp với các chứng thực trên, cơ quan kiểm tra hộ chiếu có đủ điều kiện để tin tưởng hộ chiếu là xác thực và người mang hộ chiếu đúng là con người mô tả trong hộ chiếu.
LDS CDS--->SOD. cert.
Hình 3.2: Quá trình cấp phát hộ chiếu điện tử
Hình 3.3: Quá trình xác thực hộ chiếu
3.2. Đặc tả yêu cầu cho HCĐT
Có ba vấn đề quan trọng khi làm việc với HCĐT, đó là: Cấu trúc dữ liệu được tổ chức trong HCĐT, tập giao thức truyền thông giữa HCĐT với các thiết bị đọc/ ghi và bảo mật truy cập dữ liệu trong HCĐT. Hiện nay trên thị trường HCĐT đã xuất hiện loại HCĐT cho phép thực thi các đoạn mã Java, vì vậy các nhà phát triển có thể viết những
ứng dụng cho riêng mình một cách linh hoạt cao, việc này đơn giản chỉ là họ tự tạo ra ra các ứng dụng Applet viết bằng ngôn ngữ Java và cài đặt vào HCĐT để chạy. Tuy nhiên, trong phạm vi luận văn này sẽ không sử dụng loại HCĐT JavaCard để phát triển ứng dụng cho hệ thống.
Cấu trúc dữ liệu cho HCĐT
Để các HCĐT 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 HCĐT và giao thức giữa HCĐT đó với đầu đọc HCĐT 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 HCĐT 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 HCĐT.
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 HCĐT. 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ủ HCĐT
Bảo đảm tính bảo mật cho các thông tin ghi trong HCĐT
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ập các đề mục trong HCĐT 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.
Từng thông tin cá nhân của chủ sở hữu HCĐT cũng như những thông tin bổ sung 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
Hình 3.4: Cấu trúc dữ liệu tổ chức trong HCĐT 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-7 Lưu trữ các ảnh hiển thị như chân dung (Portrail), khuôn mặt
(Future Use) và đặc điểm nhận dạng (Usual Mark) hay 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).
Để 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
-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 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 xả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ổ sung thêm các thành phần Data 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.
Hình 3.5 – 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.6 – Cấu trúc logic của Data Element
HCĐT được dùng để bao bọc các khối thông tin, mã HCĐT 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 HCĐT có HCĐT bao bọc lẫn nhau, có nghĩa là trường giá trị của HCĐT có thể là một HCĐT khác. Cấu trúc một Tag gồm 3 trường: Mã HCĐT, độ dài trường dữ liệu tính theo đ.v byte và dữ liệu:
Tag code L (Length) Value
Các DG và DE được coi là các đối tượng dữ liệu và được bọc trong các HCĐT với mã tương ứng.
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’
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’
Hình 3.7: Cấu trúc hệ thống file Trong sơ đồ trên thông điệp lệnh có định dạng:
CLA IN S
Hình 3.8: Định dạng thông điệp lệnh truyền giữa HCĐT và thiết bị đọc/ ghi 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
Định dạng thông điệp lệnh dạng chi tiết như sau:
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 xảy ra. Chuẩn ISO 7816-3 định nghĩa
5 lỗi như sau:
SW1 = 6E: Cho biết HCĐT 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.
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 HCĐT, đó 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 HCĐT. Nội dung chính như sau:
Đầ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 expire. Kết thúc giai đoạn này ta thu được chuỗi ghép, như 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.
Trong sơ đồ hình vẽ trên có:
Passport No: 1220000016D
Date of birth: 6408125F
Date of expire: 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 01 và
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.10 – 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ả mã TDES (Triple DES).
Cơ chế BAC thực hiện qua các bước sau:
Tại IFD
B1. Đầu đọc HCĐT gửi lệnh Get Challenge (Yêu cầu gửi RND.ICC) tới HCĐT,
nếu không gặp lỗi thì đầu đọc HCĐT nhận về RND.ICC từ HCĐT.
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 HCĐT (Mutual Authenticate)
B5. Sau quá trình xử lý tương tự từ HCĐT, đầu đọc nhận chuỗi E_ICC||M_ICC
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 KSseed = KIFD ⊕KICC
Tại ICC
B1. Sau khi nhận được thông điệp lệnh Get Challenge từ đầu đọc HCĐT, nó tạo ra
khóa ngẫu nhiên RND.ICC∈{0,1}64
và gửi lại cho đầu đọc HCĐT.
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 KSseed = KIFD ⊕KICC
Sau quá trình này một khóa KSseed chung sẽ được thiết lập cho cả hai bên (IFD và
ICC), 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ị KSseed lên 1 đơn vị. Điều này có thể chống được tấn
công khóa chung KSseed bằng thống kê.
3.2.1. Đặc tả yêu cầu cho module tạo HCĐT
Module tạo HCĐT cần có các chức năng cơ bản sau đây:
Ghi dữ liệu lên HCĐT 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 HCĐT.
Theo như phần trên, dữ liệu trong HCĐT đượ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 HCĐT 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.
Tạo chữ ký số lên dữ liệu của HCĐT
Chữ ký số là thông tin đi kèm theo dữ liệu chứa trong HCĐT (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ủ