AUTOSAR|AUTOSAR SecOC Introduction -- Part 1 AUTOSAR|autosar

Introduction AUTOSAR Secure Onboard Communication (SecOC) 作用是提供一种机制用于保证ECU之间通信过程中的“重要”数据的完整性和身份验证。目前SecOC 需要和COM Stack 结合使用，对于SWCs之间的数据保护则不能使用SecOC
在AUTOSAR 架构中，SecOC 和PDUR 数据同一层，其要负责和Crypto Stack交互进行数据加密与验证，也要负责和PDUR 交互进行数据的传递

文章图片

传统通信方式弊端

数据完整性的保护机制没有或者很弱

由于数据完整性保护机制没有或者很弱，ECU 之间传输的数据如果在传输过程中存在较容易被篡改的风险。
2.无法保证数据来自一个合法的数据源头
如果发送的数据可以轻易被其他人模拟发送，ECU 就无法判断接收到的数据命令是否来自一个合法的数据源
3.如果通过提高算法复杂度加强对通信数据保护，虽然可以在一定程度保证数据的“安全“
但是会带来Runtime的过高消耗
如果算法复杂度不高，数据保护机制就不强，反之如果算法复杂度足够高，虽然可以保证数据保护机制，但是也必然带来过高Runtime消耗，因此在传统数据保护机制所使用的算法都相对简单
4.CRC/Checksum 算法（参数）在整个研发，生产过程中无严格的保护机制，
容易因为外泄造成安全机制事故。
使用SecOC的好处

数据完整性的保护机制没有或者很弱
无法保证数据来自一个合法的数据源头

SecOC 一般需要使用CMAC (AES-128), 从算法的复杂程度来看，
已经满足对于数据完整性的保护机制的要求
用于生成CMAC的KEY 和ECU 存在绑定关系，且KEY 以密文形式存在
3.如果通过提高算法复杂度加强对通信数据保护，虽然可以在一定程度保证数据的“安全“，
但是会带来Runtime的过高消耗
SecOC 一般需要结合HSM 使用，因此在满足高复杂度算法要求的同时对于RT的消耗也不会增加过多
4.CRC/Checksum 算法（参数）在整个研发，生产过程中无严格的保护机制，
容易因为外泄造成安全机制事故。
对于加密所使用的KEY ，以密文的形式存储在ECU内部一个受到保护的Memory Section中(无法读取)，并且在整个研发，生产过程中KEY始终以密文形式呈现，同时KEY 的内容需要和ECU ID 严格绑定。

SecOC加密原理基于对称机密算法生成CMAC 授权码，授权码随着报文一起发送，通过验证CMAC是否正确来决定数据是否被篡改

AUTOSAR|AUTOSAR SecOC Introduction -- Part 1

文章图片

Secured I -PDU Construction 就是我们通过COMMUNICATION BUS 传输给的ECU 的一个完整的PDU
其包括Secured I -PDU Header/ Authentic I-PDU/Freshness Value/ Authenticator

文章图片

Secured I -PDU Header 可选。用于标识Authentic I-PDU的长度，对于动态长度的Authentic I-PDU 需要使用到此Header，同时Secured I -PDU Header可以用单独的报文发送也可以随着整体Secured I-PDU一起发送
Authentic I-PDU 受保护的Data
Freshness Value(Partial)
虽然是可选的，但是因为CMAC 授权码是基于对称加密算法而产生，那么也就意味着对于相同内容的Secured I-PDU,所产生的CMAC 也是一致的，因此对于“攻击者“来说即使不知道密钥（KEY）的情况下，只要模拟发送这个固定内容的Secured I-PDU 也一样可以起到”攻击“的效果，因此我们需要尽可能的让每一帧报文的CMAC 都不一样，进而推理出需要保证每一帧报文对应的Secured I-PDU 都不一样，根据Secured I-PDU 结构，只有Freshness Value是可能动态变化的。
由于Secured I-PDU Layout 可能不能装下全部的的Freshness Value ，因此可以通过SecOCFreshnessValueTxLength设置包含在Secured I-PDU中Freshness Value的长度

文章图片

因此在AUTOSAR SecOC Spec中针对Freshness Value 有三种推荐处理方式，在AUTOSAR 架构设计中由于
Liner Freshness Value
Sender/Receiver 可维护一个Liner Freshness Value
如果Freshness Value 的长度可以完全包含在Secured I-PDU 中，则对于接收端只需要基于收到的数据进行验证
如果Freshness Value的部分内容（least significant bits）被包含在Secured I-PDU中，那么接收端则需要将收到的Freshness Value和Receiver Local 存储的Freshness Value（least significant bits）进行比较，
如果大于，则Freshness Value =https://www.it610.com/article/Receiver Local Freshness Value（Mostsignificant bits）+| Received Freshness Value（
如果小于，则Freshness Value =https://www.it610.com/article/Receiver Local Freshness Value（Mostsignificant bits）+ 1 |Received Freshness Value (简单理解为就是“扣圈“了，因此高位需要+1)

文章图片

这种方式有个最致命的缺点：

Freshness Value 需要足够大，如果过短通过穷举法可以模拟出所有情况
当Sender /Receiver 所用于比较的Freshness Value 存在较大差距时，可能导致长时间无法校验成功，而对于Freshness Value 存在较大差距这种情况还是比较容易出现的情况，比如Receiver ECU 突然意外离线，Sender/Receiver ECU 意外掉电导致Freshness Value 无法存入NVM

Timestamp Freshness Value
对于Sender / Receiver 使用时间戳作用Freshness Value, 整个逻辑和Liner Freshness Value 类似，但是在一定程度上解决了因为Freshness Value存在较大差异导致长时间无法校验成功的问题，但是也引入2个新问题，如下

Sender / Receiver 的timestamp需要具有同步机制
由于数据从Sender 到Receiver 需要一定时间，因此对于Receiver Side 需要指定一个合理的timestamp 容忍度

Master / Slave Freshness Value
目前最合理的一种方案， JASPER FVM 就是基于此方案进化而来，详细内容见JASPER FVM 介绍

Authenticator(CMAC) (Partial) 【AUTOSAR|AUTOSAR SecOC Introduction -- Part 1】基于AES-128s生成的授权码：简单用公式可以理解为
CMAC=Encrypt(Data,Key)
Data = https://www.it610.com/article/Data Identifier | Authentic I-PDU | Complete Freshness Value
由于Secured I-PDU Layout 可能不能装下全部的CMAC ，因此可以通过SecOCAuthInfoTxLength设置包含在Secured I-PDU中CMAC的长度