深入理解Android之Java Security（第二部分，最后）
代码路径：
- Security.java：libcore/lunl/src/main/java/java/security/
- TrustedCertificateStore.java：libcore /crypto/src/main/java/org/conscrypt/
- CertInstallerMain:package/apps/CertInstaller/src/com/android/certinstaller/
- CredentialHelper:package/apps/CertInstaller/src/com/android/certinstaller/
- CertInstaller:package/apps/CertInstaller/src/com/android/certinstaller/
- CredentialStorage.java:package/apps/Settings/src/com/android/settings/
- OpenSSLRSAPrivateKey.java:libcore/crypto/src/main/java/org/conscrypt/
- OpenSSLEngine.java:libcore/crypto/src/main/java/org/conscrypt/
- OpenSSLKey.java:libcore/crypto/src/main/java/org/conscrypt/
二 Android Key/Trust Store研究
下面我们来看看Android Key/Trust Store方面的内容。这里就会大量涉及代码了.....。
根据前述内容可知，Android Key/Trust Store是系统全局的Key/Trust Store。虽然Android符合JCE/JSSE规范，但是Android平台的实现和一般PC机上的实现有很大不同。
我们先来看KeyStore的架构，如图16所示：
图16 Android KeyStore架构
图16中：
- 一个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（Security Element 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听起来（实际上也是）应该是够安全的了：）
关于SEE和TrustZone，图17给了一个示意图：
图17 TrustZone示意图[16]
简单点看，ARM芯片上其实跑了两个系统，一个是Android系统，另外一个是安全的系统。Android系统借助指定的API才能和安全系统交互。
提示：关于TrustZone，请童鞋们参考[13],[14][15]。
言归正传，我们马上来看AS KeyStore相关的代码。如下是分析路线：
- 导入前面例子中反复提到的test-keychain.p12文件到系统里去，看看这部分的流程。
- 在示例中使用KeyChain API获取这个文件中的Private Key和CA信息。
- 删除系统中的根CA信息。这部分和Trust Store有关（请读者自行研究吧！）
2.1 p12文件导入系统流程
2.1.1 触发PKCS12文件导入
在DemoActivity.java中有一个importPKCS12函数，代码如下所示：
[-->DemoActivity.java::importPKCS12]
void importPKCS12(){
//根据Android的规定，导入证书等文件到系统的时候，直接把文件内容通过intent发过去就行
//所以我们要先打开”test-keychain.p12”文件，也就是KEYCHAIN_FILE
BufferedInputStream bis =new BufferedInputStream(getAssets().open(
KEYCHAIN_FILE));
byte[] keychain = newbyte[bis.available()];
bis.read(keychain);
/*
调用KeyChain API中的createInstallIntent。根据KeyChain.java代码，该Intent
的内容是：
action名：android.credentials.INSTALL
目标class的包名：com.android.certinstaller
目标class为com.android.certinstaller.CertInstallerMain
*/
Intent installIntent = KeyChain.createInstallIntent();
//Android支持两种证书文件格式，一种是PKCS12，一种是X.509证书
installIntent.putExtra(KeyChain.EXTRA_PKCS12, keychain);
//指定alias名，此处的ENTRY_ALIAS值为“MyKey Chain”
installIntent.putExtra(KeyChain.EXTRA_NAME,ENTRY_ALIAS);
启动目标Activity，其实就是CertInstallerMain
startActivityForResult(installIntent, 1);
}
当处理完毕后，DemoActivity的onActivityResult会被调用。那个函数里没有什么特别的处理。我们先略过。
2.1.2 CertInstallerMain的处理
唉，Android里边除了前面讲到的keychain.apk外，还有一个专门用于导入证书的certinstaller.apk。真够麻烦的。来看CertInstallerMain的代码
[-->CertInstallerMain.java::onCreate]
protected void onCreate(Bundle savedInstanceState) {
.......//启动一个线程，然后运行自己的run函数
new Thread(new Runnable(){
public void run() {
......
runOnUiThread(CertInstallerMain.this);
}
}).start();
}
[-->CertInstallerMain.java::run]
public void run() {
Intent intent = getIntent();
String action = (intent ==null) ? null : intent.getAction();
//我们发出的Intent的Action就是INSTALL_ACTION
if (Credentials.INSTALL_ACTION.equals(action)
||Credentials.INSTALL_AS_USER_ACTION.equals(action)) {
Bundle bundle =intent.getExtras();
......
if (bundle == null ||bundle.isEmpty() || (bundle.size() == 1
&&(bundle.containsKey(KeyChain.EXTRA_NAME)
||bundle.containsKey(Credentials.EXTRA_INSTALL_AS_UID)))) {
//安装方式有两种，一种是搜索SDCard/download目录下面的证书文件，凡是后缀名
//为.crt/.cet/.p12/.pfx的文件都能被自动列出来。用户可选择要安装哪个文件
} else {
//由于我们发出的Intent已经包含了证书文件内容，所以此处再启动一个Activity就好
Intent newIntent =new Intent(this, CertInstaller.class);
newIntent.putExtras(intent);
startActivityForResult(newIntent,REQUEST_INSTALL_CODE);
return;
}
} else if (Intent.ACTION_VIEW.equals(action)) {
......//除了安装，列举系统已经安装的证书文件也是通过CertInstall这个apk来完成的
}
finish();
}
2.1.3 CertInstaller的处理
（1） 安装准备
[-->CertInstaller.java::onCreate]
protected void onCreate(Bundle savedStates) {
super.onCreate(savedStates);
//CredentialHelper是一个关键类，很多操作都是在它那完成的
mCredentials = createCredentialHelper(getIntent());
mState = (savedStates ==null) ? STATE_INIT : STATE_RUNNING;
if (mState == STATE_INIT) {
if(!mCredentials.containsAnyRawData()) {
toastErrorAndFinish(R.string.no_cert_to_saved);
finish();
} else if (//判断这次的安装请求是否对应一个PKCS12文件。显然，本例符合这个条件
mCredentials.hasPkcs12KeyStore()) {
//PKCS12文件一般由密码保护，所以需要弹出一个密码输入框
showDialog(PKCS12_PASSWORD_DIALOG);
} else {
......//其他操作
}
......
}
整个CertInstaller.apk中，核心工作是交给CredentialHelper来完成的。createCredentialHelper就是构造了一个CredentialHelper对象，我们直接来看构造函数：
[-->CredentialHelper.java::CredentialHelper]
CredentialHelper(Intent intent) {
Bundle bundle =intent.getExtras();
......
//取出Alias名，本例是“My Key Chain”，保存到成员mName中
String name =bundle.getString(KeyChain.EXTRA_NAME);
bundle.remove(KeyChain.EXTRA_NAME);
if (name != null) mName= name;
//我们没有设置uid，所以mUid为-1
mUid =bundle.getInt(Credentials.EXTRA_INSTALL_AS_UID, -1);
bundle.remove(Credentials.EXTRA_INSTALL_AS_UID);
//取出bundle中其他的key-value值。除了名字，其他的key就是EXTRA_PKCS12了
for (String key :bundle.keySet()) {
byte[] bytes =bundle.getByteArray(key);
mBundle.put(key, bytes);
}
//如果bundle中包含证书内容，则解析该证书。本例没有包含证书信息
parseCert(getData(KeyChain.EXTRA_CERTIFICATE));
}
安装时候，会判断此次安装是否为PKCS12文件，如果是的话，需要弹出密码输入框来解开这个文件。判断的代码是：
[-->CredentialHelper.java::hasPkcs12KeyStore]
//判断bundle是否包含EXTRA_PKCS12参数，本例是包含的
boolean hasPkcs12KeyStore() {
returnmBundle.containsKey(KeyChain.EXTRA_PKCS12);
}
（2） 密码输入对话框处理
来看密码输入框代码，核心在
[-->CertInstaller.java:: createPkcs12PasswordDialog]
private Dialog createPkcs12PasswordDialog() {
View view =View.inflate(this, R.layout.password_dialog, null);
mView.setView(view);
......
String title =mCredentials.getName();
......
Dialog d = newAlertDialog.Builder(this).setView(view).setTitle(title)
.setPositiveButton(android.R.string.ok,
new DialogInterface.OnClickListener(){
public voidonClick(DialogInterface dialog, int id) {
Stringpassword = mView.getText(R.id.credential_password);
//构造一个Action，把密码传进去。Pkcs12Extraction其实就是调用
//CertInstaller的extractPkcs12InBackground函数
mNextAction = new Pkcs12ExtractAction(password);
mNextAction.run(CertInstaller.this);
}})....create();
...
return d;
}
图18所示为这个密码框：
图18 密码框
注意这个对话框的Title，“Extracfrom”后面跟的是Alias名。按了OK键后，代码执行Pkcs12ExtractAction的run，其内部调用就是CertInstaller的extractPkcs12InBackground。
[-->CertInstaller.java::extractPkcs12InBackground]
voidextractPkcs12InBackground(final String password) {
// show progress bar andextract certs in a background thread
showDialog(PROGRESS_BAR_DIALOG);
newAsyncTask<Void,Void,Boolean>() {
@Override protectedBoolean doInBackground(Void... unused) {
//解码PKCS12文件
return mCredentials.extractPkcs12(password);
}
@Override protected voidonPostExecute(Boolean success) {
MyAction action = new OnExtractionDoneAction(success);
if ......
else action.run(CertInstaller.this);//执行CertInstaller的onExtractionDone
}
}.execute();
}
解码PKCS12文件的核心代码在CredentialHelper的extractPkcs12函数中。这个函数其实和我们前面示例提到的testKeyStore几乎一样。
[-->CredentialHelper.java:: extractPkcs12Internal]
private boolean extractPkcs12Internal(String password) throwsException {
//下面这段代码和testKeyStore示例代码几乎一样
java.security.KeyStore keystore =
java.security.KeyStore.getInstance("PKCS12");
PasswordProtection passwordProtection =
new PasswordProtection(password.toCharArray());
keystore.load(newByteArrayInputStream(getData(KeyChain.EXTRA_PKCS12)),
passwordProtection.getPassword());
Enumeration<String>aliases = keystore.aliases();
......
while(aliases.hasMoreElements()) {
String alias =aliases.nextElement();
KeyStore.Entry entry =keystore.getEntry(alias, passwordProtection);
if (entry instanceof PrivateKeyEntry) {
//test-keychain.p12包含的就是一个PrivateKeyEntry
return installFrom((PrivateKeyEntry)entry);
}
}
return true;
}
extractPkcs12Internal看来只处理PrivateKeyEntry，核心在installFrom函数中，如下：
[-->CredentialHelper.java::installFrom]
private synchronized boolean installFrom(PrivateKeyEntry entry) {
//私钥信息
mUserKey = entry.getPrivateKey();
//证书信息
mUserCert = (X509Certificate) entry.getCertificate();
//获取证书链，然后找到其中的根证书，也就是CA证书
Certificate[] certs = entry.getCertificateChain();
Log.d(TAG, "# certsextracted = " + certs.length);
mCaCerts = newArrayList<X509Certificate>(certs.length);
for (Certificate c : certs){
X509Certificate cert =(X509Certificate) c;
//在本例中，证书链就包含一个证书，所以mUserCert和certs[0]是同一个。
//下面这个isCa函数前面没介绍过。它将解析X509Certificate信息中的
//”Basic Constraints”是否设置“Certificate Authority”为“Yes”，如果是的话
//就说明它是CA证书
if (isCa(cert)) mCaCerts.add(cert);
}
return true;
}
总之，installFrom执行完后，我们得到一个PrivateKey，一个证书，和一个CA证书。当然，这两个证书是同一个东西。
注意，JCE似乎没有提供合适的API来判断一个Certificate是不是CA证书。但是有一些实却实现了这个函数。感兴趣的童鞋可参考isCa的处理。
提取完pkcs12文件后，在onExtractoinDone里，系统又会弹出一个框，告诉你刚才那个文件里都包含什么东西。如图19所示：
图19 证书改名对话框
这个对话框其实是让我们修改别名。当然，图里还能让你设置这个私钥等是干什么用的：
- 一个是用于VPN，另外一个是用于APP。
- 图中最后展示了这个证书包含的东西，有一个key，一个证书和一个CA证书。
（3） 别名修改对话框
[-->CertInstaller.java::createNameCredentialDialog]
private Dialog createNameCredentialDialog() {
ViewGroup view =(ViewGroup) View.inflate(this,
R.layout.name_credential_dialog,null);
mView.setView(view);
......
mView.setText(R.id.credential_info,
mCredentials.getDescription(this).toString());
final EditText nameInput =(EditText)
view.findViewById(R.id.credential_name);
if ......
else {
final Spinner usageSpinner= (Spinner)
view.findViewById(R.id.credential_usage);
usageSpinner.setOnItemSelectedListener(new OnItemSelectedListener() {
@Override
public voidonItemSelected(AdapterView<?> parent, View view, int position,
long id) {
switch ((int) id) {
//图19中的VPN和APP，对应就是设置使用范畴，默认是VPN+APP，也就是系统层面都可以用
case USAGE_TYPE_SYSTEM:
mCredentials.setInstallAsUid(KeyStore.UID_SELF);//UID_SELF为-1
break;
case USAGE_TYPE_WIFI:
mCredentials.setInstallAsUid(Process.WIFI_UID);
break;
......
} }});}
nameInput.setText(getDefaultName());//获取默认alias名
nameInput.selectAll();
Dialog d = newAlertDialog.Builder(this)
.setView(view).setTitle(R.string.name_credential_dialog_title)
.setPositiveButton(android.R.string.ok, new
DialogInterface.OnClickListener(){
public voidonClick(DialogInterface dialog, int id) {
String name =mView.getText(R.id.credential_name);
if ......
else {//用户在这里有机会修改这个alias名。注意，一旦从文件中提取出证书并安装
//到系统中的话，以前那个pkcs12文件的password和alias名都不在需要了！
mCredentials.setName(name);
try {
startActivityForResult(//安装这些个key啊，证书
mCredentials.createSystemInstallIntent(),
REQUEST_SYSTEM_INSTALL_CODE);
} ...
}
}
})....create();
return d;
}
最终导入到系统KeyStore的地方其实还不是在CertInstaller里完成的，而是由Settings！怎么启动Settings呢？关键在createSystemInstallIntent中。
[-->CredentialHelper.java::createSystemInstallIntent]
Intent createSystemInstallIntent() {
Intent intent = newIntent("com.android.credentials.INSTALL");
intent.setClassName("com.android.settings",
"com.android.settings.CredentialStorage");
//mUid=-1
intent.putExtra(Credentials.EXTRA_INSTALL_AS_UID, mUid);
try {
if (mUserKey != null) {
intent.putExtra(Credentials.EXTRA_USER_PRIVATE_KEY_NAME,
Credentials.USER_PRIVATE_KEY + mName);
intent.putExtra(Credentials.EXTRA_USER_PRIVATE_KEY_DATA,
mUserKey.getEncoded());
}
if (mUserCert != null) {
intent.putExtra(Credentials.EXTRA_USER_CERTIFICATE_NAME,
Credentials.USER_CERTIFICATE + mName);
intent.putExtra(Credentials.EXTRA_USER_CERTIFICATE_DATA,
Credentials.convertToPem(mUserCert));
}
if (!mCaCerts.isEmpty()) {
intent.putExtra(Credentials.EXTRA_CA_CERTIFICATES_NAME,
Credentials.CA_CERTIFICATE + mName);
X509Certificate[]caCerts
=mCaCerts.toArray(new X509Certificate[mCaCerts.size()]);
intent.putExtra(Credentials.EXTRA_CA_CERTIFICATES_DATA,
Credentials.convertToPem(caCerts));//将所有CA Certs转换为PEM格式保存
}
return intent;//返回这个Intent，用于启动Settings中的对应安装步骤！
} ...
}
我们要装三个东西到系统里，一个PrivateKey，一个证书，一个CA证书。在createSystemInstallIntent函数中，会单独为这三个东西设置一个特殊的名字：
- PrivateKey：用“Credentials.USER_PRIVATE_KEY+ mName”组合，本例中对应的名字是”USRPKEY_My KeyChain”
- Certifcate：用“Credentials.USER_CERTIFICATE+ mName”组合，本例中对应的名字是” USRCERT_My KeyChain”
- CACert：用“Credentials.CA_CERTIFICATE+mName”组合，本例中对应的名字是” CACERT_My KeyChain”。
如代码所示，最终的处理将交给Settings来完成。此时，我们已经测试和最开始的pkcs12文件没有关系了，比如打开pkcs12文件的密码，默认的alias（用户可以修改，本例中我们没有改！）。
2.1.4 Settings处理安装
Settings中相关处理代码位于CredentialStorage中，主要处理函数是handleUnlockOrInstall：
[-->CredentialStorage.java::handleUnlockOrInstall]
private void handleUnlockOrInstall() {
......
/*
mKeyStore就是传说中的AS KeyStore了。它有几个状态，最开始是UNINITIALIZED，
只有我们为它设置了密码，它才会变成LOCKED状态。这个密码和用户的锁屏界面解锁有关系
系统会把解锁时使用的密码传递给AS Store以初始化（或者修改新密码）。
LOCKED:AS Store被锁了，需要弹出解锁框来解锁
UNLOCKED：已经解锁，可直接安装
*/
switch (mKeyStore.state()) {
case UNINITIALIZED: {//未初始化，将提醒用户设置密码。
ensureKeyGuard();
return;
}
case LOCKED: {//锁了，请输入解锁密码
new UnlockDialog();
return;
}
case UNLOCKED: {//已经解锁
if(!checkKeyGuardQuality()) {
newConfigureKeyGuardDialog();
return;
}
installIfAvailable();
finish();
return;
}
}
}
installIfAvailable将进行安装。有对UNINTIALIZED流程感兴趣的童鞋不妨自己研究下相关代码。Anyway，用户设置的密码最终会调用AS KeyStore的password函数。回头我们还要来看这其中的处理。
先来看installIfAvailable。
[-->CredentialStorage.java:: installIfAvailable]
private void installIfAvailable() {
if (mInstallBundle != null&& !mInstallBundle.isEmpty()) {
Bundle bundle =mInstallBundle;
mInstallBundle = null;
final int uid = bundle.getInt(Credentials.EXTRA_INSTALL_AS_UID, -1);
//私钥导入到AS KeyStore
if(bundle.containsKey(Credentials.EXTRA_USER_PRIVATE_KEY_NAME)) {
String key =bundle.getString(Credentials.EXTRA_USER_PRIVATE_KEY_NAME);
byte[] value = bundle.getByteArray(
Credentials.EXTRA_USER_PRIVATE_KEY_DATA);
int flags =KeyStore.FLAG_ENCRYPTED;//加密标志
......
mKeyStore.importKey(key, value, uid, flags);
}
int flags = (uid ==Process.WIFI_UID) ? KeyStore.FLAG_NONE :
KeyStore.FLAG_ENCRYPTED;
//导入证书
if(bundle.containsKey(Credentials.EXTRA_USER_CERTIFICATE_NAME)){
String certName =
bundle.getString(Credentials.EXTRA_USER_CERTIFICATE_NAME);
byte[] certData =bundle.getByteArray(
Credentials.EXTRA_USER_CERTIFICATE_DATA);
//证书导入，调用AS KeyStore put函数
mKeyStore.put(certName, certData, uid, flags);
}
//导入CA证书
if(bundle.containsKey(Credentials.EXTRA_CA_CERTIFICATES_NAME)){
String caListName = bundle.getString(
Credentials.EXTRA_CA_CERTIFICATES_NAME);
byte[] caListData = bundle.getByteArray(
Credentials.EXTRA_CA_CERTIFICATES_DATA);
mKeyStore.put(caListName, caListData, uid, flags);
}
setResult(RESULT_OK);
}}
由上述代码可知，Settings最终会调用ASStore的几个函数把东西导进去：
- 对于Private Key来说，importKey将被调用，传入的参数包括Key名，key数据，uid和flags。Key名是前面别名修改对话时提到的“USRPKEY_My Key Chain”。
- 对于Cert和CA Cert，调用的都是put函数。参数和importKey类似。
到此，Java层的流程几乎全部介绍完毕。大家肯定还有一个疑问，ASKeyStore怎么不讲讲呢？去看看代码就知道了，AS KeyStore就是通过binder和“android.security.keystore”服务打交道。
根据图16可知，这个keystore服务应该在native的keystore进程里。直接来看它吧！
2.1.5 Native keystore daemon
keystore是一个native的daemon进程，其代码位于system/security/keystore下。这个进程由init启动。在init.rc中有如图20所示的配置：
图20 keystore启动配置
keystore的代码几乎都在keystore.cpp中，先来看它的main函数：
[-->keystore.cpp::main]
int main(int argc, char* argv[]) {
......
//修改本进程的工作目录。由图20可知，keystore设置的工作目录将变成/data/misc/keystore
chdir(argv[1]);
Entropy entropy; //Entropy设备：熵，和随机数生成有关，能增加随机数的随机性
entropy.open();
//和硬件的keymaster设备有关。如果没有硬件实现，AOSP给了一个软件实现
keymaster_device_t* dev;
keymaster_device_initialize(&dev);
//native层中的KeyStore，关键类
KeyStore keyStore(&entropy,dev);
//为系统添加一个“android.security.keystore”的服务
keyStore.initialize();
android::sp<android::IServiceManager> sm =
android::defaultServiceManager();
android::sp<android::KeyStoreProxy> proxy =
newandroid::KeyStoreProxy(&keyStore);
android::status_t ret =sm->addService(
android::String16("android.security.keystore"),proxy);
android::IPCThreadState::self()->joinThreadPool();
keymaster_device_release(dev);
return 1;
}
Native层也有一个KeyStore类，先来看它的构造函数：
（1） NativeKeyStore初始化
[-->keystore.cpp::KeyStore构造]
KeyStore(Entropy* entropy, keymaster_device_t* device)
: mEntropy(entropy)
, mDevice(device)
{
//mMetaData:一个结构体，内部只有一个int变量用来保存版本号
memset(&mMetaData, '\0', sizeof(mMetaData));
}
再来看init函数：
[-->keystore.cpp::initialize]
ResponseCode initialize() {
//读取工作目录下的.metadata文件，其中存储的是版本号
readMetaData();
if (upgradeKeystore())
writeMetaData();//版本号写到.metadata文件里
return ::NO_ERROR;
}
upgradeKeyStore用于升级Android平台KeyStore的管理结构。这个主要是为多用户支持的。来看图21：
图21 KeyStore目录管理
图21中，keystore目录下有个：
- .metadata文件用来控制版本。
- user_0文件夹：这是为了支持多用户而设置的。初始用户为user_0，后续添加新用户则叫user_xxx之类的。
- user_0目录中有个.masterkey文件和导入的PrivateKey，Cert和CA Cert文件。注意，以1000_USRPKEY_My+PKey+PChain为例，它就是我们前面说的“USRPKEY_My KeyChain”非常像，只不过前面多了一个uid（这里的uid是1000，和settings的uid是一个，也就是系统system_server的uid），然后把空格换成了“+P”。
也就是说，当我们导入东西到AS KeyStore的时候，它会在/data/misc/keystore对应用户（USER_X）目录下生成类似1000_XXX_Alias的文件。这个文件的内容并不直接保存的证书，PrivateKey等关键的二进制数据，而是一个经过加密的二进制数组。这个二进制数组将做为类似于Tag一样的东西，把它和实际的关键数据对应起来。而这些关键数据则是保存到硬件的KeyMasterDevice里的。我们接下来会看到这些文件的生成步骤。
稍微看一下upgradeKeyStore函数：
[-->keystore.cpp::upgradeKeyStore]
bool upgradeKeystore() {
bool upgraded = false;
if (mMetaData.version ==0) {
//每一个用户对应为代码中的一个UserState对象
UserState* userState = getUserState(0);
....
userState->initialize();//来看看它！
......
mMetaData.version = 1;
upgraded = true;
}
return upgraded;
}
[-->keystore.cpp:UserState:initialize]
bool initialize() {
//创建user_n目录，我们是第一个用户，所以n=0
mkdir(mUserDir, S_IRUSR | S_IWUSR | S_IXUSR);
//看看该目录下有没有.masterkey文件，如果没有，表明还没有设置
if (access(mMasterKeyFile, R_OK) == 0)
setState(STATE_LOCKED); //设置KeyStore状态，这也是前面Settings中得到的状态
else setState(STATE_UNINITIALIZED);
return true;
}
（2） password处理
有上述代码可知，当没有.masterkey文件的时候，Native KeyStore为未初始化状态。根据Settings里的处理，我们只有设置了锁屏界面时，Settings会调用password函数来设置密码。对应到Native KeyStore就是它password函数。
[-->keystore.cpp::password]
int32_t password(const String16& password) {
uid_t callingUid =IPCThreadState::self()->getCallingUid();
const String8password8(password);
switch(mKeyStore->getState(callingUid)) {
case::STATE_UNINITIALIZED: {
return mKeyStore->initializeUser(password8, callingUid);
}
case ::STATE_NO_ERROR: {
return mKeyStore->writeMasterKey(password8, callingUid);
}
case ::STATE_LOCKED: {
return mKeyStore->readMasterKey(password8, callingUid);
}
}
return ::SYSTEM_ERROR;
}
initializeUser其实就是把我们设置的密码和两个从Entropy得到的随机数（这些随机数有个奇怪的称呼，叫盐值，salt。salt也需要保存到.masterkey文件里的）搞到一起，生成一个签名，然后再用密码对这个签名进行加密，最终存储到文件里。
上述流程并不是很准确，偶也不想讨论了。说一下解密的问题：解密并不是从.masterkey里边去提取password，而是让用户输入密码，然后按类似的方法得到一个签名，最后和文件里的签名去比较是否匹配！
（3） importKey处理
来看看importKey，当Settings导入PrivateKey的时候，会调用它。importkey在nativeKeyStore中对应的是import函数，代码如下：
[-->keystore.cpp::import]
int32_t import(const String16& name, const uint8_t* data,size_t length,
int targetUid, int32_t flags) {
uid_t callingUid =IPCThreadState::self()->getCallingUid();
//权限检查，keystore对权限检查比较严格，只有system/vpn/wifi/rootuid的进程才
//可以操作它
if(!has_permission(callingUid, P_INSERT)) return ::PERMISSION_DENIED;
.....
State state =mKeyStore->getState(callingUid);
if ((flags &KEYSTORE_FLAG_ENCRYPTED) && !isKeystoreUnlocked(state)) {
return state;
}
//name是传进来的，对应为“USRPKEY_My Key Chain”
String8 name8(name);
//getkeyNameForUidWithDir将把uid和空格替换上去，并加上父目录的路径
//最终”filename=user_0/1000_USRPKEY_My+PKey+PChain”
String8filename(mKeyStore->getKeyNameForUidWithDir(name8,targetUid));
return mKeyStore->importKey(data, length,filename.string(),
callingUid,flags);
}
来看importKey函数：
[-->keystore.cpp::importkey]
ResponseCode importKey(const uint8_t* key, size_t keyLen, constchar* filename,
uid_t uid, int32_t flags) {
uint8_t* data;
size_t dataLength;
int rc;
bool isFallback = false;
//将key信息传递到keymaster device里去，注意data这个参数，它是一个返回参数，
//是keymaster device返回的。具体是什么，由硬件或驱动决定
rc = mDevice->import_keypair(mDevice, key, keyLen,&data, &dataLength);
//如果硬件没这个功能，那么就软件实现，用得是openssl_import_keypair，其内部好像就是
//对key加了把密，然后把加密后的key数据存储到data里了
if (rc) {
if(mDevice->common.module->module_api_version <
KEYMASTER_MODULE_API_VERSION_0_2){
rc = openssl_import_keypair(mDevice, key,keyLen, &data, &dataLength);
isFallback = true;
}
//把import_keypair返回的data信息放到一个Blob中
Blob keyBlob(data,dataLength, NULL, 0, TYPE_KEY_PAIR);
free(data);
keyBlob.setEncrypted(flags& KEYSTORE_FLAG_ENCRYPTED);
keyBlob.setFallback(isFallback);
//再把这个blob信息写到对应的文件里...
return put(filename, &keyBlob, uid);
}
put函数就是把data什么信息都往对应的文件里写...让人解脱的是，cert和CA cert调用的都是put函数，所以我们这也不用再单独介绍put了....
2.1.6 小结
从这一大节的流程来看，导入证书文件其实是一件很麻烦的事情，涉及到好几个进程，比如CertInstaller，Settings，native的KeyStore等。
无论如何，我们还是把信息都写到文件里了。这里要特别指出：
- Android平台中，证书等敏感信息都存储到KeyMaster Device里了，也就是前面提到的SEE中。
- nativekeystore会在对应目录下放几个文件，这几个文件存储的是二进制内容。而这些二进制内容并不是敏感信息，而是由敏感信息通过一些转换（比如加密）得到的东西。这也是所谓的KEK（Key Encryption Key，也就是给密钥加密的密钥）吧？
2.2 通过KeyChain获取PrivateKey
信息都导入到系统里去了，那是不是用JCE标准接口就能用呢？不是，至少我测试了不是。为什么？先想想下面这些个问题：
- 谁都可以往系统里导证书信息，并设置alias。但是，其他程序是否都有权限使用它们？
显然不是。Android系统里，要使用某个alias的证书，系统会弹出一个提示框以提醒用户，这个提示框如图22所示：
图22 证书选择对话框
图22中：
- 首先会列出一些证书（当然，我们这里只导入了一个证书文件，所以只有“MyKey Chain”）。
- 也可以选择从sdcard中安装.pfx或.p12文件。这需要点击图中的“install“按钮。
- 剩下的就是选择是否允许当前app使用所选别名的证书信息了。
所以，一个app要使用系统中的某个证书（这里是指privatekey和非CA的证书）信息时，必须要先调用KeyChain的choosePrivateKeyAlias函数。我们的故事就从这里开始：
2.2.1 choosePrivateKeyAlias介绍
先来看怎么用它，如DemoActivity中的onActivityResult所示：
[-->DemoActivity.java::onActivityResult]
protected void onActivityResult(int requestCode, int resultCode,Intent data) {
KeyChain.choosePrivateKeyAlias(this,
//第二个参数是一个回调对象，当用户选择了哪一个alias的时候，会通过这个回调对象传回来
new KeyChainAliasCallback() {
@Override
public voidalias(String alias) {
......
}
});
}
},
new String[] {},//设置要使用的Key Type，比如RSA或DSA，本例不设置这个
null, //设置证书的issuer，即指定目标证书的发行者，一般也不设置。除非事先约定好
"localhost", //好像和SSLServer有关，用于告诉用户想用在什么ip地址或端口号上
-1,
ENTRY_ALIAS);//ENTRY_ALIAS的值是“My Key Chain“
super.onActivityResult(requestCode,resultCode, data);
}
直接来看KeyChain的实现代码：
[-->KeyChain::choosePrivateKeyAlias]
public static voidchoosePrivateKeyAlias(Activity activity,
KeyChainAliasCallback response,
String[] keyTypes, Principal[] issuers,
String host, intport,String alias) {
......
//Action的值为“com.android.keychain.CHOOSER“
Intent intent = newIntent(ACTION_CHOOSER);
intent.putExtra(EXTRA_RESPONSE, new AliasResponse(response));
intent.putExtra(EXTRA_HOST, host);
intent.putExtra(EXTRA_PORT, port);
intent.putExtra(EXTRA_ALIAS, alias);
intent.putExtra(EXTRA_SENDER, PendingIntent.getActivity(activity, 0,
new Intent(), 0));
activity.startActivity(intent);
}
“com.android.keychain.CHOOSER“这个Intent将好多年来一直默默无名但是又重要无比的keychain这个apk来响应。
（1） KeyChainActivity
直接来看图22中那个框是咋处理的吧。
[-->KeyChainActivity.java:: showCertChooserDialog]
private void showCertChooserDialog() {
new AliasLoader().execute();
}
[-->KeyChainActivity.java::AliasLoader]
private class AliasLoader extendsAsyncTask<Void, Void, CertificateAdapter> {
@Override protectedCertificateAdapter doInBackground(Void...params) {
//借助Binder和Native KeyStore交互，获取alias列表
String[] aliasArray = mKeyStore.saw(Credentials.USER_PRIVATE_KEY);
List<String> aliasList = ((aliasArray== null)
?Collections.<String>emptyList(): Arrays.asList(aliasArray));
Collections.sort(aliasList);
return new CertificateAdapter(aliasList);
}
@Override protected voidonPostExecute(CertificateAdapter adapter) {
displayCertChooserDialog(adapter);//显示图22所示的对话框！
}
}
[-->KeyChainActivity.java::displayCertChooserDialog]
private voiddisplayCertChooserDialog(final CertificateAdapter adapter) {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
......
if......
else {
.....
builder.setPositiveButton(R.string.allow_button,
new DialogInterface.OnClickListener(){
@Override public void onClick(DialogInterface dialog, int id) {
int listViewPosition = lv.getCheckedItemPosition();
int adapterPosition = listViewPosition-1;
String alias = ((adapterPosition >= 0)
?adapter.getItem(adapterPosition) : null);
finish(alias);
}
});
}
...
final Dialog dialog =builder.create();
......
}
关键函数是这个finish，注意它是带参数的，非常容易和Activity的finish()混淆！
[-->KeyChainActivity.java::finish]
private void finish(String alias) {
......
IKeyChainAliasCallback keyChainAliasResponse
= IKeyChainAliasCallback.Stub.asInterface(
getIntent().getIBinderExtra(KeyChain.EXTRA_RESPONSE));
if (keyChainAliasResponse != null) {
new ResponseSender(keyChainAliasResponse,alias).execute();
return;
}
finish();
}
[-->KeyChainActivity.java:ResponseSender]
private class ResponseSender extends AsyncTask<Void,Void, Void> {
private IKeyChainAliasCallback mKeyChainAliasResponse;
private String mAlias;
.......
@Override protected VoiddoInBackground(Void... unused) {
try {
if (mAlias != null) {
KeyChain.KeyChainConnection connection =
KeyChain.bind(KeyChainActivity.this);
try {
//这里的Service不是Native的KeyStore，而是keychain里的KeyChainService
connection.getService().setGrant(mSenderUid,mAlias, true);
} ......
}
mKeyChainAliasResponse.alias(mAlias);//调用我们的回调函数
（2） KeyChainService
KeyChainService也在keychain.apk中，这玩意开机就会启动，因为keychain有一个BroadcastReceiver会接收BOOT_COMPLETE消息，这个BR然后启动KeyChainService。
KeyChainService功能超级简单，就是管理了一个名叫grants的数据库。这个数据库为每一个alias和调用choosePrivateKeyAlias的进程的uid维护了一个关系，也就是所谓的权限管理。即只有在这个数据库里某个alias有对应的uid时，那个uid所在进程才能访问这个alias所代表的证书信息。
图23所示为该数据库的示例：
图23 grants.db示例
（3） getPrivateKey
设置好权限后，下一步就是从对应alias中获取PrivateKey或者是证书信息了。我们这里仅以PrivateKey为例。相应的函数是KeyChain的getPrivateKey。
[-->KeyChain.java::getPrivateKey]
public static PrivateKeygetPrivateKey(Context context, String alias)
throws KeyChainException,InterruptedException {
......
KeyChainConnectionkeyChainConnection = bind(context);
try{
final IKeyChainServicekeyChainService =
keyChainConnection.getService();
//从KeyChainService那获得一个id，然后把这个id传到OpenSSL相关API里
final String keyId = keyChainService.requestPrivateKey(alias);
.....
final OpenSSLEngine engine =OpenSSLEngine.getInstance("keystore");
return engine.getPrivateKeyById(keyId);
} ......
}
由前面代码可知，PrivateKey信息之前是导入到硬件里去的，留下来的在/data/misc/keystore/user_0文件夹下是一些保存了和PrivateKey有关系的数据（想从这些数据里还原PrivateKey显然是不可能的，它有点像MD5码，和硬件里的PrivateKey有着一一对应的关系）。那么，getPrivateKey函数会把硬件里的信息弄出来吗？
显然，如果弄出来的话，安全性就没有了。所以，在Android平台中，PrivateKey永远都是保存在硬件里的，外面拿到的都是一个标志，也就是上面代码里的KeyId。那JCE怎么用这个keyid呢？
- 前面讲了。JCE只是一个框架，具体的工作是由不同引擎来完成的。在Android上，Key相关引擎由OpenSSLEngine构造并经过google修改，其中的很多函数都会和native 的keystore交互。比如加密解决也是把数据传递到硬件来完成的，因为要严格恪守PrivateKey不外传的原则！
JCE一些接口以及Android上的OpenSSLEngine等引擎比较复杂。这里也不会一一涉及，读者有个大概了解就可以了。
先来看KeyChainService的requestPrivateKey函数：
[-->KeyChainService.java::requestPrivateKey]
public String requestPrivateKey(Stringalias) {
//检查数据库里是不是给调用进程设置了权限！
checkArgs(alias);
final String keystoreAlias =Credentials.USER_PRIVATE_KEY + alias;
final int uid =Binder.getCallingUid();
//Native KeyStore也要维护一个类似的uid-alias权限。这里要设置这个权限
if (!mKeyStore.grant(keystoreAlias, uid)) {
return null;
}
//构造keyid很简单，就是返回”1000_USRPKEY_My Key Chain”
final StringBuilder sb = new StringBuilder();
sb.append(Process.SYSTEM_UID);
sb.append('_');
sb.append(keystoreAlias);
return sb.toString();
}
简直太简单了，keyid原来就是用system的uid加上对应的alias。但是，还得为它设置权限，否则你有keyid，Native keystore也无法让你访问。
好了。到此时，我们已经成功拿到了一个PrivateKey。这个privateKey是一个接口，其具体实现应该是OpenSSLRSAPrivateKey（假设我们这个PKey是RSA类似的）。
接着，我们如果继续把玩这个PKey，比如想调用它的getEncoded获取二进制表达式，很可悲得的是它会null。是的，返回null呢!！这个....从情理上似乎说得过去，因为我们不能让私有信息外流。但从法理上我们又不爽，因为我们前面的实例中，一直是可以取出二进制信息的，到底是什么东西导致信息导入到系统后，反而取不了二进制信息了呢？
这部分内容比较繁琐，我这里简单和各位一起把代码撸一遍好了！
先从OpenSSLEngine的getInstance看起。
2.2.2 为什么PrivateKey.getEncoded返回null？
由于KeyChain getPrivateKey创建的是OpenSSLEngine，所以先来看它：
[-->OpenSSLEngine.java::getInstance]
public static OpenSSLEngine getInstance(String engine)
throws IllegalArgumentException {
final long engineCtx;
synchronized(mLoadingLock) {
//engine的值是“keystore“，这里的意思好像是从Engine库里去找对应的实现
engineCtx = NativeCrypto.ENGINE_by_id(engine);
......
NativeCrypto.ENGINE_add(engineCtx);
}
//返回一个OpenSSLEngine对象
return new OpenSSLEngine(engineCtx);
}
打破脑壳你也想不到谁注册了”keystore”到NativeCrypto来。答案在keystore-engine里，这是一个动态库，代码在system/security/keystore-engine中。来看一小段：
[-->eng_keystore.cpp:: keystore_engine_setup]
static int keystore_engine_setup(ENGINE*e) {
ALOGV("keystore_engine_setup");
//这个kKeystoreEngineId是一个字符串，值就是”keystore”
//设置一些函数指针，注意红色的地方
if (!ENGINE_set_id(e, kKeystoreEngineId)
|| !ENGINE_set_name(e, kKeystoreEngineDesc)
||!ENGINE_set_load_privkey_function(e, keystore_loadkey)
||!ENGINE_set_load_pubkey_function(e, keystore_loadkey)
|| !ENGINE_set_flags(e, 0)
|| !ENGINE_set_cmd_defns(e,keystore_cmd_defns)) {
ALOGE("Could not set up keystore engine");
return 0;
}
pthread_once(&key_handle_control, init_key_handle);
//注册DSA，RSA和ECDSA算法所使用的函数，这也是使用系统证书信息的限制，它只支持这三种
//算法
if (!dsa_register(e)) {....
} else if (!ecdsa_register(e)) {....
} else if (!rsa_register(e)) {....
}
return 1;
}
然后KeyChain getPrivateKey会调用OpenSSLEngine的getPrivateKeyById：
[-->OpenSSLEngine.java::getPrivateKeyById]
public PrivateKeygetPrivateKeyById(String id) throws InvalidKeyException {
......
//传递进来的id是“1000_USRPKEY_My Key Chain“
//根据上面的代码，这里的ENGINE_load_private_key应该会调用keystore_engine的
//keystore_loadkey函数
final long keyRef = NativeCrypto.ENGINE_load_private_key(ctx, id);
OpenSSLKey pkey = new OpenSSLKey(keyRef,this, id);
try {
return pkey.getPrivateKey();
} ......
}
注意这两段代码红色的地方。Java层对应的ENGINE_load_private_key最终会走到keystore-engine的keystore_loadkey函数里。代码如下所示：
[-->eng_keystore.cpp::keystore_loadkey]
static EVP_PKEY* keystore_loadkey(ENGINE* e, const char* key_id,
UI_METHOD* ui_method,void*callback_data) {
//说得不错吧，它果然要和native keystore通过binder交互
sp<IServiceManager> sm = defaultServiceManager();
sp<IBinder> binder =sm->getService(String16("android.security.keystore"));
sp<IKeystoreService> service =interface_cast<IKeystoreService>(binder);
uint8_t *pubkey = NULL;
size_t pubkeyLen;
int32_tret = service->get_pubkey(String16(key_id),&pubkey, &pubkeyLen);
......
const unsigned char* tmp = reinterpret_cast<const unsignedchar*>(pubkey);
Unique_EVP_PKEY pkey(d2i_PUBKEY(NULL, &tmp, pubkeyLen));
switch (EVP_PKEY_type(pkey->type)) {
......
case EVP_PKEY_RSA:{//这里的rsa_pkey_setup还会和native keystore交互，此处略过！
rsa_pkey_setup(e, pkey.get(),key_id);
break;
}
.....
return pkey.release();
}
你看，果然我们的DemoActivity应用会和native keystore进程交互。而且很明显，我们调用的是它的get_pubkey函数，即使我们这样想用privatekey信息。真是步步为营啊，绝不泄露PrivateKey信息。最后，我们的PrivateKey将从OpenSSLKey的getPrivateKey得到:
[-->OpenSSLKey.java::getPrivateKey]
public PrivateKey getPrivateKey() throwsNoSuchAlgorithmException {
switch (NativeCrypto.EVP_PKEY_type(ctx)) {
case NativeCrypto.EVP_PKEY_RSA:
return new OpenSSLRSAPrivateKey(this);
case NativeCrypto.EVP_PKEY_DSA:
return newOpenSSLDSAPrivateKey(this);
case NativeCrypto.EVP_PKEY_EC:
return newOpenSSLECPrivateKey(this);
default:
throw newNoSuchAlgorithmException("unknown PKEY type");
}
}
好了，当我们对OpenSSLRSAPrivateKey调用getEncoded的时候，会发生什么问题呢？
[-->OpenSSLRSAPrivateKey.java::getEncoded]
public final byte[] getEncoded() {
if (key.isEngineBased()) {//我们是有Engine支持的，所以返回空！
return null;
}
return NativeCrypto.i2d_PKCS8_PRIV_KEY_INFO(key.getPkeyContext());
}
三 需要继续走的路
到此，本文基本就结束了。在这篇文章里：
- 我们首先对JCE的基础知识进行了一些介绍。这些知识，是理解Android平台中Java Security的重要一部分，属于最基本的知识，需要大家理解。
- 然后我们用代码对Android平台上特有的KeyChain，KeyStore，CertInstaller介绍了一番。这个...需要各位结合代码撸几把，掌握大概意思就好。
那么，剩下还有什么呢？
- 有没有谁把SSLServerFactory和我们导入系统的KeyStore联合起来？我内心觉得这事情应该是能办成的，但是我确实没找到对应的接口函数。
- 另外，实际上，每一个应用程序也可以借助JCE，并指明使用“AndroidKeyStore”。在这种情况下，它只能自己先把信息导进去，然后也只能和它同一个uid的进程才能用这些信息。（其实我们刚才是把信息通过uid=1000的settings导入到系统的，这个是系统全局的证书信息。应用程序可以往native keystore中导入自己uid的信息。）
- 另外，TrustStore的问题，大家也跟着代码看看吧
...
对上述这些感兴趣的童鞋，只能请你们自己看代码玩耍了....
参考文献
Java Security
[1] Java Security, 2nd Edition：http://shop.oreilly.com/product/9780596001575.do 中文名为《Java安全第二版》，此书是关于Java Security最好的参考书。
http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html
关于证书和证书文件格式
[2] http://www.360doc.com/content/13/0417/10/11791971_278827661.shtml
[3] http://www.blogjava.net/lihao336/archive/2011/08/18/356763.html
[4] http://en.wikipedia.org/wiki/PKCS
[5] http://en.wikipedia.org/wiki/X.509
X.509和PKCS介绍
[6] http://bbs.csdn.net/topics/190044123
关于X.509和PCKS规范之间的关系的讨论
Key管理
[7] 《Java加密与解密的艺术》，作者梁栋，国人关于JavaSecurity的一本好书。
[8] http://developer.android.com/training/articles/keystore.html
[9] http://en.wikipedia.org/wiki/Public-key_cryptography
JSSE
[10] http://en.wikipedia.org/wiki/Transport_Layer_Security
TLS和SSL的历史。
[11] https://developer.android.com/training/articles/security-ssl.html
Android开发文档中关于SSL方面的知识。
Cipher资料
[12] http://www.javamex.com/tutorials/cryptography/index.shtml
SEE和TrustZone
[13] http://research.microsoft.com/en-us/um/people/alecw/asplos-2014.pdf
[14] http://www.ti.com.cn/cn/lit/wp/spry228/spry228.pdf
TrustZone资料
[15] http://cache.freescale.com/files/32bit/doc/white_paper/QORIQSECBOOTWP.pdf
安全系统的资料
Android Security Internals：
[16] Android Security Internals
美国亚马逊上有电子版，可在浏览器上看。很好的一本系统讲述Android安全方面的书籍。