Tiêu chuẩn quốc gia TCVN 11198-2:2015 về Thẻ mạch tích hợp EMV cho hệ thống thanh toán - quy trình xử lý

• Số hiệu: TCVN11198-2:2015
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2015

Tùy chọn bên triển khai	Mô tả
EMV CPS	Thẻ hỗ trợ tùy chọn bên triển khai nay có thể được cá nhân hóa bằng các phương thức cá thể hóa được mô tả tại tài liệu đặc tả cá thể hóa thẻ EMVCPS.
Dynamic-RSA	Thẻ hỗ trợ tùy chọn bên triển khai này có khả năng xác minh tính hợp lệ của DDA, CDA và mã PIN đã mã hóa ngoại tuyến.
VLP	Thẻ hỗ trợ tùy chọn bên triển khai này có khả năng xử lý một giao dịch như một Thanh toán giá trị thấp Visa.
Lựa chọn hồ sơ sử dụng dữ liệu thẻ	Thẻ hỗ trợ tùy chọn bên triển khai này có khả năng kết nối dữ liệu thẻ như Định danh ứng dụng thẻ (AID, thẻ "4F") với thông tin ứng dụng mà sẽ cho phép dữ liệu thẻ được sử dụng trong khi Khởi động Ứng dụng để cấu hình hành động ứng dụng.
Bộ đếm an ninh ứng dụng	Thẻ hỗ trợ tùy chọn bên triển khai này có thực hiện các bộ đếm an ninh bên trong ứng dụng như mô tả tại Điều 10, TCVN 11198-7. CHÚ THÍCH: Các yêu cầu an ninh được nêu tại TCVN 11198-6 áp dụng bất kể ứng dụng có hỗ trợ tùy chọn bên triển khai Bộ đếm an ninh ứng dụng hay không.

5.2  Tổng quan về chức năng

Điều này mô tả các chức năng được sử dụng trong quy trình xử lý một giao dịch CPA bởi thẻ và thiết bị đầu cuối.

• Các chức năng được gán nhãn là bắt buộc là được thực hiện đối với tất cả các giao dịch, thông qua một số bước bên trong các chức năng bắt buộc là tùy chọn;

• Các chức năng không được gán nhãn là bắt buộc là được thực hiện dựa trên các tham số của thẻ, ứng dụng và/hoặc thiết bị đầu cuối.

5.2.1  Lựa chọn ứng dụng (bắt buộc)

Điều này đề cập chức năng bổ sung tùy chọn dựa trên EMV nếu có hỗ trợ tùy chọn bên triển khai Lựa chọn hồ sơ sử dụng dữ liệu thẻ.

5.2.1.1  Mô tả chung chức năng

Đối với thiết bị đầu cuối, Lựa chọn Ứng dụng là một chức năng EMV mà không có chức năng bổ sung cho CPA. Khi một thẻ CPA thẻ kết nối với một thiết bị đầu cuối EMV, thiết bị đầu cuối xác định các ứng dụng cả thẻ và thiết bị đầu cuối.

Nếu chỉ có duy nhất một ứng dụng hỗ trợ cả hai thì ứng dụng đó không yêu cầu sự xác nhận của chủ thẻ và thiết bị đầu cuối lựa chọn ứng dụng đó.

...

...

...

Nếu không có ứng dụng nào được hiển thị, thiết bị đầu cuối lựa chọn ứng dụng phù hợp được ưu tiên cao nhất mà không đòi hỏi sự xác nhận của chủ thẻ theo thiết kế của bên phát hành trong khi cá thể hóa thẻ.

Nếu tùy chọn Lựa chọn Hồ sơ Sử dụng Dữ liệu Thẻ không được hỗ trợ thì việc lựa chọn ứng dụng thẻ là một chức năng EMV mà không có chức năng bổ sung cho CPA.

Nếu tùy chọn Lựa chọn Hồ sơ Sử dụng Dữ liệu Thẻ được hỗ trợ thì tại thời điểm việc lựa chọn ứng dụng cuối cùng, thẻ sử dụng dữ liệu thẻ như Định danh ứng dụng thẻ (AID, thẻ "4F") để xác định các tham số sẽ được sử dụng cho cuộc giao dịch trong lúc Khởi động Ứng dụng.

5.2.1.2  Điều kiện thực hiện

Thiết bị đầu cuối luôn luôn thực hiện chức năng này và hồi đáp thẻ.

5.2.2  Quy trình Bắt đầu Ứng dụng (bắt buộc)

Điều này có chức năng bổ sung dựa theo EMV.

5.2.2.1  Mô tả Chung chức năng

Khi một ứng dụng CPA được lựa chọn, thẻ có thể yêu cầu dữ liệu từ thiết bị đầu cuối. Dữ liệu được yêu cầu, các tham số được lựa chọn trong khi Lựa chọn ứng dụng (nếu hỗ trợ tùy chọn Lựa chọn Hồ sơ Sử dụng Dữ liệu Thẻ) và các tùy chọn bên phát hành được sử dụng để xác định danh sách các chức năng được hỗ trợ bởi thẻ cho cuộc giao dịch đó, và dữ liệu được đọc bởi thiết bị đầu cuối để được sử dụng trong quy trình xử lý giao dịch. Thẻ có thể bắt đầu dữ liệu khác hoặc các chức năng hỗ trợ khác tùy theo các đặc điểm cuộc giao dịch như mã quốc gia thiết bị đầu cuối.

