Android的IsoDep命令链故障 [英] Android IsoDep command chaining failure

问题描述

我正在使用ISO-DEP（ISO 14443-4）作为TagTechnology一个NFC应用。 我试着用的DESFire EV1执行身份验证。

认证工作做好，如果命令的链接是没有停顿。

但如果为例，我做的东西，需要一段时间（如NATIVE_AUTHENTICATION_COMMAND_P1后Thread.sleep代码），我得到了验证命令第2部分从卡过程中出现错误0x911C（不支持命令code）。 Normaly错误来当认证已被取消。就像如果卡的认证程序，有没有什么办法过程中得到了另一条命令。

问题是，我的应用程序做任何其他事情，在发送selectApplication，认证第1部分，睡眠和第2部分。 我也尝试同样的code在C ++中有PCSC Reader和睡眠不是probleme，即使以5秒的睡眠认证在我的电脑上工作。 所以，我想知道，如果Android的甚至到应用程序或帧的等待时间（ISO 14443-4）无法工作或NDEF拉打破了身份验证或给予意图后，打与卡...

（NATIVE_AUTHENTICATION_COMMAND_P2的值是一个为例）

 最后一个字节[] NATIVE_AUTHENTICATION_COMMAND_P1 =新的字节[] {（字节）0×90，（字节）的0x0A，（字节）为0x00，（字节）为0x00，（字节）为0x01，（字节）为0x00，（字节）为0x00};
 最后一个字节[] NATIVE_AUTHENTICATION_COMMAND_P2 =新的字节[] {（字节）0×90，（字节）0xAF执行，（字节）为0x00，（字节）为0x00，（字节）为0x10，（字节）是0xAB，（字节）0xB4（字节）0x66 （字节）0xA4，（字节）0xE9，（字节）0x99（字节）0xFF的，（字节）0x5c的，（字节）0xD7，（字节）0xF3，（字节）0xA7，（字节）0×81，（字节）0X62 （字节）值为0x2F，（字节）0xFA回应，（字节）为0x16，（字节）为0x00};
 最后一个字节[] NATIVE_SELECT_COMMAND =新byte[]{(byte)0x90,(byte)0x5A,(byte)0x00,(byte)0x00,(byte)0x03,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x00};

IsoDep标签= IsoDep.get（tagFromIntent）;

tag.connect（）;

byte []的结果;
结果= tag.transceive（NATIVE_SELECT_COMMAND）; //成功
结果= tag.transceive（NATIVE_AUTHENTICATION_COMMAND_P1）; //成功

//了Thread.sleep（1000）;

结果= tag.transceive（NATIVE_AUTHENTICATION_COMMAND_P2）; //结果= 0x90AE无睡眠和睡眠0x911C（不支持命令code）

tag.close（）;
 

如果一个人有一个想法，因为我完全失去了：）

更新： 在迈克尔 - 罗兰和他的提示的帮助;我用读卡器模式API和NDEF检查禁用和延迟presence支票到10秒钟，让我的链接命令可以正常使用！

  @覆盖
保护无效onResume（）{
    super.onResume（）;
    捆绑选项=新包（）;
    options.putInt（NfcAdapter.EXTRA_READER_ preSENCE_CHECK_DELAY，10000）;
    mAdapter.enableReaderMode（这个，这​​个，NfcAdapter.FLAG_READER_NFC_A | NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK，期权）;
}

@覆盖
公共无效的onPause（）{
    super.onPause（）;
    mAdapter.disableReaderMode（本）;
}
 

解决方案

您遇到了一个已知的问题与NFC栈为Broadcom的NFC芯片。这个问题是著名的相当长一段时间（见本 Android的bug报告，类似的事情适用于非基于APDU的标签也是如此）。

在你的情况，问题是，尽管手机和标签之间的连接处于空闲状态，Android的自动执行presence检查。虽然这presence检查正确的恩智浦的NFC协议栈实现中，博通版本使用READ BINARY命令（IsoDep卡）或等效的READ命令（用于其它标签技术）。

所以，如果你的命令序列是缓慢的，Android的可能发送一个READ BINARY APDU放在你的命令的。

不幸的是，这个错误仍然存​​在于安卓4.4.2和我来说，似乎目前还不清楚，如果谷歌最终会做一些事情。 更新：有开始与Android 5一个新的presence检查机制

