基于 NTAG213 与 Ultralight C 的支付应用程序（使用Android NFC）

Question

我有一个（大学）项目，我基本上用Android设备写和读NFC标签中的文本，以便将余额存储在卡中（例如，可以在自助餐厅使用）。

现在，我正在使用NTAG213编写下面的代码:

ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();

正如您所注意到的，我正在使用应用程序级加密来加密消息（消息加密），然后再将其写入标签（AES-256加密与'com.scottyab： AESCrypt： 0.0.1'库-使用一个非常大的密码密钥，该密钥也使用标签UID作为其中的一部分）。

到目前为止一切顺利 - 只有我能理解标签上的数据。

在我的研究中，我发现当涉及到安全Ultralight C时

问题1）使用应用程序级加密时，为什么（是吗？）MIFARE Ultralight C比NTAG213更安全吗？

问题2）我很确定我可以使用AES加密来保证安全性，但我不希望人们（除了我）弄乱存储的数据（格式化标签或在那里写入信息）。我认为防止这种情况的唯一方法（如果我错了，请纠正我）是为标签设置密码。但是，NTAG213和Ultralight C都只有32位密码。它足够好吗？有没有另一种方法阻止某人（除了我）写数据？

问题3)我可以在这些标签上使用哪些其他安全措施来加强安全性(标签和应用层)？

