架構評審上的高頻問題：「我們已經有 E2E 了，為什麼還要 SecOC？」——因為它們防的是兩種完全不同的敵人。E2E 防的是隨機故障（位元翻轉、訊息遺失、序列錯亂），SecOC 防的是蓄意攻擊（偽造、竄改、重放）。一個屬於功能安全的世界，一個屬於資安的世界。
一張表看懂分工
| E2E Protection | SecOC | |
|---|---|---|
| 防的敵人 | 隨機故障（硬體、干擾、軟體缺陷） | 蓄意攻擊（偽造、竄改、重放） |
| 所屬領域 | 功能安全（ISO 26262 的通訊失效模式） | 資安（ISO/SAE 21434、UN R155） |
| 核心手段 | CRC ＋ 計數器（Counter）＋ 資料 ID | MAC（訊息鑑別碼）＋ 新鮮度值 |
| 金鑰 | 不需要 | 需要——對稱金鑰的分發與保管 |
| 攻擊者能不能繞過 | 能（CRC 演算法公開，攻擊者可以算出合法 CRC） | 不能（沒有金鑰算不出合法 MAC） |
| 保護範圍 | 發送端應用到接收端應用（端到端） | 匯流排上的 PDU |
關鍵洞察：E2E 擋不住攻擊者。 CRC 與 Counter 的演算法是公開的，攻擊者偽造訊息時把 CRC 一起算對就好。反過來，SecOC 也不完全取代 E2E——MAC 驗證確認「這是真的發送者發的」，但發送端應用層到通訊層之間的軟體缺陷（E2E 的守備範圍從 RTE 就開始）不在它的視野裡。兩者是疊加關係，不是二選一；再加上 IP 網段的 TLS，就是「通道—訊息—應用」三層防護的完整圖像。
E2E 的機制：三個欄位堵三種失效
E2E 在受保護的資料上附加：
- CRC：偵測資料損毀（位元翻轉）
- Counter：每發一次加一——接收端據此偵測遺失（跳號）、重複（同號）、亂序（倒退）
- Data ID：參與 CRC 計算的隱含識別——偵測錯位投遞（收到別人的訊息卻當成自己的）
接收端不只驗單筆，還維護狀態機：連續幾筆正常才算通訊健康、失效累積到門檻觸發降級。測試的重點因此不在「CRC 算得對不對」，而在狀態機——注入跳號、重複、延遲的序列，驗證應用層的失效反應（降級、保持最後有效值、進安全狀態）是否符合安全概念的設計。AUTOSAR 定義了多個 E2E Profile，差異在 CRC 長度、Counter 位元數與欄位佈局——選 Profile 實際上是在選「失效偵測能力 × 附加負載」的平衡點。
SecOC 的機制：MAC 與新鮮度的雙人舞
SecOC 對受保護的 PDU 附加兩樣東西：
- MAC（訊息鑑別碼）：以對稱金鑰對「資料＋新鮮度值」計算的密碼學標籤。沒有金鑰，偽造不出合法 MAC——這是真實性與完整性的來源
- 新鮮度值（Freshness Value）：單調遞增的計數器或時戳，讓每一筆訊息的 MAC 都不同——這是防重放的關鍵。沒有它，攻擊者錄下一筆合法訊息原封重播，MAC 依然驗得過
工程上的兩個經典難題都出在「塞不下」：
- MAC 截斷：完整 MAC 放不進傳統 CAN 的酬載，實務上只傳截斷後的一段——安全強度與頻寬的取捨要有依據（這也是 SecOC 與 CAN FD 的 64 位元組酬載特別合拍的原因，見 CAN FD 差在哪）
- 新鮮度同步：接收端要知道「現在的新鮮度值該是多少」才能驗 MAC。斷電重啟、訊息遺失後的重新同步機制（新鮮度管理器、截斷傳輸＋本地重建）是 SecOC 導入時最花工程時間的一塊，也是互通性問題的高發區
金鑰管理則是整套機制的地基：金鑰怎麼注入（產線）、存哪裡（HSM，見 Secure Boot 技術）、怎麼輪替——金鑰洩漏，SecOC 就是擺設。
測試視角：兩套機制、兩張測試清單
| E2E 要測 | SecOC 要測 |
|---|---|
| 跳號／重複／亂序注入下的狀態機行為 | 錯誤 MAC 的拒收與計數 |
| 失效門檻與降級路徑 | 重放攻擊（錄製重播）被擋下 |
| Profile 組態與兩端一致性 | 新鮮度失步後的重同步 |
| 高負載下的偵測延遲 | 金鑰錯誤／未注入時的行為 |
| 截斷 MAC 長度的邊界驗證 |
兩張清單都需要「能精準操縱訊息」的測試環境——改 Counter、改 MAC、重放指定訊框，CANoe 這類工具搭配資安測試套件就是做這件事。對供應商來說，這些證據直接對應 ISO/SAE 21434 的驗證要求（上游的分析怎麼做，見 TARA 怎麼做）。
下一步
從 SecOC 導入、新鮮度策略到攻防測試，歐特莫夫（Vector Informatik 合作夥伴）協助把通訊防護做成拿得出手的合規證據。
- 📄 解決方案：車用資安 ISO/SAE 21434、AUTOSAR 開發
- 📬 預約一次現況盤點