Android: 解密过程花费大量时间

Android: Decryption process is taking lot of time

当我们使用以下代码创建密钥集时:

val generator = KeyPairGenerator.getInstance(RSA)
generator.initialize(KEY_SIZE)
val keyPair = generator.genKeyPair()

然后当我们调用如下:

val cipher = Cipher.getInstance(RSA_TRANSFORMATION)
cipher.init(Cipher.DECRYPT_MODE, privateKey)

init 方法执行在 0-2 毫秒内完成。

但是当我们尝试使用以下方法创建密钥时,因为我们需要将私钥存储在密钥库中:

val keyPairGenerator = KeyPairGenerator.getInstance("RSA", "AndroidKeyStore")
        keyPairGenerator.initialize(keyGenParameterSpecBuilder.getProvider()
                .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_RSA_OAEP)
                .setDigests(KeyProperties.DIGEST_SHA1)
                .setKeySize(KEY_SIZE)
                .build())

        keyPairGenerator.genKeyPair()

同一个init方法执行时间超过35-40毫秒。此外,如果我们注释 setEncryptionPaddings 和 setDigest,init 方法会抛出异常。

预期输出: 能够将私钥存储在 KeyStore 中并在 0-2 毫秒内执行 init 方法,就像没有提供程序生成器一样。

AndroidKeyStore 总是比进程内键操作慢得多。

当您执行进程内密钥生成时会发生什么是对 BoringSSL 加密库的 JNI 调用。没有 IPC 调用,没有上下文切换等。BoringSSL 将对内核进行一些系统调用以获取随机位(来自 /dev/random),并且有可能触发对硬件真随机数生成器的一些调用的可能性很小,但不会很多。

当您在 AndroidKeyStore 中生成密钥时会发生什么(大致;硬件活页夹调用下面的所有内容都依赖于实现,因此您必须与您的设备制造商联系以了解详细信息):

  • 您的进程对 Keystore 进程进行活页夹调用,这可能会启动一个线程来处理您的请求。
  • 密钥库从 /dev/random 中获取一些随机位。
  • Keystore 调用 Keymaster HAL 服务的硬件绑定器。
  • 服务将密钥生成请求格式化为消息并将其写入字符设备节点,该节点调用内核驱动程序。
  • 内核驱动程序将请求连同一些控制数据复制到缓冲区中并调用 SMC 指令。
  • 处理器挂起 Linux 并跳转到安全监视器处理程序,检查一堆东西,然后将处理器切换到安全模式。
  • 受信任的 OS 内核开始执行,从传输缓冲区读取控制数据,识别应该接收它的受信任应用程序并调用它。
  • 受信任的应用程序解析请求消息并生成您的密钥,通过从硬件真随机数生成器中读取并安全地将熵与密钥库(来自 /dev/random)提供的位混合来获取必要的随机位。
  • 受信任的应用程序然后使用硬件绑定密钥加密密钥,并将结果写入响应缓冲区和 returns 控制给受信任的 OS。
  • 受信任的OS写入一些控制数据并调用SMC指令。
  • 处理器暂停受信任的 OS 并跳转到安全监视器处理程序,它检查一堆东西,然后将处理器切换出安全模式。
  • Linux内核开始执行,内核驱动returns数据通过字符设备节点。
  • HAL服务从字符设备节点读取数据。
  • HAL 服务通过硬件绑定器解析数据并returns它。
  • Keystore 接收加密密钥包并将其写入文件(与您提供的别名相关联)。
  • Keystore 生成自签名证书并将其写入另一个文件。
  • Keystore returns 通过活页夹的结果状态。

我认为 AndroidKeyStore 的性能可以改进,但从根本上说,它必须比进程内密钥生成多 很多,而且所有这些 IPC 都需要时间.

用额外的时间换取的是更高的安全性。使用进程内加密,破坏您的应用程序的攻击者可以获得私钥的副本,然后可以用它做任何他们喜欢的事情。借助 AndroidKeyStore,破坏您的应用程序的攻击者可能能够像您的应用程序一样使用密钥,但他们无法从设备中提取密钥,因此他们无法在其他任何地方使用它。此外,如果您对它的使用方式添加了一些限制(例如,仅当用户进行身份验证时),那么攻击者就无法违反这些限制。

即使攻击者不仅危害您的应用程序,而且危害密钥库守护程序、HAL 服务,甚至 Linux 内核本身,这些安全保证仍然有效。要真正提取密钥,攻击者必须破坏受信任的应用程序或受信任的 OS。这并非不可能(完全不可能),但要困难得多。

为了完整起见,我还应该提到 KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true),在 API 级别 28 中可用。在支持 StrongBox 的设备上(目前不多,但这会改变)您的密钥将不会生成在受信任的 OS 运行 中,在主要 CPU 的安全模式下,它将在专用的安全处理器中生成——嵌入式安全元件或类似的——称为"StrongBox"。 StrongBoxes 不得与主 CPU 共享处理器、RAM 或其他重要资源,并且必须由经认可的测试实验室针对直接渗透、侧信道、故障等的安全性进行正式评估。

StrongBox 设备通常比移动 CPU 设备更小、处理器更慢。原始速度通常慢两个数量级左右,尽管它们使用专用加密加速器硬件部分抵消了这一点。这意味着,如果您使用 KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true),您预期的不是 40 毫秒,而是 400 毫秒,或者可能是 1000 毫秒。另一方面,从 StrongBox 设备中提取任何秘密都非常困难。如果国家情报机构足够关心,他们可能会努力做到这一点。任何能力不如他的人都可能会过得很艰难。

(顺便说一句:如果你想提高性能,你应该考虑放弃旧的、慢速的 RSA。EC 更快。不幸的是,如果你需要非对称加密,AndroidKeyStore 还不支持 encryption/decryption使用 EC,只有 signing/verification。但是,如果您可以使用对称加密,AES 和 HMAC 比 EC 和 RSA 快得多。)

(旁白:我是 Google 工程师,从 API 23 级开始负责 AndroidKeyStore。)