我正在观察我们的iOS/Android移动应用程序与我们的RESTful web服务API之间的通信。从服务器端,我必须假设我收到的任何东西都是可疑的。我猜想移动应用程序可能是反向设计的,秘密/私钥,等等。
假设我们正确地进行了HMAC保护的对称密钥通信,当我接收、认证和解密加密消息时,我知道该消息是由拥有我们共享密钥的人发送的。
当然,这条消息可能来自获得该秘密密钥的攻击者。
我想知道在密钥管理领域是否有解决这个问题的正式协议或最佳实践:作为接收者,我是否能够检测到共享的秘密已经或可能已经被泄露了?我认为答案是不,没有这样“容易”的解决办法。但如果有答案,我想知道!
我怀疑在密钥管理领域没有答案。这实际上是“当发送者是我们从应用商店下载的移动应用程序时,如何验证消息的发送方?”
在私钥妥协后使签名有效讨论从受信任的第三方时间戳提供程序嵌入安全时间戳。当我假设攻击者可以做任何被破坏的移动应用程序时,我不认为这会有帮助。这就是web服务的本质。
在观察了我们的Web服务API的攻击者(S)之后,我正在寻找改进我们的安全体系结构的方法。我不想问一些含糊不清的事情,以致于毫无用处!
这是我所了解的情况。我们渴望得到推荐。
我们有一个相对高流量的网站(由Alexis美国排名前1500),已经有很多年了。这意味着我们在保护“正常”网站和攻击者流量方面有很强的经验。
我们发现连接到我们的移动应用程序的RESTful app是一个完全不同的领域。很可能我没有问对的问题。我还没有真正理解问题的空间!
所有API流量都通过HTTPS。我相信我们的传输层安全是正确的,因为这是我们“常规”网站体验的一部分。
攻击者正确地使用具有正确身份验证令牌等的web服务。在此之前(注意到特定的攻击集),我们的API流量是HTTPS上的纯文本。我们在苹果和Google商店都有iOS和安卓的移动应用程序。移动应用程序的开发在我们的控制之下。
由此我们得出结论,攻击者能够观察到我们的超文本HTTPS移动应用程序流量。或者我们的攻击者反向设计了我们的移动应用程序(考虑到需要更高的技术水平,这不太可能)。
因此,我认为我们需要改善的地方:
我不想问这样一个公开的问题,但我能否获得关于这些安全改进的建议/参考呢?在过去的一周里,我问了几个问题,收到了很好的建议,但这并不意味着我还能完全理解问题的空间!
发布于 2015-09-16 17:21:20
作为接收者,我是否可以检测到共享的秘密已经或者可能已经被泄露了?
简而言之:不管你在公开发布的应用程序中放了什么,你都会隐式地与攻击者分享,而(S)他一次都不会告诉你,他提取了这些秘密信息。
细节:在场景中,您描述的秘密被嵌入到应用程序中,从而隐式地与任何能够下载您的应用程序的人共享。由于共享密钥的分布范围很广(仅为模糊的),您必须考虑到它要么已经被破坏,要么将被破坏,至少如果在使用预期用例之外的密钥时有一些有价值的东西可以获得。
可能检测明确妥协的唯一方法是,如果密钥显然是在应用程序之外使用的话。您可以使用异常检测方法来检测到这一点。但是,如果你没有察觉到妥协--这并不意味着密钥不被泄露,它可能仅仅意味着黑客比你聪明,并且隐藏了足够聪明的活动,这样你的异常检测就不会捕捉到它。
https://security.stackexchange.com/questions/100403
复制相似问题