AUTOSAR中的Crypto Stack(二)--CSM数据类型

mengmianren

目录

01.Crypto_JobType

02.Crypto_JobPrimitiveInputOutputType

03.Crypto_PrimitiveInfoType

04.KeyType

05.小结

在上一节，简单梳理了加密栈的基本要求。其中最关键最核心的还是用户如何使用HSM这个黑盒子，这就必须要对Crypto Service Manager要有很清晰的认识。

那么首先我们还是围绕概述里提到的job类型进行分析。

01.Crypto_JobType

首先直接上个抽象图：



在AUTOSAR的架构里，所有的密码操作都是围绕job进行，因此拿捏job势在必行。
举一个实际例子，假设现在有一个报文A需要进行CMAC校验（SecOC场景），那么这个校验动作就为一个job，其结构体类型就为Crypto_JobType。那在配置代码里，就一定有一个job配置对象，叫做Crypto_JobType Csm_Job_Cmac_verify_A

job统一作为一个全局变量如下：



在Csm_init，将配置信息初始给job。

02.Crypto_JobPrimitiveInputOutputType

由上图，我们还可以看到一个很关键的实心箭头与Crypto_JobType相连接，对应的对象叫做e和Crypto_JobPrimitiveInputOutputType，实心箭头表示一种组合关系，后者的生命周期是与前者一致；其他空心箭头则是一种聚合关系，可以共享。

由于存在JobPrimitiveInputOutputType类型，里面包含输入的buffer、输出的buffer、cryif对应key id、运行模式等等需要分配，因此在软件设计中Crypto_JobType为全局变量。

JobPrimitiveInputOutputType存储了依赖于服务的所有关于输入和输出参数的信息，具体而言就是要待处理数据、数据长度、返回的mac buffer、待校验的mac等。在初始化的时候，将该buffer初始化：



03.Crypto_PrimitiveInfoType

密码算法原语，包括算法类型、返回结果长度、算法模式、服务类型(加密、解密)等；

这部分是静态配置，如下：



在初始化的时候，将这部分内容关联到对应job上，这也就是第一节我们提到的算法原语和key是相互独立的。

那么关键的，AUTOSAR标准里要求支持哪些算法呢？这就不去读文档了，看实现。



工作模式如下：



04.KeyType

好，上面我们把job关于密码原语、装载数据要用的buffer关联好了，还有一个最重要的，那就是算法对应的key。这个很关键，但实际上key这个东西是独立的，比如说5条SecOC报文要做AES128-CMAC，很有可能就是使用一个AES128-CMAC-Verify-Key，那实际上配置也需要用一个table来存储key的索引，如下：



05.总结

好了，加密栈要求密钥、数据、密码原语等基本都有了，那么就只需要用户调用，并将需要处理的数据放到加密栈里即可。

在实际CP开发中，这部分内容都是已知且提前静态配置完成，比如说什么报文要去做校验、安全启动具体要校验哪些地址范围、安全启动使用并行还是顺序等等。

这与AP或者SOC上调用HSM不一样，以手机内容的加解密为例，SOC自身并不能提前知道要处理的数据是什么，只有当用户把要处理的内容给加密栈后，这个栈才会去动态申请内存进行处理，完成后销毁，这一点还是有很大差距，

那么上述动态处理的实现方式对于实时性要求很高的动力、底盘控制是否有效呢？

目前还是比较存疑，因为首先如果没有提前静态配置加解密算法、限制要加解密数据，势必要将很多算法囊括在内，包括非对称、对称等，这会造成HSM侧代码量剧增，同时动态分配内存也会存在很多风险。

开垦者

关于AUTOSAR中的Crypto Stack（二）的CSM数据类型——针对CryptoJobType的分析如下：

CryptoJobType 是加密栈中的核心数据类型之一，代表了不同的加密任务类型。具体包含多种作业模式，如数据加密、哈希计算等。此数据类型定义了在加密栈中执行的具体任务类型，为后续的任务管理和执行提供了基础。在实际应用中，通过此类型的数据，用户可以与HSM（硬件安全模块）交互，进行不同类型的加密操作。具体的类型定义及使用场景会在后续文档中详细阐述。针对实际应用场景，需要深入理解此数据类型的含义和使用方法，以确保加密任务的正确执行。