...

...

...

Thiết bị đầu cuối luôn luôn thực hiện chức năng này và hồi đáp thẻ.

5.2.3  Đọc Dữ liệu ứng dụng (bắt buộc)

Điều này đề cập chức năng bổ sung dựa theo EMV.

5.2.3.1  Mô tả chung chức năng

Thiết bị đầu cuối đọc dữ liệu được cho biết bởi thẻ.

5.2.3.2  Điều kiện thực hiện

Thiết bị đầu cuối luôn luôn thực hiện chức năng này và hồi đáp thẻ.

5.2.4  Xác thực Dữ liệu Ngoại tuyến (tùy chọn)

Điều này đề cập chức năng bổ sung dựa theo EMV.

...

...

...

Thiết bị đầu cuối xác định khi nào nó phải xác thực thẻ ngoại tuyến bằng cách xác thực dữ liệu tỉnh ngoại tuyến hoặc xác thực dữ liệu động ngoại tuyến tùy theo thẻ và thiết bị đầu cuối có hỗ trợ các phương thức này.

Xác thực Dữ liệu Tĩnh (SDA) ngoại tuyến xác định tính hợp lệ của dữ liệu ứng dụng quan trọng mà không bị cảnh báo nào từ khi cá thể hóa thẻ.

Thiết bị đầu cuối xác minh tính hợp lệ dữ liệu tĩnh (chưa thay đổi) từ thẻ bằng Chứng nhận Khóa Công khai Bên phát hành và một chữ ký số. Khóa công khai bên phát hành được lưu trên thẻ như là chứng nhận khóa công khai.

Chữ ký số được tạo ra bởi quy trình ký hàm băm của dữ liệu ứng dụng quan trọng bằng Khóa Riêng bên Phát hành.

Một phép toán của hàm băm phục hồi với một hàm băm được sinh từ dữ liệu ứng dụng thực tế lấy từ dữ liệu không bị cảnh báo.

Xác thực dữ liệu động ngoại tuyến, cũng giống như SDA, xác minh tính hợp lệ của dữ liệu thẻ không bị cảnh báo gian lận và xác minh bổ sung rằng thẻ là chính hãng. Xác thực dữ liệu động ngoại tuyến có hai dạng: DDA và CDA.

• Đối với DDA, thiết bị đầu cuối yêu cầu rằng thẻ sinh ra một mã lệnh trên dữ liệu động (cuộc giao dịch đơn nhất) từ thẻ và thiết bị đầu cuối sử dụng một Khóa Riêng ICC. Thiết bị đầu cuối xác minh rằng chữ ký động này sử dụng khóa Công khai ICC được phục hồi từ Chứng chỉ Khóa Công khai ICC đọc từ thẻ. Việc xác minh đảm bảo rằng thẻ không phải là thẻ giả mạo được tạo với dữ liệu vớt (sao chép) từ thẻ hợp pháp;

• Đối với CDA, việc sinh ra một chữ ký động được kết hợp với việc sinh ra Mã lệnh Ứng dụng của thẻ trong khi Phân tích Hành động Thẻ để đảm bảo rằng Mã lệnh ứng dụng đến từ thẻ hợp lệ;

5.2.4.2  Điều kiện thực hiện

...

...

...

5.2.5  Ràng buộc xử lý (được thực hiện bởi thiết bị đầu cuối)

Điều này không thay đổi chức năng EMV

5.2.5.1  Mô tả chung chức năng

Trong Ràng buộc Xử lý, thiết bị đầu cuối sử dụng dữ liệu được đọc từ thẻ để xác định nêu giao dịch được cho phép đối với thẻ đó. Thiết bị đầu cuối kiểm tra khi nào ngày hiệu lực đối với thẻ sẽ đến, khi nào thẻ hết hạn, khi nào phiên bản ứng dụng trên thẻ và thiết bị đầu cuối phù hợp, và khi nào bất kỳ hẹn chế Kiểm soát Sử dụng Ứng dụng (AUC) có ảnh hưởng. Bên phát hành có thể sử dụng Kiểm soát Sử dụng Ứng dụng để ràng buộc việc sử dụng thẻ cho nội địa, quốc tế, ATM, tiền mặt, hàng hóa, dịch vụ hoặc hoàn tiền.

5.2.5.2  Điều kiện thực hiện

Thiết bị đầu cuối luôn luôn thực thi chức năng này.

5.2.6  Xác minh chủ thẻ (bắt buộc)

Điều này đề cập chức năng bổ sung so với EMV.

5.2.6.1  Mô tả chung chức năng

...

...

...

5.2.6.2  Điều kiện thực hiện

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 rằng ứng dụng hỗ trợ ít nhất một phương thức xác minh chủ thẻ. Thiết bị đầu cuối phải sử dụng dữ liệu liên quan đến việc xác minh chủ thẻ có trong ICC để xác định các phương thức xác minh chủ thẻ CVM đã được quy định bởi bên phát hành phải được thực hiện.

5.2.7  Quản lý Rủi ro Thiết bị đầu cuối (được thực hiện bởi thiết bị đầu cuối)

Điều này Không thay đổi chức năng của EMV.

