C-APDU của lệnh GENERATE AC được đưa ra trong Bảng 4.8
Bảng 4.8 C-APDU của lệnh GENERATE AC
Mã Giá trị
CLA 80 (Lệnh đặc trưng của EMV) INS AE
P1 Tham số điều khiển liên quan
Bit 8 và bit 7: 00 – AAC, 01 – TC, 10 – ARQC, 11 – RFU Bit 6: 0 – kết hợp hệ DDA/AC không yêu cầu rõ ràng Bit 6: 1 – kết hợp hệ DDA/AC được yêu cầu
Bit 5 đến bit 1: RFU
P2 00
LC Thay đổi: bằng độ dài của trường dữ liệu
Dữ liệu Dữ liệu liên quan của giao dịch: chuỗi byte được tạo thành với những trường giá trị của những đối tượng dữ liệu được liệt kê trong CDOL1 (trong lần đưa ra đầu tiên) hoặc CDOL2 (trong trường hợp đưa ra thứ hai)
4.8.6.1 Dữ liệu liên quan của giao dịch theo CDOL1/CDOL2
Thẻ chỉ ra trong Danh sách đối tượng dữ liệu quản lý rủi ro của thẻ 1 (CDOL1) tập những đối tượng dữ liệu từ môi trường giao dịch của thiết bị đọc mà nó cần xử lý lệnh GENERATE AC đầu tiên. CDOL1 là bắt buộc trong thẻ và nó được lưu trữ với nhãn 8C. Thẻ cũng chỉ ra trong Danh sách đối tượng dữ liệu quản lý rủi ro của thẻ 2 (CDOL2) tập những đối tượng dữ liệu mà nó cần từ thiết bị đọc cho xử lý lệnh GENERATE AC thứ hai. CDOL2 là bắt buộc trong thẻ và được lưu trữ với nhãn 8D.
Trường dữ liệu của C-APDU chứa dữ liệu liên quan đến giao dịch, dữ liệu được tạo thành như một chuỗi byte thô (không được ghi vào TLV) liên kết những trường giá trị của những đối tượng dữ liệu được đưa ra trong cùng CDOL1 hoặc trong CDOL2. Thẻ sử dụng dữ liệu liên quan đến giao dịch cho mục đích sau:
- Thực hiện xử lý quản lý rủi ro của thẻ;
- Xác định xem việc kết hợp DDA/AC có nên được thực hiện không, thậm chí khi không có yêu cầu rõ ràng trong bit 6 của tham số kiểm soát liên quan là P1 của C-APDU;
- Đưa dữ liệu đầu vào để tạo mã hóa thích hợp (TC, ARQC, AAR, hoặc AAC) để làm bằng chứng việc tham gia của thẻ trong một giao dịch liên quan.
Thiết bị đọc sẽ xây dựng dữ liệu liên quan đến giao dịch ngay lập tức trước khi gọi lệnh GENERATE AC, đảm bảo là trường giá trị của những đối tượng dữ liệu trong thiết bị đọc biểu diễn những giá trị hiện tại. Khi những đối tượng dữ liệu giống nhau được liệt ra trong danh sách CDOL1 và CDOL2, trường dữ liệu của nó được bao gồm cả trong dữ liệu có liên quan với giao dịch có thể là khác so với lệnh GENERATE AC thứ nhất và lệnh thứ hai, khi thiết bị đọc đã tiếp tục xử lý nó. Tiếp tục xử lý này có thể đã làm thay đổi giá trị của những đối tượng dữ liệu nào đó (ví dụ: TVR).
Danh sách những đối tượng dữ liệu trong CDOL1 và CDOL2 phải bao gồm độ dài nhãn liên quan của một số ngẫu nhiên được thiết bị đọc tạo ra – Số không thể đoán được (nhãn 9F37) – số này bảo đảm bằng chứng được thẻ đưa ra không thể được trả lời bởi những kẻ tấn công.
Nếu CDOL1 bao gồm nhãn 9F33 tương ứng với Những khả năng của thiết bị đọc, thì thẻ có thể tự xác định xem hệ kết hợp DDA/AC có nên được thực hiện hay không, mà không quan tâm đến giá trị của bit 6 trong tham số điều khiển liên quan, P1 trong C-APDU. Còn không, thiết bị đọc phải yêu cầu rõ ràng hệ kết hợp DDA/AC, đặt bit 6 là 1 trong tham số điều khiển liên quan.
Sự liên quan độ dài nhãn của những đối tượng dữ liệu được bao gồm trong cả CDOL1 và CDOL2. Những đối tượng dữ liệu này cho biết những điều kiện giao dịch tại điểm chấp nhận dịch vụ:
- Số tiền, Số giao dịch (Số) (nhãn 9F02); - Số tiền, Những số khác (số) (nhãn 9F03); - Mã tiền tệ giao dịch (nhãn 5F2A);
- Ngày giao dịch (nhãn 9A); - Loại giao dịch (nhãn 9C);
- Mã quốc gia của Thiết bị đọc (nhãn 9F1A); - Loại thiết bị đọc (nhãn 9F35).
Những đối tượng dữ liệu đã có trong môi trường giao dịch của thiết bị đọc có thể không tham gia trực tiếp quản lý rủi ro của thẻ nhưng chúng phải được đánh giá để tạo mã hóa của ứng dụng. Nếu vậy thì NHPH chỉ rõ độ dài nhãn liên quan của họ trong Danh sách đối tượng dữ liệu chứng chỉ của giao dịch (TDOL) có nhãn là 97 trong thẻ. Thiết bị đọc tạo thành một chuỗi byte liên kết những trường giá trị của những đối tượng dữ liệu liên quan trong TDOL và tính toán mã băm của chuỗi này. Mã băm này được lưu trong trường giá trị của đối tượng dữ liệu Giá trị băm của TC (có nhãn là 98) trong thiết bị đọc. Để đánh giá mã băm đã tính toán trong hệ mã hóa ứng dụng, thẻ phải bao gồm độ dài nhãn liên quan của Giá trị băm TC nằm trong những trường được liệt kê trong CDOL1/CDOL2.
- Những kết quả kiểm tra của thiết bị đọc (nhãn 95);
- Mã xác thực dữ liệu, cung cấp hoàn toàn bởi thiết bị đọc của SDA - Số động của thẻ EMV, cung cấp hoàn toàn bởi thiết bị đọc của DDA. Phạm vi độ dài nhãn của một số đối tượng dữ liệu khác chỉ được bao gồm trong CDOL1, nếu những đối tượng dữ liệu này có một mức phí xác định cho NHPH. Chúng bao gồm đối tượng dữ liệu Số tiền trong Tiền tệ liên quan (nhãn 9F3A), và Mã tiền tệ giao dịch liên quan (nhãn 9F3C), những mãy này được sử dụng trong chuyển đổi tiền, nếu như chúng được thiết bị đọc hỗ trợ.
Dữ liệu xác thực của NHPH (nhãn 91) nhận được từ NHPH trong gói tin phản hồi xác thực 1110. NHPH gửi gói tin này sau khi nhận và xử lý một xác thực trực tuyến với ARQC trong một gói tin yêu cầu xác thực 1100. CDOL2 có thể bao gồm phạm vi độ dài nhãn của Dữ liệu xác thực của NHPH. CDOL2 cũng có thể gồm phạm vi độ dài nhãn của đối tượng dữ liệu có nhãn 8A, Mã phản hồi xác thực. Mã này có thể được NHPH tạo ra, trong trường hợp ARQC được gửi trực tuyến thành công cho việc xác thực của NHPH và phản hồi tương trở lại từ thiết bị đọc, hoặc bởi thiết bị đọc, trong trường hợp giao dịch không được xác thực trực tuyến.
4.8.6.2 Tính toán mã hóa ứng dụng
Sau khi nhận C-APDU từ lệnh GENERATE AC, thẻ thực hiện thủ tục quản lý rủi ro của thẻ để xác định xem nó có đồng ý với mức quyết định được thiết bị đọc đề xuất hay không. Kết quả là thẻ thiết lập loại Mã hóa ứng dụng mà nó sẽ tạo (ví dụ: TC, ARQC, AAR, AAC). Thẻ cài đặt Dữ liệu thông tin mã hóa (dữ liệu này là đối tượng trong thẻ có nhãn 9F27) theo loại Mã hóa ứng dụng mà nó quyết định tính toán.
Ở bước tiếp theo thẻ tạo mã hóa ứng dụng, mã hóa này là kết quả của việc biến đổi mã hóa được thực hiện với một tham số mã hóa, tham số này là liên kết duy nhất với ATC và/hoặc số PAN của ứng dụng trong thẻ. Việc biến đổi này được thực hiện trên một chuỗi byte có liên quan đến một yêu cầu giao dịch, bao gồm những đối tượng dữ liệu liên quan với giao dịch tại điểm chấp nhận dịch vụ và một số ngẫu nhiên được thiết bị đọc tạo ra. Mã hóa ứng dụng này có thể được xem như bằng chứng được thẻ đưa ra có liên quan với việc giao dịch của nó, như một đại diện của NHPH, trong giao dịch hiện tại. Một điều có thể nhận thấy là kỹ thuật bảo mật này tương ứng với một xác thực động của thẻ. Điều này có nghĩa là khi đưa ra mã hóa ứng dụng (thẻ tự thực hiện việc xác thực động) cho phép người kiểm tra quyết định xem đây có phải là thẻ thật hay không. Nói cách khác, một người có thể cho rằng có một liên kết không thể chia cắt giữa việc tạo mã hóa ứng dụng của thẻ và việc xác thực động của nó. Câu hỏi đặt ra là ai sẽ xác thực động thẻ. Hoặc, thực thể nào có thể kiểm tra tính hợp lệ của việc xác thực động được thẻ thực hiện, qua việc quyết định sự đúng đắn của mã hóa ứng dụng?
Trường hợp 1:
Khi việc biến đổi được thẻ sử dụng là thuật toán mã hóa đối xứng, Mã hóa ứng dụng được tính như MAC với một khóa bí mật theo phiên SKAC. Trong trường hợp này xác thực động của thẻ được thực hiện với một DDA của MAC- cơ sở. NHPH của thẻ chỉ là thực thể có thể kiểm tra mã hóa ứng dụng.
Trường hợp 2:
Khi việc biến đổi được thẻ sử dụng là một thuật toán mã hóa bất đối xứng, thì Mã hóa ứng dụng được tính toán với một chữ ký số có khóa bí mật của thẻ. Trong trường hợp này xác thực động của thẻ được thực hiện với một DDA của chữ ký số cơ sở. Ai có bản sao xác thực khóa công khai của thẻ (trong trường hợp này thiết bị đọc tại điểm chấp nhận dịch vụ) thì đều có thể kiểm tra mã hóa ứng dụng. Việc này có thể được thực hiện chỉ khi gửi lệnh GENERATE AC thứ nhất và chỉ khi thẻ được yêu cầu cho một TC hoặc một ARQC.
Việc xử lý được thẻ thực hiện để tính toán của Mã hóa ứng dụng trong hai trường hợp nêu trên như sau:
Trường hợp 1:
Đầu tiên, IH sử dụng một modun mã hóa chống giả chứa khóa chủ của NHPH cho Mã hóa ứng dụng (IMKAC). Kỹ thuật trong những yêu mã hóa mà khóa chủ này có độ dài ít nhất là gấp hai lần khóa tripple-DES. Khi thẻ được phát hành, IH sử dụng dữ liệu định danh tài khoản được kết nối tới thẻ này như một thông tin đa dạng nhận được từ một khóa duy nhất cho mỗi thẻ. Dữ liệu định danh tài khoản bao gồm số PAN của ứng dụng và Dãy số PAN của ứng dụng, xác định thẻ hiện tại có nằm trong nhiều thẻ mà có thể được kết nối tới cùng một số PAN hay không. Khóa nhận được này được xem như khóa chủ mã hóa ứng dụng trong thẻ (MKAC), khóa này cũng có độ dài gấp đôi so với khóa tripple-DES. NHPH lưu khóa chủ MKAC trong thẻ EMV.
Khi thẻ nhận được lệnh GENERATE AC trong giai đoạn sử dụng thẻ, nó nhận được một khóa phiên của Mã hóa ứng dụng (SSKAC) có độ dài gấp đôi khóa tripple-DES từ MKAC, sử dụng ATC như thông tin thay đổi. Khóa phiên này được sử dụng để đưa ra Mã hóa ứng dụng với một MAC dựa trên một mã hóa khối có độ dài là 64 bit áp dụng trên yêu cầu giao dịch.
Yêu cầu giao dịch là một chuỗi byte được thiết lập như sự kết nối của những trường dữ liệu sau:
- Trường giá trị của một số đối tượng dữ liệu trong thẻ, mô tả nội dung của giao dịch EMV từ quan điểm của thẻ: AIP, ATC, và những kết quả kiểm tra quản lý rủi ro của thẻ.
Mã hóa ứng dụng bao gồm 8 byte nếu nó được đưa ra với một MAC của DES-cơ sở với khóa phiên đối xứng SSKAC.
Trường dữ liệu của R-APDU được lệnh GENERATE AC trả về bao gồm một đối tượng dữ liệu BER-TLV. Việc ghi của đối tượng dữ liệu này sẽ theo một trong hai định dạng sau:
Định dạng 1:
Đối tượng dữ liệu có thể là đối tượng dữ liệu nguyên thủy có một nhãn bằng 80. Trường giá trị này bao gồm sự nối vào nhau mà không cần những định ranh giới (nhãn và độ dài) của những trường giá trị theo những đối tượng dữ liệu:
- Dữ liệu thông tin mã hóa – bắt buộc;
- Bộ đếm giao dịch của ứng dụng (ATC) – bắt buộc; - Mã hóa ứng dụng (AC) – bắt buộc;
- Dữ liệu ứng dụng của NHPH (IAD) – tùy chọn, được tạo theo sở thích của NHPH. Nó có thể bao gồm một bộ chỉ dẫn khóa và một số phiên bản của thuật toán xác định tính duy nhất một phiên bản nào đó của IMKAC, nếu có nhiều phiên bản khóa khác nhau cho những giá trị khóa thay đổi thời gian và một phiên bản nào đó của những thuật toán MAC/thu hồi được sử dụng trong thẻ. IAD có thể cũng bao gồm những giá trị bằng chứng của việc thiết bị đọc xử lý SDA hoặc DDA (ví dụ: Mã xác thực dữ liệu, hoặc số động của thẻ). Để thúc đẩy những quyết định nào đó được thẻ đưa ra, NHPH có thể quyết định bao gồm những kết quả kiểm tra quản lý rủi ro thẻ trong IAD.
Định dạng này là phù hợp nếu câu trả lời của lệnh GENERATE AC có định dạng được thiết lập trước, biết đến trong cải tiến ứng dụng của thiết bị đọc.
Định dạng 2:
Đối tượng dữ liệu được trả về trong gói tin phản hồi là một đối tượng dữ liệu có cấu trúc với nhãn bằng 77. Trường giá trị của nó có thể chứa nhiều đối tượng dữ liệu được mã hóa BER-TLV, nhưng sẽ luôn luôn bao gồm Dữ liệu thông tin mã hóa (nhãn 9F27), ATC (nhãn 9F36), và Mã hóa ứng dụng được thẻ tính (nhãn 9F26).
Định dạng này là phù hợp nếu câu trả lời của lệnh GENERATE AC đã không được thiết lập trước định dạng.
Trường hợp 2
Khi thẻ nhận lệnh GENERATE AC, nó sử dụng khóa bí mật của thẻ (nIC, dIC) để đưa ra dữ liệu ứng dụng động đã ký. Thủ tục được sử dụng để tính toán chữ ký này là giống với thủ tục đã được mô tả đoạn trên, với những sửa đổi như sau:
- 12 đến 18 byte cực trái của trường 4, dữ liệu động của thẻ, trong phần
MR của dữ liệu ứng dụng động được ký, chứa những trường dữ liệu như sau: + Độ dài số động của thẻ – 1 byte;
+ Số động của thẻ – 2 đến 8 byte; + Dữ liệu thông tin mã hóa – 1 byte; + TC hoặc ARQC – 8 byte.
- Phần M’ của dữ liệu ứng dụng động được ký chỉ bao gồm Số không đoán được thiết bị đọc tạo ra (trong khung của DDA đơn giản, phần M’ bao gồm toàn bộ chuỗi byte dữ liệu động của thiết bị đọc, chuỗi byte bao gồm số không đoán được).
TC hoặc ARQC là phần của trường 4. Điều này có nghĩa là thẻ phải tính toán Mã hóa ứng dụng đầu tiên trên yêu cầu giao dịch. Từ đây thẻ tính toán MAC dựa trên mã hóa khối có độ dài 64 bit với khóa phiên đối xứng SSKAC,
Đối tượng dữ liệu mà được trả về trong gói tin phản hồi là một đối tượng dữ liệu có cấu trúc với nhãn bằng 77. Trường giá trị có thể chứa nhiều đối tượng dữ liệu được mã BER-TLV, nhưng sẽ luôn luôn bao gồm dữ liệu thông tin mã hóa (nhãn 9F27), ATC (nhãn 9F36), và dữ liệu ứng dụng động đã ký được tính toán bởi ICC (nhãn 9F4B).
Nếu quản lý rủi ro thẻ của thẻ quyết định trả lời với AAC được kết hợp yêu cầu DDA/AC, R-APDU là một đối tượng dữ liệu BER-TLV, được mã hóa cùng theo định dạng 1 hoặc 2. Trong cùng trường hợp R-APDU bao gồm ít nhất những đối tượng dữ liệu sau: Dữ liệu thông tin mã hóa, ATC, và AAC.
4.8.6.3 Kiểm tra mã hóa ứng dụng
Việc mã hóa ứng dụng được thẻ đưa ra có thể phục vụ việc chứng minh sự tham gia của thẻ trong một giao dịch EMV.
- Nếu GENERATE AC trả về một ARQC, đây là gói tin yêu cầu xác thực 1100 được gửi cho IH. Nếu việc kiểm tra ARQC là thành công, thì IH có bằng chứng thẻ được sử dụng tại điểm chấp nhận dịch vụ là thẻ thật.
Bởi vậy, ARQC phục vụ như việc xác thực thẻ trực tuyến, xác thực trực tuyến này đảm bảo là không có thẻ giả được xác thực trong hệ thống. Đây là một cải tiến quan trọng khi so sánh với công nghệ thẻ từ.
- Nếu GENERATE AC trả về một TC, thì đưa vào trong một gói tin thanh toán 1240, dựa trên đó NHTT yêu cầu Số tiền, Số giao dịch trong giao dịch EMV từ NHPH. Nếu việc kiểm tra TC nhận được từ gói tin thanh toán thành công, thì NHPH biết thẻ đưa ra TC đó có tham gia giao dịch hay không. NHPH