尝试英译中机翻我们总结的 API Key 相关经验文档… 尽量说人话 😊
情景
假设我们要发布一个基于 ArcGIS Maps SDK 的 app，并使用 API Key 来授权各种地图服务。API Key 的费用取决于接口调用的使用量。正常用户越多，产生的用量就越大，成本也就越高。没毛病——我们当然希望有更多用户。然而，假设某个黑客（bad actor）决定窃取我们的密钥，如果他能够利用某个漏洞获取这个 API Key，那么他的使用量最终也会算在我们的账单上。
不应该直接把密钥硬编码（hard-code）进 app 里，主要有两个原因：
- API Key 可能会被黑客从二进制文件中被提取出来
- 当需要更换 API Key 时，不用非得重新发一个新版本
API Key 会过期，但一般有效期比较长。假如我们创建密钥的时候设置了一年到期，那么黑客就可以白嫖将近一年。
API Key 过期又带来了第二个问题。如果 API Key 被硬编码在应用中，那么过期后 app 也会停止工作。这会造成两个后果：
- 我们必须在 API Key 失效之前重新发布应用
- 所有用户都必须马上升级到新版，否则 app 不能用
简而言之，硬编码密钥的弊端：
- 如果被盗白嫖，会造成额外开销
- 一旦过期，app 就不能用了
弱点分析
- 硬编码在二进制文件中的密钥
如果在代码中直接硬编码一个字符串，那么这个字符串最终会被编译进应用的二进制文件中。一旦黑客获得了没混淆的二进制文件，其中所有的字符串字面量（string literals）都可以轻松读取。
App Store 上的 app/ipa 可以下载，然后 dump 里面的字符串。我试过用 Apple Configurator 之类的工具下载已经发布的应用，并通过这种方式提取出了其中的 API Key。尽管二进制文件包含大量的字符串，但如果攻击者知道自己要找的字符串的特征，那么找到 API Key 往往并不困难。
- 通过网络传输的密钥
即使我们设法保护了二进制文件中的密钥，或者应用通过其他方式获得了密钥——例如从一个 Web 服务安全地下载密钥——仍然存在另一个疏漏。那就是：一旦我们真正开始使用这个 API Key，它就必须通过网络传输。
通常情况下，数据会通过 HTTPS/TLS 进行传输。这通常意味着我们拥有网络安全中的 C.I.A. 三要素：
- Confidentiality（机密性）：只有预期的接收者才能看到发送的数据
- Integrity（完整性）：数据在传输过程中没有被修改
- Authentication（身份认证）：消息被预期的接收者接收
对于用户密钥（user secrets）而言，这种机制很有效。
但在本文讨论的场景中，情况恰恰相反：开发者希望保护密钥，不让黑客获取；问题关键在于，“用户”自己就是那个黑客。用户可以安装类似 Proxyman 和 Charles 的代理工具，并安装代理工具提供的证书，从而使所有进出设备的流量都可以被代理工具解密。这种攻击被称为 “中间人攻击”（Man-in-the-Middle Attack，MitM）。
这意味着 API Key 可能会在传输过程中被泄露。
降低风险
由于上面介绍的两种问题，长期有效的密钥很难做到绝对安全。可以通过一些方法来降低风险。但是打的补丁越多，开发者的工作量也会增加。
按照弱点的类型，分别介绍对策。
二进制文件中的密钥
混淆（Obfuscation）
如果选择将密钥直接嵌入应用或代码中，那么应用发布之后，我们无法彻底阻止黑客找到这个字符串。不过，我们可以对它进行混淆。通过混淆，可以让密钥难以直接被搜到。黑客需要一定的技术水平，才能反编译应用逻辑，弄清楚字符串是如何被混淆的，然后再将其还原。
这种方法无法彻底保护密钥，但可以显著增加获取密钥的难度。
目前有一些可用于混淆的开源库。例如，对于 Swift 应用，可以使用 swift-confidential。
从服务器下载密钥
更好的方案是：别把密钥硬编码在代码里。开发者工作量会增加一些，但其安全优势对比硬编码来说相当明显。
问题来了：如何保证只有自己的应用才能访问存密钥的服务器？
一种方式是让用户登录某个服务器，然后通过用户身份认证来控制访问权限。这意味着开发者需要在应用中建立用户体系；同时搭建一个能够处理身份认证的服务器。很多应用不需要用户体系，或者搭建鉴权框架过于复杂，所以这个方案并不适合所有应用。
另一种方法是使用 Apple 的 App Attest Framework 或 Google 的 Integrity API。这是一种可以通过密码学手段，确保只有合法且未经修改的应用版本才能访问服务的技术。
从易用性和安全地向应用获取 API Key 的角度来看，这是一个非常不错的方案：用户不需要进行任何操作，所有过程都在后台自动完成。
当然，这要求我们作为开发者：
- 在应用端编写代码来完成 attestation（应用真实性证明）
- 在服务器端编写代码来验证这个 attestation
此外，还有一些第三方库和框架可以替开发者完成 Apple App Attest 或 Google Integrity API 的大量工作。其中一个例子就是 Google 的 Firebase App Check。
这是一个不错的选择，因为搭建一个项目以及一个受到 App Check 保护的 Firebase 云函数步骤相对简单。
这种方案安全性很高，但也存在一些缺点：
- API Key 过期后，需要在服务端更新
- 需要支付服务费用
- 如果不使用 Firebase 这样的第三方服务，而是自己编写 attestation 逻辑，那么整个实现过程会比较复杂
当我们已经安全地获得了密钥，应用也可以使用之后，我们仍然需要解决另一个问题：密钥使用时，依然需要通过网络传输。
通过网络传输的密钥
TLS Pinning
防止中间人攻击的一种方法，是使用 TLS Pinning（也称 SSL pinning 或者 Certificate Pinning）。
这种技术要求我们对应用进行配置，使其只与指定的目标域名通信。
具体来说，我们需要在应用代码中“固定”（pin）目标服务器的证书；或者更准确地讲，固定该证书对应的公钥（public key）。因为证书已经被固定，代理服务器或中间人就没办法解密网络流量。如果中间人试图篡改流量，那么发送到被固定域名的请求也会直接失败。
从密码学角度来看，这是一个安全性很高的方法。
不过，这种方案也存在一些缺点，主要集中在应用的开发维护方面：
- 如果服务器证书轮换（certificate rotation）或过期后导致公钥发生变化，那么应用必须发一个新版，更新里面的证书后才能继续正常工作
- 如果我们希望保护多个子域名，就还需要知道这些子域名所使用的全部公钥
- 如果黑客水平足够高，把应用给逆向工程了，他也还是可能绕过 TLS Pinning。当然，这种可能性很小啦
这和处理过期 API Key 时面临的问题非常类似：产生变化之后要发新版，而用户则需要升级到最新版本才能用。另外，对于不属于我们的域名和服务器，好比 arcgis.com，维护的麻烦程度进一步增加。
由于我们的应用通常需要将 API Key 传输给一个不属于我们的服务器，例如 arcgis.com，因此 TLS Pinning 带来的维护成本往往超过了它所提供的安全收益。有没有一种更好的办法，可以同时避免上面提到的两种漏洞？如果不把密钥硬编码进应用，同时我们也不需要通过网络传输一个长期有效的密钥，该怎么办？
更好的方案
ArcGIS OAuth 2.0 Application Credential
OAuth 2.0 Application Credential 是一种短期有效的 Token（令牌）。生成这个 Token 需要两项信息：
- Client ID（客户端 ID）
- Client Secret（客户端密钥）
有了这两项信息，我们就可以调用一个服务，动态生成 Token。我们仍然必须保护 Client ID 和 Client Secret，不能让黑客获取。因此，不能硬编码进代码里。
虽然我们仍然不希望真正的 Token 落入黑客手中，但 Token 是短期有效的，因此即使 Token 被盗，攻击者能够利用它的时间也是有限的。
Firebase App Check
借助 Firebase 和 Firebase App Check，我们可以创建一个 Firebase Cloud Function，让它负责为我们生成短期有效的 Token，也就是 ArcGIS OAuth 2.0 Application Credential。这个 Token 生成服务可以受到 App Check 的保护，从而确保只有我们的应用才能访问。
Client ID 和 Client Secret 都存储在服务器上，从来不会在应用与服务器之间通过网络传输。这意味着我们的密钥可以免受 MitM 攻击。
整个方案中：
- 密钥没有嵌入应用；
- 密钥不会通过网络被嗅探劫持
- 应用只获取短期有效的 Token
有什么缺点？
- 和前面介绍 App Check 时一样，需要花钱买这些 Firebase 之类的服务
- 此外，虽然长期密钥得到了保护，但短期 Token 本身仍然有可能通过 MitM 被嗅探。不过正如前面所说，这个 Token 的有效期很短，因此攻击者能够利用它的时间也是有限的
未来方向
理想情况下，我们希望 ArcGIS Online / Enterprise 能够提供一种 App Verification Credential。它的使用方式可以类似于目前创建 OAuth 2.0 Application Credential 的方式。这种新的 Credential 类型可以配置各种权限。在创建 Credential 时，需要提供 App Attest 或 Google Integrity 所需的信息。例如，对于 iOS App Attest，需要提供：
- Team ID
- Bundle ID
然后，系统可以提供一个 Endpoint ，用于生成一个短期有效的 Token，并且这个 Endpoint 只能由提供了 ID 的应用调用。
这样一来，在 Native Maps SDK 中，我们就可以提供一个 AppVerificationCredential，并将 App Attest 或 Google Integrity 的客户端实现逻辑全部内置进去。这将是一个非常理想的方案。
它可以提供：
- 短期有效的、基于使用量的 API Token
- 短期有效的、基于会话的 Session Token
开发者不需要自己托管服务器，同时整个方案由 Apple 和 Google 的密码学技术提供安全保障，也不需要开发者自己编写复杂的客户端代码。
从实现所需要的工作量来看，服务端逻辑确实比较复杂，但绝非无法完成。与其让每一个用户都自己编写这些代码，不如由我们统一实现。
相关链接
- Video showing how to use swift-confidential for obfuscation
- App Attest documentation
- WWDC26: Secure your apps with App Attest | Apple
- WWDC21: Mitigate fraud with App Attest and DeviceCheck
- Google Integrity API documentation
- Older article on Secret Management in iOS
- Protecting APIs with DeviceCheck, App Attest & WebAuthn - Oliver Binns
