Android KeyStore， KeyStore TA （一）

Android KeyStore是比较小众的一个模块，随着移动互联网安全的日益突出，

这个模块就可以值得研究研究。

KeyStore使用 

Android上的Keystore目前主要分为两类分别是BKS和AndroidKeyStore。 BKS是一个对Java中的

加密库Bouncy Castle精简后的版本，其剔除了一些向创建证书等开发者为很少在Android上使用的功能。

而如果应用中需要使用到相关功能时也可以自行导入完整的BouncyCastle，为防止名称冲突其在

Android中称之为Spongy Castle。一般BKS将密钥存储在文件中。 AndroidKeyStore是从Android4.3

开始引入进来的。可以通过 KeyStore. getInstance

(“AndroidKeyStore”)或KeyPairGenerator.getInstance(algorithm,provider)来使用。开发者通

过他可以自己创建与管理只属于该应用自身的密钥，目前公开的API只允许使用非对称加密算法的密钥与证书。

KeyChain 

从4.0（API 14）开始Android引入了一个新的类android.security.KeyChain。该类向外界提供了一个

能够访问和存储系统范围内全局证书的接口。在这之前，这些证书只有系统级的WIFI和VPN等少

数应用可以访问。该类为BYOD（Bring Your Own Device）之类的服务提供了很大的便利，使得PKI等

技术可以方便的应用在Android系统之上。Android同时还提供了一套UI，第三方应用要访问证书时，

会自动调用该UI来让用户来选择是否允许以及具体访问哪一个证书。

 

KeyMaster 

以前keystore服务将密钥管理与加密服务通过一个软件来实现，自4.1开始Android引入一个新的

HAL（hardwareabstraction layer）模块keymaster，其专门负责创建非对称密钥，同时还可以

在其内部完成数据的签名与验证工作，这样省去了将密钥导出给外部的过程从而加强了密钥的安全性。

keymaster的引入不仅减轻了keystore的任务同时也方便了后续引入硬件级的密钥存储，与硬件加密模块。

对于不支持硬件加密与硬件存储密钥的设备，Android加入一个softkeymaster的模块来通过软件的方

式使用OpenSSL的库处理相应的密钥操作。AndroidKitkat之前密钥使用的是RSA的2048bit的

密钥，Kitkat开始支持DSA（Digital Signature Algorithm）和ECDSA（EllipticCurve DSA）密钥且大小可自己指定。 

目前keymaster支持的操作有：generate_keypair,import_keypair, 

sign_data, verify_data, get_keypair_public, delete_keypair,delete_all。

https://blog.csdn.net/innost/article/details/44199503

 

 一个APP有两种方式和Android Keystore交互。一种是利用JCE的KeyStore接口，并

强制使用“AndroidKeyStore“作为Provider的名字。这样，JCE就会创建AndroidKeyStore对象。

当然，这个对象也就是个代理，它会创建另外一个KeyStore对象。这个KeyStore就是

android.security.KeyStore。虽然名字一样，但是包名却不同，这个是android特有的。

·        另外一条路是使用Android提供的KeyChain API。KeyChain我觉得从“Key和

CertificatesChain的意思”来理解KeyChain的命名可能会更加全面点。KeyChain会和

一个叫KeyChainService的服务交互。这个KeyChainService又是运行在“keychain“进程里的。

keychain进程里也会创建android.security.KeyStore对象。

·        再来看android.security.KeyStore（以后简称AS Store，而JCE里的，我们则简称JSStore）。

好吧，binder无处不在。AS（AndroidSecurity） Store其实也是一个代理，它会

通过binder和一个native的进程“keystore“交互。而keystore又会和硬件中的SEE

（SecurityElement Enviroment）设备交互（ARM平台几乎就是Trust Zone了）。高通平中，

SEE设备被叫做QSEE。keystore进程会加载一个名叫“libQSEEComAPI.so”的文件。

为什么要搞这么复杂？

·        KeyChain其实简化了使用。通过前面的例子大家可以看到，JCE其实用起来是很麻烦的，而且

还要考虑各种Provider的情况。而且，通过KeyChain API能使用系统级别的KeyStore，而且还有

对应的权限管理。比如，不是某个APP都能使用特定alias的Key和Chain的。有一些需要用户确认。

·        而更重要的功能是把硬件key managment功能融合到AS Keystore里来了。这在普通的JCE中是

没有的。硬件级别的KM听起来（实际上也是）应该是够安全的了：）