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

Question

Android/Iphone应用程序将从服务器访问应用程序数据。 [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连接。

一步一步来回答这个问题要比这里要长得多。我建议分阶段这样做，因为web上有关于如何在Android和iOS中处理自签名SSL证书的资源，包括服务器端和客户端。我的书Application Security for the Android Platform中也有一个完整的介绍，由O'Reilly出版。

Answer 2

使用SSL进行客户端身份验证，或者在服务器身份验证SSL的基础上添加自己的客户端身份验证（用户名/密码、令牌等）。

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

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

Answer 3

SSL确实有其他注释者已经提到的双向身份验证。 但是，我认为你甚至不应该尝试验证客户端，也就是应用程序。您只对用户（Oauth术语中的资源所有者）进行身份验证，而不是对代理或客户端进行身份验证。

事实上，移动应用程序不能保守任何秘密。所以千万不要把证书/密码放在设备上。典型的错误示例是将用户名和密码保存在一些系统密钥库中，例如IOS密钥链。如果应用程序用户没有在手机上设置密码，则整个密钥库将以纯文本保存，任何人都可以转储所有信息。在应用程序中嵌入证书几乎和服务器一样糟糕，移动电话不会被锁在机房中。人们确实会失去他们。

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

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

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

但是，您仍然需要小心，如前所述，OAuth 2规范有一些基本问题——在本例中，您不能遵循它的规范来实现令牌刷新逻辑——这通常涉及使用永不过期的刷新令牌——这可以看作是Google的oauth2实现。然后，这个令牌本身就变成了一个秘密——破坏了使用OAuth的目的。

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

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

这就是为什么银行支付数百万美元去做他们的移动银行解决方案，但是他们仍然失败了（http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks/） ；-）