一、车端HSM运用类型及接近的硬件安全概念
依据EVITA典型架构，车端HSM可以分为三种架构：
SHE模块称为Secure HardwareExtension（安全硬件扩展），旨在将密钥的控制从软件到硬件，大体示意图如下：
1.完整HSM模块
保护因V2X通讯引起的漏洞，本质上完整HSM模块拥有可以生成并校验电子签名非对称加密引擎。
从HSM角度，完整形态提供了最高级别功能、信息安全及性能
常见采用完整HSM模块汽车零部件：网关、TBOX、Head Unit、V2X等。
|
Item |
完整HSM |
|
RAM |
x |
|
NVM |
x |
|
对称加密引擎 |
x |
|
非对称加密引擎 |
x |
|
哈希引擎 |
x |
|
计数 |
x |
|
随机数发生器 |
x |
|
CPU安全防护 |
x |
|
IO部件 |
x |
2.中等HSM模块
类似完整版HSM，可执行若干非时间相关的关键非对称密码操作，但其包含性能稍差μC，且无非对称加密硬件引擎。
|
Item |
中等HSM |
|
RAM |
x |
|
NVM |
x |
|
对称加密引擎 |
x |
|
非对称加密引擎 |
|
|
哈希引擎 |
|
|
计数 |
x |
|
随机数发生器 |
x |
|
CPU安全防护 |
x |
|
IO部件 |
x |
3.轻型HSM模块
此等级仅包含对称加密引擎和IO组件，仅简单用于确保ECU与传感器和执行器之间的交互。
|
Item |
轻型HSM |
|
RAM |
可选 |
|
NVM |
可选 |
|
对称加密引擎 |
x |
|
非对称加密引擎 |
|
|
哈希引擎 |
|
|
计数 |
可选 |
|
随机数发生器 |
可选 |
|
CPU安全防护 |
|
|
IO部件 |
x |
二、AutoSAR与HSM关联模块
从CP及AP AutoSAR我们选取与HSM相关联的有代表性的网络安全需求罗列如下：
AutoSAR_RS_Cryptography
|
RS_CRYPTO_02001 |
The Crypto Stack shall conceal symmetric keys from the users |
|
Type |
draft |
|
Description |
There shall be no interfaces for the users to directly extract symmetric key values. Keys shall be addressed via identifiers by the users, preventing the key values disclosure. |
|
Rationale |
If symmetric key values are available in the application at runtime it increases the risk of key compromise. If symmetric key values are stored in the application, centralized key management (e.g. renewal) is hard. |
|
Dependencies |
— |
|
Use Case |
Keys are stored in HSMs and never exposed in plain text. |
|
Supporting Material |
— |
|
RS_CRYPTO_02002 |
The Crypto Stack shall conceal asymmetric private keys from the users |
|
Type |
draft |
|
Description |
There shall be no interfaces for the users to directly extract asymmetric private key values. Keys shall be addressed via identifiers by the users, preventing the key values disclosure. |
|
Rationale |
If asymmetric private key values are available in the application at runtime it increases the risk of key compromise. If asymmetric private key values are stored in the application, centralized key management (e.g. renewal) is hard. |
|
Dependencies |
— |
|
Use Case |
Keys are stored in HSMs and never exposed in plain text. |
|
Supporting Material |
— |
|
RS_CRYPTO_02109 |
The Crypto Stack shall support interfaces for a unified Machine-wide storage and retrieval of different crypto objects |
|
Type |
draft |
|
Description |
A wide range of hardware (e.g. HSM/TPM/SHE based) and/or software based (e.g. encrypted files) can be supported for secure storage and retrieval of different crypto objects (e.g. keys, certificates, digests, etc.). Therefore, a unified Machine-wide access to all these different storage providers abstracts physical details about storage handling and reduces complexity of cooperative usage of different crypto objects by applications. |
|
Rationale |
A few trusted applications can have a need to use some keys (or other crypto objects) cooperatively while applications’ access rights to the crypto object slots needs to be controlled. A logically centralized crypto object storage handling can facilitate these scenarios conveniently.. |
|
Dependencies |
— |
|
Use Case |
— |
|
Supporting Material |
— |
|
RS_CRYPTO_02401 |
The Crypto Stack should support a joint usage of multiple back-end cryptography providers including ones with non-extractable keys |
|
Type |
draft |
|
Description |
The Crypto Stack interfaces should support simultaneous cooperative usage of multiple software or hardware based cryptography implementations, which can implement the concept of non-extractable keys (HSMs/TPMs). |
|
Rationale |
Single ECU can have a few different HSMs/TPMs and additional software implementation of cryptography for usage in different application domains. |
|
Dependencies |
— |
|
Use Case |
— |
|
Supporting Material |
— |
AutoSAR_EXP_LayeredSoftwareArchitecture
AutoSAR MCAL层中包括了HSM或SHE设备的是Crypto Drivers
AutoSAR_SRS_CryptoStack
|
SRS_CryptoStack_00101 |
Asynchronous Job Processing |
|
Type |
Valid |
|
Description |
Some crypto services shall allow asynchronous job processing. |
|
Rationale |
There are some crypto services which require a lot of time or are executed in an HSM. Then, synchronous job processing would require too much time. |
|
Dependencies |
Signature verification |
|
Use Case |
— |
|
Supporting Material |
— |
|
SRS_CryptoStack_00008 |
The Crypto Stack shall allow static configuration of keys used for cryptographic jobs |
|
Type |
Valid |
|
Description |
The Crypto Stack shall allow static configuration of symmetric and asymmetric key pairs used for crypto services. |
|
Rationale |
It shall be possible to use keys individually. |
|
Dependencies |
Data encryption with a protected key in the HSM. |
|
Use Case |
— |
|
Supporting Material |
— |
|
SRS_CryptoStack_00010 |
The Crypto Stack shall conceal symmetric keys from the users of crypto services |
|
Type |
Valid |
|
Description |
There shall be no interface to extract symmetric key values directly to the user. Keys shall be addressed via identifiers by the users. Such keys shall only be exported in an encrypted format. |
|
Rationale |
If keys are stored in the application, this increases the chances of invalidation of keys or keys being compromised. |
|
Dependencies |
Keys residing in the HSM |
|
Use Case |
— |
|
Supporting Material |
— |
|
SRS_CryptoStack_00011 |
The Crypto Stack shall conceal asymmetric private keys from the users of Crypto services |
|
Type |
Valid |
|
Description |
There shall be no interface to extract asymmetric private key values directly to the user. Keys shall be addressed via identifiers by the Users. Such keys shall only be exported in an encrypted format. |
|
Rationale |
If keys are stored in the application, this increases the chances of invalidation of keys or keys being compromised. |
|
Dependencies |
Keys residing in the HSM |
|
Use Case |
— |
|
Supporting Material |
— |
|
SRS_CryptoStack_00098 |
The Crypto Driver shall provide access to all cryptographic algorithms supported by the hardware |
|
Type |
Valid |
|
Description |
The Crypto Driver shall support access to all by the Crypto Stack supported algorithms. |
|
Rationale |
Usage of hardware support and performance benefits. |
|
Dependencies |
Primitives which are supported by the HSM should be accessible through the Crypto Driver. |
|
Use Case |
— |
|
Supporting Material |
— |
AutoSAR_SWS_CryptoDriver
加密驱动程序对象表示独立加密硬件“设备”（例如AES加速器）的实例。对于高优先级作业，HSM上可能有一个用于快速AES和CMAC计算的通道，该通道以加密驱动程序中的本机AES计算服务结束。但也有可能，加密驱动程序对象是一个软件，例如用于RSA计算，其中作业能够加密、解密、签名或验证数据。加密驱动程序对象是加密通道的端点。
AutoSAR_SWS_CryptoInterface
加密接口模块提供一个独特的接口，用于管理不同的加密硬件和软件解决方案，如HSM、SHE或基于软件的CDD。
AutoSAR_SWS_CryptoServiceManager
HSM有两个加密驱动程序对象（HW-AES和HW-RSA），每个对象都有自己的通道。每个通道都连接到CSM队列和加密驱动程序对象队列。
在这种情况下，两个加密驱动程序对象分别处理一个加密作业（AES高和RSA），而加密驱动程序对象的队列又包含一个作业（AES低）。如果HSM的HW-AES完成AES高作业，AES低作业将作为下一个作业处理。
AUTOSAR_SWS_SecureOnboardCommunication
SecOC模块依赖于CSM模块在AUTOSAR中提供的加密算法。SecOC模块需要API函数来生成和验证加密签名或消息身份验证码，即
-
MAC生成接口（Csm_MacGenerate）
-
MAC验证接口（Csm_MacVerify）
-
签名生成接口（Csm_SignatureGenerate）
-
签名验证接口（Csm_SignatureVerify）
三、FIP140-2
本标准针对安全模块定义了总计四个安全级别，大体如下
|
安全级别 |
级别1 |
级别2 |
级别3 |
级别4 |
|
内容 |
仅加解密模块 |
加解密模块、基于角色的访问授权机制、运行环境安全EAL2+、一定的抗物理攻击能力 |
完备的抗物理攻击能力（立即清理敏感数据）、基于身份的访问授权机制、参数传递安全、运行环境EAL3+ |
完全抗物理攻击能力、运行环境EAL4+ |
而从国内国密对于安全芯片的三个等级：
|
安全级别 |
安全等级1 |
安全等级2 |
安全等级3 |
|
内容 |
安全芯片对密钥和敏感信息提供基本的保护措施 |
在安全等级1基础上，安全芯片须具有的逻辑和物理防御措施，并要求送检单位能够对相应防御措施的有效性进行说明，安全芯片应具有较全面的生命周期保障 |
在安全等级2的基础上，安全等级3规定了安全芯片须具有的逻辑和物理保护措施。安全等级3要求安全芯片能够对密钥和敏感信息提供高级保护，要求安全芯片具有逻辑和物理安全机制能够对密钥和敏感信息提供完整的保护，要求安全芯片能够防御本标准指定的各种攻击，要求送检单位能够证明相关防御措施的有效性，并要求安全芯片应具有完整的生命周期保障 |
四、基础Use Case分析
参考网址https://mp.weixin.qq.com/s/0XM2dlMYCjndhpZy8-EiNg中所分析的网络安全需求及功能安全需求，我们可以得到如下目标与ADS控制器中HSM相关：
|
ID |
安全需求描述 |
ASIL |
分配 |
FHTI（ms） |
|
SR02 |
如果ADS收到ESP故障报警信息，忽略ESP踏板状态信号，信任备份（IBooster）踏板状态… |
D |
ADS |
20 |
|
SR04 |
如果ADS未收到ESP制动踏板踩下信号，ADS禁止退出pilot功能； |
D |
ADS |
80 |
|
ID |
需求 |
防护等级 |
|
CS-01 |
防止ADS控制器融合算法的保密性受非法披露 |
CAL2 |
|
CS-02 |
防止ADS控制器融合算法的完整性受非法篡改 |
CAL2 |
|
CS-04 |
防止ADS控制器状态机的保密性及完整性受非法披露和篡改 |
CAL2 |
提取上述SR04及CS-04，可以得到一点，如果ADS控制器状态机或相关信息被非法披露且篡改，则此时功能安全目标SR04有被违反可能即
如果ADS控制器状态机被篡改，ADS在未收到ESP制动踏板踩下信号时仍退出pilot功能。
具体设计：
ADS控制器状态采用类似机可以采用介于FIP140-2中2或3等级的加密模块HSM保证安全性，在AutoSAR中涉及到的资源及网络安全链路concept如下：
从这个链路中我们可以发现：
App1，App2及App3是ASILD的，同时均需要被网络安全机制保护。
因制动踏板相关信号及HWP功能状态速度通常是10ms一次，因而用AES算法计算比较快，但ADS状态机可以是80ms FHTI，此时可以用保密性更强的RSA模型。
因CSM/CryIf/Crypto Hardware称为Crypto Stack，此时从CSM的工作图，可以简要推导出如下与HSM相关的AutoSAR需求ASIL级别及CAL级别，并由此更加明确HSM的ASIL级别和等级：
|
Context |
ASIL |
CAL |
HSM functionality |
|
|
RS_CRYPTO_02001 |
The Crypto Stack shall conceal symmetric keys from the users |
D （旧方案，如果新方案考虑座舱对人的监控则可降低到B） |
CAL2 |
D (Safety functional) Key store in HSM |
|
RS_CRYPTO_02002 |
The Crypto Stack shall conceal asymmetric private keys from the users |
D （旧方案，如果新方案考虑座舱对人的监控则可降低到B） |
CAL2 |
D (Safety functional) |
|
RS_CRYPTO_02109 |
The Crypto Stack shall support interfaces for a unified Machine-wide storage and retrieval of different crypto objects |
D |
CAL2 |
D
secure storage and retrieval of different crypto objects (e.g. keys, certificates, digests, etc.) |
|
RS_CRYPTO_02401 |
The Crypto Stack should support a joint usage of multiple back-end cryptography providers including ones with non-extractable keys |
D |
CAL2 |
D
concept of non-extractable keys (HSMs/TPMs). |
|
SRS_CryptoStack_00101 |
Asynchronous Job Processing |
Not D，normally |
CAL2 |
B Different time countering
Counter is must |
|
SRS_CryptoStack_00008 |
The Crypto Stack shall allow static configuration of keys used for cryptographic jobs |
QM(D) |
CAL2 |
Configuration
FLASH/RAM is requested |
|
SRS_CryptoStack_00010 |
The Crypto Stack shall conceal symmetric keys from the users of crypto services |
D |
CAL2 |
D Keys residing in the HSM |
|
SRS_CryptoStack_00011 |
The Crypto Stack shall conceal asymmetric private keys from the users of Crypto services |
D |
CAL2 |
D
Due to keys residing in the HSM |
|
SRS_CryptoStack_00098 |
The Crypto Driver shall provide access to all cryptographic algorithms supported by the hardware |
D |
CAL2 |
D Primitives which are supported by the HSM should be accessible through the Crypto Driver. |
由上述需求的要求，我们得到了该ADS控制器对HSM的特性要求：
|
Item |
完整HSM |
CAL |
ASIL |
|
|
RAM |
x |
2 |
B (粗略估计) |
SRS_CryptoStack_00008 RS_CRYPTO_02109 RS_CRYPTO_02001 |
|
NVM |
x |
2 |
D |
SRS_CryptoStack_00008 SRS_CryptoStack_00011 SRS_CryptoStack_00010 RS_CRYPTO_02401 RS_CRYPTO_02109 RS_CRYPTO_02001 |
|
对称加密引擎 |
x |
2 |
D |
RS_CRYPTO_02002 |
|
非对称加密引擎 |
x |
2 |
D |
RS_CRYPTO_02002 |
|
哈希引擎(生成MAC) |
x |
2 |
D |
SRS_CryptoStack_00011 SRS_CryptoStack_00010 |
|
计数 |
x |
2 |
B |
SRS_CryptoStack_00101 |
|
随机数发生器 |
x |
2 |
D |
RS_CRYPTO_02401 |
|
CPU安全防护 |
x |
2 |
D |
RS_CRYPTO_02002 |
|
IO部件 |
x |
2 |
D |
SRS_CryptoStack_00098 |
如下是关于全套HSM上，每个子模块的ASIL级别
如何实现不同ASIL等级在AutoSAR上的设计，如下仅举Memory partition为例子：
每个memory partition之间，通过CSM—CryIF—CryDriver—-HSM这条链路进行。
END
原文始发于微信公众号（汽车信息安全）：谈谈AutoSAR中HSM相关功能安全
