聊聊AUTOSAR：信息安全之Crypto Stack篇

随着智能化时代的发展，越来越多的汽车融入到互联网中，与此同时汽车的网络安全也逐渐受到重视。AUTOSAR作为目前全球范围普遍认可的汽车嵌入式软件架构，已经集成了相关信息安全模块，对实现信息安全需求起到充分的支持作用。

此次为大家介绍一下Crypto Stack。

01 什么是Crypto Stack？

Crypto Stack（加密协议栈），能够为应用程序和系统功能提供对加密服务的标准化访问。

加密服务，例如散列计算(又称哈希计算)、不对称签名的验证以及对称的数据加密，都依赖于底层的加密原语和加密方案。

在AUTOSAR体系中，Crypto Stack主要包含以下内容，详见图1-1：

• Crypto Service Manager(Csm)
• Crypto Interface(CryIf)
• Crypto Driver(Crypto)
• Key Manager(KeyM)

1-1   AUTOSAR layered view with Csm,CryIf,Crypto and KeyM

其中，Csm的功能是允许不同的应用程序通过相同的服务，使用不同的底层加密原语和加密方案。例如，一个应用程序可能需要使用哈希服务计算SHA2摘要，而另一个应用程序通过哈希服务来计算SHA1摘要。

此时加密协议栈就能够配置其需要的服务，并可以为每个服务配置几个不同的方案和原语。

Csm调用CryIf继续进一步操作，CryIf将请求调度到加密驱动程序及静态分配给该服务的加密驱动程序对象。然后调用到配置好的Crypto Driver。

Crypto Driver有如下两种实现方式：

a.  Crypto(HW based)：硬件加密模块的驱动程序，用于控制HSM(Hardware Security Module)或SHE(Security Hardware Extensions),与具体芯片相关。

b.  Crypto(SW based)：基于软件的CDDs(Complex Device Drivers)实现的加密算法，如AES-128等算法。

加密协议栈集成了密钥管理体系结构，在一个加密功能中，密钥和证书的功能比重很大。密钥是一种参数，是在明文转换为密文或将密文转换为明文的算法中输入的参数。许多加密算法都需要使用密钥。因此采用KeyM模块还管理密钥，这种管理主要体现在更新和生成密钥方面，其中密钥和相关数据以端到端的保护形式进行管理。密钥可以基于现有的供应密钥以受信任的方式引入系统，也可以通过本地密钥生成以不受信任的方式引入系统。而证书以加密或解密的形式保障了用户网络中的信息和数据的完整性和安全性。KeyM模块就可以实现证书链的配置保存与验证，使得网络中的信息和数据的安全性更高。

除此之外，加密协议栈也能够提供加密功能服务，该功能的实现是基于软件库设置、硬件模块设置或者它们的混合设置。以上的设置将底层功能实例化，被称为加密库。

02 Crypto Stack 支持的加密算法

这里只是单纯地对AUTOSAR中的Crypto Stack支持的加密算法加以列举，但在本文中不做详细讨论，其原理和具体实现可参阅其他书籍。

03 Crypto Stack 的功能需求

3.1常规

3.1.1.同步作业处理

描述：某些加密服务应允许同步作业处理。

根本原因：有一些加密服务可以很快计算出来。

用例：SecOC模块的MAC生成。(若使用异步作业处理（包括主函数调用和回调函数）则开销太大。)

3.1.2.异步作业处理

描述：某些加密服务应允许异步作业处理。

根本原因：有些加密服务需要大量时间或在HSM中执行。 

用例：签名验证。(若使用同步作业处理将需要太多时间。)

3.1.3.加密协议栈应能够包含加密库的模块

描述：加密协议栈应能够包含加密库的模块。

根本原因：加密库本身必须在AUTOSAR堆栈中可用。

用例：密码原语的软件实现。

3.2配置

3.2.1.加密协议栈应为加密功能提供可扩展性

描述：加密协议栈应保证未使用的加密功能不会编译成二进制。

根本原因：无论硬件是否支持,不同的安全功能需要不同的加密解决方案(例如：对称/非对称加密、哈希)。可用的硬件配置文件提供了不同的功能（例如：内部NVM、随机数生成器、安全CPU核心等）。如果不需要某些功能，则加密功能的可扩展性允许不同的实现策略，从而最大限度地降低软件或硬件资源利用率。

用例：加密协议栈和微控制器硬件功能之间的映射允许硬件供应商为其HSM开发通用驱动程序。

3.2.2.加密协议栈应允许对用于加密作业的密钥进行静态配置

描述：加密协议栈应允许用于加密服务的对称和非对称密钥对的静态配置。

根本原因：应能够单独使用密钥。

用例：在HSM中使用受保护的密钥进行数据加密。

3.2.3.加密协议栈应仅允许唯一的密钥标识符

描述：为每个加密密钥配置一个keyId。

根本原因：应能够单独处理密钥。

用例：加密密钥的使用。

3.2.4.加密协议栈的模块应仅支持预编译时配置

描述：加密协议栈的模块应仅支持预编译时配置。

根本原因：Post-build或link-time parameters不适用。

用例：所有可配置的参数值都必须在编译或构建之前决定。

3.2.5.加密协议栈模块的配置文件应可供人读取

描述：加密协议栈模块的配置文件应可供人阅读，例如，通过整合评论或工具支持。

