點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

"SecOC啊，我知道，就是給報文加個密嘛。"

你要是敢在面試或者項目評審會上這么回答，對面的人大概率會愣一下，然后追問你："那你說說，它加的什么密？密鑰存在哪？報文里哪幾個字節是密文？新鮮度值怎么同步？"

三個問題，一個都答不上來，場面直接尷尬。

說實話，這個場景我見過太多次了。SecOC（Secure On-board Communication，車內安全通信）是AUTOSAR里專門做通信安全的標準模塊，這幾年幾乎成了新項目的標配。網關、域控、智駕、底盤，只要帶安全等級的通信，大概率都要上SecOC。但很多人對它的理解就停留在"加了密"三個字上。真要上手配置，連新鮮度值（Freshness Value）是什么都說不清楚。

更扎心的是，SecOC恰恰不做加密。它不保護報文的機密性，防的是三件事：篡改、偽裝、重放。而防重放的核心，就是新鮮度值。你連新鮮度值都沒搞懂，SecOC這扇門你就還沒進去。

這篇文章不講廢話，從原理到配置到調試，一條線捋下來：SecOC到底在保護什么、新鮮度值怎么工作、MAC怎么算、工具里怎么配、項目里最容易踩哪些坑。全是干活的料，你看完就能拿去項目上對號入座。

1.1 一句話說清SecOC

SecOC是AUTOSAR標準里的一個BSW模塊。它掛在PDU Router和各個通信接口（CanIf、FrIf、EthIf）之間，給通過它的PDU做兩件事：加認證信息（MAC），加新鮮度信息（Freshness）。

它保護的鏈路是總線這一段，CAN、CAN FD、FlexRay、以太網都能用。報文從發送方的SecOC出來，經過總線，到接收方的SecOC，中間任何人在總線上篡改、偽造、重放，接收方都能發現并丟棄。

記住

記住一句關鍵的話：SecOC是逐跳（hop-by-hop）的，它保護的是ECU之間某一段總線的通信。這和E2E那種端到端的保護是兩碼事，后面Part 04專門講它倆怎么配合。

1.2 SecOC不加密

這是最容易搞混的一點。SecOC不加密，它不做機密性保護。

什么叫機密性？就是別人偷看你的數據看不懂。SecOC不干這個，你的報文內容在總線上還是明文，誰拿個CAN工具一抓，報文內容一目了然。

SecOC干的是另外三件事：

• 完整性：

  報文內容有沒有被篡改，改一個bit都能發現

• 真實性：

  報文是不是真的來自聲稱的那個發送方，防止偽造

• 新鮮性：

  報文是不是新鮮的，防止重放

這三件事靠一個東西實現：消息認證碼MAC（Message Authentication Code）。接收方用共享密鑰重新算一遍MAC，對不上就丟。密鑰只有發送方和接收方有，攻擊者沒有密鑰，算不出合法的MAC，偽造的報文過不了關。

要是有人問"為什么不上加密"，答案是：車載報文大多是控制類數據，對實時性和帶寬極敏感，全量加密計算開銷大、延遲高，而且很多場景根本不關心被竊聽，只關心別被篡改和偽造。所以SecOC選了"認證優先"這條路。真正要防竊聽的場景，那是另一套體系，跟SecOC不是一個層級的事。

1.3 SecOC在協議棧里的位置

報文從應用層到總線的路徑大致是這樣：

圖1 · SecOC夾在PduR與CanIf之間，給經過的PDU加上認證與新鮮度信息

SecOC夾在PduR和CanIf之間。COM把信號組裝成PDU，PduR負責路由，路由到SecOC的PDU會被SecOC"包裝"一遍——加上新鮮度值和MAC，變成一個Secured PDU，再往下交給CanIf發出去。

接收方向反過來：

注意

不是所有PDU都要過SecOC。配置里每個PDU有安全等級，安全的走SecOC，普通的直接透傳。混合使用很常見，別以為上了SecOC整條總線都被保護了，只保護你配了的那部分。

1.4 Secured PDU長什么樣

一個被保護的報文，在總線上長這樣：

Secured PDU = Data + Freshness（截斷） + MAC（截斷），新鮮度和MAC都追加在原始數據的屁股后面。

舉個例子，一個8字節的原始PDU：