5.2.7.1  Mô tả chung chức năng

Việc Quản lý Rủi ro Thiết bị đầu cuối kiểm tra khi nào lượng giao dịch vượt quá hạn mức sàn thiết bị giao dịch, số lượng tài khoản có trong một tệp tin ngoại lệ thiết bị đầu cuối tùy chọn, hoặc bên bán hàng bắt buộc giao dịch trực tuyến.

Một số giao dịch phải được lựa chọn ngẫu nhiên trong quy trình xử lý trực tuyến.

5.2.7.2  Điều kiện thực hiện

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 việc Quản lý Rủi ro Thiết bị đầu cuối phải được thực hiện.

...

...

...

5.2.8  Phân tích hành động Thiết bị đầu cuối (được thực hiện bởi thiết bị đầu cuối)

Điều này không thay đổi chức năng của EMV.

5.2.8.1  Mô tả chung chức năng

Việc Phân tích Hành động Thiết bị đầu cuối sử dụng kết quả của việc Xác thực Dữ liệu Ngoại tuyến, Ràng buộc Xử lý, Quản lý Rủi ro Thiết bị đầu cuối và Xác minh Chủ thẻ, cộng thêm các quy tắc được thiết lập trong thẻ và thiết bị đầu cuối để xác định khi nào cuộc giao dịch phải diễn ra ngoại tuyến, gửi trực tuyến để xác thực, hoặc bị từ chối ngoại tuyến.

Các quy tắc thẻ được thiết lập trong các trường được gọi là các Mã Hành động bên Phát hành (IAC) được đọc bởi thiết bị đầu cuối; tập quy tắc thiết bị đầu cuối có trong các Mã Hành động Thiết bị đầu cuối (TAC).

Sau khi xác định khi nào cuộc giao dịch phải thực hiện ngoại tuyến, gửi trực tuyến để xác thực, hoặc bị từ chối ngoại tuyến; thiết bị đầu cuối yêu cầu một mã lệnh ứng dụng từ thẻ.

Kiểu mã lệnh ứng dụng là một trong các kiểu sau: Chức nhận giao dịch (TC) để thực hiện ngoại tuyến, Mã lệnh Yêu cầu Xác thực (ARQC) để yêu cầu trực tuyến, mã lệnh Xác thực Ứng dụng (AAC) để từ chối ngoại tuyến.

5.2.8.2  Điều kiện thực hiện

Thiết bị đầu cuối luôn luôn thực hiện chức năng này.

...

...

...

Điều này đề cập chức năng bổ sung so với EMV.

5.2.9.1  Mô tả chung chức năng

Tùy theo việc nhận mã lệnh GENERATE AC đầu tiên từ thiết bị đầu cuối, thẻ thực hiện việc Phân tích Hành động Thẻ khi việc Quản lý Rủi ro Thẻ kiểm tra đã xác định khi nào thay đổi việc chuyển nhượng giao dịch được yêu cầu bởi thiết bị đầu cuối.

Điều này có thể bao gồm việc kiểm tra số lượng và tốc độ hạn mức kiểm tra đang có, các cuộc giao dịch trực tuyến ưu tiên chưa hoàn thành, và các lỗi của việc Xác thực bên Phát hành hoặc xác thực dữ liệu ngoại tuyến trong cuộc giao dịch trước đấy.

Thẻ có thể chuyển đổi một yêu cầu thiết bị đầu cuối để chấp thuận ngoại tuyến thành một giao dịch trực tuyến hoặc một từ chối ngoại tuyến, và thẻ có thể chuyển đổi một yêu cầu trực tuyến thành từ chối ngoại tuyến. Thẻ phải từ chối một giao dịch nếu thiết bị đầu cuối quyết định là từ chối giao dịch đó.

Sau khi hoàn thành các kiểm tra, thẻ sinh ra mã lệnh ứng dụng bằng dữ liệu ứng dụng và một khóa bí mật được lưu trên thẻ. Nó trả về mã lệnh này đến thiết bị đầu cuối.

Đối với các giao dịch được chấp thuận ngoại tuyến, kiểu mã lệnh là TC. Đối với các giao dịch bị từ chối ngoại tuyến, kiểu mã lệnh là AAC. Đối với các giao dịch gửi trực tuyến, kiểu mã lệnh là ARQC.

5.2.9.2  Điều kiện thực hiện

Ứng dụng luôn luôn thực hiện chức năng này.

...

...

...

Điều này không thay đổi chức năng EMV.

5.2.10.1  Mô tả chung chức năng

Nếu thiết bị đầu cuối có khả năng trực tuyến và thẻ xác định rằng cuộc giao dịch yêu cầu một chuẩn chi trực tuyến, sau đó thiết bị đầu cuối gửi đi một thông điệp yêu cầu chuẩn chi trực tuyến đến bên phát hành. Thông điệp này bao gồm mã lệnh ARQC, dữ liệu được sử dụng để sinh ra ARQC, và các chỉ báo cho biết kết quả xử lý ngoại tuyến.

Trong quy trình xử lý trực tuyến, bên phát hành xác minh tính hợp lệ của ARQC để xác thực thẻ trong một quy trình được gọi là Xác thực Thẻ trực tuyến.

Bên phát hành có thể xem xét kết quả của việc Xác thực Thẻ Trực tuyến và các kết quả xử lý ngoại tuyến trong các quyết định chuẩn chi.

