[关闭]
@1qaz 2016-08-08T13:44:58.000000Z 字数 1194 阅读 1104

Analysis of Secure Key Storage Solutions on Android

未分类


spsm 14

束博士

攻击模型

  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种攻击情形。

尝试在没有用户交互的情况下使用key

结果

  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
添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注