基于NTAG213的支付应用对比Ultralight C（使用Android NFC）
Payment application based on NTAG213 vs. Ultralight C (using Android NFC)
我有一个（大学）项目，我基本上用 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）足以存储某人的余额。您（这是个人意见）会说具有应用程序级加密和 32 位密码的 NTAG213 足以满足此类应用程序的要求吗？真正破坏其安全性需要多长时间？
我想你的问题太宽泛了，并不是所有的子问题都适合 SO 的这一部分。
通过关注密码强度，您会错过一些东西：如果令牌的低级别安全性很容易受到攻击，那么没有人需要破解您的密钥。
- 一个简单的转储和后来的恢复（在一些支付之后）对应于印钞
- 如果令牌直接包含钱（而不是仅识别存储在后台系统中的钱包），您需要一个更安全的系统来避免财务损失。这涉及动态加密通信，但会继续讨论更多的主题。
使用应用程序级加密时，为什么 Ultralight C 比 NTAG213 更安全？这是真的吗？
首先，"safer"取决于您的实际保护目标是什么。由于您想在卡上存储余额（现金！），您可能希望（至少）实现以下目标：
- 用户不能通过在卡上设置任意余额来打印自己的钱。
- 用户不能复制他们的卡，因此不能复制他们的余额。
- 用户在付款后不能通过将他们的卡恢复（回滚）到以前的余额来打印自己的钱。
- 用户不能通过重玩充值程序来打印自己的钱。
- 用户不得在付款交易中通过撕毁卡片来逃避付款。
- 用户不得在充值过程中通过撕毁卡在卡上产生任意（且可能更高）的余额。
此外，您可能也不想信任运营商（接受付款和执行充值的人）。在一组操作员仅执行充值而另一组仅执行支付交易的系统中，后一组可能永远不会被允许 "create" 钱。特别是，你必须非常清楚你是否完全信任你在现场使用的（Android）设备来执行这些操作，以及你是否信任操作员（例如，他们不会对这些进行任何攻击）设备）。
此外，您可能需要考虑隐私方面的问题（例如，余额是否可自由读取，用户是否可识别等）
那么让我们看看您 "application level encryption" 在安全方面添加了什么：
- 由于用户不知道加密密钥，他们可能无法在卡上生成任意余额。但是，这在很大程度上取决于您的余额格式（未加密形式）。用户可以对密文进行任意修改，结果是对明文进行"random"次修改。因此，尽管加密，用户仍可以修改余额值。数字 signature/message 身份验证代码是您可能想要克服此问题的途径。
- 由于加密密钥（假设加密就足够了，但实际上可能不够）取决于标签的 UID，因此您可以安全地防止卡的克隆（+ 余额）。但是，请注意 UID 只是一个可自由读取的标识符。它绝不是经过身份验证的，也可能是可克隆的。参见 Serials on NFC Tags - truly unique? cloneable?。
- 加密值不会保护您免受用户在付款后将其余额恢复为先前记录值的影响。这种类型的漏洞之前已经被发现（特别是在基于 MIFARE Ultralight 的系统中），例如 Benninger, C., Sobell, M. (2012): NFC for free rides and rooms (on your phone). In: Presentation at EUSecWest 2012.
- 由于您在充值过程中写入了完整的值（即没有特定的 "increment balance" 命令），您可能可以安全地防止用户重播充值（回滚方面除外）这个）。
- 如果您的系统只允许有人出席，撕裂的影响可能相当有限 payment/top-up。
让我们看看 NTAG213 有哪些附加功能可以用来保护您的系统：
- UID 在正版标签上是唯一的。这没有多大帮助，请参阅 Serials on NFC Tags - truly unique? cloneable?。
- 原创签名：同上，原创签名也只是一个静态的、可自由读取的值。因此，它也很容易被克隆。
- 单向计数器可能是一种帮助您防止回滚的工具（通过将计数器值包含在签名中）。这仍然不会阻止克隆到允许生成任意计数器值的标签平台上。此外，计数器不容易控制，如果用户试图读取标签，计数器的值就会改变。因此，基于该值的实现是否可靠值得怀疑。
- 与 MIFARE Ultralight 不同，NTAG213 没有可用的一次性可编程区域（因为该区域已被功能容器使用）。因此，您不能基于此实施一次性免赔额。
- 密码保护功能可以帮助您验证标签（通过执行密码验证）和保护存储在标签上的值（通过在密码验证后将值设为 readable/writable）。但是，密码以明文形式传输（可能会被嗅探，特别是在（但不限于）无人值守的情况下）并且密码与实际 read/write.
之间没有加密绑定
MIFARE Ultralight C 将添加以下内容：
- 可以使用 OTP 字节。如果可以选择使标签一次性可用（即它们以只能从中扣除不能充值的特定余额开始），那么使用 OTP 字节来表示余额将是一个选项。请注意，您仍然有很多事情可能会做错，例如Beccaro, M., Collura, M. (2013): OTP circumventing in MIFARE ULTRALIGHT: Who says free rides?. In: Presentation at DEFCON 21
- 身份验证得到了很大改进。 3DES 身份验证方案似乎足够安全以防止嗅探密钥。但是，read/write 命令也 未 以加密方式绑定到身份验证步骤。因此，攻击者可能能够让真正的支付终端+真正的标签进行身份验证，但将 read/write 重定向到其他地方。在无人值守的情况下，这可能（特别是）是一个问题。
我很确定我可以使用 AES 加密来保证安全。
见上文。这可能不是真的。
我不希望人们弄乱存储的数据。我看到防止这种情况的唯一方法是为标签设置密码。
password/authentication 密钥可能会有所帮助，但请注意在这些标签平台上由于身份验证与 read/write 分离而导致的限制。
NTAG213 和 Ultralight C 都只有 32 位密码。
这不是真的。 NTAG213 有一个 32 位密码。 MIFARE Ultralight C 使用具有 112 位密钥的更复杂的相互 2K-3DES 身份验证机制。
当您比较标签安全性时，真正比较的是什么？
- 身份验证机制（算法、密钥大小）
- 通信安全（例如，通信本身是否 encrypted/authenticated 使用从身份验证步骤派生的会话密钥？）
- 访问控制（例如，充值和支付是否有单独的密钥？）
- 是否有专门的余额管理机制（例如值字段、专用 increment/decrement 操作）？因此，是否有防止撕裂攻击的机制？
- 可能还有更多...
我看到很多其他技术更安全，这让我想知道我使用的技术是否足以存储某人的余额。
您的特定系统在很多方面都存在缺陷。在我看来，MIFARE Ultralight/NTAG203/NTAG21x 绝对不是离线系统在卡上存储现金的好选择。
MIFARE Ultralight C 可能适用于一些预防措施。我绝对不会在无人值守的情况下使用它，我可能会使用一个在线系统来跟踪余额和监控不一致。
任何使用对称加密并将加密密钥存储在终端中的东西肯定需要针对恶意操作者采取预防措施。对于运营商（具有一定知识）来说，从应用程序中提取密钥并生成他们自己的钱可能相当容易。
我有一个（大学）项目，我基本上用 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）足以存储某人的余额。您（这是个人意见）会说具有应用程序级加密和 32 位密码的 NTAG213 足以满足此类应用程序的要求吗？真正破坏其安全性需要多长时间？
我想你的问题太宽泛了，并不是所有的子问题都适合 SO 的这一部分。
通过关注密码强度，您会错过一些东西：如果令牌的低级别安全性很容易受到攻击，那么没有人需要破解您的密钥。
- 一个简单的转储和后来的恢复（在一些支付之后）对应于印钞
- 如果令牌直接包含钱（而不是仅识别存储在后台系统中的钱包），您需要一个更安全的系统来避免财务损失。这涉及动态加密通信，但会继续讨论更多的主题。
使用应用程序级加密时，为什么 Ultralight C 比 NTAG213 更安全？这是真的吗？
首先，"safer"取决于您的实际保护目标是什么。由于您想在卡上存储余额（现金！），您可能希望（至少）实现以下目标：
- 用户不能通过在卡上设置任意余额来打印自己的钱。
- 用户不能复制他们的卡，因此不能复制他们的余额。
- 用户在付款后不能通过将他们的卡恢复（回滚）到以前的余额来打印自己的钱。
- 用户不能通过重玩充值程序来打印自己的钱。
- 用户不得在付款交易中通过撕毁卡片来逃避付款。
- 用户不得在充值过程中通过撕毁卡在卡上产生任意（且可能更高）的余额。
此外，您可能也不想信任运营商（接受付款和执行充值的人）。在一组操作员仅执行充值而另一组仅执行支付交易的系统中，后一组可能永远不会被允许 "create" 钱。特别是，你必须非常清楚你是否完全信任你在现场使用的（Android）设备来执行这些操作，以及你是否信任操作员（例如，他们不会对这些进行任何攻击）设备）。
此外，您可能需要考虑隐私方面的问题（例如，余额是否可自由读取，用户是否可识别等）
那么让我们看看您 "application level encryption" 在安全方面添加了什么：
- 由于用户不知道加密密钥，他们可能无法在卡上生成任意余额。但是，这在很大程度上取决于您的余额格式（未加密形式）。用户可以对密文进行任意修改，结果是对明文进行"random"次修改。因此，尽管加密，用户仍可以修改余额值。数字 signature/message 身份验证代码是您可能想要克服此问题的途径。
- 由于加密密钥（假设加密就足够了，但实际上可能不够）取决于标签的 UID，因此您可以安全地防止卡的克隆（+ 余额）。但是，请注意 UID 只是一个可自由读取的标识符。它绝不是经过身份验证的，也可能是可克隆的。参见 Serials on NFC Tags - truly unique? cloneable?。
- 加密值不会保护您免受用户在付款后将其余额恢复为先前记录值的影响。这种类型的漏洞之前已经被发现（特别是在基于 MIFARE Ultralight 的系统中），例如 Benninger, C., Sobell, M. (2012): NFC for free rides and rooms (on your phone). In: Presentation at EUSecWest 2012.
- 由于您在充值过程中写入了完整的值（即没有特定的 "increment balance" 命令），您可能可以安全地防止用户重播充值（回滚方面除外）这个）。
- 如果您的系统只允许有人出席，撕裂的影响可能相当有限 payment/top-up。
让我们看看 NTAG213 有哪些附加功能可以用来保护您的系统：
- UID 在正版标签上是唯一的。这没有多大帮助，请参阅 Serials on NFC Tags - truly unique? cloneable?。
- 原创签名：同上，原创签名也只是一个静态的、可自由读取的值。因此，它也很容易被克隆。
- 单向计数器可能是一种帮助您防止回滚的工具（通过将计数器值包含在签名中）。这仍然不会阻止克隆到允许生成任意计数器值的标签平台上。此外，计数器不容易控制，如果用户试图读取标签，计数器的值就会改变。因此，基于该值的实现是否可靠值得怀疑。
- 与 MIFARE Ultralight 不同，NTAG213 没有可用的一次性可编程区域（因为该区域已被功能容器使用）。因此，您不能基于此实施一次性免赔额。
- 密码保护功能可以帮助您验证标签（通过执行密码验证）和保护存储在标签上的值（通过在密码验证后将值设为 readable/writable）。但是，密码以明文形式传输（可能会被嗅探，特别是在（但不限于）无人值守的情况下）并且密码与实际 read/write. 之间没有加密绑定
MIFARE Ultralight C 将添加以下内容：
- 可以使用 OTP 字节。如果可以选择使标签一次性可用（即它们以只能从中扣除不能充值的特定余额开始），那么使用 OTP 字节来表示余额将是一个选项。请注意，您仍然有很多事情可能会做错，例如Beccaro, M., Collura, M. (2013): OTP circumventing in MIFARE ULTRALIGHT: Who says free rides?. In: Presentation at DEFCON 21
- 身份验证得到了很大改进。 3DES 身份验证方案似乎足够安全以防止嗅探密钥。但是，read/write 命令也 未 以加密方式绑定到身份验证步骤。因此，攻击者可能能够让真正的支付终端+真正的标签进行身份验证，但将 read/write 重定向到其他地方。在无人值守的情况下，这可能（特别是）是一个问题。
我很确定我可以使用 AES 加密来保证安全。
见上文。这可能不是真的。
我不希望人们弄乱存储的数据。我看到防止这种情况的唯一方法是为标签设置密码。
password/authentication 密钥可能会有所帮助，但请注意在这些标签平台上由于身份验证与 read/write 分离而导致的限制。
NTAG213 和 Ultralight C 都只有 32 位密码。
这不是真的。 NTAG213 有一个 32 位密码。 MIFARE Ultralight C 使用具有 112 位密钥的更复杂的相互 2K-3DES 身份验证机制。
当您比较标签安全性时，真正比较的是什么？
- 身份验证机制（算法、密钥大小）
- 通信安全（例如，通信本身是否 encrypted/authenticated 使用从身份验证步骤派生的会话密钥？）
- 访问控制（例如，充值和支付是否有单独的密钥？）
- 是否有专门的余额管理机制（例如值字段、专用 increment/decrement 操作）？因此，是否有防止撕裂攻击的机制？
- 可能还有更多...
我看到很多其他技术更安全，这让我想知道我使用的技术是否足以存储某人的余额。
您的特定系统在很多方面都存在缺陷。在我看来，MIFARE Ultralight/NTAG203/NTAG21x 绝对不是离线系统在卡上存储现金的好选择。
MIFARE Ultralight C 可能适用于一些预防措施。我绝对不会在无人值守的情况下使用它，我可能会使用一个在线系统来跟踪余额和监控不一致。
任何使用对称加密并将加密密钥存储在终端中的东西肯定需要针对恶意操作者采取预防措施。对于运营商（具有一定知识）来说，从应用程序中提取密钥并生成他们自己的钱可能相当容易。