通过移动应用确保沟通[真实性,隐私和完整性]？

Question

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

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

期望:对于密码等敏感信息足够安全,除了暴力破解之外,没有直接的解密方法.

我的要求:

• 身份验证[仅限应用程序]
• 完整性[不应在两者之间修改消息]
• 隐私[如果嗅闻,通讯不应该是可读的]

我的努力:

• SSL仅对服务器进行身份验证,而不是客户端.
• 我不能使用对称加密[仅提供隐私]
• 数字签名是不可能的[缺乏隐私]
• PGP满足所有3个要求.

问题:

• PGP需要在客户端应用程序上存储密钥.
• 似乎没有确保在客户端应用程序上保护密钥的方法.
• 如果密钥已关闭,则PGP或对称加密同样容易受到攻击.
• 反向工程PGP密钥或symmetic密钥同样困难.
• 在这种情况下,PGP是移动处理器上的无意义负担.
• OAuth再次无用,因为它也有一个客户端密钥.

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

我应该实施休闲方法:

• 使用简单的SSL并交叉我的手指？,如果密钥被盗,则无法进行身份验证？(此时只能进行服务器认证)

更新:

结论是使用AES,因为如果我能保持密钥安全,那么我就像SSL一样好.此外,我可以不断更改密钥,以提高安全性.如果您认为有更好的方法,请在发布之前阅读整篇文章.

Answer 1

你正在研究糟糕的信息.SSL可以绝对验证客户端,它不是为大量SSL做的事情,因为协议(或者,至少是)通常用于保护服务器身份验证很重要的电子商务站点但是对客户端这样做不重要和/或不可行.您要做的是使用经过相互身份验证的SSL,以便您的服务器只接受来自您应用的传入连接,并且您的应用只会与您的服务器通信.

这是高级方法.创建自签名服务器SSL证书并在Web服务器上部署.如果您使用的是Android,则可以使用Android SDK附带的keytool来实现此目的; 如果您正在使用像iOS这样的其他应用平台,那么它们也会存在类似的工具.然后创建一个自签名客户端,并在应用程序中将其作为资源部署在应用程序中包含的自定义密钥库中(keytool也会生成此内容).将服务器配置为要求客户端SSL身份验证,并仅接受您生成的客户端证书.将客户端配置为使用该客户端证书来标识自身,并且只接受您在服务器上安装的那个服务器端证书.

如果您的应用程序以外的某人/某些人尝试连接到您的服务器,则不会创建SSL连接,因为服务器将拒绝未显示您已包含在应用程序中的客户端证书的传入SSL连接.

这是一个循序渐进的答案,比这里所保证的要长得多.我建议分阶段执行此操作,因为网络上有关于如何在Android和iOS(服务器端和客户端)处理自签名SSL证书的资源.在我的书中,O'Reilly出版的Android平台应用程序安全性也有一个完整的演练.

Answer 2

SSL确实有其他评论者已经提到的双向身份验证.但是,我认为你甚至不应该尝试验证客户端,即app.您只能验证用户(Oauth术语中的资源所有者)而不是代理或客户端.

事实上,移动应用程序无法保守任何秘密.所以永远不要在设备上放置证书/密码.典型的错误示例是在某些系统密钥库中保存用户名和密码,例如IOS密钥链.如果应用程序用户未在手机上设置密码,则整个密钥库将以纯文本格式保存,任何人都可以转储所有信息.在应用程序中嵌入证书几乎同样糟糕,因为不像服务器,手机没有锁定在计算机房.人们确实失去了他们.

在此基础上,您需要一个基于令牌的解决方案,以便应用程序不需要保密.您传递秘密(用户登录凭据)并立即从内存中清除它们.你只需要持有令牌,这将是短暂的(30分钟到期等)

Oauth 2.0 Implicit flow旨在解决这个问题.然而,它远非完美.Oauth 2.0规范存在一些基本问题.特别是,实现此流程需要应用程序使用UIWebView(嵌入式浏览器),这本身可能是不安全和糟糕的用户体验.所以这几乎消除了所有基于重定向的流程.唯一众所周知的使用OAuth 2重定向流程的应用程序是facebook,它的表现非常糟糕.

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

但是,如前所述,您仍需要小心,OAuth 2规范存在一些基本问题 - 在这种情况下,您无法遵循其规范来实现令牌刷新逻辑 - 通常涉及使用永不过期的刷新令牌 - 可以将其视为Google的OAuth 2实施.那个令牌本身就变成了秘密 - 破坏了使用OAuth的目的.

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

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

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