ATF官方文档翻译（二）：Authentication Framework & Chain of Trust（身份验证框架和信任链）（1）

前言

本文件旨在描述在可信固件-A（TF-A）中实现的认证框架。该框架满足以下要求：

1、平台端口可以根据证书层次结构及其机制指定信任链去校验镜像和证书。

2、框架需要区别一下：
+ 这个机制是用于编码和传输信息的机制，比如e.g. DER encoded X.509v3 certificates to ferry Subject Public Keys, hashes and non-volatile counters.
+ 用于验证传输信息的机制。（“i.e.是拉丁语 id est 的缩写,意思是“那就是说、换句话说”）如加密库。

该框架按照下图所示的模块化方法设计：


本文档描述了身份验证框架的内部细节以及用于指定信任链的抽象机制。

可以看出这个内部是分为加密、认证、镜像分析模块。可以看出这个模块间的链接依赖关系，加密+镜像校验–>认证校验。

2、框架设计

本节描述了框架设计的一些方面及其背后的基本原理。这些方面是验证信任链的关键。

2.1 信任链

信任链本质上来说就是一系列镜像的校验，这一系列起点是一个信任根，终点是一个单镜像。下面这个图像说明了在COT这个信任链中BL31镜像对应的位置。

信任的根通常是一个公钥（ROTPK），该公钥已在平台中烧掉，无法修改。

这个图片是对于BL31这个镜像的一系列校验过程，整个atf的镜像都是这样。

2.2 Image types（镜像类型）

在信任链中的镜像可以分为认证镜像和数据镜像。

认证镜像：认证镜像包含的信息是校验数据镜像或者其他的认证镜像

数据镜像：数据镜像通常是引导加载二进制文件，但它也可以是任何其他需要认证的数据。

2.3 部件的功能

在COT中的每一个镜像，都会有下面的操作去校验它：

1、在静态或者运行态都可以为镜像分配内存

2、校验镜像并将其加载到指定分配内存

3、根据镜像的类型检查镜像的完整性

4、根据所使用的加密算法校验认真镜像（每个镜像对应的算法可能是不同的）

5、如果镜像是认证镜像，那么还需要从这个镜像中提取认证信任链中下一个镜像的信息。

这就是在cot中每个镜像会执行的一些操作。

在第一幅图中，每个组件（AM CM IPM）负责上面这些操作中的一个或多个。具体的工作内容，在下面描述一下。

2.4 TF-A Generic code and IO framework (GEN/IO)（TF-A通用代码和IO框架）

这些组件的功能是负责启动BL1或BL2中特定镜像的认证过程。对于每个BL镜像都需要进行认证，通用代码会递归地向认证模块询问父映像是什么，直到达到认证映像或ROT（The root of trust）（这个就是通用的代码会跟踪这个镜像的整个链），然后调用IO框架去加载镜像，然后调用认证模块去认证这个镜像。（就是检查你的过去，没毛病以后然后检查你自身）这个过程是从ROT -到最后的镜像，都是遵守这个信任链逻辑的。

其实这就是说的整个框架的流程是符合信任链的

信任链需要执行的步骤，在平台对与一些复用的步骤和操作进行了封装。

2.5 TF-A Platform Port (PP)（atf平台接口）

这个平台的工作主要是：
1、指定了CoT中每个需要认真的镜像。平台如何指定CoT的细节将在后面解释。平台还指定了用于每个镜像的身份认证（验证）方法和解析方法。
2、为COT中校验过程中用到的每个镜像的每个参数都静态分配了内存空间。（镜像校验用到的参数，比如公钥、散列值等）
3、提供信任公钥的根或其散列值。（这个应该厂家是通过接口去指定）
4、提供给IPM(镜像解析模块)一些附加的信息使其能识别并提取一些包含在镜像中的认证校验参数，（e、 g.如果参数存储为X509v3扩展，则必须提供相应的OID。）
5、满足IPM和CM的任何其他内存要求（本文件中目前未描述）。
6、向外部提供一些方法验证镜像，这些镜像的验证方法CM无法实现。比如e、 g.如果必须使用NV计数器验证图像，则要比较的计数器值只能由平台提供。
7、如果正在使用特有的镜像格式（稍后描述），也支持自定义实现镜像解析器。

