汽车网络信息安全概述
首先按照惯例，先对汽车网络安全做个科普。
随着汽车网联化和智能化，汽车不再孤立，越来越多地融入到互联网中。同时，汽车也慢慢成为潜在的网络攻击目标。
这边不做过多赘述，只是强调一下 网络安全和功能安全的区别，经常会有人疑惑这两者之间的关系，这边引用一张vector的图，非常清晰的展示了两者之间的区别：
功能安全是保护人为目的的，车如果发生故障的话，目的是让车能尽可能的可控，不会失控去对人做出伤害
网络安全是反过来保护车辆系统的，防止黑客的入侵，控制或者窃取车辆信息，使车辆不可控，或者干一些违法的事情
网络安全相关
那么车辆哪些部件是网络安全相关的，哪些不是相关的呢？ISO21434中已经给出明确的定义，如右图所示，展示了如何判定汽车中的相关组件是否和网络安全相关。这个判断一般是由主机厂做，然后把需求给到下层供应商，所以我们不做过多描述：
这边我们做出如下总结：
1. 像T-BOX，TCU，网关等节点或功能，必须考虑网络安全，因为它们有直接的对外连接
2. 具有高功能安全等级，比如ASIL C/D的节点，也要实施网络安全
3. 涉及存储和处理与车辆或者驾驶员相关数据的节点，也需要实施网络安全措施，以防止重要信息泄露或者被窃取
4. 有无线连接的节点，比如蓝牙，NFC，WIFI等有关的组件也要涉及网络安全，因为他们是最容易被攻击的组件
5. 对外连接的节点，比如对外连接的总线，OBD
对于网络安全相关的部件需要做哪些安全保护措施，这边引用了vector一张图来展示，个人觉得比较清晰：
AUTOSAR CP 信息安全架构
好了，前面科普啰嗦了太多了，那么在AUTOSAR架构中是怎么实现网络安全功能的呢？
这个话题涉及的内容就比较多，今天我们只讲Crypto Stack的实现。
如下图，是AUTOSAR CP 信息安全架构图：
可以看到Crypto Stack分为三部分
Crypto Service Manager（CSM）： 是其他软件模块调用加解密模块的第一接口。应用层SWC通过RTE访问CSM，而其他底层软件（BSW）或者复杂驱动（CDD）则可以直接调用CSM。同时CSM也负责安全相关任务的队列管理，即优先级管理。
Crypto Interface（CryIf）： CSM往下调用的接口模块，每一个CryIf中的加密基元都会与CSM中的一个服务相对应。而且CryIf支持分发相关任务，进一步调用不同的驱动
Crypto Driver（CryDrv）： 驱动模块，访问相关部件，实现加解密操作，例如访问加解密加速器或者真随机数生成器等
为什么会存在 CSM, CryIf，Crpto Driver？
是为了将硬件HSM的接口做一个封装，以便上层服务可以标准化调用，而不受HSM的不同的影响。
汽车信息安全之锚：HSM
那我们就先了解一下HSM。
HSM是硬件安全模块的英语缩写，全称是Hardware Security Module。 随着信息安全变得越来越重要，在通信领域常用的AES、SHA、RSA等加密算法被越来越多地应用到汽车上。但通常这类加解密算法都需要大量的数**算，需要消耗很多CPU时间和资源，汽车上的ECU又有比较高的实时性要求，为了节省主CPU的资源，HSM应运而生。
HSM（Hardware Security Module），它一般会有一个独立的CPU，专门用来进行加解密运算，还有一些针对特定算法的硬件加速器（如AES-128、SHA-256等）。有了HSM模块，程序中就可以把加解密运算交给HSM来执行，主CPU就可以去做其他工作，一段时间后来查询结果，或等待HSM计算完成后通过中断等方式通知主CPU计算结果即可。
而且HSM通常还拥有单独的存储区，包括RAM和NVM，HSM的存储区在正常运行状态下应只允许HSM核读写，主核不能读写。这样就可以把算法秘钥等重要数据存储在HSM存储区，与主核进行隔离，进一步加强安全性。此外HSM模块还会带有真随机数生成器等加密算法常用外设。
HSM两个主要功能：
第一个是存储管理密钥。 第二个是加速加解密算法
英飞凌AURIX系列MCU的HSM
以TC397为例，HSM作为外设之一，挂载在单片机的SPB系统外设总线上。
HSM展开后的架构图，HSM有一个基于ARM Cortex-M3的CPU，有随机数生成器TRNG，AES算法等硬件加速器，以及中断、Timer等组成部分。
其中存储软件程序和数据的PFlash和DFlash实际上与芯片的其他部件共用一块Flash，但是能通过TriCore的访问控制设置，来保护HSM所对应的Flash区域不被非法访问或篡改。安全密钥的存储就是在其中的DFlash里。
AUTOSAR中的HSM接口：Crypto Stack
除了硬件实现，广义的HSM还包括相应的固件和驱动。AUTOSAR跟HSM最相关的就是Crypto Stack：将硬件HSM的接口做一个封装，以便上层服务可以标准化调用，而不受HSM的不同的影响。
上层应用需要执行加密相关的任务时的一个基本工作流程，SWC提供必要的data及jobid，调用CSM提供的接口，接下来分析主核的CSM stack的各个模块为了完成这个任务需要的配置。
CSM, CryIf，Crpto Driver每层都做了什么
举个栗子， HSM有两个加密驱动对象Crypto Driver Object：HW-AES和HW-RSA
它们每个都有自己的通道。每个通道连接到一个CSM队列和一个Crypto Driver Object队列。
两个Crypto Driver Object都在分别处理一个加密作业：AES-high和RSA
其中一个Crypto Driver Object的队列包含另一个作业(AES-low)。如果HSM的HW-AES已经完成了AES-high的任务，则将AES-low的任务作为下一个任务处理。
假设应用程序的新作业调用RSA:
如果RSA的Crypto Driver Object不繁忙，则立即处理该任务。
如果RSA的Crypto Driver Object很忙，但是Crypto Driver Object的队列未满，则该作业将按优先级顺序列在该队列中。一旦Crypto Driver Object空闲，将执行Crypto Driver Object队列中具有最高优先级的作业。
如果RSA的Crypto Driver Object很忙，并且Crypto Driver Object的队列已满，则该作业将按照优先级顺序存储在CSM队列中。·
如果RSA的Crypto Driver Object忙，且Crypto Driver Object队列和CSM队列都已满，CSM会拒绝请求。
如果RSA的Crypto Driver Object是活动的，则作业已经在加密驱动程序中启动，正在等待更多的数据来处理或完成命令。
Crypto Driver（CryDrv）配置
主核的Crypto层主要负责与HSM的交互，将任务转发给HSM，并获取响应 Crypto模块需要如下container，如果不存在就需要右键Crypto添加这些Container.
1、CryptoPrimitives配置用到的算法
我这边举了一个CAMC Verify的例子.
2、配置CryptoDriverObjects
我这边只添加一个Object: HSM_Crypto
3、配置CryptoGeneral
4、配置CryptoKeyElements
5、配置CryptoKeyTypes
6、配置CryptoKeys
Crypto Interface（CryIf）配置
CryIf将CSM层的请求转发到对应的CryptoDriver。它涉及到的主要配置就是CryIfChannel。它将Csm层的job和实际处理cryptoDriverObject对应起来。 CryIf模块需要如下container: CryIfChannels, CryIfCryptoModules, CryIfKeys, CryIfGeneral.
1、配置CryIfChannels：
Driver Objects Ref就是Crypto模块配置中配置好的
2、配置CryIfCryptoModules
3、 CryIfKeys配置
4、CryIfGeneral配置
Crypto Service Manager（CSM）配置
CSM层提供标准的接口给SWC和BSW来实现加解密相关的功能，可以是同步的，也可以时异步的。 Csm模块需要如下Container: CsmPrimitives, CsmCallbacks, CsmGeneral, CsmJobs, CsmKeys, CsmQueues.
1. CsmJobs配置
SWC或者BSW调用接口时除了data之外只传了jobid，而没有类似使用什么key，什么算法之类的东西，CSM job封装了所有这些信息，可以被视为在CryptoDriverObject中实现的加密算法的实例。所以通过CSMJob为入口分析CSM的配置
2、CsmPrimitives配置
CSM job会引用到Csm层的CsmPrimitive
3、CsmKeys配置
4、CsmQueues配置
5、CsmGeneral配置
6、CsmCallbacks配置
异步执行作业时需要有callback函数。根据需要配置，这边只是举个例子
CSM API的调用
CSM 的 API 大致可以分为两类：直接API（主要用于密钥管理）和 基于作业的API（主要用于加解密操作）
直接 API（Direct API）：
直接对应于 CryIf 和加密驱动程序中的函数。这些函数只能同步调用。CSM 会将参数从应用程序直接传递给函数调用。
基于作业的 API（Job-based API）：
使用作业结构 Crypto_JobType，它包含静态和动态参数以及对结构的引用。此数据为加密驱动程序提供执行该作业所需的所有信息。每个使用作业的服务都将使用此结构。服务的所有必要参数将由 CSM 打包到结构的元素中，然后将调用 CryIf，而这又将调用配置的加密驱动程序。
直接API是直接调用，只能同步调用，比较简单，这里不做过多描述
我这边想要讲一下基于job的API的调用的同步模式，和异步模式
同步作业模式
Synchronous Mode Synchronous mode: CSM服务Job在调用方的上下文中立即执行，函数返回结果直接可用 因为对于同步作业处理来说，队列排队可能用途不大。所以如果选择了同步作业处理，则建议把队列大小设定为 0。 但是，如果通道同时支持同步和异步作业，则队列排队机制还是有使用的必要。在 Csm_MainFunction() 中，可以将排队的作业传递给给 CRYIF 模块。
异步作业模式
Asynchronous Mode Asynchronous mode: 异步作业稍后由专用CRYPTO在预先安排的主函数上下文中或硬件中处理。如果特定的CRYPTO驱动程序对象因为繁忙而拒绝该作业，CSM将服务请求放在相应的CSM作业队列中。CRYPTO使用CRYIF的回调函数通知CRYIF异步作业的完成。CRYIF通过CSM的回调函数转发结果。
CSM Job的调用
最后来总结一下CSM job调用的流程：
CSM Job可能有多个队列，每个队列映射到一个单独的加密驱动对象Crypto Driver Object(CDO)，从而可以访问CDO的加密原语crypto primitives，CRYPTO因为繁忙拒绝了CSM的服务请求后，特定的Job会根据其优先级放入相应的CSM队列中， 在Csm_MainFunction()循环调用期间，排队的Job被传递给CRYIF。CRYIF将把Job转发给特定的CRYPTO。 为了优化CDO的硬件使用CDO也可以有选择的有Job Queuing。 每个Job的优先级根据其配置决定其优先级，优先级值越高，优先级越高，Job将根据其优先级执行。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/2301_76563067/article/details/132065031
|
楼主
标题置顶
标题高亮
