最佳实践：Android KeyStore 使用哪些 AES 设置答案

【问题标题】：Best Practice: Which AES settings to use for Android KeyStore最佳实践：Android KeyStore 使用哪些 AES 设置
【发布时间】：2019-07-30 21:01:26
【问题描述】：

Android KeyStore 提供了可用ciphers 的完整列表，这让我想到了以下问题：在 2019 年使用哪种组合是最佳实践？每种组合似乎都有其自身的一系列缺点，而且作为非安全专家，真的很难决定使用哪一种。

一些背景资料：我正在开发一个连接到 API 的基于 Kotlin 的 Android 应用程序。用户必须提供一对用户名：密码来向 API 进行身份验证，然后 API 将返回一个十六进制的不记名令牌以供将来进行身份验证。与 API 的连接已经过 TLS 加密，因此此处无需额外加密。问题是安全地存储信息。用户名以及密码和不记名令牌必须安全存储。这个问题的一个常见解决方案似乎是加密凭证并通过 Preferences API 存储它们。由于加密只发生在应用程序内部，不需要交换密钥，因此对称密钥加密看起来不错。

【问题讨论】：

您想在您的设备上存储您的用户名并加密传递吗？或者你是在问你应该如何加密它们以将它们发送到服务器？
我想在设备上存储用户名、密码和不记名令牌。

标签： android encryption kotlin aes keystore

【解决方案1】：

TL; DR：首选AES/GCM/NoPadding。永远不要使用AES/ECB/*。

在您的情况下，您会更喜欢经过身份验证的对称加密，而在您链接的列表中提供此功能的唯一选项是 AES/GCM/NoPadding。

这对您来说的好处是，您的数据不仅被加密，而且还不会被篡改 - 如果有人或某物修改了存储的数据，当您尝试解密它时会出现异常。其他列出的模式没有此属性。这意味着存储的密文可能会被修改而您不知道 - 它可能会或可能不会仍然解密（我说可能会或可能不会，因为它可能会在其他情况下引发异常，例如修改后的错误填充）。

缺点（也不是很多）是您必须确保您永远不会同时使用相同的密钥和随机数。如果你这样做了——并且攻击者可以访问或查看两组不同的密文——他们破解和解密就变得微不足道了。解决此问题的最简单方法是简单地始终生成随机随机数。在遇到任何问题之前，您将能够加密 2^96 次！

如果您因任何原因不能或不想使用AES/GCM/NoPadding，请从AES/CTR/NoPadding 或AES/CBC/PKCS7Padding 中进行选择。两者都有自己的缺点。您需要找到一种方法来防止自己篡改（通常使用 HMAC）。我更喜欢AES/CTR/NoPadding，因为它与AES/GCM/NoPadding 非常相似（至少可以使用）。

最后，不要使用任何与欧洲央行相关的东西。 欧洲央行表现不佳。

【讨论】：

非常感谢您这么详细的回答！不过，我还有 2 个问题： 1. nonce 是否与 IV 相同？我应该如何存储 IV？对 IV 进行 Base64 编码并将其附加到密文（我认为在某些示例代码中已经看到）是否安全？ 2. AES/GCM/NoPadding中IV的长度限制为96bits。这对密钥的长度有什么影响？我可以结合例如一个 256 位 AES 密钥和一个 96 位 IV/Nonce？提前致谢！
@AHahn94 nonce 和 IV 或多或少是一样的。一种常见的方法是在密文前面加上 nonce，然后 then base64 编码，尽管如果你可以简单地存储为字节，那会更好。随机数和密钥根本不交互。它们的大小相对于彼此根本不会影响操作（或安全）。