我有一个(大学)项目，我基本上用Android设备从NFC标签中写入和读取文本，以便将余额存储在卡中(例如，可以在自助餐厅使用)。
现在，我正在使用NTAG213执行以下代码：
ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();
正如您所注意到的，在将消息写入标签之前，我正在使用应用程序级加密来加密消息(messageEncrypted)(AES-256 使用"com.scottyab：aescrypt：0.0.1"库加密 - 使用非常大的密码密钥，也使用标签 UID 作为其中的一部分)。
到目前为止一切顺利 - 只有我能理解标签上的数据。
在我的研究中，我发现在安全性方面，Ultralight C> NTAG213。
问题1)使用应用程序级加密时，为什么MIFARE Ultralight C比NTAG213更安全？
问题2)我很确定我可以使用AES加密来保证安全性，但我不希望人们(除了我之外)弄乱存储的数据(格式化标签或在那里写入信息)。我看到防止这种情况的唯一方法(如果我错了，请纠正我)是为标签设置密码。但是，NTAG213 和 Ultralight C 都只有 32 位密码。够好吗？有没有另一种方法可以防止某人(除了我)写入数据？
问题3)我可以在此类标记上使用哪些其他安全措施来强制实施安全性(标记和应用层)？
问题4)当您比较标签安全性(MIFARE DESFire> Ultralight> NTAG213> MIFARE Classic)时，真正比较的是什么？一个人破解(本机标签)加密的难易程度还是未经许可在标签上存储(任何东西)的难易程度？
问题5)我看到一堆其他技术(MIFARE DESFire，ICODE SLIX，Infineon Cipurse)更安全，这让我想知道我正在使用的技术(NTAG213或Ultralight C)是否足以存储某人的余额。你会(这是个人意见)说NTAG213应用程序级加密和 32 位密码足以满足此类应用程序的需求吗？有人需要多长时间才能真正破坏其安全性？
使用应用程序级加密时，为什么 Ultralight C 比 NTAG213 更安全？这是真的吗？
首先，"更安全"取决于您的实际保护目标是什么。由于您想在卡上存储余额(现金！)，因此您可能希望(至少)保护以下目标：
- 用户不得通过在卡上设置任意余额来打印自己的钱。
- 用户不得复制他们的卡，从而无法复制他们的资金余额。
- 用户在付款后不得通过将卡恢复(回滚)到以前的余额来打印自己的钱。
- 用户不得通过重播充值过程来打印自己的钱。
- 用户不得在付款交易期间撕卡以逃避付款。
- 用户不得通过在充值过程中撕毁卡来在其卡上生成任意(并且可能更高)的余额。
此外，您可能也不想信任运营商(接受付款和执行充值的人)。在一个系统中，一组运营商只执行充值，另一组只执行支付交易，后一组可能不应该被允许"创造"货币。特别是，您必须非常清楚地表明您是否完全信任您在现场使用的(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 身份验证方案似乎足够安全，可以防止嗅探密钥。但是，读/写命令也不会以加密方式绑定到身份验证步骤。因此，攻击者可能能够让真正的支付终端+真正的标签执行身份验证，但将读/写重定向到其他地方。在无人参与的情况下，这可能(特别是)是一个问题。
我很确定我可以使用AES加密来保证安全性。
见上文。这可能不是真的。
我不希望人们弄乱存储的数据。我看到防止这种情况的唯一方法是为标签设置密码。
密码/身份验证密钥可能会有所帮助，但请注意由于身份验证与这些标签平台上的读/写分离而产生的限制。
NTAG213和Ultralight C都只有32位密码。
这不是真的。NTAG213有一个 32 位密码。MIFARE Ultralight C使用更复杂的相互2K-3DES身份验证机制和112位密钥。
当您比较标签安全性时，真正比较的是什么？
- 身份验证机制(算法、密钥大小) 通信
- 安全性(例如，通信本身是否使用从身份验证步骤派生的会话密钥进行加密/身份验证？
- 访问控制(例如，是否有单独的充值和付款密钥？
- 是否有专门的余额管理机制(例如值字段、专用的递增/递减操作)？因此，是否有防止撕裂攻击的机制？
- 可能还有更多...
看到一堆其他更安全的技术，这让我想知道我使用的技术是否足以存储某人的余额。
您的特定系统在很多方面都有缺陷。在我看来，MIFARE Ultralight/NTAG203/NTAG21x对于在卡上存储现金的离线系统来说绝对不是一个好的选择。
MIFARE Ultralight C可能适合采取一些预防措施。我绝对不会在无人值守的情况下使用它，我可能会使用在线系统跟踪平衡并监控不一致之处。
任何使用对称加密并将加密密钥存储在终端中的东西肯定都需要防范恶意操作员。对于操作员(具有一些知识)来说，从应用程序中提取密钥并产生自己的钱可能相当容易。
我想你的问题太宽泛了，并不是所有子问题，SO的这一部分是最合适的。
通过专注于加密强度，你会错过一些东西：如果令牌的低级别安全性很容易被攻击，那么没有人需要破解你的密钥。
- 一个简单的转储和后来的恢复(在一些付款之后)对应于印钞
- 如果代币直接包含资金(而不仅仅是识别存储在后台系统上的钱包)，您需要一个更安全的系统来避免经济损失。这涉及动态加密通信，但继续讨论大量进一步的主题。