Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

ASM: A Programmable Interface for Extending Android Security

论文下载

攻击模型

  1. 恶意app attcker
  2. root attacker:exploit,require root privilege
  3. Intercepting root attacker:root,通过查看内存来劫持用户输入

key存储的解决方案

  1. Bouncy Castle: keystore默认的provider
  2. AndroidKeyStore: API level 18, 厂商可以开发驱动支持硬件存储,没有驱动可用时软件实现。不支持用户提供密码

细分: 1. Bouncy Castle using a stored password 2. Bouncy Castle using a user-provided password 3. AndroidKeyStore using the TEE on Qualcomm 4. AndroidKeyStore using the TEE on TI devices 5. AndroidKeyStore using software-fallback

安全需求: 1. App-binding:只有特定设备上的特定应用能使用key 2. Device-binding: 只能在特定设备上使用 3. User-consent require:只有用户UI同意使用key

方法

  • 硬件支持:Keychain中的isBoundKeyAlgorithm 检查RSA/ECDSA/DSA
  • 生成RSA key pair,用私钥签名,另一个instance用公钥验证,考虑3种攻击情形。

结果

  1. Bouncy Castle using a stored password:
    • JAVA keystore的api不提供导出原始key的功能, password加密方式
    • pbe-WithSHAAnd3-KeyTripleDES-CBC
    • root attcker能拿到password和keystore文件
  2. Bouncy Castle using a user-provided password
    • 需要攻击者能够劫持UI输入的passwrod
    • 爆破password
  3. AndroidKeyStore using the TEE on Qualcomm
    • /data/misc/keystore/user_0/uid_type_alias
    • root只要重命名文件就能使用其他app的key
  4. AndroidKeyStore using the TEE on TI devices
    • actual format is unknown,TEE
  5. AndroidKeyStore using software-fallback

建议

  1. AndroidKeyStore 加入password保护
  2. keystore文件中加入uid做完整性校验,避免root直接重命名
  3. 没有PIN时AndroidKeyStore也加密, key可以来自device id,just harder

Fig

Fig

Fig