为什么Android密钥管理员在Android 9中记录DROPBOX_ENTRY_ADDED事件?

时间:2018-12-20 00:26:04

标签: java android encryption broadcastreceiver android-keystore

我正在使用一个处理一些敏感数据的Android应用程序,因此,无论何时我对存储进行写入或读取操作,都严重依赖加密。在Android API 27及以下版本中,此方法运行良好且非常快。但是,我注意到,在API 28(Android 9 Pie)中,解密操作明显较慢。

看着我的logcat,我发现一条新邮件被发送了数百次垃圾邮件:

2018-12-19 16:20:10.564 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
2018-12-19 16:20:10.565 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver
2018-12-19 16:20:10.588 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
2018-12-19 16:20:10.588 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver
2018-12-19 16:22:54.580 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.stats.service.DropBoxEntryAddedReceiver
2018-12-19 16:22:54.580 1233-1260 W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.DROPBOX_ENTRY_ADDED flg=0x10 (has extras) } to com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver

似乎每个解密操作都会生成android.intent.action.DROPBOX_ENTRY_ADDEDcom.google.android.gms/.stats.service.DropBoxEntryAddedReceiver com.google.android.gms/.chimera.GmsIntentOperationService$PersistentTrustedReceiver尝试处理。这似乎要花费大量时间,并且在使用Android Pie之前不是问题。为了量化,我在API23中对这些相同的解密操作进行了基准测试,平均运算时间约为3毫秒。 Android Pie上完全相同的代码需要60到90毫秒,但速度要慢20到30倍。疯。当我的应用启动时,这一点尤其明显,因为它需要解密数百个小字符串才能加载一些用户数据。在Android Pie上,我的应用程序启动时间现在大约需要整整10秒钟,而在Logcat中向该消息发送垃圾邮件的过程中一直如此。

我生成了一个错误报告,并寻找了一些有趣的东西,我看到了:

  Service com.google.android.gms.stats.service.DropBoxEntryAddedService:
    Process: com.google.android.gms
    Running op count 34:
      SOn /Norm: +12s205ms
          TOTAL: +12s205ms
    Started op count 17:
      SOn /Norm: +12s118ms
          TOTAL: +12s118ms
    Executing op count 652:
      SOn /Norm: +2s737ms
          TOTAL: +2s737ms

我不确定如何读取此输出,但与此同时(或并非如此),此服务的总运行时间几乎恰好是我的应用程序现在启动所花费的时间。

接下来,我想看看这些消息中包含什么内容,因此我在有根的模拟器上运行它并执行了dumpsys dropbox keymaster --print

========================================
2018-12-19 18:32:04 keymaster (data, 52 bytes)
/data/system/dropbox/keymaster@1545262324865.dat

========================================
2018-12-19 18:32:04 keymaster (data, 52 bytes)
/data/system/dropbox/keymaster@1545262324880.dat

========================================
2018-12-19 18:32:05 keymaster (data, 53 bytes)
/data/system/dropbox/keymaster@1545262325142.dat

在保管箱中有数百个此类条目。查看生成的实际文件,我发现前几个似乎是合理的:获取提供程序,加载AndroidKeystore,生成我的密钥,然后进行数百个完全相同的事件:

AES�IMPORTED2NONEBCTRHRdecrypt

这是非ASCII记录,因此十六进制转储看起来像这样:

0000000 0a 03 41 45 53 10 80 01 1a 08 49 4d 50 4f 52 54
0000010 45 44 32 04 4e 4f 4e 45 42 03 43 54 52 48 01 52
0000020 07 64 65 63 72 79 70 74                        
0000028

无论这可能有多有趣,它都使我无法接近实际问题或解决方案。为什么在Android 9中会发生这种情况?每次执行解密操作时广播看似无用的消息有什么意义?我该如何预防?其他人有没有经历过?

添加更多细节:

  • 使用AndroidKeystore进行密钥存储
  • CipherInputStreamCipherOutputStreamAES/CTR/NoPadding一起使用
  • 用户第一次启动应用程序时,先使用SecretKey然后使用KeyGenParameterSpec.Builder来生成AES KeyGenerator.generateKey()
  • 随后的应用启动会使用密钥别名从AndroidKeystore加载密钥
  • SecretKey条目引用由加密帮助程序类保存。并非每次加密/解密操作都会加载它
  • 使用上面的SecretKey参考和AES/CTR/NoPadding的Cipher实例,为每个加密操作创建一个新密码

我很乐意回答任何后续问题。对我来说这是一个严重的问题,有关此“功能”的Google文档绝对没有用。

0 个答案:

没有答案