最近看见了Keystore这个名词不知道什么意思，百度找到了前辈的优秀文章，这里copy学习一下，原文链接放在文末，感谢前辈。
Keystore的技术演进之路
Android提供的keystore功能发展历程伴随着Android版本不断演进。
从 Android 6.0 之前的版本中，Android已有一个非常简单的由硬件支持的加密服务 API（由0.2和0.3版的Keymaster硬件抽象层(HAL)提供）。
Keymaster 1 HAL与Keymaster 0.2和0.3完全不兼容。为了在运行 Android 5.0 及更早版本的设备上实现互用性，Keystore 提供了一个可通过调用现有硬件库来实现 Keymaster 1 HAL 的适配器，但最终仍不能提供 Keymaster 1 HAL 中的全部功能。因为它仅支持 RSA 和 ECDSA 算法，而且所有密钥授权强制执行都由该适配器在非安全域中进行。
从Android6.0开始，Google借助系统芯片 (SoC) 中提供的可信执行环境TEE，Android设备可以为Android操作系统、平台服务甚至是第三方应用提供由硬件支持的强大安全服务。由硬件支持的密钥的访问控制系统。访问控制在密钥生成期间指定，并会在密钥的整个生命周期内被强制执行。可以将密钥限定为仅在用户通过身份验证后才可使用，并且只能用于指定的目的或只有在具有指定的加密参数时才可使用。
微信SOTER方案就是利用Android keystore技术实现的一个应用解决方案。
在 Android 7.0 中，Keymaster 2 增加了对密钥认证和版本绑定的支持。 密钥认证提供公钥证书，这些证书中包含密钥及其访问控制的详细描述，以使密钥存在于安全硬件中并使其配置可以远程验证。
版本绑定将密钥绑定至操作系统和补丁程序级别版本。这样可确保在旧版系统或 TEE 软件中发现漏洞的攻击者无法将设备回滚到易受攻击的版本，也无法使用在较新版本中创建的密钥。此外，在已经升级到更新的版本或补丁程序级别的设备上使用指定版本和补丁程序级别的密钥时，需要先升级该密钥才能使用，因为该密钥的旧版本已失效。当设备升级时，密钥会随着设备一起“升级”，但是将设备恢复到任何一个旧版本都会导致密钥无法使用。
在 Android 8.0中，Keymaster 3从旧式C结构硬件抽象层 (HAL)转换到了从采用新的硬件接口定义语言 (HIDL) 的定义生成的 C++ HAL接口。
Android 8.0 还扩展了 Keymaster 2 的认证功能，以支持 ID 认证。 ID 认证提供了一种受限且可选的机制来严格认证硬件标识符，例如设备序列号、产品名称和手机 ID (IMEI/MEID)。要实现此附加功能，需更改 ASN.1 认证架构以添加 ID 认证。Keymaster 实现需要通过某种安全方式来检索相关的数据项，还需要定义一种安全永久地停用该功能的机制。
Key attestation-Google的密钥认证
Android的密钥库已经有很多年了，它为应用程序开发者提供了一种使用加密密钥进行验证和加密的方法。 Keystore将密钥保留在应用程序的进程空间之外，以便应用程序不会无意中将其泄露给可能被钓鱼的用户，通过其他渠道泄漏，或者在应用程序遭到破坏时。
许多设备还为安全硬件中的密钥库密钥提供了基于硬件的安全性，从而将密钥材料完全保留在Android系统之外，从而即使Linux内核泄露也不会泄露密钥材料。 在绝大多数Android设备中，安全硬件是主CPU的特殊模式，硬件强制与Linux内核和Android用户空间隔离。比如基于Arm的TrustZone技术实现的TEE安全操作系统， 或者，某些设备使用单独的安全微处理器。比如SE芯片。
Android提供的API允许应用程序确定给定的密钥库密钥是否在安全硬件中，但是如果操作系统受到威胁，这些API可能不可靠。 密钥证明Key attestation为设备的安全硬件提供了一种方法，用于验证非对称密钥是否处于安全硬件中，以防止对Android操作系统的破坏。
Keystore的历史
Keystore最初是在Android 4.0中引入的，而且密钥是用用户的密码加密的。 在Android 4.1中增加了使用设备安全硬件的基础设施。
直到Android 6.0，Keystore支持RSA和ECDSA。 在Android 6.0中，Keystore得到了显着增强，增加了对AES和HMAC的支持。 此外，加密操作的其他关键要素（如RSA填充1和AES块链接2模式）也被转移到安全的硬件中。
在Android 6.0中，Keystore也获得了限制特定密钥的使用方式的能力。 可以应用的最明显有用的限制是用户身份验证绑定。 这允许密钥的使用被“绑定”到用户的密码 - 它们的PIN，图案或密码 - 或指纹。 对于密码认证绑定，应用程序开发人员可以在几秒钟内指定超时。 如果用户上次输入的密码超过了指定的时间，安全硬件将拒绝任何使用该密钥的请求。 每次使用密钥时，指纹绑定密钥都需要新的用户身份验证。
其他更技术性的限制也可以应用于Android 6.0及更高版本。 特别是在密钥创建或导入时，有必要指定可以使用密钥的加密目的（加密，解密，签名或验证）以及填充和块模式，摘要，熵源 用于初始化向量或随机数，以及密码操作的其他细节。 由于指定的信息是永久性的，并且密码上与密钥材料绑定，所以密钥库不允许以任何其他方式使用密钥。 因此，获得应用程序或系统控制权的攻击者不能误用密钥。 为了帮助防止攻击，开发人员应该为给定的密钥指定可能的最窄范围。
Android密钥库最重要的变化之一是在Android 7.0中引入的。 使用安全锁屏启动Android 7.0+的新设备必须具有安全的硬件，并支持基于硬件的密码验证和密钥库密钥。 在Android 7.0之前，安全的硬件支持非常普遍，但是在未来的几年里，它将会变得普遍。
在Android 8.0中，所有安装了Google Play的新设备都必须提供关键证明。
为什么要密钥认证？
简单来说，Google的keystore机制提供了一套密钥管理机制，应用越来多，越来越重要了，但是密钥认证问题如果不解决，这一切都是不可靠的！
1，keymaster HAL可以是假的，你没办法判断系统HAL以下是否真实，简单来说，如果没有使用TEE，你也可以通过keymaster HAL欺骗Framwork层。
2，即使设备是正常的，应用也可以欺骗第三方。
假设您正在开发一个应用程序，为银行的客户提供银行余额，交易历史记录和账单支付系统。 安全是重要的。 您不希望任何拿起用户手机的人访问他们的银行帐户。 一种方法是使用用户的网站密码。 但是这对用户来说通常是不方便的，因为网站经常需要长而复杂的密码，这在小的触摸屏上是不方便的。
使用Android Keystore，可以生成非对称身份验证密钥，例如256位ECDSA密钥，并让每个用户使用其复杂的Web密码登录一次，然后在银行的客户帐户数据库中注册公钥。 每次打开应用程序时，您都可以使用该ECDSA密钥执行质询 - 响应身份验证协议。 此外，如果您将密钥认证绑定，则用户每次打开应用程序时都可以使用其锁屏密码或指纹进行身份验证。 这使得他们可以在手机上使用更简单，更方便的认证机制。
如果攻击者危及Android并尝试提取密钥，则他们不会成功，因为密钥在安全硬件中。
作为应用程序开发人员，密钥认证允许您在服务器上验证您的应用程序所请求的ECDSA密钥实际上是否安全地存在于硬件中。 请注意，在您的应用程序本身中使用证明是没有意义的。 如果Android操作系统是不妥协和可信的，那么您可以使用6.0中引入的KeyInfo类来发现密钥是否在安全硬件中。 如果它被攻破，那么这个API和你在设备上验证证明的任何尝试都是不可靠的。
请注意，密钥证明不同于SafetyNet认证。 他们是相同的概念，但是证明不同的事物来自不同的地方。 密钥库密钥证明确认密钥存在于安全的硬件中并具有特定的特征。 SafetyNet认证确认设备是真实的（不是仿真器），并且运行已知的软件。 SafetyNet使用Keystore密钥证明，所以如果你想了解设备的完整性使用。 如果您想确认您的密钥是否在安全硬件中，请使用密钥认证。
https://android-developers.googleblog.com/2017/09/keystore-key-attestation.html
Key attestation的几个关键点！
下图是Google Android密钥认证的架构图。基本上TEE OS、Keystore、Keymaster等等都有相关涉及。
我们今天来总结一下密钥认证的几个关键点：
Attestation details
● 认证可以应用于RSA或EC密钥。
● 证书是以X.509证书的形式出示的。
● 认证密钥（ECDSA和RSA）将设置在工厂。
● 谷歌将提供CA根，并将认证密钥。
Key Provisioning
● 谷歌将为谷歌批准的设备认证认证密钥。
● 密钥将被部署到设备上，每10K设备用一个密钥。
● 谷歌将创建密钥并对它们进行验证。
这个过程是与Widevine密钥分配过程非常类似（将可能使用相同的交付方法）。
密钥撤回：密钥撤销将通过CRL和OSCP被取消
● 安全密钥注入只能在工厂完成，所以设备被吊销的密钥将永久不受信任。
● 密钥被注入到设备批次中，因此撤销至少影响整个批处理。
● 撤销将应用广泛的需要，根据泄漏的性质和范围。
其他的keystore安全措施：
● More elliptic curve functionality：ECIES ECDH
● Exportable symmetric keys
● Fingerprint-bound keys that are not revoked on fingerprint enrollment
● OS version binding to protect against OS rollback
Bootloader修改：
新的硬件密钥库功能需要一些BootLoader功能：
● Bootloader must provide OS version and patch level to TEE.
● Bootloader must provide Verified Boot public key and lock status to TEE.
CDD测试要求：
Hardware-backed keystore will be MANDATORY in a future release.
● All algorithms (RSA, AES, ECDSA, ECDH, ECIES, HMAC)
● All hash functions (MD5, SHA1, SHA-2 family)
● Hardware Gatekeeper (on devices with lockscreens)
● With brute force protection in hardware
● Hardware attestation support
FIDO and Android KeyStore Attestation
KeyStore attestation is similar to—but not an implementation of—FIDO U2F.
● U2F uses other data structures and protocols that are too specific for a
general-purpose crypto toolkit.
● KeyStore attestation does provide all of the security properties desired by
FIDO relying parties.
● Google will work with FIDO to reconcile the issues.
● Bottom line: FIDO relying parties will be able to use KeyStore. This is
expected to drive widespread use of KeyStore.