问题4)当您比较标签安全性(MIFARE DESFire

问题5）我看到一堆其他技术（MIFARE DESFire，ICODE SLIX，英飞凌Cipurse）更安全，这让我想知道我正在使用的技术（NTAG213或Ultralight C）是否足以存储某人的余额。您会（这是个人意见）说具有应用程序级加密和 32 位密码的 NTAG213 足以满足此类应用程序的需求吗？有人需要多长时间才能真正破坏其安全性？

Answer 1

我想你的问题太宽泛了，并不是对于所有子问题，SO的这一部分是最合适的。

通过专注于加密强度，你会错过一些东西：如果令牌的低级别安全性很容易被攻击，那么没有人需要破解你的密钥。

• 一个简单的转储和稍后的恢复（在一些付款之后）对应于印刷货币
• 如果令牌直接包含资金（而不是仅识别存储在后台系统上的钱包），您需要一个更安全的系统来避免财务损失。这涉及动态加密通信，但仍有大量其他主题。

Answer 2

首先，“更安全”取决于您的实际保护目标是什么。既然您想在卡上存储余额（现金！），您可能希望（至少）朝着以下目标进行保护：

< li >用户不能通过在卡上设置任意余额来打印自己的钱。 < li >用户不能复制他们的卡，因此也不能复制他们的资金余额。 < li >用户不能通过在支付后将卡恢复(回滚)到以前的余额来打印自己的钱。 < li >用户不能通过重放充值过程来打印自己的钱。 < li >用户不得在支付交易过程中通过撕卡来逃避支付。 < li >用户不得通过在充值过程中撕毁卡来在卡上生成任意(且可能更高)的余额。

此外，您可能也不想信任运营商（接受付款和执行充值的人）。在一个系统中，一组运营商只执行充值，另一组只执行支付交易，后一组可能不应该被允许“创造”金钱。特别是，你必须明确你是否完全信任你在现场使用的（Android）设备来执行这些操作，以及你是否信任运营商（例如，他们不会对这些设备进行任何攻击）。

此外，您可能需要考虑隐私方面（例如，如果余额是可自由阅读的，如果用户是可识别的，等等）

因此，让我们看看您的“应用程序级加密”在安全性方面增加了什么:

• 由于用户不知道加密密钥，因此他们可能无法在卡上生成任意余额。但是，这在很大程度上取决于您的余额格式（未加密形式）。用户可以对密文进行任意修改，从而导致对纯文本的“随机”修改。因此，尽管加密，用户仍可能修改余额值。数字签名/消息身份验证代码是您可能希望解决此问题的路径。
• 由于加密密钥（假设加密就足够了，但可能不是）取决于标签的 UID，因此您可以安全地防止克隆卡（余额）。但是，请注意，UID 只是一个可自由读取的标识符。它本身绝不经过身份验证，也可能是可克隆的。查看 NFC 标签上的连续剧 - 真正独特吗？可克隆？。
• 加密值不会保护您免受用户在付款后将其余额恢复到先前记录的值的影响。这种类型的漏洞以前已经发现过（特别是在基于MIFARE Ultralight的系统中），例如，参见Benninger，C.，Sobell，M.（2012）：NFC免费乘车和房间（在您的手机上）。在：在2012年欧洲西部博览会上的演讲。
• 由于您在充值过程中写入完整值（即没有特定的“增量平衡”命令），因此您可能可以安全地防止用户重放充值（除了回滚方面）。
• 如果您的系统只允许有人值守付款/充值，撕裂的影响可能相当有限。

因此，让我们看看NTAG213将具有哪些其他功能来保护您的系统：

• UID在真正的标签上是唯一的。这帮不了什么忙，看看NFC标签上的连续剧——真的很独特吗？可克隆的
• 原创签名：如上所述，原创签名也是一个静态的、可自由阅读的值。因此，它也很容易被克隆。
• 单向计数器可能是一种工具，可以帮助您防止回滚（通过将计数器值包含到签名中）。这仍然不会阻止克隆到允许生成任意计数器值的标签平台上。此外，计数器不容易控制，如果用户试图读取标签，计数器将改变其值。因此，基于该值的实现是否可靠是值得怀疑的。
• 与MIFARE Ultralight不同，NTAG213没有可用的一次性可编程区域（因为功能容器已经使用了该区域）。因此，您不能基于此实现一次性可抵扣余额。
• 密码保护功能可以帮助您验证标签（通过执行密码验证）和保护标签上存储的值（通过在密码验证后使值仅可读/写）。然而，密码以明文传输（可能会受到嗅探，特别是在（但不限于）无人值守的情况下），并且密码和实际读/写之间没有密码绑定

MIFARE Ultralight C将添加以下内容：

• 可以使用 OTP 字节。如果可以选择使标签一次性可用（即它们以只能从中扣除而不能充值的特定余额开头），那么使用 OTP 字节来表示余额将是一个选项。请注意，你仍然有很多事情可能做错，例如Beccaro，M.，Collura，M.（2013）：MIFARE ULTRALIGHT中的OTP规避：谁说免费乘车？。在：在DEFCON 21上的演讲
• 身份验证得到了很大的改进。3DES 身份验证方案似乎足够安全，可以防止嗅探密钥。但是，读/写命令也不会以加密方式绑定到身份验证步骤。因此，攻击者可能能够让真正的支付终端真实标签执行身份验证，但将读/写重定向到其他地方。在无人参与的情况下，这可能（特别是）是一个问题。

见上文。这可能不是真的。

密码/身份验证密钥可能会有所帮助，但请注意由于在这些标签平台上身份验证与读/写分离而造成的限制。

这不是真的。NTAG213 具有 32 位密码。MIFARE Ultralight C使用更复杂的相互2K-3DES身份验证机制和112位密钥。

• 身份验证机制（算法、密钥大小）
通信
• 安全性（例如，通信本身是否使用从身份验证步骤派生的会话密钥进行加密/身份验证？
• 访问控制（例如，是否有单独的充值和付款密钥？
• 是否有专门的余额管理机制（例如值字段、专用的递增/递减操作）？因此，是否有防止撕裂攻击的机制？
• 可能还有更多...

您特定的系统在许多方面都存在缺陷。在我看来，MIFARE Ultralight/NTAG203/NTAG21x绝对不是在卡上存储现金的离线系统的好选择。

MIFARE Ultralight C可能适合一些预防措施。我肯定不会在无人值守的情况下使用副歌，我可能会使用在线系统跟踪平衡和监控不一致。

任何使用对称密码学并将密码密钥存储在终端中的东西都肯定需要对恶意操作员采取预防措施。操作员（有一些知识）从应用程序中提取密钥并生成自己的钱可能相当容易。