AUTOSAR中的Crypto Stack(1)--概述

hudaren43

前面我们聊到了比较多的关于信息安全的概念，以及主流MCU的信息安全方案。但从软件工程师的角度来看，最终这些信息安全的概念都是会从软件来实现；

如何设计出一种合理、安全的信息安全软件框架，

我们从AUTOSAR的加密栈来分析。

01.Crypto Stack概述
目前最新的标准为CP R22-11，所以我们借这个标准来看一下Crypto Stack。

该协议栈主要是给应用、系统服务等提供一种标准接口，该接口可以访问内置\外挂HSM的加解密算法硬件加速、软件自定义的加解密算法等。

其基本架构如下：


上图可以看到，Crypto Stack遵循经典AUTOSAR的标准框架，

SWC或者User通过如下接口访问加密驱动资源，CSM(服务层)-> CryIf(接口层) -> Crypto Driver(MCAL)。

从上图右边可以看到，CryIf -> Crypto Driver这一路，对象是内置HSM的MCU(这里只讲evita-full)或者小SOC，但就这么明晃晃地调用，显然不符合信息安全要求。

可以这样想，从信息安全的角度，加密服务提供者对它就是一个黑盒子，使用者只能输入，然后加密服务提供者输出，具体里面如何实现不是使用者操心的。这里的加密服务提供者就是通常意义上的HSM。

因此，在实际方案设计里，Crypto Stack会部署在使用者(Host)和服务者(Hsm)两颗核上，两者通过mailbox或者共享内存的方式进行通讯，如下图：


图为Vector基于某芯片设计的信息安全架构。

在Host APP和Host Secure Boot虽然也有Crypto Driver，但实际上这个Driver是无法直接访问HSM的算法硬件加速器；为啥？还是老生常谈，基于信息安全角度考虑。

那么要怎么做才能访问呢？通过IPC，以共享内存为例，Host侧将要加密的数据、调用的加密算法及工作模式、该数据要使用的密钥组包存放到共享内存，HSM侧轮询或者根据Host触发的中断，去读取共享内存中的数据包；

由于Host和HSM都遵循AUTOSAR的标准，因此HSM侧可以将该数据包根据标准进行解析，获取加密算法并调用相应的硬件加速器、密钥等、完成数据的加解密。

02.Crypto Stack关键概念

AUTOSAR基于上述描述，定义了一些关键概念。
2.1 Crypto_Primitive

Primitive，即加密原语，源自于密码学。

原语，我个人理解，主要还是强调的是使用动机。

AUTOSAR使用加密原语的概念来定义了密码操作，包括要使用什么密码算法、用于加密还是解密。

在CP AUTOSAR中，软件开发阶段就要对加密对象选择密码算法、操作模式进行配置。如下图：



举个例子，假设我选择对某一个SecOC属性的报文做AES-128-CMAC的计算，那么在Host侧和HSM都要同时配置一个Primitive，算法为AES128，工作模式为CMAC，MAC值长度等。

但是否Host就可以直接使用Primitive呢？不可以。

为什么呢？因为使用这个原语的场景还没有定义，比如说CMAC计算的同步还是异步的？优先级怎么样？用什么样的密钥？

所以，就继续引入了Job的概念

        拓展：why静态配置？CP ASR基本用于实时性要求很高的场景，同时对象多为片内Flash较小的MCU，动态分配实现起来困难。

2.2 Crypto_Job

Job，见名知意，那就是一个任务（与Task区别），该任务就定义了primitive没有定义的东西：该job的优先级、同步异步处理、关联的key ID等，如下图：



我们这里只讲了job中和原语相关的类型，在下一篇文章将详细描述job类型，看看代码怎么玩的。

2.3 API分类

根据上面描述，primitive只是描述了算法、工作模式、MAC长度；而所使用的密钥是通过Job去关联的。那么我们对于密钥的存储、更新、派生是不是就可以不通过job，而直接调用某种API去处理呢？AUTOSAR也帮我们考虑了这点。
它设计了两套API：

直接API用于密钥管理；基于job的API，用于密码操作。

如下图所示：



从这个两种API，我们可以看到，
左边不管服务层调用什么算法，Hash也好，加密也好，最终都是封装成job类型的数据包交由driver一个api进行处理；而右边不一样，密钥的管理是一一对应的，例如KeySetValid在每一层都一个专用接口。
但我个人，觉得这样做，有点憨，接口层代码又多了一大套。

其实可以也用CryIf_ProcessJob，在该函数里面进行分发即可，省却接口，即省测试消耗。
2.4 密码运行模式

AUTOSAR针对密码运行模式也提出了一个状态机。



其实这个状态机，只要看过HSM相关的参考手册，就能明白，这种状态机其实对应的HSM的指令序列。
例如，

Start，就是调用INIT指令，往对应的加速器里填写算法、工作模式、密钥信息、IV、待加解密数据等；

Update，就是同时加速引擎开始处理数据了，为什么会有多个update？因为目前多数对称都是基于分组算法，需要软件将数据拆成算法规定的大小block，然后依次处理；

Finish也算是一条指令，清除引擎中对应的此次操作的上下文等。
2.5 Queue

既然在job提到了优先级的概念，那么优先级管理肯定是必须要搞起来的。

队列这个东西就出现了。

AUTOSAR首先定义了一个东西叫做chanel，这个干啥的呢？就是将密码操作进行分类，例如对称一个通道、非对称一个通道、Hash一个通道。

那么每个通道里就排着job等待处理(针对异步的)。如下图：


这个图很清晰，queue里做优先级排布；

其实我发现在实际运用中，特别是在SecOC这里面，很多都是同步的，数据包干到share memory里马上要求处理；所以优先级这个问题，得好好分析其用法。

03.总结

结合上面的描述，我们对加密栈简单有了一个认识，但这里我没有讲最新出的一个feature：redirection功能。

大家可以积极讨论，因为这个加密栈，AUTOSAR出的架构不一定最优，不然ETAS和Vector就会全部按这个来做了。

而且我们对于信息安全固件的交付是黑盒白盒也影响着开发的工作量。

andyo7

关于AUTOSAR中的Crypto Stack概述，我理解这是一个为了满足汽车电子行业信息安全需求而设计的加密协议栈。基于CP R22-11标准，Crypto Stack为应用和系统服务提供了一个标准接口，用以访问加解密算法硬件加速或软件自定义的加解密算法。该协议栈确保了算法实现的安全性，并提供标准化的操作方式。其基本架构通常包括不同层次的模块，如接口层、功能层和安全层等。在设计合理且安全的信息安全软件框架时，我们需要考虑算法的可靠性、安全性、性能以及与其他系统组件的兼容性等因素。另外，需要注意确保代码的安全性和健壮性，如进行严格的代码审查和安全测试等。

mizhongquan

针对所给帖子关于AUTOSAR中的Crypto Stack概述的内容，专业回复如下：

随着汽车信息安全要求的提升，AUTOSAR中的Crypto Stack设计变得尤为重要。基于CP R22-11标准，Crypto Stack提供了标准接口供应用和系统服务调用，用以访问HSM（硬件安全模块）中的加解密算法硬件加速及软件自定义算法。其核心架构包括安全通信接口、安全服务层及安全中间件等部分。设计时需考虑算法的安全性、效率及兼容性。同时，应确保框架的模块化、可扩展性，便于集成至现有AUTOSAR架构中。此外，还需考虑应急情况下的密钥管理策略及安全防护措施，确保系统整体安全可靠性。