Android (2.3.6) 中的 Mifare Ultralight C 身份验证答案

【问题标题】：Mifare Ultralight C Authentication in Android (2.3.6)Android (2.3.6) 中的 Mifare Ultralight C 身份验证
【发布时间】：2012-03-12 15:37:40
【问题描述】：

我正在尝试验证 Mifare Ultralight C（兼容 ISO/IEC 14443-2 和 14443-3 A 型）标签。

我使用 Android 中提供的 MifareUltralight.transceive() 函数发送身份验证命令。我还检查了 NfcA.transceive()（IsoDep 似乎与这种标签不兼容，因为该对象用于处理 ISO/IEC 14443-4 标签，这就是我不使用 IsoDep.transceive() 的原因）。

所以，当我第一次发送身份验证请求命令时，标签用 AFxxxx 回答 transceive() ..... 我在其中处理标签回答，然后我发送另一个带有对该答案的响应的 transceive() 但是.. . 就在发送 transceive() 之前，标签已连接，发送时我收到“标签丢失”警告和“收发失败”。

另外，如果我尝试使用 NfcA 也会出现同样的问题。

最后，如果我在第一个响应后尝试发送一个身份验证命令，我还会收到“标签丢失”警告，并且收发失败。

所以我的问题是：

为什么我发送第二个 transceive() 时 NFC 标签会丢失？

（这似乎不是超时问题，因为在发送第二个 transceive() 之前，连接已使用标签打开）我在与 UI 不同的线程中制作了所有东西。

提前致谢！

【问题讨论】：

我的猜测是响应（第二次发送）没有正确验证并且标签从不响应，因此看起来像标签丢失了手机。尝试多次写入（4 字节写入），看看是否有效。它将是 transcieve(0xA2, 0x06, 0x01, 0x02, 0x03, 0x04) ，其中 0x06 是页码。如果这可行，那么您尝试进行身份验证将是错误的。
首先，感谢您的回复:)。阅读后我认为您可能是对的，问题可能是我对身份验证的回复不正确，所以我会尝试您的建议以了解这是否有意义。但是，似乎是一个很好的观点。再次感谢！ ;) 我会在这里发布，如果我一实现它就可以写多次。
是的，在写了几篇文章后它工作了，所以这似乎是我的身份验证请求的问题。感谢您的帮助，我将检查我的请求程序以找出问题所在。谢谢你的帮助！ :)
我正在审查我的身份验证算法，发现一个可能是错误的前提。我将所有“0h”用作默认身份验证密钥。这可能是问题吗？ - 提前致谢！
我一直无法找到有关与 Mifare Ultralight C 进行收发级别通信或身份验证的信息。任何人都可以发布一些材料吗？

标签： android authentication nfc apdu mifare

【解决方案1】：

您的方法似乎是正确的。但是，标签的行为表明您对标签的回答不正确。在这种情况下，标签拒绝回答。从手机的角度来看，这与消失的标签无法区分，因此您会得到 TagLostException。

【讨论】：

是的，也许你是对的，我会尝试按照 Ben 的建议进行连续的写作，我们会发现我的错误的真相。感谢您的回复 NFC 家伙！
你有理由，我会检查我的认证程序，找出问题所在！谢谢你的帮助:)
我正在审查我的身份验证算法，我发现一个可能是错误的前提。我将所有“0h”用作默认身份验证密钥。这可能是问题吗？ - 提前致谢！
这取决于您在哪里/如何获得 Ultralight C。我已经看到了具有不同键的演示示例。我建议您向制造商索取一份应用说明，其中显示了逐步演练的身份验证，这将允许您验证自己实现的正确性。通过反复试验来调试加密代码不太可能成功，而且在任何情况下都非常麻烦（去过那里，做过；）
让我们结束话题，我前段时间找到了解决方案，标签有一个密钥，但在 NDA 条件下给出并且不是“0h”所以我不能在这里说如何进行身份验证，但最后它是成功实施。感谢大家的支持！

【解决方案2】：

对我来说这是同样的问题，但后来它以奇怪的方式解决了

第1步：pass1 1A00命令到卡

第 2 步：能够检索 pass1 响应挑战

第 3 步：算法计算步骤任意（假设此时标签丢失）并从设备中丢失一种合理的标签

第 4 步：通过 2 与 AFxxxxx 引发异常收发失败，但到那时如果我检查标记已丢失！！！

在挣扎了几天之后，我的一位同事要求我尝试减少 pass1 到 pass2 之间的任何延迟，这需要将近 1-1.5 秒，而在这之间却失败了。

我删除了中间写的所有日志，并在 pass1 后 500 毫秒内进行了简单的快速调用，我们来了，奇怪的工作正常！！！！

这可能是出于某种原因，卡技术具有某些安全目的，或者我不知道仍在尝试调查。

希望这会有所帮助。

【讨论】：