Xem mẫu
- TIÊU CHUẨN QUỐC GIA
TCVN 11198-6: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 6: QUẢN LÝ KHÓA VÀ AN NINH
EMV integrated circuit card for payment systems - Common payment application specification - Part 6:
Security and key management
Lời nói đầu
TCVN 11198-6: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-6: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 6: QUẢN LÝ KHÓA VÀ AN NINH
EMV Integrated Circuit Card for Payment Systems - Common payment application specification
- Part 6: Security and key management
1. Phạm vi áp dụng
Tiêu chuẩn TCVN 11198-2 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 chủ đề bổ sung cho các quy trình xử lý chức năng, cụ thể
bao gồm:
• Các chức năng bổ sung;
• Quản lý an ninh và quản lý khóa;
• Cá thể hóa.
Các yêu cầu an ninh trong điều này phải đạt được cho tất cả các triển khai CPA nhưng phương pháp
để đảm bảo các yêu cầu (ví dụ khi nào yêu cầu được đặt ra bởi ứng dụng hoặc bởi nền tảng, và khi
nào có hoặc không có bộ đếm được sử dụng cho an ninh) là theo ý muốn của bên triển khai.
CHÚ THÍCH: Các yêu cầu an ninh trong tiêu chuẩn này áp dụng bất kể có hay không việc ứng dụng hỗ
trợ các tùy chọn triển khai Bộ đếm An ninh Ứng dụng.
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. Các chức năng bổ sung
5.1. Tổng quan
CPA quy định một tập lõi các chức năng mà bên phát hành có thể dựa vào những thứ có sẵn trong tất
cả việc triển khai của CPA “off the shelf”. EMV chỉ định rõ kiểu yêu cầu chính cho chức năng lõi này.
Điều này là theo ý muốn bên phát hành để lựa ra một việc triển khai CPA mà có thể cũng bao gồm
chức năng bổ sung. Điều này mô tả các yêu cầu liên quan với chức năng bổ sung và ví dụ về cách
thức chức năng bổ sung có thể thêm vào chức năng lõi như mô tả trong bộ TCVN 11198 này.
CPA bao gồm các phần tùy ý bên phát hành trong lựa chọn các phần tử dữ liệu mà có thể được sử
dụng để hỗ trợ chức năng bổ sung (ví dụ, trong ADR, Kiểm soát ứng dụng, CIAC, và CVR). CPA cũng
cho phép mở rộng các lựa chọn phần tử dữ liệu (ví dụ Kiểm soát Hồ sơ) để hỗ trợ các chức năng bổ
sung.
5.2. Yêu cầu cho Chức năng bổ sung
Để cho phép kiểu triển khai chính cho CPA mà bao gồm chức năng bổ sung, cải tiến CPA như bên
dưới:
Req 6.5.1 (cấu hình chức năng bổ sung để phù hợp CPA):
Tất cả yêu cầu trong đặc tả CPA (ngoại trừ các hạng mục tùy chọn triển khai) phải có trong ứng dụng,
và nó phải có thể cấu hình ứng dụng để phù hợp với đặc tả CPA.
Req 6.5.2 (tuân thủ CPA liên quan tới chức năng bổ sung):
Ứng dụng được xem xét không tuân thủ CPA khi các tính năng bổ sung được cấu hình theo cách thức
làm cho ứng dụng không còn phù hợp với đặc tả CPA.
Chức năng bổ sung không tác động đến hành động CPA đã thực hiện.
Chức năng bổ sung không được thử nghiệm như một phần kiểu CPA chính
CHÚ THÍCH: Các bit được thể hiện trong Điều 7 của TCVN 11198-8 như RFU được cấp pháp cho
tương lai bởi EMV và không được sử dụng cho chức năng bổ sung.
5.3. Ví dụ về Chức năng bổ sung
5.3.1. Các Thanh tổng, Bộ đếm, Thanh tổng Chu kỳ bổ sung
CPA yêu cầu một tập tối thiểu gồm hai thanh tổng (và các Quỹ Có sẵn VLP tùy chọn), ba bộ đếm và
hai thanh tổng chu kỳ là phải được triển khai trong CPA cho bên phát hành sử dụng theo ý muốn của
họ.
• Mở rộng chiều dài cho phần tử dữ liệu Kiểm soát Hồ sơ X từ n byte (n>8). Từng cụm 4 bit trong byte
9 đến n phải được gán để chỉ một số ID Kiểm soát Hồ sơ cho từng thanh tổng, bộ đếm bổ sung hoặc
thanh tổng chu kỳ bổ sung. Ví dụ một thanh tổng bổ sung và một bộ đếm bổ sung:
▪ byte 9, bit b8-5: số ID Kiểm soát Hồ sơ Thanh tổng cho Thanh tổng 3;
▪ byte 9, bit b4-1: số ID Kiểm soát Hồ sơ Bộ đếm cho Bộ đếm 4;
• Đối với từng Thanh tổng x bổ sung, thêm vào:
▪ một Kiểm soát Thanh tổng x (bản mẫu ‘BF32’);
▪ một Dữ liệu Thanh tổng x (bản mẫu ‘BF30’);
• Đối với từng Bộ đếm x bổ sung, thêm vào:
▪ một Kiểm soát Bộ đếm x (bản mẫu ‘BF37’);
- ▪ một Dữ liệu Bộ đếm x (bản mẫu ‘BF35’);
• Đối với từng Thanh tổng Chu kỳ x bổ sung, thêm vào một phần tử dữ liệu Kiểm soát Thanh tổng Chu
kỳ x (bản mẫu ‘BF3A’);
• Sử dụng các bit bên dưới trong ADR và CIAC cho quản lý rủi ro thẻ gán với các thanh tổng, bộ đếm
và thanh tổng chu kỳ bổ sung:
▪ Vượt quá Hạn mức Dưới Thanh tổng bổ sung;
▪ Vượt quá Hạn mức Trên Thanh tổng bổ sung;
▪ Vượt quá Hạn mức Dưới Bộ đếm bổ sung;
▪ Vượt quá Hạn mức Trên Bộ đếm bổ sung;
▪ Vượt quá Hạn mức Thanh tổng Chu kỳ bổ sung;
5.3.2. Các bit Tùy ý bên Phát hành - CVR, ADR và CIAC
Các bit tùy ý bên phát hành trong CVR, ADR, và CIAC có thể được sử dụng cho chức năng bổ sung
mà có thể được sử dụng trong Quản lý Rủi ro Thẻ. Các bit CVR và ADR có thể được thiết lập như là
một kết quả triển khai các chức năng bổ sung. Các bit CVR phải được sử dụng để chỉ ra kết quả của
chức năng bổ sung để bên phát hành. Các bit ADR phải được thiết lập sao cho bit tương ứng trong
CIAC có thể được cá thể hóa để cho phép các ứng dụng bao gồm các kết quả của các chức năng bổ
sung trong quyết định xem có nên từ chối giao dịch ngoại tuyến và gửi thực hiện trực tuyến.
5.3.3. Các bit Tùy ý bên Phát hành - Dữ liệu ứng dụng Nội bộ
Các bit tùy ý bên phát hành trong Kiểm soát ứng dụng và Kiểm soát Hồ sơ Tùy chọn bên Phát hành có
thể được sử dụng cho các chức năng bổ sung. Để đảm bảo loại thẻ CPA chính có thể với thẻ chứa
chức năng bổ sung, thiết lập các bit tùy ý bên phát hành thành giá trị không phải vô hiệu hóa bất kỳ
chức năng bổ sung nào thay đổi hành động của thẻ.
5.3.4. Các bit Tùy ý bên Phát hành - Dữ liệu ứng dụng bên Phát hành
Các byte tùy ý bên phát hành trong Dữ liệu ứng dụng bên Phát hành có thể được thiết lập để các giá trị
mặc định được cá thể hóa, có thể mang theo các thông tin được mô tả tại Điều 7 trong TCVN 11198-8
cho byte 19-32, hoặc có thể được sử dụng để gửi các kết quả của chức năng bổ sung cho bất kỳ Hồ
sơ nào khác hơn so với Hồ sơ ‘7E’ (trong đó yêu cầu các byte được thiết lập giá trị không).
5.3.5. Các bit Tùy ý bên Phát hành - Dữ liệu Xác thực bên Phát hành
Các thẻ CPA có thể hỗ trợ lên đến tám byte của Dữ liệu Xác thực Độc quyền trong Dữ liệu Xác thực
bên Phát hành. Các chức năng bổ sung sử dụng Dữ liệu Xác thực Độc quyền nằm ngoài phạm vi của
bộ tiêu chuẩn này.
CPA yêu cầu thẻ có thể chấp nhận 8-byte của Dữ liệu Xác thực bên Phát hành, ứng dụng cũng có thể
hỗ trợ lên đến 16 byte của Dữ liệu Xác thực bên Phát hành (trong đó bao gồm lên đến 8 byte của Dữ
liệu Xác thực Độc quyền). Các đặc điểm kỹ thuật của quy trình xử lý Xác thực bên Phát hành trong
Điều 7 của TCVN 11198-4 mô tả ứng dụng CPA hỗ trợ chi có 8 byte của Dữ liệu Xác thực bên Phát
hành. Khi ứng dụng CPA cũng hỗ trợ Dữ liệu Xác thực Độc quyền:
• Nếu bit ‘bao gồm Dữ liệu Xác thực Độc quyền’ trong CSU có giá trị 0b, thì ứng dụng xác nhận các Dữ
liệu Xác thực bên Phát hành với một Dữ liệu Xác thực Độc quyền có các byte chiều dài không;
• Nếu bit ‘bao gồm Dữ liệu Xác thực Độc quyền’ trong CSU có giá trị 1b, thì:
▪ xác nhận của ARPC phải được sửa đổi để bao gồm các Dữ liệu Xác thực Độc quyền;
▪ chiều dài cho Dữ liệu Xác thực bên Phát hành phải được thay đổi để bao gồm chiều dài của Dữ liệu
Xác thực Độc quyền;
• Chức năng bổ sung sử dụng PAD là nằm ngoài phạm vi của CPA.
5.3.6. Lệnh tập lệnh bên Phát hành bổ sung
CPA đòi hỏi một tập tối thiểu các lệnh tập lệnh bên phát hành đến thẻ phải được thực hiện hoặc trong
các thẻ hoặc ứng dụng cho bên phát hành để sử dụng theo ý muốn của họ. Các lệnh bổ sung phải
được hỗ trợ.
Nếu một thẻ hỗ trợ các lệnh tập lệnh bổ sung để sử dụng với CPA, các lệnh phải được thực hiện sao
- cho các bit CVR và ADR cho các chỉ báo tập lệnh phải được thiết lập cho giao dịch hiện thời và tiếp
theo nếu các yêu cầu của Điều 5.5.4 của TCVN 11198-5 đã được thực hiện cho các lệnh.
Các ứng dụng phải giữ trong trạng thái hiện thời (xem Điều 6.2, TCVN 11198-2) sau khi xử lý thành
công một lệnh tập lệnh bên phát hành bổ sung.
5.3.7. Hỗ trợ cho các Chiều dài MAC khác
CPA yêu cầu thẻ có thể chấp nhận mã MAC 4-byte. Ứng dụng cũng có thể hỗ trợ các mã MAC dài hơn
(mã MAC 5-byte đến 8-byte) như quy định đối với ứng dụng tương thích CCD trong EMV Quyển 2,
Điều 9. Quy định đặc tả các lệnh tập lệnh từ Điều 5.6 đến Điều 5.9 của TCVN 11198-5 mô tả các ứng
dụng CPA chỉ hỗ trợ mã MAC 4-byte. Khi ứng dụng CPA cũng hỗ trợ các mã MAC dài hơn, các sửa
đổi yêu cầu sau đây phải áp dụng:
• Kiểm tra trên New Lc được sửa đổi để cho phép dữ liệu lệnh dài hơn;
• Kiểm tra về chiều dài của phần tử dữ liệu ‘8E’ được sửa đổi để cho phép mã MAC dài hơn.
6. Quản lý An ninh và Quản lý khóa
6.1. Bảo vệ mã PIN tham khảo
So sánh các PIN giao dịch với mã PIN tham khảo cần phải được thực hiện trong một cách an toàn có
thể ngăn chặn sự thỏa hiệp của PIN tham khảo thông qua các cuộc tấn công chẳng hạn như, nhưng
không hạn mức, chèn lỗi, rách, và thời gian hoặc phân tích năng lượng.
Trong trường hợp của một mã PIN không đúng, nó cần phải được không thể phát hiện thời gian hoặc
đo công suất mà chữ số hoặc chữ số là không chính xác và đó (nếu có) chính xác.
Req 6.6.1 (Giảm Bộ đếm lần thử mã PIN khi mã PIN được truy nhập):
Bất cứ khi nào các mã PIN tham khảo được truy nhập, Bộ đếm Lần thử mã PIN phải được giảm đi một.
Req 6.6.2 (Thiết lập lại Bộ đếm lần thử mã PIN):
Bộ đếm Lần thử mã PIN chỉ được thiết lập lại khi tiến hành xác minh thành công mã PIN, hoặc xử lý
thành công một lệnh PIN CHANGE/UNBLOCK. Bộ đếm Lần thử mã PIN phải được thiết lập cho các
giá trị quy định trong CSU là một kết quả của việc xử lý thành công một CSU tại đó bit 'Cập nhật Bộ
đếm Lần thử mã PIN' có giá trị 1b.
Req 6.6.3 (mã PIN tham khảo không thể truy cập từ bên ngoài):
Các tham chiếu PIN được sử dụng để xác minh ẩn PIN phải không thể truy cập từ bên ngoài vào thẻ.
Req 6.6.4 (Lưu trữ các mã PIN tham khảo):
Các PIN tham khảo được lưu trữ trong một cách để đảm bảo rằng những thất bại trong quy trình xử lý
PIN (bao gồm cả lỗi giải mã PIN hoặc nhập mã PIN không chính xác) và quy trình xử lý (như rách) phải
không gây ra một tổn thất hoặc thay đổi mã PIN tham khảo.
Req 6.6.5 (Không tiết lộ mã PIN tham khảo):
Việc xử lý của việc so sánh mã PIN, Lệnh VERIFY, và các lệnh PIN CHANGE/UNBLOCK không được
tiết lộ bất kỳ thông tin về giá trị của các mã PIN tham khảo.
6.2. Bảo vệ khóa
Việc cần thiết là không thể xác định giá trị của bất kỳ khóa ứng dụng nào trong thẻ bởi việc việc sử
dụng sai giao diện logic (ví dụ, bằng cách tập trung vào ứng dụng để xử lý một số lượng lớn các lệnh,
hoặc lệnh có chứa mã lệnh được định dạng sai).
Các khóa mã hóa có thể được bảo vệ bằng cách đảm bảo rằng khóa chỉ có thể được sử dụng (hoặc
sử dụng sai) một số lần hạn mức.
• Đối với thuật toán mã hóa đối xứng, việc sử dụng các khóa phiên tự nhiên dẫn đến việc hạn chế sử
dụng một khóa phiên cụ thể. Tuy nhiên việc này cần thiết được thực hiện để hạn chế rủi ro rò rỉ khóa
chính trong khi phân phối khóa phiên. Nếu nền tảng thẻ là không đủ bảo vệ chống lại một số loại tấn
công, thì việc rò rỉ có thể xảy ra thông qua việc lạm dụng liên tục thẻ và quy trình xử lý phân phối khóa
phiên của thẻ;
• Đối với khóa bất đối xứng xác thực dữ liệu ngoại tuyến (DDA/CDA), ứng dụng phải ngăn chặn kẻ tấn
công từ việc thu thập một số lượng quá nhiều của chữ ký kỹ thuật số từ thẻ. Hơn nữa ứng dụng nên
- ngăn chặn một kẻ tấn công từ việc thu thập một số lượng quá nhiều chữ ký được tạp ra trên cùng một
đầu vào dữ liệu;
• Đối với khóa bất đối xứng giải mã mã PIN ngoại tuyến, khóa riêng RSA nên không được sử dụng để
giải mã một số lượng quá nhiều mã PIN được định dạng xấu.
Req 6.6.6 (An ninh cho khóa mã hóa):
Việc triển khai CPA phải đảm bảo rằng không khả thi cho kẻ tấn công để xác định giá trị của các khóa
mã hóa bí mật được sử dụng bởi ứng dụng.
6.3. Gửi thông điệp bí mật
Req 6.6.7 (Trạng thái hỗ trợ quy trình xử lý gửi thông điệp bí mật):
Thẻ phải không xử lý các thông điệp bí mật trừ khi trong trạng thái ONLINE hoặc SCRIPT.
Req 6.6.8 (Dừng quy trình xử lý tập lệnh sau khi lỗi mã MAC):
Một khi lỗi mã MAC xuất hiện, thẻ phải chấm dứt quy trình xử lý các lệnh tập lệnh tiếp theo đã nhận
trong cùng giao dịch, phải hồi đáp với một SW1 SW2 chỉ ra lỗi, và hồi đáp với SW1 SW2 = ‘6982’ (tình
trạng an ninh không thích hợp).
6.4. Bộ đếm an ninh
Việc sử dụng bộ đếm an ninh là một phương thức để đảm bảo rằng đạt được các yêu cầu trong Điều
6.2. Nếu việc triển khai cụ thể sử dụng các bộ đếm an ninh cho một mục đích rõ ràng, các bộ đếm và
liên quan của chúng có thể được triển khai bởi các ứng dụng hoặc bởi nền tảng. Trong TCVN 11198-7,
Điều 10 quy định một phương pháp để triển khai bộ đếm an ninh trong ứng dụng, về cơ bản có thể có
bốn loại bộ đếm trong CPA:
• Bộ đếm Giao dịch ứng dụng (ATC), đây là ứng dụng rộng rãi, và là tăng lên một lần cho mỗi giao
dịch. Bảo vệ khóa đạt được bằng cách áp dụng các kiểm soát để hạn chế các hoạt động mã hóa hạn
mức có liên quan cho từng giao dịch;
▪ Với ATC bao gồm trong dữ liệu mã hóa, đầu vào dữ liệu phải khác nhau đối với mỗi giao dịch;
▪ Với ATC bao gồm trong phân phối khóa phiên, khóa phiên phải khác nhau đối với mỗi giao dịch.
• Bộ đếm khóa có kiểm soát số lần mà một khóa được sử dụng trong một quá trình mã hóa để hạn chế
sự lạm dụng liên tục của một thẻ (ví dụ, việc sinh thêm nhiều mật mã ứng dụng hơn được kỳ vọng
thông qua việc sử dụng thông thường trong một khoảng thời gian nhất định);
• Bộ đếm lần thử mã PIN có thể hạn mức số lần mà một PIN bị nhập sai;
• Bộ đếm lệnh có thể hạn mức số lần một lệnh cụ thể được thực hiện trong một giao dịch (ví dụ lệnh
INTERNAL AUTHENTICATE trong một giao dịch).
Đối với mã lệnh ứng dụng, một bộ đếm khóa (và hạn mức có liên quan) tăng thêm trước khi phân phối
khóa phiên đồng bộ và được thiết lập lại khi xác minh thành công một ARPC có thể bảo vệ cả khóa
chính và khóa phiên như sau:
• Bằng cách hạn mức số lượng liên tiếp phân phối khóa phiên có thể xảy ra (không do bên phát hành)
và do đó, số lần các khóa chính được thực hiện mà không cần bên phát hành biết;
• Đối với mỗi khóa phiên khi đã phân phối, số lần sinh Mã lệnh Ứng dụng được hạn mức bởi các ứng
dụng nhiều nhất là hai cho mỗi giao dịch;
• Đối với mỗi khóa phiên khi đã phân phối, số lần cố gắng xác minh ARPC được hạn mức bởi các ứng
dụng là một lần cho mỗi giao dịch.
Đối với việc gửi thông điệp bí mật, một bộ đếm khóa (và hạn mức có liên quan) tăng thêm trước khi
phân phối khóa phiên đồng bộ và giảm khi xác minh thành công một mã MAC gửi thông điệp bí mật có
thể bảo vệ khóa như sau:
• Bằng cách hạn mức tổng số các lần xác minh mã MAC tập lệnh không thành công và lần phân phối
khóa phiên có liên quan, bởi vì lúc nhiều nhất là một thất bại MAC có thể xảy ra cho mỗi giao dịch.
• Bằng cách cấm sự cố gắng buộc giải mã không thành công dữ liệu bí mật, từ khi mỗi tin nhắn như
vậy được bảo vệ bởi một MAC đã xác minh (và phải thất bại) đầu tiên.
Đối với các khóa DDA/CDA, số lượng các chức năng ký trên từng giao dịch cần thiết hạn chế.
- Đối với khóa giải mã mã PIN, một bộ đếm an ninh có thể được áp dụng để hạn mức số lần mã PIN giải
mã sai được thực hiện.
Req 6.6.9 (ATC không quay vòng):
ATC phải không được phép quay vòng.
CHÚ THÍCH: Nếu một bên phát hành lựa chọn hạn mức số giao dịch tối đa mà có thể được xử lý bởi
ứng dụng trên vòng đời của thẻ ít hơn 65535, thì ATC có thể được cá thể hóa để bắt đầu một giá trị
khác không. Điều này là tùy chọn bên phát hành.
Req 6.6.10 (ATC không được cập nhật bằng tập lệnh):
ATC phải không thể cập nhật bằng bất kỳ lệnh tập lệnh nào.
Req 6.6.11 (Chỉ một lệnh INTERNAL AUTHENTICATE trên từng giao dịch):
Việc triển khai CPA phải đảm bảo rằng ứng dụng thực hiện nhiều nhất một lệnh INTERNAL
AUTHENTICATE cho từng giá trị của ATC. Nếu ứng dụng nhận được lệnh INTERNAL
AUTHENTICATE bổ sung (sau cái thứ nhất) trong cùng giao dịch, thì ứng dụng phải chấm dứt quy
trình xử lý lệnh INTERNAL AUTHENTICATE bổ sung, phải hồi đáp với một SW1 SW2 chỉ ra lỗi, và hồi
đáp với SW1 SW2 = ‘6985’ (điều kiện không thích hợp).
Req 6.6.12 (Các bộ đếm an ninh không quay vòng):
Các bộ đếm an ninh không được quay vòng.
6.5. Các yêu cầu dữ liệu khác
Phát triển ứng dụng thẻ thông minh phải đưa vào tài khoản các khía cạnh sau:
• Các ứng dụng phải có khả năng chống các cuộc tấn công rách. Mất điện tại bất kỳ giai đoạn quy trình
xử lý nào không làm ứng dụng chuyển sang trạng thái không an toàn. Với ngoại lệ các mục dữ liệu như
bộ đếm an ninh mà bảo vệ dữ liệu nhạy cảm, hoặc là tất cả hoặc không có thay đổi được thực hiện
trong quy trình xử lý một lệnh phải diễn ra.
• Các mục dữ liệu phải được bảo vệ thích hợp chống lại các hư hỏng tình cờ và / hoặc phần mềm độc
hại (ví dụ, được bảo vệ bởi checksums). Nếu dữ liệu được tìm thấy bị hư hỏng, các ứng dụng phải loại
bỏ tất cả các lệnh với một mã lỗi thích hợp.
Số ICC động được tạo ra bởi các ứng dụng để sử dụng trong DDA và CDA. Số ICC không thể đoán
trước được tạo ra để đáp ứng với các lệnh GET CHALLENGE.
Req 6.6.13 (số ngẫu nhiên được tạo ra bởi ứng dụng):
Số ICC không thể đoán trước (thách thức) và số ICC động (như trong DDA / CDA) phải là số không thể
đoán trước 8 byte và như vậy phải được tạo ra một cách ngẫu nhiên.
Điều này có thể đạt được bằng cách sử dụng một Bộ sinh số ngẫu nhiên (RNG) được cung cấp bởi
nhà sản xuất IC. Một RNG như vậy nên thực hiện theo tiêu chuẩn ISO/IEC 18032, NIST SP 800-22A,
hay AIS 20.31.
Sau đây mô tả phương pháp cho mã hóa các phần 8-byte ‘Bộ đếm’ của Dữ liệu ứng dụng bên Phát
hành trước khi Mã lệnh ứng dụng được tạo ra. ‘Bộ Đếm’ được mã hóa nếu bit ‘Phần bộ đếm mã hóa
trong IAD’ trong Kiểm soát Hồ sơ Tùy chọn bên Phát hành có giá trị 1b.
Req 6.6.14 (Bộ đếm mã hóa trong Dữ liệu ứng dụng bên Phát hành):
Nếu (8-byte) phần Bộ đếm của Dữ liệu ứng dụng bên Phát hành là được mã hóa, nó phải được mã hóa
như sau:
Khối Bộ đếm 8-byte được mã hóa trong chế độ ECB theo quy định tại Phụ lục A1.1 của EMV Quyển 2,
với không có đệm bổ sung được áp dụng (như vậy, bản mã dài tám byte).
Khóa Mã hóa (ECK) được sử dụng phải là một biến thể của khóa phiên AC (SK) tính như sau:
SKL = Bên trái nhất của byte SKAC
SKR = Bên phải nhất của byte SKAC
ECKL : = SKL ⊕ (‘59’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ’00 ’)
ECK R: = SKR ⊕ (‘95’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00’ ║ ‘00 ’)
- ECK = ECKL ║ ECKR
7. Cá thể hóa
7.1. Phần tử Dữ liệu được cá thể hóa
Phần này quy định cụ thể các phần tử dữ liệu được cá thể hóa cho các ứng dụng. Các yêu cầu của
phần này áp dụng bất kể ứng dụng là cá thể hóa bằng EMV CPS, hoặc một phương pháp cá thể hóa
nào khác.
Làm thế nào các phần tử dữ liệu được cá thể hóa hoặc tiền cá thể hóa là nằm ngoài phạm vi của CPA,
trừ khi EMV CPS được sử dụng.
CHÚ THÍCH: Dữ liệu bắt buộc của EMV được quy định trong EMV Quyển 3, điều 7.2,
7.1.1. Dữ liệu EMV trong bản ghi với SFI từ 1 đến 10
Trước hoặc sau khi cá thể hóa theo CPA, phần sau đây được xác định:
• Các tập tin (nghĩa là, giá trị cho SFI) được sử dụng để lưu trữ dữ liệu EMV.
• Các bản ghi (nghĩa là, các giá trị cho số lượng bản ghi trong một tập tin) được sử dụng và chiều dài
dành cho mỗi bản ghi.
Triển khai một số CPA không cần phải xác định việc tổ chức dữ liệu trong bản ghi trước Khi cá thể hóa,
kể từ khi một số nền tảng thẻ đa ứng dụng không đòi hỏi một hệ thống tập tin và các ứng dụng thì có
thể mô phỏng các tập tin và tự ghi lại chính nó.
Các triển khai khác phải cần phải xác định việc tổ chức dữ liệu trong bản ghi trước khi cá thể hóa. Đây
là trường hợp, ví dụ, khi một hệ thống tập tin thực sự được sử dụng để lưu trữ các bản ghi và khi các
cấu trúc tập tin không thể được tạo ra bởi các ứng dụng.
Req 6.7.1 (Tổ chức dữ liệu bản ghi EMV):
Các yêu cầu sau được áp dụng cho tổ chức bản ghi EMV thành tệp tin:
• Ở mức tối thiểu, các CPA phải hỗ trợ lên tới 2K (2048) byte của bộ nhớ để lưu trữ bản ghi EMV nếu
các ứng dụng hỗ trợ tùy chọn triển khai RSA động.
• Ở mức tối thiểu, các CPA phải hỗ trợ lên đến 1.5K (1536) byte của bộ nhớ để lưu trữ bản ghi EMV
nếu ứng dụng không hỗ trợ tùy chọn triển khai RSA động.
• Việc này là một tùy chọn bên phát hành để lưu trữ các bản ghi EMV trong bất kỳ tập tin với một SFI từ
1 đến 10 (ví dụ,bản ghi có thể được lưu trữ trong SFI 1 và 2; hoặc trong SFI 1, 3, và 4; hoặc trong SFI
5, 6, 8, 9).
• Ở mức tối thiểu, các CPA phải hỗ trợ lên đến tổng cộng 16 bản ghi cho dữ liệu EMV.
• Việc này là một tùy chọn bên phát hành để đặt tối đa 16 bản ghi trong bất kỳ tập tin với SFI tù 1 đến
10, với tổng số bản ghi là nhỏ hơn hoặc bằng số lượng tối đa của các bản ghi được hỗ trợ bởi ứng
dụng (ví dụ, hai bản ghi trong tập 1, ba bản ghi trong tập 2 v..v.).
• Việc này là một tùy chọn bên phát hành yêu cầu bản ghi với chiều dài kỷ lục lên tới 254 byte
Nói cách khác, trong bất kỳ việc triển khai nào của CPA, việc phân bổ dữ liệu EMV đến tệp tin và bản
ghi có thể được thực hiện trong bất kỳ tệp tin nào với SFI từ 1 đến 10 và bất kỳ bản ghi nào, cung cấp:
• Tổng bộ nhớ cho các bản ghi cần thiết là ít hơn hoặc bằng:
▪ 2048 (2K) byte nếu tùy chọn triển khai RSA Động được hỗ trợ
▪ 1536 (1.5K) byte nếu tùy chọn triển khai RSA Động không được hỗ trợ
• Tổng số lượng bản ghi là nhỏ hơn hoặc bằng 16
• Chiều dài của bản ghi là nhỏ hơn hoặc bằng 254 byte, bao gồm các byte thẻ tag ‘70’ và các byte
chiều dài.
Triển khai có thể hỗ trợ:
• Nhiều hơn tối thiểu 2048 hoặc 1536 byte
• Nhiều hơn 16 bản ghi trong tổng số tất cả các tập tin với SFI giữa 1 và 10
- Như ngụ ý trước đó, một số hiện thực phải hỗ trợ trên yêu cầu mà không cần phải chuẩn bị thẻ trước
khi cá nhân hóa để đáp ứng tổ chức dữ liệu của một bên phát hành cần trong khi hiện thực khác phải
cần phải được tùy chỉnh trước khi cá thể hóa.
7.1.2. Các phần tử Dữ liệu CPA đòi hỏi cá thể hóa
Bất kỳ giá trị nào của AID và FCI được phép bởi EMV có thể được chọn bởi bên phát hành. Việc cá thể
hóa FCI khi EMV CPS được sử dụng như mô tả tại Điều 6.2.
Req 6.7.2 (Cá thể hóa cho hồi đáp SELECT):
Các phần tử dữ liệu được liệt kê trong Bảng 1 có thể được thiết lập trong khi chẩm bị cá thể hóa hoặc
đang cá thể hóa, để bất kỳ giá trị được chọn bởi bên phát hành được cho phép trong EMV.
Bảng 1 - Phần tử dữ liệu hồi đáp lệnh SELECT - Bắt buộc
Tag Tên phần tử dữ liệu Kích cỡ (byte) Định dạng
‘84’ AID (trả về trong hồi đáp lệnh SELECT) var. 5-16 nhị phân
‘6F’ FCI var. lên đến 240 nhị phân
Các phần tử dữ liệu Tham số Lệnh, Hạn mức lần thử mã PIN, Lịch sử Giao dịch Trước đó, và Dữ liệu
Vòng đời bên Phát hành ứng dụng chỉ yêu cầu thẻ tag khi các phần tử dữ liệu được cá thể hóa bằng
tùy chọn bên triển khai EMV CPS.
Nếu tùy chọn bên triển khai EMV CPS không được hỗ trợ, tài liệu đặc tả kỹ thuật này không đòi hỏi các
phần tử dữ liệu được gắn thẻ tag, và không đòi hỏi các giá trị được sử dụng cho các thẻ tag kết hợp
với mỗi phần tử dữ liệu.
Req 6.7.3 (Cá thể hóa cho dữ liệu bắt buộc):
Phần tử dữ liệu được liệt kê trong Bảng 2 phải được cá thể hóa cho CPA
Bảng 2 - Phần tử Dữ liệu bền vững CPA đơn nhất - Bắt buộc
Tag Tên phần tử Dữ liệu Kích cỡ (bytes) Định dạng
‘C1’ Kiểm soát Ứng dụng 4 nhị phân
‘C8’ Dữ liệu Vòng đời bên Phát hành Ứng dụng 20 nhị phân
‘9F10’ Dữ liệu Ứng dụng bên Phát hành 32 nhị phân
‘5F28’ Mã nước bên Phát hành 2 n3
— Khóa chính cho SMC 16 nhị phân
— Khóa chính cho SMI 16 nhị phân
— Khóa chính cho AC 16 nhị phân
Req 6.7.4 (Cá thể hóa cho dữ liệu tùy chọn bên phát hành):
Phần tử dữ liệu được liệt kê trong Bảng 3 phải được cá thể hóa cho CPA nếu điều kiện là đúng.
Bảng 3 - Phần tử Dữ liệu bền vững CPA đơn nhất - Tùy chọn bên phát hành
Tên phần tử Dữ Kích cỡ Định
Tag Điều kiện
liệu (bytes) dạng
- Mã PIN tham khảo nếu bên phát hành hỗ trợ mã 8 nhị phân
PIN ngoại tuyến
‘9F17’ Bộ đếm lần thử mã nếu bên phát hành hỗ trợ mã 1 nhị phân
PIN PIN ngoại tuyến, và muốn Bộ
đếm Lần thử mã PIN bắt đầu
một giá trị khác với Hạn mức
lần thử mã PIN
‘9F36’ Bộ đếm Giao dịch Nếu bên phát hành lựa chọn 2 nhị phân
Ứng dụng (ATC) hạn mức số lần giao dịch trong
vòng đời của thẻ nhỏ hơn 65
535.
- ‘C2’ Mục nhập Tệp tin Nếu lựa chọn hồ sơ được kích 2 nhị phân
Lựa chọn Hồ sơ hoạt cho ứng dụng
‘C3’ Hạn mức số ngày Nếu Số ngày Kiểm tra ngoại 2 n4
ngoại tuyến tuyến được kích hoạt cho bất kỳ
hồ sơ đã cá thể hóa trong ứng
dụng
‘C6’ Hạn mức lần thử nếu bên phát hành hỗ trợ mã 1 nhị phân
mã PIN PIN ngoại tuyến
‘C7’ Lịch sử Giao dịch nếu bên phát hành lựa chọn gửi 2 nhị phân
Trước đây trực tuyến thẻ mới
Req 6.7.5 (Cá thể hóa cho dữ liệu khóa đối với DDA/CDA):
Nếu trong bất kỳ hồ sơ cho các ứng dụng, các bên phát hành cá thể hóa thẻ để hỗ trợ DDA hay CDA,
thì các Phần tử Khóa Bí mật ICC được cá nhân hóa.
Req 6.7.6 (Cá thể hóa cho dữ liệu khóa bí mật ICC đối với mã PIN đã mã hóa):
Nếu trong bất kỳ hồ sơ cho các ứng dụng, các bên phát hành cá thể hóa thẻ để hỗ trợ mã PIN đã mã
hóa ngoại tuyến bằng cách sử dụng cặp khóa ICC Công khai/Bí mật, thì các phần tử khóa bí mật ICC
được cá nhân hóa.
Req 6.7.7 (Cá thể hóa cho dữ liệu khóa mã hóa mã PIN ICC đối với mã PIN đã mã hóa):
Nếu trong bất kỳ hồ sơ cho các ứng dụng, các bên phát hành cá thể hóa thẻ để hỗ trợ mã PIN đã mã
hóa ngoại tuyến bằng cách sử dụng cặp khóa ICC Công khai / Bí mật, thì các phần tử khóa bí mật mã
hóa mã PIN ICC được cá nhân hóa.
Bảng 4 - Phần tử Dữ liệu bền vững CPA đơn nhất - phần tử tùy chọn RSA động
Tag bản Kích cỡ
Tag # Tên phần tử Dữ liệu Định dạng
mẫu (bytes)
- - Phân tử Khóa Riêng ICC var. nhị phân
Phân tử Khóa Riêng mã hóa
- - var. nhị phân
mã PIN ICC
Req 6.7.8 (Cá thể hóa cho dữ liệu ghi log giao dịch):
Nếu trong bất kỳ hồ sơ cho các ứng dụng, các bên phát hành cá thể hóa thẻ để hỗ trợ ghi log giao
dịch, thì phần tử Dữ liệu Nội dung Log phải được cá thể hóa;
Việc này phải là tùy chọn bên phát hành để cá thể hóa bất kỳ Bảng Dữ liệu Log nào được liệt kê trong
Bảng 5.
Bảng 5 - Phần tử Dữ liệu bền vững CPA đơn nhất - phần tử ghi log giao dịch tùy chọn bên phát
hành
Tag bản Kích cỡ Định
Tag # Tên phần tử Dữ liệu
mẫu (bytes) dạng
- ‘9F4D’ Mục nhập Log 2 nhị phân
Bảng Dữ liệu Log lệnh GEN AC lần
‘BF40’ ‘DF01’ 1 + (N * 2) nhị phân
đầu
Bảng Dữ liệu Log không thay đổi của
‘BF40’ ‘DF03’ 1 + (N * 2) nhị phân
lệnh GEN AC lần đầu
‘BF40’ ‘DF02’ Bảng Dữ liệu Log lệnh GEN AC lần hai 1 + (N * 2) nhị phân
Req 6.7.9 (Cá thể hóa cho dữ liệu an ninh tùy chọn):
Nếu tùy chọn Bộ đếm Khóa Phiên được mô tả trong Điều 10 của TCVN 11198-7 và Điều 7 của TCVN
11198-8 được thực hiện, thì Hạn mức Bộ đếm Khóa Phiên trong Bảng 6 phải được cá thể hóa.
Bảng 6 - Phần tử Dữ liệu bền vững CPA đơn nhất - tùy chọn Bộ đếm Khóa Phiên
- Tag bản Kích cỡ
Tag # Tên phần tử Dữ liệu Định dạng
mẫu (bytes)
- ‘C5’ Hạn mức An ninh 6 nhị phân
Req 6.7.10 (Cá thể hóa cho dữ liệu VLP có điều kiện):
Phần tử dữ liệu được liệt kê trong Bảng 1 phải được cá thể hóa cho CPA nếu tùy chọn bên triển khai
VLP được hỗ trợ và kích hoạt.
Bảng 7 - Phần tử Dữ liệu bền vững CPA đơn nhất - Phần tử VLP có điều kiện
Tag bản Kích cỡ
Tag # Tên phần tử Dữ liệu Định dạng
mẫu (bytes)
- ‘9F77’ Hạn mức Quỹ VLP 6 n 12
- ‘9F42’ Mã Tiền Ứng dụng 2 n3
Req 6.7.11 (Cá thể hóa cho dữ liệu VLP tùy chọn):
Phần tử dữ liệu được liệt kê trong Bảng 8 phải được cá thể hóa cho CPA nếu tùy chọn bên triển khai
VLP được hỗ trợ và kích hoạt, các điều kiện sau là đúng.
Bảng 8 - Phần tử Dữ liệu bền vững CPA đơn nhất - Phần tử VLP tùy chọn bên phát hành
Tên phần tử Dữ Kích cỡ
Tag# Điều kiện Định dạng
liệu (bytes)
‘9F78’ Hạn mức Giao dịch nếu bên phát hành hạn mức 6 n 12
Đơn VLP giá trị cho từng giao dịch VLP
Req 6.7.12 (Cá thể hóa cho dữ liệu bản mẫu CPA):
Phần tử dữ liệu được liệt kê trong Bàng 9 phải được cá thể hóa cho CPA nếu các điều kiện sau là
đúng.
Bảng 9 - Phần tử Dữ liệu bền vững CPA - Tập dữ liệu
Tag bản Tên phần tử Dữ Kích cỡ Định
Tag # Điều kiện
mẫu liệu (bytes) dạng
Mục nhập
nếu lựa chọn hồ sơ
- - Lựa chọn được kích hoạt cho var. bản ghi
ứng dụng
Hồ sơ
‘DF01-’ Dữ liệu Thanh
DF0n’, tổng: N * (18
‘BF30’ luôn luôn (ít nhất một) dạng số
‘DF11-‘ giá trị (‘DF0x’) và hoặc 30)
DF1n’ hạn mức (‘DF1x’)
Kiểm soát
‘DF01’-‘ nhị
‘BF31’ Hồ sơ luôn luôn (ít nhất một) N*2
DF0n’ phân
Thanh tổng
‘DF01’-‘ Kiểm soát Thanh nhị
‘BF32’ luôn luôn (ít nhất một) N*3
DF0n’ tổng x phân
nếu bất kỳ Kiểm tra
bảng kiểm tra bổ sung
‘DF01’-‘ Bảng Kiểm tra Bổ nào được kích hoạt nhị
‘BF33’ N * var.
DF0n’ sung cho bất kỳ hồ sơ đã cá phân
thể hóa trong ứng
dụng
‘BF34’ ‘DF01’ - Mục nhập CIAC luôn luôn (ít nhất một) N * 18 nhị
‘DF0n’ (CIAC-Decline, phân
CIAC-Online, và
- CIAC-Default)
‘DF01’-‘
Dữ liệu Bộ đếm:
DF0n’, N * (3
‘BF35’ giá trị (‘DF0x’) và luôn luôn (ít nhất một) dạng số
‘DF11’ - hoặc 5)
Hạn mức (‘DF1x’)
‘DF1n’
‘DF01’ - Kiểm soát Hồ sơ nhị
‘BF36’ luôn luôn (ít nhất một) N*1
‘DF0n’ Bộ đếm phân
‘DF01’ - Kiểm soát Bộ đếm nhị
‘BF37’ luôn luôn (ít nhất một) N*1
‘DF0n’ x phân
Bảng 9 - Phần tử Dữ liệu bền vững CPA - Tập dữ liệu (kết thúc)
Điều Kích cỡ Kích cỡ Định
Định dạng Điều kiện
kiện (bytes) (bytes) dạng
nếu quy đổi tiền tệ
được phép trong một
Kiểm tra Lượng tiền
Giao dịch Tối đa, bất
kỳ Kiểm tra Thanh
‘DF01’ - Bảng Quy đổi N * (2 +
‘BF38’ tổng x nào, hoặc bất nhị phân
‘DF0n’ Tiền tệ (n*5))
kỳ Kiểm tra Thanh
tổng Chu Kỳ x nào
đang kích hoạt cho bất
kỳ hồ sơ đã cá thể hóa
trong ứng dụng
Nếu bất kỳ Thanh tổng
Kiểm soát
Chu kỳ x được kích
‘DF01’ - Hồ sơ
‘BF39’ hoạt cho bất kỳ hồ sơ N*2 nhị phân
‘DF0n’ Thanh tổng
đã cá thể hóa trong
Chu kỳ
ứng dụng
Nếu bất kỳ Thanh tổng
Kiểm soát Chu kỳ x được kích
‘DF01’ -
‘BF3A’ Thanh tổng hoạt cho bất kỳ hồ sơ N*3 nhị phân
‘DF0n’
Chu kỳ x đã cá thể hóa trong
ứng dụng
Kiểm soát Hồ luôn luôn (ít nhất một)
‘DF01’ -
‘BF3B’ sơ Tùy chọn N*7 nhị phân
‘DF0n’
bên Phát hành
nếu Kiểm tra Lượng
tiền Giao dịch Tối đa,
bất kỳ Kiểm tra Thanh
‘DF01’ - Mục nhập Hạn
‘BF3C’ tổng Chu kỳ x nào N*6 n 12
‘DF0n’ mức
đang kích hoạt cho bất
kỳ hồ sơ đã cá thể hóa
trong ứng dụng
nếu Kiểm tra Lượng
Kiểm soát Hồ
tiền Giao dịch Tối đa
‘DF01’-‘D sơ Lượng tiền
‘BF3D’ đang kích hoạt cho bất N*4 nhị phân
F0n’ Giao dịch Tối
kỳ hồ sơ đã cá thể hóa
đa
trong ứng dụng
‘DF01’-‘D luôn luôn (ít nhất một)
‘BF3E’ Tham số GPO N*2 nhị phân
F0n’
‘DF01’-‘D Kiểm soát Hồ luôn luôn (ít nhất một)
‘BF3E’ N*8 nhị phân
F0n’ sơ
- ‘DF01’ - Mục nhập luôn luôn (ít nhất một) N*
‘BF41’ nhị phân
‘DF0n’ AIP/AFL (2+1+61)
Req 6.7.13:
Từng Tham số Quy đổi Tiền tệ trong một Bảng Quy đổi Tiền tệ phải có chứa phần tử dữ liệu được liệt
kê trong Bảng 10.
Bảng 10 - Tham số Quy đổi Tiền tệ
Dữ liệu Chiều Mô tả
dài
Mã Tiền tệ 2 Các mã tiền tệ của lượng tiền được quy đổi sang lượng
Nguồn tiền được xác định bởi các Mã Tiền Đích cho thanh tổng
đang sử dụng tham số quy đổi tiền tệ này
Tỷ lệ Quy đổi 2 Tỷ lệ (sử dụng với các số mũ Quy đổi) nhân với các giá trị
lượng tiền giao dịch ra gần đúng giá trị giao dịch trong
lượng tiền thanh tổng
Số mũ Quy đổi 1 Một số có dấu mà chỉ ra số mũ của 10 được sử dụng để
thay đổi Tỷ lệ Quy đổi. Bít b8 chỉ ra các dấu của số mũ, và
bit b7 đến b1 cho biết giá trị của số mũ.
Nếu là dấu dương (b8 = 0b):
Giá trị gần đúng =
Số tiền giao dịch * Tỷ lệ Quy đổi
* 10 Số mũ Quy đổi (b7 để b1)
Nếu là dấu âm (b8 = 1b):
Giá trị gần đúng =
Số tiền giao dịch * Tỷ lệ Quy đổi)
/ 10 Số mũ Quy đổi (b7 để b1)
Các byte điền đầy được phép trong dữ liệu cá thể hóa cho các bản ghi có chứa Mục nhập Lựa chọn hồ
sơ.
Các byte điền đầy được phép trong dữ liệu cá thể hóa cho bản mẫu được liệt kê trong Bảng 9.
CHÚ THÍCH: EMV sử dụng giá trị ‘00’ cho các byte điền đầy.
7.1.3. Triển khai Mặc định CPA
Bảng 11 cho biết số lượng tối thiểu và tối đa của từng loại tài nguyên hồ sơ có thể được thực hiện
trong CPA. Cột “Min #” chỉ ra các số lượng tối thiểu của từng loại tài nguyên hồ sơ phải được hỗ trợ
trong bất kỳ thực hiện CPA. Cột “Max #” cho biết số lượng tối đa từng loại tài nguyên hồ sơ mà có thể
được thực hiện, do thiết kế hạn chế (chẳng hạn như hạn mức trên dải thẻ tag).
Bên phát hành chọn lựa bao nhiêu cho mỗi loại tài nguyên hồ sơ được sử dụng trong một ứng dụng
sau khi cá thể hóa, phụ thuộc vào thiết kế hồ sơ và hành động hồ sơ của bên phát hành. Bên phát
hành thiết kế hồ sơ của họ để sử dụng không nhiều hơn số lượng tối thiểu của bất kỳ loại tài nguyên
hồ sơ phải có thể cá thể hóa ứng dụng của họ trên bất kỳ triển khai CPA nào. Bên phát hành thiết kế
hồ sơ của họ để sử dụng nhiều hơn số lượng tối thiểu của bất kỳ loại tài nguyên hồ sơ nào phải cần
đảm bảo việc triển khai CPA họ chọn hỗ trợ số lượng bổ sung các loại tài nguyên hồ sơ.
Req 6.7.14 (Số lượng tối đa/tối thiểu để hỗ trợ dữ liệu tài nguyên hồ sơ):
Tại điểm tối thiểu, việc triển khai CPA phải hỗ trợ ít nhất một số tối thiểu các phần tử dữ liệu Thanh
tổng, Bộ đếm và Dữ liệu Thanh tổng Chu kỳ được chỉ ra trong Bảng 11.
Req 6.7.15 (Số lượng tối đa/tối thiểu để hỗ trợ dữ liệu tài nguyên hồ sơ):
Tại điểm tối thiểu, việc triển khai CPA phải có khả năng thực hiện cá thể hóa với số lượng tối thiểu từng
loại tài nguyên hồ sơ đã liệt kê trong Bảng 11.
- Bảng 11 - Số lượng từng loại Tài nguyên Hồ sơ trong CPA
tag bản Chiều dài Min
Tài nguyên Hồ sơ Max #
mẫu (bytes) #
Thanh tổng - 6 2 14
Kiểm soát Thanh tổng ‘BF32’ 3 2 14
Tag ‘DF0x’ = Kiểm soát Thanh tổng x
Kiểm soát Hồ sơ Thanh tổng ‘BF31’ 2 6 14
Tag ‘DF0x’ = Kiểm soát Hồ sơ Thanh tổng x
Dữ liệu Thanh tổng ‘BF30’ 18 2 14
Tag ‘DF0x’ = giá trị Thanh tổng x hoặc
Tag ‘DF1x’ = Hạn mức Thanh tổng x 30
Bảng kiểm tra Bổ sung ‘BF33’ Var. 2 14
Tag ‘DF0x’ = Bảng kiểm tra Bổ sung x
các mục AIP/AFL ‘BF41’ Var. 6 14
Tag ‘DF0x’ = Mục AIP/AFL x
các mục CIAC ‘BF34’ 18 6 14
Tag ‘DF0x’ = Mục CIAC x
Bảng Dữ liệu Log ‘BF40’ Var. 1 1
Tag ‘DF01’ = Bảng Dữ liệu Log GEN AC lần Var. 1 1
đầu
Var. 1 1
Tag ‘DF02’ = Bảng Dữ liệu Log GEN AC lần hai
Tag ‘DF03’ = Bảng Dữ liệu Log hông thay đổi
GEN AC lần đầu
Kiểm soát Hồ sơ MTA ‘BF3D’ 4 6 14
Tag ‘DF0x’ = Kiểm soát Hồ sơ MTA x
Kiểm soát Hồ sơ ‘BF3E’ Nhỏ nhất 8 126
8
Tag ‘DFx’ = Kiểm soát Hồ sơ x
7.2. EMV CPS
Hỗ trợ cho Tài liệu Đặc tả Cá thể hóa thẻ EMV (CPS) là một tùy chọn bên triển khai CPA. Đối với thẻ
có hỗ trợ tùy chọn triển khai CPS, định dạng cho dữ liệu cá thể hóa có thể phù hợp khi triển khai với
cùng dữ liệu cá thể hóa. Các yêu cầu cho điều này được áp dụng khi ứng dụng được cá thể hóa sử
dụng EMV CPS như một phương thức cá thể hóa.
7.2.1. Lệnh Cá thể hóa
7.2.1.1. Tổng quan
Lệnh APDU được quy định tại Tài liệu Đặc tả Cá thể hóa thẻ EMV (CPS), Chương 3. Một kiểu cá thể
hóa điển hình bao gồm những lệnh sau đây theo trình tự thể hiện:
• SELECT;
• INITIALIZE UPDATE;
• EXTERNAL AUTHENTICATE ;
• STORE DATA.
7.2.1.2. Lệnh SELECT
Lệnh SELECT được sử dụng lựa chọn từng ứng dụng thẻ IC để cá thể hóa. Việc lựa chọn ứng dụng
được mô tả trong EMV Quyển 1.
- Lệnh SELECT phải được phát hành 1 lần cho từng ứng dụng thẻ IC để cá thể hóa. Dữ liệu trong FCI
(hồi đáp cho lệnh SELECT) được thay đổi trong quy trình cá thể hóa. Điều này không là yêu cầu cụ thể
đối với phần trước khi cá thể hóa, hoặc khác hơn yêu cầu trả về thẻ tag AID (84) với chiều dài và giá
trị.
7.2.1.3. Lệnh INITIALIZE UPDATE
Lệnh INITIALIZE UPDATE là lệnh đầu tiên được phát hành sau khi thiết bị cá thể hóa lựa chọn ứng
dụng. Lệnh INITIALIZE UPDATE phải bắt đầu thiết lập Phiên Kênh Bí mật để sử dụng trong khi cá thể
hóa. Dữ liệu để thực hiện xác thực lẫn nhau được trao đổi.
Tham khảo EMV CPS về định nghĩa chi tiết của lệnh INITIALIZE UPDATE
7.2.1.4. Lệnh EXTERNAL AUTHENTICATE
Lệnh EXTERNAL AUTHENTICATE theo sau lệnh INITIALIZE UPDATE và được sử dụng để xác thực
thiết bị cá thể hóa cho ứng dụng thẻ IC. Lệnh EXTERNAL AUTHENTICATE phải được phát hành một
lần cho từng bắt đầu kênh bí mật và phải được phát hành tại ít nhất một lần cho mỗi ứng dụng để cá
thể hóa.
Tham khảo EMV CPS về định nghĩa chi tiết của lệnh EXTERNAL AUTHENTICATE.
Ứng dụng CPA phải hỗ trợ ba mức an ninh bên dưới cho EMV CPS:
• Không an ninh - Kênh bí mật được thiết lập chỉ cho mục đích xác thực
• MAC - kênh bí mật được thiết lập với mục đích toàn vẹn cũng như xác thực
• Mã hóa và MAC - kênh bí mật được thiết lập cho mục đích bí mật và toàn vẹn cũng như xác thực.
7.2.1.5. Lệnh STORE DATA
Lệnh STORE DATA được sử dụng để gửi dữ liệu cá thể hóa đến ứng dụng thẻ. Quy trình chuẩn bị dữ
liệu tổ chức dữ liệu cá thể hóa để gửi vào trong nhóm dữ liệu. Nhận diện Nhóm Dữ liệu (DGI) chỉ ra
từng nhóm dữ liệu, ứng dụng thẻ IC thì sử dụng DGI để xác định cách thức nhóm dữ liệu để xử lý.
Tham khảo EMV CPS về định nghĩa lệnh STORE DATA.
Req 6.7.16 (Bỏ qua giá trị P1 trong Lệnh STORE DATA):
Giá trị P1 trong mào đầu lệnh STORE DATA phải bị bỏ qua ngoại trừ bit thứ tự cao, được sử dụng để
chỉ ra Lệnh STORE DATA cuối cùng.
Req 6.7.17 (Bỏ qua giá trị P2 trong Lệnh STORE DATA):
Giá trị P21 trong mào đầu lệnh STORE DATA phải bị bỏ qua.
Hỗ trợ cho một DGI duy nhất thông qua hai Lệnh STORE DATA là cần thiết để cá nhân hóa một hồ sơ
có chứa một Chứng chỉ bên phát hành với kích thước khóa CA là 1984 bit, và các thẻ mẫu mà có thể
tràn chiều dài của trường dữ liệu lệnh trong một Lệnh STORE DATA. Hỗ trợ của nhiều DGI trong một
lệnh STORE DATA này có thể giảm số lượng các lệnh cần thiết, và có thể là thời gian cá thể hóa. Lệnh
STORE DATA hỗ trợ nhiều DGI không phải cũng có thể phân nhịp DGI cuối cùng trên lệnh STORE
DATA thứ hai.
Req 6.7.18 (Hỗ trợ nhiều DGI trong lệnh STORE DATA):
Một lệnh STORE DATA đơn phải hỗ trợ nhiều DGI.
Req 6.7.19 (Hỗ trợ phân nhịp DGI nhiều lệnh STORE DATA):
Ứng dụng phải hỗ trợ bất kỳ phân nhịp DGI đơn cho hai lệnh STORE DATA.
Req 6.7.20 (Chiều dài DGI trong lệnh STORE DATA):
Ứng dụng phải hỗ trợ chri chiều dài DGI đơn byte.
Req 6.7.21 (Định dạng TLV cho dữ liệu trong DGI):
Tất cả phần tử dữ liệu gán thẻ tag phải được nhập trong DGI trong định dạng TLV, và ứng dụng phải
chấp nhận phần tử dữ liệu gán thẻ tag trong bất kỳ thứ tự bên trong DGI cụ thể.
7.2.2. Quy tắc Nhóm Dữ liệu
Quy tắc để tạo nhóm dữ liệu được định nghĩa trong EMV CPS Điều 2.2 và tham khảo Chương 3 về
- định nghĩa Nhóm Dữ liệu yêu cầu cá thể hóa cho CPA.
7.2.3. Thứ tự Nhóm Dữ liệu
Điều này được khuyến nghị rằng bên phát triển ứng dụng cho phép Nhóm Dữ liệu được gửi đến ứng
dụng CPA theo bất kỳ thứ tự nào. Tuy nhiên trong môt số triển khai tồn tại ràng buộc theo cách mà
Nhóm Dữ liệu được xếp thứ tự.
Bên phát triển Ứng dụng và Chuẩn bị Dữ liệu phải đảm bảo rằng bất kỳ ràng buộc cụ thể khi triển khai
nào là được tôn trọng.
7.2.4. Nhóm dữ liệu đã nhóm
Khuyến nghị đối với bên phát triển ứng dụng hỗ trợ bất kỳ việc nhóm các Nhóm Dữ liệu, với mở rộng
Nhóm Dữ liệu chỉ ra trong trường kiểm soát phiên bản (VERCNTL) trong Dữ liệu ứng dụng Thẻ IC. Tuy
nhiên, trong một số triển khai có thể có ràng buộc với cách thức nhóm các Nhóm Dữ liệu.
Bên phát triển ứng dụng và Chuẩn bị Dữ liệu phải đảm bảo rằng bất kỳ ràng buộc cụ thể khi triển khai
nào đều được tôn trọng.
Cột yêu cầu có tiêu đề “Req.” trong các bảng tiếp theo về các phần tử dữ liệu cho từng DGI, liệt kê các
yêu cầu cho từng phần tử dữ liệu:
• M (bắt buộc) chỉ ra rằng các phần tử dữ liệu phải có mật;
• C (có điều kiện) chỉ ra rằng các phần tử dữ liệu là cần thiết trong một số điều kiện;
• O (Tùy chọn) chỉ ra rằng các phần tử dữ liệu là tùy chọn.
7.2.5. DGI cho Dữ liệu Bản ghi
Đối với ứng dụng EMV, các yếu tố liên tục dữ liệu được lưu trữ trong các tập tin với một SFI từ 1 đến
30, được lưu trữ trong bản ghi và có thể phục hồi được với lệnh Bản ghi Đọc EMV. Một bản ghi luôn là
giá trị của một Nhóm Dữ liệu.
Trong khi cá thể hóa, các ứng dụng nhận được một loạt các lệnh STORE DATA tương ứng với giá trị
bản ghi và thì lưu trữ các giá trị bản ghi trong bản ghi. Các ứng dụng phải có bộ nhớ lâu dài có sẵn để
lưu trữ bản ghi như vậy, bằng cách sử dụng một trong các phương pháp sau đây:
• Các tiền phân bổ bộ nhớ và cấu trúc tập tin;
• Việc phân bổ bộ nhớ và cấu trúc tệp tin trong khi cá thể hóa.
Các Nhóm Dữ liệu được cấp phát cho các giá trị bản ghi đối với Định danh Nhóm Dữ liệu trong dãy
‘XXYY’, tại đó ‘XX’ chỉ ra SFI và ‘YY’ chỉ ra số hiệu bản ghi như sau:
• ‘01’
- Do đó có mười tập tin (rong các bản ghi EMV có thể được lưu trữ. Mỗi tập tin có thể chứa lên đến 255
bản ghi. Tuy nhiên, các ứng dụng CPA không tiếp cận những hạn mức này.
7.2.7. Tệp tin với SFI giữa 11 và 30
Các nhóm dữ liệu được dành riêng cho các giá trị kỷ lục EMV cho dữ liệu Phản nhóm Định danh với
một giá trị của ‘XX’ ’,trong đó:
• ‘SFI ‘0B’
- M ‘9F1F’ Rãnh 1 Dữ liệu Tự do Var. N/A
Bảng 15 - Nội dung Dữ liệu đối với DGI ‘0201’
Req. Tag Phần tử Dữ liệu Điều kiện Chiều dài Mã hóa
C ‘90’ Chứng chỉ Khóa Nếu SDA, DDA, CDA, Var. N/A
công khai bên hoặc mã PIN đã mã
Phát hành (IPK) hóa ngoại tuyến được
hỗ trợ
Bảng 16 - Nội dung Dữ liệu đối với DGI ‘0202’
Phần tử Dữ Chiều
Req. Tag Điều kiện Mã hóa
liệu dài
C ‘9F32’ IPK số mũ Nếu SDA, DDA, CDA, hoặc mã 1 hoặc N/A
PIN đã mã hóa ngoại tuyến được 3
hỗ trợ
C ‘92’ IPK còn lại Nếu SDA, DDA, CDA, hoặc mã Var N/A
PIN đã mã hóa ngoại tuyến được
hỗ trợ và các mục IPK không hợp
với Chứng chỉ IPK
C ‘8F’ Chỉ mục Chứng Nếu SDA, DDA, CDA, hoặc mã 1 N/A
chỉ khóa công PIN đã mã hóa ngoại tuyến được
khai được phép hỗ trợ
C ‘9F47’ số mũ Khóa Nếu DDA, CDA, hoặc mã PIN đã 1 hoặc N/A
Công khai ICC mã hóa ngoại tuyến sử dụng 3
Khóa Công khai ICC được hỗ trợ
C ‘9F48’ Khóa Công Nếu DDA, CDA, hoặc mã PIN đã Var N/A
khai ICC còn lại mã hóa ngoại tuyến sử dụng
Khóa Công khai ICC được hỗ trợ
và các mục IPK không hợp với
Chứng chỉ IPK
C ‘9F49’ DDOL Nếu DDA hoặc CDA được hỗ trợ 3 N/A
C ‘9F2E’ số mũ Khóa Nếu mã PIN đã mã hóa ngoại Var N/A
Công khai mã tuyến sử dụng Khóa Công khai
hóa mã PIN mã hóa mã PIN ICC được hỗ trợ
ICC
C ‘9F2F’ Khóa Công Nếu mã PIN đã mã hóa ngoại Var N/A
khai mã hóa tuyến sử dụng Khóa Công khai
mã PIN ICC mã hóa mã PIN ICC được hỗ trợ
còn lại và các mục PK mã hóa mã PIN
ICC không hợp với Chứng chỉ PK
mã hóa mã PIN ICC
Bảng 17 - Nội dung Dữ liệu đối với DGI ‘0203’
Chiều
Req. Tag Phần tử Dữ liệu Điều kiện Mã hóa
dài
C ‘93’ Dữ liệu Ứng dụng nếu SDA được hỗ trợ Var. N/A
Tĩnh có dấu
Bảng 18 - Nội dung Dữ liệu đối với DGI ‘0204’
Chiều
Req. Tag Phần tử Dữ liệu Điều kiện Mã hóa
dài
C ‘9F46’ ICC Chứng chỉ Nếu DDA, CDA, hoặc mã Var. N/A
khóa công khai PIN đã mã hóa ngoại
tuyến sử dụng Khóa
- Công khai ICC được hỗ
trợ
Bảng 19 - Nội dung Dữ liệu đối với DGI ‘0205’
Req. Tag Phần tử Dữ liệu Điều kiện Chiều dài Mã hóa
C ‘9F2D’ Chứng chỉ Khóa Nếu mã PIN đã mã Var. N/A
Công khai mã hóa hóa ngoại tuyến sử
mã PIN ICC dụng Khóa Công khai
mã hóa mã PIN ICC
được hỗ trợ
Bảng 20 - Nội dung Dữ liệu đối với DGI ‘020n’
Chiều
Req. Tag Phần tử Dữ liệu Điều kiện Mã hóa
dài
C ‘90’ Chứng chỉ ICK Nếu DDA, CDA, hoặc mã Var. N/A
PIN đã mã hóa ngoại tuyến
sử dụng Khóa Công khai
ICC được hỗ trợ và chứng
nhận đa bên thì có thể được
cá thể hóa
C ‘8F’ Chỉ mục Chứng Nếu DDA, CDA, hoặc mã 1 N/A
chỉ khóa công PIN đã mã hóa ngoại tuyến
khai được phép sử dụng Khóa Công khai
ICC được hỗ trợ và chứng
nhận đa bên thì có thể được
cá thể hóa
C ‘9F32’ IPK số mũ Nếu DDA, CDA, hoặc mã 1 hoặc 3 N/A
PIN đã mã hóa ngoại tuyến
sử dụng Khóa Công khai
ICC được hỗ trợ và chứng
nhận đa bên thì có thể được
cá thể hóa
C ‘92’ IPK còn lại Nếu DDA, CDA, hoặc mã Var N/A
PIN đã mã hóa ngoại tuyến
sử dụng Khóa Công khai
ICC được hỗ trợ và mục
nhập IPK không điền đầy
chứng chỉ IP và chứng nhận
đa bên thì có thể được cá
thể hóa
C ‘93’ Dữ liệu ứng dụng Nếu SDA được hỗ trợ và Var. N/A
Tĩnh có dấu chứng nhận đa bên thì có
thể được cá thể hóa
Bảng 21 - Nội dung Dữ liệu đối với DGI ‘0301’
Chiều
Req. Tag Phần tử Dữ liệu Điều kiện Mã hóa
dài
M ‘5F24’ Ngày Hết hạn Ứng dụng luôn luôn 3 N/A
O ‘5F25’ Ngày Hiệu lực Ứng dụng tùy chọn 3 N/A
M ‘5A’ Số tài khoản cơ bản(PAN) luôn luôn Var N/A
O ‘5F34’ Số chuỗi PAN ứng dụng tùy chọn 1 N/A
Kiểm soát Lưu lượng Sử
O ‘9F07’ tùy chọn 2 N/A
dụng Ứng dụng
- Danh sách Đối tượng Dữ
M ‘8C’ liệu Quản lý Rủi ro Thẻ 1 luôn luôn Var N/A
(CDOL1)
Danh sách Đối tượng Dữ
M ‘8D’ liệu Quản lý Rủi ro Thẻ 2 luôn luôn Var N/A
(CDOL2)
Nếu Xác minh chủ
Danh sách Phương thức
M ‘8E' thẻ được thực hiện Var N/A
Xác minh Chủ thẻ (CVM)
cho mọi hồ sơ
M ‘9F0D’ IAC Mặc định luôn luôn 5 N/A
M ‘9F0E’ IAC Từ chối luôn luôn 5 N/A
M ‘9F0F’ IAC Ngoại tuyến luôn luôn 5 N/A
Nếu bit ‘bao gồm
chỉ nếu quốc tế’
được cá thể hóa
C ‘5F28’ mã nước bên phát hành thành 1b trong mọi 2 N/A
Kiểm soát Hồ sơ
bộ đếm kích hoạt
cho ứng dụng
C ‘9F4A’ danh sách thẻ tag SDA nếu AIP có dấu 1 N/A
CHÚ THÍCH 1: Phần tử dữ liệu trong DGI ‘0301’ này được bao gồm trong Dữ liệu ứng dụng có dấu
(SAD). Nếu cập nhật đến Danh sách CVM được tạo bởi bên Phát hành sử dụng Quy trình xử lý Tập
lệnh bên Phát hành hoặc nếu nhiều danh sách CVM được sử dụng và một SAD đơn được sử dụng,
Danh sách CVM phải được gộp trong DGI 0303 hơn là trong DGI 0301.
CHÚ THÍCH 2: AIP bao gồm trong Dữ liệu ứng dụng có dấu (SAD) không gộp trong dữ liệu bản ghi bởi
vì giá trị này có thể thay đối với hồ sơ đã chọn cho giao dịch.
Bảng 22 - Nội dung dữ liệu đối với DGI ‘0302’
Req. Tag Phần tử Dữ liệu Chiều dài Mã hóa
O ‘9F05’ Dữ liệu Tùy chọn Ứng dụng Var N/A
O ‘9F0B’ Mở rộng tên Chủ thẻ (27-45) Var N/A
C ‘9F44’ Số mũ Tiền Ứng dụng 1 N/A
C ‘9F42’ Mã Tiền Ứng dụng 2 N/A
O ‘5F30’ Mã Dịch vụ 2 N/A
M ‘9F08’ Số phiên bản Ứng dụng 2 N/A
Bảng 23 - Nội dung dữ liệu đối với DGI ‘0303’
Req. Tag Phần tử Dữ liệu Chiều dài Mã hóa
Danh sách Phương thức Xác minh Chủ thẻ
M ‘8E’ Var N/A
(CVM)
DGI ‘0B01’ được sử dụng chỉ khi VLP là được cá thể hóa. Chú ý rằng nhiều phần tử dữ liệu trong bản
ghi này cũng gộp trong các bản ghi khác.
Các phần tử trùng lặp tại đây không được yêu cầu nhưng nó cho phép một danh sách AFL cho VLP để
chứa một ít phần tử và bản ghi.
Bảng 24 - Nội dung Dữ liệu đối với DGI ‘0B01’
Chiều
Req. Tag Phần tử Dữ liệu Điều kiện Mã hóa
dài
Mã Chuẩn chi bên Phát
M ‘9F74’ luôn luôn 6 N/A
hành VLP
- M ‘9F79’ Quỹ Có sẵn VLP luôn luôn 6 N/A
Số Tài khoản chính của nếu một PAN khác
C ‘5A’ Var N/A
Ứng dụng (PAN) sử dụng cho VLP
nếu một Số Chuỗi
C ‘5F34’ Số Chuỗi PAN Ứng dụng PAN khác sử dụng 1 N/A
cho VLP
nếu một CDOL1 khác
C ‘8C’ CDOL1 Var N/A
sử dụng cho VLP
nếu một CDOL2 khác
C ‘8D’ CDOL2 Var N/A
sử dụng cho VLP
nếu một Danh sách
C ‘8E’ Danh sách CVM CVM khác sử dụng Var N/A
cho VLP
nếu một IAC mặc
C ‘9F0D’ IAC mặc định định khác sử dụng 5 N/A
cho VLP
nếu một IAC Từ chối
C ‘9F0E’ IAC từ chối khác sử dụng cho 5 N/A
VLP
nếu một IAC trực
C ‘9F0F’ IAC trực tuyến tuyến khác sử dụng 5 N/A
cho VLP
Nếu một Ngày Hết
hạn ứng dụng khác
C ‘5F24’ Ngày Hết hạn ứng dụng 3 N/A
đang sử dụng cho
VLP
Nếu một Mã nước
bên Phát hành khác
C ‘5F28’ Mã nước bên Phát hành 2 N/A
đang sử dụng cho
VLP
Nếu một AUC khác
Kiểm soát Lưu lượng Sử
C ‘9F07’ đang sử dụng cho 2 N/A
dụng Ứng dụng (AUC)
VLP
O ‘5F25’ Ngày Hiệu lực Ứng dụng Tùy chọn 3 N/A
Nếu một Mã Tiền
C ‘9F42’ MãTiền Ứng dụng Ứng dụng khác đang 2 N/A
sử dụng cho VLP.
O ‘9F08’ Số Phiên bản ứng dụng Tùy chọn 2 N/A
O ‘5F20’ Tên chủ thẻ Tùy chọn 2-26 N/A
Đối với các DGI với byte đầu tiên tương đương với ‘ss’, trong đó ‘ss’ là giá trị của byte đầu tiên của
Mục nhập Tệp tin Lựa chọn Hồ sơ; byte đầu tiên chỉ ra SFI trong đó dữ liệu là được lưu giữ, và byte
thứ hai chỉ ra số hiệu bản ghi bên trong SFI. Dải ‘ss’ trong giá trị từ ‘15’ đến ‘1E’ và dải ‘rr’ có giá trị từ
‘01’ đến ‘0F’.
Bảng 25 - Nội dung Dữ liệu đối với DGI ‘ssrr’
Req. Tag Phần tử Dữ liệu Chiều dài Mã hóa
C - Mục nhập lựa chọn Hồ sơ ‘rr’ var. Không
7.2.9. DGI cho Dữ liệu Ứng dụng Nội bộ
Bảng 26 - Tóm tắt DGI cho Dữ liệu ứng dụng Nội bộ
nguon tai.lieu . vn
