如何在Android App中保护密钥?

FloJ12

我的Android应用程序具有excel导出和导入功能,最近我想通过添加写保护密钥来确保其安全。首先,我将硬编码的密钥放在源代码中,但是显然由于反向工程,这根本不安全。我读了很多书,我认为我的解决方案现在是安全的,但是我不确定。您能否看一下并指出可能的警告?

  1. 想要导出excel的用户必须使用带有Google登录名的Google帐户登录。
  2. 我的应用请求Google的登录令牌(已通过SHA签名验证)
  3. 登录令牌已发送到我的服务器(HTTPS POST)
  4. 我的服务器验证令牌是Google验证的有效令牌。文档:https : //developers.google.com/identity/sign-in/android/backend-auth
  5. 以JSON格式发送回应用程序帐户信息和excel导出机密(HTTPS POST)
  6. 应用程序使用密码保护Excel工作表并将其导出。

只能再次导入使用提供的密码导出的Excel工作表。

我还具有PDF导出功能。PDF应由应用签名。该过程与之前相同,但是使用包含私有和公共密钥作为base64字符串的pkcs密钥。

植根设备怎么样,攻击者能否获得发送的密码/ pkcs密钥?

Exadra37

可能的注意事项

我读了很多书,我认为我的解决方案现在是安全的,但是我不确定。您能否看一下并指出可能的警告?

乍一看:

  1. 从私钥离开您的后端服务器的那一刻起,它就属于公共域,因此必须将其视为已泄露。
  2. 该移动应用程序正在制定重要决策,签署文档并验证其签名,并且可以在运行时使用Frida和xPosed之类的检测框架来绕过此操作。
  3. 后端服务器仅在认证请求的用户,而不是什么它发出请求。

1.私钥

  1. 以JSON格式发送回应用程序帐户信息和excel导出机密(HTTPS POST)

该过程与之前相同,但是使用包含私有和公共密钥作为base64字符串的pkcs密钥。

私有密钥可以保持私有的唯一方法是将其安全地存储在要使用的位置,我强烈建议在使用它的相同位置(也就是同一台服务器)生成它。

私钥离开后端服务器的那一刻起,它就不再安全地存储,并且现在任何具有技能和知识的人都可以使用它来使用大量开源和付费工具进行逆向工程静态二进制文件,甚至进行内部检查。在运行时,并更改其行为或提取数据(也称为私钥)

对于静态二进制分析,我们有一个开源工具MobSF,该工具在幕后结合了其他几个开源工具,这些工具可以反编译,分析和提取静态二进制文件中的数据。

移动SF

移动安全框架(MobSF)是一种自动化的多合一移动应用程序(Android / iOS / Windows)可以进行静态和动态分析的笔测试,恶意软件分析和安全评估框架。MobSF支持移动应用程序二进制文件(APK,IPA和APPX)以及压缩的源代码,并提供REST API以与CI / CD或DevSecOps管道无缝集成。动态分析器可帮助您执行运行时安全性评估和交互式检测。

关于运行时,可以使用FridaxPosed挂钩到使用私钥的代码位置,并将其提取到攻击者服务器。

弗里达

将自己的脚本注入黑盒进程。挂钩任何功能,监视加密API或跟踪私有应用程序代码,不需要任何源代码。编辑,点击保存,立即查看结果。全部没有编译步骤或程序重新启动。

x位置

Xposed是一个框架,使用户可以轻松地将附件(称为模块)应用于ROM。您无需使用新的ROM来获取特定功能,而可以使用Xposed将单个功能添加到正在使用的ROM中,甚至仅添加到常用ROM中。

2.应用程式内决策

  1. 应用程序使用密码保护Excel工作表并将其导出。

只能再次导入使用提供的密码导出的Excel工作表。

正如我之前在此答案中已经提到的那样,Frida和XPosed可用于在运行时自检和检测代码。

攻击者可以使用其中一种工具来挂接表明文档是否正确签名的功能,然后始终返回true,从而绕过移动应用程序代码中随附的所有预期安全机制。这是我之前提到的在运行时使用Frida或xPosed提取私钥的一种替代方法。

3.谁与什么在访问后端服务器

  1. 想要导出excel的用户必须使用带有Google登录名的Google帐户登录。
  2. 我的应用请求Google的登录令牌(已通过SHA签名验证)
  3. 登录令牌已发送到我的服务器(HTTPS POST)
  4. 我的服务器验证令牌是Google验证的有效令牌。文档:https : //developers.google.com/identity/sign-in/android/backend-auth

