AUTOSAR SecOC Introduction -- Part 1

Introduction

AUTOSAR Secure Onboard Communication (SecOC) 作用是提供一种机制用于保证ECU之间通信过程中的“重要”数据的完整性和身份验证。目前SecOC 需要和COM Stack 结合使用,对于SWCs之间的数据保护则不能使用SecOC

在AUTOSAR 架构中,SecOC 和PDUR 数据同一层, 其要负责和Crypto Stack交互进行数据加密与验证,也要负责和PDUR 交互进行数据的传递

AUTOSAR SecOC Introduction -- Part 1_第1张图片

传统通信方式弊端

  1. 数据完整性的保护机制没有或者很弱

由于数据完整性保护机制没有或者很弱,ECU 之间传输的数据如果在传输过程中存在较容易被篡改的风险。

      2.无法保证数据来自一个合法的数据源头

如果发送的数据可以轻易被其他人模拟发送,ECU 就无法判断接收到的数据命令是否来自一个合法的数据源

     3.如果通过提高算法复杂度加强对通信数据保护,虽然可以在一定程度保证数据的“安全“

        但是会带来Runtime的过高消耗 

如果算法复杂度不高,数据保护机制就不强,反之如果算法复杂度足够高,虽然可以保证数据保护机制,但是也必然带来过高Runtime消耗,因此在传统数据保护机制所使用的算法都相对简单

     4.CRC/Checksum 算法(参数)在整个研发,生产过程中无严格的保护机制,

        容易因为外泄造成安全机制事故。

使用SecOC的好处

  1. 数据完整性的保护机制没有或者很弱
  2. 无法保证数据来自一个合法的数据源头

        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是否正确来决定数据是否被篡改

AUTOSAR SecOC Introduction -- Part 1_第2张图片

 

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 Introduction -- Part 1_第3张图片

 

因此在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)

AUTOSAR SecOC Introduction -- Part 1_第4张图片

 

这种方式有个最致命的缺点:

  1. Freshness Value 需要足够大,如果过短通过穷举法可以模拟出所有情况
  2. 当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个新问题,如下

  1. Sender / Receiver 的timestamp需要具有同步机制
  2. 由于数据从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的长度

AUTOSAR SecOC Introduction -- Part 1_第5张图片

Data Identifier

也是SecOCDataId 每一个Secured I-PDU 都会对应唯一的一个DataID

你可能感兴趣的