• Data ID：0x1234（這個不進報文，收發雙方各自配好）

• 新鮮度值：0x00000042，截斷取低16位 → 報文里放0x0042，2個字節

• MAC：AES-128-CMAC算出來128位，截斷取低24位 → 3個字節

那總線上實際發的是：8字節數據 + 2字節新鮮度 + 3字節MAC = 13字節。經典CAN一幀8字節放不下，就得換CAN FD或者壓縮數據長度。這就是為什么很多上SecOC的項目強制上CAN FD——不是炫技，是DLC真不夠用。

你抓包的時候看到一幀報文比DBC里定義的多了幾個字節，末尾多出來的就是新鮮度和MAC。這個特征后面調試時有大用。

2.1 為什么非要新鮮度值

先想一個問題：有了MAC，是不是就安全了？

不是。MAC防篡改、防偽造，但防不了重放。

重放攻擊是這樣的：攻擊者不需要破解任何東西，他就拿個CAN工具在總線上錄一段合法的報文——比如一條"解鎖車門"的指令。這段報文是合法的，MAC是對的，因為就是真ECU發的。然后等車主離開，攻擊者把這段錄音原樣重發一遍。接收方收到一看，MAC正確，數據合法，執行解鎖。

一次重放，整個認證體系被繞過。因為MAC只能證明"這段數據是用密鑰算出來的"，證明不了"這段數據是現在發出來的"。你需要的，是讓接收方判斷"這條報文是不是過期的"，這就是新鮮度值的活。

新鮮度值（Freshness Value，FV）就是給每條報文蓋的一個"序號戳"。發送方每次發報文，新鮮度值往前進；接收方收到報文，先檢查新鮮度值是不是新的。舊的、重復的、倒退的，直接丟。重放的報文攜帶的是老的新鮮度值，一查就露餡。

圖2 · 攻擊者重放的舊報文攜帶過期FV，接收方直接拒絕

2.2 新鮮度值由什么構成

AUTOSAR里新鮮度值本身是一個多字節的值，常見的構成方式有三種：

第一種：計數器（Counter）。發送方維護一個單調遞增的計數器，每發一條報文加一。接收方也維護一個計數器，收到合法報文后跟進。兩邊計數器對上，重放報文拿的是舊計數值，對不上，丟。這是最常用、最便宜的方式，不依賴任何外部時鐘，純本地邏輯。缺點是長時間運行計數器會溢出，需要設計回繞處理，一般配合同步機制在回繞前重置。

第二種：時間戳（Timestamp）。新鮮度值直接取全局時間。要求整車有統一的時間基準，比如以太網上跑gPTP時間同步，所有ECU的時間對齊到微秒級。接收方收到報文，取出時間戳，跟自己的當前時間比，差值在允許窗口內就收，超過窗口就丟。好處是天然抗重放、還能發現報文延遲，壞處是必須依賴時間同步，時間不同步整車直接趴窩。

第三種：混合（Counter + Timestamp）。高位用時間戳、低位用計數器，兼顧兩者的優點。時間同步失效時計數器還能兜底，計數器的溢出問題也被時間戳的高位天然解決。

AUTOSAR把新鮮度值做成了標準化的Profile，叫Freshness Value Profile，一共六種，本質就是上面三種方案的排列組合：純計數器、純時間戳、混合，以及它們各自的"截斷傳輸"版本。配置工具里你選一個Profile，工具就按標準把新鮮度值的位數、構成、同步方式定死，你不需要自己發明輪子。

2.3 Truncation截斷：報文里只放一小段

新鮮度值本身往往很長——32位、64位、甚至128位。全放報文里，DLC扛不住。

所以有了截斷機制（Truncation）：完整的新鮮度值參與MAC計算，但報文里只放它的低若干位，常見8位、16位、24位。接收方怎么恢復完整值？它自己手里也有一份接近同步的完整新鮮度值，把收到的截斷值填進自己那份的低位，高位的差異在容差范圍內就認為對齊了，然后拿恢復出來的完整值算MAC。

打個比方，發送方計數器是0x0000_0042，報文里只發0x0042。接收方本地計數器是0x0000_0040，把收到的0x0042填進低位，恢復成0x0000_0042，跟自己的計數器差2，在容差內，收。如果攻擊者重放一條老的0x0001，接收方恢復成0x0000_0001，比自己的0x0040倒退了一大截，直接丟。