这4个步骤只能识别在请求,通过换言之,请求是为取得了用户,但不提供任何形式的识别是什么做出在用户的代表请求。

有关更深入的解释,建议您阅读我撰写的文章,特别是以下部分:您是否知道与Api服务器进行通讯的对象和对象之间的区别?

是移动应用,我们可以验证,授权和以多种方式确定,比如使用OpenID登录连接或流的oauth2的用户。

什么是发出请求到服务器API的东西。它确实是您的移动应用程序的真正实例,还是机器人,自动化脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上戳戳?

您可能会感到惊讶,攻击者经常是您的真正用户试图绕过系统。

可能的解决方案

警告1

要解决警告1,您必须始终将私钥保留在您的后端服务器中,并且永远不要在对移动应用程序的任何响应中发送该私钥

警告2

需要说明的2可以通过不签署或移动应用验证的文件来解决,而不是你在后端服务器做,你必须确保你的后端服务器知道什么它发出请求。

警告3

需要说明的3它已经部分解决了,一旦你已经知道是在请求中,你只需要实现一个强大的解决方案,以知道什么它使用户代表该请求。

找出最常见的方式是什么它发出请求到后台服务器,它在请求的报头使用一个秘密,那你可能是知道的APi-KeyAccess-Token或选择任何其他的名字,但你可以看到这种方法它是如何的在“与一名中间人攻击窃取Api密钥”一文中轻松地绕过了中间人攻击(MitM)

因此,在本文中,您将学习如何设置和运行MitM攻击以在您控制的移动设备中拦截https流量,以便您可以窃取API密钥。最后,您将在较高层次上看到如何缓解MitM攻击。

一个更强大的解决方案可以被使用,其中一个在另一台服务器证明了移动应用程序的完整性,这将允许后端服务器时,在信任知道什么发出请求,而这一概念是由移动应用认证闻名。

移动应用程序认证服务的角色进行了更详细的文章,我写的解释,在部分移动应用认证的作用

移动应用程序认证服务的作用是进行身份验证什么是发送请求,因此只响应来自真正的移动应用程序实例来请求,并拒绝未经授权来源的所有其他请求。

为了知道是什么向API服务器发送了请求,移动应用程序证明服务在运行时将高度确定您的移动应用程序是否存在,尚未被篡改/重新打包,是否未在根目录下运行设备,尚未被检测框架(Frida,xPosed,Cydia等)钩住,也不是中间人攻击(MitM)的对象。这是通过在后台运行SDK来实现的,该SDK将与在云中运行的服务进行通信以证明其运行的移动应用程序和设备的完整性。

在成功证明移动应用程序完整性后,将发布并使用一个秘密的短期生存JWT令牌进行签名,该秘密只有云中的API服务器和移动应用程序证明服务才能知道。在证明失败的情况下,将使用错误的机密对JWT令牌进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密,因此即使在应用程序被篡改,在有根设备中运行或通过连接通信时,也无法在运行时对其进行反向工程这是MitM攻击的目标。

移动应用必须在每个API请求的标头中发送JWT令牌。这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名并且尚未到期时才服务请求。所有其他请求将被拒绝。换句话说,有效的JWT令牌会告诉API服务器发出请求的是上传到Google或Apple商店的真正的移动应用程序,而无效或丢失的JWT令牌则意味着发出请求的内容无权这样做,因为它可能是机器人,重新包装的应用程序或发起MitM攻击的攻击者。

虽然构建自己的Mobile App Attestation服务并不容易,但由知识渊博的工程师团队进行操作是可行的,并且要记住的主要一点是,SDK不执行任何决策,只是响应于由Microsoft提出的随机挑战服务器,它是负责决定移动应用程序完整性的人。

结论

您目前的防御措施要比最初的防御措施要好,并且您还有改进的余地,在提高移动应用程序和后端服务器的安全性方面应该付出多少努力,可能需要与规范您所做工作的法律相平衡。您和您的团队可以使用的知识和资源,并与保护资产的价值成正比。

最后,我强烈建议您解决第1和第2条警告,并尝试第3条警告。

走得更远

我一直想向您推荐这份非常有价值的资源《OWASP移动安全性测试指南》

移动安全测试指南(MSTG)是用于移动应用安全开发,测试和逆向工程的综合手册。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章