文章目录
- 0前言
- [1 什么是SecOC](#1 什么是SecOC)
- [2. 术语](#2. 术语)
- [3 规范描述](#3 规范描述)
-
- [3.1 Secured I-PDU结构](#3.1 Secured I-PDU结构)
- [3.2 认证数据范围](#3.2 认证数据范围)
- [3.3 Freshness Values新鲜度值](#3.3 Freshness Values新鲜度值)
- [3.4 发送端认证流程](#3.4 发送端认证流程)
- [3.5 接收端校验流程](#3.5 接收端校验流程)
- 4.参考文献
0前言
- SecOC Freshness Value 和 MAC（Authenticator）为什么要截断？
- Secoc 是否只能应用于CAN通信，是否可以应用于以太网呢
- 为什么实际应用场景中，都不约而同采用了对称算法，是否可以采用非对称算法呢
- 新鲜度值定义的这么复杂，是否可以采用时间戳的方式呢
刚开始接触SecOC会有很多困惑，先要解决这些困惑，我们不得不追根溯源。想搞懂这些问题，我们需要去阅读以下文档
- AUTOSAR_SRS_SecureOnboardCommunication（需求文档）
- AUTOSAR_SWS_SecureOnboardCommunication（规范文档）
其中规范文档为理解SecOC的核心文档。以上所关心的话题，均能在文档中直接或者间接找到答案。
1 什么是SecOC
SecOC 的全称是AUTOSAR Secure Onboard Communication。
顾名思义，安全车载通信协议。
SecOC解决的是消息真实性与完整性问题，不能解决保密性。
CAN 协议在设计之初目的是为了高效，并未考虑网络安全。因此对于CAN通信来说，SecOC作为补充协议无疑很大程度上补齐了这个短板。
对于以太网来说，由于车载以太网的应用是在2015年之后大规模进行应用，相当大一部分协议直接沿用了互联网的协议，互联网协议天然已经考虑了网络安全，因此在车载上secoc应用的场景相对较少。
2. 术语
由于SecOC规范中有很多专用名词，本文为了尽量减少关键信息翻译所引起的信息缺失或者歧义，会使用规范中的原图文+解释说明进行阐述分析。
| Term（术语） | Description（描述） | 说明 |
|---|---|---|
| Authentic I-PDU | An arbitrary AUTOSAR I-PDU the content of which is secured during network transmission by means of the Secured I-PDU. The secured content comprises the complete I-PDU or a part of the I-PDU. | 指需要被SecOC保护的原始通信数据单元。可以是整个I-PDU或I-PDU的一部分内容被安全保护。它是安全保护的"对象"。 |
| Authentication | A service related to identification. Applies to both entities and information itself. Subdivided into two major classes: entity authentication and data origin authentication. Data origin authentication implicitly provides data integrity. | 认证服务涵盖两个维度：实体认证 （验证通信方身份）和数据源认证（验证数据来源及完整性）。数据源认证隐含了数据完整性保证。 |
| Authentication Information | Consists of a Freshness Value (or a part thereof) and an Authenticator (or a part thereof). These are additional pieces of information added by SecOC to realize the Secured I-PDU. | SecOC在原始I-PDU上附加的安全数据，由两部分组成：新鲜值（FV） 和 认证器（MAC/签名）。用于构建最终的Secured I-PDU。 |
| Authenticator | Data used to provide message authentication. MAC (Message Authentication Code) for symmetric approaches; Signature/Digital Signature for asymmetric approaches. | 用于实现消息认证的具体密码学数据。对称方案使用 MAC （消息认证码），密钥短、效率高；非对称方案使用 数字签名，有不同的安全属性和约束。 |
| Data Integrity | The property whereby data has not been altered in an unauthorized manner since creation, transmission, or storage. Detects data manipulation including insertion, deletion, and substitution. | 保证数据自创建/传输/存储以来未被未授权方篡改。能检测插入、删除、替换等篡改行为。是安全通信的基本保障之一。 |
| Data Origin Authentication | A type of authentication whereby a party is corroborated as the (original) source of specified data created at some time in the past. By definition, includes data integrity. | 验证某一方确实是特定数据的（原始）来源。按定义必然包含数据完整性，因为如果数据被修改，来源也就变了。 |
| Distinction Unilateral / Bilateral Authentication | Unilateral : one side proves identity, the requesting side is not authenticated. Bilateral: both parties authenticate each other, achievable in three messages (more efficient than four with two unilateral messages). | 单向认证 ：仅一方证明身份（如ECU→网关）；双向认证：双方互相验证身份，仅需3条消息即可完成，比两次单向认证（4条消息）更高效。车载通信中多为单向认证。 |
| Entity Authentication | The process whereby one party is assured of the identity of a second party and that the second has actually participated (is active). Proves presence and operational readiness of a communication endpoint. Prevents record-and-replay attacks. | 确认通信端点的身份、存在性和活跃性 。通常通过证明持有密钥和知道秘密来实现。可防止重放攻击。由接收方触发，发送方提供证明。 |
| Message Authentication | A term used analogously with data origin authentication. Provides data origin authentication with respect to the original message source and data integrity, but no uniqueness and timeliness guarantees. | 等同于数据源认证，提供数据来源验证和完整性保证，但不保证唯一性和时效性。即无法区分消息是否是重放的旧消息。 |
| Secured I-PDU | An AUTOSAR I-PDU that contains Payload of an Authentic I-PDU supplemented by additional Authentication Information. | 最终在网络上传输的安全保护数据单元。结构为：Authentic I-PDU 载荷 + Authentication Information（FV + Authenticator）。 |
| Transaction Authentication | Message authentication augmented to additionally provide uniqueness and timeliness guarantees on data, thus preventing undetectable message replay. | 在消息认证基础上增加了唯一性和时效性 保证，能够防止不可检测的消息重放攻击 。SecOC通过引入Freshness Value（新鲜值） 来实现事务认证，这是SecOC的核心安全目标。 |
3 规范描述
一句话总结 ：SecOC 的核心安全方案是------发送端用 MAC + 新鲜度值"签名"消息，接收端用相同的新鲜度值验证 MAC，从而实现数据真实性 + 防重放 的双重保护。
| 维度 | 要点 |
|---|---|
| 核心目的 | 确保车辆通信中敏感数据的真实性 （来自正确的 ECU）和完整性（值未被篡改） |
| 认证方式 | 主要描述对称方法（MAC），同时保留非对称方法（数字签名）的适配接口 |
| 发送端流程 | Authentic I-PDU + 新鲜度值 → 生成 MAC → 组装为 Secured I-PDU → 交给 PduR 发送 |
| 接收端流程 | 收到 Secured I-PDU → 提取 MAC → 用相同新鲜度值重新计算 MAC → 比对验证 |
| 新鲜度机制 | 由外部 Freshness Manager 管理，无论是否在报文中传输，FV 都参与 MAC 计算 |
| 关键约束 | ① 收发双方都必须实现 SecOC ② 接收端必须知道发送端使用的 FV ③ 接收到的 Secured I-PDU 必须与发送端发出的一致 |
3.1 Secured I-PDU结构
一句话总结 ：Secured I-PDU 是在原始 Authentic I-PDU 基础上附加可选 Header + 可选新鲜度值 + 可截断 MAC 的封装结构，MAC 由密钥、数据标识符、原始数据和完整新鲜度值联合计算，所有字段大端编码、长度可按 PDU 粒度独立配置。
| 维度 | 要点 |
|---|---|
| Authentic I-PDU | 需要被保护的原始数据 PDU，防篡改和防重放 |
| Secured I-PDU | = Header(可选) + Authentic I-PDU + FV(可选) + MAC(可截断) |
| MAC 生成要素 | 密钥 + Data Identifier + Authentic Payload + Complete FV |
| 截断规则 | ① MAC 保留最高有效位 （MSB） ② FV 保留最低有效位 （LSB） ③ 每个 PDU 可独立配置截断长度 |
| Header 作用 | 指示 Authentic I-PDU 的长度（字节数），支持动态长度 PDU |
| 字节序 | 所有 SecOC 传输数据统一使用大端序（Big Endian） |
| 安全建议 | 密钥 ≥ 128 位，MAC ≥ 64 位（NIST 标准） |
3.2 认证数据范围
一句话总结 ：MAC 的输入数据是 DataId + Authentic I-PDU 载荷 + 完整新鲜度值 三者的严格拼接，其中 DataId 和完整 FV 虽然可能不在网络上传输，但都参与认证计算，确保了即使报文被截断传输，验证端也能用相同规则重新计算 MAC 进行校验。
-
Data covered by Authenticator
SecOCDataId 不传输，是因为它不是业务数据，而是认证上下文。双方通过 ECU 配置预共享 Data ID，用它参与 MAC 计算，从而节省 CAN 带宽，并防止报文跨 PDU 重放攻击。DataToAuthenticator = Data Identifier | secured part of the Authentic I-PDU |
Complete Freshness Value
| 要素 | 说明 |
|---|---|
| Data Identifier | 本地配置的 2 字节标识符（SecOCDataId），不通过网络传输，参与 MAC 计算和 CSM 密钥选择 |
| Authentic I-PDU data | 需要被保护的原始报文数据（或其被保护的部分） |
| Complete Freshness Value | 用于 MAC 计算的是完整的新鲜度值，而非截断后放入报文的值 |
| 拼接顺序 | DataId → Payload → FV，严格按此顺序拼接 |
- 不参与认证的数据
| 排除项 | 原因 |
|---|---|
| Secured I-PDU Header | Header 在 MAC 计算完成后才添加到报文中 |
| 截断后的 FV | 报文传输的只是 FV 的最低有效位部分，但 MAC 计算用的是完整 FV |
| MAC 本身 | MAC 是认证算法的输出，不作为输入 |
3.3 Freshness Values新鲜度值
每个 Secured I-PDU 至少配置一个 Freshness Value，它是一个单调递增计数器，用于保证报文的新鲜性（防重放攻击）。
3.4 发送端认证流程
一句话总结 ：TX 认证是严格的 6 步流水线------准备缓冲区 → 拼接认证数据（DataId+Payload+完整FV）→ 调用 CSM 生成 MAC → 按截断规则组装报文 → 递增计数器 → 交给 PduR 发送。
- Step 1: 准备 Secured I-PDU
准备 / 分配缓冲区
在开始认证构建之前，SecOC 模块为本次发送分配必要的缓冲区空间，用于存放中间计算结果和最终的 Secured I-PDU。缓冲区大小需能容纳：
- Secured I-PDU Header（可选）
- Authentic I-PDU 有效载荷
- 截断后的 Freshness Value（LSB 部分）
- 截断后的 MAC（MSB 部分）
若此时遇到资源不足（
E_BUSY或QUEUE_FULL），且authBuildCounter < SecOCAuthenticationBuildAttempts，将在下一次 Tx MainFunction 调度周期重试，而非本周期内立即重试。
- Step 2: 构造认证数据
DataId | Payload | Complete FV（大端编码）
按照 SWS_SecOC_00034 的要求，将以下三部分严格拼接为 DataToAuthenticator：
| 字段 | 位宽 | 编码 | 说明 |
|---|---|---|---|
| SecOCDataId | 16 bit | 大端 | 本地配置的标识符，不传输，仅参与 MAC 计算 |
| Payload | 可变 | 原始 | Authentic I-PDU 的被保护有效载荷部分 |
| Complete FV | 可变 | 大端 | 完整的 Freshness Value（非截断值），对齐到 MSB，未使用位填 0 |
Secured I-PDU Header 不参与认证数据构造。 FV 可以是独立计数器，也可以复用 Authentic I-PDU 中已有的字段（如 E2E counter），由
SecOCUseAuthDataFreshness配置决定。
- Step 3: 生成 MAC
调用 CSM 认证算法
将 Step 2 构造好的 DataToAuthenticator 及其长度传递给 CSM（Cryptographic Service Manager）模块（SWS_SecOC_00035）：
- 输入 ：
DataToAuthenticator+ 数据长度 - 算法引用 ：由
SecOCTxAuthServiceConfigRef配置的加密算法（如 AES-128-CMAC） - 输出：完整的 MAC 值
CSM 返回完整的 MAC 后，后续步骤将对其进行截断。
- Step 4: 构造 Secured I-PDU
Header + Payload + FV 截断 + MAC 截断
按照 SWS_SecOC_00036/00037 的规则，组装最终的 Secured I-PDU：
┌─────────────────────────────────────────────────────┐
│ Header (可选) │ Payload │ FV (LSB) │ MAC (MSB) │
└─────────────────────────────────────────────────────┘- Header：可选的 Secured I-PDU 头部，不参与 MAC 计算
- Payload：Authentic I-PDU 被保护部分的完整数据
- FV 截断 ：取完整 FV 的 LSB（最低有效位） 部分，长度为
SecOCFreshnessValueTruncLength配置值 - MAC 截断 ：取完整 MAC 的 MSB（最高有效位） 部分，长度为
SecOCAuthInfoTruncLength配置值
截断规则的核心逻辑：FV 截断取 LSB（因为 MSB 变化频率低，接收端可本地推导）；MAC 截断取 MSB（高位包含更强的认证信息）。
- Step 5: 递增 FV 计数器
递增新鲜度计数器
在 Step 3 的 MAC 计算完成之后才递增 FV 计数器，这是关键的时序要求：
- 确保本次发送使用的 FV 与参与 MAC 计算的 FV 完全一致
- 若在 MAC 计算之前递增，接收端将无法验证（FV 不匹配导致 MAC 验证失败）
- 递增操作通过 Freshness Manager 的接口完成
- Step 6: 广播 Secured I-PDU
交给 PduR 发送
将 Step 4 构造完成的 Secured I-PDU 通过 PduR（PDU Router）向下层路由：
- PduR 根据配置将报文路由到对应的总线接口（CAN / Ethernet / LIN 等）
- 最终由底层通信模块将报文发送到总线上
- 接收端 ECU 收到后，将执行对应的 RX 验证流程（SWS 7.1.3）
3.5 接收端校验流程
一句话总结：RX 验证是 TX 认证的镜像过程------先解析出载荷、FV 和 MAC，用本地获取的新鲜度值重新构造认证数据并调用 CSM 验证 MAC，验证通过则剥离安全封装上传数据，同时支持灵活的重试和状态上报配置
- Step 1: 解析 Secured I-PDU
Secured I-PDU → Header + Payload + FV + MAC
接收端从 PduR 收到 Secured I-PDU 后，按照配置将其拆解为四个部分：
- Header（可选）：Secured I-PDU 头部，不参与后续 MAC 验证
- Payload：Authentic I-PDU 的被保护有效载荷部分
- FV：发送端截断后传输的新鲜度值 LSB 部分
- MAC：发送端截断后传输的认证器 MSB 部分
若配置为 PDU Collection 模式，还需通过 Message Linker 将 Authentic I-PDU 与 Cryptographic I-PDU 进行匹配关联。
- Step 2: 获取新鲜度值
从 Freshness Manager 获取 RX 新鲜度
通过 Freshness Manager 接口获取用于验证的完整新鲜度值（FreshnessVerifyValue）。具体方式取决于配置：
- 独立 FV 接口 ：调用
FreshnessManager_RxAuth获取 RX 端维护的新鲜度计数器值 - 复用已有新鲜度 （
SecOCUseAuthDataFreshness = TRUE）：从 Authentic I-PDU 中已有的计数器字段（如 E2E counter）提取
获取到的完整 FV 将与 Step 1 中解析出的截断 LSB 进行拼接还原。
- Step 3: 构造验证数据
DataId | Payload | FreshnessVerifyValue
按照与发送端相同的规则拼接 DataToAuthenticator：
| 字段 | 说明 |
|---|---|
| SecOCDataId | 本地配置的 16 位标识符（大端编码），不传输，仅用于计算 |
| Payload | Authentic I-PDU 的被保护部分 |
| FreshnessVerifyValue | Step 2 获取的完整新鲜度值（大端编码） |
Secured I-PDU Header 不参与认证数据构造，这与发送端一致。
- Step 4: 验证 MAC
调用 Csm_MacVerify
将构造好的验证数据提交给 CSM 模块进行 MAC 验证：
- DataToAuthenticator：Step 3 拼接的数据及长度
- Authenticator：Step 1 解析出的截断 MAC（MSB 部分）
- 截断长度 ：由
SecOCAuthInfoTruncLength配置 - 算法引用 ：使用
SecOCRxAuthServiceConfigRef指定的加密算法
CSM 返回验证结果：E_OK（成功）或错误码（失败）。
- Step 5: 报告状态
VERIFICATION_SUCCESS / VERIFICATION_FAILURE
根据 Step 4 的验证结果，向上层报告状态。报告模式由配置决定：
| 传播模式 | 说明 |
|---|---|
| BOTH | 成功和失败均上报 |
| FAILURE_ONLY | 仅上报失败 |
| NONE | 不上报中间状态 |
验证成功时，还需向 Freshness Manager 发送确认，更新 RX 新鲜度计数器。
- Step 6: 上传 Authentic I-PDU
Authentic I-PDU → PduR → 上层
仅在验证成功时执行。将原始的 Authentic I-PDU（不含 FV 和 MAC 部分）通过 PduR 路由至上层应用模块。验证失败的报文不会被上传。
- 重试机制（验证失败分支）
当 Step 4 验证失败时，进入重试流程：
- 使用
authVerifyCounter计数器跟踪重试次数 - 每次重试从 Step 2 重新开始（重新获取新鲜度值），因为 Freshness Manager 可能已更新
- 重试次数上限由
SecOCAuthenticationVerifyAttempts配置 - 重试耗尽后 ：丢弃该报文，报告最终失败状态（
VERIFICATION_FAILED）
重试不是在本周期内立即执行，而是在下一次 Rx MainFunction 调度周期中进行，给 Freshness Manager 更新时间。
4.参考文献
- AUTOSAR_SRS_SecureOnboardCommunication
- AUTOSAR_SWS_SecureOnboardCommunication