2.6 Authentication Module (AM)（认证模块（AM））

认证模块的功能有什么？

1、

对CoT这个功能进行一定的抽象，便于去操作。其中认证机制和镜像校验机制的方法都必须要在CoT中的PP接口指定好。

2、

CoT是通过GEN验证，而GEN是利用了PP、IPM和CM输出的功能。

3、

确定哪些镜像是被认证了的。举个例子，就是在CoTs这个链上有很多的镜像，确保这些镜像不会被重复验证，而有的镜像漏掉。在TBBR-Client spec.中的 Trusted World Key Certificate，包含了很多的信息，这些信息可以拿来校验SCP_BL2, BL31, BL32 ，他们每个都有自己的信任链。（其实这里比较迷惑的是三者是分开的呢？还是说在他们的这个部分是比较独特的，或者是他们内部的校验流程是不一样的，是一连串的。对于这个有点疑惑，我觉的这里可以理解为子链，就在宏观上我遵守这个CoT，但是小细节的实现流程，按照我自己的操作）

4、

通过存储器的存储器来验证认证镜像（这意思就是校验镜像的内存放在内存中的，校验镜像的时候久去放BL31镜像校验信息的位置去取），例如在图2中描述的CoT中，可以在平台为BL31镜像保留的存储器中加载和验证每个证书。在加载BL31镜像时，将从父镜像（即BL31内容证书）中提取用于认证它的所有信息。假设认证镜像的大小永远不会超过数据镜像的大小。应该可以在构建时使用断言来验证这一点。

小结一下功能：提供了抽象的接口便于使用、校验模块负责保证校验的准确性和唯一性、以及去获取镜像校验文件的位置

2.7 Cryptographic Module (CM) 加密模块

加密模块提供了一些API，这些API的作用是：
1、校验数字前面
2、校验hash
加密模块本身是没有任何加密的代码，CM是依赖一个额外的库去实现加密的操作，因此要实现加密必须连接CM和外部库的加密库（CL）。CL提供以下函数：

这些函数在CM中的通过宏的方式进行注册：

这个name官方要求你包含CL，这样是为了debug的时候方便

2.8 Image Parser Module (IPM) 镜像校验模块

IPM的主要目的是：
1、检查IO框架加载的镜像的完整性
2、在CoT描述符中，提供的描述去实现提取用于认证图像的参数的目的。

因为镜像可能会有不同的格式，因此IPM允许每个镜像提供自己对应的镜像解析库（IPL），将自己对应的解析库注册到CoT中。（ (for example, authentication images could be x509v3 certificates, signed ELF files or
any other platform specific format).）当IPM在CoT中获取到镜像的格式，就会调用对应的IPL库去验证镜像的完整性并获取校验参数。

2.9 认证方法

认证方法包括两种：
1、hash
2、数字签名

平台可以指定这些方法，也可自定义

如果数据图像使用多种方法，则所有方法必须是同一CoT的一部分。参数的数量和类型是方法特定的。这些参数应使用IPM从父图像中获得。

2.9.1 Hash

参数：

a. 数据的指针
b. 数据长度
c. hash的指针
d. hash的长度

散列将由以下ASN.1的DER编码表示：

这是ASN.1结构使得可以去除关于所使用的散列算法类型的任何假设，因为该信息伴随散列。这应该允许加密库（CL）支持多个哈希算法实现。(就是通过这个指定了一种算法，我猜测)

2.9.2 数字签名

参数：
1.指向要签名的数据的指针
2.数据长度
3.公钥算法
4.公钥值
5.数字签名算法
6.数字签名值

公钥参数将由以下ASN的DER编码表示。1类型：

数字签名算法将由以下ASN的DER编码表示。1类型。

数字签名将表示为：

认证框架将使用镜像描述符来提取与认证相关的所有信息。

这个部分有点长，下文再接着来一半