Thông điệp hồi đáp chuẩn chi được gửi trả lại thiết bị đầu cuối có thể bao gồm Dữ liệu Xác thực Bên Phát hành.

Dữ liệu Xác thực bên Phát hành có chứa một mã Lệnh Hồi đáp Chuẩn chi được sinh ra bởi bên phát hành (ARPC) (được sinh ra từ ARQC, Cập nhật Tình trạng Thẻ, và khóa bí mật của thẻ) và Cập nhật Tình trạng Thẻ. Hồi đáp có thể bao gồm các cập nhật sau phát hành đối với thẻ được gọi là các lệnh trong Tập lệnh bên Phát hành.

CHÚ THÍCH 1: Dữ liệu Xác thực bên Phát hành có thể bao gồm Dữ liệu Xác thực Độc quyền. Hỗ trợ cho bên nhận Dữ liệu Xác thực Độc quyền và chức năng gắn cùng với dữ liệu bổ sung được phép như chức năng bổ sung (xem Điều 19.3.5).

CHÚ THÍCH 2: Xác thực bên Phát hành trong CPA là được thực hiện như một phần của lệnh GENERATE AC thứ hai đang xử lý thay thế sử dụng lệnh EXTERNAL AUTHENTICATE.

...

...

...

Thiết bị thực hiện chức năng này nếu ứng dụng gửi một ARQC trong hồi đáp đến lệnh GENERATE AC đầu tiên đối với giao dịch.

5.2.11  Phân tích hành động thẻ lần hai (điều kiện - nếu kiểu AC đầu tiên là ARQC)

Điều này đề cập chức năng bổ sung so với EMV.

5.2.11.1  Mô tả chung chức năng

Trong khi nhận được mã GENERATE AC thứ hai từ thiết bị đầu cuối, thẻ thực hiện Phân tích Hành động Thẻ lần hai.

Cuộc giao dịch được chấp thuận bởi bên phát hành có thể chuyển đổi thành từ chối dựa theo kết quả Xác thực bên Phát hành và các tùy chọn bên phát hành trên thẻ.

Nếu cuộc giao dịch không thể tiến hành trực tuyến, việc Quản lý Rủi ro Thẻ bổ sung kiểm tra được thực hiện để xác định khi nào thay đổi việc chuyển nhượng giao dịch được gửi bởi thiết bị đầu cuối.

Việc này bao gồm các kiểm tra số lượng và hạn mức tốc độ kiểm tra đang có, các giao dịch trực tuyến ưu tiên chưa hoàn thành, các lần Xác thực bên Phát hành lỗi hoặc xác thực dữ liệu ngoại tuyến bị lỗi trong lần giao dịch trước.

Nếu hồi đáp chuẩn chi có chứa một ARPC, ứng dụng thực hiện việc Xác thực bên Phát hành bằng cách xác minh tính hợp lệ của ARPC để xác minh rằng hồi đáp đến từ bên phát hành (hoặc đại diện) chính hãng.

...

...

...

Việc xác thực bên Phát hành được yêu cầu để ứng dụng thực hiện quy trình xử lý Cập nhật Tình trạng Thẻ.

Yêu cầu Xác thực bên Phát hành ngăn chặn việc tránh né các tính năng an ninh của thẻ bằng cách mô phỏng quy trình xử lý trực tuyến và làm giả sự chấp thuận giao dịch để thiết lập lại bộ đếm và các chỉ báo của thẻ. Nếu hồi đáp chuẩn chi không có chứa ARP, thẻ sử dụng các quy tắc bố trí giao dịch và quy tắc đã mã hóa bởi bên phát hành để xác minh khi nào cần cập nhật bộ đếm và các chỉ báo có trên thẻ. Thẻ sinh ra một TC cho các giao dịch đã được chấp nhận hoặc một AAC cho các giao dịch bị từ chối. Sau khi hoàn thành các kiểm tra, thẻ sinh ra mã lệnh ứng dụng bằng dữ liệu ứng dụng và một khóa bí mật đã lưu trên thẻ. Việc này trả về một mã lệnh đến thiết bị đầu cuối.

5.2.11.2  Điều kiện thực hiện

Ứng dụng thực hiện chức năng này nếu ICC trả về một ARQC trong hồi đáp cho lệnh GENERATE AC đầu tiên đối với giao dịch.

5.2.12  Quy trình xử lý Lệnh trong Tập lệnh bên Phát hành (tùy chọn)

Điều này đề cập về chức năng bổ sung so với EMV.

5.2.12.1  Mô tả chung chức năng

Nếu bên phát hành bao gồm một tập lệnh trong thông điệp hồi đáp chuẩn chi, thiết bị đầu cuối chuyển qua các lệnh trong Tập lệnh đến thẻ. Trước khi áp dụng bản cập nhật, thẻ thực hiện việc kiểm tra an ninh để đảm bảo rằng tập lệnh đến từ bên phát hành hợp lệ và không bị cảnh báo trong khi truyền. Các lệnh trong Tập lệnh được hỗ trợ cho phép cập nhật các tham số quy trình xử lý ngoại tuyến, mở khóa ứng dụng và thay đổi giá trị mã PIN ngoại tuyến.