截斷長度是個權衡：截得越短，報文越省，但同步容差窗口越大、安全余量越小；截得越長，越安全，但DLC開銷越大。項目里一般按報文周期和DLC預算來選，后面Part 04講怎么踩坑。

2.4 同步策略：兩邊怎么對上

新鮮度值最大的坑，就是"兩邊對不上"。對不上，所有報文驗簽全掛，整車靜默丟幀。同步策略分兩派：

全局時間同步（Time-based）。前提是整車時間基準統一。以太網鏈路用gPTP同步，CAN鏈路上也有自己的時間同步方案。時間同步好之后，收發雙方拿同一個時間軸，新鮮度值天然對齊，幾乎不需要額外機制。代價是時間同步鏈路本身要維護，同步斷了要能檢測、能降級。

計數器同步（Counter-based）。收發雙方各自維護計數器，靠"收到合法報文就跟進"來隱式同步。正常通信時兩邊天然咬合：發送方發一條，計數值加一，接收方驗過一條，計數值跟進。但ECU重啟、報文丟失、總線靜默，都會讓兩邊錯位。錯位了怎么辦？需要專門的同步機制：要么發方周期性發同步報文，把自己的當前計數值廣播給接收方；要么接收方在連續驗簽失敗后進入"重新同步"流程，主動向發送方請求當前值。

注意

AUTOSAR里負責維護新鮮度值的是SecOC模塊內部的新鮮度值管理器（Freshness Value Manager），它從哪拿值可以配置：獨立的計數器模塊、時間服務、或者干脆由上層軟件喂給它。配置時你要把"誰給新鮮度值、怎么同步、截斷多少位"一次想清楚，這是SecOC配置里最容易出事的地方。

2.5 新鮮度值不同步是什么癥狀

說點實際的。項目里新鮮度值不同步，典型癥狀是：

• 某個ECU喚醒后，它發出的所有安全報文，接收方全部驗簽失敗，錯誤計數器蹭蹭漲

• 整車表現為間歇性丟功能，比如某個控制器一直收不到有效指令，進不了工作狀態

• 抓包看報文是好的，MAC算下來也是對的，但接收方就是丟——這時候十有八九是兩邊新鮮度值錯位了

記住

記住一個排查思路：MAC驗簽失敗分兩種，一種是MAC真錯了（密鑰、數據、算法不一致），一種是新鮮度值不對導致算出來的MAC對不上。先用純數據比對排除密鑰問題，再查新鮮度值同步，別一上來就懷疑密鑰。

3.1 MAC計算的完整流程

MAC不是拿原始數據隨便算的。AUTOSAR定義了標準輸入順序，收發雙方必須嚴格一致，差一個字節順序結果都不一樣。發送方向的計算流程：

1. 拼Auth Data。

   按順序拼：Data ID（16位） + 原始PDU數據 + 新鮮度值（完整值）。

2. 用密鑰對Auth Data算CMAC。

   算法是AES-128-CMAC，算出來一個128位的MAC。

3. 截斷。

   128位MAC太長，按配置截取低若干位（比如低24位、低32位），放進報文。

4. 組幀發出：

   數據 + 截斷新鮮度 + 截斷MAC。

Data ID是每個Secured PDU配置的一個16位標識符，它不進報文，但參與MAC計算。它的作用是把MAC"綁"到具體這條PDU上：防止你把A報文的MAC剪下來貼到B報文上。收發雙方各自配置相同的Data ID，算出來才能對上。

圖3 · MAC計算的四個步驟：拼裝 → CMAC → 截斷 → 組幀

接收方向是同樣的四步，只是順序反過來：

安全細節

這里有個安全細節：比對必須用常數時間比較（constant-time compare），不能用普通的字符串比較，否則攻擊者可以通過時間側信道一點點猜MAC。這是安全審計必查的點，面試能說出來很加分。

3.2 為什么是CMAC而不是普通AES

面試高頻題。答案是：MAC需要的是"單向、防偽造"的認證原語，而AES本身只是加密原語，加密不等于認證

