如何在 Android 上安全地存储硬编码 API 密钥？

Question

在我的 Android 项目中，我想以安全的方式存储 API 密钥。该密钥是从应用程序外部生成的，需要在构建应用程序之前以某种方式存储在应用程序中。

我已经看到了一些如何使用 KeyStore 的示例（例如this或this），但据我了解，这些是存储运行时生成的密钥的解决方案，而不是我将存储在代码中某处的密钥。

我还检查了此处解释的其他方法，但由于逆向工程，它们看起来可以很容易地检索 API 密钥。

我也不想将我的密钥存储在我的代码中，也是因为它可以通过逆向工程轻松检索。

其目的是能够在每次调用我制作的网络服务时发送该密钥，因此我确定（或几乎确定）该调用来自我正在制作的原始应用程序，这将是在 Play 商店上发布，而不是从其他地方发布。

我远不是安全专家，所以任何帮助将不胜感激。

谢谢。

Answer 1

您的挑战

其目的是能够在每次调用我制作的网络服务时发送该密钥，因此我确定（或几乎确定）该调用来自我正在制作的原始应用程序，这将是在 Play 商店上发布，而不是从其他地方发布。

这是一项非常艰巨的任务，但并非不可能，因此需要深入研究移动 API 安全性并了解其背后的机制。

清楚地了解API 请求中的参与者与发出 API 请求的内容之间的差异至关重要，否则您可能设计/使用的任何安全解决方案都可能无法达到预期结果。

WHO 和 WHAT 之间的区别是访问 API 服务器

我撰写了一系列有关 API 和移动安全的文章，并在文章《为什么您的移动应用程序需要 Api 密钥？》中 您可以详细阅读访问 API 服务器的人员和内容之间的区别，但我将在此摘录其中的主要内容：

向 API 服务器发出请求的是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 等工具手动探查您的 API 服务器？

我们可以通过多种方式（例如使用 OpenID Connect 或 OAUTH2 流）对移动应用程序的用户进行身份验证、授权和识别。

因此，您需要考虑谁作为您的 API 服务器的用户能够对数据进行身份验证和授权访问，并且您需要考虑代表用户发出该请求的软件是什么。

逆向工程

我也不想将我的密钥存储在我的代码中，也是因为它可以通过逆向工程轻松检索。

确实如此，根据用于隐藏 API 密钥的方法，它或多或少容易实现，正如您提到的那样：

我还检查了此处解释的其他方法，但由于逆向工程，它们看起来可以很容易地检索 API 密钥。

无论 API 密钥存储得多么安全，无论是在 Android 密钥库中、加密、混淆等，在某些时候，API 密钥都需要以纯文本形式在 API 请求标头上发送，而此时它很容易通过静态逆向工程、MitM 攻击或仪器框架被提取

我写了一篇文章如何使用静态二进制分析从移动应用程序中提取 API 密钥来说明它是多么容易完成：

可用于逆向工程的开源工具种类繁多，在本文中我们确实无法触及这个主题的表面，但我们将重点关注使用移动安全框架（MobSF）来演示如何对我们的移动应用程序的 APK。MobSF 是开源工具的集合，它们在有吸引力的仪表板中展示其结果，但是 MobSF 和其他地方在幕后使用的相同工具可以单独使用以实现相同的结果。

在本文中，我们将使用Android Hide Secrets研究存储库，它是一个虚拟移动应用程序，使用多种不同的技术隐藏 API 密钥。

我还写了另一篇文章来在运行时实现它，通过中间人攻击窃取 Api 密钥：

为了帮助演示如何窃取 API 密钥，我在 Github 上构建并发布了适用于 Android 的货币转换器演示应用程序，该应用程序使用我们在早期Android Hide Secrets应用程序中使用的相同JNI/NDK技术来隐藏 API 密钥。

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

还可以在运行时使用检测框架来挂钩使用 API 密钥的代码以提取它。例如流行的Frida 框架：

将您自己的脚本注入黑盒进程。挂钩任何函数、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，然后立即看到结果。全部无需编译步骤或程序重新启动。

因此，无论采取什么措施来保护 API 密钥，一旦它出现在 API 请求上，就很容易被提取。

移动 API 安全

任何在客户端运行并且需要一些秘密才能访问 API 的内容都可能以不同的方式被滥用，您可以在有关移动 API 安全技术的本系列文章中了解更多信息。本文将教您如何使用 API 密钥、用户访问令牌、HMAC 和 TLS Pinning 来保护 API 以及如何绕过它们。

可能的解决方案

我建议您阅读我针对“How to secure an API REST for mobile app?”问题给出的答案。，特别是“强化和屏蔽移动应用程序” 、“保护 API 服务器安全”和“可能的更好解决方案”部分。

移动应用程序证明可以解决您的问题，这将使您的后端知道发出请求的确实是您的移动应用程序的真实且未经篡改的版本，正如您希望实现的那样：

其目的是能够在每次调用我制作的网络服务时发送该密钥，因此我确定（或几乎确定）该调用来自我正在制作的原始应用程序，这将是在 Play 商店上发布，而不是从其他地方发布。

您想加倍努力吗？

在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。

对于APIS

OWASP API 安全性前 10 名

OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建并维护十大 API 安全风险文档，以及创建或评估 API 时最佳实践的文档门户。

对于移动应用程序

OWASP 移动安全项目 - 十大风险

OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

OWASP - 移动安全测试指南：

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