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

Ứ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

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

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

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ẻ

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

Bảng 7 - Mã hóa Tham số Kiểm soát Tham chiếu cho lệnh READ RECORD

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ơ

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ẻ

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

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

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ẻ

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

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ẻ

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.

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

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

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

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 N_ic, 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 N_PE, 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.