5.2.12.2  Điều kiện thực hiện

...

...

...

5.3  Luồng giao dịch mẫu

Luồng giao dịch mẫu thể hiện trong Hình 3 minh họa một luồng có thể có cho một giao dịch CPA tại thiết bị tương thích EMV. Chú ý rằng luồng các quy trình này là chủ yếu được điều lái bởi thiết bị đầu cuối, không có ứng dụng nào trên ICC.

Sự trao đổi giữa ICC và thiết bị đầu cuối thông qua các lệnh gửi từ thiết bị đầu cuối đến ICC và ICC gửi các hồi đáp tới thiết bị đầu cuối.

Hình 1 - Luồng giao dịch mẫu

5.4  Chức năng tối thiểu

Điều này chỉ ra các chức năng tối thiểu cần có cho ứng dụng. Các yêu cầu đối với thiết bị đầu cuối được quy định trong EMV.

5.4.1  Yêu cầu Chức năng Thẻ

Req 2.5.1 (Chức năng bắt buộc):

...

...

...

CHÚ THÍCH: Sử dụng các chức năng được hỗ trợ có thẻ là một tùy chọn bên phát hành. Bảng 2 chỉ ra chức năng mà phải được hỗ trợ bởi bên triển khai sao cho chức năng phải hiện hữu để sử dụng bởi bên phát hành trong tất cả các triển khai CPA.

Req 2.5.2 (Chức năng điều kiện):

Các thẻ CPA phải hỗ trợ các chức năng điều kiện được liệt kê trong Bảng 2 nếu các điều kiện có liên quan là đúng.

CHÚ THÍCH: Sử dụng các chức năng được hỗ trợ có thể là một tùy chọn bên phát hành. Bảng 2 chỉ ra chức năng mà phải được hỗ trợ bởi bên triển khai nếu điều kiện là đúng, sao cho chức năng phải hiện hữu để sử dụng bởi bên phát hành trong tất cả các triển khai CPA trong khi các điều kiện là đúng.

Bảng 2 - Các yêu cầu chức năng thẻ

Chức năng

Hỗ trợ thẻ

Lựa chọn ứng dụng

bắt buộc

...

...

...

bắt buộc

• Lựa chọn một phần AID

bắt buộc

• Phương thức lựa chọn rõ ràng

bắt buộc

Bắt đầu quy trình xử lý ứng dụng

bắt buộc

Đọc dữ liệu ứng dụng

bắt buộc

...

...

...

• SDA

Yêu cầu cá thể hóa - Thẻ phải có khả năng cá thể hóa với dữ liệu cần thiết để thiết bị đầu cuối thực hiện SDA.

• DDA

Điều kiện - Nếu tùy chọn bên triển khai RSA động được hỗ trợ.

• CDA

Điều kiện - Nếu tùy chọn bên triển khai RSA động được hỗ trợ.

Xác minh chủ thẻ

bắt buộc

...

...

...

bắt buộc

• mã PIN bản mã ngoại tuyến

điều kiện - Nếu tùy chọn bên triển khai RSA động được hỗ trợ

Phân tích hành động thẻ lần đầu

bắt buộc

• ra quyết định trực tuyến/ngoại tuyến

bắt buộc

• quản lý rủi ro thẻ

bắt buộc

...

...

...

bắt buộc, thuật toán được quy định bởi CCD

đối với Phiên bản Mã lệnh ‘5’

• lịch sử giao dịch

bắt buộc

Phân tích hành động thẻ lần hai

bắt buộc

• xác thực bên phát hành

bắt buộc

...

...

...

bắt buộc

• lịch sử giao dịch

bắt buộc

Quy trình xử lý tập lệnh bên phát hành đến thẻ

bắt buộc

• Gửi thông điệp bảo mật

bắt buộc, định dạng được quy định trong CCD

5.4.2  Yêu cầu Hỗ trợ Lệnh

Req 2.5.3 (Các lệnh được hỗ trợ):

...

...

...

Bảng 3 - Các yêu cầu Hỗ trợ Lệnh

Lệnh

CLA

INS

Hỗ trợ thẻ

APPLICATION UNBLOCK

'8C'

'18'

bắt buộc

...

...

...

'80'

'AE'

bắt buộc

GET CHALLENGE

’00‘

'84’

điều kiện - Nếu tùy chọn bên triển khai RSA động được hỗ trợ

GET DATA

'80'

...

...

...

bắt buộc

GET PROCESSING OPTIONS

'80'

'A8'

bắt buộc

INTERNAL AUTHENTICATE

'00'

'88'

điều kiện - Nếu tùy chọn bên triển khai RSA động được hỗ trợ

...

...

...

'8C'

'24'

bắt buộc

PUT DATA

'0C'

'DA'

bắt buộc

READ RECORD

'00'

...

...

...

bắt buộc

SELECT

'00'

'A4'

bắt buộc

UPDATE RECORD

'0C'

'DC'

bắt buộc

...

...

...

'00'

'20'

bắt buộc

6  Thông tin chung về Lệnh

6.1  Việc thực thi tài liệu đặc tả CPA

