使用APDU命令获取卡的一些信息 [英] Use APDU commands to get some information for a card

问题描述

我有一个具有自己的API的终端，可以在芯片和终端之间稳定和发送命令，还有一个功能可以传输APDU命令并以字节数组形式返回答案.

I have a terminal that has its own API to stablish and send commands between chip and terminal, there is a function that transmits the APDU command and returns the answer in a byte array.

例如，如果要读取标签5A(应用程序PAN)，我将发送以下命令:

For example, if a want to read the tag 5A (Application PAN), I send the following command:

byte[] byteArrayAPDU = new byte[]{(byte)0x00, (byte)0xCA, (byte)0x00, (byte)0x5A};
int nResult = SmartCardInterface.transmit(nCardHandle, byteArrayAPDU, byteArrayResponse);

变量byteArrayResponse获取对APDU命令的响应.

The variable byteArrayResponse gets the response to the APDU command.

当我将byteArrayAPDU的值转换为十六进制数字的字符串时，这给了我:00 CA 00 5A.并且对该命令的响应为6E 00(不支持的类).

When I translate the value of byteArrayAPDU to a string of hexadecimal digits, this gives me: 00 CA 00 5A. And the response to that command is 6E 00 (class not supported).

我的设备符合ISO 7816的技术规范.我发送APDU命令的方式是否正确?我之所以这样问，是因为我已经读到APDU命令至少必须具有5个值，但是我不知道在第五个参数中发送什么.我不知道回复的长度是多少.

My device works with ISO 7816 as technical specifications. Is the way in which I am sending APDU commands correct? I ask this because I have read that an APDU command must have 5 values at least, but I don't know what to send in the fifth parameter. I don't know what the lenght of the response is.

您能举一个如何在APDU命令中获取标签5A或其他内容的示例吗?

Can you give an example of how to get the tag 5A or something else in APDU commands?

如果该命令正确无误，而不是现在我看到的6E 00位置，当转换为字符串时，我是否将信息视为纯文本?

If the command where correct, in place of where I see 6E 00 at the moment, would I see the information as plain text when cast to a string?

推荐答案

问题中显示的输入和输出值表明您对方法transceive()的使用正确，即第二个参数是命令APDU和第三个参数填充响应APDU:

The input and output values that you showed in your question suggest that your use of the method transceive() is correct, i.e. the second argument is a command APDU and the third argument is filled with the response APDU:

resultCode = SmartCardInterface.transmit(cardHandle, commandAPDU, ResponseAPDU);

关于APDU命令的格式和有效性的问题相当广泛.通常，APDU的格式和基本命令集在ISO/IEC 7816-4中定义.由于您使用 emv 的问题，并提及了该应用程序主帐号，您可能正在与某种形式的EMV付款卡(例如，来自主要方案之一的信用卡或借记卡)进行交互.在这种情况下，您可能需要研究EMV支付系统的各种规范，这些规范定义了这些卡的数据结构和特定于应用程序的命令.

Your question regarding the format and validity of APDU commands is rather broad. In general, the format of APDUs and a basic set of commands is defined in ISO/IEC 7816-4. Since you tagged the question with emv and mention the application primary account number, you are probably interacting with some form of EMV payment card (e.g. a credit or debit card from one of the major schemes). In that case, you would probably want to study the various specifications for EMV payment systems which define the data structures and application-specific commands for those cards.

关于您的具体问题:

不，当然不是.命令APDU至少包含4个字节(标头字节).这些是

No, certainly not. Command APDUs consist of at least 4 bytes (the header bytes). These are

+-----+-----+-----+-----+
| CLA | INS | P1  | P2  |
+-----+-----+-----+-----+

这种4字节的APDU称为情况1".这意味着命令APDU不包含发送到卡的数据字段，并且不希望卡生成响应数据字段.因此，预期响应APDU仅包含响应状态字:

Such a 4-byte APDU is called "case 1". This means that the command APDU does not contain a data field sent to the card and that the card is not expected to generate a response data field. So the response APDU is expected to only contain a response status word:

+-----+-----+
| SW1 | SW2 |
+-----+-----+

命令APDU的第5个字节是什么?

第5个字节是一个长度字段(如果是APDU扩展长度，则是长度字段的一部分，在本文中我将不作进一步解释).视情况而定，该长度字段可能具有两个含义:

What is the 5th byte of a command APDU?