普通AES加密有個著名的坑：CBC模式直接拿最后一個密文塊當MAC，只在固定長度消息下安全，消息長度一變就容易被偽造。CMAC在CBC-MAC基礎上加了子密鑰處理，解決了變長消息的問題，是標準認證算法。

另一個理解角度：SecOC要的是"認證標簽"，不是"密文"。認證標簽可以公開傳輸，攻擊者看到也不怕——他沒有密鑰就算不出合法的標簽。有些流加密模式還能被攻擊者翻轉bit而不被察覺，密文沒有完整性保護，所以加密算法不能直接當認證算法用。

一句話總結

CMAC（AES-128-CMAC）是AUTOSAR里SecOC強制要求支持的算法，別的算法（比如HMAC）也可以配，但默認就是AES-128-CMAC，兼容性最好，硬件加密單元支持也最普遍。

3.3 密鑰從哪來、怎么更新

MAC的安全強度全部押在密鑰上。密鑰泄露，一切白搭。AUTOSAR里密鑰管理有一套完整體系，涉及三個模塊：

• CSM（Crypto Service Manager）：

  對外提供統一的密碼學服務接口，SecOC的MAC計算就是通過CSM做的

• CryIf（Crypto Interface）：

  CSM和底層密碼學驅動之間的路由層

• Crypto Driver：

  真正干活的，可能是軟件算法，也可能是硬件HSM（Hardware Security Module）或芯片內置的加密加速器

密鑰的整個生命周期（生成、安裝、激活、停用、刪除）由KeyM（Key Manager）管理。典型場景是：整車廠把密鑰刷進ECU——可以通過診斷刷寫，也可以通過OTA，密鑰先以"已安裝"狀態存進密鑰槽（Key Slot），再被"激活"使用。

密鑰輪換（Key Update）是量產車必須面對的事：密鑰不能一輩子不換，泄露了要能換，整車下線后密鑰要能更新。輪換的關鍵問題是新舊密鑰的切換時機——發送方切到新密鑰了，接收方還在用舊密鑰，所有報文瞬間驗簽失敗。解決手段有兩個：

方案一：報文里帶Key ID。新版本AUTOSAR支持在Secured PDU里放Key ID字段，接收方看到Key ID就知道該用哪把密鑰。切換是平滑的，兩邊不用精確對齊時間。代價是報文又多了幾個字節。

方案二：靠配置對齊。不加Key ID，靠整車統一協調切換時機，比如下線檢測時統一刷寫、統一激活。省字節，但切換瞬間必須保證所有相關ECU同步完成，任何一臺沒刷上，就是通信故障。

注意

還有一個容易忽略的點：密鑰和密鑰槽的對應關系必須和CSM配置一致。工具里SecOC配置引用的是Csm里的Key ID，配錯了一個引用，代碼能編過，跑起來全軍覆沒。

3.4 MAC截斷長度怎么定

MAC截斷長度（Auth Info長度）是配置里一個不起眼但極其重要的參數，常見值：24位、32位、64位。

截斷越短，攻擊者暴力猜測的成本越低。24位MAC，攻擊者每秒猜幾百萬次，幾個小時就可能撞上正確的值，還要配合重放窗口。32位好一些，但高頻率總線上仍然有風險。安全要求高的系統，比如轉向、制動相關，建議32位起步，條件允許上64位。

但別忘了成本：MAC每長一個字節，DLC就多一個字節，CAN FD 64字節的預算就那么點。項目里經常是"安全工程師要64位，網絡工程師只給留了3個字節"，最后折中成32位。這種決策要留下書面記錄，別拍腦袋。

另外收發雙方的截斷長度必須完全一致，這個不一致的坑我在Part 04細說，是配置錯誤重災區。

4.1 工具里SecOC怎么配

主流的AUTOSAR配置工具就那幾家：Vector的DaVinci、EB的tresos、ETAS的ISOLAR。界面不一樣，配置項的底層邏輯完全一樣，你理解一套就夠。核心配置就五塊：

1、第一塊：SecOC模塊配置。

打開SecOC模塊，里面按"Secured PDU"組織。你要為每一條要保護的PDU建一條Secured PDU配置，指定：

• Secured PDU名字和它對應的原始PDU

• Data ID（16位，收發雙方一致）

