1、Android提供的加解密服务的方法
Andorid系统有两种设备加密方法，即：文件级加密和全盘加密
（1）文件级加密 （FBE：File-Based Encryption）
使用不同的密钥对不同的文件进行加密，也可以对加密文件单独解密。
引入文件级加密之后，App应用可以在用户提供凭据之前运行，同时系统仍能保护私密用户信息。
（2）全盘加密 （FDE：Full-Disk Encryption）
使用单个密钥来保护设备的整个用户数据分区。在启动时，用户必须先提供凭据，然后才能访问磁盘的任何部分。
小结：Android提供的加解密服务就是为了保护设备的所有用户数据，即：只有通过授权，才能访问相应的数据。
2、加解密服务是如何被提供的
那么，整个加解密服务是如何被提供的，以及它自身是否是安全？
一句话来说，借助系统芯片所提供的可信执行环境（TEE），Android设备可以为Android操作系统、平台服务以及第三方应用提供由硬件支持的强大安全服务。
（1）Keystore组件
AndroidKeystore是供App应用访问Keystore功能的Android Framework API和组件。
AndroidKeystore通过将与密钥库行为有关的应用请求转发给密钥库守护程序来执行这些请求。
密钥库守护程序提供对所有密钥库功能的访问权限，通过Keymasterd服务来访问Keymaster TA（可信应用 Trusted Application）。
（2）Keymaster TA
Keymater TA（可信应用）是在TEE环境中运行的软件，它提供所有安全的密钥库操作：能够访问密钥，以及在密钥上验证所有访问权限控制等。即，只有Keymaster才能打开我们的密钥库（称为“密钥blob”）。
Keymaster TA不仅服务Keystore，也服务于用户身份认证相关的应用，即：第三篇文章所提及的Gatekeeper和Fingerprint。
至此，上述问题（如何提供以及是否安全）就落在Keymaster上。
3、Keymaster
从Android10（Keymaster4.1）以后，在Android的后续版本中，Keymaster组件被重命名为KeyMint。
（1）架构
Android Keystore API和底层Keymaser HAL提供了一套基本的加密服务，以便使用者使用由硬件支持的密钥学服务。
NON-SECURE WORLD：指的是Android的运行环境；
SECURE WORLD：指的是TEE OS的运行环境。
从上面架构图可以看出，SECURE WORLD中的Keymaster才是实际的服务主体。
（2）Keystore/KeyMaster提供的功能
主要提供以下操作
-
生产密钥
-
导入导出密钥（对称密钥和非对称密钥）
-
进行加密和解密
-
进行签名和验证
-
生产和验证对称消息验证码
（3）访问权限控制
密钥库访问权限控制的基本原则是：每个应用都有自己的命名空间（namespace）。
I、建立密钥库域
访问密钥库的密钥的客户端必须指定其想要访问的密钥库域、命名空间和别名。根据这组信息和调用方的身份，系统可以确定调用方想要访问哪个密钥以及是否具有相应的权限。
为了控制访问密钥的方式，采用了五个域参数
-
DOMAIN_APP：调用方的UID。
-
DOMAIN_SELINUX：命名空间的域标签。是在SELinux Policy中定义（并且为指定操作建立相应的权限）；
-
DOMAIN_GRANT：授权标识符。在创建授权后，系统会检查该权限。
-
DOMAIN_KEY_ID：命名空间中的唯一的密钥ID。
-
DOMAIN_BLOB：标识调用方要自行管理blob。
II、keystore_key的SELinux Policy
在SELinux Policy中配置密钥命名空间ID、UID，所映射的SELinux标签、以及访问权限等一组信息和策略。
其中，UID就是Android用户ID，即：将密钥限定为仅在用户通过身份验证后才可使用。
（4）信任根绑定
Keystore 要求将密钥绑定到一个信任根。信任根是在启动期间提供给 Keymaster 安全硬件的一个位串（bitstring）。该位串会以加密形式绑定到由 Keymaster 管理的每个密钥。
这是为了确保由攻击者安装的操作系统无法使用 Keymaster 密钥。
4、进一步说明
Keystore提供了一个更安全的位置，让用户以可控方式创建、存储和使用加密密钥。
在Keystore/Keymaster演进中，不断提升密钥库的安全以及对密钥库的访问控制。典型的有：
（1）身份认证，即：经过认证的密钥需要进行用户是身份认证才能使用；（参考第三篇）
（2）ID Attestation（ID认证），即：设备提供安全的硬件标识符的证明（例如品牌名称、制造商名称、序列号以及IMEI）。因为在zero-touch（零触摸）远程配置等场景下，远程端需要确定对方是正确的设备，而非假冒身份的设备。（参考第七篇）
另外，关于安全级别SecurityLevel，包含如下三类：
-
Software：
创建或管理相关元素（认证或密钥）的代码已在 Android 系统中实现，如果 Android 系统遭到入侵，该代码可能会被更改。
-
TrustedEnvironment：
创建或管理相关元素（认证或密钥）的代码已在可信执行环境 (TEE) 中实现。 如果 TEE 遭到入侵，该代码可能会被更改；不过，TEE 对远程入侵具有很强的抵抗力，并且可以适度抵御来自直接硬件攻击的入侵。
-
StrongBox：
创建或管理相关元素（认证或密钥）的代码已在专用硬件安全模块（通常是嵌入式安全芯片eSE）中实现。 如果硬件安全模块遭到入侵，该代码可能会被更改；不过，它对远程入侵具有很强的抵抗力，并且可以强力抵御来自直接硬件攻击的入侵。
即，StrongBox级别是更安全的方案。
【参考资料】
1、https://www.android.com/android-14/
2、https://source.android.com/docs/security/