SecOC密钥及安全解决方案.docx
《SecOC密钥及安全解决方案.docx》由会员分享，可在线阅读，更多相关《SecOC密钥及安全解决方案.docx（10页珍藏版）》请在冰豆网上搜索。
SecOC密钥及安全解决方案
SecOC密钥安全
越来越多的车辆连接到外部IT系统以支持新的功能和业务模式。
为了保护联网车辆免遭网络攻击，密钥加密的方法正在被使用，其安全性基于相应的密钥材料。
对于密钥管理而言，需要应对解决哪些挑战呢？
采用AUTOSAR定义的实现方式又将带来什么好处呢？
多年以前，车辆中就开始部署与安全相关的功能。
数据加密和数字签名等加密操作已经被使用，例如安全防盗系统和ECU安全刷新。
车辆互联化的趋势扩大着车辆的功能范围，比如，远程（OTA）软件更新、远程功能激活以及车辆与基础设施之间的通信（V2X）。
这些应用案例均可为汽车行业创造有趣且非常有前景的商业模式。
然而，随着车辆互联的程度愈来愈高，对车辆网络攻击的潜在方式也越来越多。
密钥：
网络安全的基础
汽车行业正在制定部署自己特定的安全措施或从传统IT领域借鉴相关通信协议以应对网络攻击的风险。
例如，AUTOSAR中已经被标准化的安全车载通信系统（SecOC），用来保护车辆内ECU之间的网络通信。
根据总线技术和具体的应用，还可以使用IT领域中的安全传输层协议（TLS）和互联网安全协议（IPSec）。
所有现代安全机制的特点是安全性更多的取决于密钥的保护，而不是使用何种加密算法。
为了进一步提升安全性，任何给定的密钥只能用于一种安全应用场景。
越来越多的网络安全应用导致很多ECU需要存储大量加密材料，如密钥、私钥/公钥对和证书。
在这个背景下，密钥的存储和管理就变得越来越重要，它们之间的差异会在下面进行讨论。
安全地保存密钥
近年来，加密硬件的标准化有了进一步的进展。
一个特殊的硬件单元——硬件安全模块（HSM），能够安全地存储密钥和加速加密计算。
AUTOSAR已经针对密钥模块和密钥服务（Figure1）在基础软件的实现进行了标准化。
这些模块基于软件库或者HSM（Figure2）提供用于访问安全功能的标准化接口。
这种软硬件结合的方式使得在ECU中可以高效且安全地存储密钥。
Figure1:
ThepurposeoftheAUTOSARCryptoStackistomodelkeysandtomakeuseofcryptographic services
Figure2:
ArchitectureofaHardwareSecurityModule（HSM）
安全地保存密钥
密钥不仅仅在日常工作模式下使用，在车辆的整个生命周期里都需要使用到密钥并进行密钥管理（Figure3）：
1.ECU开发阶段：
在ECU中保存初始密钥。
2.车辆集成阶段：
用开发密钥替换初始密钥。
3.车辆生产阶段：
用生产密钥替换初始密钥或开发密钥。
除此以外，通常还需要安装外部密钥或者从已存在于车辆中的密钥派生出新的密钥。
如果密钥是在ECU之间共享的，那么必须确保这些密钥的保密性和完整性。
例如，绝对不能以纯文本的形式在总线上发送密钥。
4.售后和淘汰阶段：
更新或者安装额外的密钥。
例如，远程功能激活就需要合适的新密钥。
当需要更换有故障的ECU时，必须要采取相应的措施来保障关键的密钥不会被任何方式读取和篡改。
同时新的ECU也需要提供合适的密钥来保障正常的功能执行。
Figure3:
Keymanagementrangesovertheentirevehiclelifecycle密钥管理策略
以SecOC为例介绍多样化的密钥管理策略。
SecOC主要用来验证车辆中ECU之间的通信，可以帮助数据接收方检测数据是否重发，检查发送方的真实性以及评估传输数据的完整性。
因此，接收方就需要验证消息认证码（MAC）。
MAC本质上就是密码校验和，即发送方生成数字签名，接收方检查其有效性。
一旦MAC检查失败，接收方就会拒绝接收该消息。
出于通信实时性的考虑，MAC选择用对称加密算法。
在这种算法中，发送方和接收方会采用相同的密钥去分别生成和检查MAC。
在密钥整个生命周期内，密钥都需要妥善地保护好。
因此，密钥不允许在车辆内部或外部网络之间进行没有保护的传输。
下文还会提到生产期间密钥的生成和安装。
这些不同的密钥策略不会在本文进行评估，这里只是告诉大家在实践当中，存在多种不同的密钥管理解决方案，甚至对于相同的使用场景，也可以选择不同的方案。
下面介绍在SecOC中，密钥是如何生成和分配的。
非车载的密钥生成
有一种策略是使用一个非车载的密钥管理服务器去生成SecOC所需的密钥。
这个服务器必须要有车辆中ECU信息和SecOC所需密钥的需求信息。
ECU会在生产过程中获得所需密钥。
因为保密安全的需要，所以在传输过程中要对密钥进行加密保护。
ECU在存储密钥之前需要检查其真实性和完整性。
车载协调器的密钥生成
车辆生产期间，诊断仪会将一个经过认证的例程请求发给车载协调器，用来生成SecOC密钥。
首先，充当协调器功能的ECU会生成一个通用的车辆密钥，通过密钥协议和临时的安全通道把这个通用密钥发送给其它ECU。
基于这个密钥和密钥的派生协议，每个ECU都会生成合适的SecOC密钥。
因为执行密钥协议需要相当长一段时间，所以它仅适用于密钥的生成和分配。
使用刚刚生成的密钥，所有的ECU都可以通过SecOC进行安全高效的通信。
这样做可以避免新的密钥分配带来的安全隐患。
无车载协调器的密钥生成
跟车载协调器的密钥生成一样，密钥在车辆内生成。
只不过生成密钥的请求不再发送给负责协调的ECU，而是直接发送给目标ECU。
每个ECU都知道自己所在组的成员，并且它们会启动多阶段的密钥协议。
组内的成员相互交换信息以生成共享密钥，从而无需通过总线发送密钥。
一旦组内的所有ECU都计算出了共享密钥，那么每个成员都会根据密钥的派生规范生成SecOC所需的密钥。
标准化现状
由于此前没有关于密钥管理的标准化方案，各OEM会采取私有的解决方案，这样会导致因为解决相同类型的问题而开发和维护不同解决方案的情况，从而产生额外成本的增加。
另外一个考虑因素是密钥管理通常不具有差异化产品特征，因此密钥管理的标准化在AUTOSAR4.4中得到了实现，并且制定了用于密钥管理的专用模块KeyM（Figure4），该模块由密钥和证书两个子模块组成。
密钥子模块提供处理密钥的功能。
密钥处理过程分为不同的阶段，在最后阶段，密钥在ECU的HSM中导出或存储。
KeyM模块中没有实现OEM定义的逻辑，而是把相应逻辑作为密钥处理程序放在应用层实现（Figure4）。
证书子模块用于解析、验证和安装证书，可以读取证书已定义元素的值，从而用于进一步的处理。
在最后阶段，证书将被存储在ECU的非易失性内存（NVM）或HSM中。
Figure 4:
InAUTOSAR,keymanagementisimplementedbytheKeyMmodelwithitstwosub-modulesCryptoKeyandCertificate.
标准化的挑战
密钥管理与OEM和供应商的开发、生产以及售后流程密切相关。
因为密钥已经被用于某些功能中，在一些IT基本架构中也都存在，例如公钥基础设施（PKI）和密钥服务器，所以OEM更倾向于复用已有的基础架构，因此标准化的可能也就受到了限制。
现有的或规划中的基础架构还会影响是否选择车载或非车载的方法来生成密钥。
此外，密钥管理还受OEM定义的安全目标影响，这些目标会有不同的考虑因素，例如在开发、生产和售后服务环境中的安全性假设。
举例来说，关于内部生产环境是否安全存在不同意见。
这些假设会直接影响在生产和售后环节引入密钥时所采取的保护性措施。
所需的产品性能要求也会影响密钥管理。
例如，如果需要在几秒钟内把密钥分配给所有ECU，那么密钥管理策略就需要为此而进行设计。
通过标准化减少方案数量
加密算法和相关密钥材料构成了现代汽车安全机制的基础。
它们用于保护创新功能和基础业务模型免受攻击。
迈向标准化的第一步是在AUTOSAR中引入KeyM模块。
它没有对特定的密钥管理策略标准化，而是为不同策略提供了通用接口。
汽车行业应该集中精力协商密钥管理策略，使密钥处理策略的标准化成为可能，从而减少实践中的解决方案数量。
高度标准化的优势在于降低开发和维护成本。
SecOC安全
SecOC规范虽然详细介绍了消息保护技术，但一些安全方面仍然不属于AUTOSAR规范的范围，也就是密钥管理和新鲜度管理。
此外，该规范不一定适用于所有车内通信，并且当正确应用时，可能会受到CAN消息大小的限制。
这些都会带来安全挑战。
以下将讨论ElektrobitSecOC产品机制和ArgusIDPS的联合方法，以充分利用这两种技术的优势，并大大提高车内通信的安全性。
1.SecOC规范差异
尽管详细说明了SecOC的许多方面，但AUTOSAR有意将密钥管理或新鲜度值管理等方面从标准化中排除。
这些方面必须由每个OEM单独定义，其中涉及解决每个解决方案所特有的安全方面。
为了降低重复攻击的风险，解决方案中需集成新鲜度值管理。
AUTOSAR标准将计数器或基于时间的新鲜度值作为典型选项，但由于不同的OEM解决方案，这些主题却被有意地排除在标准化之外。
这使得OEM在实施SecOC方案时需要定义两个基本的安全攸关方面：
新鲜度值管理和密钥管理。
后面会讨论需要解决的一些典型挑战。
2.新鲜度值管理
时间管理是一种特殊的计数器管理形式。
若要根据时间值设置SecOC方案，您需要在参与SecOC组的所有ECU中建立同步且安全的基准时间。
面临的挑战是确保安全的时间同步，而不依赖于SecOC机制。
如果使用基于对称加密的类似SecOC机制传输初始时间值，则所涉及的所有ECU都可以访问用于验证时间戳消息的密钥。
任何ECU都可能冒充时间戳消息的发送方并将欺骗性时间戳消息发送到其他ECU。
因此，被盗用的ECU可能会尝试执行以下任何操作：
（1）向后移动时间（甚至稍微后移）以扩展消息接受窗口。
（2）在一个网段中实质上改变时间，使其与其他网段不同步。
（3）通过将新鲜度机制移动到其最大值来有效地禁用新鲜度机制。
通常，由于不支持值的翻转以防止重复攻击，因此一旦新鲜度达到其最大值，它将无限期地保留在那里。
一旦新鲜度值被固定，就无法阻止重复攻击。
安全通信的监测机制如图1所示。
图1安全通信的检测机制
3.密钥管理
有许多策略可用在相关的ECU中分配和管理对称密钥，但许多不太复杂的策略涉及难以维护的复杂流程。
通常，为了处理不同ECU中的对称密钥，将使用基于附加非对称算法的密钥交换机制。
这些机制允许车辆中ECU之间的密钥交换，并且可以触发一次、频繁地触发或根据请求（例如当不同步时）触发。
在计算能力方面，这种密钥交换机制的实现通常很昂贵，这可能导致某些速度优化，从而危及安全目标：
（1）攻击者可能会窃听ECU更换过程并从车内流量中提取新密钥（即，即使它被另一个“已知”密钥加密）。
（2）攻击者可能会强制进行密钥交换。
这可能导致拒绝服务或可能允许攻击者窃听密钥资料。
在AUTOSAR架构中集成安全的通信如图2所示。
图2在AUTOSAR架构中集成安全的通信
4.MAC截断
当通过CAN网络实现SecOC时（与通过CAN-FD网络实现相反），每条消息只有8Byte的数据可用（而不是CAN-FD中的64Byte）。
若要执行消息验证，这8Byte必须包含MAC和消息数据。
由于这种严格的限制，必须使用短MAC（例如，2-4ByteMAC使该方案容易受到蛮力攻击—对于2ByteMAC，车内蛮力攻击只需2h即可攻破，对于4ByteMAC，蛮力攻击大约需10天）。
在这种情况下，如果这些消息对这些时隙有效，蛮力攻击可能会导致在总线上成功注入一条有效但恶意的消息。
这种单条有效但恶意的消息的潜在影响的一些示例可能是：
（1）恶意单条消息可能会操纵新鲜度/时间戳值。
这建立在上面给出的分析的基础上，但它并不要求攻击者知道SecOC密钥即可完成攻击。
（2）恶意单条消息可能会对车辆造成网络物理损坏。
例如该消息可以模拟预碰撞消息，用于紧固安全带并切断燃料泵。
抑或该消息可能解锁车门或使防抱死制动系统减压（即，使制动器放气）以便禁用制动器。
在大型车队的数百或数千辆车辆上大规模地执行此攻击可以显著缩短攻击者成功猜出一条有效消息所需的时间。
如何通过IDPS增强SecOC
与SecOC相比，IDPS可以提供有关系统安全性的不同声明。
监控总线上的所有消息，IDPS不需要显式配置单条消息，并且可以基于将每条消息与预期车内流量行为的预定义行为模型进行比较来检测流量中的异常。
此外，IDPS的部分行为模型一般可以包括协议的属性、消息序列的逻辑和总线流量等。
这可以包括消息的定时和内容属性以及关于车辆中不同消息的消息测试和合理性测试的预期一致性。
例如，IDPS可以对诊断流量进行分析以便对其进行验证并确保其与车辆的当前状态一致，或者它可以检测与周期性消息的预定义循环时间的偏差。
这些品质可用于增强SecOC方案和必要的相邻协议的安全性。
Argus和Elektrobit在2017年EscarUS上展示的综合解决方案如图3所示。
图3Argus和Elektrobit在2017年EscarUS上展示的综合解决方案
关于检测攻击，上面提到的对SecOC方案的示例攻击通常要求攻击者将消息注入总线或以与正常情况下预期车内流量的行为方式不同的方式修改流量。
因此，部署在车辆中心位置（例如，在网关上，具体取决于车辆架构）的ArgusIDPS可以基于不同的消息定时和内容模型以及一致性和其他合理性测试来检测是否有攻击在尝试操纵SecOC。
IDPS的行为模型可以包括新鲜度值和密钥管理协议的属性，因此，IDPS可以被配置为检测重复攻击、新鲜度值操纵尝试、密钥管理操纵、蛮力攻击，这使IDPS能够检测对SecOC方案正常运行所必需的相关协议和消息的攻击。
由于通过车载网络传输的所有消息都由IDPS进行监控，因此它可以检测到对SecOC方案未涵盖的消息的攻击以及针对SecOC方案本身的攻击。
整个车队的网络安全
可以收集来自IDPS和SecOC机制以及车辆中其他安全机制的安全日志，并将其发送到中央分析中心。
然后，可以使用此信息来更好地了解车队的网络安全健康状况，并协助进行网络安全事件管理流程。
客户可通过基于Web的控制面板访问该信息，该控制面板可以检查关于车队中车辆的网络健康状况的不同测量值和指标：
关于网络攻击的实时和历史信息、在线（OTA）更新车队的安全策略、攻击热图等。
车队的网络健康状况显示如图4所示。
网络安全专家和车辆工程师也可以分析其他技术信息，如取证数据。
控制面板的另一个组成部分是能够查看安全层的配置并通过OTA车队更新对该配置进行修改/更新。
图4车队的网络健康状况显示在基于网络的控制面板上
关于ElektrobitSecOC和ArgusIDPS联合设置的提案
通过互相配合，ElektrobitSecOC实施和ArgusIDPS能够全面覆盖所有网络通信：
1）使用ElektrobitSecOC验证消息的真实性和完整性。
使用ArgusIDPS保护适当的SecOC方案所必需的相关协议和消息。
2）使用ArgusIDPS增强所有消息的安全性（无论消息是否按照SecOC配置）。
3）通过监控与分析ArgusIDPS和ElektrobitSecOC及其他来源生成的车辆数据，经由无线安全更新实时了解并响应攻击。
升级会员 