Android安全付出（1）-团体架构-keymint
目次一、团体架构
1.app到keystore
2.keystore到keymaster(这部分，不同版本会有不同的实现)
3.keymaster到trusty
4.trusty内部的ipc机制调用到TA
5.trusty TA
二、采用keymint照旧keymaster
三、keymint接口定义和具体实现
（1）接口定义
（2）AndroidKeyMintDevice(具体实现服务端示例)
（3）trusty KeyMintDevice(具体实现服务端的另一个示例)
四、trusty TA对硬件的操纵调用和通信
五、总结
一、团体架构
我们来看下如何基于已有的Android系统框架和安全架构，如作甚区块链用户在arm平台的android装备上添加一颗安全芯片，提供硬件级别的安全付出能力和硬件装备。【ps：所有公开内容将仅限于对已开源的AOSP源码的分析】
团体的框架（官方图镇楼）：
https://i-blog.csdnimg.cn/direct/6a214d02e215484ca13c4055647a21af.png
我们起首以一个简单应用到TA的调用流程来作为整个分析的索引，然后渐渐拆解开来。
1.app到keystore
https://i-blog.csdnimg.cn/direct/17bcc67c49f14005a85efe988af3e0e4.png
2.keystore到keymaster(这部分，不同版本会有不同的实现)
https://i-blog.csdnimg.cn/direct/a823168b26b04a58bf033bb15d23da24.png
3.keymaster到trusty
https://i-blog.csdnimg.cn/direct/ad98a2d302d049d18c75b92eb530bc44.png
4.trusty内部的ipc机制调用到TA
https://i-blog.csdnimg.cn/direct/e28fdaa3f94f4607b229365f1cd7db7b.png
5.trusty TA
https://i-blog.csdnimg.cn/direct/78e3ecd87cdb4a238eec9215e43888fa.png
二、采用keymint照旧keymaster
在keystore功能的底层实现上，android在不同的版本有不同的实现。
keymint是keymaster v4之后的替换计划。所以android 15上最好采用keymint的接口进行硬件功能的对接。【这里要看下keymint接口和keymaster接口的差异】
https://i-blog.csdnimg.cn/direct/52526a729f604f04adc50bce307b4d62.png
这里，我们关注最新的keymint部分的架构。
三、keymint接口定义和具体实现
（1）接口定义
hardware/interfaces/security/keymint/aidl/android/hardware/security/keymint/IKeyMintDevice.aidl
https://i-blog.csdnimg.cn/direct/a2794e9449fa4642a0c6082ac0571f00.png
（2）AndroidKeyMintDevice(具体实现服务端示例)
https://android.googlesource.com/platform//system/keymaster/+/9d64bc288499acd6aefa22e44826871e56acfda4/ng/AndroidKeyMintDevice.cpp
https://i-blog.csdnimg.cn/direct/019389b230e844428b01898a887c5ce3.png
https://i-blog.csdnimg.cn/direct/d904970f0b5349c9b1cb3ef16fb20a72.png
https://i-blog.csdnimg.cn/direct/4973698bdff3425286a4618578e7bbd8.png
这里会构造一个UpgradeKeyRequest 请求，并实行SetKeyMaterial的任务。
会调到android_keymaster_messeges.cpp中的实现中：
https://i-blog.csdnimg.cn/direct/6de737f5e1ba4f7bbe8d2d769f97601b.png
进而调用到：
https://i-blog.csdnimg.cn/direct/c08b6e5c01db4c1187f39d952f64eb44.png
对keymaster_key_blob_t这个布局体进行更新。这个布局体是定义在prebuilts/vndk/v32/arm/include/hardware/libhardware/include/hardware/keymaster_defs.h中。
https://i-blog.csdnimg.cn/direct/77e1cde45f6a4293b009b7ca979f2e59.png
到这里更新布局体以后，还调用了request.upgrade_params.Reinitialize(KmParamSet(upgradeParams));
这个upgrade_params是AuthorizationSet类型的。
会调用到authorization_set.cpp中：
https://i-blog.csdnimg.cn/direct/fe752eb86ff843b8a8f4b21d88e29e55.png
这里重要是通过memcpy完成的密钥更新。
最后调用impl_->UpgradeKey返回更新结果。
说明：这个system/keymaster目次下是一个AndroidKeyMintDevice的实现。而假如要具体和trusty通信来进行密钥更新。可以参考trusty的TrustyKeyMintDevice的实现。这部分，不同的厂商可以有自己不同的实现：
源码路径：system/core/trusty/keymaster/keymint/TrustyKeyMintDevice.cpp
（3）trusty KeyMintDevice(具体实现服务端的另一个示例)
对于trusty的KeyMintDevice的实现。其在trusty_keymaster_ipc.h中定义了trusty的跨历程通信函数
trusty_keymaster_send.
https://i-blog.csdnimg.cn/direct/69983ed9a714427dafed4ac967396f7b.png
在TrustyKeymaster.cpp中调用trusty_keymaster_send进行了跨历程通信和trusty的TA进行了交互：
https://i-blog.csdnimg.cn/direct/48c75fa7168140d4b568b05052528065.png
https://i-blog.csdnimg.cn/direct/ba316d4acf5a42b5a236b74e2d3aad16.png
这样，更新密钥的请求就到了trusty 的TA中。
四、trusty TA对硬件的操纵调用和通信
接下来我们看看trusty的keymaster TA端的实现：
源码路径：https://android.googlesource.com/trusty/app/keymaster/+/refs/tags/android-15.0.0_r23
这里，在Android端的TrustyKeymaster.cpp调用UpgradeKey接口以后。会跨进行通信到trusty的TA端：
比如在keymaster_ipc.cpp中会处理KM_UPGRADE_KEY消息：进行派发和TA内部的处理：
https://i-blog.csdnimg.cn/direct/622d1805b6684017a20365dcd74cf2fe.png
上面UpgradeKey是一个函数指针。会调用TrustyKeymaster的UpgradeKey函数中（trusty_keymaster.cpp）。AOSP里UpgradeKey函数貌似没有做参考实现（大概我没有找到）。但其他，比如KM_SET_WRAPPED_ATTESTATION_KEY等消息对应的函数有提供参考实现用作示例。
这里，我们看下KM_SET_WRAPPED_ATTESTATION_KEY消息的调用链来分析一下ta的核心功能的实现：
1.起首会构造一个AttestationKeySlot的对象 key_slot
https://i-blog.csdnimg.cn/direct/9f649a1bc405424fa673d10d797039e6.png
最后，会通过SecureStorageManager对象，将这个key_slot对象写到存储装备上去：
https://i-blog.csdnimg.cn/direct/b39b76ce08904b7587df57cce1781dbd.png
固然，最终的写入也是通过memcpy和snprintf来实现：
https://i-blog.csdnimg.cn/direct/e50c0cc507bd4db6a57b958d6342bf52.png
https://i-blog.csdnimg.cn/direct/9ef00f00765e431cadcf402d94ed8315.png
这样，最终就到了硬件层面的文件节点操纵。
五、总结
从上面的源码分析，我们可以看到
1.从应用APP层面不停到trusty TA的团体调用链条
2.以及各个调用步调干系的安全模块
3.以及其源码分布环境（framework+kernel）。
能够团体架构上审阅Android端的架构计划。
ps：后续，我们将从【软件架构视角】和【安全架构视角】逐个分析各调用流程涉及的各个模块。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]