• Auth Info長度（就是MAC截斷長度，24/32/64位）

• 新鮮度值相關配置（用哪個Profile、截斷長度、新鮮度值來源）

2、第二塊：新鮮度值配置。

建一個Freshness Value配置，選Profile（計數器型/時間戳型/混合型），定截斷位數，指定新鮮度值的提供者。時間戳型的要接時間服務，計數器型的要指定計數器來源。

3、第三塊：密碼學配置。

在Csm里建好密鑰槽，指定算法AES-128-CMAC、密鑰長度128位、密鑰材料；然后在SecOC配置里把Secured PDU的"Key ID"指到對應密鑰槽。

4、第四塊：PduR路由配置。

這一步很多人漏。原始PDU要走COM → PduR → SecOC → CanIf的路徑，你得在PduR里把路由改道到SecOC，SecOC處理完再路由到CanIf。漏配了，報文繞過了SecOC，裸奔上總線，你還以為保護了。

5、第五塊：生成代碼和驗證。

工具生成代碼后，檢查SecOC模塊有沒有正確初始化、密鑰槽有沒有正確安裝。然后編譯燒錄，用總線工具驗證。

4.2 踩坑一：新鮮度值不同步導致驗簽失敗

這是SecOC項目第一大坑，前面2.5講了癥狀，這里講配置層面的根因和預防：

• ECU重啟后計數器沒有復位到和發送方一致，兩邊錯位，驗簽全掛。對策：配置好重啟后的重新同步流程，別讓接收方傻等。

• 時間同步型的新鮮度值，gPTP沒收斂就開始通信。對策：啟動時序上保證"時間同步OK"再允許安全通信，或者配置好新鮮度值有效窗口。

• 截斷位太短，容差窗口太大，老報文還能在窗口內蒙混過關。對策：按報文周期算好截斷位，周期越短，截斷位越長。

排查手段：把收發兩邊的當前新鮮度值都打出來，直接對比差值。差值穩定在一個小范圍內就是同步正常，差值亂跳就是同步邏輯有bug。

4.3 踩坑二：MAC截斷長度收發不一致

這個坑蠢但極其常見：發送方配置32位MAC，接收方配置了64位——兩邊DLC都對不上，更別說驗簽了。或者同一份DBC，A ECU刷了新配置，B ECU還是舊配置。

癥狀是：單方向通、反方向不通；或者換個ECU就全掛。這種問題看配置對比表一查一個準。對策：SecOC參數（Data ID、MAC長度、新鮮度截斷長度、密鑰）必須做全網絡的配置一致性檢查，上線前用腳本比對所有ECU的配置文件，別靠人眼。

4.4 踩坑三：密鑰輪換失敗

癥狀：密鑰輪換后，一部分報文能收，一部分不能；或者某臺ECU刷了密鑰后整車通信癱瘓。

根因幾乎都是切換時機不一致：發送方已經切到新密鑰，接收方密鑰槽里還是舊密鑰，或者反過來。如果報文里帶了Key ID，接收方還能勉強識別；不帶Key ID的，切換必須整車同步，任何一臺沒跟上就是故障。

還有一個隱蔽的：密鑰輪換流程本身——KeyM把密鑰裝進槽位后，要顯式"激活"才生效。只安裝了沒激活，代碼跑的還是舊密鑰。審計日志里看密鑰狀態機：

卡在Installed就是沒激活。

4.5 踩坑四：SecOC和E2E怎么配合

E2E（End-to-End Protection）和SecOC經常被搞混，實際項目里兩個經常同時上。搞清楚分工：

• E2E

  是端到端（SWC到SWC）的保護，管的是信號層面的完整性：數據損壞、丟失、重復、亂序、延遲、插入。它一路跟著數據走，跨網關也能全程校驗，因為校驗在應用層做。

• SecOC

  是逐跳（ECU到ECU、總線段到總線段）的保護，管的是PDU層面的真實性、完整性和防重放。到了網關，SecOC驗完再重新加保護，網關就是SecOC的邊界。

同一幀報文里它倆是疊加的，不是二選一：

E2E管"數據在應用鏈路上有沒有出錯"，SecOC管"報文在總線段上有沒有被偽造重放"，各管一段，互不替代。

反面教材

