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