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 便无法判定接收到的信号指令是否来自一个真实的来源。
通过增强算法的计算复杂度来加强通信数据的安全性，在一定程度上保障了通信数据的安全性
但是会带来Runtime的过高消耗
当算法的复杂度较低时，数据保护机制的强度不足；相反地，在算法具有较高复杂度的情况下尽管能够确保数据保护机制的有效性 但也必然会导致过高的Runtime消耗 因此 在传统数据保护机制中使用的算法通常较为简单
4.CRC/Checksum 算法（参数）在整个研发，生产过程中无严格的保护机制，
容易因为外泄造成安全机制事故。
使用SecOC的好处
- 该机制对于数据完整性缺乏有效的保护措施。
- 数据来源的合法性存在较大疑虑。
SecOC 一般需要使用CMAC (AES-128), 从算法的复杂程度来看，
已经满足对于数据完整性的保护机制的要求
用于生成CMAC的KEY 和ECU 存在绑定关系，且KEY 以密文形式存在
3.如果经过对算法复杂度的增强以强化通信数据保护，则尽管可以在一定程度上保障数据的信息安全，并且能够实现这一目标的具体方法通常具有较高的计算复杂度需求
但是会带来Runtime的过高消耗
通常建议采用HSM进行搭配，在确保支持高复杂度算法需求的同时不会导致额外计算负担显著增加。
4.CRC/Checksum 算法（参数）在整个研发，生产过程中无严格的保护机制，
__容易因为外泄造成安全机制事故。 __
该加密机制采用密文形式将KEY存储于ECU内部的一个受保护的记忆单元中（不可读）。并且，在研发及生产全过程中(KEY)始终保持为密文形式。此外，在整个系统设计中(KEY)的内容必须与(ECU ID)严格对应。
SecOC加密原理
基于对称密钥算法生成CMAC授权码，在发送过程中伴随传输这些代码，并根据CMAC的有效性判断数据完整性。
Secured I -PDU Construction
就是我们通过COMMUNICATION BUS 传输给的ECU 的一个完整的PDU
其包含加密的I-PDU字段/认证的I-PDU/新鲜度值/认证者
Secured I -PDU Header
可选字段用于标识Authentic I-PDU的长度参数，在处理动态长度的Authentic I-PDU时必须包含此Header字段。而对于 Secured I-PDU Header字段而言，则既可以独立以单独的形式传输一份报文进行数据传输操作，并非必须依赖其他信息；也可以作为整体数据的一部分一同完成整个传输过程。
Authentic I-PDU
受保护的Data
Freshness Value(Partial)
虽然具有可选性，在CMAC授权码生成机制中基于对称加密算法的特点下
由于Secured I-PDU Layout无法容纳全部的Freshness Values ，因此可通过设置SecOCFreshnessValueTxLength 来确定其在**Secured I-PDU中 Freshness Value 的长度。
因此，在AUTOSAR SecOC规范中就针对"Freshness Value"这一指标提出了三种推荐处理方案；在AUTOSAR体系架构设计过程中则基于系统的实际需求进行了相应的优化调整
Liner Freshness Value
Sender/Receiver 可维护一个Liner Freshness Value
如果Freshness Value能够完整嵌入到Secured I-PDU中，则仅需接收方基于接收到的数据完成验证流程。
如果其中一部分内容（least significant bits）被包含于Secured I-PDU中，则接收端就需要对收到的Freshness Value与Receiver Local所存储的Freshness Value（least significant bits）进行比较。
若大于，则 freshness value = receiver local freshness value（最高有效位）+ | received freshness value（
如果某个条件满足，则Freshness Value被定义为：Receiver\ Local\ Freshness\ Value加上Most\ significant\ bits对应的值再加一；并可视为扣减一圈后的情况，在此情况下需相应地对高位数值进行调整以确保其有效性
这种方式有个最致命的缺点：
- 为了确保数据的有效性Freshness Value必须达到一定的规模。
- 当Comparative Freshness Values在Sender和Receiver之间出现显著差异时，
会导致持续无法完成校验过程，
而这种显著差异的情况并非罕见，
例如当Receiver ECU突然失去连接，
或者Sender/Receiver ECU因供电故障导致Freshness Values无法存储至NVM时。
Timestamp Freshness Value
对于Sender/Receiver在通信中采用时间戳作用来实现Freshness Value, 其整体流程与Linear Freshness Value类似, 但在一定程度上缓解了由于其显著差异可能导致长时间验证失败的问题, 然而，在此过程中带来了两个新的挑战, 具体来说如下
- Sender和Receiver必须确保其timestamp具有一致性。
- 因为数据传输从Sender到Receiver必然存在延迟，在接收端（Receiver Side）必须设定一个适当的 timestamp 容差值。
Master / Slave Freshness Value
当前最优的解决方案即为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中的长度。
Data Identifier
也是SecOCDataId 每一个Secured I-PDU 都会对应唯一的一个DataID