TCVN 11198-5:2015
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (854.24 KB, 34 trang )
TIÊU CHUẨN QUỐC GIA
TCVN 11198-5: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 5: QUY TRÌNH XỬ LÝ TẬP LỆNH BÊN PHÁT HÀNH ĐẾN THẺ
EMV integrated circuit card for payment systems - Common payment application specification - Part 5:
lssuer-to-card script processing
Lời nói đầu
TCVN 11198-5: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-5: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 5: QUY TRÌNH XỬ LÝ TẬP LỆNH BÊN PHÁT HÀNH ĐẾN THẺ
EMV integrated Circuit Card for Payment Systems - Common payment application specification
- Part 5: lssuer-to-Card Script Processing
1 Phạm vi áp dụng
Tiêu chuẩn TCVN 11198-5 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ý tập lệnh bên phát hành đến thẻ.
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 Quy trình xử lý lệnh tập lệnh bên phát hành
5.1 Mục đích
Quy trình xử lý Tập lệnh bên Phát hành đến Thẻ cho phép bên phát hành chỉnh sửa các tham số thẻ
trên các thẻ (như là dữ liệu cá nhân) mà không cần phát hành lại thẻ. Với chức năng này, bên phát
hành truyền các lệnh trong tập lệnh bên phát hành có chứa trong thông điệp hồi đáp chuẩn chi. Thiết bị
đầu cuối cho qua các lệnh này đến thẻ, tại đó chúng được thực thi nếu các yêu cầu gửi bảo mật là hợp
lệ.
Quy trình xử lý tập lệnh bên Phát hành đến thẻ được thực hiện như mô tả ở EMV Quyển 3, Điều 6 và
Điều 10.10 và EMV Quyển 4, Điều 6.3.9. Việc gửi thông điệp bí mật được thực hiện như Điều 9 thuộc
phần CCD của EMV Quyển 2.
5.2 Trình tự thực hiện
5.2.1 Quy trình xử lý có liên quan trước đó
Hồi đáp trực tuyến nhận được bởi thiết bị đầu cuối từ bên thu mua có thể chứa một tập lệnh bên phát
hành để được xử lý trong Quy trình xử lý Tập lệnh bên Phát hành đến thẻ.
Quy trình xử lý trực tuyến
Các lệnh tập lệnh được gửi đến thẻ trước lệnh GENERATE AC lần hai nếu bản mẫu tập lệnh nhận
được bởi thiết bị đầu cuối có thẻ tag '71'.
Phân tích Hành động Thẻ lần hai
Các lệnh tập lệnh được gửi đến thẻ sau lệnh GENERATE AC lần hai nếu bản mẫu tập lệnh nhận được
bởi thiết bị đầu cuối có thẻ tag '72'.
5.2.2 Quy trình xử lý có liên quan tiếp theo
Phân tích Hành động thẻ Lần hai (giao dịch hiện thời)
Nếu một lệnh tập lệnh đã nhận trước lệnh GENERATE AC lần hai, thì trong khi Phân tích Hành động
thẻ lần hai:
• Thẻ thiết lập bit 'Số lượng các lệnh tập lệnh bên phát hành chứa trong thông điệp bí mật đã xử lý'
trong Kết quả Xác minh Thẻ (CVR);
• Nếu Quy trình xử lý tập lệnh bên Phát hành đến thẻ bị lỗi, thì thẻ thiết lập bit 'Quy trình xử lý tập lệnh
bên phát hành bị lỗi' trong CVR.
Phân tích Hành động thẻ (giao dịch tiếp theo)
Trong khi Phân tích Hành động thẻ cho thẻ ở giao dịch tiếp theo:
• Thẻ thiết lập bit 'Số lượng các lệnh tập lệnh bên phát hành chứa trong thông điệp bí mật đã xử lý"
trong CVR;
• Thẻ thiết lập bit 'tập lệnh đã nhận’ trong ADR là cho phép ứng dụng thực hiện trực tuyến bởi vì thẻ đã
nhận một lệnh tập lệnh trong giao dịch trước đó;
• Nếu Quy trình xử lý tập lệnh bên Phát hành đến thẻ bị lỗi, thì thẻ:
- thiết lập bit 'Quy trình xử lý tập lệnh bên phát hành bị lỗi' trong ADR cho phép ứng dụng thực hiện
trực tuyến hoặc từ chối ngoại tuyến bởi vì quy trình xử lý tập lệnh bị lỗi trong giao dịch trước đó;
- và thiết lập bit 'Quy trình xử lý tập lệnh bên phát hành bị lỗi' trong CVR để chỉ thị cho bên phát hành
rằng quy trình xử lý tập lệnh bị lỗi trong giao dịch trước đó.
Phân tích Hành động thẻ lần hai (giao dịch tiếp theo)
Chỉ báo về lỗi tập lệnh bên phát hành và tập lệnh bên phát hành đã nhận có thể được thiết lập lại sau
khi các giao dịch trực tuyến dựa trên kết quả việc 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ẻ.
5.3 Dữ liệu thẻ
Dữ liệu thẻ được sử dụng trong khi Quy trình xử lý tập lệnh bên phát hành đến thẻ được liệt kê và
được mô tả trong Bảng 1.
Đối với mô tả chi tiết cho dữ liệu này và việc sử dụng chúng, xem Điều 7 trong TCVN 11198-8.
Bảng 1 - Quy trình xử lý tập lệnh bên phát hành đến thẻ - Dữ liệu thẻ
Dữ liệu
Mô tả
Bản mẫu
Thẻ tag
-
-
-
'9F52'
-
-
-
'C7'
Kết quả Quyết định Sử dụng nội bộ cho ứng dụng chỉ ra các điều
Ứng dụng
kiện ngoại lệ có thể xảy ra trong các giao dịch
hiện thời và trước đó.
Kết quả Quyết định Ứng dụng được sử dụng
trong quy trình xử lý lệnh GENERATE AC khi
xác định khi nào giao dịch phải bị từ chối
ngoại tuyến hoặc được thực hiện trực tuyến.
Kết quả Xác minh Thẻ Trong phân tích hành động thẻ lần hai của
(CVR)
giao dịch hiện thời nếu lệnh tập lệnh bên phát
hành được nhận trước khi lệnh GENERATE
AC lần hai, hoặc trong Phân tích Hành động
thẻ lần đầu của các giao dịch tiếp theo; chức
năng Phân tích Hành động thẻ ghi đầy các
trường con CVR:
- số lượng các lệnh tập lệnh bên phát hành
có chứa thông điệp bí mật đã xử lý - thiết lập
từ giá trị trong Bộ đếm lệnh tập lệnh bên phát
hành
- quy trình xử lý tập lệnh bên phát hành bị lỗi thiết lập chỉ ra rằng quy trình xử lý một lệnh
tập lệnh bị lỗi
Bộ đếm Lệnh Tập lệnh Bộ đếm Lệnh Tập lệnh bên Phát hành được
bên Phát hành
sử dụng bởi thẻ để đếm từng lệnh có chứa
thông điệp bí mật mà đã xử lý thành công
trước hoặc sau lệnh GENERATE AC lần hai
Lịch sử Giao dịch
Trước đó (PTH)
Chứa các chỉ báo được sử dụng lưu thông tin
về các giao dịch trước đó được sử dụng trong
Quản lý Rủi ro Thẻ cho giao dịch tiếp theo.
PTH chứa ba chỉ báo có liên quan tập lệnh:
• Tập lệnh đã nhận;
• ứng dụng bị khóa;
• tập lệnh bị lỗi;
Trong giao dịch tiếp theo, các chỉ báo 'tập
lệnh đã nhận’ và 'tập lệnh bị lỗi’ có thể được
thiết lập lại trong Phân tích Hành động Thẻ
lần hai
5.4 Dữ liệu Thiết bị đầu cuối
Dữ liệu thiết bị đầu cuối được sử dụng trong khi Quy trình xử lý tập lệnh bên phát hành đến thẻ được
liệt kê và được mô tả trong Bảng 2.
Đối với mô tả chi tiết cho dữ liệu này và việc sử dụng chúng, xem Điều 7 trong TCVN 11198-8.
Bảng 2 - Quy trình xử lý tập lệnh bên phát hành đến thẻ - Dữ liệu thiết bị đầu cuối
Dữ liệu
Mô tả
Kết quả tập lệnh bên phát hành có chứa các
Kết quả tập lệnh bên
kết quả của quy trình xử lý tập lệnh và phải đi
phát hành
kèm trong khi xóa thông điệp
Kết quả Xác minh thiết TVR chứa hai chỉ báo liên quan tập lệnh:
bị đầu cuối (TVR)
• tập lệnh bên phát hành bị lỗi trước lệnh
GENERATE AC cuối cùng;
Bản mẫu
Thẻ tag
-
-
-
'95'
• tập lệnh bên phát hành bị lỗi sau lệnh
GENERATE AC cuối cùng;
TSI có chứa một cờ chỉ ra rằng Quy trình xử
Thông tin tình trạng
lý tập lệnh bên phát hành đến thẻ đã được
giao dịch (TSI)
thực hiện
-
'9B'
5.4.1 Dữ liệu Hồi đáp Chuẩn chi
Nếu quy trình xử lý tập lệnh bên phát hành đến thẻ đã diễn ra, thì bên phát hành bao gồm dữ liệu được
liệt kê và mô tả như trong Bảng 3 trong hồi đáp chuẩn chi.
Bảng 3 - Quy trình xử lý tập lệnh bên phát hành đến thẻ - Dữ liệu hồi đáp chuẩn chi
Dữ liệu
Mô tả
CPA cho phép chỉ một bản mẫu tập lệnh bên phát hành
trong lần giao dịch, nhưng mà bản mẫu tập lệnh có thể là
thẻ Tag '71' hoặc Tag ‘72’
Bản mẫu Tập lệnh bên Phát
hành
• Thẻ tag '71' chỉ ra Bản mẫu tập lệnh bên phát hành 1 và
có chứa dữ liệu bên phát hành độc quyền cho truyền tải
đến thẻ trước lệnh GENERATE AC lần hai;
• Thẻ tag '72' chỉ ra Bản mẫu tập lệnh bên phát hành 2 và
có chứa dữ liệu bên phát hành độc quyền cho truyền tải
đến thẻ sau lệnh GENERATE AC lần hai;
Định danh tập lệnh bên Phát
hành
Định danh tập lệnh bên phát hành là một số được sử dụng
bởi bên phát hành để nhận diện đơn nhất tập lệnh bên phát
hành.
Lệnh tập lệnh bên phát hành
Từng lệnh tập lệnh bên phát hành trong tập lệnh là trong
định dạng BER-TLV với thẻ tag '86'.
Thiết bị đầu cuối gửi các lệnh riêng biệt trong tập lệnh bên phát hành đến thẻ hoặc trước hoặc sau lệnh
GENERATE AC lần hai, được chỉ ra bởi thẻ Tag Bản mẫu Tập lệnh bên Phát hành.
Sau từng lệnh riêng đó, thiết bị đầu cuối phân tích tình trạng trả về của lệnh. Nếu thẻ hồi đáp cho thấy
lỗi xuất hiện, thiết bị đầu cuối phải chấm dứt quy trình xử lý tập lệnh bên phát hành.
5.5 Tổng quan
Tập lệnh bên phát hành được xử lý theo phương thức sau:
5.5.1 Thông điệp Hồi đáp Chuẩn chi
Hầu hết một bản mẫu tập lệnh bên phát hành có thể gửi đến thiết bị đầu cuối trong thông điệp hồi đáp
chuẩn chi cho thẻ tương thích CPA. Bản mẫu Tập lệnh bên Phát hành này hoặc có thẻ tag 71 hoặc 72.
• Thẻ tag '71' chỉ ra Bản mẫu tập lệnh bên phát hành 1 và có chứa dữ liệu bên phát hành độc quyền
cho truyền tải đến thẻ trước lệnh GENERATE AC lần hai;
• Thẻ tag '72' chỉ ra Bản mẫu tập lệnh bên phát hành 2 và có chứa dữ liệu bên phát hành độc quyền
cho truyền tải đến thẻ sau lệnh GENERATE AC lần hai;
Các lệnh tập lệnh bên phát hành được định nghĩa trong điều này được sử dụng để thực hiện các cập
nhật sau:
• Mở khóa ứng dụng;
• Thay đổi mã PIN ngoại tuyến;
• Mở khóa mã PIN ngoại tuyến;
• Cập nhật thông số thẻ;
Nguyên gốc của lệnh tập lệnh bên phát hành được gán vào bởi bên phát hành thẻ Nếu một thực thể
khác bên phát hành sinh ra lệnh, các yêu cầu tương tự được áp dụng.
Các khả năng Khóa Thẻ và Khóa ứng dụng sử dụng CSU được hỗ trợ bởi CPA.
5.5.2 Quy trình xử lý Tập lệnh bên phát hành đến thẻ
Tất cả các lệnh tập lệnh bên phát hành yêu cầu gửi thông điệp bí mật. Ứng dụng xem xét tất cả các
lệnh nhận được với gửi thông điệp bí mật cho lệnh tập lệnh.
Điều 5.5.4 mô tả việc thiết lập các chỉ báo liên quan đến quy trình xử lý tập lệnh bên phát hành đến thẻ
khi một lệnh tập lệnh bên phát hành được truyền đến thẻ.
5.5.3 Gửi thông điệp bí mật thẻ
Mục đích của việc gửi thông điệp bí mật là đảm bảo tính bí mật dữ liệu, tính toàn vẹn thông điệp và xác
thực bên phát hành. Tính toàn vẹn thông điệp và xác thực bên phát hành nhận được bằng sử dụng mã
MAC. Tính bí mật dữ liệu nhận được bằng cách mã hóa dữ liệu bí mật như thể một mã PIN ngoại
tuyến. CPA xác thực bên phát hành trước khi quy trình xử lý một lệnh tập lệnh bên phát hành sử dụng
gửi thông điệp bí mật. Xác thực bên Phát hành (như mô tả tại Điều 7 trong TCVN 11198-4) không
được thực hiện cho quy trình xử lý tập lệnh.
Req 5.1 (Xác thực bên phát hành không yêu cầu xử lý lệnh tập lệnh):
Thẻ phải không yêu cầu rằng việc Xác thực bên Phát hành được mô tả trong Điều 5.5.3.1 của TCVN
11198-4 được thực hiện và thông qua theo thứ tự thực hiện các lệnh tập lệnh.
Req 5.2 (Gửi thông điệp bí mật được yêu cầu trong các tập lệnh cập nhật thông tin):
Bất kỳ lệnh tập lệnh bên phát hành nào cập nhật, thiết lập lại, thay đổi hoặc sửa đổi trong bất kỳ cách
thức thông tin nào trong ứng dụng phải:
• hỗ trợ việc gửi thông điệp bí mật;
• yêu cầu rằng gửi thông điệp bí mật được thực hiện thành công.
Một khi mã MAC có lỗi xuất hiện, thẻ phải loại trừ các lệnh tập lệnh tiếp theo nhận được trong cùng
giao dịch (xem Điều 6.3 trong TCVN 11198-6). Trong các biểu đồ luồng đáp ứng đầy đủ yêu cầu này
làm việc sử dụng cờ 'tập lệnh lỗi' nhưng các việc thực thi khác vẫn được phép.
Gửi thông điệp bí mật cho các lệnh tập lệnh bên phát hành sử dụng Định dạng Gửi thông điệp Bí mật 1
như quy định cho ứng dụng tương thích CCD trong EMV Quyển 2, Điều 9.
5.5.3.1 Xác thực Thông điệp (MAC)
Xác thực thông điệp (sử dụng mã MAC) phải được sử dụng để xác thực bên phát hành là bên khởi tạo
ra lệnh tập lệnh bên phát hành và để đảm bảo rằng lệnh không bị sửa đổi sau khi được gửi bởi bên
phát hành.
MAC được sinh ra bằng cách sử dụng tất cả các mào đầu lệnh và dữ liệu lệnh. MAC được sinh ra sau
khi mã hóa bất kỳ dữ liệu bí mật nào trong lệnh. Tính toàn vẹn của lệnh, bao gồm các thành phần dữ
liệu đang chứa trong trường dữ liệu lệnh, nếu có, được đảm bảo bằng cách gửi thông điệp bí mật.
Req 5.3 (hỗ trợ mã MAC 4 byte):
Ứng dụng CPA phải hỗ trợ mã MAC 4 byte.
CHÚ THÍCH 1: Hỗ trợ các mã MAC có chiều dài từ 5 đến 8 byte được phép như một chức năng bổ
sung. Xem thêm tại Điều 6.3.5.
CHÚ THÍCH 2: Việc gửi thông điệp bí mật CPA bao gồm chuỗi MAC từ một lệnh đến tiếp theo trong
một tập lệnh.
5.5.3.2 Tính bí mật dữ liệu
Mã hóa dữ liệu được sử dụng để đảm bảo tính bí mật của dữ liệu được yêu cầu cho lệnh. Mã hóa dữ
liệu diễn ra trước khi sinh ra mã MAC cho lệnh.
5.5.4 Chỉ báo kết quả
Thẻ sử dụng Bộ đếm Lệnh Tập lệnh bên Phát hành để đếm từng lệnh có chứa gửi thông điệp bí mật
rằng được thực hiện thành công hoặc trước hoặc sau lệnh GENERATE AC lần hai.
Thẻ tăng bộ Đếm Lệnh tập lệnh bên Phát hành thêm một nếu lệnh tập lệnh được xử lý thành công.
Thẻ sử dụng bit 'đã nhận tập lệnh' trong PTH đến bản ghi rằng một lệnh tập lệnh đã được nhận.
Req 5.4 (Định nghĩa lệnh tập lệnh đã nhận):
Thẻ phải thiết lập bit 'tập lệnh đã nhận' trong PTH giá trị 1b khi thẻ nhận một lệnh tập lệnh và định dạng
lệnh là hợp lệ (tức là lệnh đã qua xác minh lệnh như mô tả ở Điều 6.3 trong TCVN 11198-2 và byte
CLA của mào đầu lệnh chỉ ra việc gửi thông điệp bí mật).
Thẻ sử dụng bit 'tập lệnh đã nhận' trong PTH đến bản ghi rằng quy trình xử lý lệnh tập lệnh bị lỗi.
Req 5.5 (Định nghĩa tập lệnh bị lỗi):
Nếu một lệnh tập lệnh được thông qua yêu cầu tại Điều 5.4 đã nhận hoặc trước hoặc sau lệnh
GENERATE AC lần hai, và lệnh không được thông qua thành công, thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH sang giá trị 1b;
• phải trả về một tình trạng lỗi trong hồi đáp lệnh;
• phải loại bỏ các lệnh tập lệnh tiếp theo đã nhận trong cùng giao dịch.
Ví dụ về nguyên nhân lỗi có thể không được xử lý thành công bao gồm:
• xác minh định dạng bị lỗi;
• việc gửi thông điệp bí mật bị lỗi (ví dụ như mã MAC đã tính toán không tương ứng với mã MAC có
trong lệnh, hoặc chiều dài của mã MAC không được hỗ trợ bởi ứng dụng);
• gửi thông điệp bí mật được thông qua nhưng quy trình xử lý lệnh bị lỗi;
5.5.5 Các lệnh tập lệnh được hỗ trợ
Các lệnh tập lệnh bên phát hành được hỗ trợ bởi tất cả việc thực thi CPA mà có thể được thực hiện
bằng Quy trình xử lý Tập lệnh bên phát hành đến thẻ được liệt kê bên dưới. Các lệnh tập lệnh bổ sung
có thể được hỗ trợ bởi việc thực thi CPA nhưng nằm ngoài phạm vi của bộ tiêu chuẩn này.
Req 5.6 (Các lệnh tập lệnh được hỗ trợ):
Tất cả các thực thi CPA phải hỗ trợ các lệnh tập lệnh bên phát hành bên dưới:
• APPLICATION UNBLOCK;
• PIN CHANGE/UNBLOCK;
• PUT DATA;
• UPDATE RECORD;
5.6 Lệnh APPLICATION UNBLOCK
Lệnh APPLICATION UNBLOCK được sử dụng để loại bỏ các hạn chế được đặt lên ứng dụng khi ứng
dụng bị khóa. Ví dụ ứng dụng có thể bị khóa khi bit 'Khóa ứng dụng' trong một CSU được phục hồi
thành công được thiết lập giá trị 1b.
Việc APPLICATION UNBLOCK thông qua việc sử dụng lệnh APPLICATION UNBLOCK nghĩa là ứng
dụng không còn được yêu cầu phản hồi tất cả các lệnh GENERATE AC với một AAC và trong hồi đáp
SELECT trong khi việc Lựa chọn Ứng dụng không còn yêu cầu SW1 SW2 = '6283'.
Trong phiên bản CPA này, việc APPLICATION UNBLOCK có thể xảy ra chỉ tại thiết bị đặc biệt được
thiết kế bởi bên phát hành. Từ khi APPLICATION UNBLOCK được thực hiện tại thiết bị đặc biệt đó,
luồng quy trình xử lý giao dịch để mở khóa giao dịch không nằm trong phạm vi của bộ tiêu chuẩn này,
việc này chỉ phù hợp với chuỗi lệnh đã mô tả tại Điều 6.2.2 trong TCVN 11198-2.
Lệnh APPLICATION UNBLOCK được thực hiện như mô tả ở EMV Quyển 3, Điều 6.5.2. Lệnh nhận
được từ thiết bị đầu cuối bao gồm việc gửi thông điệp bí mật mã MAC trong trường dữ liệu lệnh.
Thẻ nhận được lệnh APPLICATION UNBLOCK từ thiết bị đầu cuối. Nếu mã MAC là hợp lệ và các Byte
Tham số P1 và P2 có chứa giá trị '00' thì ứng dụng thiết lập bit 'Ứng dụng bị khóa’ trong PTH thành giá
trị 0b trước khi gửi hồi đáp APPLICATION UNBLOCK đến thiết bị đầu cuối.
5.6.1 Mã hóa Lệnh APPLICATION UNBLOCK
Bảng 4 - Thông điệp lệnh APPLICATION UNBLOCK
Code
CLA
Giá trị
'8C'
INS
'18'
P1
'00'
P2
'00'
New Lc
'06'
Data
trường dữ liệu lệnh bí mật
Le
không có mặt
Req 5.7 (lệnh tập lệnh APPLICATION UNBLOCK đã nhận):
Ứng dụng phải thiết lập bit ‘tập lệnh đã nhận' trong PTH thành giá trị 1b.
5.6.1.1 Xác minh định dạng lệnh APPLICATION UNBLOCK
Req 18.8 (Kiểm tra giá trị P1 cho APPLICATION UNBLOCK):
Nếu P1 không phải '00' thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh APPLICATION UNBLOCK, 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 = '6A86' (Tham số không đúng P1 P2);
Req 18.9 (Kiểm tra giá trị P2 cho APPLICATION UNBLOCK):
Nếu P2 không phải '00' thì thẻ:
• phải thiết lập bit ‘tập lệnh bị lỗi’ trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh APPLICATION UNBLOCK, 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 = ‘6A86’ (Tham số không đúng P1 P2);
5.6.2 Quy trình xử lý Lệnh APPLICATION UNBLOCK
Dữ liệu lệnh (Trường Dữ liệu lệnh bí mật) cho APPLICATION UNBLOCK có chứa chỉ dữ liệu MAC như
Hình 1.
Hình 1 - Định dạng Dữ liệu Lệnh chỉ nếu Dữ liệu MAC được thể hiện
Req 5.10 (Kiểm tra chiều dài dữ liệu lệnh cho APPLICATION UNBLOCK):
Nếu New Lc có giá trị khác '06' thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh APPLICATION UNBLOCK, 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 = '6700' (chiều dài sai);
Req 5.11 (Kiểm tra thẻ tag MAC cho APPLICATION UNBLOCK):
Nếu byte đầu tiên của Dữ liệu Lệnh có giá trị khác '8E' (thẻ tag MAC) thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh APPLICATION UNBLOCK, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ
đợi bị mất);
Req 5.12 (Kiểm tra chiều dài MAC cho APPLICATION UNBLOCK):
Nếu byte thứ hai của Dữ liệu Lệnh có giá trị khác '04' (chiều dài MAC) thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh APPLICATION UNBLOCK, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không
chính xác);
Ứng dụng tiến hành xác minh mã MAC.
Req 5.13 (Xác minh MAC cho APPLICATION UNBLOCK):
Nếu việc xác minh mã MAC không thành công, thì ứng dụng:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh APPLICATION UNBLOCK, 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 = '6982' (trạng thái an ninh không phù hợp);
nếu việc xác minh mã MAC thành công, thì ứng dụng phải:
• được mở khóa;
• thiết lập bit 'ứng dụng bị khóa' trong PTH thành giá trị 0b;
• tăng thêm một cho bộ Đếm Lệnh Tập lệnh bên Phát hành;
• hồi đáp với SW1 SW2 = '9000';
5.6.3 Luồng APPLICATION UNBLOCK
Hình 2 minh họa luồng lệnh APPLICATION UNBLOCK.
Hình 2 - Luồng APPLICATION UNBLOCK
Hình 2 - Luồng APPLICATION UNBLOCK (kết thúc)
5.7 Lệnh PIN CHANGE/UNBLOCK
Lệnh PIN CHANGE/UNBLOCK cung cấp cho bên phát hành khả năng hoặc để thay đổi đồng thời việc
mở khóa mã PIN Tham khảo hoặc để mở khóa mã PIN Tham khảo. Mã PIN Tham khảo được mở khóa
bằng cách thiết lập lại Bộ đếm Lần thử mã PIN thành giá trị của Hạn mức Lần thử mã PIN.
Thay đổi mã PIN
Nếu mã PIN tham khảo của thẻ bị thay đổi:
• định dạng Khối mã PIN bản rõ như biểu diễn trong EMV Quyển 3, Điều 6.5.12.2.
• Dữ liệu mã PIN được mã hóa như mô tả trong EMV Quyển 2, phần IV Điều 9.3, với byte Chỉ báo Đệm
thiết lập giá trị là '01'. Việc này nghĩa là khối 8 byte bổ sung có giá trị '80 00 00 00 00 00 00 00' được
gán vào khối mã PIN trước khi mã hóa.
Một khi mã PIN tham khảo của thẻ bị thay đổi, thẻ hoàn toàn được mở khóa mã PIN, từ khi hoàn thành
thành công lệnh PIN CHANGE/UNBLOCK tự động thiết lập lại Bộ đếm lần thử mã PIN sang Hạn mức
lần thử mã PIN,
Bỏ qua phương thức được sử dụng, mã PIN thay đổi chỉ khi được thực hiện bên trong môi trường bảo
mật được kiểm soát bởi bên phát hành.
5.7.1 Mã hóa Lệnh PIN CHANGE/UNBLOCK
Bảng 5 - Thông điệp lệnh PIN CHANGE/UNBLOCK
Code
Giá trị
CLA
‘8C’
INS
'24'
P1
'00'
P2
'00' hoặc ’02'
New Lc
'06' hoặc '09'
Data
dữ liệu liên quan đến mã PIN (thành phần dữ liệu mã PIN được mã
hóa, nếu có, và thành phần dữ liệu mã MAC)
Le
không có mặt
Req 5.14 (lệnh tập lệnh PIN CHANGE/UNBLOCK đã nhận):
Ứng dụng phải thiết lập bit 'tập lệnh đã nhận' trong PTH thành giá trị 1b.
5.7.1.1 Xác minh định dạng lệnh PIN CHANGE/UNBLOCK
Req 5.15 (Kiểm tra giá trị P1 cho PIN CHANGE/UNBLOCK):
Nếu P1 không phải '00' thì thẻ:
• phải thiết lập bít 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6A86’ (Tham số không đúng P1 P2);
Req 5.16 (Kiểm tra giá trị P2 cho PIN CHANGE/UNBLOCK):
Nếu P2 không phải '00' hoặc '02' thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6A86' (Tham số không đúng P1 P2);
5.7.2 Quy trình xử lý Lệnh PIN CHANGE/UNBLOCK
Req 5.17 (Kiểm tra khi nào Thay đổi mã PIN hoặc Mở khóa mã PIN):
Nếu P2 là '00' tiếp tục với quy trình được mô tả trong Điều 5.7.2.1. Nếu P2 là '02' tiếp tục quy trình xử
lý được mô tả trong Điều 5.7.2.2.
5.7.2.1 Mở khóa mã PIN
Quy trình xử lý trong điều này áp dụng nếu P2 là ’00’. Dữ liệu lệnh (dữ liệu liên quan mã PIN) để mở
khóa mã PIN có chứa chỉ dữ liệu mã MAC, như thể hiện trong Hình 1.
Req 5.18 (Kiểm tra chiều dài dữ liệu lệnh cho MỞ KHÓA MÃ PIN):
Nếu New Lc có giá trị khác '06' thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6700’ (chiều dài sai);
Req 5.19 (Kiểm tra thẻ tag MAC cho MỞ KHÓA MÃ PIN):
Nếu byte đầu tiên của Dữ liệu liên quan mã PIN có giá trị khác '8E' (thẻ tag MAC) thì thẻ:
• phải thiết lập bit ‘tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ
đợi bị mất);
Req 5.20 (Kiểm tra chiều dài MAC cho MỞ KHÓA MÃ PIN):
Nếu byte thứ hai của Dữ liệu liên quan mã PIN có giá trị khác '04' (chiều dài MAC) thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không
chính xác)
Ứng dụng thực hiện việc xác minh mã MAC.
Req 5.21 (Xác minh MAC và thiết lập lại Bộ đếm lần thử mã PIN):
Nếu việc xác minh mã MAC thành công, thì ứng dụng phải:
• thiết lập bộ đếm lần thử mã PIN thành giá trị của Hạn mức Lần thử mã PIN;
• tăng thêm một cho Bộ Đếm Lệnh Tập lệnh bên Phát hành;
• hồi đáp với SW1 SW2 = '9000';
Nếu việc xác minh mã MAC không thành công, thì ứng dụng:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6982' (trạng thái an ninh không phù hợp);
5.7.2.2 Thay đổi mã PIN
Quy trình xử lý trong điều này áp dụng nếu P2 là '02'.
Khối mã PIN bản rõ trước khi mã hóa để giữ bí mật được mã hóa như trong EMV Quyển 3, Bảng 24.
Việc này đệm thêm '80 00 00 00 00 00 00 00' và thì mã hóa như quy định cho ứng dụng tương thích
CCD trong EMV Quyển 2, Điều 9.3. Minh họa quy trình phục hồi Khối mã PIN mới tại Hình 3.
Hình 3 - Phục hồi Khối mã PIN Mới từ Dữ liệu Lệnh PIN CHANGE/UNBLOCK
Req 5.22 (Kiểm tra chiều dài dữ liệu lệnh cho THAY ĐỔI MÃ PIN):
Nếu New Lc có giá trị khác '19' thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6700' (chiều dài sai);
Req 5.23 (Kiểm tra thẻ tag bản mẫu thông điệp bí mật để THAY ĐỔI MÃ PIN):
Nếu byte đầu tiên của Dữ liệu liên quan mã PIN có giá trị khác '87', thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ
đợi bị mất);
Req 5.24 (Kiểm tra chiều dài của thông điệp bí mật để THAY ĐỔI MÃ PIN):
Nếu byte thứ hai của Dữ liệu liên quan mã PIN có giá trị khác '11', thì thẻ:
• phải thiết lập bit 'Tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không
chính xác);
Req 5.25 (Kiểm tra Chỉ báo phần Đệm để THAY ĐỔI MÃ PIN):
Nếu byte thứ ba của Dữ liệu liên quan mã PIN có giá trị khác '01' (Chỉ báo phần Đệm), thì thẻ:
• phải thiết lập bit 'Tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không
chính xác);
Req 5.26 (Kiểm tra thẻ tag MAC để THAY ĐỔI MÃ PIN):
Nếu byte thứ hai mươi của Dữ liệu liên quan mã PIN có giá trị khác '8E' (thẻ tag MAC), thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ
đợi bị mất);
Req 5.27 (Kiểm tra chiều dài mã MAC để THAY ĐỔI MÃ PIN):
Nếu byte hai mươi mốt của Dữ liệu liên quan mã PIN có giá trị khác '04' (chiều dài mã MAC), thì thẻ:
• phải thiết lập bit 'Tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không
chính xác);
Ứng dụng thực hiện việc xác minh mã MAC.
Req 5.28 (Xác minh MAC bị lỗi đối với THAY ĐỔI PIN):
Nếu việc xác minh mã MAC không thành công, thì ứng dụng:
• phải thiết lập bit ‘tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6982' (trạng thái an ninh không phù hợp);
Nếu không thẻ phải giải mã các byte 4-19 của dữ liệu lệnh để phục hồi Khối mã PIN Mới.
Req 5.29 (Xác minh định dạng Khối mã PIN và thay đổi mã PIN Tham khảo):
Nếu tất cả điều sau là đúng:
• byte 1, bit b8-b5 của Khối mã PIN mới (trường kiểm soát) có giá trị '2';
• và byte 1, bit b4-b1 của Khối mã PIN mới (chiều dài mã PIN) có giá trị lớn hơn hoặc bằng '4';
• và byte 1, bit b4-b1 của Khối mã PIN mới (chiều dài mã PIN) có giá trị nhỏ hơn hoặc bằng 'C;
• và tất cả các số Điền đầy của Khối mã PIN mới có giá trị 'F;
thì thẻ phải:
• cập nhật mã PIN Tham khảo;
• thiết lập Bộ đếm Lần thử mã PIN thành giá trị của Hạn mức Lần thử mã PIN;
• tăng Bộ đếm Lệnh tập lệnh bên Phát hành lên một;
• hồi đáp với SW1 SW2 = '9000';
nếu khác thì thẻ:
• phải thiết lập bit 'Tập lệnh bị lỗi' trong PTH có giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không
chính xác).
5.7.3 Luồng PIN CHANGE/UNBLOCK
Hình 4 minh họa luồng lệnh PIN CHANGE/UNBLOCK.
Hình 4 - Luồng PIN CHANGE/UNBLOCK
Hình 4 - Luồng PIN CHANGE/UNBLOCK (tiếp theo)
Hình 4 - Luồng PIN CHANGE/UNBLOCK (tiếp theo)
Hình 4 - Luồng PIN CHANGE/UNBLOCK (tiếp theo)
Hình 4 - Luồng PIN CHANGE/UNBLOCK (kết thúc)
5.8 Lệnh PUT DATA
Lệnh PUT DATA cho phép các phần tử dữ liệu cụ thể và bản mẫu trong thẻ được cập nhật. Một phần
tử dữ liệu hoặc bản mẫu có thể được cập nhật với lệnh này chỉ nếu nó có một thẻ tag liên quan nó.
Req 5.30 (Phần tử dữ liệu được hỗ trợ bởi PUT DATA):
Trong TCVN 11198-8, Điều 5 cho thấy chỉ các phần tử dữ liệu ứng dụng được định nghĩa bởi EMV và
bởi CPA và bản mẫu có thể được cập nhật bằng lệnh PUT DATA.
Req 5.31 (PUT DATA không yêu cầu các byte điền đầy):
Đối với các thẻ Tag bản mẫu, lệnh PUT DATA phải cho phép các bản mẫu không có các byte điền đầy.
Lệnh PUT DATA làm một thẻ Tag bản mẫu được phép chứa các byte điền đầy giá trị '00' trong dữ liệu
lệnh.
Xem Điều 11 trong TCVN 11198-7 về giải thích việc quản lý dữ liệu tài nguyên ứng dụng trong các bản
mẫu cho lệnh PUT DATA sử dụng một thẻ tag bản mẫu đơn cho từng kiểu tài nguyên.
5.8.1 Mã hóa Lệnh PUT DATA
Các tham số P1 và P2 của lệnh PUT DATA chỉ ra thẻ tag của dữ liệu được cập nhật.
Bảng 6 - Thông điệp lệnh PUT DATA
Code
Giá trị
CLA
'0C'
INS
‘24’
P1/P2
thẻ tag
New Lc
Var.
Data
trường dữ liệu lệnh bí mật
Le
không có mặt
Req 5.32 (lệnh tập lệnh PUT DATA đã nhận):
Ứng dụng phải thiết lập bit 'tập lệnh đã nhận' trong PTH thành giá trị 1b.
CHÚ THÍCH: Nếu một lệnh PUT DATA đã nhận trước khi lệnh GENERATE AC lần hai cập nhật phần
tử dữ liệu mà được sử dụng trong lúc quy trình xử lý của lệnh GENERATE AC lần hai, thì các giá trị
được cập nhật được sử dụng trong quy trình xử lý lệnh GENERATE AC lần hai.
5.8.1.1. Xác minh Định dạng Lệnh PUT DATA
Req 5.33 (Kiểm tra giá trị P1 cho PUT DATA):
Nếu P1/P2 không chứa một thẻ hoặc một thẻ biểu mẫu mà có thể được cập nhật bằng PUT DATA, thì
thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6A86' (Tham số không đúng P1 P2);
Các thẻ tag byte đơn đứng trước với một byte dẫn đầu '00' điền đầy P1/P2.
5.8.2 Quy trình xử lý PUT DATA
Định dạng của dữ liệu lệnh (Trường Dữ liệu Lệnh bí mật) cho PUT DATA như Hình 5.
Hình 5 - Định dạng dữ liệu Lệnh cho PUT DATA.
Nếu P1/P2 cho lệnh PUT DATA chứa một thẻ tag bản mẫu, dữ liệu lệnh gói gọn một tổ hợp gồm dữ
liệu mã hóa TLV được hiểu là một phần nội dung của bản mẫu.
Lệnh PUT DATA đưa thẻ tag bản mẫu cập nhật các phần tử dữ liệu mã hóa TLV với bản mẫu. Trường
dữ liệu lệnh không đòi hỏi việc bao gồm tất cả các phần tử dữ liệu trong bản mẫu, chỉ nếu chúng được
thêm vào hoặc sửa đổi. Xem Điều 11 trong TCVN 11198-7 về cách cập nhật một bản mẫu bằng lệnh
PUT DATA.
Req 5.34 (Kiểm tra bản mẫu gửi thông điệp bí mật để PUT DATA):
Nếu byte đầu tiên của Trường Dữ liệu lệnh bí mật có giá trị không bằng ’81’ thì ứng dụng:
• phải thiết lập bit ‘tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ đợi bị mất);
Ứng dụng xác minh định dạng gửi thông điệp bí mật cho dữ liệu lệnh.
Req 5.35 (Kiểm tra chiều dài dữ liệu lệnh và dữ liệu lệnh cho chiều dài 1 byte):
Nếu L được mã hóa một byte thì:
• Nếu New Lc không bằng 8+L thì thẻ:
- phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
- phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6700' (chiều dài sai);
• Nếu giá trị của byte (L + 3) của Trường Dữ liệu Lệnh bí mật có giá trị khác '8E' (thẻ tag MAC), thì thẻ:
- phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
- phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ đợi bị mất);
• Nếu giá trị của byte (L + 4) của Trường Dữ liệu Lệnh bí mật có giá trị khác '04' (chiều dài MAC), thì
thẻ:
- phải thiết lập bit 'Tập lệnh bị lỗi' trong PTH thành giá trị 1b;
- phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không chính xác);
Req 5.36 (Kiểm tra chiều dài dữ liệu lệnh và dữ liệu lệnh cho chiều dài 2 byte):
Nếu L được mã hóa hai byte thì:
• Nếu New Lc không bằng 9+L thì thẻ:
- phải thiết lập bit ‘tập lệnh bị lỗi' trong PTH thành giá trị 1b;
- phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6700' (chiều dài sai);
• Nếu giá trị của byte (L + 4) của Trường Dữ liệu Lệnh bí mật có giá trị khác '8E' (thẻ tag MAC), thì thẻ:
- phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
- phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6987' (các đối tượng dữ liệu gửi thông điệp bí mật đang chờ đợi bị mất);
• Nếu giá trị của byte (L + 5) của Trường Dữ liệu Lệnh bí mật có giá trị khác '04' (chiều dài MAC), thì
thẻ:
- phải thiết lập bit 'Tập lệnh bị lỗi' trong PTH thành giá trị 1b;
- phải chấm dứt quy trình xử lý lệnh PUT DATA, 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 = '6988' (các đối tượng dữ liệu gửi thông điệp bí mật không chính xác);
Nếu không, ứng dụng phải tiếp tục quy trình xử lý với việc xác minh mã MAC.
Ứng dụng thực hiện việc xác minh mã MAC.
Req 5.37 (Xác minh MAC bị lỗi để PUT DATA):
Nếu việc xác minh mã MAC không thành công, thì thẻ:
• phải thiết lập bit 'tập lệnh bị lỗi' trong PTH thành giá trị 1b;
• phải chấm dứt quy trình xử lý lệnh PIN CHANGE/UNBLOCK, 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 = '6982' (trạng thái an ninh không phù hợp).
Nếu việc xác minh mã MAC thành công, thì thẻ xác định rằng dữ liệu lệnh có thẻ tag và chiều dài hợp
lệ để cập nhật dữ liệu ứng dụng.
Ứng dụng thiết lập không gian cho các phần tử dữ liệu mà có thể được cấu hình bằng lệnh PUT DATA,
và không xử lý truy vấn để cập nhật phần tử dữ liệu nếu việc cập nhật vượt quá không gian đã lập cho
phần tử dữ liệu.
Req 5.38 (PUT DATA có một thẻ tag bản mẫu trong P1/P2):
Nếu P1/P2 có chứa một thẻ tag bản mẫu, thì:
• thẻ phải tách từng phần tử dữ liệu mã hóa TLV bên trong dữ liệu lệnh;
• đối với từng phần tử dữ liệu mã hóa TLV đã tách:
- Nếu thẻ tag không được hỗ trợ bên trong bản mẫu, thì thẻ:
■ phải thiết lập bit 'tập lệnh bị lỗi' trong PTH có giá trị 1b;
■ phải chấm dứt quá trình xử lý lệnh PUT DATA, phải hồi đáp với một SW1 SW2 chỉ ra một lỗi và hồi
đáp với SW1 SW2 = '6A88' (dữ liệu tham chiếu không có);
- Nếu chiều dài của dữ liệu bản mẫu lớn hơn chiều dài phục hồi cho phần tử dữ liệu, thì thẻ:
■ phải thiết lập bit 'tập lệnh bị lỗi' trong PTH có giá trị 1b;
■ phải chấm dứt quá trình xử lý lệnh PUT DATA, phải hồi đáp với một SW1 SW2 chỉ ra một lỗi và hồi
đáp với SW1 SW2 = '6700' (chiều dài sai);
• Nếu thẻ và chiều dài được hỗ trợ cho tất cả phần tử dữ liệu bên trong bản mẫu, thì thẻ phải:
- cập nhật tất cả phần tử dữ liệu;
- tăng thêm một cho Bộ đếm Lệnh tập lệnh bên Phát hành;
- hồi đáp với SW1 SW2 = '9000';
CHÚ THÍCH: Thẻ phải kiểm tra chiều dài của dữ liệu chiều dài cố định trước khi cập nhật phần tử dữ
liệu.
Req 5.39 (PUT DATA có một thẻ tag phần tử dữ liệu trong P1/P2):
Nếu P1/P2 có chứa một thẻ tag phần tử dữ liệu, thì:
• Nếu L nhỏ hơn hoặc bằng với chiều dài phục hồi cho phần tử dữ liệu, thì thẻ phải:
- cập nhật tất cả phần tử dữ liệu;
- tăng thêm một cho Bộ đếm Lệnh tập lệnh bên Phát hành;
- hồi đáp với SW1 SW2 = '9000';
• Nếu không thì thẻ:
- phải thiết lập bit 'tập lệnh bị lỗi' trong PTH có giá trị 1b;
- phải chấm dứt quá trình xử lý lệnh PUT DATA, phải hồi đáp với một SW1 SW2 chỉ ra một lỗi và hồi
đáp với SW1 SW2 = '6700' (chiều dài sai);
CHÚ THÍCH: Thẻ phải kiểm tra chiều dài của dữ liệu chiều dài cố định trước khi cập nhật phần tử dữ
liệu.
Lệnh PUT DATA không yêu cầu các byte điền đầy trong dữ liệu bản mẫu. Tuy nhiên, bởi vì lệnh có một
chiều dài cho dữ liệu lệnh bổ sung cho chiều dài từng phần tử dữ liệu mã hóa TLV, bên phát hành cho
phép thêm các byte điền đầy vào dữ liệu lệnh.
CHÚ THÍCH: EMV sử dụng giá trị '00' cho các byte điền đầy.
Req 5.40 (Các byte điền đầy không yêu cầu trong lệnh PUT DATA):
Các byte điền đầy không được yêu cầu gửi trong bản mẫu cho lệnh PUT DATA.
5.8.3 Luồng PUT DATA
Hình 6 minh họa luồng của lệnh PUT DATA.
Hình 6 - Luồng PUT DATA
Hình 6 - Luồng PUT DATA (tiếp theo)
Hình 6 - Luồng PUT DATA (tiếp theo)
Hình 6 - Luồng PUT DATA (kết thúc)
5.9 Lệnh UPDATE RECORD
Lệnh UPDATE RECORD được sử dụng để cập nhật một bản ghi trong một tệp tin với dữ liệu được
cung cấp trong trường dữ liệu lệnh.
5.9.1 Mã hóa lệnh UPDATE RECORD
Tham số P1 của lệnh UPDATE RECORD chỉ ra khi số lượng bản ghi bên trong SFI tham chiếu trong
P2 được cập nhật. Tham số P2 chỉ ra SFI của tệp tin có chứa bản ghi được cập nhật, và chỉ ra P1 có
chứa số lượng bản ghi. Phần dữ liệu của lệnh chứa dữ liệu cho bản ghi.
Bảng 7 - Thông điệp lệnh UPDATE RECORD
Code
Giá trị
CLA
‘0C’
INS
‘DC’
P1
Số lượng Bản ghi
P2
Tham số Kiểm soát tham khảo
New Lc
Var.
Data
Dữ liệu liên quan đến bản ghi
Le
Không có mặt
Bảng 8 thể hiện việc mã hóa của Tham số Kiểm soát Tham khảo trong P2:
b8
b7
x
x
Bảng 8 - Mã hóa tham số kiểm soát tham khảo cho UPDATE RECORD
gi
ải
ng
hĩ
b3 b2b
ag
b6
b5
b4 b3
b1giải nghĩa
b2 1
iải
ng
hĩ
a
S
F
I
S
F
x
x
x
SFI
I
S
F
I
xx
xx
x
1 10
00
0P1 là số hiệu bản ghi.
x
P
1
l
à
s
ố
h
i
ệ
u
b
ả
n
g
h
i.
P
1
l
à
s
ố
h
i
ệ
u
b
ả
n
g
