标签: SecOC

1.前言 我们在以往的分享中介绍了网络安全的相关技术在车载通信中的一些内容，包括E2E和SecOC等，但这些技术通常更多地是做数据校验，数据本身还是以明文进行传输。而随着网络安全级别的提高以及以太网在车载中更大规模的使用，我们迫切地需要数据加密的手段来防止数据被监听。同时由于车载通信对延迟性能的要求和部署的特点，MACsec可能是一个更容易被选择的方案。 2.什么是MACsec MACsec全称为Media Access Control Security，基于协议802.1AE和802.1X，主要功能是用于数据加密，同时还有认证、校验的功能。其保护的数据是以太网中二层以上的数据，即包括ARP在内的数据，都会被加密进而无法通过网络监听获取。 同时相比于其他加密手段，如TLS，MACsec由于可以基于硬件实现，因此可以做到更低的延时和更高的性能。并且对于上层应用来说，MACsec是在二层进行加密，因此对于上层来说是无感的，这意味着上层不需要做任何改动就可以进行加密的部署。这对于当前无加密系统切换加密系统来说有着很大的优势。 3. MACsec工作流程 MACsec使用对称加密，其密钥生成分发过程为EAPOL-MKA（EAP是Extensible Authentication Protocol，EAPOL即EAP over LANs，MKA即MACsec Key Agreement protocol ，见IEEE Std 802.1X)，标准的MACsec的EAPOL-MKA流程会先进行密钥服务器的选举，但在车载网络中，更可能的情况是预先定义好密钥服务器，因此本文就不赘述密钥服务器选举流程（可以参考IEEE 802.1X），直接看一下密钥服务器如何生成和分发密钥。 首先所有的MACsec设备中会预先配置好一个密钥，称为CAK（Secure Connectivity Association Key），由于其是预先定义的密钥，因此也叫做Pre-Shared-Key。需要注意的是，CAK并不是能直接参与数据加密的密钥，实际用于数据加解密的密钥是SAK（Secure Association Key），SAK是通过CAK进行派生，SAK的生成过程如下所示： 1）预配置密钥：除了预先配置CAK外，还需要配置密钥标识CKN（Connectivity Association Key Name）。CKN就是额外的一个数据参数，CAK+CKN共同用于密钥派生函数KDF（Key Derivation Function）。 2）密钥派生：CAK通过不同的派生函数（派生函数参考AUTOSAR AUTOSAR_SWS_MACsecKeyAgreement、IEEE 802.1X、NIST 800-108）和参数生成3个密钥：ICK（Integrity Check Value Key，即校验的密钥）、KEK（Key Encryption Key，即加密SAK的密钥）、SAK（Secure Association Key，即实际加密数据的密钥）。其中ICK和KEY是通过CAK+CKN生成固定的密钥，可以认为MACsec设备均已预先得知。ICK用于流程校验，KEK用于SAK的加密。SAK是由CAK+RNG（Random Number Generator，即随机数生成）生成的随机密钥，用于实际数据的加密。 3）加密SAK：使用KEK加密SAK（加密算法参考rfc3394中AES Key Wrap algorithm），将加密SAK传输到以太网总线中 4）获取解密后的SAK：伙伴节点使用相同的KEK解密后获取SAK，将SAK用于实际数据的加解密 在SAK成功分发到MACsec节点后，MACsec中的二层以太网报文就都可以用加密的方式进行数据的交互 4. MACsec报文格式 MACsec的报文格式如下图所示： 其中DMAC即目标MAC，SMAC即源MAC，CRC即帧校验，这部分都是以太网帧中原有的内容。802.1Q+payload即原有以太网中携带的数据（包含以太网帧类型），这部分数据会以GCM-AES-128（也允许支持GCM-AES-256）的加密算法进行加密（密钥为上一章节中分发的SAK）。ICV（Intergrity Check Value）为校验码。SecTAG为加密头，用于识别MACsec相关信息，其结构如下： MACsec EtherType为固定值0x88E5，表示MACsec报文； TCI（TAG Control Informatin）为控制信息； AN（Association Number）为关联号； SL（Short Length）为短数据长度（小于48字节才会使用，见IEEE 802.1AE）； PN（Packet Number）为包的序号，用来防止重放攻击； SCI（Secure Channel Identifier）中还包含PI（Port Identifier），即通道和端口的标识，对简单网络来说应该是固定值。 SecTAG的解析见如下示例： 另外对于GCM-ASE算法来说，有3个参数：nonce（即加密向量IV）、add（附加消息）、tag（消息认证码）和MACsec中字段有映射关系。Nonce对应SCI+PN，add对应DMAC+SMAC+SecTAG，tag对应ICV（参考IEEE 802.1AE）。 5. CANoe MACsec示例 在CANoe中我们建立多个节点：ChatClient1和ChatClient2以TCP的连接与ChatServer建立会话关系，他们的通信不需要关注MACsec。实际在总线的数据由Switch_1的Port1与Switch_2的Port2进行以太网数据的发送接收，拓扑关系如下所示： 环境启动后，Port1和Port2就进行MACsec的SAK分发过程，分发完成后，Port1和Port2就可以正常以MACsec进行加密通信，如下所示： 当我们在ChatClient1发送会话数据“Polelink”，ChatClient2响应会话“YES”时，对于ChatClient1和ChatClient2来说数据的收发是原封不动的明文，如下所示： 而对于实际以太网数据而言，Port1和Port2的收发数据就全是密文数据，如下所示： 6.总结 北汇信息专注于汽车电子测试、与众多OEM合作，在总线网络诊断测试开发相关领域积累了丰富的经验。本次为大家简单介绍了MACsec，但很多细节还有待商榷，后续我们也会带来更多关于网络安全的测试开发内容，也欢迎大家共同探讨。 注：文中图片来源于AUTOSAR、Vector CANoe、IEEE 802.AE 参考文献 AUTOSAR_RS_MACsec AUTOSAR_SWS_MACsecKeyAgreement IEEE 802.1X IEEE 802.1AE https://info.support.huawei.com/info-finder/encyclopedia/en/MACsec.html https://community.cisco.com/t5/networking-knowledge-base/mka-macsec-key-agreement-exchange-on-the-wire/ta-p/4436083

