gpt4 book ai didi

android - Android:解密过程需要很多时间

转载 作者:行者123 更新时间:2023-11-29 23:06:01 34 4
gpt4 key购买 nike

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

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)


初始化方法的执行在0到2毫秒内完成。

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

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方法将引发异常。

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

最佳答案

AndroidKeyStore总是比进程中的键操作要慢得多。

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

当您在AndroidKeyStore中进行密钥生成时,会发生什么情况(大致;硬件绑定程序调用下的所有内容均取决于实现,因此您必须与设备制造商联系以了解详细信息):


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


我认为可以改进AndroidKeyStore的性能,但从根本上讲,它必须比进程内密钥生成做更多的事情,并且所有这些IPC都需要时间。

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

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

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

与移动CPU相比,StrongBox设备通常更小,速度更慢。原始速度通常会慢两个数量级,尽管它们可以通过专用的加密加速器硬件部分抵消。这意味着,如果您使用KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true),则预期不会是40毫秒,而是400毫秒,甚至1000毫秒。另一方面,从StrongBox设备中提取任何秘密都是非常困难的。如果国家情报机构足够重视的话,他们可能会尽力而为。能力不强的人可能确实会度过非常艰难的时光。

(顺便说一句:如果要提高性能,则应考虑转储旧的慢速RSA。EC的速度要快得多。不幸的是,如果需要非对称加密,AndroidKeyStore尚不支持使用EC进行加密/解密,而仅支持签名/验证但是,如果可以通过对称加密来解决,则AES和HMAC比EC和RSA都快得多。)

(此外:我是Google工程师,自API级别23开始负责AndroidKeyStore。)

关于android - Android:解密过程需要很多时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56526038/

34 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com