AUTOSAR SecOC Introduction -- Part 1
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是否正确来决定数据是否被篡改
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 =Receiver Local Freshness Value（Most significant bits）+| Received Freshness Value（
如果小于，则Freshness Value =Receiver Local Freshness Value（Most significant 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)
基于AES-128s生成的授权码：简单用公式可以理解为
CMAC=Encrypt(Data,Key)
Data = Data Identifier | Authentic I-PDU | Complete Freshness Value
由于Secured I-PDU Layout 可能不能装下全部的CMAC ，因此可以通过SecOCAuthInfoTxLength设置包含在Secured I-PDU中CMAC的长度
Data Identifier
也是SecOCDataId 每一个Secured I-PDU 都会对应唯一的一个DataID