因此，您的两种情况都依赖于对手机具有 root 访问权限的攻击者。在安全方面，通常认为一旦攻击者拥有 root 访问权限，游戏就结束了。也就是说，关于您的问题，仍有一些有趣的事情要说。

你问：

是否存在安全元素确实为该银行应用程序提供了明显的安全优势的情况，是否可以合理地强制执行？

有点厚脸皮：是的，正常的用例是用户有密码/密码锁，而攻击者没有 root 访问权限。

再深入一点：

当您说“有理由强制执行”时，我假设您的意思是与通过将密钥存储在软件中来为使用非 Secure Element 设备的用户提供相同的功能？我想到了几件事：

1. 在 Android > 6.0（我相信 iOS）上，加密发生在 Secure Element / Secure Enclave 内，因此私钥永远不会进入用户空间，因此它不会受到银行应用程序本身或软件加密库中潜在漏洞/草率编码的影响。利用。（通常是一个很好的做法）。

2. 因为私钥永远不会离开安全元件的密钥库，所以不可能从设备中提取它们并从服务器运行欺骗；您需要从物理设备执行此操作。如果所有者发现设备被盗，他们可以进行远程擦除，这将清除私钥，攻击结束。

3. 如果密钥库受密码保护，那么在软件密钥库的情况下，您可以将文件提取到服务器并暴力破解密码到您心中的内容。在安全元件的情况下，经过一些蛮力尝试后，他们可以擦除密钥。

4. 虽然仍处于试验阶段，但 Android 和 iOS 开始提供简洁的访问控制机制，以了解硬件密钥存储何时解锁密钥并为您执行加密。例如，您可以对您的应用程序进行编程，以通过以下方式从 SE 请求加密“签署此数据，但前提是设备已使用密码、指纹或 PIN 解锁，​​并且设备在 5 分钟前解锁，重新提示他们先登录”。使用基于软件的密钥根本不可能实现这种级别的控制。

对于对设备具有 root 访问权限的攻击者，这些东西都不是 100% 万无一失的，但我认为它们表明硬件密钥库/加密模块确实增加了一些价值。我的专业意见是，仅当您的设备具有安全元件时，银行应用程序才允许您绕过物理令牌生成器，这是一个合理的选择。

[免责声明：Android 安全元件在 Android 6.0 中进行了重大改造，所以我上面所说的不适用于 Android < 6.0，它没有在 SE 中进行任何加密，并且确实将私钥交还给了用户空间。]

一个想法。

虽然银行应用程序及其与银行服务器的通信方式在技术上可能是可靠的，并且几乎无法破解；手机本身呢？

我主要担心的是手机本身的安全性。如果它被盗或丢失，那么发现者/小偷需要做的就是绕过锁定屏幕。

很多人使用解锁图案，可以通过研究物理屏幕上的涂抹图案来追溯。一旦对手成功追溯解锁模式，对手就是我（就银行应用程序而言）。

因此，虽然银行应用程序可能相当安全，但我觉得手机本身的安全性现在是最薄弱的环节。