Mục đích của bộ tiêu chuẩn TCVN 11198 là để định nghĩa rõ ràng hành vi của ứng dụng CPA với bên ngoài. Theo đó quy định rõ ràng hành vi với bên ngoài này để trợ giúp cho việc quy định một số quy trình xử lý nội bộ và mô tả một số phần tử dữ liệu nội bộ (ví dụ: các cờ nội bộ, các bit trong Lịch sử Giao dịch Trước đó) và chỉ ra phương thức có khả năng để thực thi hành vi được yêu cầu với bên ngoài.

Ví dụ, có rất nhiều luồng gồm các chuỗi hành động trong khi thực hiện quy trình xử lý lệnh mà không tạo ra bất kỳ khác biệt nào với hành vi với bên ngoài. Tuy nhiên việc này là cần thiết để mô tả luồng quy trình xử lý nội bộ và dữ liệu nội bộ để mà thể hiện rõ ràng các khái niệm ứng dụng.

Việc triển khai không cần thực thi chức năng nội bộ sử dụng các phần tử dữ liệu và các quy trình nghiêm ngặt như đã định nghĩa trong bộ TCVN 11198. Tuy nhiên, việc triển khai được yêu cầu phải thực hiện theo một cách không phân biệt (bên ngoài ứng dụng) với hành vi mà đã được mô tả sử dụng các phần tử dữ liệu nội bộ và quy trình nội bộ. CPA là một thực thi tương thích CCD của EMV.

Req 2.6.1 (Thực thi CCD)

...

...

...

CHÚ THÍCH: Tuân thủ CCD là phụ thuộc vào việc cá thể hóa các thông số mà cấu hình hành vi ứng dụng. Xem Điều 7, TCVN 11198-6 đối với các yêu cầu cá thể hóa để tương thích với CCD.

Việc thực thi không yêu cầu nghiêm ngặt về các biểu đồ luồng mô tả hành vi ứng dụng. Tuy nhiên, việc thực thi được yêu cầu thực hiện theo cách không phân biệt (xem như là hộp đen hồi đáp lệnh) với hành vi được mô tả bởi các biểu đồ luồng. Có hay không thực hiện nội bộ theo các biểu đồ luồng không phải là một điều kiện để phù hợp với bộ TCVN 11198.

Req 2.6.2 (hành vi theo các biểu đồ luồng):

Các thực thi phải thực hiện nếu như chúng theo các biểu đồ luồng.

Trong các điều mô tả quy trình xử lý lệnh, các chú thích thực thi chỉ ra tại nơi các thực thi khác nhau phải theo các hành vi giống nhau. Danh sách này không đầy đủ và các bên triển khai hoan nghênh việc sử dụng bất kỳ tính năng nào theo nền tảng hoặc tối ưu hóa mà sẽ tạo thuận lợi cho việc thực thi trong khi vẫn giữ cho hành vi thẻ với bên ngoài là không thay đổi.

6.2  Bộ máy trạng thái

Ứng dụng hoạt động bởi nhận được một lệnh từ một thiết bị đầu cuối EMV, xử lý nó, sau đó sinh ra và gửi đi một hồi đáp đến thiết bị đầu cuối. Sau việc này, ứng dụng đã sẵn sàng quy trình xử lý lệnh mới. Trong tiêu chuẩn này, ứng dụng được mô tả như một bộ máy trạng thái. Bởi vì ứng dụng khi nhận và xử lý một lệnh, trạng thái của ứng dụng có thể thay đổi trước khi ứng dụng chấp nhận lệnh tiếp theo từ thiết bị đầu cuối. Quy trình xử lý các lệnh dẫn dắt thực hiện giao dịch bên trong bộ máy trạng thái.

6.2.1  Các trạng thái

Sau khi ứng dụng có thể cá thể hóa, hành vi có thể được quy định như một máy trạng thái. Bảng 4 cung cấp các trạng thái của ứng dụng được sử dụng trong mô tả của CPA.

...

...

...

Trạng thái

Mô tả

SELECTED

Ứng dụng được chọn

INITIATED

Giao dịch được bắt đầu

ONLINE

Ứng dụng chờ đợi một kết nối với bên phát hành.

Việc này cũng sẵn sàng để chấp nhận một lệnh trong Tập lệnh

...

...

...

Ứng dụng sẵn sàng chấp nhận một lệnh trong Tập lệnh

SELECTED

Mọi giao dịch bắt đầu với trạng thái SELECTED. Ứng dụng chuyển sang trạng thái SELECTED dựa theo việc nhận lệnh SELECT tức là thẻ hoặc thiết bị đầu cuối đã lựa chọn sử dụng ứng dụng để xử lý giao dịch. Khi thẻ ở trong trạng thái SELECTED:

• Nếu ứng dụng đã bị quá số lượng giao dịch tối đa được phép trên vòng đời của thẻ (xem Điều 5, TCVN 11198-3), thì thẻ sẽ được hồi đáp lệnh GET PROCESSING OPTIONS với một thông báo lỗi rằng cho phép thiết bị đầu cuối trả về việc lựa chọn ứng dụng để lựa chọn một ứng dụng khác (nếu có). Các chuyển đổi trạng thái đối với các lệnh khác như chỉ dẫn trong Bảng 5.

• Nếu ứng dụng bị khóa, thì thẻ hồi đáp các SW1 SW2 = '6285' (tệp tin được chọn trong trạng thái thiết bị đầu cuối) trong hồi đáp lệnh SELECT và ứng dụng hoặc không thêm vào hoặc bị loại ra khỏi danh sách ứng cử; phụ thuộc vào khi nào lệnh SELECT xuất hiện.