有人覺得上了SecOC就不需要E2E了，結果網關轉發的場景里，SecOC在網關就驗完了、重加了，跨網段全程的完整性反而沒人管了——丟了幀、錯位了信號，應用層根本不知道。反過來只上E2E不上SecOC，偽造和重放防不住。高安全等級的系統，兩個都得有，一個都不能少。

4.6 踩坑五：多核SecOC性能開銷

SecOC的MAC計算是實打實的CPU開銷：每個安全報文，收發兩個方向各一次CMAC。算一筆賬：一個域控上20條安全PDU，每條10ms周期，每幀雙向2次CMAC，一秒鐘就是4000次AES-128-CMAC運算。純軟件實現，這能吃掉好幾個百分點的CPU，任務超時、報文丟幀分分鐘出現。

對策按優先級排：

1. 第一優先：硬件加速。

   現在的主流MCU基本都帶HSM或密碼學加速器，把CMAC交給硬件算，軟件開銷趨近于零。Csm配成異步Job，別阻塞。

2. 第二：核間分攤。

   多核架構下把不同Secured PDU的驗簽任務分到不同核，別全堆在一個核上。

3. 第三：降頻降長。

   報文周期拉長（業務允許的話）、MAC截斷長度縮短（安全允許的話）、減少保護報文的條數。

4. 第四：算力預留。

   設計階段就給SecOC留出20%以上的算力余量，別等測試爆了再改架構。

測性能的土辦法：在SecOC處理前后打時間戳，統計單幀處理耗時和峰值耗時，峰值耗時不能超過報文周期的30%，否則調度抖動一來就出事。

4.7 調試方法：CANoe驗證、抓包分析、故障模擬

第一招：CANoe驗證SecOC報文。Vector的CANoe支持SecOC，把密鑰、Data ID、新鮮度值策略配進CANoe的分析環境（Security Manager），CANoe就能像接收方一樣實時計算MAC，并在Trace窗口里標出每條報文的驗簽結果。MAC錯誤、新鮮度值錯誤、重放，一眼就能看出來。這是項目調試最常用的工具，比你自己寫腳本算MAC快一個量級。

第二招：抓包分析新鮮度值。用CANoe抓原始總線報文，或者用任意總線分析儀，重點看三條：

• DLC和DBC定義是否一致：多了字節，多出來的尾部就是新鮮度加MAC

• 新鮮度值是否單調遞增：相鄰兩幀的截斷新鮮度值應該連續遞增（0x0042、0x0043、0x0044）。看到跳變、回退、長時間不變，就是新鮮度值邏輯有問題

• 周期是否穩定：SecOC驗簽失敗丟幀會導致接收方向信號周期出現空洞，看周期圖能反推丟幀位置

第三招：模擬新鮮度值不同步故障。測試要主動制造故障，驗證安全機制真的在工作：

• 凍結發送方的計數器，或者篡改發送方時間，連發幾條報文，接收方應該在預期窗口內全部拒絕，錯誤計數器上漲

• 用CANoe錄制一條合法報文，等一會原樣重放，接收方必須拒絕——這是驗證防重放的核心用例，測試報告必寫

• 單邊更換密鑰，所有報文驗簽失敗——驗證密鑰輪換失敗時的安全降級行為

• 故意讓時間同步失效，驗證接收方是降級還是安全停機，降級策略是否符合功能安全設計

第四招：看錯誤計數器。SecOC模塊內部有驗證失敗計數器、新鮮度值錯誤計數器，通過調試口或診斷讀出來，能區分"MAC算錯"和"新鮮度不對"兩種失敗，排查方向完全不同。

回到開頭那句話：SecOC不是"加個密"。

它是一套完整的認證體系：Data ID綁定報文身份，新鮮度值防重放，CMAC保證完整性和真實性，密鑰管理保證信任基礎，配置一致性保證整套體系不破功。而新鮮度值，是整個體系里最容易被忽略、也最容易出事的環節——不同步，全盤皆輸。

這篇文章把原理、配置、踩坑、調試串成了一條線。你在項目里真去配一遍SecOC，再親手制造一次重放攻擊看它被拒掉，這一章就算真正過了。下次面試再有人問SecOC，你就從新鮮度值講起，面試官就知道你是真干過活的。

來源：車載軟件研習社