加密是保护数据在传输过程中的一个默认标准。许多例子都支持这一说法，例如通过 HTTPS 进行的客户端-服务器通信以及通过移动应用程序普遍公开的热门聊天服务。加密也是《通用数据保护条例》（第32条）所倡导的措施之一，以保护任何处理此类数据的应用场景中的个人数据。欧洲数据保护委员会强调 "联网车辆和移动性相关应用的情况 "就是这样一种场景，并明确要求进行加密。然而，可以看到，目前车载通信没有加密，事实上，AUTOSAR SecOC模块只规定了完整性和真实性，详见下文。
加密也应该被添加到车辆通信中，因此，本文引入了CINNAMON，一个需要通过控制器区域网络（CAN）进行加密的模块。上述加密应用的普遍性在某种程度上促成了本次工作。更重要的是，这个概念的验证已经证明了，在目前廉价的硬件上，运算成本可以忽略不计，所以可行性大大增加了我们的动力。尽管如此，主要的动力是抗信息收集攻击，这也可能在 CAN 总线级别产生严重后果，例如专有映射的逆向工程，通常存储在数据库 CAN (DBC) 文件中。DBC存储了由原始设备制造商（OEM）决定的CAN帧有效载荷和车辆功能之间的映射。因此，DBC是攻击者的明确目标，因为它使特定车辆的电子控制单元（ECU）能够正确解读有效载荷值并将其转化为执行预期功能的信号。此外，信息收集攻击也可能是以侵犯司机的隐私为导向的。
AUTOSAR收集了监管规范汽车界的大多数战略和准则。AUTOSAR描述了一个经典平台，这是一个为深度嵌入式系统和应用软件设计的软件平台，对可预测性、安全性和响应速度有很高的要求。AUTOSAR 涵盖了车载通信的功能安全和安全性问题。
至于后者，AUTOSAR 提出了名为 SecOC 的安全车载通信基础软件 (BSW) 模块，列出了其要求并提供了其规范。SecOC坚持车载通信的完整性和作为发送方的ECU的真实性。相比之下，它不考虑保密性。
另外还会介绍CINNAMON模块，其需求利用和扩展SecOC已经提供的要求。因此，CINNAMON 是一个符合 AUTOSAR 标准的基本软件 (BSW) 模块，不仅坚持真实性和完整性（如 SecOC 所做的那样），而且还坚持 CAN 总线通信的机密性。
CINNAMON 旨在通过对 CAN 总线上传输的帧进行对称密钥加密来对抗攻击者的信息收集（逆向工程）活动。因此，攻击者将无法读帧架数据字段，除非她至少破坏了一个ECU以获得加密密钥。因此，CINNAMON在缓解信息收集攻击的设计上超过了SecOC。
本文的结构如下。
第二部分描述了假设的威胁模型。
第三部分回顾了SecOC的主要特点。
第四节通过其要求、规范和安全配置文件描述了CINNAMON。
第五节提供了对新模块的非正式安全评估。
第六节提供了原型实现的纲要
近些年，汽车安全史上，有几个对真实车辆进行攻击的例子。2010年，研究人员展示了如何远程控制一辆汽车，即，使汽车引擎可用，关闭刹车，使汽车不会停下来，并使仪器给出错误的读数。2015年，一辆吉普车切诺基和一辆通用汽车发生了劫机事件。黑客们远程控制了发动机，并从信息娱乐系统中窃取了数据。他们利用了车内信息娱乐系统的网络连接，以及安装在汽车上的信息娱乐软件的恶意版本。2016年，研究人员利用特斯拉奖励计划中的漏洞入侵了一辆特斯拉Model S，该奖励计划原本目的是使车辆获得固件更新。因为车内CAN总线网络中传输数据的保密性不足，暴露在多种威胁之下，所以这些攻击都利用了这个问题，因此我们的工作动机也随之增加。
本文假设了一个威胁模型，其中主动的黑客可能利用汽车的一些漏洞，在本地或远程获得对汽车的一些数字访问。更确切地说，该黑客：
• 可能会获取到他所观察到的网络中正在运行的协议和其他机制的信息，
• 可以随意构建和注入帧来操纵目标ECU处理的信息，
• 可能无法获得访问任何ECU的特权。
因此，威胁模型假设黑客对ECU只有部分控制权，因而他对ECU功能只有部分访问权。例如，当采用硬件安全模块（HSM）或类似的解决方案来保护加密密钥和运行加密等安全关键操作时，就会出现这种情况。
在实践中，黑客可能试图通过发送特制的CAN帧来修改目标车辆的行为，以触发接收ECU的特定功能。黑客通常会进行以下攻击：
• 重放：以恶意或欺诈为目的，重用有效的CAN帧。
• 篡改：对CAN帧的操作，破坏其内容，使接收的ECU不能执行原来的操作。
• 伪造：生成一个有效的CAN帧，然后生成一个有效的信号并激活一个特定的ECU功能。
• 模糊：注入以前伪造的CAN帧，旨在研究目标ECU对意外输入的行为。
• 伪装：通过使用其他一些真正的ECU的CAN ID来混淆黑客的身份，从而伪装成那个ECU。
• 信息收集：识别CAN帧的关键内容，如帧ID或有效载荷及其相关的ECU功能，目的是利用它对目标ECU执行事后攻击。
为了减少这样的攻击，我们认为一个安全的CAN协议应该实现以下安全属性：
• 保密性：框架的内容不会透露给未经授权的实体。
• 身份验证：可以验证 帧发送者的身份。
• 完整性：帧的内容在传输过程中不被改变。
• 新鲜度：它可以验证一个帧是否在之前收到过。
在AUTOSAR经典平台中，车载通信的安全性由基本软件模块SecOC管理，SecOC是通信服务的一部分（图1）。
图1: 在AUTOSAR中集成SecOC BSW模块
AUTOSAR中的基本软件模块是一个文件集，用于确定可部署在ECU上的某些基本软件功能。
AUTOSAR提供了所有SecOC的要求。这些要求规范了功能和非功能方面。更确切地说，非功能性需求调节了模块在消息通信方面的响应能力。
SecOC模块必须部署在所有通信的ECU上。反过来说，SecOC 使每个 ECU 能够通过消息验证码 (MAC) 验证接收到的消息的真实性和完整性，并通过使用特殊计数器验证接收到的消息的新鲜度，如下所示。与特定的协议无关，交换的信息一般以协议数据单元（PDU）的形式进行处理，因此，SecOC安全PDU可以被描述为图2。
图2：安全协议数据单元内容
按照设计，SecOC模块能够克服§II中列出的所有攻击，除了信息收集攻击，正如本文的后续部分所证明的那样。
CINNAMON BSW模块利用SecOC的设计来解决认证和完整性问题，并通过引入和规范加密技术的使用来增加保密性。在第一个版本中，CINNAMON 只打算保护 CAN 总线，因此 PDU 可以具体地视为 CAN 帧。
A. 要求
本节回顾了SecOC要求，以及它们如何在CINNAMON中被继承和升级以实现机密性、完整性和真实性的目标。除非引起相关的讨论，否则通常不会提出未经修改就继承的需求。每个需求都有一个状态字段，代表当前的原型实现对它的覆盖程度。
a) 职能: CINNAMON 00003（表 I）配置了不同的安全属性。安全专家负责确定车载通信框架的保护级别以及配置模块功能所需的参数。
CINNAMON通过设定保密性、认证和完整性属性来满足这一要求。因此，除了SecOC模块外，它还管理着加密和解密工作所需的参数。
表 I: CINNAMON 00003
b) 初始化：CINNAMON 00005（表II）还规定了加密和解密的功能。
关于 SRS SecOC 00005 的要求，CINNAMON 中的安全配置细节不仅限于用于身份验证的Key-ID 和 Freshness Values，还扩展了用于加密和解密的 Key-ID。
表 II: CINNAMON 00005
c) 正常运行: CINNAMON 00012（表 III）要求将该模块用于不同类型的总线系统。这是一个值得注意的要求，因为在当前阶段，CINNAMON 仅设计用于 CAN 总线，这一点从“部分完成”的状态中可以看出。我们预计，模块的进一步版本可以在未来扩展其他协议总线的保密性。
表 III: CINNAMON 00012
CINNAMON 00030（表四）要求该模块能够从安全帧中提取有效载荷，而不需要认证。在目前的CINNAMON规范中，只要先进行帧解密，就能做到这一点。相反，SecOC能够直接提取数据有效载荷。
表 IV: CINNAMON 00030
d) 支持端到端和点对点保护：点对点的安全通信保证了一对通信ECU之间的安全。在多跳通信的情况下，即一个帧在几个ECU之间循环以到达一个接收ECU，每个ECU都对该帧进行认证。端到端通信只保证发送方ECU和接收方ECU之间的安全，而不考虑中间的ECU。在两种通信类型中交换的帧都必须得到保护。
表 V: CINNAMON 00013
CINNAMON旨在保障点对点通信的安全。这意味着，如果一个CAN帧从多跳中通过，所有的安全机制都必须由通信链中的每一跳来执行。然而，通过对CINNAMON模块进行配置，CINNAMON 可以扩展以获得端到端的通信保护，使 ECU 不充当接收器而是转发帧。
e) 非功能需求: CINNAMON 00025（表 VI）是指计算性能。因此，它规定了执行所有安全操作所需的时间，特别是考虑到加密和解密。
B. 规范
CINNAMON 作为一个SecOC，是AUTOSAR经典平台通信服务的一部分，如图3所示。它封装了SecOC模块并继承了它的API，以便与PDU路由器组件（在这个版本中只管理CAN帧）和加密服务管理器提供的加密服务进行交互。
图 3: 在AUTOSAR中集成CINNAMON BSW模块
CINNAMON在底层通信模块（即TP）和上层软件模块（即AUTOSAR COM）之间充当中间层。此外，我们的模块在内部管理与底层的通信，以建立和发送使用单一CAN帧的安全数据。与此不同的是，SecOC规范的最后一个版本建议使用两个PDU，一个专门用来存储关于验证帧发送方的信息，另一个包含安全帧。
1) 身份验证和完整性：CINNAMON继承了SecOC的身份验证和完整性机制，如图4所示。
图 4: SecOc MAC的生成和验证
AUTOSAR假定所有 ECU都具有处理消息身份验证码(Message Authentication Codes, mac)的加密密钥。此外，外部的新鲜度管理器向发送方和接收方提供计数器，以支持交换帧的新鲜度。
CINNAMON继承了同样的先决条件，这里简要地回顾一下。设定一个发送方ECU和一个接收方ECU。在发送有效载荷之前，发送方根据有效载荷和可能新鲜度值开始生成MAC，该新鲜度值可以根据新鲜度管理器提供的单调计数器(图4)计算出来(ECU可能决定忽略新鲜度值)。因此，安全的CAN帧是由有效载荷、截断的MAC（图4中的MACT）以及可选择的截断新鲜度值（FVT）组成。
接收方在接受CAN帧之前必须对其进行证实，并通过验证MAC来实现这一点。事实上，接收方从新鲜度管理器收到的单调计数器（图4）和之前收到的新鲜度值（图4中最新收到的计数器）开始，生成一个用于验证的新鲜度值（FVV）。然后，据接收到的有效载荷和FVV计算MAC。如果结果等于接收到的MACT，则接受该有效载荷，否则丢弃有效载荷。
CINNAMON模块将AUTOSAR的安全CAN帧转变成CINNAMON的安全CAN帧；其数据字段如图5所示。通过减小有效载荷的尺寸，形成一个CINNAMON的安全CAN帧。然后，一个新鲜度值被用来保证帧内容是新鲜的。为了完成数据字段，一个额外的区块被用于信息验证码（MAC），以确保身份验证和完整性。最后，对有效载荷的64位字段进行加密以确保保密性。
2) 机密性：CINNAMON旨在通过MAC-then-Encrypt的方法来实现机密性。设定 k代表加密密钥，τ代表标签，ν代表有效载荷。在操作时，标签 τ被附加到有效载荷 ν上。然后，有效载荷和MAC都被加密，得到C=ENC(k, ν τ)。与之相反的方法是Encrypt-then-MAC，其中C=ENC(k, ν) τ , 即MAC是根据加密后的有效载荷计算的。根据所选择的算法和帧的长度，比起Encrypt-then-MAC，MAC-then-Encrypt方法更安全性更低，因为信息填充可能使黑客破坏信息重建的安全性。但是，在本文的例子中，这种风险是零，因为考虑的消息的长度是固定的，所以没有填充效果。
还有第二个原因支持本研究的选择。MAC- then-Encrypt方法对64位长帧进行加密（使用64位块大小的加密算法，不需要填充）。相比之下，根据AUTOSAR规范，使用Encrypt-then-MAC的方法，有效载荷（或有效载荷加FVT）短于64位，因此需要填充。最重要的是，在已经使用了64位的帧中，增加一个MAC必然需要传输一个额外的帧来容纳它。
Encrypt-then-MAC的一个潜在优势可能会在验证时出现，因为可以在收到帧后立即测试MAC的有效性。然而，这一操作并不适用于CINNAMON，因为接收方需要有普通有效载荷来验证MAC。
C. 安全配置文件
与安全车载通信模块一样，在CINNAMON模块中，也可以定义和管理各种安全配置文件。安全配置文件为与CINNAMON配置有关的参数子集提供了一套一致的数值。CINNAMON安全配置文件被定义为以下强制性参数的配置。
• algorithmFamily:字符串[0...1]是描述所用认证算法的第一个参数。该参数用于标识认证算法族。
• algorithmMode: 字符串[0...1]是描述所用认证算法的第二个参数。这个参数确定了使用的是哪种MAC算法。
• algorithmSecondaryFamily:字符串[0...1]是描述所使用的认证算法的第三个参数。该参数标识认证算法的第二算法族(如果有的话)。
• authInfoTxLength:PositiveInteger表示截断的MAC的长度
• freshnessValueLength:PositiveInteger表示生成的新鲜度值的长度。
• freshnessValueTruncLength:PositiveInteger 表示插入帧中被截断的新鲜度值的长度。
• algorithmFreshnessValue: 字符串[0...1]表示用于生成新鲜度值的算法。
• algorithmEncryption: 字符串[0...1]表示加密算法。
请注意，前六个参数继承自SecOC，而后两个参数是CINNAMON的典型参数。
本文确定了一个安全配置文件的例子，如表VII所示。可以看出，被截断的MAC需要24位字段，这与SecOC的选择是一致的。它依赖于Chaskey MAC，Chaskey MAC在标签截断和SPECK64/128上都是稳健的，SPECK64/128是一个由NSA公开发布的轻量级块密码。
很明显，这个安全配置文件的定义受到了实验反馈的影响，如下可见(§VI) 。
表 VII: CINNAMON安全配置文件实例
图5: CINNAMON的安全CAN数据字段
本节将CINNAMON与SecOc相比较，介绍了对CINNAMON的非正式安全评估。假设在这样一个场景中，黑客没有对ECU的完全控制，因此她没有访问电路板的特权，也不能看到每个电路板存储的加密密钥，例如在HSM保护下的密钥。评估结果可以归纳在表VIII和表IX中，表VIII涉及安全属性，而表九则显示威胁的缓解情况。
表VIII: 安全属性
表 IX: 缓解威胁
可以看出，CINNAMON针对机密性属性来统计收集的信息。然而，这一点必须进一步说明。这意味着符合SecOC的模块实现仍然会带来明显的内在风险，即黑客发现了CAN帧，试图翻译它们，并继续进行模糊处理以观察目标ECU的反应。黑客最终可能会了解观察到的每个帧的语义，并最终重新创建车辆的整个DBC。值得注意的是，因为帧是明文发送的，即使没有任何访问MAC密钥的权限，黑客的上述操作还是可能发生。而CINNAMON将这种风险降到了最低。
另一方面，必须承认，如果黑客设法完全破坏掉ECU，获得其存储的所有密钥，两个模块都将失效。然而，这一设想在即基于硬件的安全层面受阻，这一领域至少在过去20年里一直在发酵。首先，已经提到的hms(如ARM TrustZone)保护存储键的内存区域。我们甚至可以根据给定应用程序场景的特定保护需求，推测硬件保护(和成本)增加了几个级别。例如，加密密钥可以存储在TPM 2.0中，而MAC密钥可以存储在HSM中，这种结构导致黑客的多次违规行为。
VI.原型实现的纲要
上面看到的CINNAMON安全配置文件的原型实现是可用的。本文概述了它的主要特点和性能，而全部细节则发表在其他论文中。
与安全配置文件的定义一致，没有使用与新鲜度有关的参数，因此安全帧由40比特的有效载荷和24比特的MAC组成。加密是最外层的操作，因为加密是必需的。
A. 试验台
本文探讨的原型部署在两块STM32F407探索板上，每块都有一个ARM Cortex M4处理器。这些板子提供了物理输入按钮，以及用于视觉输出的发光二极管。两者都通过USB-to-CAN接口连接到工作站。
B. 实现的复杂性
我们最初选择使用Chaskey作为MAC函数是基于它的规格，这是一个幸运的选择。从最初的实验来看，这个函数相当容易实现，速度也相当快。标签被截短为24位。
然而，加密算法的选择必须谨慎。我们最初的候选算法是AES，但它会产生一个至少128位的数据字段，而我们的目标是一个只有64位的数据字段，与图5一致，这样仅需一个帧就可以容纳它。另一方面，64位版本的AES会比较弱，而且没有标准化。也试验了DES、3DES和Blowfish，但它们在应用中的主要缺点是计算成本高。相比之下，SPECK64/128使用一个128位的密钥，产生一个64位的输出，并且SPECK64/128是轻量级的，所以它是最好的选择。
C. 示例
发送板负责发送安全帧。该板使用128位密钥计算给定的40位有效载荷的MAC，然后将所得标签截短为24位，以完成所需的64位数据字段。之后，有效载荷被SPECK 64/128加密，最后通过总线发送到另一块板上。
当另一块板收到安全帧时，它首先对整个64位字段的有效载荷进行解密，然后对40位字段的有效载荷进行MAC计算。它将实时MAC截短为24位，并将其与从发送板收到的24位字段的MAC进行比较。如果所有的检查都成功，则打开蓝色指示灯，否则打开红色指示灯。
D. 性能
由于管理MAC和加密而产生的额外计算成本可能会是一个困扰。如上所述，试验和错误是不可避免的，因此不得不放弃一些候选的加密方案。然而，值得高兴的是，处理Chaskey/SPECK配对对整体性能的影响可以忽略不计。尽管使用了168MHz的低价硬件，但我们面临着平均不到6μs的时间来生成或翻译一个安全帧。
