Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Breaking Into the KeyStore: A Practical Forgery Attack Against Android KeyStore

论文下载

Mohamed Sabt,Jacques Traore,Orange Labs,Sorbonne University France,ESORICS 2016

ABSTRACT && INSTRUCTIONS

Keystore是安卓存储用户凭据和密钥的系统服务,作者证明其加密模式不能提供完整性保证,并提出了利用该漏洞的伪造攻击,伪造一个弱密钥来欺骗app

Background

  • Android从4.3引入Keystore,允许应用生成、使用、存储密钥;密钥进入Keystore后无法被提取。Google在实现时,使用认证加密(AE)来保护key的完整性和保密性,但是使用的加密模式并没有遵循任何标准。
  • Hash-then-CBC-Encrypt: CBC-Enc( MD5(M)||M )

主要贡献:

  1. 证明 Hash-then-CBC-Encrypt模式不能提供认证性,且与哈希算法无关
  2. 提出一个伪造攻击的场景:app将对称密钥存储在keystore中,攻击者伪造了存储的密钥密文,app读取的密钥长度变小(HMAC,256->32)

实际的系统经不起简单的密码分析。

认证加密一个简单的实现是“带冗余的加密”, 消息M算一个checksum h(M),然后将M和h(M)加密. Broken,见 Wagner Bellare.

Hash-then-CBC-Encrypt

定义:对称加密、不可区分性、CBC、密文完整性、密文不可伪造性。。。

  • Hash-then-CBC-Encrypt is not IND-CCA secure

Fig

Fig

Fig

Android Keystore

  • Android 1.6 credential store,VPN and WiFi EAP
  • 实现版本:android-6.0.1 r22

Fig

  • 只有keymaster能直接访问到key,防止泄漏(?keystore.cpp)
  • key在keymaste之外的形式:Public API中的alias,Keystore service中的keyhandler
  • keyhandler格式:Soft Key Magic || Key Type || Key Length || Key.

Keystore service

root@generic_x86:/data/misc/keystore/user_0 # ls -al
ls -al
-rw------- keystore keystore       84 2016-07-22 00:31 .masterkey
-rw------- keystore keystore      820 2016-07-22 00:31 1000_USRCERT_aaa
-rw------- keystore keystore      804 2016-07-22 00:31 1000_USRPKEY_aaa
  • 128bit的masterkey由/dev/urandom生成,锁屏密码和随机的盐经过PBKDF2生成128bit的passwordAeskey加密
  • masterkey,存储为.masterkey(4.3上的masterkey是不加密的)

  • metadata || CBC-Encrypt(MD5(keyhandler)||keyhandler)

  • metadata格式 version type flag info

Attacking the Android Keystore

威胁模型和安全假设:

  1. malware on device:能向keystore导入key, 能读写/data/misc/keystore目录
  2. 锁屏密码足够强
  3. 禁止keystore存储短密钥 见1
  4. 攻击者控制流量

Fig

  • ε’(M)=ε(length(M)||M)

攻击者在导入key时,系统看到的是padding||M’‘,大于32字节。例如攻击者可以选择4字节的M,导入了一个32+4=36字节的key,攻击者在截取密文后就成了4字节的key

Man in the Keystore

流程:

  • 预备阶段:恶意app执行keystore伪造过程,导入32+x字节的对称密钥,(对奇怪的长度没有做检查),将加密后的文件截断,实际密钥只有x字节
  • 哄骗阶段:正常app请求Keystore生成key,恶意app观察到keystore生成文件这一过程,将自己之前生成的文件重命名,重命名后的文件被认为是属于正常app的
  • 攻击阶段:正常app向服务器传输信息,为了保证完整性,请求keystore为消息生成HMAC tag,keystore使用弱key生成了tag。消息和tag被网络中的攻击者截获,暴力破解HMAC key,修改消息

建议

  1. Hash-then-CTRencrypt 也不能保证完整性
  2. Encrypt-then-MAC mobile计算力有限
  3. GCM

  • 攻击者截断密文后不知道对应明文?不同app的加密key可能不一样?
  • keystore可以存储不加密的内容
  • 正常app使用key时不会发现长度不对?
versoin type flag info iv ENC(md5(data)||data) salt
0000000: 0202 0110 3e40 e04a 928e 4988 c0f8 61d9  ....>@.J..I...a.
0000010: 243d e565 c089 5ad9 e2e7 ce25 c1a1 33cf  $=.e..Z....%..3.
0000020: 5aa3 22fa ff79 96bd 3d66 a5f9 0020 7046  Z."..y..=f... pF
0000030: abca 389a 898e 67b9 4c71 0340 d39e 8dea  ..8...g.Lq.@....
0000040: 3ede c4e8 94ea 62e4 503c 78f9 069f a6c1  >.....b.P<x.....
0000050: ceb9 7506                                ..u.