カード ID の 7 バイトを取得する APDU コマンドはどれですか? ISO14443 レイヤーで T=CL (ISO7816) プロトコルを使用します。カードの検出では、カード ID の 4 バイトしか確認できません。これは、カード ID を取得するための APDU コマンドであることがわかりました。たとえば、その:
0xFF, 0xCA, 0x00, 0x00, 0x00
しかし、このコマンドの結果は:6E 00です。APDU の仕様では、「クラスはサポートされていません」と回答
その後、その APDU コマンドが次のようになる可能性があること
0x00, 0xCA, 0x00, 0x00, 0x00
が6A 88
わかり6A XXました。88
あなたはそれについてどう思いますか？
ありがとうございました！
PS すべてのコマンドとして:CLA, INS, P1, P2, LenData, Data
他の私のコマンドは正常に動作します (sellect aplet やそれで動作するなど)、カード ID の取得のみの問題
先ほどの答えは間違っています。これは、ここでは ISO 7816 コマンドについてではなく、PC/SC API の内部コマンドについて話しているためです。
APDU "0xFF 0xCA 0x00 0x00 0x00" は実際には正しく、7 バイトの応答が得られるカードがあります。この UID は無線プロトコルの一部であるため、これは非接触 (RFID) カードでのみ機能することに注意してください。さらに、一部のチップは、電源を入れるたびに新しいランダム UID を返すことに注意してください。これは、たとえば、私のパスポート チップ、ドイツの国民 ID カード、およびカード所有者の追跡を防止するための対策に当てはまります。理論的には、このようなランダムな UID は 0x08 で始まりますが、常にそうとは限りません。
UID はプロトコルの「内部」値であるため、問題の APDU はカードに送信されず、カード リーダー ドライバから UID を取得するための (PC/SC インターフェイスの) 内部コマンドにすぎません。CLA 0xFF は、「プロトコル パラメータ選択」(PPS) 用に予約されているため、通常は使用されません。PC/SC は、この CLA を内部コマンドに悪用します。
ここでのコマンドは、PC/SC 仕様のパート 3、セクション 3.2.2.1.3 で指定されている、PC/SC 内部の「Get Data」コマンドです。ここで、P1 と P2 には事前定義された特別な意味があるため、異なる値を試しても意味がありません。標準では、UID を取得するための P1=0,P2=0 と、「CRC のない ISO 14443 A カードの ATS からのすべての履歴バイト」のための P1=1,P2=0 のみが定義されています。他の値はサポートされていません。
興味深いことに、答え 0x6A 0x88 は標準で定義されていません。0x6a 0x81 は「サポートされていない機能」を意味します。これは、UID を持たないカードの場合です (標準では 7816-10 コンタクト カードが言及されています)。他の 2 つの定義済み回答 (0x62 0x82 および 0x6C 0xXX) は、要求された回答の長さと実際のデータ量との間の不一致を定義しますが、ここでは発生しません。これは、要求の最後のバイトに 0 を指定して任意の長さのデータを要求するだけだからです。 .
では、なぜ送信者が機能しないのかはわかりません。私にとってはうまくいきます.4バイトを返すカードもあれば、7バイトを返すカードもあります。
PC/SC 標準、特にパート 3 を参照してください: http://www.pcscworkgroup.com/specifications/specdownload.php
0xCAはGETDATAコマンドです。P1-P2でTLVタグを指定する必要があります。
ISO 7816パート6「交換のための業界間データ要素」にはこれらのタグのリストがありますが、「カードID」に明確に対応するものはありません。カードでサポートされているデータ要素を見つけるために、P1が0x00、0x5F、または0x7Fに等しいP2のすべての値を試すことをお勧めします。
2 番目のコマンドは正しいと思いますが、カードにはアプリケーション ID がプログラムされていません。
6A88 の場合、BasicCard のマニュアルには次のように記載されています。