Lệnh APDU nào nhận được thẻ ID

Question

Lệnh APDU nào nhận được 7 byte ID thẻ? Tôi sử dụng T = CL (ISO7816) pritocol với lớp ISO14443. Trên thẻ phát hiện, tôi chỉ có thể xem 4 byte ID thẻ. Tôi đã tìm kiếm, đó là lệnh APDU để lấy ID thẻ. Ví dụ của nó:
0xFF, 0xCA, 0x00, 0x00, 0x00
nhưng kết quả của thouse lệnh là: 6E 00, mà trên thông số kỹ thuật của APDU câu trả lời nói rằng "Class không được hỗ trợ"

Sau đó, tôi tìm thấy, rằng lệnh APDU của nó có thể là:
0x00, 0xCA, 0x00, 0x00, 0x00
lệnh này trở 6A 88
nơi 6A XX- "thông số sai (s) P1-P2" và 88 - "Không tìm thấy dữ liệu tham chiếu"

Bạn nghĩ gì về nó?

Cảm ơn bạn!

p.s. Tất cả các lệnh dưới dạng: CLA, INS, P1, P2, LenData, Data
Lệnh khác của tôi hoạt động bình thường (chẳng hạn như bán vé aplet và làm việc với nó), vấn đề chỉ nhận được thẻ ID

Answer 1

0xCA là lệnh GET DATA. Bạn phải cung cấp Thẻ TLV trong P1-P2.

ISO 7816 phần 6 "Yếu tố dữ liệu liên ngành để trao đổi" có danh sách các thẻ này, nhưng không có thẻ nào tương ứng rõ ràng với "ID thẻ". Tôi khuyên bạn nên thử tất cả các giá trị của P2, với P1 bằng 0x00, 0x5F hoặc 0x7F, để tìm ra yếu tố dữ liệu nào được thẻ của bạn hỗ trợ.

Answer 2

Câu trả lời được đưa ra trước đây là sai. Điều này là do chúng ta không nói về lệnh ISO 7816 ở đây mà là một lệnh nội bộ của API PC/SC.

APDU "0xFF 0xCA 0x00 0x00 0x00" là trên thực tế chính xác và tôi có thẻ mà tôi nhận được câu trả lời 7 byte. Xin lưu ý rằng điều này sẽ chỉ hoạt động với thẻ không tiếp xúc (RFID) vì UID này là một phần của giao thức radio. Xin lưu ý thêm rằng một số chip sẽ trả về một UID ngẫu nhiên mới sau mỗi lần tăng nguồn. Điều này là ví dụ đúng đối với con chip hộ chiếu của tôi cũng như thẻ căn cước quốc gia Đức của tôi và một biện pháp đối phó để ngăn chặn việc theo dõi chủ thẻ. Theo lý thuyết, các UID ngẫu nhiên sẽ bắt đầu bằng 0x08 nhưng không phải lúc nào cũng vậy.

Vì UID là giá trị "nội bộ" của giao thức, APDU được đề cập KHÔNG được gửi tới thẻ mà chỉ là lệnh nội bộ (của Giao diện PC/SC) để nhận UID từ trình đọc thẻ . CLA 0xFF thường không được sử dụng bình thường vì nó chỉ được sử dụng để dành riêng cho "Protocol Parameter Selection" (PPS). PC/SC lạm dụng CLA này cho các lệnh nội bộ.

Lệnh ở đây là lệnh "Lấy dữ liệu" bên trong PC/SC, được chỉ định trong Phần 3, Mục 3.2.2.1.3 của đặc tả PC/SC. Ở đây P1 và P2 có ý nghĩa đặc biệt được xác định trước, do đó, không có điểm trong việc thử các giá trị khác nhau. Tiêu chuẩn chỉ xác định P1 = 0, P2 = 0 để nhận UID và P1 = 1, P2 = 0 cho "tất cả các byte lịch sử từ ATS của ISO 14443 Thẻ không có CRC". Các giá trị khác không được hỗ trợ.

Điều thú vị là câu trả lời 0x6A 0x88 không được xác định trong tiêu chuẩn. 0x6a 0x81 có nghĩa là "Chức năng không được hỗ trợ" sẽ là trường hợp thẻ không có UID (tiêu chuẩn đề cập đến thẻ liên hệ 7816-10).Hai câu trả lời được xác định khác (0x62 0x82 và 0x6C 0xXX) xác định sự không khớp giữa độ dài câu hỏi được yêu cầu và lượng dữ liệu thực tế và sẽ không xảy ra ở đây, bởi vì chúng tôi chỉ yêu cầu bất kỳ dữ liệu độ dài nào bằng cách chỉ định 0 trong byte cuối cùng của yêu cầu .

Vậy tại sao nó không hoạt động đối với người gửi mà tôi không biết. Đối với tôi nó hoạt động, một số thẻ trả về 4 byte, trả về 7 byte khác.

Xem tiêu chuẩn PC/SC, phần 3 nói riêng, ở đây: http://www.pcscworkgroup.com/specifications/specdownload.php

Answer 3

Tôi nghĩ rằng lệnh thứ hai của bạn là đúng, nhưng thẻ đã không được lập trình với một Id ứng dụng.

Đối với 6A88 hướng dẫn sử dụng BasicCard cho biết: "Lệnh dựng sẵn GET APPLICATION ID trả về mã lỗi này nếu không có ID ứng dụng nào được định cấu hình trong BasicCard".