• Nếu ứng dụng bị khóa, thì các chuyển đổi trạng thái như chỉ dẫn trong Bảng 5. Việc này cho phép lựa chọn một ứng dụng đã bị khóa sao cho một lệnh trong Tập lệnh có thể mở khóa ứng dụng. Chức năng này được thực hiện tại các thiết bị đặc biệt, và không nằm trong luồng giao dịch EMV.

INITIATED

Ứng dụng CPA chuyển sang trạng thái INITIATED sau khi xử lý lệnh GET PROCESSING OPTIONS. Trong trạng thái này, một giao dịch mới được khởi động. Quy trình xử lý các lệnh GET DATA và READ RECORD không làm cho ứng dụng với giao dịch chuyển sang trạng thái mới. Quy trình xử lý lệnh GENTERATE AC đầu tiên làm cho ứng dụng thực hiện giao dịch hoặc chuyển sang ONLINE hoặc SCRIPT.

CHÚ THÍCH: Khi thẻ ở trong trạng thái INITIATED, ONLINE hoặc SCRIPT và ứng dụng bị khóa, thì các chuyển đổi trạng thái như chỉ dẫn tại Bảng 5. Ứng dụng sẽ hồi đáp lệnh GENERATE AC đầu tiên một AAC, như mô tả trong chương Phân tích Hành động Thẻ đầu tiên.

...

...

...

CPA chuyển sang trạng thái ONLINE sau khi xử lý lệnh GENERATE AC đầu tiên nếu hồi đáp là một ARQC. Trong trạng thái này, ứng dụng chờ đợi một hồi đáp từ bên phát hành. Ứng dụng chấp nhận các lệnh trong Tập lệnh trong trạng thái này. Ứng dụng cũng chấp nhận lệnh GENERATE AC thứ hai, tại đó có thể chứa một hồi đáp từ bên phát hành. Quy trình xử lý lệnh GENERATE AC thứ hai làm cho ứng dụng thực hiện giao dịch chuyển sang trạng thái SCRIPT.

SCRIPT

CPA chuyển sang trạng thái SCRIPT sau khi hồi đáp một TC hoặc một AAC đối với lệnh GENERATE AC, để nhận và xử lý bất kỳ lệnh trong Tập lệnh nào (Xem Bảng 5 đối với các chuyển đổi trạng thái).

6.2.2  Chuỗi các lệnh và chuyển dịch giữa các trạng thái

Trong Bảng 5, tiêu đề cột mô tả trạng thái hiện thời của ứng dụng khi đã nhận một lệnh từ thiết bị đầu cuối. Tiêu đề dòng mô tả lệnh đã nhận.

Bảng 5 mô tả chuyển dịch giữa các trạng thái mà ứng dụng phải thực hiện dựa trên các thực hiện thành công các lệnh CPA (với SW1 SW2 = '9000' trong hồi đáp lệnh, hoặc chỉ cho lệnh VERIFY, SW1 SW2 = '63Cx'). Từng nội dung bảng cho biết trạng thái cuối khi thực hiện lệnh thành công.

Điều kiện có trong một hồi đáp lỗi đến thiết bị đầu cuối như mô tả trong các điều xử lý lệnh tại Phần III của tiêu chuẩn này. Nếu có một lỗi xuất hiện trong quy trình xử lý lệnh cho GENERATE AC hoặc GET PROCESSING OPTIONS, trong trạng thái mà các lệnh được cho phép, ứng dụng thực hiện giao dịch phải chuyển sang trạng thái SELECTED.

Đối với lỗi trong quy trình xử lý bất kỳ lệnh nào khác, ứng dụng phải giữ lại trạng thái hiện thời.

Bảng 5 - Chuỗi các lệnh và các chuyển đổi trạng thái đối với các lệnh

...

...

...

Lệnh ß

SELECTED

INITIATED

ONLINE

SCRIPT

APPLICATION

UNBLOCK

Không được phép

Không được phép

...

...

...

SCRIPT

GENERATE AC

Không được phép

SCRIPT (nếu hồi đáp là TC hoặc AAC và

SW1 SW2 = '9000')

ONLINE (nếu hồi đáp là ARQC và

SW1 SW2 = '9000')

SELECTED

(nếu SW1 SW2≠ '9000')

...

...

...

(if SW1 SW2

= '9000')

SELECTED

(if SW1 SW2 ≠ '9000')

Không được phép1

GET CHALLENGE

SELECTED

INITIATED

ONLINE

...

...

...

GET DATA

SELECTED

INITIATED

ONLINE

SCRIPT

GET PROCESSING OPTIONS

INITIATED

(nếu SW1 SW2 = '9000')

SELECTED

...

...

...

Không được phép

Không được phép

Không được phép

INTERNAL AUTHENTICATE

Không hỗ trợ

INITIATED

Không hỗ trợ

Không hỗ trợ

PIN CHANGE/ UNBLOCK

...

...

...

Không được phép

ONLINE

SCRIPT

PUT DATA

Không được phép

Không được phép

ONLINE

SCRIPT

READ RECORD

...

...

...

INITIATED

ONLINE

SCRIPT

SELECT

SELECTED

