TIÊU CHUẨN QUỐC GIA TCVN 11198-3:2015 VỀ THẺ MẠCH TÍCH HỢP EMV CHO HỆ THỐNG THANH TOÁN – ĐẶC TẢ ỨNG DỤNG THANH TOÁN CHUNG – PHẦN 1: QUY TRÌNH XỬ LÝ CHỨC NĂNG
TIÊU CHUẨN QUỐC GIA
TCVN 11198-3:2015
THẺ MẠCH TÍCH HỢP EMV CHO HỆ THỐNG THANH TOÁN – ĐẶC TẢ ỨNG DỤNG THANH TOÁN CHUNG – PHẦN 3: QUY TRÌNH XỬ LÝ CHỨC NĂNG
EMV integrated circuit card for payment systems – Common payment application specification – Part 3: Function processing
Lời nói đầu
TCVN 11198-3:2015 được xây dựng trên cơ sở tham khảo EMV CPA (Common Payment Application Specification) Version 1.0, 2005.
TCVN 11198-3:2015 do Ban Kỹ thuật tiêu chuẩn quốc gia TCVN/JTC1/SC 17 Thẻ nhận dạng biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.
Bộ tiêu chuẩn TCVN 11198 Thể mạch tích hợp EMV cho hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung gồm các tiêu chuẩn sau:
– TCVN 11198-1:2015, Phần 1: Tổng quát;
– TCVN 11198-2:2015, Phần 2: Giới thiệu về quy trình xử lý;
– TCVN 11198-3:2015, Phần 3: Quy trình xử lý chức năng;
– TCVN 11198-4:2015, Phần 4: Phân tích hành động thẻ;
– TCVN 11198-5:2015, Phần 5: Quy trình xử lý tập lệnh bên phát hành đến thẻ;
– TCVN 11198-6:2015, Phần 6: Quản lý khóa và an ninh;
– TCVN 11198-7:2015, Phần 7: Mô tả về chức năng;
– TCVN 11198-8:2015, Phần 8: Thư mục phần tử dữ liệu;
THẺ MẠCH TÍCH HỢP EMV CHO HỆ THỐNG THANH TOÁN – ĐẶC TẢ ỨNG DỤNG THANH TOÁN CHUNG – PHẦN 3: QUY TRÌNH XỬ LÝ CHỨC NĂNG
EMV Integrated Circuit Card for Payment Systems – Common payment application specification – Part 3: Function Processing
1. Phạm vi áp dụng
Tiêu chuẩn TCVN 11198-3 là một phần thuộc bộ TCVN 11198 cung cấp các đặc tả kỹ thuật về phần ứng dụng Thanh toán Chung (CPA), định nghĩa các phần tử dữ liệu và các chức năng cho ứng dụng tương thích với Định nghĩa Lõi Chung (CCD) EMV.
Phạm vi của tiêu chuẩn này đề cập về các quy trình xử lý chức năng:
• Lựa chọn Ứng dụng (Điều 5);
• Quy trình Khởi tạo Ứng dụng (Điều 6);
• Đọc Dữ liệu Ứng dụng (Điều 7);
• Xác thực Dữ liệu Ngoại tuyến (Điều 8);
• Ràng buộc Xử lý (Điều 9);
• Xác minh Chủ thẻ (Điều 10);
• Quản lý Rủi ro Thiết bị đầu cuối (Điều 11);
• Phân tích hành động thiết bị đầu cuối (Điều 12).
2. Tài liệu viện dẫn
Các tài liệu viện dẫn sau đây rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).
TCVN 11198-1:2015, Thẻ mạch tích hợp EMV cho Hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung – Phần 1: Tổng quát;
3. Thuật ngữ và định nghĩa
Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa nêu trong TCVN 11198-1:2015.
4. Thuật ngữ viết tắt, ký hiệu, quy ước và biểu tượng
Tiêu chuẩn này sử dụng các thuật ngữ viết tắt, ký hiệu, quy ước định dạng phần tử dữ liệu và biểu tượng nêu trong TCVN 11198-1:2015.
5. Lựa chọn ứng dụng
5.1. Mục đích
Lựa chọn ứng dụng là một chức năng không phụ thuộc ứng dụng được thực hiện bởi thẻ và thiết bị đầu cuối để lựa ra các ứng dụng mà được hỗ trợ bởi cả thẻ và thiết bị đầu cuối và sẽ được sử dụng để thực hiện giao dịch.
5.2. Trình tự thực hiện
5.2.1. Quy trình xử lý có liên quan tiếp theo
Quy trình Khởi tạo Ứng dụng
Nếu có hỗ trợ tùy chọn bộ thực thi Lựa chọn Hồ sơ sử dụng Dữ liệu Thẻ, thì thẻ nhận diện các tham số mà sẽ được sử dụng cho cuộc giao dịch trong khi Khởi tạo Ứng dụng.
Nếu thẻ yêu cầu dữ liệu thiết bị đầu cuối trong khi Khởi tạo Ứng dụng, Danh sách Đối tượng Dữ liệu Tùy chọn quy trình xử lý (PDOL) có bao gồm trong hồi đáp SELECT trong khi Lựa chọn Ứng dụng. PDOL là một danh sách gồm các thẻ (tag) và chiều dài của các đối tượng dữ liệu thường trú ở thiết bị đầu cuối cần có cho thẻ trong quy trình xử lý lệnh GET PROCESSING OPTIONS trong suốt Quy trình Khởi tạo Ứng dụng. Lệnh GET PROCESSING OPTIONS được gửi đến thẻ bởi thiết bị đầu cuối bao gồm bất kỳ dữ liệu thiết bị đầu cuối nào đã được quy định trong PDOL. Nếu thẻ không yêu cầu dữ liệu thiết bị đầu cuối trong khi Khởi tạo Ứng dụng, PDOL không cần có trong hồi đáp SELECT.
Nếu ứng dụng được chọn không thể khởi động, thiết bị đầu cuối chấm dứt ứng dụng đó và trả về đến Lựa chọn Ứng dụng để lựa chọn ứng dụng khác.
5.3. Quy trình xử lý
Quy trình xử lý được thực hiện bởi thiết bị đầu cuối và thẻ để xây dựng danh sách các ứng viên ứng dụng như mô tả trong EMV. Lựa chọn ứng dụng thực hiện theo hai bước:
1. Thiết bị đầu cuối xây dựng một danh sách ứng viên về các ứng dụng được hỗ trợ lẫn nhau.
2. Một ứng dụng đơn từ trong danh sách này được nhận diện và lựa chọn cho quy trình xử lý giao dịch.
Thiết bị đầu cuối gửi lệnh SELECT đến thẻ để nhận thông tin trên ứng dụng được hỗ trợ bởi thẻ. Thông tin ứng dụng có thể bao gồm các tham chiếu bên phát hành như tính ưu tiên của ứng dụng được chọn, tên ứng dụng và ngôn ngữ tham khảo. Lệnh hoặc có chứa tên thư mục Môi trường hệ thống thanh toán (được sử dụng cho phương thức PSE) hoặc một AID đã được yêu cầu (sử dụng cho Danh sách phương thức AID và cho lựa chọn ứng dụng cuối cùng).
Lựa chọn Ứng dụng được thực hiện như mô tả cho ứng dụng tương thích CCD trong EMV Quyển 1, Điều 12 và EMV Quyển 4, Điều 11.3.
5.3.1. Xây dựng Danh sách Ứng viên
Có hai phương thức tiếp cận được sử dụng bởi thiết bị đầu cuối để xây dựng một danh sách các ứng dụng được hỗ trợ lẫn nhau.
• Phương thức PSE được mô tả trong EMV Quyển 1, Điều 12.3.2. Phương thức này là tùy chọn đối với thẻ và thiết bị đầu cuối, nhưng nếu được hỗ trợ bởi thiết bị đầu cuối thì đây là lần thử đầu tiên.
• Trong phương thức PSE, thiết bị đầu cuối lựa chọn Môi trường Hệ thống Thanh toán và đọc Thư mục Hệ thống Thanh toán từ thẻ sử dụng lệnh READ RECORD được mô tả trong EMV Quyển 1, điều 11.2. Tệp tin này là một danh sách của các ứng dụng thanh toán được hỗ trợ bởi thẻ. Thiết bị đầu cuối thêm vào bất kỳ ứng dụng nào được liệt kê trong cả danh sách thẻ và danh sách thiết bị đầu cuối cho danh sách ứng cử.
• Danh sách phương thức của AID được mô tả trong EMV Quyển 1, Điều 12.3.3. Việc hỗ trợ của phương thức này là bắt buộc cho các thẻ và thiết bị đầu cuối. Trong danh sách phương thức của AID, thiết bị đầu cuối phát một lệnh SELECT cho từng ứng dụng được hỗ trợ bởi thiết bị đầu cuối. Nếu hồi đáp thẻ chỉ ra rằng ứng dụng là được hỗ trợ bởi thẻ, thiết bị đầu cuối thêm ứng dụng vào danh sách ứng cử.
CHÚ THÍCH: Việc Lựa chọn từng Phần được hỗ trợ cho CPA. Xem phần CCD của EMV Quyển 1 cho yêu cầu lựa chọn ứng dụng.
5.3.2. Định danh và Lựa chọn Ứng dụng
Nếu tồn tại ít nhất một ứng dụng được hỗ trợ lẫn nhau trên Danh sách ứng cử, thiết bị đầu cuối và chủ thẻ xác định ứng dụng được sử dụng.
CHÚ THÍCH: Bên phát hành phải nhận thức rằng thiết lập ứng dụng của họ cần sự xác nhận bởi chủ thẻ (xem EMV Quyển 1, điều 12.4) nghĩa rằng ứng dụng có thể không được lựa chọn bởi thiết bị đầu cuối khi không hỗ trợ hoặc Xác nhận Chủ thẻ hoặc Lựa chọn Chủ thẻ.
Việc có thể là một thiết bị đầu cuối đặc biệt lựa chọn một ứng dụng mà đã bị khóa để mở khóa ứng dụng. Nếu việc này xảy ra, thẻ sẽ trả về một AAC (từ chối ngoại tuyến) trong hồi đáp lệnh GENERATE AC. Thẻ hồi đáp một lệnh SELECT với SW1 SW2 = ‘9000’ nếu thẻ xác định rằng giao dịch có thể được thực hiện với ứng dụng đó.
Nếu ứng dụng bị khóa, thẻ sẽ không tiếp tục quy trình xử lý lệnh SELECT và hồi đáp với SW1 SW2 = ‘6283’ (tệp tin đã chọn không hợp lệ).
Nếu thẻ bị khóa, thẻ sẽ không tiếp tục quy trình xử lý lệnh SELECT và hồi đáp với SW1 SW2 = ‘6A81’ (chức năng được hỗ trợ).
Nếu thẻ có chứa một PDOL, đây là một phần của dữ liệu FCI trong hồi đáp SELECT. Thiết bị đầu cuối gửi dữ liệu được quy định trong PDOL đến thẻ trong suốt Quy trình Khởi tạo Ứng dụng.
Req 3.5.1 (chiều dài FCI được hỗ trợ):
CPA phải có khả năng hồi đáp với một FCI có chiều dài lên đến 240 bytes.
Các yêu cầu cho việc cá thể hóa cho PDOL mà cần thiết hỗ trợ chức năng CPA được quy định trong Điều 7, TCVN 11198-6.
Nếu có hỗ trợ tùy chọn bên triển khai có Lựa chọn Hồ sơ sử dụng Dữ liệu Thẻ, thì thẻ xác định rằng nội dung trong bản mẫu các Tham số GPO sẽ được sử dụng cho giao dịch trong khi Khởi tạo Ứng dụng. Các phương thức được sử dụng để lựa chọn nội dung trong các tham số GPO, và để chỉ ra ứng dụng mà Tham số GPO x được sử dụng cho giao dịch tuân theo phạm vi của ứng dụng.
Req 3.5.2 (Tùy chọn bên triển khai có Lựa chọn Hồ sơ sử dụng dữ liệu thẻ):
Ít nhất, thẻ hỗ trợ tùy chọn bên triển khai có Lựa chọn Hồ sơ sử dụng Dữ liệu Thẻ phải có khả năng có liên quan từng Định danh Ứng dụng – thẻ (AID, thể tag ‘4F’) được sử dụng để lựa chọn ứng dụng với một nội dung khác với trong bản mẫu các Tham số GPO.
6. Quy trình Khởi tạo Ứng dụng
6.1. Mục đích
Trong suốt Quy trình Khởi tạo Ứng dụng, thiết bị đầu cuối ký xác nhận với thẻ rằng quy trình xử lý giao dịch đang bắt đầu. Thiết bị đầu cuối thực hiện công việc này bằng cách gửi đi lệnh GET PROCESSING OPTIONS đến thẻ.
Khi phát lệnh này, thiết bị đầu cuối hỗ trợ thẻ với bất kỳ phần tử dữ liệu nào được yêu cầu bởi thẻ trong Danh sách Đối tượng Dữ liệu Tùy chọn Quy trình (PDOL). PDOL (một danh sách các thẻ tag và chiều dài của các phần tử dữ liệu) là tùy chọn được cung cấp bởi thẻ cho thiết bị đầu cuối trong khi Lựa chọn Ứng dụng.
Trong quy trình xử lý lệnh GET PROCESSING OPTIONS, ứng dụng thực hiện Lựa chọn Hồ sơ, việc này cho phép mở ứng dụng chức năng ứng dụng khác tùy theo môi trường giao dịch.
Sau khi Lựa chọn Hồ sơ, thẻ hồi đáp lệnh GET PROCESSING OPTIONS với Hồ sơ hoán đổi ứng dụng (AIP), một danh sách các chức năng có thể thực hiện trong quy trình xử lý giao dịch.
Thẻ cũng cung cấp Vị trí Tệp tin Ứng dụng (AFL), một danh sách các tệp tin và bản ghi mà thiết bị đầu cuối cần thiết khi đọc thẻ.
Quy trình Khởi tạo Ứng dụng được thực hiện như mô tả trong Điều 10.1, EMV Quyển 3.
6.2. Trình tự thực hiện
Đây là chức năng đầu tiên được thực hiện sau khi lựa chọn ứng dụng.
6.2.1. Quy trình xử lý có liên quan trước đó
Lựa chọn Ứng dụng
Thẻ hỗ trợ PDOL (nếu có) cho thiết bị đầu cuối như một phần của FCI được cung cấp trong hồi đáp cho lệnh SELECT.
Nếu được hỗ trợ tùy chọn bên thực hiện Lựa chọn Hồ sơ sử dụng Dữ liệu Thẻ, sau khi thẻ nhận diện các tham số sẽ được sử dụng cho giao dịch trong khi Khởi tạo Ứng dụng.
6.2.2. Quy trình xử lý có liên quan tiếp theo
Lựa chọn Ứng dụng
Nếu quy trình xử lý lệnh GET PROCESSING OPTIONS xác định rằng ứng dụng bị ràng buộc khi sử dụng, thẻ hồi đáp cho phép thiết bị đầu cuối gửi trả đến Lựa chọn Ứng dụng một lựa chọn ứng dụng khác.
Đọc dữ liệu Ứng dụng
AFL được cung cấp bởi thẻ trong hồi đáp đến lệnh GET PROCESSING OPTIONS được sử dụng bởi thiết bị đầu cuối để xác định các dữ liệu ứng dụng để đọc từ thẻ và dữ liệu được sử dụng trong việc Xác thực Dữ liệu Ngoại tuyến.
Xác thực Dữ liệu Ngoại tuyến
Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong hồi đáp đến lệnh GET PROCESSING OPTIONS để xác định các mẫu Xác thực Dữ liệu Ngoại tuyến được hỗ trợ từ ứng dụng.
Xác minh Chủ thẻ
Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong hồi đáp lệnh GET PROCESSING OPTIONS để xác định khi nào ứng dụng hỗ trợ Xác minh Chủ thẻ. Chuỗi các phương thức xác minh được đưa ra trong Danh sách CVM có chứa trong dữ liệu bản ghi được đọc bởi thiết bị đầu cuối.
Quản lý Rủi ro Thiết bị đầu cuối
Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong hồi đáp cho lệnh GET PROCESSING OPTIONS để xác định khi nào thiết bị đầu cuối phải thực hiện Quản lý Rủi ro Thiết bị đầu cuối. Thiết bị đầu cuối có thể thực hiện Quản lý Rủi ro Thiết bị đầu cuối không liên quan đến thiết lập các bit trong AIP.
Phân tích Hành động Thẻ lần Đầu
Ứng dụng sử dụng các tùy chọn được lựa chọn trong suốt Quy trình Khởi tạo Ứng dụng để kiểm soát chức năng quản lý rủi ro thẻ có thể cấu hình được đang thực hiện như là một phần quy trình xử lý lệnh GENERATE AC đầu tiên. Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong hồi đáp GET PROCESSING OPTIONS để xác định khi nào lệnh GENERATE AC đầu tiên có thể yêu cầu CDA.
Quy trình xử lý lệnh Trực tuyến
Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong hồi đáp cho lệnh GET PROCESSING OPTIONS để xác định khi nào ứng dụng hỗ trợ việc Xác thực bên Phát hành có sử dụng lệnh EXTERNAL AUTHENTICATE.
CHÚ THÍCH: CPA không sử dụng lệnh EXTERNAL AUTHENTICATE. Đối với CPA, việc Xác thực bên Phát hành được kết hợp trong quy trình xử lý lệnh GENERATE AC lần hai.
Phân tích Hành động Thẻ lần Hai
Ứng dụng sử dụng các tùy chọn được lựa chọn trong suốt Quy trình Khởi tạo Ứng dụng để kiểm soát chức năng quản lý rủi ro thẻ có thể cấu hình được đang thực hiện như là một phần quy trình xử lý lệnh GENERATE AC thứ hai. Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong hồi đáp GET PROCESSING OPTIONS để xác định khi nào lệnh GENERATE AC thứ hai có thể yêu cầu CDA.
6.3. Dữ liệu thẻ
Dữ liệu thẻ được sử dụng trong Quy trình Khởi tạo Ứng dụng được liệt kê và được mô tả trong Bảng 1. Đối với mô tả chi tiết về dữ liệu này và cách sử dụng đã đề cập trong Điều 7, TCVN 11198-8.
Bảng 1 – Quy trình Khởi tạo Ứng dụng – Dữ liệu Thẻ
Dữ liệu |
Mô tả |
Bản mẫu |
Thẻ tag |
||
Mục AIP/AFL x | Bao gồm một AIP, chiều dài AFL và một AFL, và có thể được chọn sử dụng Chức năng Lựa chọn Hồ sơ.
Mục dữ liệu này cho phép việc lựa chọn một số chức năng ứng dụng mà dựa trên một kiểm thử các thuộc tính giao dịch |
‘BF41’ |
‘DF0x’ |
||
Kiểm soát Ứng dụng | Các chỉ báo được sử dụng để kích hoạt hoặc tắt các chức năng trong ứng dụng |
– |
‘C1’ |
||
Kết quả Quyết định Ứng dụng (ADR) | Các chỉ báo được sử dụng nội bộ để ứng dụng nhận diện các điều kiện ngoại lệ mà có mặt trong các giao dịch hiện thời và trước đó.
Mã Hành động bên Phát hành Thẻ (CIAC) được so sánh với các Kết quả Quyết định Ứng dụng để đưa ra các quyết định liên quan đến khi nào chấp nhận hoặc từ chối giao dịch ngoại tuyến, hoặc yêu cầu thực hiện trực tuyến |
– |
– |
||
Định vị Tệp tin Ứng dụng AFL | Chỉ ra vị trí tệp tin và dải các báo cáo mà có chứa dữ liệu thẻ sẽ được đọc bởi thiết bị đầu cuối để sử dụng trong quy trình xử lý giao dịch. Đối với từng tệp tin được đọc, AFL có chứa các thông tin sau:
Byte 1 (b8-b4) Định danh tệp tin ngắn (một nhãn dạng số cho tệp tin) Byte 2 Số bản ghi của bản ghi đầu tiên để đọc Byte 3 Số bản ghi của bản ghi cuối cùng để đọc Byte 4 Số bản ghi liên tiếp có chứa dữ liệu được sử dụng trong Xác thực Dữ liệu Ngoại tuyến bắt đầu với bản ghi đầu tiên được đọc như trong Byte 2 |
– |
’94’ |
||
Hồ sơ Hoán đổi Ứng dụng AIP | Một danh sách cho biết khả năng của ứng dụng có hỗ trợ các chức năng cụ thể trong ứng dụng (SDA, DDA, CDA, Quản lý Rủi ro Thiết bị đầu cuối, Xác minh Chủ thẻ và Xác thực bên Phát hành) |
– |
’82’ |
||
Bộ đếm Giao dịch Ứng dụng ATC | Bộ đếm giao dịch được chỉ ra cho ứng dụng |
– |
‘9F36’ |
||
Kết quả Xác minh Chủ thẻ CVR | Có chứa các chỉ báo được lập trong cuộc giao dịch hiện thời để cho biết các điều kiện quản lý rủi ro thẻ có xuất hiện trên thẻ.
Giá trị dữ liệu này bắt đầu từ không trong Quy trình Khởi tạo Ứng dụng. |
|
‘9F52’ |
||
Các Tham số GPO x | Có chứa hai tham số được sử dụng trong quy trình xử lý lệnh GPO:
• Chiều dài Dữ liệu Lệnh GPO • Đa dạng Lựa chọn Hồ sơ |
‘BF3E’ |
’DF0x’ |
||
Chiều dài Dữ liệu Lệnh GPO | Giá trị được kỳ vọng trong thẻ đối với chiều dài của trường dữ liệu trong bản mẫu GET PROCESSING OPTIONS được gửi bởi thiết bị đầu cuối. | ||||
Đa dạng Lựa chọn Hồ sơ | Một chỉ thị cho dữ liệu thẻ có liên quan đến ứng dụng tại thời điểm lựa chọn, được sử dụng để hỗ trợ việc lựa chọn hồ sơ dựa trên dữ liệu thẻ | ||||
Lịch sử Giao dịch trước đó (PTH) | Có chứa các chỉ báo rằng định danh cho các giao dịch tiếp theo mà các sự kiện chắc chắn xảy ra; ví dụ như ứng dụng đang bị khóa, Xác thực bên Phát hành bị lỗi hoặc bên phát hành được yêu cầu rằng thẻ sẽ tiến hành trực tuyến vào lần giao dịch tiếp theo |
– |
‘C7’ |
||
Danh sách Đối tượng Dữ liệu Tùy chọn Quy trình xử lý (PDOL) | PDOL là danh sách các thẻ tag và chiều dài của các đối tượng dữ liệu thường trú ở thiết bị đầu cuối cần thiết cho ứng dụng trong quy trình xử lý lệnh GET PROCESSING OPTIONS trong suốt Quy trình Khởi tạo Ứng dụng |
– |
‘9F38’ |
||
Kiểm soát Hồ sơ x | Các chỉ thị mà các nguồn ứng dụng đã được sử dụng khi quy trình xử lý giao dịch với ID Hồ sơ x. Chỉ các hạng mục trong phần tử dữ liệu Kiểm soát Hồ sơ x được sử dụng trong suốt Quy trình Khởi tạo Ứng dụng như sau: |
|
|
||
ID mục AIP/AFL | Các chỉ thị Mục AIP/AFL x được sử dụng trong quy trình xử lý giao dịch | ||||
ID Hồ sơ | Các chỉ thị hồ sơ được sử dụng cho giao dịch; có liên quan tới một mô tả của các hành động tùy chọn ứng dụng và dữ liệu được chọn để sử dụng trong quy trình xử lý một giao dịch |
– |
– |
||
Tệp tin Lựa chọn Hồ sơ | Một tệp tin được cá thể hóa trên thẻ mà được sử dụng với dữ liệu liên quan tới PDOL để xác định hồ sơ nào được sử dụng cho giao dịch.
Ứng dụng so sánh dữ liệu ứng dụng với dữ liệu có liên quan tới PDOL nhận được trong lệnh GET PROCESSING OPTIONS từ thiết bị đầu cuối để lựa chọn hồ sơ. Hồ sơ xác định một số các hành động thẻ bao gồm AIP và AFL được trả về trong hồi đáp GET PROCESSING OPTIONS, bộ đếm và hành vi của thanh ghi và các tham số ra quyết định của thẻ |
|
|
||
Các Mục Lựa chọn Hồ sơ | Các hồ sơ trong Tệp tin Lựa chọn Hồ sơ mà có chứa dữ liệu và logic cho một bước trong quy trình lựa chọn hồ sơ | ||||
Ứng dụng sử dụng các phần tử dữ liệu sau để xử lý và hồi đáp lệnh GET PROCESSING OPTIONS: các Mục nhập AIP/AFL, Bộ đếm Giao dịch Ứng dụng ATC, Dữ liệu lệnh GPO, Chiều dài Dữ liệu lệnh GPO trong các tham số GPO, các Kiểm soát Hồ sơ, và số ID Hồ sơ.
Nếu ứng dụng có sử dụng dữ liệu có nguồn từ thiết bị đầu cuối trong lựa chọn AIP và AFL cho hồi đáp lệnh GET PROCESSING OPTIONS, ứng dụng cũng sử dụng các phần tử dữ liệu sau để thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ: PDOL, Đa dạng Lựa chọn Hồ sơ trong các tham số GPO, và các Mục Lựa chọn Hồ sơ trong Tệp tin Lựa chọn Hồ sơ.
6.4. Dữ liệu Thiết bị đầu cuối
Dữ liệu thiết bị đầu cuối được sử dụng trong Quy trình Khởi tạo Ứng dụng được liệt kê và mô tả như trong Bảng 2.
Đối với một mô tả chi tiết cho các dữ liệu này và việc sử dụng chúng xem Điều 7, TCVN 11198-8.
Bảng 2 – Quy trình Khởi tạo Ứng dụng – Dữ liệu Thiết bị đầu cuối
Dữ liệu |
Mô tả |
Bản mẫu |
Thẻ tag |
Dữ liệu lệnh GPO | Ứng dụng có thể sử dụng bất kỳ phần tử dữ liệu nào có thể được yêu cầu từ thiết bị đầu cuối (sử dụng PDOL) cho Quy trình xử lý Lựa chọn Hồ sơ |
– |
– |
Chỉ báo thiết bị hỗ trợ VLP | Một phần tử dữ liệu mà (nếu có trong thiết bị đầu cuối) cho biết rằng thiết bị đầu cuối hỗ trợ quy trình xử lý VLP |
– |
‘9F7A’ |
6.5. Lệnh GET PROCESSING OPTIONS
Lệnh GPO (GET PROCESSING OPTIONS) được sử dụng bởi thiết bị đầu cuối để ký xác nhận cho ứng dụng rằng quy trình xử lý ứng dụng đang bắt đầu.
Lệnh có chứa một phần giá trị của các phần tử dữ liệu thiết bị đầu cuối được yêu cầu bởi ứng dụng trong Danh sách Đối tượng Dữ liệu Tùy chọn Quy trình (PDOL) mà có tùy chọn cung cấp đến thiết bị đầu cuối bởi thẻ trong khi Lựa chọn Ứng dụng. PDOL cũng quy định số lượng byte được gửi đến từng phần tử dữ liệu đã yêu cầu.
Thẻ hồi đáp theo Định dạng 2 và như mô tả trong Điều 6.5.8.4 của phần CCD của EMV Quyển 3. Việc này chỉ bao gồm Hồ sơ Hoán đổi Ứng dụng AIP quy định các chức năng được hỗ trợ bởi thẻ và Định vị Tệp tin Ứng dụng AFL quy định các tệp tin và bản ghi được sử dụng cho giao dịch.
6.5.1. Mã hóa Lệnh
Bảng 3 – Thông điệp lệnh GET PROCESSING OPTIONS
Mã |
Giá trị |
CLA | ’80’ |
INS | ‘A8’ |
P1 | ’00’ |
P2 | ’00’ |
Lc | Var. |
data | Dữ liệu có liên quan tới PDOL |
Le | ‘00‘ |
Dữ liệu lệnh có chứa giá trị trong thiết bị đầu cuối của phần tử dữ liệu sở hữu thẻ tag và chiều dài được liệt kê trong PDOL, nếu PDOL được gửi từ thiết bị đầu cuối trong hồi đáp SELECT.
Dữ liệu có liên quan tới PDOL theo bản mẫu lệnh ’83’ và nó được giải bởi ứng dụng như có chứa dữ liệu được mô tả trong Bảng 4.
Bảng 4 – Dữ liệu liên quan tới PDOL
Tên |
Thẻ tag |
Chiều dài |
Giá trị |
Dữ liệu liên quan tới PDOL |
’83’ |
Chiều dài bản mẫu GPO |
Dữ liệu lệnh GPO |
Req 3.6.1 (chiều dài được hỗ trợ cho dữ liệu lệnh GPO):
Tại điểm tối thiểu, ứng dụng phải hỗ trợ chiều dài Dữ liệu liên quan tới PDOL trong dải từ 2 đến 128 byte.
6.5.1.1. Xác minh Định dạng Lệnh
Nếu có hỗ trợ tùy chọn bên thực thi Lựa chọn Hồ sơ có sử dụng Dữ liệu Thẻ, thì tại thời điểm của lựa chọn cuối cùng về ứng dụng, thẻ lựa ra Tham số GPO x để sử dụng cho giao dịch trong khi Khởi tạo Ứng dụng. Nếu có hỗ trợ tùy chọn bên thực thi Lựa chọn Hồ sơ có sử dụng Dữ liệu Thẻ, thì phương thức giao dịch tùy theo phạm vi của ứng dụng.
Req 3.6.2 (Mục Tham số GPO mặc định):
Nếu không có hỗ trợ tùy chọn bên thực thi Lựa chọn Hồ sơ có sử dụng Dữ liệu Thẻ, thì Tham số GPO x được sử dụng cho giao dịch trong khi Khởi tạo Ứng dụng phải là Tham số GPO 1 (với thẻ tag ‘DF01’ trong bản mẫu ‘BF3E’).
Req 3.6.3 (Kiểm tra giá trị P1 cho lệnh GPO):
Nếu tham số P1 có chứa một giá trị khác với ’00’ thì thẻ phải chấm dứt quy trình xử lý lệnh GPO, phải hồi đáp với một SW1 SW2 chỉ ra lỗi, và phải hồi đáp với SW1 SW2 = ‘6A86’ (tham số không chính xác, P1-P2).
Req 3.6.4 (Kiểm tra giá trị P2 cho lệnh GPO):
Nếu tham số P2 có chứa một giá trị khác với ’00’ thì thẻ phải chấm dứt quy trình xử lý lệnh GPO, phải hồi đáp với một SW1 SW2 chỉ ra lỗi, và phải hồi đáp với SW1 SW2 = ‘6A86’ (tham số không chính xác, P1-P2).
Req 3.6.5 (Kiểm tra chiều dài của Dữ liệu Lệnh GPO):
Nếu giá trị của Chiều dài Bản mẫu GPO không tương đương với giá trị của tham số Chiều dài Dữ liệu GPO trong phần tử dữ liệu Tham số GPO x được sử dụng cho giao dịch, thì thẻ phải chấm dứt quy trình xử lý lệnh GPO, phải hồi đáp một SW1 SW2 chỉ ra lỗi, và phải hồi đáp với SW1 SW2 = ‘6700’ (Chiều dài Sai).
Req 3.6.6 (Chiều dài hợp lệ tối thiểu cho Dữ liệu có liên quan tới PDOL):
Nếu giá trị của Lc ít hơn 2, thì thẻ phải chấm dứt quy trình xử lý lệnh GPO, phải hồi đáp với SW1 SW2 chỉ ra lỗi, và phải hồi đáp với SW1 SW2 = ‘6700’ (Chiều dài Sai).
6.5.2. Quy trình xử lý
Sau khi thẻ nhận được lệnh GET PROCESSING OPTIONS từ thiết bị đầu cuối, ứng dụng bắt đầu quy trình xử lý giao dịch.
Ứng dụng đặt một hạn mức về tổng số lượng các giao dịch được phép tiến hành xử lý bởi ứng dụng bằng cách không cho phép bộ Đếm Giao dịch Ứng dụng (ATC) gia hạn. Khi hạn mức (‘FFFF’) đã đến, ứng dụng sẽ không còn xử lý giao dịch. Nếu hạn mức chưa đến, ứng dụng tăng bộ Đếm Giao dịch Ứng dụng thêm một để bao gồm giao dịch hiện thời và thiết lập lại các chỉ báo được sử dụng để chỉ ra các điều kiện và sự kiện có mặt trong cuộc giao dịch.
CHÚ THÍCH Nếu một bên phát hành lựa chọn hạn mức tối đa số lượng giao dịch mà có thể xử lý bởi ứng dụng trên vòng đời của thẻ ít hơn 65,535, thì ATC có thể được cá thể hóa cho giá trị khởi điểm khác hơn giá trị không. Đây là một tùy chọn bên phát hành.
Req 3.6.7 (kiểm tra ATC):
Nếu giá trị của ATC ít hơn ‘FFFF’, thì ứng dụng phải:
• tăng ATC thêm một;
• thiết lập lại nhanh dữ liệu giao dịch, như:
– thiết lập lại Kết quả Quyết định Ứng dụng (ADR) thành ’00 00 00 00 00 00′;
– thiết lập lại Kết quả Xác minh Thẻ (CVR) thành ’00 00 00 00 00′;
– thiết lập lại các Cờ Nội bộ (nếu đã thực thi) thành không;
Mặt khác (ATC có giá trị là ‘FFFF’), ứng dụng phải chấm dứt quy trình xử lý lệnh GET PROCESSING OPTIONS và hồi đáp với SW1 SW2 = ‘6985’ (các điều kiện được sử dụng không phù hợp).
6.5.3. Lựa chọn Hồ sơ
Lựa chọn Hồ sơ sử dụng thông tin từ thiết bị đầu cuối để lựa ra chức năng ứng dụng dựa trên một so sánh về dữ liệu thiết bị đầu cuối với dữ liệu được cá thể hóa. Ví dụ, nó cho phép ứng dụng lựa chọn giữa nhiều AIP và AFL được cá thể hóa trên thẻ khi xây dựng hồi đáp cho lệnh GET PROCESSING OPTIONS, và để cấu hình quản lý rủi ro thẻ (như vậy các kiểm thử tùy chọn để thực hiện, và bộ đếm được sử dụng).
Lựa chọn Hồ sơ là một cơ chế sử dụng để nhận diện môi trường giao dịch và lựa ra một Hồ sơ có thể sử dụng cho giao dịch.
Thông tin cần thiết từ thiết bị đầu cuối cho ứng dụng để nhận ra môi trường giao dịch là được yêu cầu sử dụng PDOL được gửi từ thẻ đến thiết bị đầu cuối.
Dữ liệu được gửi trả về thiết bị đầu cuối đến thẻ như các trường dữ liệu lệnh GPO thuộc Dữ liệu liên quan tới PDOL.
Nếu tùy chọn bên phát hành VLP không được hỗ trợ bởi ứng dụng hoặc giao dịch không đạt các điều kiện để sử dụng Hồ sơ VLP, ứng dụng sẽ kiểm tra khi nào bên phát hành được yêu cầu tiến hành thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ.
Nếu Quy trình xử lý Tệp tin Lựa chọn Hồ sơ không được yêu cầu bởi bên phát hành, thì số ID Hồ sơ mặc định ’01’ sẽ được sử dụng cho giao dịch và lệnh GET PROCESSING OPTIONS mà không sử dụng dữ liệu liên quan tới PDOL. Mặt khác, ứng dụng sẽ thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ để xác định Hồ sơ đã sử dụng cho giao dịch.
Req 3.6.8 (kiểm tra khi nào hỗ trợ tùy chọn bên triển khai VLP):
Nếu tùy chọn bên triển khai VLP được hỗ trợ bởi ứng dụng, thì ứng dụng phải thực hiện Quy trình xử lý Lựa chọn Hồ sơ VLP, thì ứng dụng phải thực hiện Quy trình xử lý Lựa chọn Hồ sơ VLP, như mô tả trong Điều 6.5.3.1.
Nếu tùy chọn bên triển khai VLP không được hỗ trợ bởi ứng dụng:
• nếu bit ‘Kích hoạt Tệp tin Lựa chọn Hồ sơ’ trong Kiểm soát Ứng dụng có giá trị là 0b, thì giao dịch phải được xử lý với số ID Hồ sơ mặc định ’01’.
• nếu bit ‘Kích hoạt Tệp tin Lựa chọn Hồ sơ’ trong Kiểm soát Ứng dụng có giá trị là 1b, thì ứng dụng phải thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ như mô tả tại Điều 6.5.3.2.
Chức năng bổ sung sử dụng dữ liệu thu được từ thiết bị đầu cuối sử dụng PDOL được chuẩn chi, nhưng vượt ngoài phạm vi của bộ tiêu chuẩn TCVN 11198. Xem Điều 5, TCVN 11198-6 về thông tin thêm liên quan đến chức năng bổ sung.
6.5.3.1. Quy trình xử lý Lựa chọn Hồ sơ VLP
Số ID Hồ sơ ‘7D’ chi ra hồ sơ VLP, một hồ sơ đặc biệt mà nếu được hỗ trợ trong thẻ và được yêu cầu bởi thiết bị đầu cuối, có thể chọn cho quy trình xử lý giao dịch.
Mục đích của hồ sơ VLP là có một giao dịch ngoại tuyến nhanh cho nhiều cuộc giao dịch giá trị thấp. Không có Quản lý Rủi ro Thẻ được thực hiện tại hồ sơ này. Nếu thiết bị đầu cuối có yêu cầu chấp nhận ngoại tuyến, thẻ sẽ chấp nhận giao dịch. Nếu thiết bị đầu cuối yêu cầu từ chối ngoại tuyến, thẻ sẽ từ chối giao dịch.
Nếu tùy chọn bên thực thi VLP được hỗ trợ bởi ứng dụng, ứng dụng sẽ kiểm tra đầu tiên khi nào giao dịch có đủ thích hợp cho quy trình xử lý như là một giao dịch VLP. Nếu cả ứng dụng và thiết bị đầu cuối đều hỗ trợ VLP, và giao dịch đạt được các yêu cầu cho quy trình xử lý như VLP, thì Hồ sơ VLP sẽ được sử dụng cho giao dịch.
Nếu giao dịch không đạt các điều kiện để sử dụng Hồ sơ VLP, ứng dụng sẽ kiểm tra khi nào bên phát hành sẽ yêu cầu thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ.
Nếu Quy trình xử lý Tệp tin Lựa chọn Hồ sơ không được yêu cầu bởi bên phát hành, thì số ID Hồ sơ ’01’ mặc định sẽ được sử dụng cho giao dịch và lệnh GET PROCESSING OPTIONS sẽ không sử dụng dữ liệu liên quan tới PDOL. Mặt khác, ứng dụng sẽ thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ để xác định Hồ sơ đã sử dụng cho giao dịch.
CHÚ THÍCH: Nếu quy trình xử lý VLP được cho phép bởi ứng dụng, thì Dữ liệu Lệnh GPO bắt đầu với Chỉ báo Thiết bị đầu cuối Hỗ trợ VLP, Mã Tiền Giao dịch, và Lượng được Chuẩn chi. Xem Điều 7, TCVN 11198-6.
Req 3.6.9 (kiểm tra các điều kiện để lựa chọn Hồ sơ VLP):
Nếu tất cả các điều sau là đúng:
• bit ‘kích hoạt VLP’ trong Kiểm soát Ứng dụng có giá trị 1b,
• và các điều kiện VLP phải đạt được:
– Chỉ báo Hỗ trợ Thiết bị đầu cuối VLP (byte 1 của Dữ liệu Lệnh GPO) có giá trị ‘01’;
– Mã Tiền Giao dịch (byte 2 và 3 của Dữ liệu lệnh GPO) phù hợp với Mã Tiền Ứng dụng;
– Lượng được Chuẩn chi (các byte 4-9 của Dữ liệu Lệnh GPO) nhỏ hơn hoặc bằng Quỹ Có sẵn VLP;
– Lượng được Chuẩn chi (các byte 4-9 của Dữ liệu Lệnh GPO) nhỏ hơn hoặc bằng Hạn mức một lần Giao dịch VLP (nếu được cá thể hóa trên thẻ);
– Bộ đếm lân Thử mã PIN không bằng 0;
– bit ‘Xác thực bên Phát hành bị lỗi’ trong PTH có giá trị là 0b;
– bit ‘Tiến hành Trực tuyến với lần Giao dịch Tiếp theo’ trong PTH có giá trị 0b;
– bit ‘Lần giao dịch cuối không thành công’ trong PTH có giá trị là 0b;
– bit ‘Ứng dụng bị khóa’ trong PTH có giá trị là 0b;
khi giao dịch phải sử dụng số ID Hồ sơ ‘7D’ (Hồ sơ VLP) để xử lý giao dịch, tiếp tục với Điều 6.5.4.
Mặt khác, nếu bit ‘Kích hoạt Tệp tin Lựa chọn Hồ sơ’ trong Kiểm soát Ứng dụng có giá trị là 0b, thì giao dịch phải được xử lý với số ID Hồ sơ mặc định ’01’.
Mặt khác, ứng dụng phải thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ như mô tả trong Điều 6.5.3.2.
6.5.3.2 Quy trình xử lý Tệp tin Lựa chọn Hồ sơ
Ứng dụng tùy chọn sử dụng PDOL để yêu cầu rằng thiết bị đầu cuối gửi dữ liệu trong Dữ liệu liên quan tới PDOL. Khi chức năng Tệp tin Lựa chọn Hồ sơ được kích hoạt, ứng dụng sử dụng nội dung của Dữ liệu Lệnh GPO và các Mục Lựa chọn Hồ sơ, để lựa ra số ID Hồ sơ của Hồ sơ đã sử dụng cho giao dịch. Nếu hỗ trợ tùy chọn bên thực thi Lựa chọn Hồ sơ sử dụng Dữ liệu Thẻ, ứng dụng cũng sử dụng Đa dạng Lựa chọn Hồ sơ trong Tham số GPO x được sử dụng cho giao dịch trong Quy trình xử lý Tệp tin Lựa chọn Hồ sơ. Số ID Hồ sơ chỉ ra Kiểm soát Hồ sơ cho Hồ sơ đã chọn. Dựa trên đầu ra của Quy trình xử lý Tệp tin Lựa chọn Hồ sơ, ICC có thể cũng chấm dứt quy trình xử lý lệnh và hồi đáp với một từ khóa trạng thái làm cho thiết bị đầu cuối gửi trả về Lựa chọn Ứng dụng để lựa chọn ứng dụng khác.
Req 3.6.10 (Thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ):
Quy trình xử lý Tệp tin Lựa chọn Hồ sơ phải được thực hiện như mô tả trong Điều 5, TCVN 11198-7.
Req 3.6.11 (lỗi Lựa chọn Hồ sơ):
Nếu tồn tại một lỗi trong Quy trình xử lý Tệp tin Lựa chọn Hồ sơ, thì số ID Hồ sơ phải là ‘7F’. Nếu các kết quả Quy trình xử lý Tệp tin Lựa chọn Hồ sơ trong khi đang chọn số ID Hồ sơ ‘7F’ thì thẻ phải chấm dứt quy trình xử lý lệnh GPO và hồi đáp với SW1 SW2 = ‘6985’ (các điều kiện sử dụng không phù hợp)
6.5.4. Hành vi Hồ sơ
Số ID Hồ sơ được chọn trong khi Lựa chọn Hồ sơ chỉ ra Kiểm soát Hồ sơ được sử dụng để cấu hình hành vi ứng dụng cho Quy trình Khởi tạo Ứng dụng và Phân tích Hành động Thẻ.
Kiểm soát Hồ sơ cho biết rằng AFL và AIP được trả về thiết bị đầu cuối trong hồi đáp lệnh GPO (ngoài ra đang cấu hình hành vi thẻ khác cho giao dịch). Với thông tin khác xem thêm Điều 11, TCVN 11198-7.
6.5.4.1. Tất cả Hồ Sơ
Req 3.6.12 (Thực hiện Quy trình xử lý Tệp tin Lựa chọn Hồ sơ):
Nếu kết quả quy trình xử lý Lựa chọn Hồ sơ trong lựa chọn một số ID Hồ sơ trong dải ’01’ đến ‘7E’ để mà một Kiểm soát Hồ sơ x có liên quan (trong đó x là giá trị của số ID Hồ sơ được chọn cho giao dịch) có mặt, thì Kiểm soát Hồ sơ được chọn cho giao dịch phải là Kiểm soát Hồ sơ x.
Nếu Kiểm soát Hồ sơ x không có mặt trong ứng dụng (trong đó x là giá trị của số ID Hồ sơ được chọn cho giao dịch), thì ứng dụng phải chấm dứt quy trình xử lý lệnh GPO, và phải hồi đáp với SW1 SW2 = ‘6985’ (các điều kiện sử dụng không phù hợp).
Ứng dụng có chứa tập AIP và AFL trong các Mục nhập AIP/AFL mà có thể được lựa chọn để sử dụng bên trong một Hồ sơ. Một bên phát hành có thể chỉ trả lời hỗ trợ đến sáu Mục nhập AIP/AFL. Việc này cho phép việc triển khai hỗ trợ nhiều hơn sáu Mục nhập AIP/AFL, nhưng không yêu cầu trong mọi việc triển khai.
Req 3.6.13 (Số lượng tối thiểu mục nhập AIP/AFL được hỗ trợ):
Tối thiểu ứng dụng phải có thể hỗ trợ đến sáu mục nhập AIP/AFL.
Req 3.6.14 (Lựa chọn AIP/AFL để hồi đáp):
Nếu Mục nhập AIP/AFL x có mặt, thì ứng dụng phải sử dụng AIP và AFL trong Mục nhập AIP/AFL x để sinh ra hồi đáp lệnh GPO, trong đó x là giá trị của số ID AIP/AFL trong Kiểm soát Hồ sơ cho giao dịch. Nếu Mục nhập AIP/AFL x không có mặt, thì ứng dụng phải chấm dứt quy trình xử lý lệnh GPO, phải hồi đáp với một SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6985’ (điều kiện sử dụng không phù hợp).
6.5.4.2. Hồ sơ VLP (số ID Hồ sơ = ‘7D’)
Req 3.6.15 (Giảm các Quỹ có sẵn VLP):
Nếu số ID Hồ sơ được lựa chọn cho giao dịch là ‘7D’ (như thế Hồ sơ VLP được sử dụng cho giao dịch), thì ứng dụng phải khấu trừ Lượng tiền, đã Chuẩn chi từ các Quỹ Có sẵn VLP.
6.5.5. Hồi đáp lệnh GET PROCESSING OPTIONS
Bit ‘Xác thực bên Phát hành được hỗ trợ’ trong AIP gửi trong hồi đáp được thiết lập là 0b để chỉ ra rằng thẻ hỗ trợ Xác thực bên Phát hành như là một phần quy trình xử lý lệnh GENERATE AC lần hai hơn là sử dụng lệnh EXTERNAL AUTHENTICATE.
Bit ‘Xác minh Chủ thẻ được hỗ trợ’ trong AIP gửi trong hồi đáp được thiết lập là 1b để chỉ ra rằng thẻ yêu cầu việc xác minh chủ thẻ được thực hiện bởi thiết bị đầu cuối.
Req 3.6.16 (định dạng hồi đáp GPO):
Hồi đáp lệnh GPO phải được định dạng như quy định trong EMV Quyển 3, điều 6.5.8.4 cho thẻ tương thích CCD.
6.6. Biểu đồ luồng chức năng
Hình 1 biểu diễn luồng Quy trình Khởi tạo Ứng dụng.
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (tiếp theo)
Hình 1 – Luồng Quy trình Khởi tạo Ứng dụng (kết thúc)
7. Đọc dữ liệu ứng dụng
7.1. Mục đích
Trong suốt quá trình đọc dữ liệu ứng dụng, các thiết bị đầu cuối đọc dữ liệu thẻ là cần thiết để xử lý các giao dịch và xác định dữ liệu cần được xác thực trong suốt quá trình xác thực dữ liệu tĩnh (SDA – Static Data Authentication), xác thực dữ liệu động (DDA – Dynamic Data Authentication), hoặc kết hợp DDA/CDA (CDA – Thế hệ Mã lệnh Ứng dụng).
Quá trình đọc dữ liệu ứng dụng được thực hiện như mô tả trong EMV Quyển 3, mục 10.2.
7.2. Trình tự thực hiện
Quá trình đọc dữ liệu ứng dụng được thực hiện ngay khi khởi tạo chức năng xử lý ứng dụng.
7.2.1. Quy trình xử lý có liên quan trước đó
Quy trình Khởi tạo Ứng dụng
Trong suốt quá trình Khởi tạo Ứng dụng, các thẻ gửi AFL tới thiết bị đầu cuối để chỉ rõ bản ghi thiết bị đầu cuối nên được yêu cầu từ thẻ.
7.2.2. Quy trình xử lý có liên quan tiếp theo
Các chức năng khác sử dụng đọc dữ liệu trong suốt quá trình đọc dữ liệu ứng dụng.
Xác thực dữ liệu ngoại tuyến
Thiết bị đầu cuối sử dụng danh sách dữ liệu tĩnh cần được xác thực mà được xây dựng trong suốt quá trình đọc dữ liệu ứng dụng trong việc phê chuẩn các ứng dụng dữ liệu tĩnh được đăng ký trong suốt quá trình SDA; hoặc quá trình chứng thực khóa công khai ICC trong suốt quá trình DDA và CDA
7.3. Dữ liệu thẻ
Dữ liệu thẻ được sử dụng trong quá trình đọc dữ liệu ứng dụng được liệt kê và mô tả trong Bảng 5.
Đối với một mô tả chi tiết dữ liệu và cách thức sử dụng chúng, xem Điều 7, TCVN 11198-8.
Bảng 5 – Đọc dữ liệu ứng dụng – Dữ liệu thẻ
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Tệp tin ứng dụng cơ bản (AEF) | Tệp tin dữ liệu thẻ chứa dữ liệu sử dụng cho xử lý ứng dụng.
AEF gồm một chuỗi các bản ghi được gắn địa chỉ bằng các con số bản ghi. Mỗi AEF được định nghĩa bởi một SFI. Các thiết bị đầu cuối đọc các bản ghi sử dụng lệnh đọc bản ghi chứa thiết kế SFI và số bản ghi để được đọc |
||
Định vị tệp tin ứng dụng (AFL) | Trong suốt quá trình xử lý ứng dụng, các thẻ sẽ gửi các thiết bị đầu cuối định vị tệp tin AFL chứa nhóm các bản ghi được đọc. Mỗi mục chỉ định:
• Định danh tệp tin ngắn • Số lượng bản ghi của bản ghi đầu tiên và bản ghi cuối cùng đọc từ tệp tin • Số lượng bản ghi (bắt đầu với bản ghi đầu tiên đọc tệp tin ) để sử dụng xác thực trong suốt quá trình SDA, DDA hoặc CDA |
’94’ |
|
Định danh tệp tin ngắn (SFI) | Một số sử dụng định danh những tệp tin ứng dụng thành phần. Được liệt kê trong định vị tệp tin ứng dụng AFL và sử dụng bởi thiết bị đầu cuối để định danh các tệp tin được đọc |
‘88’ |
7.4. Dữ liệu thiết bị đầu cuối
Các thẻ không sử dụng dữ liệu thiết bị đầu cuối trong đọc dữ liệu ứng dụng.
7.5. Lệnh READ RECORD
Lệnh READ RECORD được thực hiện như mô tả trong EMV Quyển 3, phần 6.5.11.
7.5.1. Mã hóa lệnh
Lệnh READ RECORD nhận được từ thiết bị đầu cuối được mã hóa như trong EMV Quyển 3, mục 6.5.11.2, bao gồm định danh tệp tin ngắn (SFI) của tệp tin được đọc và ghi số bản ghi trong Tệp tin.
Bảng 6 – Thông điệp lệnh READ RECORD
Mã |
Giá trị |
CLA | ‘00’ |
INS | ‘B2’ |
P1 | Số bản ghi |
P2 | Thông số kiểm soát tham khảo (xem bảng 3) |
Lc | Không hiện diện |
data | Không hiện diện |
Le | ’00’ |
Bảng 7 – Mã hóa Tham số Kiểm soát Tham chiếu cho lệnh READ RECORD
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
Ý nghĩa |
x | x | x | x | x | SFI | |||
x | x | x | ||||||
1 | 0 | 0 | P1 là số bản ghi |
7.5.1.1. Cho phép định dạng lệnh
Req 3.7.1 (Kiểm tra giá trị P1 cho lệnh READ RECORD):
Nếu tham số P1 có giá trị ‘00’, các thẻ sẽ dừng lệnh READ RECORD, Hồi đáp SW2 SW1 chỉ ra lỗi và Hồi đáp lại SW1 SW2 = ‘6A86’ (thông số không chính xác, P1-P2).
Req 3.7.2 (Kiểm tra giá trị P2 cho lệnh READ RECORD)
Nếu bít 3 qua 1 của tham số P2 không có giá trị là 100b, các thẻ sẽ có trách nhiệm dừng lệnh READ RECORD, Hồi đáp với SW1 SW2 cái mà chỉ ra lỗi và nên Hồi đáp lại với SW1 SW2 = ‘6A86’ (thông số không chính xác, P1-P2).
7.5.2. Quy trình Xử lý
Một lệnh READ RECORD được trả về cho mỗi bản ghi được chỉ định trong AFL gửi đến các thiết bị đầu cuối trong suốt quá trình Khởi tạo Ứng dụng. Thẻ nhận được lệnh READ RECORD từ các thiết bị đầu cuối và trả lại bản ghi yêu cầu tới thiết bị đầu cuối như mô tả trong Điều 7.5.3.
Các thiết bị đầu cuối tiếp tục thực hiện lệnh READ RECORD cho đến khi tất cả các bản ghi trong mỗi Tệp tin được đọc.
7.5.3. Hồi đáp lệnh READ RECORD
Các lệnh Hồi đáp được trả về bởi các thẻ bao gồm các bản ghi được yêu cầu trong trường dữ liệu.
Đối với các bản ghi trong Tệp tin với SFI trong khoảng từ 1 đến 10, các trường dữ liệu đáp ứng được định dạng như mô tả trong EMV Quyển 3, mục 6.5.11.4.
Các thẻ được phép gửi các byte phụ có giá trị ‘00’ trong lệnh Hồi đáp READ RECORD cho tệp tin lựa chọn hồ sơ.
Định dạng của các bản ghi trong Tệp tin với SFI nằm trong khoảng 11-30 khác hơn so với Tệp tin dữ liệu VLP, Tệp tin Log Giao dịch và các Tệp tin cá nhân lựa chọn ra khỏi phạm vi được chỉ ra đặc điểm kỹ thuật này.
Req 3.7.3 (SFI không tìm thấy):
Nếu tham chiếu đến SFI mà không thể tìm thấy, sau đó thẻ phải ngừng quy trình xử lý lệnh READ RECORD, khi đó SW1 SW2 sẽ Hồi đáp lại để chỉ ra lỗi, và nếu lệnh Hồi đáp SW1 SW2 = ‘6A82’ (tức là không tìm thấy Tệp tin).
Req 3.7.4 (bản ghi không tìm thấy):
Nếu hồ sơ tham chiếu không thể tìm thấy, thì các thẻ phải ngừng quy trình xử lý lệnh READ RECORD và Hồi đáp lại với SW1 SW2 = ‘6A83’ (số bản ghi không tồn tại)
7.6. Biểu đồ luồng chức năng
Hình 2 – Biểu đồ xử lý lệnh READ RECORD
7.7. Yêu cầu Tệp tin Bổ sung
Ba tệp tin bổ sung sau đây được xác định cho CPA:
• Tệp tin dữ liệu VLP (SFI);
• Tệp tin Log Giao dịch (một SFI trong khoảng 21-30);
• Tệp tin có chứa hồ sơ nhập vào (một SFI trong khoảng 21-30);
7.7.1. Tệp tin dữ liệu VLP
Req 3.5.5 (SFI 11 sử dụng cho VLP):
Nếu VLP được hỗ trợ thực hiện, thì các tệp tin với SFI 11 sẽ dành riêng cho việc sử dụng dữ liệu bởi VLP.
Yêu cầu thêm Tệp tin dữ liệu vào VLP điều này được quy định trong Điều 7, TCVN 11198-6.
7.7.2. Tệp tin Log Giao dịch
Req 3.5.6 (SFI cho Tệp tin Log Giao dịch):
Nếu Log Giao dịch được các bên phát hành hỗ trợ (có nghĩa là các yếu tố định dạng dữ liệu đăng nhập vào được dành riêng cho cá nhân), sau đó các Tệp tin Log Giao dịch sẽ phải có SFI nằm trong khoảng từ 21 đến 30.
Các Tệp tin Log Giao dịch được định dạng như mô tả trong EMV Quyển 3, phần D4. Các SFI sử dụng cho các Log Giao dịch được xác định trong byte 1 của phần tử dữ liệu nhật ký đăng nhập.
CHÚ THÍCH: Các phần tử dữ liệu nhật ký đăng nhập phải được cá thể hóa như một phần tử dữ liệu được gắn trong thẻ để xác định cho các ứng dụng SFI sẽ được sử dụng để đăng nhập giao dịch và số lượng tối đa của các bản ghi được hỗ trợ trong tệp tin. Xem thêm Điều 7, TCVN 11198-6.
Các CPA hỗ trợ nhật ký của dữ liệu giao dịch một cách linh hoạt. Nội dung của các bản ghi Log Giao dịch là sự kết nối của các phần tử dữ liệu có giá trị được xây dựng như mô tả trong phụ lục D. Các bản ghi trong Tệp tin Log Giao dịch không bao gồm thẻ mẫu.
Req 3.7.7 (Số lượng tối thiểu của các bản ghi Log Giao dịch):
Ở mức tối thiểu, CPA sẽ hỗ trợ một Tệp tin có chứa 10 bản ghi Log Giao dịch.
Các điều kiện để đăng nhập một giao dịch và các nội dung của bản ghi được quy định trong Điều 8, TCVN 11198-7. Hệ thống xử lý có thể hỗ trợ hơn mười bản ghi trong Log Giao dịch.
Req 3.7.8 (Kích thức tối thiểu được hỗ trợ cho các Tệp tin Log Giao dịch)
Ở mức tối thiểu, các CPA sẽ hỗ trợ một Tệp tin Log Giao dịch lên đến 256 byte.
Nếu trong một phiên của CPA không đăng nhập ít nhất một lần cho mỗi bản ghi trong Log Giao dịch, một số mục trong Log Giao dịch không đại diện cho giao dịch, nhưng là trống rỗng. Những mục rỗng không thể phục hồi được với lệnh READ RECORD.
Req 3.7.9 (Tệp tin Log Giao dịch rỗng):
Nếu một bản ghi Log Giao dịch rỗng hoặc kết thúc Tệp tin đã đạt được, các ứng dụng sẽ ngừng xử lý các lệnh READ RECORD và Hồi đáp lại SW1 SW2 = ‘6A83’ (số bản ghi không tồn tại)
Khi truy cập vào Log Giao dịch các luồng xử lý thông tin cần phải tuân thủ theo các quy luật xử lý thông thường đối với sự ủy quyền hoặc phiên giao dịch chính. Log Giao dịch truy cập được mô tả chi tiết trong EMV Quyển 3, phần D4.
7.7.3. Tệp tin chứa Mục nhập Lựa chọn Hồ sơ
Tệp tin này chứa hồ sơ lựa chọn truy nhập; mỗi bản ghi trong Tệp tin là một hồ sơ lựa chọn đầu truy nhập. Các hồ sơ lựa chọn truy nhập không bao gồm các thẻ mẫu.
Req 3.7.10 (Kích thước tối thiểu cho Tệp tin Lựa chọn Hồ sơ)
Ở mức tối thiểu, các CPA sẽ được hỗ trợ một Tệp tin có chứa Tệp tin Lựa chọn Hồ sơ với:
• Ở mức tối thiểu, có thể lên tối đa 15 Tệp tin Lựa chọn Hồ sơ;
• Ở mức tối thiểu, có thể lên tối đa 30 byte trong mỗi Tệp tin Lựa chọn Hồ sơ.
Hệ thống xử lý có thể hỗ trợ nhiều hơn 15 Tệp tin Lựa chọn Hồ sơ và triển khai hỗ trợ Tệp tin Lựa chọn Hồ sơ dài hơn 30 byte.
Req 3.5.11 (Không có mẫu thẻ trong Tệp tin Lựa chọn Hồ sơ):
Các Tệp tin Lựa chọn Hồ sơ gửi các Hồi đáp tới READ RECORD cho các Tệp tin Lựa chọn Hồ sơ không bao gồm các thẻ tag bản mẫu.
Khi truy cập vào hồ sơ tuyển chọn, các luồng xử lý không cần phải tuân thủ các quy tắc xử lý thông thường đối với một sự ủy quyền giao dịch tài chính.
Những thiết bị đọc các Tệp tin hồ sơ lựa chọn sử dụng các thành phần của Tệp tin hồ sơ lựa chọn để xác định vị trí (SFI) và số lượng bản ghi để đọc.
Bảng 8 mô tả định dạng của thành phần Tệp tin hồ sơ lựa chọn (tag ‘C2’).
Bảng 8 – Tệp tin Lựa chọn Hồ sơ
Byte |
Định dạng |
Độ dài |
Giá trị |
1 |
b |
1 |
SFI chứa tệp tin lựa chọn hồ sơ |
2 |
b |
1 |
Số Mục nhập Lựa chọn Hồ sơ trong tệp tin lựa chọn hồ sơ |
Req 3.7.12 (SFI cho Tệp tin Lựa chọn Hồ sơ):
Nếu Tệp tin Lựa chọn Hồ sơ được hỗ trợ bởi các bên phát hành (có nghĩa là các hồ sơ lựa chọn là của cá nhân), sau đó các Tệp tin Lựa chọn Hồ sơ sẽ có SFI nằm trong khoảng từ 21 đến 30.
Req 3.7.13 (Tệp tin hồ sơ lựa chọn hỗ trợ bởi READ RECORD):
Các Tệp tin hồ sơ lựa chọn sẽ có thể được truy cập bằng cách sử dụng lệnh READ RECORD. Mỗi bản ghi có thể thay đổi độ dài nhập vào theo quy định tại Điều 7, TCVN 11198-8.
Req 3.7.14 (Tệp tin hồ sơ lựa chọn không được liệt kê trong AFL):
Các Tệp tin hồ sơ lựa chọn sẽ không được chỉ định trong các tệp tin ứng dụng.
Req 3.7.15 (Tệp tin hồ sơ lựa chọn có thể truy cập khi ứng dụng bị chặn):
Các Tệp tin hồ sơ lựa chọn đăng nhập và các hồ sơ chọn đăng nhập vẫn có thể truy cập được khi ứng dụng bị chặn.
Để đọc các Tệp tin lựa chọn hồ sơ, cho các thiết bị đặc biệt sử dụng các bước sau:
1. Thực hiện chọn các ứng dụng;
2. Thực hiện lệnh GETDATA để lấy hồ sơ chọn Tệp tin nhập liệu;
3. Thực hiện lệnh READ RECORD để đọc hồ sơ truy nhập được lựa chọn trong Tệp tin hồ sơ lựa chọn.
8. Xác thực dữ liệu ngoại tuyến
8.1. Mục đích
Xác thực dữ liệu ngoại tuyến là một quá trình tại đó thẻ được xác minh hợp lệ tại điểm giao dịch bằng cách sử dụng công nghệ khóa công khai RSA để chống lại các tấn công tráo hàng (counterfeit) hoặc tấn công vớt (skimming). Có ba hình thức xác thực dữ liệu ngoại tuyến như sau:
• Xác thực dữ liệu tĩnh (SDA);
• Xác thực dữ liệu động (DDA);
• Kết hợp cả 2 thế hệ DDA/AC (CDA);
Một thẻ có hỗ trợ sử dụng khóa công khai động hoặc hỗ trợ các tùy chọn của DDA và CDA
Req 3.8.1 (Hỗ trợ cho SDA):
Tất cả các thẻ CPA sẽ phải chấp nhận dữ liệu thẻ cá nhân sử dụng cho SDA. Nó là một bên phát hành có lựa chọn AIP hay không từ đó chỉ ra các ứng dụng được hỗ trợ bởi hình thức SDA.
Req 3.8.2 (Hỗ trợ cho DDA/CDA):
Nếu các ứng dụng hỗ trợ người dùng tùy chọn sử dụng khóa công khai động, thì các thẻ sẽ được hỗ trợ bởi hình thức xác thực DDA và CDA. Nó là một bên phát hành có lựa chọn AIP hay không từ đó chỉ ra các ứng dụng được hỗ trợ bởi hình thức DDA hoặc CDA.
Trong quá trình xử lý SDA các thiết bị đầu cuối xác thực tĩnh (không thay đổi) dữ liệu thẻ. Xem Điều 7, TCVN 11198-6 về danh sách đề xuất dữ liệu tĩnh để xác thực SDA đảm bảo rằng các thẻ được lựa chọn phát hành không thay đổi kể từ khi thẻ đó đã được cá thể hóa.
Trong quá trình xử lý DDA và CDA các thiết bị đầu cuối xác thực dữ liệu tĩnh và xác thực một chữ ký mà thẻ tạo ra bằng cách sử dụng dữ liệu duy nhất trong giao dịch.
DDA và CDA đảm bảo rằng các bên phát hành lựa chọn dữ liệu thẻ đã không bị thay đổi kể từ khi thẻ đã được cá thể hóa.
DDA và CDA cũng xác nhận thẻ là thật và không được tạo ra bằng cách sao chép dữ liệu từ một thẻ hợp lệ để làm giả thẻ (skimming).
Xác thực dữ liệu ngoại tuyến được thực hiện như mô tả trong EMV Quyển 2, phần 5 và 6.
8.2. Trình tự thực hiện
8.2.1. Quy trình xử lý có liên quan trước đó
Quy trình Khởi tạo Ứng dụng
Trong suốt quy trình Khởi tạo Ứng dụng, các thẻ sẽ gửi AIP và AFL đến thiết bị đầu cuối để chỉ ra các phương thức xác thực dữ liệu ngoại tuyến được hỗ trợ bởi các ứng dụng và các bản ghi được sử dụng để xác thực.
Đọc dữ liệu ứng dụng:
Các thiết bị đầu cuối đọc dữ liệu ứng dụng từ các thẻ. Đối với các thẻ hỗ trợ SDA các dữ liệu này bao gồm các bên phát hành Chứng chỉ PK, các dữ liệu quan trọng liên quan đến bên phát hành khác và các ứng dụng dữ liệu chữ ký tĩnh (SSAD).
Đối với các thẻ hỗ trợ DDA và CDA các dữ liệu này bao gồm các bên phát hành Chứng chỉ PK, các dữ liệu quan trọng liên quan đến bên phát hành khác, các DDOL, Chứng chỉ ICC và các dữ liệu quan trọng liên quan đến ICC khác.
Dữ liệu chứng thực tĩnh được xây dựng từ hồ sơ liên quan đến xác thực dữ liệu ngoại tuyến (như quy định trong AFL) và từ danh sách tag xác thực dữ liệu tĩnh.
8.2.2. Quy trình xử lý có liên quan tiếp theo
Phân tích Hành động Thiết bị đầu cuối
Các thiết bị đầu cuối sử dụng SDA, DDA và CDA cũng như thẻ để xác định xem các giao dịch ngoại tuyến phải được giảm bớt và giao dịch trực tuyến được cho phép.
Phân tích Hành động Thẻ lần đầu (giao dịch tiếp theo)
Nếu các thiết bị đầu cuối yêu cầu CDA trước trong lệnh GENERATE AC và thẻ CDA yêu cầu giấy phép trực tuyến hoặc chấp nhận các giao dịch ngoại tuyến sau đó các thẻ này sẽ đưa các Hồi đáp ARQC hoặc TC trong một túi hồ sơ RSA để đáp ứng với các thiết bị đầu cuối.
Nếu kết quả xác nhận từ thiết bị đầu cuối chỉ ra rằng SDA hoặc DDA hoặc CDA thất bại, sau đó các thẻ ngoại tuyến không xác thực được dữ liệu trong các giao dịch tiếp theo cho đến khi một giao dịch được phê duyệt hoặc đi đến giao dịch trực tuyến thành công.
Nếu CDA là phương thức xác thực dữ liệu ngoại tuyến và hồi đáp lại thẻ sau đó các thiết bị đầu cuối sẽ phục hồi và xác nhận các dữ liệu được mã hóa trong các Hồi đáp được sinh ra. Nếu quá trình phục hồi thất bại các giao dịch sẽ bị từ chối bởi thiết bị đầu cuối.
Phân tích Hành động Thẻ lần đầu (giao dịch tiếp theo)
Các dữ liệu ngoại tuyến nếu xác thực không thành công thì các CVR sẽ được thiết lập lại trong suốt qua trình giao dịch ngoại tuyến được chấp thuận nếu dữ liệu ngoại tuyến tiếp theo xác thực không thất bại.
Phân tích Hành động Thẻ lần hai (giao dịch tiếp theo)
Các dữ liệu ngoại tuyến không xác thực giao dịch thành công thì bit trong CVR được thiết lập lại trong một giao dịch trực tuyến dựa trên các bên phát hành.
8.3. Dữ liệu thẻ
Các dữ liệu thẻ được sử dụng trong việc xác thực dữ liệu ngoại tuyến được liệt kê và mô tả trong Bảng 9 dưới đây:
Bảng 9 – Xác thực Dữ liệu Ngoại tuyến – Dữ liệu Thẻ
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Hồ sơ trao đổi ứng dụng (AIP) | Bao gồm các chỉ số sau:
• SSDA được hỗ trợ bởi các thẻ; • DDDA được hỗ trợ bởi các thẻ; • CCDA được hỗ trợ bởi các thẻ; |
– |
’82’ |
Kết quả xác thực thẻ (CVR) | Một chỉ số được thiết lập trong thẻ phân tích các hoạt động của giao dịch tiếp theo cho thấy dữ liệu xác thực không thành công của giao dịch trước.
Ngoài ra nó còn chứa các chỉ số thiết lập của giao dịch hiện tại để chỉ ra các giao dịch ngoại tuyến DDA được thực thi hoặc CDA được thực thi. |
– |
‘9F52’ |
Chứng chỉ ủy quyền (CA) khóa công khai | Chứng chỉ ủy được cung cấp bởi các bên phát hành chứng nhận khóa công khai (PK).
Nó xác định các hệ thống thanh toán sử dụng khóa công khai tại các điểm cuối để sử dụng cho việc xác minh bên phát hành khóa công khai. |
– |
‘8F’ |
Danh sách đối tượng xác thực dữ liệu động | Danh sách các thẻ cung cấp dữ liệu cho thiết bị đầu cuối bao gồm các lệnh xác thực bên trong. |
– |
‘9F49’ |
Dữ liệu động ICC | Những nguyên lý cơ bản của dữ liệu bao gồm chữ ký dữ liệu ứng dụng động |
– |
– |
Các số động ICC | Một phần của dữ liệu động ICC có chứa một biến thời gian được tạo ra bởi các ICC |
– |
– |
Khóa bảo mật ICC | Các phim được sử dụng để tạo ra các chữ ký dữ liệu ứng dụng động. |
– |
– |
Chứng chỉ khóa công khai ICC | Chứng chỉ chứa tất cả hoặc một phần của khóa công khai ICC và một hàm băm dữ liệu tĩnh của thẻ.
Chứng chỉ khóa công khai ICC được tạo ra bằng cách sử dụng các bên phát hành khóa bảo mật và đặt trong quá trình riêng biệt hóa thẻ. Chứng chỉ khóa công khai này được mô tả chi tiết trong mục 6.1 quyển 2 EMV. Các dữ liệu tĩnh được sử dụng trong Chứng chỉ khóa công khai sẽ nhận hàm băm của cùng một dữ liệu đã dùng để tạo ra các thẻ của SSAD sử dụng trong SDA. Những dữ liệu này là yếu tố để xác định các AFL và danh sách SDA quá trình đọc dữ liệu ứng dụng. Nếu dữ liệu đầu vào SDA có thể thay đổi từ một giao dịch khác, thì các AFl phải được hỗ trợ. Ví dụ khi dữ liệu có thể không phải là duy nhất là khi một thẻ sử dụng chức năng CVM khác nhau cho giao dịch trong nước và quốc tế. Nếu bất kỳ các yếu tố dữ liệu nào được ký kết có thể thay đổi được sau khi phát hành Chứng chỉ khóa công khai cũng phải được hỗ trợ. |
– |
‘9F46’ |
Giải thích về khóa công khai ICC | Những giải thích về việc sử dụng RSA sẽ được mô tả lại trong dữ liệu ứng dụng chữ ký động. |
– |
‘9F47’ |
Phần còn lại của khóa công khai | Đây là các khóa công khai không phù hợp với chứng nhận khóa công khai. |
– |
‘9F48’ |
Bên phát hành Chứng chỉ khóa công khai | Bên phát hành Chứng chỉ khóa công khai được ký kết với khóa bảo mật (CA).
Chứng chỉ này được mô tả chi tiết trong bảng 5 quyển 2 EMV. |
– |
’90’ |
Trình bày về bên phát hành khóa công khai | Tiêu biểu cho việc sử dụng RSA là thuật toán để ghi lại các bên phát hành khóa công khai |
– |
‘9F32’ |
Phần còn lại của bên phát hành khóa công khai | Đây là các phần nếu có của bên phát hành khóa công khai không phù hợp với các tổ chức chứng nhận phát hành khóa công khai. |
– |
‘92‘ |
Lịch sử giao dịch trước đó (PTH) | Có một chỉ số xác định cho các giao dịch ngoại tuyến xác thực dữ liệu bị lỗi tiếp theo |
– |
‘C7‘ |
Cung cấp ứng dụng đã được đăng ký (RID) của định danh ứng dụng (AID) | Năm byte đầu tiên của ứng dụng đã được định danh dùng để nhận dạng hệ thống thanh toán.
Các RID sẽ được đăng ký tiêu chuẩn ISO. Các RID và Chứng chỉ khóa công khai sẽ được sử dụng để xác định các hệ thống thanh toán sẽ được sử dụng để phục hồi lại các bên phát hành khóa công khai. |
– |
– |
Danh sách thẻ SDA | Chứa các thẻ không phải bản ghi dữ liệu bao gồm các ứng dụng chữ ký dữ liệu tĩnh hoặc trong chứng thực khóa công khai ICC |
– |
‘9F4A’ |
Chữ ký động dữ liệu ứng dụng | Đối với DDA chữ ký được tạo ra bởi thẻ tại thời điểm sau khi giao dịch nhận lệnh xác thực từ bên trong.
Đối với CDA thì chữ ký được tạo ra bởi các giao dịch thẻ tại thời điểm sau khi thực hiện lệnh. Các thẻ tạo chữ ký bằng cách sử dụng một hàm băm dữ liệu một cách ngẫu nhiên từ thiết bị đầu cuối và thẻ. Các dấu hiệu dữ liệu ứng dụng thẻ được ký hiệu ngẫu nhiên với khóa bảo mật ICC. Định dạng của dữ liệu ứng dụng ngẫu nhiên được mô tả trong bảng 16 quyển 2 EMV. |
– |
‘9F4B’ |
Dữ liệu ứng dụng chữ ký tĩnh (SSAD) | Đối với SDA một chữ ký số được tạo ra từ các dữ liệu thẻ và được sử dụng bởi thiết bị đầu cuối để xác thực sự hợp lệ dữ liệu tĩnh của thẻ.
Các SSAD ký nhận với các bên phát hành khóa bí mật và các thông tin các nhân trên thẻ. |
– |
’93’ |
8.4. Dữ liệu thiết bị đầu cuối
Các dữ liệu thiết bị đầu cuối sử dụng xác thực dữ liệu ngoại tuyến được liệt kê và mô tả trong Bảng 10. Mô tả chi tiết xem trong Điều 7, TCVN 11198-8.
Bảng 10 – Xác thực dữ liệu ngoại tuyến – Dữ liệu thiết bị đầu cuối
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Tổ chức chứng nhận khóa công khai | Hệ thống thanh toán sử dụng khóa công khai cho SDA, DDA hoặc CDA |
– |
– |
Kết quả xác nhận thiết bị đầu cuối. | Một loạt các chỉ số hiển thị kết quả quá trình xử lý ngoại tuyến từ quan điểm của thiết bị đầu cuối.
Nó được sử dụng để ghi lại kết quả của quá trình xác thực dữ liệu ngoại tuyến. |
– |
’95’ |
Số không thể dự đoán trước | Một biến thời gian bao gồm lệnh xác thực từ bên trong cho DDA, hoặc lệnh được tạo ra cho CDA. |
– |
‘9F37’ |
8.5. Khả năng thực thi của SDA, DDA hoặc CDA
Các thiết bị đầu cuối sử dụng AIP để gửi các lệnh Hồi đáp tới GPO từ thẻ và hỗ trợ xác thực dữ liệu ngoại tuyến được cung cấp bởi các thiết bị đầu cuối để xác định khả năng thực thi của SDA, DDA hoặc CDA.
Có duy nhất một phương thức xác thực dữ liệu ngoại tuyến được thực hiện trong một giao dịch.
Nếu các thiết bị đầu cuối xác định cả hai thẻ (được chỉ ra bởi các AIP) và hỗ trợ thực hiện thiết bị đầu cuối CDA. Mặt khác nếu không hỗ trợ thực hiện thiết bị đầu cuối DDA. Mặt khác nếu cả hai thẻ hỗ trợ và thực thi thiết bị đầu cuối SDA.
Nếu thẻ và thiết bị đầu cuối không hỗ trợ phương thức chung xác thực dữ liệu ngoại tuyến, thì việc xác thực dữ liệu ngoại tuyến sẽ không được thực hiện.
8.6. Xác thực dữ liệu tĩnh (SDA)
Trong quy trình xử lý SDA, các thiết bị đầu cuối sử dụng công nghệ khóa công khai RSA để xác nhận tính hợp lệ của dữ liệu trên thẻ không bị thay đổi từ khi thẻ được cá thể hóa.
Định dạng của SSAD được nói chi tiết trong Bảng 6 của EMV Quyển 2. Các định dạng của dữ liệu sử dụng hàm băm được mô tả trong Bảng 3 của EMV Quyển 2.
Nếu có nhiều hơn một tập hợp dữ liệu được ký cho ứng dụng thì các dữ liệu ứng dụng tĩnh đã ký SSAD phải được hỗ trợ. Ví dụ khi có nhiều hơn một tập hợp các dữ liệu có thể được yêu cầu bởi một bên phát hành khi một thẻ CVM khác nhau cho các giao thức trong nước và quốc tế.
Reg 3.8.3 (Thay đổi dữ liệu chữ ký tĩnh)
Nếu thẻ có khả năng hỗ trợ thay đổi chữ ký sau khi đã được cấp thì khả năng thay đổi các dữ liệu ứng dụng đã ký SSAD cũng sẽ được hỗ trợ.
Xác thực dữ liệu tĩnh (SDA) chứa danh sách hồ sơ trao đổi ứng dụng (AIP) nếu nó được ký kết. Điều này được khuyến cáo trong AIP bao gồm dữ liệu tĩnh đã ký nếu AIP chỉ ra rằng DDA hoặc CDA được hỗ trợ. Danh sách xác thực dữ liệu tĩnh không chứa danh sách các thẻ khác so với AIP.
8.6.1. Các lệnh
Các lệnh không được sử dụng trong quy trình xử lý SDA.
8.6.2. Quy trình xử lý
Các thẻ không được thực hiện trong quy trình xử lý SDA.
Trong SDA các thiết bị đầu cuối sử dụng khóa công khai RSA để khôi phục và phê chuẩn khóa công khai để xác nhận các SSAD từ thẻ.
Các bước xử lý SDA thiết bị đầu cuối được mô tả chi tiết hơn trong EMV quyển 2, phần 5. Nếu tất cả các bước SDA thành công thì SDA sẽ được qua.
8.7. Xác thực Dữ liệu Động Ngoại tuyến
Trong quá trình xử lý Xác thực Dữ liệu Động Ngoại tuyến, các thiết bị đầu cuối sử dụng công nghệ khóa công khai RSA để xác định dữ liệu của thẻ đã bị thay đổi hoặc bị giả mạo.
EMV hỗ trợ 2 phương thức Xác thực Dữ liệu Động Ngoại tuyến là DDA và CDA. Cả hai phương thức dữ liệu của thẻ không bị thay đổi và được mã hóa bằng cách sử dụng khóa bí mật.
Đối với DDA thẻ tạo chữ ký động bằng cách sử dụng thiết bị đầu cuối động, thẻ và dữ liệu giao dịch hồi đáp INTERNAL AUTHENTICATE lệnh phân tích hành động thẻ.
Đối với CDA thẻ hồi đáp lệnh GENERATE AC lần đầu (hoặc thứ hai) phân tích hành động thẻ được tạo ra bằng cách tạo ra một chữ ký động bao gồm Mã lệnh Ứng dụng và dữ liệu Thông tin Mã lệnh cũng như các thiết bị đầu cuối, thẻ và giao dịch dữ liệu sử dụng DDA.
8.7.1. Lệnh INTERNAL AUTHENTICATE
Các thiết bị đầu cuối phát lệnh INTERNAL AUTHENTICATE trong Quy trình xử lý DDA. Các lệnh bao gồm các dữ liệu động của thiết bị đầu cuối được quy định trong danh sách đối tượng dữ liệu chứng thực dữ liệu động (DDOL).
Lệnh INTERNAL AUTHENTICATE được mô tả chi tiết trong EMV Quyển 3, Điều 6.5.9. Nếu các ứng dụng hỗ trợ DDA thì thẻ cá nhân với DDOL chỉ chứa các số không thể đoán trước được tạo ra bởi các thiết bị đầu cuối (tag ‘9F37’).
Khi thẻ nhận lệnh INTERNAL AUTHENTICATE, nó sẽ tính toán xác minh rằng chữ ký ứng dụng dữ liệu động sử dụng khóa công khai ICC. Chữ ký động này bao gồm lệnh hồi đáp trong INTERNAL AUTHENTICATE.
Trong TCVN 11198-6, Điều 7 mô tả những hạn mức về số lượng lệnh của INTERNAL AUTHENTICATE cho mỗi giá trị của bộ đếm giao dịch ứng dụng (ATC).
8.7.1.1. Mã hóa lệnh
Bảng 11 – Thông điệp Lệnh INTERNAL AUTHENTICATE
Mã |
Giá trị |
CLA |
’00’ |
INS |
’88’ |
P1 |
’00’ |
P2 |
’00’ |
Lc |
’04’ |
data |
Dữ liệu xác thực có liên quan |
Le |
’00’ |
8.7.1.1.1. Định dạng lệnh hợp lệ
Req 3.8.4 (Kiểm tra giá trị P1/P2 cho xác thực nội biên )
Nếu cùng tham số P1 hoặc P2 không có giá trị ’00’, sau khi thẻ phải ngừng quy trình xử lý kết nối lệnh xác thực nội biên, phải hồi đáp với thông báo lỗi SW1 SW2 và phải hồi đáp với SW1 SW2 = ‘6A86’ (tham số không hợp lệ, P1-P2).
Req 3.8.5 (Kiểm tra chiều dài dữ liệu lệnh xác thực nội biên):
Nếu giá trị của Lc không bằng ‘04’, thì thẻ phải chấm dứt xử lý lệnh xác thực nội biên, và phải hồi đáp với thông báo lỗi SW1 SW1, phải hồi đáp với SW1 SW1 = ‘6700’ (Chiều dài sai)
8.7.1.2. Quy trình xử lý
Trong suốt quy trình xử lý chứng thực dữ liệu động DDA, thiết bị đầu cuối sử dụng công nghệ khóa công khai RSA được xác nhận chứng thực bởi tổ chức cung cấp chứng chỉ khóa công khai PK, chứng chỉ ICC PK, và chữ ký ứng dụng dữ liệu động (chữ ký động) từ thẻ.
Các chức năng chỉ được thực hiện trong quá trình xử lý dữ liệu động DDA là sinh ra số ICC động và chữ ký động. Xem Điều 7, TCVN 11198-6 về yêu cầu sinh số ICC động.
Quy trình xử lý dữ liệu động DDA được mô tả chi tiết trong EMV Quyển 2, Điều 6, EMV Quyển 3, Điều 10.3, và EMV Quyển 4, Điều 6.3.2.
Ứng dụng thiết lập bit “thực hiện DDA ngoại tuyến” trong CVR đối với giá trị 1b nếu và chỉ nếu chữ ký ứng dụng dữ liệu động được trả về bằng trả lời hồi đáp đối với lệnh xác thực nội biên.
Nếu toàn bộ bước xử lý dữ liệu động DDA thành công, thì xử lý dữ liệu động DDA được cho qua.
8.7.1.3. Biểu đồ luồng chức năng
Hình 3 – Biểu đồ INTERNAL AUTHENTICATE
8.7.2. Lệnh GENERATE APPLICATION CRYPTOGRAM (AC)
Các thiết bị đầu cuối đưa ra mã lệnh ứng dụng GENERATE AC lần đầu trong suốt Quy trình xử lý hành động thẻ đầu tiên.
Thiết bị đầu cuối có thể phát sinh mã lệnh ứng dụng GENERATE AC trong suốt quá trình xử lý phân tích hành động thẻ thứ hai. Nếu giao dịch đủ điều kiện cho sinh mã lệnh ứng dụng CDA, tham số P1 của lệnh GENERATE AC được thiết lập để yêu cầu xử lý CDA.
Nếu thẻ nhận lệnh GENERATE AC yêu cầu xử lý CDA, TC hoặc ARQC trả về bởi các thẻ bao gồm chữ ký khóa công khai được mô tả trong EMV Quyển 2, Điều 6.6.1. Xem Điều 5 và Điều 7 của TCVN 11198-4 để biết thông tin bổ sung về lệnh này.
8.7.2.1. Quy trình xử lý CDA
Quy trình xử lý CDA được mô tả chi tiết trong EMV Quyển 2, Điều 6, EMV Quyển 3, Điều 10.3, và EMV Quyển 4, Điều 6.3.2. Trong TCVN 11198-4, Điều 5 có mô tả về quy trình xử lý CDA trong CPA, bao gồm các yêu cầu thiết lập bit “thực hiện sinh mã lệnh ứng dụng-CDA” trong CVR.
Nếu toàn bộ các bước sinh mã lệnh ứng dụng CDA thành công, quá trình CDA thành công.
9. Ràng buộc Xử lý
9.1. Mục đích
CHÚ THÍCH Để cung cấp một mô tả đầy đủ hơn về xử lý giao dịch với ứng dụng CPA, phần này cung cấp một cái nhìn tổng quan về chức năng được cung cấp bởi các thiết bị đầu cuối EMV. CPA không đòi hỏi bất kỳ sự thay đổi chức năng thiết bị đầu cuối EMV.
Các chức năng Ràng buộc Xử lý được thực hiện bởi thiết bị đầu cuối sử dụng dữ liệu từ các thiết bị đầu cuối và các thẻ. Chức năng này bao gồm kiểm tra trên các phiên bản ứng dụng, ngày hiệu lực và ngày hết hạn, và các điều kiện tại các điểm giao dịch.
Ràng buộc Xử lý được mô tả chi tiết trong Điều 10.4 của EMV Quyển 3, và Điều 6.3.3 của EMV Quyển 4 và Điều 5 của TCVN 11198-7.
9.2. Trình tự thực hiện
9.2.1. Quy trình xử lý có liên quan trước đó
Đọc dữ liệu ứng dụng
Thiết bị đầu cuối sử dụng lệnh READ RECORD để có được dữ liệu ứng dụng trong các giao dịch. Những thông tin này bao gồm các mã quốc gia, phiên bản ứng dụng, ngày hết hạn, ngày có hiệu lực áp dụng.
9.2.2. Quy trình xử lý có liên quan tiếp theo
Phân tích Hành động Thiết bị đầu cuối
Trong suốt quá trình Phân tích Hành động Thiết bị đầu cuối, thiết bị đầu cuối kiểm tra mã hành động bên phát hành (IAC) và Mã hành động thiết bị đầu cuối (TAC) để xác định giao dịch được sắp đặt, hoặc yêu cầu các dịch vụ không được cho phép đối với các ứng dụng.
9.3. Dữ liệu thẻ
Dữ liệu thẻ được sử dụng trong Ràng buộc Xử lý được liệt kê và mô tả trong Bảng 12.
Mô tả chi tiết về dữ liệu và cách sử dụng xem tại Điều 7, TCVN 11198-8.
Bảng 12 – Ràng buộc Quy trình xử lý – Dữ liệu thẻ
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Ngày ứng dụng kích hoạt | Ngày ứng dụng bắt đầu được đưa vào sử dụng |
– |
‘5F25’ |
Ngày ứng dụng hết hạn | Ngày ứng dụng không còn trong thời gian sử dụng nữa |
– |
‘5F24’ |
Kiểm soát Lượng dùng ứng dụng (AUC) | Chỉ ra bất kỳ hạn chế đã được quy định bởi nhà cung cấp dịch vụ trong việc cho phép sử dụng ứng dụng thẻ. Sử dụng trong Kiểm soát Lượng dùng Ứng dụng kiểm tra bởi các thiết bị đầu cuối |
– |
‘9F07’ |
Số phiên bản ứng dụng | Cho phép biết số phiên bản ứng dụng thẻ. Các thiết bị đầu cuối có thể kiểm tra và xác định phiên bản ứng dụng trong các hệ thống thanh toán. |
– |
‘9F08’ |
Mã vùng | Các phần tử dữ liệu EMV cho biết xác định các nước phát hành thẻ. Sử dụng trong kiểm tra thiết bị đầu cuối. |
– |
‘5F28’ |
9.4. Dữ liệu thiết bị đầu cuối
Dữ liệu Thiết bị đầu cuối sử dụng trong ràng buộc Quy trình xử lý được liệt kê và mô tả trong Bảng 13.
Mô tả chi tiết về dữ liệu và sử dụng xem tại Điều 7, TCVN 11198-8.
Bảng 13 – Ràng buộc Quy trình xử lý – Dữ liệu thiết bị đầu cuối
Dữ liệu |
Mô tả |
Bản mẫu |
Nhãn |
Số phiên bản ứng dụng | Chỉ ra phiên bản ứng dụng trong các thiết bị đầu cuối. Đặc biệt là các hệ thống thanh toán |
– |
‘9F08’ |
Mã vùng thiết bị đầu cuối | Chỉ ra vùng thiết bị đầu cuối được xác định. Sử dụng trong việc kiểm tra thiết bị đầu cuối |
– |
‘9F1A’ |
Kết quả xác minh thiết bị đầu cuối (TVR) | Một loạt các chỉ số được sử dụng để ghi lại các kết quả của quy trình xử lý hành động ẩn từ thiết bị đầu cuối, bao gồm các kết quả của các Hạn mức xử lý kiểm tra thiết bị đầu cuối |
– |
‘95’ |
Ngày giao dịch | Thời gian địa phương trong thiết bị đầu cuối khi giao dịch đang diễn ra. Được sử dụng bởi các thiết bị đầu cuối để kiểm tra ngày có hiệu lực và ngày hết hạn |
– |
‘9A’ |
Kiểu giao dịch | Cho biết các loại giao dịch. (Được biểu diễn bằng hai chữ số đầu tiên của mã Quy trình xử lý, theo quy định của hệ thống thanh toán). Sử dụng trong kiểm soát kiểm tra bởi các thiết bị đầu cuối |
– |
‘9C’ |
9.5. Quy trình xử lý
Các thẻ không xử lý trong khi các chức năng Ràng buộc Xử lý. Các thiết bị đầu cuối sử dụng dữ liệu từ thẻ để kiểm tra xem các ứng dụng có thể được sử dụng cho các giao dịch, và chỉ ra điều kiện lỗi có thể có từ kết quả xác minh thiết bị đầu cuối (TVR).
Các điều sau đây mô tả chi tiết thiết bị đầu cuối sử dụng dữ liệu từ thẻ.
9.5.1. Số phiên bản Ứng dụng
Thiết bị đầu cuối so sánh các phiên bản ứng dụng từ thẻ đối với phiên bản ứng dụng trong các thiết bị đầu cuối để xem nếu chúng giống nhau. Nếu khác nhau thiết bị đầu cuối thiết lập một bit TVR để báo cho người phát hành các phiên bản có trùng khớp nhau hay không.
9.5.2. Kiểm soát Lượng dùng Ứng dụng
Trong suốt quá trình Kiểm soát Lượng dùng Ứng dụng, thiết bị đầu cuối kiểm tra một loạt điều kiện ở điểm giao dịch đối với thiết bị đầu cuối để xác định quy trình xử lý có nên tiếp tục hay không.
Nếu các Kiểm soát Lượng dùng Ứng dụng (AUC) và Mã Nước bên Phát hành nhận được từ thẻ trong suốt quá trình đọc dữ liệu ứng dụng, thiết bị đầu cuối kiểm tra cho phép Hạn mức ứng dụng:
Kiểm tra trong nước và quốc tế
Các thiết bị đầu cuối sẽ xác định liệu các giao dịch trong nước và quốc tế (Dựa trên mã vùng), và sau đó kiểm tra xem thẻ được sử dụng cho các loại giao dịch trong vùng của thiết bị đầu cuối.
CHÚ THÍCH Việc kiểm tra này được thực hiện bởi các thiết bị đầu cuối để bổ sung bất kỳ kiểm tra trong nước và quốc tế cái mà có thể được thực hiện bởi các ứng dụng như một phần của Quy trình xử lý ứng dụng hoặc quản lý rủi ro thẻ.
Kiểm tra máy ATM
Nếu thiết bị đầu cuối là một máy ATM, việc kiểm tra được thực hiện trên thẻ có được phép sử dụng ở máy ATM. Nếu thiết bị đầu cuối không phải là máy ATM, nó kiểm tra thẻ được cho phép sử dụng thiết bị đầu cuối xác định không thuộc về máy ATM
Nếu bất kỳ việc kiểm tra trên được thực hiện bởi các thiết bị đầu cuối không thành công, các thiết bị đầu cuối chỉ ra rằng ‘dịch vụ được yêu cầu không được phép cho thẻ’ trong TVR.
Mã Kiểm soát Lượng dùng Ứng dụng được mô tả trong EMV Quyển 3, Điều C2.
9.5.3. Ngày kích hoạt ứng dụng
Thiết bị đầu cuối thực hiện kiểm tra ngày kích hoạt Dữ liệu thẻ ứng dụng.
Việc này đảm bảo ứng dụng đang hoạt động bằng cách xác định ngày có hiệu lực từ thẻ đang còn ít hơn hay bằng với ngày giao dịch (thiết bị đầu cuối địa phương).
Nếu ngày ứng dụng hiệu lực lớn hơn ngày giao dịch, các thiết bị đầu cuối chỉ ra rằng trong TVR, ứng dụng chưa hết hạn.
9.5.4. Ngày hết hạn ứng dụng
Kiểm tra ngày hết hạn ứng dụng là bắt buộc.
Các thiết bị đầu cuối xác nhận rằng ứng dụng chưa hết hạn bằng cách đảm bảo rằng ngày hết hạn ứng dụng từ thẻ phải lớn hơn hoặc bằng ngày giao dịch.
Nếu ngày hết hạn ứng dụng ít hơn ngày giao dịch, thiết bị đầu cuối xác định trong kết quả xác minh thiết bị đầu cuối TVR đã bị hết hạn.
10. Xác minh Chủ thẻ
10.1. Mục đích
Xác minh Chủ thẻ được sử dụng để đảm bảo rằng chủ thẻ là hợp pháp và thẻ không bị mất hoặc bị đánh cắp.
Trong Xác minh Chủ thẻ, thiết bị đầu cuối sử dụng các quy tắc trong Danh sách CVM từ thẻ để xác định phương thức xác minh chủ thẻ (CVM) để sử dụng và thực hiện CVM đã chọn. Kết quả của quy trình xử lý CVM đóng một vai trò trong việc xử lý sau này.
Với các phương pháp mã PIN bản rõ ngoại tuyến và phương pháp mã PIN bản mã ngoại tuyến, việc xác minh mã PIN được thực hiện bên trong thẻ. Kết quả xác minh mã PIN ngoại tuyến có trong thông điệp chuẩn chi trực tuyến và cần được xem xét trong quyết định được ủy quyền của bên phát hành. Thẻ không đóng vai trò trong xử lý mã PIN trực tuyến hoặc chữ ký CVM.
Xác minh chủ thẻ được mô tả trong Điều 10.5, EMV Quyển 3.
10.2. Trình tự thực hiện
10.2.1. Quy trình xử lý có liên quan trước đó
Quy trình Khởi tạo Ứng dụng
Thiết bị đầu cuối sử dụng AIP được cung cấp bởi thẻ trong đáp ứng lệnh GET PROCESSING OPTIONS để xác định chủ thẻ.
Đọc dữ liệu ứng dụng
Các thiết bị đầu cuối đọc danh sách CVM và các dữ liệu khác được sử dụng trong quá trình CVM từ thẻ.
Danh sách CVM có thể phụ thuộc vào hồ sơ AFL gửi đến các thiết bị đầu cuối cho việc định danh các danh sách CVM khác nhau và cho các hồ sơ khác.
10.2.2. Quy trình xử lý có liên quan tiếp theo
Phân tích Hành động Thiết bị đầu cuối
Thiết bị đầu cuối sử dụng kết quả xác minh chủ thẻ và thẻ và các thông số để xác định xem các giao dịch ngoại tuyến có được giảm, gửi trực tuyến hoặc phê duyệt các giao dịch ngoại tuyến.
Phân tích Hành động Thẻ lần đầu
Các thẻ sử dụng mã thẻ được phát hành để xác định xem các giao dịch ngoại tuyến có được giảm không, gửi trực tuyến hoặc các giao dịch ngoại tuyến được phê duyệt nếu cố gắng vượt qua được mã PIN ngoại tuyến, việc xác minh mã PIN ngoại tuyến thất bại trong giao dịch hiện tại hoặc mã PIN ngoại tuyến không được thực hiện trong giao dịch hiện tại.
Xử lý trực tuyến
Nếu CVM là mã PIN ngoại tuyến, thì sau đó các thẻ sẽ không thực thi xử lý mã PIN này. Các thiết bị đầu cuối mã hóa mã PIN và các yêu cầu xác thực cho giao dịch trực tuyến.
Nếu CVM là mã PIN ngoại tuyến, mã PIN không bao gồm các yêu cầu xác thực cho giao dịch trực tuyến nhưng kết quả xác thực cho mã PIN ngoại tuyến sẽ bao gồm các yêu cầu cầu phải được xem xét trong quyết định ủy quyền của các bên phát hành.
Phân tích Hành động Thẻ lần hai
Nếu các thiết bị đầu cuối đã thử xác thực giao dịch trực tuyến nhưng không thành công, sau đó quá trình phân tích các hành động của thẻ sẽ sử dụng các quy tắc riêng trên thẻ (các CIAC để mặc định) để xác định xem có nên từ chối giao dịch đó không (xem Điều 7, TCVN 11198-4).
Những quy định này được xem như các điều kiện có thể xảy ra trong quá trình xác minh chủ thẻ: vượt qua Hạn mức của mã PIN, xác thực mã PIN thất bại hoặc việc xác thực mã PIN ngoại tuyến không được thực hiện.
Trong các Hồi đáp trực tuyến bên phát hành có thẻ đặt lại hoặc cập nhật các số còn lại của mã PIN và cố gắng sử dụng trạng thái cập nhật cho thẻ.
Quy trình xử lý Tập lệnh bên Phát hành đến Thẻ
Lệnh thay đổi mã PIN hoặc bẻ khóa có thể được sử dụng để thay đổi mã PIN hoặc thiết lập lại mã PIN.
10.3. Dữ liệu thẻ
Dữ liệu thẻ được sử dụng trong quá trình xác minh chủ thẻ được liệt kê và mô tả chi tiết trong Bảng 14.
Các mô tả chi tiết về dữ liệu và cách sử dụng xem Điều 7, TCVN 11198-8.
Bảng 14 – Xác minh Chủ thẻ – Dữ liệu thẻ
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Kiểm soát ứng dụng | Chỉ số được sử dụng để kích hoạt hoặc tắt các chức năng trong ứng dụng. |
– |
‘C1’ |
Mã Tiền Ứng dụng | Được sử dụng để xác định xem giao dịch bằng tiền hay bằng thẻ.
Nếu danh sách CVM hiện tại có giá trị cả hai số X hoặc Y trong danh sách CVM không có giá trị bằng không, các ứng dụng tiền tệ sẽ có mặt trong bản ghi được trỏ đến bởi AFL. |
– |
‘9F42’ |
Hồ sơ trao đổi ứng dụng (AIP) | Có một chỉ số được dùng để hỗ trợ xác minh chủ thẻ. |
– |
’82’ |
Kết quả xác minh thẻ (CVR) | Chứa 4 bít mã PIN thử đến giá trị và các chỉ số thiết lập thẻ theo các điều kiện sau:
• Xác minh mã PIN ngoại tuyến; • Xác minh mã PIN ngoại tuyến và xác mã PIN chưa được xác thực thành công; • Thử vượt qua các Hạn mức xác thực mã PIN; |
– |
‘9F52’ |
Danh sách phương pháp xác minh chủ thẻ (CVM) | Xác định danh sách ưu tiên của các phương pháp xác minh chủ thẻ cho thẻ ứng dụng.
Các thiết bị đầu cuối sử dụng danh sách CVM trong việc lựa chọn các phương pháp xác minh để thực hiện các giao dịch. CHÚ THÍCH: Danh sách CVM được sử dụng cho các giao dịch có thể khác nhau phụ thuộc hồ sơ giao dịch được chọn. |
– |
‘8E’ |
Mã hóa khóa bí mật mã PIN ICC hoặc Khóa bí mật ICC | Lưu trữ an toàn trên thẻ và không bao giờ truyền cho thiết bị đầu cuối.
Có thể được sử dụng để phục hồi lại mã PIN phù hợp với lệnh VERIFY trong quá trình kiểm tra mã PIN ngoại tuyến. |
– |
– |
Chứng chỉ khóa công khai mã PIN ICC hoặc chứng chỉ khóa công khai ICC | Ký kết với bên phát hành khóa bí mật. Chứa khóa công khai có thể được sử dụng để mã hóa PIN cho mã PIN ngoại tuyến.
Định dạng của mã PIN ICC và Chứng chỉ khóa công khai được miêu tả chi tiết trong EMV quyển 2, bảng 22. |
– |
‘9F2D’ hoặc ‘9F46’ |
Hàm mũ khóa công khai mã PIN ICC hoặc hàm mũ khóa công khai ICC | Chứa các hàm mũ được sử dụng trong thuật toán mã PIN cho mã PIN mã hóa ngoại tuyến.
CHÚ THÍCH: Hàm mũ khóa công khai mã PIN ICC hoặc hàm mũ khóa công khai ICC là 3 hoặc 216+ 1 |
– |
‘9F2E’ hoặc ‘9F47’ |
Phần còn lại khóa công khai mã PIN ICC hoặc phần còn lại của khóa công khai ICC | Chứa một phần cần thiết của khóa công khai mà không phù hợp với các chứng nhận khóa công khai của ICC. |
– |
‘9F2F’ hoặc ‘9F48’ |
Chứng chỉ tổ chức phát hành khóa công khai (PK) | Được ký với hệ thống thanh toán khóa công khai. Chứa khóa công khai được sử dụng để khôi phục các mã PIN ICC được mã hóa hoặc khóa công khai ICC từ Chứng chỉ. |
– |
’90’ |
Số mũ khóa công khai của bên phát hành | Chứa các số mũ được sử dụng trong thuật toán giải mã mã PIN ICC được mã hóa hoặc Chứng chỉ khóa công khai. |
– |
‘9F32’ |
Phần còn lại của bên phát hành khóa công khai | Chứa một phần cần thiết của bên phát hành khóa công khai mà không phù hợp bên trong bên phát hành Chứng chỉ khóa công khai. |
– |
’92’ |
Đếm số lần thử mã PIN | Xác định số lần thử mã PIN còn lại. Nó được đưa vào kiểm tra phản ứng để thông báo cho các thiết bị đầu cuối cho dù việc nhập mã PIN này được phép. Thiết bị này cũng có thể được thu được số lần thử mã PIN bằng cách sử dụng lệnh GET DATA.
Số lần thử mã PIN được giảm đi cho mỗi lần xác minh mã PIN không thành công. Nó được thiết lập lại để Hạn mức thời gian mỗi lần xác thực mã PIN thành công. Lệnh thay đổi hoặc bẻ khóa mã PIN cũng có thể được thiết lập lại trong suốt quá trình cập nhật trạng thái thẻ và phân tích hành động tiếp theo của thẻ. |
– |
‘9F17’ |
Hạn mức số lần thử mã PIN | Quy định tối đa số lần thử mã PIN. |
– |
‘C6’ |
Hồ sơ ID | Xác định hồ sơ kiểm soát được sử dụng để cấu hình các hành động giao dịch |
– |
– |
Tham chiếu mã PIN | Mã PIN của chủ thẻ được so sánh với các mã PIN giao dịch trong quá trình xử lý mã PIN ngoại tuyến. |
– |
– |
Định danh bên cung cấp ứng dụng đã đăng ký (RID), Định danh ứng dụng (AID) | 5 byte đầu tiên của ứng dụng AID dùng để nhận dạng hệ thống thanh toán.
Các RID được đăng ký tiêu chuẩn ISO. Các RID và Chứng chỉ ủy quyền khóa công khai được sử dụng trong hệ thống thanh toán sẽ được sử dụng để Hồi đáp lại bên phát hành khóa công khai. |
– |
– |
Tổ chức phát hỗ trợ việc xác minh chủ thẻ có trong AIP và được thiết lập giá trị là 1b để chỉ ra rằng các ứng dụng được hỗ trợ xác minh chủ thẻ.
Req 3.10.1 (Hỗ trợ danh sách CVM)
Các thẻ phải có một danh sách CVM và có thể chứa nhiều danh sách CVM để sử dụng trong các loại giao dịch khác nhau như giao dịch trong nước và giao dịch quốc tế. Chỉ có một danh sách CVM duy nhất được chỉ định trong một AFL để đọc trong một giao dịch.
Req 3.10.2 (Định dạng danh sách CVM)
Mỗi mục trong danh sách CVM được mã hóa theo định dạng xác minh chủ thẻ được mô tả trong EMV Quyển 3, Điều C3.
Req 3.10.3 (Tham chiếu hỗ trợ mã PIN)
Các tham chiếu mã PIN sẽ có mặt trên thẻ nếu nhà phát hành lựa chọn hỗ trợ xác minh mã PIN ngoại tuyến.
Req 3.10.4 (Tham chiếu cập nhật mã PIN)
Các tham chiếu mã PIN chỉ được cập nhật bởi lệnh bên phát hành hoặc sử dụng Thông điệp cho tính toàn vẹn và bảo mật. Các tham chiếu mã PIN có thể được cập nhật bằng cách sử dụng câu lệnh CHANGE/UNBLOCK PIN được mô tả trong TCVN 11198-5.
10.4. Dữ liệu thiết bị đầu cuối
Các dữ liệu đầu cuối sử dụng trong xử lý PIN được liệt kê và mô tả trong Bảng 15.
Thông tin mô tả chi tiết xem trong Điều 7, TCVN 11198-8.
Bảng 15 – Xử lý mã PIN – Dữ liệu thiết bị đầu cuối.
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Tổ chức chứng nhận khóa công khai | Được sử dụng với RID để xác định hệ thống thanh toán sử dụng khóa bí mật. |
– |
‘8F’ |
Kết quả CVM | Cho biết kết quả xử lý việc xác minh danh sách các chủ thẻ |
– |
‘9F34’ |
Kết quả xác minh thiết bị đầu cuối (TVR) | Một loạt các chỉ số được sử dụng để ghi lại các kết quả từ quan điểm của thiết bị đầu cuối, bao gồm cả kết quả của việc xác minh chủ thẻ. |
– |
’95’ |
Mã PIN | Dữ liệu được nhập vào bởi chủ thẻ và dùng cho mục đích xác thực mã PIN |
– |
– |
10.5. Lệnh GET DATA
Lệnh GET DATA có thể sử dụng bởi các thiết bị đầu cuối để thu được mã PIN từ thẻ. Lệnh này cũng hỗ trợ thu hồi thêm yếu tố dữ liệu ứng dụng, như được mô tả trong Điều 10.5.2.
10.5.1. Mã hóa lệnh
Bảng 16 – Thông điệp Lệnh GET DATA
Mã |
Giá trị |
CLA |
’80’ |
INS |
‘CA’ |
P1/P2 |
Tag |
Lc |
Không hiện diện |
data |
Không hiện diện |
Le |
’00’ |
10.5.1.1. Kiểm tra giá trị lệnh
Nếu P1 có giá trị ’00’, thì P2 chứa Tag có số byte đơn đối với thành phần dữ liệu hoặc các mẫu yêu cầu bởi lệnh GET DATA. Nếu không thì P1/P2 chứa 2 byte Tag đối với thành phần dữ liệu hoặc mẫu yêu cầu bởi lệnh GET DATA.
Reg 3.10.5 (Kiểm tra giá trị P1/P2 đối với GET DATA):
Nếu các thành phần P1 và P2 không được thiết lập giá trị của Tag hỗ trợ sử dụng lệnh GET DATA, thẻ phải chấm dứt xử lý lệnh GET DATA, và phải hồi đáp với thông báo SW1 SW2 lỗi, và phải hồi đáp với SW1 SW2 = ‘6A88’ (đối tượng dữ liệu tham chiếu không được tìm thấy).
10.5.2. Quy trình xử lý
Reg 3.10.6 (Hỗ trợ lệnh GET DATA như mô tả trong EMV)
Thẻ phải hỗ trợ lệnh GET DATA như mô tả trong EMV Quyển 3, Điều 6.5.7 thu hồi các thành phần dữ liệu liệt kê trong Điều 5, TCVN 11198-8 hỗ trợ lệnh GET DATA.
Xem Điều 11 trong TCVN 11198-7 để biết thông tin bổ sung về quản lý tài nguyên Hồ sơ sử dụng một thẻ tag bản mẫu đơn cho từng kiểu tài nguyên. Thẻ trả về tất cả các phần tử dữ liệu trong bản mẫu, theo thứ tự, và được phép gửi byte giá trị ’00’ trong lệnh hồi đáp dữ liệu GET DATA đối với một thẻ tag bản mẫu.
Reg 3.10.7 (GET DATA hỗ trợ giá trị và hạn mức thanh tổng)
Việc thu nhận giá trị và hạn mức Thanh tổng và Bộ đếm sử dụng lệnh GET DATA là tùy chọn bên phát hành. Nếu các tham số P1 và P2 được thiết lập giá trị ‘BF30’ thì:
• Nếu bit ‘Cho phép thu nhận các Giá trị và Hạn mức của Thanh tổng và Bộ đếm’ trong Kiểm soát Ứng dụng được thiết lập giá trị 0b, thì thẻ phải chấm dứt quy trình xử lý lệnh GET DATA, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6985’ (điều kiện sử dụng không phù hợp);
• Nếu không các thẻ sẽ trả về cho các thiết bị đầu cuối trong hồi đáp GET DATA. Bản mẫu ‘BF30’ chứa phần ghép mã TLV của Giá trị Thanh tổng x và Hạn mức Thanh tổng x của tất cả giá trị x mà Thanh tổng x được hỗ trợ bởi ứng dụng.
CHÚ THÍCH Nếu lệnh GET DATA được thực hiện ở mức ứng dụng, sau đó bit ‘Cho phép thu nhận các Giá trị và Hạn mức của Thanh tổng và Bộ đếm’ trong Kiểm soát Ứng dụng chỉ ra khi nào bên phát hành cho phép các giá trị và hạn mức bộ đếm được thu nhận bằng lệnh GET DATA.
Nếu GET DATA được cung cấp bởi các dịch vụ mức thẻ (ví dụ, Hệ thống vận hành thẻ) thay vì các ứng dụng, thì khi bên phát hành cho phép giá trị và hạn mức của Bộ đếm có thể được thu nhận qua các phương tiện khác, việc này nằm ngoài phạm vi của bộ tiêu chuẩn TCVN 11198, và các bit này là RFU.
Req 3.10.8 (GET DATA hỗ trợ giá trị và hạn mức Bộ đếm):
Việc thu nhận giá trị và hạn mức Thanh tổng và Bộ đếm sử dụng lệnh GET DATA là tùy chọn bên phát hành. Nếu các tham số P1 và P2 được thiết lập giá trị ‘BF35’ thì:
• Nếu bit ‘Cho phép thu nhận các Giá trị và Hạn mức của Thanh tổng và Bộ đếm’ trong Kiểm soát Ứng dụng được thiết lập giá trị 0b, thì thẻ phải chấm dứt quy trình xử lý lệnh GET DATA, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6985’ (điều kiện sử dụng không phù hợp);
• Nếu không các thẻ sẽ trả về cho các thiết bị đầu cuối trong hồi đáp GET DATA. Bản mẫu ‘BF35’ chứa các phần ghép TLV của Giá trị Bộ đếm x và Hạn mức Bộ đếm x của tất cả giá trị x mà Bộ đếm x được hỗ trợ bởi ứng dụng.
CHÚ THÍCH Nếu lệnh GET DATA được thực hiện ở mức ứng dụng, sau đó bit ‘Cho phép thu nhận các Giá trị và Hạn mức của Thanh tổng và Bộ đếm’ trong Kiểm soát Ứng dụng chỉ ra khi nào bên phát hành cho phép các giá trị và hạn mức bộ đếm được thu nhận bằng lệnh GET DATA.
Nếu GET DATA được cung cấp bởi các dịch vụ mức thẻ (ví dụ, Hệ thống vận hành thẻ) thay vì các ứng dụng, thì khi bên phát hành cho phép giá trị và hạn mức của Bộ đếm có thể được thu nhận qua các phương tiện khác, việc này nằm ngoài phạm vi của bộ tiêu chuẩn TCVN 11198, và các bit này là RFU.
Req 3.10.9 (GET DATA hỗ trợ cân bằng ngoại tuyến)
Việc thu nhận Cân bằng Ngoại tuyến bằng lệnh GET DATA là tùy chọn bên phát hành. Nếu các tham số P1, P2 được thiết lập giá trị ‘9F50’ thì:
• Nếu bit ‘Cho phép thu nhận các Giá trị và Hạn mức của Thanh tổng và Bộ đếm’ trong Kiểm soát Ứng dụng được thiết lập giá trị 0b, thì thẻ phải chấm dứt quy trình xử lý lệnh GET DATA, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6985’ (điều kiện sử dụng không phù hợp);
• Nếu không, thẻ phải trả về Cân bằng Ngoại tuyến đến thiết bị đầu cuối trong hồi đáp GET DATA.
CHÚ THÍCH: Nếu lệnh GET DATA được thực hiện ở mức ứng dụng, sau đó bit ‘Cho phép thu nhận các Giá trị và Hạn mức của Thanh tổng và Bộ đếm’ trong Kiểm soát Ứng dụng chỉ ra khi nào bên phát hành cho phép Cân bằng Ngoại tuyến nhận được bằng lệnh GET DATA.
Nếu GET DATA được cung cấp bởi các dịch vụ mức thẻ (ví dụ, Hệ thống vận hành thẻ) thay vì các ứng dụng, thì khi bên phát hành cho phép Cân bằng Ngoại tuyến có thể được thu nhận qua các phương tiện khác, việc này nằm ngoài phạm vi của bộ tiêu chuẩn TCVN 11198, và các bit này là RFU.
Sau khi các thiết bị đầu cuối được xác định một mã PIN Ngoại tuyến được nhập vào, các thiết bị đầu cuối có thể truyền tải một lệnh GET DATA vào thẻ để nhận Bộ đếm Lần thử mã PIN.
Thẻ trả về tag, chiều dài, và giá trị của các phần tử dữ liệu đã yêu cầu đến thiết bị đầu cuối trong hồi đáp GET DATA được mô tả trong EMV Quyển 3, phần 6.5.7.4.
10.5.3. Biểu đồ luồng GET DATA
Hình 3 thể hiện luồng quy trình xử lý GET DATA.
Hình 4 – Luồng GET DATA
10.6. Lệnh GET CHALLENGE
Nếu CVM là mã PIN mã hóa ngoại tuyến, thì ưu tiên phát hành lệnh VERIFY các thiết bị đầu cuối sử dụng lệnh GET CHALLENGE yêu cầu số không thể đoán trước từ thẻ sử dụng quy trình xử lý mã PIN mã hóa ngoại tuyến.
Req 3.10.10 (Hỗ trợ lệnh GET CHALLENGE):
Nếu thẻ hỗ trợ tùy chọn bên triển khai RSA động, thì thẻ phải hỗ trợ lệnh GET CHALLENGE được mô tả trong EMV Quyển 3, Điều 6.5.6.
10.6.1. Mã lệnh
Bảng 17 – Thông điệp Lệnh GET CHALLENGE
Mã |
Giá trị |
CLA |
’00’ |
INS |
’84’ |
P1 |
’00’ |
P2 |
’00’ |
Lc |
Không hiện diện |
Data |
Không hiện diện |
Le |
’00’ |
10.6.2. Quy trình xử lý
Lệnh định dạng hợp lệ
Req 3.10.11 (Kiểm tra giá trị P1/P2 đối với lệnh GET CHALLENGE):
Nếu tham số P1 hoặc P2 không thiết lập giá trị ’00’, thì thẻ phải ngừng quy trình xử lý lệnh GET CHALLENGE, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6A86’ (tham số không hợp lệ, P1-P2).
Tính toán Challenge
EMV quy định rằng giá trị Challenge là chỉ hợp lệ cho lệnh được phát hành tiếp theo, vì vậy nếu mã PIN mã hóa ngoại tuyến được sử dụng, các lệnh VERIFY ngay lập tức kèm theo lệnh GET CHALLENGE. Nếu một lệnh VERIFY chứa mã PIN đã mã hóa được nhận và lệnh trước đó không phải là một lệnh GET CHALLENGE thành công, lệnh VERIPY bỏ qua Xác minh mã PIN. Cách thức để thỏa mãn các yêu cầu này giúp cho việc triển khai.
10.6.3. Hồi đáp lệnh GET CHALLENGE
Các trường dữ liệu của hồi đáp chứa một số không thể đoán trước 8 byte được sinh ra bởi ICC.
Thuật toán tính toán giá trị Challenge này giúp cho việc triển khai.
Xem Điều 6 của TCVN 11198-6 về việc sinh ra số không thể đoán trước ICC.
10.6.4. Biểu đồ luồng GET CHALLENGE
Hình 5 thể hiện Quy trình xử lý lệnh GET CHALLENGE
Hình 5 – Luồng GET CHALLENGE
10.7. Lệnh VERIFY
Các lệnh VERIFY sử dụng để xác minh chủ thẻ mã PIN mã hóa ngoại tuyến và mã PIN bản rõ ngoại tuyến. Các lệnh VERIPY khởi tạo việc so sánh thẻ giữa mã PIN Giao dịch được chủ thẻ nhập vào với mã PIN Tham khảo.
Sau mỗi lần Xác minh mã PIN không thành công với số lần thử mã PIN còn lại (được chỉ trong SW1 SW2 ’63Cx’ với x ¹ 0), thiết bị đầu cuối có thể yêu cầu mục nhập mã PIN khác và gửi thẻ lệnh VERIFY khác. Chủ thẻ có thể tiếp tục nhập PIN cho đến khi Bộ đếm lần thử mã PIN giảm tới 0. Vào thời điểm đó thiết bị đầu cuối không được định trước sẽ không được truyền tải bất kỳ thông điệp lệnh VERIFY nào đến thẻ.
CHÚ THÍCH Các Từ khóa Trạng thái được quy định tại Điều 10 này là các Từ khóa Trạng thái được EMV quy định cho quy trình xử lý lệnh VERIFY. Chúng được sử dụng trong ứng dụng để thông báo bất kỳ bất thường trong khi xử lý lệnh VERIFY. Trong sự kiện lệnh VERIFY không thể xử lý một cách chính xác, cho phép thiết bị đầu cuối xử lý tiếp tục quy trình CVM theo quy định tại EMV Quyển 3. Bỏ qua việc sử dụng các Từ khóa Trạng thái trong điều này hoặc sử dụng các giá trị khác với quy định sẽ gây ra hủy giao dịch do thiết bị đầu cuối, dẫn đến một kết quả giao dịch không mong muốn (từ điểm quan sát bên phát hành/chủ thẻ). Đây được coi là những lỗi không thường xuyên xảy ra, sử dụng Từ khóa Trạng thái được EMV quy định so với các Từ khóa Trạng thái do ISO quy định sẽ cung cấp một dịch vụ tốt hơn cho các chủ thẻ.
Req 3.10.12 (Hỗ trợ lệnh VERIFY)
Thẻ phải hỗ trợ lệnh VERIFY được mô tả trong EMV Quyển 3, Điều 6.5.12.
10.7.1. Mã lệnh
Bảng 18 – Thông điệp lệnh VERIFY
Mã |
Giá trị |
CLA |
’00’ |
INS |
’20’ |
P1 |
’00’ |
P2 |
Tham chiếu dữ liệu (xem bên dưới) |
Lc |
Var |
Data |
Dữ liệu mã PIN giao dịch |
Le |
Không hiện diện |
Tham chiếu dữ liệu có thể theo giá trị sau:
• ‘80’ Khối mã PIN trong bản rõ;
• ‘88’ Khối mã hóa PIN;
Giá trị khác được cho phép, nhưng quy trình xử lý các giá trị khác nằm ngoài phạm vi của tiêu chuẩn này.
10.7.1.1. Xác minh Định dạng giá trị lệnh
Xác định mã PIN trong giao dịch:
CHÚ THÍCH Trong các yêu cầu sau, Kết quả xác minh thẻ bit CVR (Như thực hiện kiểm tra mã PIN Ngoại tuyến) được sử dụng nội bộ đối với các thẻ xác định trạng thái kiểm tra mã PIN Ngoại tuyến. CVR chỉ được mở rộng sẵn (chỉ có thể được kiểm chứng) trong Hồi đáp sinh ra lần đầu tiên và thứ hai. Do đó để đạt được các hành vi tương tự bằng cách sử dụng dữ liệu gốc độc quyền trong quá trình xử lý lệnh VERIFY để giữ trạng thái xác minh mã PIN, nếu các dữ liệu nội bộ được sử dụng thiết lập các bit ADR và CVR trong lần phát sinh đầu tiên và lần thứ hai.
Req 3.10.13 (Thiết lập thực hiện kiểm tra xác minh mã PIN trong CVR):
Sau khi thẻ nhận lệnh VERIFY, và trước khi kiểm tra giá trị cho P1 và P2, ứng dụng sẽ thiết lập bit ‘Xác minh mã PIN Ngoại tuyến đã thực hiện’ trong CVR đối với giá trị 1b.
Ứng dụng kiểm tra định dạng lệnh VERIFY.
Req 3.10.14 (Kiểm tra giá trị P1 cho VERIFY):
Nếu tham số P1 được thiết lập giá trị khác ’00’, thì thẻ phải chấm dứt quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi và phải hồi đáp SW1 SW2 = ‘6984’ (lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Req 3.10.15 (Hỗ trợ mã PIN bản rõ Ngoại tuyến bằng P2):
Một thẻ CPA sẽ hỗ trợ giá trị ’80’ (mã PIN bản rõ Ngoại tuyến) bằng tham số P2.
Req 3.10.16 (Hỗ trợ mã PIN được mã hóa ngoại tuyến bằng P2):
Thẻ hỗ trợ lựa chọn thành phần động RSA sẽ hỗ trợ giá trị ‘88’ (mã PIN mã hóa ngoại tuyến) bằng tham số P2.
Req 3.10.17 (giá trị P2 không hỗ trợ):
Nếu tham số P2 được thiết lập tới một giá trị không được hỗ trợ bởi thẻ, thì thẻ phải chấm dứt quy trình xử lý lệnh VERIFY, hỗ trợ với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (lệnh không cho phép, tham chiếu dữ liệu không hợp lệ).
10.7.2. Quy trình xử lý
Ứng dụng kiểm tra số lần thử mã PIN còn lại.
Req 3.10.18 (Hạn mức lần thử mã PIN)
Nếu Bộ đếm lần thử mã PIN có giá trị 0, thì ứng dụng phải thiết lập bit ‘Việc Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN đã xác minh không thành công’ trong CVR có giá trị 1b, phải chấm dứt xử lý lệnh VERIFY, và phải hồi đáp với SW1 SW2 = ‘6983’ (lệnh không cho phép, phương thức xác thực bị khóa).
Req 3.10.19 (Lỗi xác minh mã PIN không chặn ứng dụng):
Ứng dụng sẽ không bị chặn bởi việc xác minh mã PIN thất bại do vượt quá Hạn mức Lần thử mã PIN.
Req 3.10.20 (Lỗi xác minh mã PIN không chặn thẻ):
Thẻ sẽ không bị chặn bởi việc xác minh mã PIN thất bại do vượt quá Hạn mức Lần thử mã PIN.
Tiếp theo ứng dụng xử lý lệnh VERIFY được chỉ ra bởi tham số P2.
Req 3.10.21 (Quy trình xử lý mã PIN bản rõ Ngoại tuyến):
Nếu tham số P2 được thiết lập giá trị ’80’ (mã PIN bản rõ Ngoại tuyến), thì thẻ phải thực hiện quy trình xử lý mã PIN bản rõ Ngoại tuyến được mô tả trong Điều 10.7.2.1.
Req 3.10.22 (Quy trình xử lý mã PIN mã hóa Ngoại tuyến):
Nếu tham số P2 được thiết lập giá trị ’88’ (mã PIN mã hóa Ngoại tuyến), thì thẻ phải thực hiện quy trình xử lý mã PIN mã hóa Ngoại tuyến được mô tả trong Điều 10.7.2.2.
10.7.2.1. Kiểm tra mã PIN bản rõ Ngoại tuyến.
Thẻ kiểm tra rằng bên phát hành cho phép xác minh mã PIN bản rõ ngoại tuyến và dữ liệu lệnh có chiều dài hợp lệ.
Req 3.10.23 (Kiểm soát Ứng dụng không hỗ trợ mã PIN bản rõ):
Nếu Bit ‘Xác minh mã PIN ngoại tuyến được hỗ trợ’ trong Kiểm soát Ứng dụng có giá trị 0b, thì thẻ:
• Phải thiết lập bit ‘Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không xác minh thành công’ trong CVR bằng giá trị 1b;
• Phải chấm dứt quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Req 3.10.24 (Kiểm tra chiều dài dữ liệu lệnh cho mã PIN bản rõ)
Nếu Lc có một giá trị khác hơn ’08’, thì thẻ:
• Phải thiết lập bit ‘Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không xác minh thành công’ trong CVR bằng giá trị 1b;
• Phải chấm dứt quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Ứng dụng xác minh mã PIN bằng cách xác minh khối mã PIN đã định dạng một cách chính xác, và rằng mã PIN đã nhận trong lệnh trùng khớp với số PIN được lưu trữ nội bộ trong ứng dụng. Định dạng Khối mã PIN được mô tả trong EMV Quyển 3 bảng 24.
Req 3.10.25 (Kiểm tra định dạng khối mã PIN cho bản rõ mã PIN):
Nếu truyền dữ liệu không có toàn bộ điều kiện sau:
• Kiểm soát trường truyền dữ liệu mã PIN có giá trị ‘2’.
• Chiều dài trường mã PIN có giá trị lớn hơn hoặc bằng ‘4’ và ít hơn hoặc bằng ‘C’.
• Các số điền đầy đủ trong khi truyền dữ liệu mã PIN có giá trị ‘F’.
Thì định dạng khối mã PIN không có giá trị và mã PIN không thể xác minh. Ứng dụng:
• Sẽ thiết lập ‘Thực hiện xác minh mã PIN Ngoại tuyến và mã PIN xác minh không thành công’ bit trong CVR bằng giá trị 1b.
• Sẽ ngừng Quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (Lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Mặt khác (Định dạng khối mã PIN có giá trị), ứng dụng sẽ:
• Giảm đi một bằng hàm đếm mã PIN
• So sánh truyền mã PIN để tham chiếu mã PIN.
• Nếu truyền mã PIN không phù hợp với mã PIN tham chiếu thì xác minh mã PIN thất bại và ứng dụng sẽ:
▪ Thiết lập bit ‘Thực hiện xác minh mã PIN Ngoại tuyến và mã PIN không xác minh thành công’ trong CVR bằng giá trị 1b.
▪ Hồi đáp lệnh xác minh với SW1 SW2 = ‘63Cx’, ‘x’ đại diện cho số mã PIN.
• Nếu truyền mã PIN phù hợp với tham chiếu mã PIN, thì xác minh mã PIN là thành công và ứng dụng sẽ:
▪Thiết lập bit ‘Thực hiện xác minh mã PIN Ngoại tuyến và mã PIN không xác minh thành công’ trong CVR bằng giá trị 0b.
▪ Thiết lập hàm đếm mã PIN với giá trị của mã PIN được Hạn mức
▪ Xác định so sánh thành công lệnh Hồi đáp với SW1 SW2 = ‘9000’
10.7.2.2. Xác minh mã PIN mã hóa ngoại tuyến.
Thẻ kiểm tra rằng bên phát hành cho phép xác minh mã PIN mã hóa ngoại tuyến, và dữ liệu lệnh có chiều dài chính xác.
Req 3.10.26 (Kiểm soát Ứng dụng không hỗ trợ mã PIN mã hóa):
Nếu bit ‘Xác minh mã PIN mã hóa Ngoại tuyến được hỗ trợ’ trong kiểm soát ứng dụng có giá trị 0b, thì thẻ:
• Phải thiết lập bit ‘Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không xác minh thành công’ trong CVR bằng giá trị 1b;
• Phải chấm dứt quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Req 3.10.27 (Kiểm tra chiều dài mã PIN mã hóa sử dụng khóa riêng ICC):
Nếu khóa sử dụng để Xác minh mã PIN mã hóa Ngoại tuyến là khóa riêng ICC và Lc không bằng Nic, thì thẻ phải chấm dứt quy trình xử lý Lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (Lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Nếu lệnh VERIFY được thực hiện ở mức ứng dụng, các ‘cặp khóa được sử dụng cho Xác minh mã PIN mã hóa Ngoại tuyến’ bit trong kiểm soát ứng dụng chỉ ra trong lựa chọn khóa riêng ICC hoặc một chìa khóa mã hóa ICC cho mã hóa PIN Ngoại tuyến.
Nếu Xác minh mã PIN mã hóa Ngoại tuyến được cung cấp bởi một nền tảng thay vì các ứng dụng, chìa khóa sử dụng cho mã hóa xác minh mã PIN có thể được xác định thông qua có nghĩa là vượt ra ngoài phạm vi của quy chuẩn, và bit này là RFU.
Req 3.10.28 (Kiểm tra chiều dài mã hóa mã PIN sử dụng khóa mã hóa PIN ICC):
Nếu khóa sử dụng xác minh mã PIN mã hóa ngoại tuyến thì khóa riêng mã hóa mã PIN ICC và LC không bằng NPE, thì thẻ phải chấm dứt xử lý lệnh xác minh, phải hồi đáp với SW1 SW2 được xác minh lỗi, và phải hồi đáp với SW1 SW1 = ‘6984’ (lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Để xử lý các mã PIN mã hóa ngoại tuyến, các thiết bị đầu cuối cần một số lượng không thể đoán từ thẻ. Thiết bị đầu cuối sử dụng lệnh GET CHALLENGE (xem Điều 10.6) ưu tiên quy trình xử lý mã PIN mã hóa ngoại tuyến. Số ICC không thể đoán trước gửi tới thiết bị đầu cuối bằng hồi đáp còn lại có sẵn trong thẻ đối với ứng dụng để hoàn thành việc xác minh mã PIN mã hóa ngoại tuyến. Nếu lệnh VERIFY chứa mã hóa mã PIN đã nhận và lệnh trước đó không thực hiện GET CHALLENGE thành công, thì lệnh VERIFY thất bại trong xác minh mã PIN. Các thức để thỏa mãn các yêu cầu này nằm ngoài việc triển khai.
Req 3.10.29 (Không thực hiện GET CHALLENGE trước VERIFY):
Nếu không có challenge từ lệnh GET CHALLENGE ngay trước lệnh VERIFY, thì việc xác minh mã PIN thất bại và ứng dụng:
• Phải thiết lập bit ‘Việc Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không được xác minh thành công’ trong CVR bằng giá trị 1b.
• Phải ngừng quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (Lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Ứng dụng có thể giải mã các dữ liệu mã PIN giao dịch để khôi phục mã PIN và xác minh mã PIN được khôi phục như sau. EMV Quyển 2 cung cấp điều kiện chi tiết phát sinh và sử dụng khóa công khai/khóa riêng RSA được yêu cầu cho mã PIN mã hóa ngoại tuyến.
Nếu khóa được sử dụng cho mã PIN mã hóa ngoại tuyến là khóa mã hóa mã PIN ICC, thì ứng dụng sử dụng khóa riêng mã hóa mã PIN ICC để giải mã dữ liệu mã PIN giao dịch được mô tả từ bước 6 tới bước 9 trong Điều 7.2, EMV Quyển 2.
Nếu khóa sử dụng mã PIN mã hóa ngoại tuyến là khóa riêng ICC thì ứng dụng sử dụng khóa riêng ICC sử dụng cho DDA đối với việc giải mã dữ liệu mã PIN giao dịch được mô tả từ bước 6 tới bước 9 trong Điều 7.2, EMV Quyển 2.
Req 3.10.30 (Kiểm tra định dạng khôi phục dữ liệu):
Sau khi giải mã dữ liệu giao dịch mã PIN, nếu khôi phục dữ liệu không đạt cả hai hai điều kiện sau:
• Khôi phục số ICC không thể đoán trước trùng khớp với số ICC không thể đoán trước gửi trong hồi đáp tới lệnh GET CHALLENGE ngay trước lệnh VERIFY;
• Và khôi phục mào đầu dữ liệu có giá trị ‘7F’;
Thì ứng dụng:
• phải bỏ việc xác minh mã PIN;
• phải thiết lập bit ‘Việc Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không được xác minh thành công’ trong CVR bằng giá trị 1b;
• phải ngừng quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (Lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Nếu không thì ứng dụng phải tiếp tục với xác minh khối mã PIN đã khôi phục.
Ứng dụng xác minh mã PIN bằng cách xác minh khối mã PIN đã khôi phục được định dạng chính xác, và mã PIN đã khôi phục trùng khớp với mã PIN đã lưu trữ nội bộ trong ứng dụng. Định dạng Khối mã PIN được mô tả trong EMV Quyển 3, Bảng 24.
Req 3.10.31 (Kiểm tra định dạng khối mã PIN cho mã PIN đã mã hóa):
Nếu khối mã PIN đã khôi phục không đạt tất cả các điều kiện sau:
• Trường Kiểm soát của khối mã PIN đã khôi phục có giá trị ‘2’;
• Trường Chiều dài mã PIN của khối mã PIN đã khôi phục có giá trị lớn hơn hoặc bằng ‘4’ và nhỏ hơn hoặc bằng ‘C’;
• Các số Điền đầy của khối mã PIN đã khôi phục có giá trị ‘F’.
Thì định dạng Khối mã PIN là không hợp lệ và mã PIN không thể được xác minh. Ứng dụng phải thiết lập bit ‘Việc Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không được xác minh thành công’ trong CVR bằng giá trị 1b, phải ngừng quy trình xử lý lệnh VERIFY, phải hồi đáp với SW1 SW2 chỉ ra một lỗi, và phải hồi đáp với SW1 SW2 = ‘6984’ (Lệnh không cho phép, dữ liệu tham chiếu không hợp lệ).
Nếu khác (tức là định dạng Khối mà PIN là hợp lệ), ứng dụng phải:
• Bộ đếm lần thử mã PIN giảm đi một;
• So sánh khối mã PIN đã khôi phục với mã PIN tham khảo;
▪ Nếu mã PIN được khôi phục không giống với mã PIN tham khảo, thì xác minh mã PIN thất bại và ứng dụng phải:
• Thiết lập bit ‘Việc Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không được xác minh thành công’ trong CVR bằng giá trị 1b;
• Hồi đáp đối với lệnh xác minh SW1 SW2 = ‘63Cx’, x biểu diễn cho số lần thử mã PIN còn lại;
▪ Nếu mã PIN khôi phục giống với mã PIN tham chiếu, thì xác minh mã PIN là thành công và ứng dụng sẽ là:
• Thiết lập bit ‘Việc Xác minh mã PIN Ngoại tuyến đã thực hiện và mã PIN không được xác minh thành công’ trong CVR bằng giá trị 0b;
• Thiết lập lại Bộ đếm lần Thử mã PIN thành giá trị của Hạn mức lần Thử mã PIN;
• Chỉ ra việc hoàn thành lệnh thành công bằng cách gửi hồi đáp với SW1 SW2 = ‘9000’.
CHÚ THÍCH Điều kiện yêu cầu bảo mật cho bảo vệ mã PIN tham khảo và khóa riêng RSA được đề cập trong Điều 6, TCVN 11198-6.
10.7.3. Biểu đồ luồng VERIFY
Hình 6 thể hiện cách ứng dụng xử lý một lệnh VERIFY.
Hình 6 – Biểu đồ luồng VERIFY
Hình 6 – Biểu đồ luồng VERIFY (tiếp theo)
Hình 6 – Biểu đồ luồng VERIFY (kết thúc)
11. Quản lý rủi ro thiết bị đầu cuối
11.1. Mục đích
Quản lý rủi ro thiết bị đầu cuối đảm bảo các giao dịch có giá trị cao hơn giá trị trực tuyến, và đảm bảo các giao dịch trực tuyến định kỳ để bảo vệ chống lại các rủi ro tín dụng và gian lận và có thể không phát hiện được trong môi trường ảo.
CHÚ THÍCH Để cung cấp một mô tả đầy đủ hơn về xử lý giao dịch ứng dụng CPA, phần này cung cấp một cái nhìn tổng quan về chức năng thiết bị đầu cuối thẻ tích hợp EMV. CPA không đòi hỏi bất kỳ sự thay đổi nào đối với chức năng thiết bị đầu cuối thẻ tích hợp.
Tổ chức có thể yêu cầu các thiết bị đầu cuối để thực hiện quản lý rủi ro bằng cách thiết lập các “Quản lý rủi ro thiết bị đầu cuối để thực hiện bit gán giá trị AIP bằng 1b. Các thiết bị đầu cuối có thể thực hiện quản lý rủi ro thiết bị đầu cuối hay không là yêu cầu của thẻ.
Quản lý rủi ro thiết bị đầu cuối được mô tả trong EMV Quyển 3, Điều 10.6, và EMV Quyển 4, Điều 6.3.5.
11.2. Trình tự thực hiện
11.2.1. Quy trình xử lý có liên quan trước đó
Đọc dữ liệu ứng dụng
Dữ liệu sau được đọc từ thẻ:
• Số Tài khoản Chính Ứng dụng (PAN) và số Chuỗi PAN Ứng dụng đã sử dụng trong kiểm tra tệp tin ngoại lệ thiết bị đầu cuối và Hạn mức sàn.
11.2.2. Quy trình xử lý có liên quan tiếp theo
Phân tích Hành động Thiết bị đầu cuối
Xác định thiết bị đầu cuối dựa trên cài đặt thẻ và thiết bị đầu cuối nếu:
• Thẻ có Tệp tin Ngoại lệ Thiết bị đầu cuối;
• Bắt buộc thực hiện giao dịch trực tuyến;
• Hạn mức Sàn Thiết bị đầu cuối bị vượt quá;
• Lựa chọn giao dịch ngẫu nhiên cho quy trình xử lý trực tuyến.
11.3. Dữ liệu thẻ
Dữ liệu thẻ sử dụng trong quản lý rủi ro thiết bị đầu cuối được liệt kê và mô tả trong Bảng 19.
Thông tin mô tả chi tiết xem trong Điều 7, TCVN 11198-8.
Bảng 19 – Quản lý rủi ro thiết bị đầu cuối – Dữ liệu thẻ
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Chuỗi số ứng dụng PAN | Xác định sử dụng thẻ khác nhau với ứng dụng số cá nhân giống nhau PAN |
– |
‘5F34’ |
Số tài khoản ứng dụng cá nhân chính PAN | Số tài khoản thẻ lưu giữ đối với từng ứng dụng |
– |
‘5A’ |
11.4. Dữ liệu Thiết bị đầu cuối
Dữ liệu Thiết bị đầu cuối sử dụng quản lý rủi ro thiết bị đầu cuối được mô tả trong EMV Quyển 3, phần 10.6 và Phụ lục A1.
11.5. Quy trình xử lý
Ứng dụng thanh toán chung CPA không xử lý trong suốt quá trình quản lý rủi ro thiết bị đầu cuối. Theo như mô tả cách thiết bị đầu cuối sử dụng dữ liệu từ thẻ trong suốt quá trình quản lý rủi ro thiết bị đầu cuối.
11.5.1. Tệp tin Ngoại lệ Thiết bị đầu cuối
Nếu một Tệp tin Ngoại lệ Thiết bị đầu cuối hiện tại, thiết bị đầu cuối có thể kiểm tra số tài khoản ứng dụng chính PAN và chuỗi số cá nhân ứng dụng PAN từ thẻ được liệt kê trên tệp tin loại bỏ.
11.5.2. Bắt buộc thực hiện giao dịch trực tuyến
Ở thiết bị đầu cuối trực tuyến, cần chỉ ra các thiết bị đầu cuối mà giao dịch phải được xử lý trực tuyến. Thẻ không dữ liệu được sử dụng trong quá trình này.
11.5.3. Hạn mức sàn
Kiểm tra Hạn mức sàn được thực hiện giao dịch với tổng số Hạn mức sàn thiết bị đầu cuối được gửi trực tuyến cho xác thực. Xem EMV Quyển 3, Điều 10.6.1 để biết thêm thông tin. Thẻ không dữ liệu được sử dụng trong trường hợp này.
11.5.4. Lựa chọn giao dịch ngẫu nhiên
Thiết bị đầu cuối có khả năng hỗ trợ cả giao dịch nội và ngoại tuyến, có thể lựa chọn giao dịch ngẫu nhiên xử lý trực tuyến. Xem EMV Quyển 3, Điều 10.6.2 để biết thêm thông tin. Thẻ không dữ liệu được sử dụng trong quá trình này.
11.5.5. Kiểm tra nhanh thiết bị đầu cuối
Ứng dụng thanh toán chung CPA kiểm tra nhanh quản lý rủi ro thiết bị đầu cuối trên thẻ như phần của quản lý rủi ro thẻ, do vậy CPA không yêu cầu thiết bị đầu cuối thực hiện kiểm tra nhanh quản lý rủi ro.
Bởi vì Hạn mức Dưới tích lũy ngoại tuyến và Hạn mức Trên tích lũy ngoại tuyến không hiện diện trong ứng dụng, thiết bị đầu cuối không thực hiện kiểm tra nhanh và kiểm tra thẻ mới mô tả trong EMV Quyển 3, Điều 10.6.3.
12. Phân tích Hành động Thiết bị đầu cuối
12.1. Mục đích
Theo cung cấp mô tả quy trình xử lý giao dịch với ứng dụng CPA, phần này cung cấp một cái nhìn tổng quan cung cấp các chức năng bởi thiết bị đầu cuối EMV. CPA không yêu cầu bất kỳ thay đổi nào đối với chức năng thiết bị đầu cuối EMV.
Trong Phân tích Hành động Thiết bị đầu cuối, thiết bị đầu cuối áp dụng luật bằng thẻ và bằng hệ thống thanh toán trong thiết bị đầu cuối đối với kết quả Quy trình Quy trình xử lý Ngoại tuyến để xác định giao dịch có thể được chấp nhận ngoại tuyến, từ chối ngoại tuyến, hoặc gửi trực tuyến để ủy quyền
Phân tích Hành động Thiết bị đầu cuối được thực hiện như mô tả trong EMV Quyển 3, Điều 10.7.
12.2. Trình tự thực hiện
12.2.1. Quy trình xử lý có liên quan trước đó
Đọc dữ liệu ứng dụng
Trong suốt quá trình đọc dữ liệu ứng dụng, thẻ gửi bản ghi dữ liệu ứng dụng tới thiết bị đầu cuối. Bản ghi dữ liệu bao gồm IAC và CDOL1 được sử dụng trong suốt quá trình Phân tích Hành động Thiết bị đầu cuối.
12.2.2. Quy trình xử lý có liên quan tiếp theo
Phân tích hành động thẻ đầu tiên
Trong quá trình phân tích hành động thẻ đầu tiên, thẻ thực hiện các điều kiện quản lý rủi ro để xác định các ngoại lệ Phân tích Hành động Thiết bị đầu cuối quyết định để chấp nhận ngoại tuyến hoặc gửi thực hiện trực tuyến. Một thiết bị đầu cuối bị từ chối ngoại tuyến không thể bị ghi đè bởi các thẻ.
12.3. Dữ liệu thẻ
Dữ liệu thẻ sử dụng trong Phân tích Hành động Thiết bị đầu cuối được liệt kê và mô tả trong Bảng 20.
Thông tin mô tả chi tiết xem trong Điều 7, TCVN 11198-8.
Bảng 20 – Phân tích Hành động Thiết bị đầu cuối – Dữ liệu thẻ
Dữ liệu |
Mô tả |
Bản Mẫu |
Tag |
Danh sách đối tượng quản lý rủi ro thẻ 1 (CDOL1) |
CDOL1 chứa tags và chiều dài đối tượng dữ liệu thiết bị đầu cuối bởi các thẻ tạo ra một loại ẩn ứng dụng hay xử lý thẻ khác.
Tham khảo Điều 7, TCVN 11198-8: Từ điển dữ liệu yêu cầu CDOL1. Và Điều 5, TCVN 11198-4, Phân tích hành động thẻ lần đầu, cho thấy các yêu cầu CDOL1 đối với phân tích hành động thẻ. |
– |
‘8C’ |
Mã hành động bên phát hành (IAC) |
Mã hành động bên phát hành lACs là ba phần tử dữ liệu, mỗi bộ gồm một loạt các bít tương ứng so với các bit trong các kết quả xác nhận thiết bị đầu cuối (TVR). Trong thời gian cá nhân, các bên phát hành phải thiết lập IAC thành 1b kiểm soát TVR tương ứng theo chỉ định IAC. Ba lACs là:
• lAC – Từ chối |
|
|
Bên phát hành thiết lập giá trị 1b các bít IAC tương ứng với các bít cho TVR điều kiện và nhà phát hành muốn dẫn đến một sự suy giảm ngoại tuyến; |
– |
‘9F0E’ |
|
• IAC – Trực tuyến |
|
|
|
Bên phát hành thiết lập giá trị 1b cho các bít IAC tương ứng với các bít TVR cho điều kiện mà các nhà phát hành muốn kết quả trong xác thực trực tuyến; |
– |
‘9F0F’ |
|
• IAC – Mặc định |
|
|
|
Bên phát hành thiết lập giá trị 1b cho các bít IAC tương ứng với điều kiện TVR bit mà bên phát hành muốn mặc định để suy từ chối ngoại tuyến nếu Quy trình xử lý trực tuyến được yêu cầu nhưng không có giá trị. |
– |
‘9F0D’ |
Mã hành động bên phát hành IAC bao gồm trong phần tử dữ liệu được đề nghị để xác định bởi dữ liệu xác thực ngoại tuyến.
Nếu IAC có trong xác nhận dữ liệu đối với các ứng dụng dữ liệu chữ ký tính (SSAD), chứng nhận ICC PK, chứng nhận PK hoặc mã hóa PIN ICC, IAC không nên thay đổi và cũng không cập nhật SSAD và chứng chỉ khi cần thiết.
Mặt khác SDA, DDA, CDA, và (Nếu khóa riêng ICC được sử dụng cho mã hóa PIN Ngoại tuyến) mã hóa PIN Ngoại tuyến sẽ thất bại.
12.4. Dữ liệu thiết bị đầu cuối
Dữ liệu thiết bị đầu cuối trong Phân tích Hành động Thiết bị đầu cuối được liệt kê và mô tả trong Bảng 21. Mô tả chi tiết dữ liệu và sử dụng, xem Điều 7 trong TCVN 11198-8 và EMV Quyển 3, Điều 10.7.
Bảng 21 – Tổng quan kết quả Quy trình xử lý Ngoại tuyến – Dữ liệu thiết bị đầu cuối
Dữ liệu |
Mô tả |
Bản mẫu |
Tag |
Mã hành động thiết bị thiết bị đầu cuối (TAC) | Mã hành động thiết bị đầu cuối TAC là ba phần tử dữ liệu mỗi phần tử tương ứng với một loạt các bit trong kết quả xác nhận thiết bị đầu cuối (TVR).
Tương tự như thẻ lACs, các bit TAC được thiết lập thành 1b nếu bít TVR tương ứng là kết quả trong hành động theo quy định của TAC. Những hành động này làm suy giảm xác thực ngoại tuyến, trực tuyến, và từ chối ngoại tuyến nếu xác thực trực tuyến không thể hoàn thành |
– |
– |
Kết quả mã xác nhận thiết bị đầu cuối (TVR) | Một loạt các chỉ số được sử dụng để ghi lại các kết quả của quy trình Quy trình xử lý Ngoại tuyến bởi thiết bị đầu cuối, bao gồm cả các kết quả của kiểm tra quản lý rủi ro thiết bị đầu cuối |
– |
’95’ |
12.5. Quy trình xử lý
Phân tích Hành động Thiết bị đầu cuối gồm hai bước:
• Rà soát kết quả Quy trình xử lý Ngoại tuyến;
• Yêu cầu mã lệnh.
12.5.1. Rà soát kết quả Quy trình xử lý Ngoại tuyến
Bước rà soát kết quả Quy trình xử lý Ngoại tuyến của Phân tích Hành động Thiết bị đầu cuối là thực hiện hoàn toàn với thiết bị đầu cuối. Các thiết bị đầu cuối xem xét kết quả của Quy trình xử lý Ngoại tuyến để xác định giao dịch có nên trực tuyến không, được chấp nhận ngoại tuyến, hoặc từ chối ngoại tuyến. Quá trình này xem xét các tiêu chí phát hành từ thẻ được gọi là mã hành động bên phát hành, và tiêu chí thu được trong thiết bị đầu cuối gọi là mã hành động thiết bị đầu cuối (TACs).
Thẻ thực hiện xử lý trong suốt quá trình soát xét xử lý ngoại tuyến. Quá trình xử lý thiết bị đầu cuối so sánh các bít trong IAC và TAC đối với các bít tương ứng trong TVR.
Nếu bất kỳ các bít TVR có giá trị 1b, và các bít tương ứng hoặc IAC hay TAC cũng có giá trị 1b, sau khi các thiết bị đầu cuối yêu cầu các hành động cụ thể của các kiểu IAC/TAC.
• Từ chối giao dịch ngoại tuyến bằng gửi các yêu cầu kiểu Mã lệnh Ứng dụng AAC;
• Gửi các giao dịch trực tuyến bằng các yêu cầu kiểu Mã lệnh Ứng dụng ARQC.
Mặt khác, thiết bị đầu cuối sẽ yêu cầu các thẻ chấp nhận giao dịch ngoại tuyến bằng cách yêu cầu với Mã lệnh Ứng dụng kiểu TC.
Mô tả chi tiết quy trình xử lý này, xem EMV Quyển 3, Điều 10.7.
12.5.2. Yêu cầu Quy trình xử lý Mã lệnh
Trong bước yêu cầu xử lý mã hóa của phân tích hành động ứng dụng, các định dạng thiết bị đầu cuối lệnh đầu tiên phát sinh mã lệnh ứng dụng (phát sinh AC) và các vấn đề với thẻ yêu cầu sinh mã ứng dụng DES. Lệnh bao gồm giá trị của dữ liệu thẻ và độ dài được liệt kê trong CDOL1. Các thiết bị đầu cuối cho biết trong một tham số lệnh DDA/AC sinh mã CDA được thực hiện. CDA không yêu cầu khi thiết bị đầu cuối yêu cầu kiểu Mã lệnh Ứng dụng AAC (từ chối ngoại tuyến).
Để biết chi tiết về mã hóa và xử lý các lệnh GENERATE AC xem Điều 5, TCVN 11198-4, lệnh GENERATE AC lần đầu. Phân tích Hành động Thiết bị đầu cuối hoàn thành khi thiết bị đầu cuối đảm bảo lệnh GENERATE AC lần đầu đối với thẻ.
Khi thẻ nhận lệnh GENERATE AC lần đầu, sẽ xử lý phân tích hành động thẻ đầu tiên (Điều 5, TCVN 11198-4)
THƯ MỤC TÀI LIỆU THAM KHẢO
[1] TCVN 11198-4, Thẻ mạch tích hợp EMV cho Hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung – Phần 4: Phân tích hành động thẻ;
[2] TCVN 11198-5, Thẻ mạch tích hợp EMV cho Hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung – Phần 5: Quy trình xử lý tập lệnh bên phát hành đến thẻ;
[3] TCVN 11198-6, Thẻ mạch tích hợp EMV cho Hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung – Phần 6: Quản lý khóa và an ninh;
[4] TCVN 11198-7, Thẻ mạch tích hợp EMV cho Hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung – Phần 7: Mô tả về chức năng;
[5] TCVN 11198-8, Thẻ mạch tích hợp EMV cho Hệ thống thanh toán – Đặc tả ứng dụng thanh toán chung – Phần 8: Thư mục phần tử dữ liệu;
[6] EMV Book 1, EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 1, Application Independent ICC to Terminal Interface Requirements, May 2004 (EMV Quyển 1).
[7] EMV Book 2, EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 2, Security and Key Management, May 2004 (EMV Quyển 2).
[8] EMV Book 3, EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 3, Application Specification, May 2004. (EMV Quyển 3).
[9] EMV Book 4, EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 4, Cardholder, Attendant, and Acquirer lnterface Requirements, May 2004. (EMV Quyển 4).
MỤC LỤC
Lời nói đầu
1. Phạm vi áp dụng
2. Tài liệu viện dẫn
3. Thuật ngữ và định nghĩa
4. Thuật ngữ viết tắt, ký hiệu, quy ước và biểu tượng
5. Lựa chọn ứng dụng
5.1. Mục đích
5.2. Trình tự thực hiện
5.2.1. Quy trình xử lý có liên quan tiếp theo
5.3. Quy trình xử lý
5.3.1. Xây dựng Danh sách Ứng viên
5.3.2. Định danh và Lựa chọn Ứng dụng
6. Quy trình Khởi tạo Ứng dụng
6.1. Mục đích
6.2. Trình tự thực hiện
6.2.1. Quy trình xử lý có liên quan trước đó
6.2.2. Quy trình xử lý có liên quan tiếp theo
6.3. Dữ liệu thẻ
6.4. Dữ liệu Thiết bị đầu cuối
6.5. Lệnh GET PROCESSING OPTIONS
6.5.1. Mã hóa Lệnh
6.5.2. Quy trình xử lý
6.5.3. Lựa chọn Hồ sơ
6.5.4. Hành vi Hồ sơ
6.5.5. Hồi đáp lệnh GET PROCESSING OPTIONS
6.6. Biểu đồ luồng chức năng
7. Đọc dữ liệu ứng dụng
7.1. Mục đích
7.2. Trình tự thực hiện
7.2.1. Quy trình xử lý có liên quan trước đó
7.2.2. Quy trình xử lý có liên quan tiếp theo
7.3. Dữ liệu thẻ
7.4. Dữ liệu thiết bị đầu cuối
7.5. Lệnh READ RECORD
7.5.1. Mã hóa lệnh
7.5.2. Quy trình Xử lý
7.5.3. Hồi đáp lệnh READ RECORD
7.6. Biểu đồ luồng chức năng
7.7. Yêu cầu Tệp tin Bổ sung
7.7.1. Tệp tin dữ liệu VLP
7.7.2. Tệp tin Log Giao dịch
7.7.3. Tệp tin chứa Mục nhập Lựa chọn Hồ sơ
8. Xác thực dữ liệu ngoại tuyến
8.1. Mục đích
8.2. Trình tự thực hiện
8.2.1. Quy trình xử lý có liên quan trước đó
8.2.2. Quy trình xử lý có liên quan tiếp theo
8.3. Dữ liệu thẻ
8.4. Dữ liệu thiết bị đầu cuối
8.5. Khả năng thực thi của SDA, DDA hoặc CDA
8.6. Xác thực dữ liệu tĩnh (SDA)
8.6.1. Các lệnh
8.6.2. Quy trình xử lý
8.7. Xác thực Dữ liệu Động Ngoại tuyến
8.7.1. Lệnh INTERNAL AUTHENTICATE
8.7.2. Lệnh GENERATE APPLICATION CRYPTOGRAM (AC)
9. Ràng buộc Xử lý
9.1. Mục đích
9.2. Trình tự thực hiện
9.2.1. Quy trình xử lý có liên quan trước đó
9.2.2. Quy trình xử lý có liên quan tiếp theo
9.3. Dữ liệu thẻ
9.4. Dữ liệu thiết bị đầu cuối
9.5. Quy trình xử lý
9.5.1. Số phiên bản ứng dụng
9.5.2. Kiểm soát Lượng dùng Ứng dụng
9.5.3. Ngày kích hoạt ứng dụng
9.5.4. Ngày hết hạn ứng dụng
10. Xác minh Chủ thẻ
10.1. Mục đích
10.2. Trình tự thực hiện
10.2.1. Quy trình xử lý có liên quan trước đó
10.2.2. Quy trình xử lý có liên quan tiếp theo
10.3. Dữ liệu thẻ
10.4. Dữ liệu thiết bị đầu cuối
10.5. Lệnh GET DATA
10.5.1. Mã hóa lệnh
10.5.2. Quy trình xử lý
10.5.3. Biểu đồ luồng GET DATA
10.6. Lệnh GET CHALLENGE
10.6.1. Mã lệnh
10.6.2. Quy trình xử lý
10.6.3. Hồi đáp lệnh GET CHALLENGE
10.6.4. Biểu đồ luồng GET CHALLENGE
10.7. Lệnh VERIFY
10.7.1. Mã lệnh
10.7.2. Quy trình xử lý
10.7.3. Biểu đồ luồng VERIFY
11. Quản lý rủi ro thiết bị đầu cuối
11.1. Mục đích
11.2. Trình tự thực hiện
11.2.1. Quy trình xử lý có liên quan trước đó
11.2.2. Quy trình xử lý có liên quan tiếp theo
11.3. Dữ liệu thẻ
11.4. Dữ liệu Thiết bị đầu cuối
11.5. Quy trình xử lý
11.5.1. Tệp tin Ngoại lệ Thiết bị đầu cuối
11.5.2. Bắt buộc thực hiện giao dịch trực tuyến
11.5.3. Hạn mức sàn
11.5.4. Lựa chọn giao dịch ngẫu nhiên
11.5.5. Kiểm tra nhanh thiết bị đầu cuối
12. Phân tích Hành động Thiết bị đầu cuối
12.1. Mục đích
12.2. Trình tự thực hiện
12.2.1. Quy trình xử lý có liên quan trước đó
12.2.2. Quy trình xử lý có liên quan tiếp theo
12.3. Dữ liệu thẻ
12.4. Dữ liệu thiết bị đầu cuối
12.5. Quy trình xử lý
12.5.1. Rà soát kết quả Quy trình xử lý Ngoại tuyến
12.5.2. Yêu cầu Quy trình xử lý Mã lệnh
Thư mục tài liệu tham khảo.
TIÊU CHUẨN QUỐC GIA TCVN 11198-3:2015 VỀ THẺ MẠCH TÍCH HỢP EMV CHO HỆ THỐNG THANH TOÁN – ĐẶC TẢ ỨNG DỤNG THANH TOÁN CHUNG – PHẦN 1: QUY TRÌNH XỬ LÝ CHỨC NĂNG | |||
Số, ký hiệu văn bản | TCVN11198-3:2015 | Ngày hiệu lực | |
Loại văn bản | Tiêu chuẩn Việt Nam | Ngày đăng công báo | |
Lĩnh vực |
Lĩnh vực khác |
Ngày ban hành | 01/01/2015 |
Cơ quan ban hành |
Bộ khoa học và công nghê |
Tình trạng | Còn hiệu lực |
Các văn bản liên kết
Văn bản được hướng dẫn | Văn bản hướng dẫn | ||
Văn bản được hợp nhất | Văn bản hợp nhất | ||
Văn bản bị sửa đổi, bổ sung | Văn bản sửa đổi, bổ sung | ||
Văn bản bị đính chính | Văn bản đính chính | ||
Văn bản bị thay thế | Văn bản thay thế | ||
Văn bản được dẫn chiếu | Văn bản căn cứ |