Android安全支付-整体架构-KeyStore2-APP到Framework层的调用
前面，我们整体审视了应用到TA的整个调用流程。这里，我们来看下最上层的KeyStore2部分（暂不含KeyStore目录下的源码）。
方式上，我们先整体看下KeyStore2 Java层的类框架设计，然后以一个简单的交易签名流程看下从APP到Framework层的调用过程。Android系统在和应用层对接的Framework层面是提供了KeyStore相关的接口给APP调用。派生的java的安全框架，因此通常通过java的框架类和接口来进行调用。
一、KeyStore相关的类结构体系设计
这里，我们还可以顺便看下KeyStore的核心类框架设计：
KeyStore2的相关类主要包含2个部分
（1）是Key相关的秘钥派生类簇。
（2）是Spi相关的类簇。
（说明：这里暂时只整理了KeyStore2部分。KeyStore目录下的后面再分析）
1.Key相关的秘钥派生类簇。主要是对java.security中接口框架的实现。
（其中AndroidKeyStoreSecretKey是来自javax.crypto)
2.Spi相关的类簇。比如后面要分析的AndroidKeyStoreKeypairGeneratorSpi就是其中之一。
注意：这里主要是对javax.crypto和java.security的类以及android.security.keystore中KeyStoreCryptoOperation接口的继承实现。
二、业务调用流程
1.首先在应用（如区块链钱包或者其他支付相关应用）首次安装或首次使用时，在 KeyStore 中生成一个 非对称密钥对（RSA/ECDSA） 或 对称密钥（AES）。生成的密钥只能在当前设备上使用，且无法导出。
2.将公钥Base64编码后传到服务器端。并且将公钥和用户ID绑定。
3.在交易请求时，APP使用KeyStore中的私钥对交易数据进行数字签名。
4.在服务端，利用公钥验证签名的正确性。
这个签名可以保证数据的完整性和真实性。APP 端 用 私钥 签名交易数据并发送给服务器。服务器端 用 公钥 验证签名的真实性，确保交易合法。服务器端预存了APP的公钥，收到请求后，使用该公钥对签名进行验证，确保数据未被篡改。
这样，即使攻击者拦截数据，也无法伪造合法交易，因为私钥永远不会离开设备。
1.生成密钥对
这里要构造KeyGenParameterSpec的初始化对象，指定摘要算法和Padding模式：
这里主要是涉及到generateKeyPair。
2.将公钥上传服务器
3.使用私钥签名交易数据
4.在服务端使用公钥验证签名正确性。
这样，可以保证：
1.通过安全芯片保证私钥不出设备、不泄露
2.通过非对称密钥验证和签名来保障交易安全性。
三、系统接口的实现（ex：generateKeyPair）
我们分析以上示例中提到的generateKeyPair的调用
1.实现方式
其中KeyPairGenerator主要是采用工厂模式。KeyPairGenerator和KeyPairGeneratorSpi都是一个抽象类。其实现是在其generateKeyPair主要是在各算法对应的秘钥生成器类中。
2.实现示例
Android KeyStore2中有提供一个实现：
3.框架来源
基于java的安全框架进行实现的：
4.核心代码
这里会首先根据安全级别来确定创建的秘钥要受到哪个级别的保护，比如如果要求硬件级别的保护：
最高安全级别：SECURITY_LEVEL_STRONGBOX。
普通硬件TEE：SECURITY_LEVEL_TRUSTED_ENVIRONMENT（普通硬件 TEE）。
仅在软件中存储：SECURITY_LEVEL_SOFTWARE。
。然后调用generateKey生成对应级别的秘钥。最后，返回一个KeyPair对象：
这里会调用到IKeystoreSecurityLevel.aidl接口的实现中：system/security/keystore2/src/security_level.rs
调用keymint（或者keymaster）设备的API接口函数generateKey来生成秘钥。
四、总结
通过上面的代码分析，我们可以整体从类结构设计的层面上看到
（1）应用层面调用的Framework层接口如何与系统层面的KeyStore2模块产生联系。
（2）Framework层KeyStore2模块java层面的整体架构设计及框架衍生来源（javax.crypto,java.security,android.security）
ps：后面我们将进一步从【安全视角】逐个分析KeyStore2每个类簇及每个类的作用，进而了解Android原生的整个安全框架都通过这些类提供了什么能力。