使用移动应用程序保护通信 [真实性、隐私性和完整性]？

Question

Android/Iphone 应用程序将从服务器访问应用程序数据。 [Django-Python]

如何确保与移动应用程序的通信安全？

期望：对密码等敏感信息足够安全，除了暴力破解之外，没有直接的解密方式。

我的要求：

• 身份验证[只有应用被授权]
• 完整性 [不应在两者之间修改消息]
• 隐私 [如果被嗅探，通信不应该是可读的]

我的努力：

• SSL 仅对服务器进行身份验证，而不对客户端进行身份验证。
• 我无法使用对称加密 [仅提供隐私]
• 无法进行数字签名 [缺乏隐私]
• PGP 完全满足所有 3 个要求。

问题：

• PGP 要求将密钥存储在客户端应用程序上。
• 似乎没有确保客户端应用程序密钥安全的可靠方法。
• 如果密钥失效，那么 PGP 或对称加密同样容易受到攻击。
• 逆向工程 PGP 密钥或对称密钥同样困难。
• 在这种情况下，PGP 对移动处理器来说是无意义的负担。
• OAuth 又没用了，因为它还有一个客户端密钥。

那么，我该如何/应该如何继续前进？ 行业如何处理这个问题？

我应该实施随意的方法吗：

• 使用简单的 SSL 并交叉手指？，因为如果密钥被盗，则无法进行身份验证？ （只能使用服务器身份验证）

更新：

结论是使用 AES，因为如果我可以保证密钥的安全，那么我和 SSL 一样好。 另外，我可以不断更改密钥以提高安全性。 如果您认为有更好的方法，请在发帖前阅读整篇文章。

Answer 1

您正在处理错误信息。 SSL 绝对可以对客户端进行身份验证，这不是对大部分 SSL 所做的事情，因为该协议通常（或至少曾经）用于保护服务器身份验证很重要但对客户端这样做的电子商务站点不重要和/或不可行。您要做的是使用相互验证的 SSL，这样您的服务器将只接受来自您的应用的传入连接，并且您的应用只会与您的服务器通信。

这是高级方法。创建一个自签名服务器 SSL 证书并部署在您的 Web 服务器上。如果您使用的是 Android，您可以使用 Android SDK 中包含的 keytool 来实现此目的；如果您使用的是 iOS 等其他应用平台，也可以使用类似的工具。然后创建一个自签名客户端并将其部署在您的应用程序中作为资源包含在您的应用程序中的自定义密钥库中（keytool 也会生成它）。将服务器配置为要求客户端 SSL 身份验证并仅接受您生成的客户端证书。将客户端配置为使用该客户端证书来标识自己，并且只接受您在服务器上安装的一个服务器端证书。

如果您的应用程序以外的某人/某物尝试连接到您的服务器，则不会创建 SSL 连接，因为服务器将拒绝不提供您应用程序中包含的客户端证书的传入 SSL 连接。

一步一步的回答比这里保证的要长得多。我建议分阶段执行此操作，因为网络上有关于如何在 Android 和 iOS（服务器端和客户端）中处理自签名 SSL 证书的资源。我的书中还有一个完整的演练，Application Security for the Android Platform，由 O'Reilly 出版。

Answer 2

正如其他评论者已经提到的那样，SSL 确实具有两种身份验证。 但是，我认为您甚至不应该尝试对客户端（即应用程序）进行身份验证。您只对用户（Oauth 术语中的资源所有者）进行身份验证，而不是对代理或客户端进行身份验证。

事实上，移动应用程序无法隐藏任何秘密。因此，切勿将证书/密码放在设备上。典型的不良示例是将用户名和密码保存在某些系统密钥库中，例如 IOS 钥匙串。如果应用用户未在手机上设置密码，则整个密钥库以纯文本形式保存，任何人都可以转储所有信息。在应用程序中嵌入证书几乎和服务器不同，手机没有锁在机房里一样糟糕。人们确实会失去它们。

在此基础上，您需要一个基于令牌的解决方案，这样应用就不需要保留秘密。您传递秘密（用户登录凭据）并立即从内存中清除它们。您只需要持有令牌，令牌将是短暂的（30 分钟后到期等）

Oauth 2.0 隐式流旨在解决这个问题。然而，它远非完美。 Oauth 2.0 规范存在一些基本问题。特别是，实现此流程需要应用程序使用 UIWebView（嵌入式浏览器），这本身可能是不安全的和糟糕的用户体验。所以这几乎消除了所有基于重定向的流程。使用 OAuth 2 重定向流程的唯一知名应用程序是 facebook，它做得很糟糕。

OAuth 2.0 资源所有者流程是一种选择。通过这个流程，您的整个系统安全级别可以达到 B2C 解决方案——以基于浏览器的网上银行解决方案为例。这意味着任何拥有用户名密码的人都可以访问服务器上的资源——与基于浏览器的解决方案的安全级别相同。

但是，您仍然需要小心，如前所述，OAuth 2 规范存在一些基本问题——在这种情况下，你不能按照它的规范来实现令牌刷新逻辑——这通常涉及使用 never-过期刷新令牌——可以看作是 Google 的 OAuth 2 实现。然后，该令牌本身就变成了一个秘密——违背了使用 OAuth 的目的。

一种解决方法是根据上次活动自动更新令牌。

无论如何，移动应用安全并不是一个新话题，但遗憾的是，我们仍然没有任何标准工具/机制来解决这些独特的挑战。

这就是为什么银行支付数百万美元来开发他们的移动银行解决方案但仍然失败的原因(http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks/) ;-)

Answer 3

将客户端身份验证与 SSL 结合使用，或者仅在服务器身份验证 SSL 之上添加您自己的客户端身份验证（用户名/密码、令牌等）。

（编辑：将评论移到此处，因为它不适合作为评论）

详细说明一下，任何身份验证信息都需要存储或输入到应用程序中。如果每次都有人输入密码，则不需要保存，但这显然不方便。您可以使用特定于设备的密钥对其进行加密，因此它在有根设备上不可见。使用私钥，您需要使用用户输入的密码（见上文）来保护它，或者让它受到系统的保护。这仅在 Android 4.0 (ICS) 和系统密钥库的公共 API（KeyChain 类）之后才可用。在这种情况下，用户需要解锁（使用图案/密码或 PIN）手机才能访问密钥库。