如果你使用Android 4.4系统，有，然而，有些东西可以做，以避免故障：使用新的阅读模式的API来调整presence检查超时。如果你不使用NDEF，你甚至可以完全禁用presence检查。

I am making a NFC application that use ISO-DEP (ISO 14443-4) as TagTechnology. I try to execute a authentication with a DESFire EV1.

The authentication work well if the chaining of the command is without pause.

But if for exemple, I make something that take time (like the Thread.Sleep after NATIVE_AUTHENTICATION_COMMAND_P1) I got an error 0x911C ("Command code not supported") during the authentication command part 2 from the card. Normaly the error come when the authentication has been canceled. Like if the card got another command during the authentication procedure that have nothing about it.

The problem is that my application do nothing else that sending the selectApplication, Authentication Part 1, Sleep and the Part 2. I have try the same code in C++ with a PCSC Reader and the Sleep is not the probleme, even with 5 second sleep the authentication have work on my computer. So I would like to know if Android is "playing" with the card even after giving the Intent to the application or if the Frame Waiting Time (ISO 14443-4) is not working or NDEF "pull" broke the authentication or...

(The value of NATIVE_AUTHENTICATION_COMMAND_P2 is a exemple)

 final byte[] NATIVE_AUTHENTICATION_COMMAND_P1 = new byte[]{(byte)0x90, (byte)0x0A, (byte)0x00, (byte)0x00, (byte)0x01, (byte)0x00, (byte)0x00};
 final byte[] NATIVE_AUTHENTICATION_COMMAND_P2 = new byte[]{(byte)0x90, (byte)0xAF, (byte)0x00, (byte)0x00, (byte)0x10, (byte)0xAB, (byte)0xB4, (byte)0x66, (byte)0xA4, (byte)0xE9, (byte)0x99, (byte)0xFF, (byte)0x5C, (byte)0xD7, (byte)0xF3, (byte)0xA7, (byte)0x81, (byte)0x62, (byte)0x2F, (byte)0xFA, (byte)0x16, (byte)0x00};
 final byte[] NATIVE_SELECT_COMMAND = new byte[]{(byte)0x90,(byte)0x5A,(byte)0x00,(byte)0x00,(byte)0x03,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x00};

IsoDep tag = IsoDep.get(tagFromIntent);

tag.connect();

byte[] result;
result = tag.transceive(NATIVE_SELECT_COMMAND); //SUCCESS
result = tag.transceive(NATIVE_AUTHENTICATION_COMMAND_P1); //SUCCESS

// Thread.sleep(1000);

result = tag.transceive(NATIVE_AUTHENTICATION_COMMAND_P2); //result = 0x90AE without Sleep and with Sleep 0x911C ("Command code not supported")

tag.close();

If someone have an idea because I am totally lost :)

UPDATE: After the help of michael-roland and his tips; I have use the reader-mode API with NDEF check disable and delay presence check to 10 second to get my chaining command working perfectly !

@Override
protected void onResume() {
    super.onResume();
    Bundle options = new Bundle();
    options.putInt(NfcAdapter.EXTRA_READER_PRESENCE_CHECK_DELAY, 10000);
    mAdapter.enableReaderMode(this, this, NfcAdapter.FLAG_READER_NFC_A | NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK, options);
}

@Override
public void onPause() {
    super.onPause();
    mAdapter.disableReaderMode(this);
}

解决方案

You ran into a known problem with the NFC stack for Broadcom's NFC chipset. The issue is known for quite a while (see this Android bug report, something similar applies to non APDU-based tags too).

In your case, the problem is that while the connection between the phone and the tag is idle, Android automatically performs a presence check. While this presence check is correctly implemented for NXP's NFC stack, the Broadcom version uses a READ BINARY command (for IsoDep cards) or an equivalent READ command (for other tag technologies).

So, if your command sequence is slow, Android might send a READ BINARY APDU somewhere in between your commands.

Unfortunately, this bug still exists in Android 4.4.2 and to me it seems unclear if Google will eventually do something about it. UPDATE: There is a new presence check mechanism starting with Android 5.

If you use Android 4.4, there is, however, something you can do to avoid the bug: Use the new reader-mode API to tweak the presence-check timeout. If you do not use NDEF, you could even completely disable the presence-check.

这篇关于Android的IsoDep命令链故障的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！