网络安全：关于SecOC及测试开发实践简介 北汇信息-蒋露 1.前言 我们知道，在车载网络中，大部分的数据都是以明文方式广播发送且无认证接收。这种方案在以前有着低成本、高性能的优势，但是随着当下智能网联化的进程，这种方案所带来的安全问题越来越被大家所重视。 为了提高车载通信的安全性，各OEM已经采用针对敏感数据增加诸如RollingCounter和Checksum的信息，但其能实现的安全性十分有限。 而随着车载网络技术的发展，我们有了更多的方式来实现网络安全。之前我们曾介绍过E2E（End to End）的技术，本期我们将介绍SecOC方案。 2.SecOC简介 SecOC全称Secure Onboard Communication，主要用于对车内敏感信息进行认证。 其数据结构如下：Authentic I-PDU是需要被保护的数据；Authenticator为认证信息（通常使用消息认证码，即Message Authentication Code，简称MAC，后文以MAC来简称此内容）；Secured I-PDU Header为可选用的报头；Freshness Value为可选用的新鲜度值。 图1 Secured I-PDU结构 而在实际使用中，新鲜度值和MAC可能会使用较多长度的数据来提高安全性，但这又会消耗大量的带宽等资源，所以常使用截取的方式做平衡处理。新鲜度值和MAC都按照完整的值来生成，但是在发送和认证的时候只会截取一部分，如下图所示： 图2 Secured I-PDU的截取 以CANoe demo中的ARXML为例，其节点ECU1发送的Secured_PDU_1分别包含了8个字节的Authentic I-PDU，1个字节的新鲜度值（实际长度8字节）和3个字节的MAC（实际长度16字节）。 图3 Secured I-PDU在ARXML中的排布示例 接下来我们就以此Demo为例，来详细谈谈SecOC中2个重要的组成部分：新鲜度值管理（Freshness Value Manager，简称FVM）和MAC生成 。 3.新鲜度值管理 在SecOC中，给出了多种新鲜度值管理方案： 1）基于counter的递增，即包含了原有方案的机制 2）基于全局时间戳，源于时间戳的唯一性 3）基于同步的复合counter 这里我们主要谈一下第三种方案。在此方案中，完整的新鲜度值包括同步计数器（Trip Counter）、重置计数器（Reset Counter）、重置标志值（Reset Flag）和消息计数器（Message Counter）。其中消息计数器又分为高值和低值，而真正在报文中发送的值只包含消息计数器的低值和重置标志值。 图4 新鲜度值结构 新鲜度值的更新如下所示，完整的新鲜度值为0x10000040F，实际发送的新鲜度值为0xF。而由于重置标志值为1 bit，消息计数器虽然以步长1递增，实际发送到总线上的新鲜度值则是以2的步长递增。 图5 新鲜度值示例 从上述内容可以看出，新鲜度值存在 2 个重要的基准：同步计数器和重置计数器，这 2 个计数器需要接收方和发送方保持一致。 SecOC 在新鲜度值管理上提出了主从模式的框架，由主节点向接收方和发送方分发同步计数器和重置计数器，从而达到同步的目的。 图6 主从模式的新鲜度值管理 图7 新鲜度值的分发示例 4.MAC生成 MAC是对受保护数据的身份认证。其中涉及的加密算法多种多样，每个算法还可以有多个配置。这里我们以SecOC提供的一个方案Profile 1进行说明，其使用CMAC/AES-128的算法，截取8 bit的新鲜度值和24 bit的MAC，配置信息如下所示。 图8 Profile 1配置 除此配置外，MAC生成还需要128 bit的密钥（这里预先定义了0x0102030405060708090A0B0C0D0E0F10）、16 bit的Data ID（这里预先定义了33）、完整的新鲜度值和需要认证的数据。Data ID是用来标识I-PDU的数据，可以给密钥管理机制提供支持。以Demo中时间戳为8.300203的I-PDU进行说明，需要认证的数据为0xE8030000000000FF，完整的新鲜度值为0x100000405，实际进行加密运算的数据为Data ID、待认证数据和完整新鲜度值的拼接，计算后的实际MAC为0x498330e818f3fbb068759ff3b72d015f，截取24 bit后发送的MAC为0x498330。 图9 MAC发送示例 这里使用的加密为对称加密，以更快地进行I-PDU的交换。通常的做法还包括利用非对称加密的方式来传递对称加密的密钥，以此完成密钥的定期更新。通过对Data ID、I-PDU和密钥的映射，以及密钥的更新和分发，可以做到一个非常完整的密钥管理方案。 5. SecOC测试开发 从上面可以看出，SecOC的机制是比较复杂的，按照过往的项目经验，需要测试验证的内容包括新鲜度值管理、MAC认证、密钥分发等。 为了保证ECU的运行环境，并监测ECU自身的行为，我们需要仿真其外部条件，包括同步报文、ECU接收的SecOC报文等。为了实现此仿真环境，可以使用CANoe提供的Security模块。 在CANoe的Security Configuration中，对SecOC方案的进行选择与配置，并将其与控制器的端口形成映射。 图10 Security Configuration配置 在ARXML中，可直接配置相关的信息，包括Data ID、新鲜度值的长度等。通过这种方式，可以对每个I-PDU进行不同Data ID的配置从而形成I-PDU和Data ID的映射。 图11 ARXML相关配置 在CANoe的Security Manager中，可以对Data ID进行其密钥的写入，实现密钥与Data ID的映射。 图12 Security Manager相关配置 除了使用CANoe的Security模块，还可以集成CANoe的SecOC接口函数等进行编程来实现仿真环境。解决了仿真环境后，需要依据所开发的测试用例实现测试脚本。一方面验证正向的SecOC流程，另一方面验证SecOC机制的防“攻击”特性。通过使用CANoe的各个内置函数及外部第三方编程接口，对仿真条件进行相应的输入控制器，并监测ECU的反馈，就可以高效地完成SecOC的验证。 图13 SecOC测试用例展示 6.总结 在网络安全领域，越高的安全性要求，意味安全机制的复杂性，对系统资源消耗和性能的更高要求。那么，需分析和确认哪些数据需要被保护、网络安全等级如何定义也尤为重要。结合应用场景，考虑数据的敏感性、实时性等要求，才能选择合适的方案。不管是E2E更偏向数据完整性的校验，还是SecOC中更关注身份合法性的认证，包括SSL、TLS提供的保密性，都是可供选择的方案。 北汇信息专注于汽车电子测试、与众多OEM合作，在总线网络诊断测试开发相关领域积累了丰富的经验。本次为大家简单介绍了SecOC，后续将会为大家带来更多信息安全的相关内容。关于车内的通信、诊断刷写中各类网络安全相关的测试验证方案，欢迎垂询和沟通，共同探讨。 注：文中图片来源于AUTOSAR、Vector CANoe 参考文献 AUTOSAR_SWS_SecureOnboardCommunication AUTOSAR_SWS_CryptoServiceManager NIST Special Publication 800-38B