The 5th byte is a length field (or part of a length field in case of extended length APDUs, which I won't further explain in this post). Depending on the case, this length field may have two meanings:

1. 如果命令APDU没有数据字段，则该长度字段表示响应数据字段的预期长度(Ne):

1. If the command APDU does not have a data field, that length field indicates the expected length (Ne) of the response data field:

+-----+-----+-----+-----+-----+
| CLA | INS | P1  | P2  | Le  |
+-----+-----+-----+-----+-----+

• Le = 0x01 .. 0xFF:这意味着期望的响应数据长度Ne为1、2，... 255字节(即Le的值).
• Le = 0x00:这意味着预期的响应数据长度Ne为256个字节.这通常用于指示卡为您提供尽可能多的字节(最多256个字节).因此，即使Le设置为0x00，您也不会总是从卡中准确获取256个字节.

如果命令APDU本身具有数据字段，则该长度字段表示命令数据字段的长度(Nc):

If the command APDU itself has a data field, that length field indicates the length (Nc) of the command data field:

+-----+-----+-----+-----+-----+-----------------+
| CLA | INS | P1  | P2  | Lc  | DATA (Nc bytes) |
+-----+-----+-----+-----+-----+-----------------+

• Lc = 0x01 .. 0xFF:这意味着命令数据长度Nc为1、2，... 255字节(即Lc的值).
• Lc = 0x00:用于指示扩展长度的APDU.

如果存在命令数据字段，并且期望该命令生成响应数据，则该命令APDU可能会再次跟一个Le字段:

If there is a command data field and the command is expected to generate response data, that command APDU may again be followed by an Le field:

+-----+-----+-----+-----+-----+-----------------+-----+
| CLA | INS | P1  | P2  | Lc  | DATA (Nc bytes) | Le  |
+-----+-----+-----+-----+-----+-----------------+-----+

命令00 CA 00 5A是否正确?

可能不是，原因如下:

Is the command 00 CA 00 5A correct?

Probably not, for several reasons:

1. 由于您希望卡传递一个响应数据字段(即数据对象0x5A)，因此需要指定一个Le字段.因此，有效格式应为

1. Since you expect the card to deliver a response data field (i.e. the data object 0x5A), you need to specify an Le field. Hence, a valid format would be

+------+------+------+------+------+
| CLA  | INS  | P1   | P2   | Le   |
+------+------+------+------+------+
| 0x00 | 0xCA | 0x00 | 0x5A | 0x00 |
+------+------+------+------+------+

• 您将收到状态字6E 00来响应该命令.此状态字的含义是"不支持的类".这表明在当前状态下不支持将CLA字节设置为0x00的命令.对于某些卡，这也仅表示不支持CLA和INS(00 CA)的组合，即使这与ISO/IEC 7816-4中的定义相抵触.

• You receive the status word 6E 00 in response to the command. The meaning of this status word is "class not supported". This indicates that commands with the CLA byte set to 0x00 are not supported in the current state. With some cards this also simply means that this combination of CLA and INS (00 CA) is not supported, eventhough this contradicts the definition in ISO/IEC 7816-4.

  总体上，您可以假定您的卡在其当前执行状态下不支持此命令.

  Overall, you can assume that your card does not support this command in its current execution state.

  假设您正在与EMV支付卡进行交互，通常需要首先选择一个应用程序.您的问题并未表明您是否已经这样做，所以我认为您现在不这样做.通过发送SELECT(通过AID)命令来完成应用程序的选择:

  Assuming you are interacting with an EMV payment card, you typically need to select an application first. Your question does not indicate if you do this already, so I assume, you don't do this right now. Selecting an application is done by sending a SELECT (by AID) command:

  
  +------+------+------+------+------+-----------------+------+
  | CLA  | INS  | P1   | P2   | Le   | DATA            | Le   |
  +------+------+------+------+------+-----------------+------+
  | 0x00 | 0xA4 | 0x04 | 0x00 | 0xXX | Application AID | 0x00 |
  +------+------+------+------+------+-----------------+------+
  

  应用程序AID的值当然取决于卡的应用程序，并且可以通过遵循EMV规范中定义的发现过程来获取.

  The value of the application AID, of course, depends on the card application and may be obtained by following the discovery procedures defined in the EMV specifications.

  即使在选择了应用程序之后，EMV应用程序的GET DATA APDU命令仍在专有类中定义.因此，CLA字节必须设置为0x80:

  Even after application selection, the GET DATA APDU command for EMV applications is defined in the proprietary class. Consequently, the CLA byte must be set to 0x80:

  
  +------+------+------+------+------+
  | CLA  | INS  | P1   | P2   | Le   |
  +------+------+------+------+------+
  | 0x80 | 0xCA | 0x00 | 0x5A | 0x00 |
  +------+------+------+------+------+
  

• 最后，即使如此，我仍然不知道有任何方案允许卡通过GET DATA命令检索PAN.通常，只能通过基于文件/记录的访问来访问PAN.由于您没有透露卡的特定类型/品牌，因此无法说出卡实际支持或不支持的内容.

• Finally, even then, I'm not aware of any schemes where cards would allow you to retrieve the PAN through a GET DATA command. Usually, the PAN is only accessible through file/record based access. Since you did not reveal the specific type/brand of your card, it's impossible to tell what your card may or may not actually support.

  这篇关于使用APDU命令获取卡的一些信息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！