SELECTED

SELECTED

SELECTED

UPDATE RECORD

...

...

...

Không được phép

ONLINE

SCRIPT

VERIFY

Không hỗ trợ

INITIATED

Không hỗ trợ

Không hỗ trợ

6.3  Xác minh lệnh

...

...

...

Req 2.5.3 (Xác minh lệnh):

Nếu ứng dụng nhận được một lệnh không rõ, nó phải chấm dứt quy trình xử lý lệnh và phải hồi đáp một SW1 SW2 chỉ ra lỗi.

• nếu CLA là không rõ, thẻ phải hồi đáp với SW1 SW2 = '6E00' (CLA không được hỗ trợ).

• nếu CM là đã biết rõ, nhưng INS là chưa rõ đối với CLA, thẻ phải hồi đáp với SW1 SW2 = '6D00' (Sai INS).

• nếu cả hai CLA và INS là không rõ, thẻ phải hồi đáp với SW1 SW2 = hoặc '6E00' hoặc '6D00'.

6.4  Xử lý ngoại lệ

6.4.1  Các từ khóa trạng thái

Bổ sung cho phần Xác minh Lệnh được quy định trong Điều 6.3, từng điều quy trình xử lý lệnh có thể nhận diện ra các từ khóa trạng thái được khuyến nghị và bắt buộc trong tương lai.

Việc triển khai ứng dụng có thể hồi đáp với các từ khóa trạng thái khác với các điều kiện đã có ngoài những quy định trong CPA. Ví dụ, ứng dụng có thể hồi đáp với các từ khóa trạng thái quy định việc thực thi khi dữ liệu được yêu cầu cho việc thực hiện một chức năng không hiện có (tức là không được cá thể hóa) hoặc khi dữ liệu bị lỗi. Các từ khóa trạng thái bổ sung này là dành cho việc triển khai.

...

...

...

6.4.2  Tài nguyên thiếu hoặc không hợp lệ

Trong suốt quá trình ứng dụng, một tài nguyên ứng dụng có thể bị thiếu hoặc không hợp lệ (ví dụ, tài nguyên tham chiếu bởi số ID tài nguyên là một trong những đối tượng dữ liệu nội bộ thẻ có thể bị thiếu hoặc mã hóa không chính xác). Trong trường hợp như vậy, hành động có thể thực hiện phụ thuộc vào kiểu tài nguyên bị thiếu hoặc không hợp lệ. Trong TCVN 11198-6, Điều 7 có chỉ ra hành động thích hợp để thực hiện nếu tài nguyên bị thiếu hoặc không hợp lệ.

Vì lợi ích rõ ràng, các sơ đồ luồng trong các phần thuộc bộ TCVN 11198 không có chứa quy trình xử lý lỗi đối với tất cả các kiểu thiếu tài nguyên. Chỉ các trường hợp khi quy trình xử lý lệnh phải chấm dứt (và trạng thái lỗi trả về thiết bị đầu cuối) hoặc các trường hợp mà giá trị mặc định phải được sử dụng, là được minh họa.

THƯ MỤC TÀI LIỆU THAM KHẢO

[1] 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;

[2] 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;

[3] EMV CPS, EMV Card Personalization Specification, version 1.0, June 2003;

...

...

...

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  Tổng quan

5.1  Tùy chọn bên triển khai

5.2  Tổng quan về chức năng

5.2.1  Lựa chọn Ứng dụng (bắt buộc)

...

...

...

5.2.3  Đọc Dữ liệu Ứng dụng (bắt buộc)

5.2.4  Xác thực Dữ liệu Ngoại tuyến (tùy chọn)

5.2.5  Ràng buộc xử lý (được thực hiện bởi thiết bị đầu cuối)

5.2.6  Xác minh chủ thẻ (bắt buộc)

5.2.7  Quản lý Rủi ro Thiết bị đầu cuối (được thực hiện bởi thiết bị đầu cuối)

5.2.8  Phân tích hành động Thiết bị đầu cuối (được thực hiện bởi thiết bị đầu cuối)

5.2.9  Phân tích hành động thẻ lần đầu (bắt buộc)

5.2.10  Quy trình xử lý trực tuyến (điều kiện - nếu kiểu AC đầu tiên là ARQC)

5.2.11. Phân tích hành động thẻ lần hai (điều kiện - nếu kiểu AC đầu tiên là ARQC)

...

...

...

5.3  Luồng giao dịch mẫu

5.4  Chức năng tối thiểu

5.4.1  Yêu cầu Chức năng Thẻ

5.4.2  Yêu cầu Hỗ trợ Lệnh

6  Thông tin chung về Lệnh

6.1  Việc thực thi tài liệu đặc tả CPA

6.2  Bộ máy trạng thái

6.2.1  Các trạng thái

6.2.2  Chuỗi các lệnh và chuyển dịch giữa các trạng thái

...

...

...

6.4  Xử lý ngoại lệ

6.4.1  Các từ khóa trạng thái

6.4.2  Tài nguyên thiếu hoặc không hợp lệ

Thư mục tài liệu tham khảo

1 EMV yêu cầu rằng thẻ hồi đáp SW1 SW2 = '6985' cho chuỗi con hoặc một lệnh GENERATE AC thứ ba đã nhận bởi thẻ trong một giao dịch đơn.