根本原因：配置应具有可读性和可理解性，必须人为阅读并理解配置。

用例：调试。

3.3通常控制

3.3.1.加密协议栈应支持所有加密服务的可重入性

描述：加密协议栈应支持加密相关接口的可重入性，以此在多个用户请求时实现相同或不同类型的并行操作。此要求还涵盖了应用程序驻留在不同核心上的场景。

根本原因：加密作业应可同时处理。

用例：不同的应用程序可以并行使用加密服务。同时处理不同的任务是必要的。

3.3.2.加密协议栈应向加密服务的用户隐藏对称密钥

描述：不应存在直接向用户提取对称密钥值的接口。密钥应由用户通过标识符进行寻址。此类密钥只能以加密格式导出。

根本原因：如果密钥存储在应用程序中，则会增加密钥失效或被泄露的可能性。

用例：驻留在HSM中的密钥。

3.3.3.加密协议栈应向加密服务的用户隐藏非对称私有密钥

描述：不应存在直接向用户提取非对称私有密钥值的接口。密钥应由用户通过标识符进行寻址。此类密钥只能以加密格式导出。

根本原因：如果密钥存储在应用程序中，则会增加密钥失效或被泄露的可能性。

用例：驻留在HSM中的密钥。

3.3.4.加密协议栈应将随机数生成识别为可向驱动程序请求的加密原语

描述：加密协议栈应将随机数生成识别为可向驱动程序请求的加密原语。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的随机数生成器。

用例：生成随机数。

3.3.5.加密协议栈应将对称加密/解密识别为可向驱动程序请求的加密原语

描述：加密协议栈应将对称加密/解密识别为可向驱动程序请求的加密原语。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的对称算法。

用例：加密通讯。

3.3.6.加密协议栈应将非对称加密/解密识别为可向驱动程序请求的加密原语

描述：加密协议栈应将非对称加密/解密识别为可向驱动程序请求的加密原语。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的非对称算法。

用例：采用成功的异构软硬件解决方案的独特接口。

3.3.7.加密协议栈应将MAC生成/验证识别为可向驱动程序请求的加密原语

描述：加密协议栈应将MAC生成/验证识别为可向驱动程序请求的加密原语。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的MAC算法。

用例：SecOC使用MAC验证消息。

3.3.8.加密协议栈应将非对称签名生成/验证识别为可向驱动程序请求的加密原语

描述：加密协议栈应将非对称签名生成/验证识别为可向驱动程序请求的加密原语。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的非对称签名算法。

用例：签名创建/验证。

3.3.9.加密协议栈应将哈希计算识别为可向驱动程序请求的加密原语

描述：加密协议栈应将哈希计算识别为可向驱动程序请求的加密原语。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的哈希算法。

用例：签名认证。

3.3.10.加密协议栈应提供用于生成非对称密钥的接口

描述：加密协议栈应为非对称密钥对服务的生成提供一个抽象接口。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的密钥生成服务。

用例：一旦在ECU内部生成非对称密钥对，在ECU之外就不能再获得私有密钥。

3.3.11.加密协议栈应为生成对称密钥提供接口

描述：加密协议栈应通过标准化接口，从各种加密驱动程序存储的多个对称密钥中提取用户。此外，还应为驱动器提供一个接口，用于生成此类密钥。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的密钥生成服务。

用例：基于密码的密钥输入。

3.3.12.加密协议栈应提供用于导出对称密钥的接口

描述：加密协议栈应通过标准化接口，从各种加密驱动程序存储的多个对称密钥中提取用户。此外，还应为驱动器提供一个接口，用于推导此类密钥。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的密钥推导服务。

用例：基于密码的密钥输入。

3.3.13.加密协议栈应为密钥交换机制提供接口

描述：加密协议栈应支持作为密钥管理接口的密钥交换机制。

根本原因：应使用同质接口访问驻留在不同加密驱动程序上的密钥交换算法。

用例：会话处理。

3.3.14.加密协议栈应为密钥包装/提取机制提供接口

描述：加密协议栈应支持密钥封装和提取机制，方向从Csm转到相应的驱动程序。支持包装对称密钥和非对称密钥。

根本原因：驱动程序中实现的密钥包装和封装算法不应被用户直接访问，需要进行抽象。

用例：会话处理。

3.3.15.加密协议栈应为解析认证提供接口

描述：加密协议栈应支持解析证书和提取包含的密钥。

根本原因：加密驱动程序应解析新的证书，并将信息存储在相应的密钥中。

用例：对于PKI，有必要从证书中获取公钥。

3.3.16.加密协议栈支持检测无效密钥

描述：加密原语的实现应检测并拒绝无效密钥。

根本原因：例如RSA或几种ECC类型的算法指导密钥，这些密钥被用于数学算法中没有错误但不安全的特殊情况下，密钥必须被识别并拒绝。但因为没有通用方法，因此在使用软件加密时必须在加密原语中实现；在加密硬件的情况下，在其驱动程序中实现。

用例：RSA和一些Elliptic Curve Cryptosystems。

以上就是本次有关Crypto Stack的科普内容，如果想了解更多，可以将需求发送到邮箱market@dotrustech.com，会有专人为您解答~

下次系列文章我们将介绍“信息安全之CSM”,敬请期待~。

文章转载自公众号：东信创智