众所周知，自2022年欧洲率先实施汽车网络安全及软件更新相关法规以来，这一趋势已扩散至全球。 韩国于今年8月起开始实施《韩国汽车管理法》，中国也即将在2026年实施相关国家标准(GB)。各国在不同的时间，以不同的标准引入法规，对于计划进军海外的OEM(车辆制造商)和Tier(控制器开发商)企业而言，理解各国法规并制定针对各市场的定制化应对策略已成为必不可少的课题。 本次网络研讨会，将重点聚焦《韩国汽车管理法》和UN法规。希望大家能借此机会清晰理解复杂的法规环境，并找到切实可行的应对方案。 飞斯柯罗基于覆盖车辆全生命周期的国际法规应对成功经验，将提出《韩国汽车管理法》的应对策略。那么，接下来我将简要介绍一下飞斯柯罗为何能够提供法规应对策略，以及我们所具备的能力。 首先，我们拥有应对网络安全法规的专业性。我们助力OEM和Tier供应商提前获得UN法规认证，并于2023年达成了全球四大汽车网络安全认证咨询“大满贯”的成就。 此外，飞斯柯罗拥有网络安全领域丰富的经验。 我们分析了10款车型所有控制器的安全漏洞，并在150多种控制器上量产应用了安全解决方案。通过向OEM和Tier供应商提供一站式解决方案，我们正在不断扩大网络安全领域的参考案例。 最后，我们正积极拓展面向软件定义汽车(SDV)的新一代控制器业务。我们自主开发软硬件(SW/HW)的安全网关控制器，在发布仅两年内就获得了100万台规模的订单。并且已完成整车制造商的1级供应商注册。 正是基于在网络安全法规认证和车载系统领域的专业能力，我们来分享有关《汽车管理法》的实用实务指南。 ■ 问题LIST 1. 想了解韩国汽车管理法修订案 2. 与UN认证（R155、R156）有何不同？ 3. 若已获得UN 认证（ R155,R156）是否可以替代？ 4. 想了解韩国汽车管理法网络安全与软件更新方面内容 5. 需要准备什么，应该怎么准备？ (OEM/Tier) 6. 应对韩国汽车管理法时，控制器软件是否会发生变化？  7. 一定要使用 AUTOSAR 吗？ 8. 可以自己开发AUTOSAR吗？ 9. 应用于AUTOSAR时需要考虑哪些方面？ ■ 视频 Ver. ■ 文本 Ver. 1. 想了解韩国汽车管理法修订案 首先从“《韩国汽车管理法》”开始解释。《韩国汽车管理法》是一部涵盖从汽车注册、安全标准、自我认证到制造缺陷纠正等环节，旨在管理在韩国境内运行的汽车，确保汽车性能和安全性，以增进公共福利为目的的大韩民国法规。 该《汽车管理法》的”修订案”已于24年2月13日公布。此修订案的背景是，随着现有汽车从内燃机及机械部件为中心向软件为中心的转换，需要修订相关条款以进行完善。本次修订案的核心内容是：必须确保汽车的安全性，使其免受网络攻击和威胁，并须针对可能影响汽车安全的软件建立更新管理制度，也就是说，大家需要为《汽车管理法》修订案中关于网络安全管理系统和软件更新的相关要求做好准备。当然，认证主体是汽车制造商，但合作公司也需要应对相关要求。详细内容将在后续深入探讨。并且，《汽车管理法》修订案的生效时间为：对于新车，从25年8月，也就是本月开始；对于现有车辆，则从27年8月开始实施。接下来将说明《韩国汽车管理法》修订案中关于网络安全管理系统及软件更新的主要条款。 首先是关于网络安全管理系统(CSMS)的内容。《韩国汽车管理法》明确规定，汽车制造商及进口销售商只有在持有CSMS认证的情况下，才能在韩国销售汽车。当然，在CSMS认证被撤销的情况下，也禁止销售汽车。这里，CSMS是Cyber Security Management System的缩写，法规中使用“网络安全管理系统”这一词汇。法规中对CSMS的定义是：指为保护汽车免受网络攻击及威胁，包含管理性、技术性、物理性保护措施在内的综合性管理体系。这里的网络攻击及威胁是指犯罪分子，即黑客的攻击。并且，为了实现汽车CSMS，不仅需要技术要素，还需要组织安全所需的管理性体系，以及对营业场所和生产设施的物理性保护措施。最后，为制造安全汽车，汽车制造商需要为网络安全供应链管理负责，因此制造商只能向合作公司要求建立CSMS。也就是说，合作公司必须具备应对汽车制造商的网络安全管理和网络安全工程要求的能力。 接下来，是关于软件更新的内容。《韩国汽车管理法》规定，当更新涉及安全标准相关功能的软件时，汽车制造商必须在事前向国土交通部通报该更新信息后，才可展开软件更新活动。若未遵守此规定，根据违规情况可能被处以刑事处罚或行政罚款。为此，合作公司必须事先将软件更新对安全标准等影响的分析结果传达给汽车制造商。然后，制造商将基于此结果，审查是否符合相关法规。总结来说，网络安全管理系统(CSMS)需获得认证方可在韩国销售车辆。软件更新则需要向国土部共享更新信息，但并未明确规定需要单独的认证。2. 与UN认证（R155、R156）有何不同？在说明时，会考虑到《韩国汽车管理法》修订案及CSMS认证指南是基于UN R155·R156建立的这一点。该认证分为系统认证和车辆认证两部分。第一，系统认证包括CSMS认证和SUMS认证，但韩国法规仅要求汽车制造商及进口销售商获得CSMS认证。第二，车辆认证是针对在韩国销售的车辆型式实施的认证，认证方式包括VTA认证或自我认证。韩国法规适用自我认证。这里需要注意的是，《汽车管理法》中的车辆认证和系统认证并非互不相干。《汽车管理法》的CSMS认证是要求需获得在韩国销售车辆认证的汽车制造商具备的CSMS，即是针对制造商的网络安全管理系统进行的系统认证。这与ISO 9001、IATF 16949等国际标准的系统认证不同，是针对UN规定及韩国法规要求的CSMS进行的系统认证。特别是，若没有该系统认证，相关的车辆认证也无法进行。再次强调，系统认证即CSMS认证必须先进行，车辆认证才能进行，这一点请大家参考。 为方便起见，我将韩国《汽车管理法》称为‘韩法’，UN R155·156称为‘欧法’。认证机构方面，韩法的认证机构是韩国国土交通部，欧法的认证机构则是UNECE成员国指定的批准机构。CSMS系统认证方面，韩法和欧法均要求事先认证；SUMS系统认证则仅在欧法中要求事先认证。并且，若没有该系统认证，韩法规定无法销售汽车，欧法规定无法获得VTA认证，同样无法销售汽车。若制造商的CSMS或SUMS发生变更，则需重新审查。系统认证的有效期最长为3年，获得认证后每年还需进行事后审查。若违反该法规，系统认证可能被撤销。关于违反法规时的处罚：欧法可能导致相关认证被撤销；韩法则根据违规情况可能被处以刑事处罚或行政罚款。最后，车辆认证方法：欧法规定在向UNECE会员国销售汽车前必须获得VTA认证；韩法则通过自我认证即可销售，但若在已售车辆中发现违规事项，可能被命令停止销售。3. 若已获得UN 认证（ R155,R156）是否可以替代？ 首先说结论，不可以。《韩国汽车管理法》的CSMS认证，只有通过韩国国土交通部审查并颁发的认证书才能被认可。但是，已获得UN Regulation 155 CSMS认证的制造商或销售商，有可能获得国土交通部主管的CSMS认证。这是因为韩国《汽车管理法》及其施行令是基于UN Regulation 155制定的。最终，对于OEM或Tier供应商需要准备的内容是大同小异的，因此只需根据《韩国汽车管理法》进行调整即可。飞斯柯罗已达成网络安全认证咨询大满贯，对相关项目有非常丰富的经验，如需应对《韩国汽车管理法》，请联系飞斯柯罗。4. 想了解韩国汽车管理法网络安全与软件更新方面内容 首先就修订后的《韩国汽车管理法》中关于CSMS的各项条款进行简要说明。⦁ 第30条之3规定，没有CSMS认证则不得制造或销售汽车。(第30条之9, 10, 11, 12 规定了关于CSMS的法规) ⦁ 第30条之9规定，欲进行汽车自我认证的汽车制造商等，必须建立CSMS并获得韩国国土交通部长官的认证；⦁ 第30条之10规定，汽车制造商等必须响应国土交通部提出的关于CSMS建立及运营资料的提交要求；⦁ 第30条之11规定了汽车CSMS认证的撤销标准；⦁ 第30条之12规定，当现场发生与网络攻击及威胁相关的事故时，必须向国土交通部长官申报。⦁ 第81条刑事处罚条款规定，无CSMS认证却销售适用认证的汽车者，可被处以1年以下有期徒刑或1000万韩元以下罚金。 接下来，说明软件更新的相关条款。⦁ 第34条之5规定，更新时必须遵守6项合规事项，必须就涉及汽车安全运行的更新事项事前向国土交通部通报，以及更新需事先通过性能试验代行机构确认：①号，更新后汽车的所有功能必须能正常工作；②号，必须证明更新后汽车仍符合汽车安全标准；③号，要求更新实施过程安全；④号，需要将更新信息传递给汽车用户；⑤号，需要安全保存更新内容和历史记录；⑥号，其他安全、顺畅的更新所需事项，国土交通部令规定的事项。⦁ 第34条之6规定，若国土交通部认为有必要，性能试验代行机构可对制造商的更新内容、方法、管理实际状况进行适当性调查。(此处性能试验代行机构指因国土交通部无法直接进行所有认证审查而指定的代行机构。例如，韩国汽车安全研究院即属此类。)⦁ 第35条第2项规定，禁止任意更改、安装、添加或删除可能影响汽车安全运行的软件。⦁ 第81条刑事处罚条款规定，若违反第34条之5第1项前述更新合规事项中的1号、2号、3号，可被处以1年以下有期徒刑或1000万韩元以下罚金。（即①更新后所有功能正常、②更新后符合安全标准、③更新过程安全）⦁ 第84条行政罚款条款规定，违反更新相关资料提交条款者，可被处以2000万韩元以下罚款；违反第34条之5第1项更新合规事项中4号~6号者，可被处以1000万韩元以下罚款。(④向汽车用户传达更新信息、⑤安全保存更新内容与记录、⑥国土交通部令规定的事项)关于具体要求或评估的具体内容，是由韩国国土交通部、韩国交通安全公团、韩国汽车安全研究院主导制定并应用的，飞斯柯罗也在认证准备或网络安全测试方面进行了合作。5. 需要准备什么，应该怎么准备？ (OEM/Tier) 首先从未获得UN认证的OEM角度进行说明。 OEM需要建立满足ISO/SAE 21434的CSMS，并且该CSMS系统不仅要在开发阶段，还必须在生产阶段、现场维修诊断阶段得到执行。特别是，需要具备TARA以及网络安全测试和有效性确认流程，并为此确保必要的资源。此外，还需建立并运行持续的网络安全监控流程、网络安全事故响应流程以及提供相关事故数据的流程。对OEM而言，最重要的是建立用于网络安全供应链管理的体系。 Tier的准备事项也与OEM类似。首先，为应对OEM的CSMS要求，需建立包含CIA要求的网络安全分布式开发流程。主要由营业部门和设计部门负责。并且，需要建立符合ISO/SAE 21434标准的CSMS，并设立负责网络安全管理及事故响应的专门部门或专职团队。最后，为应对OEM的要求，需提前准备执行TARA的流程及资源，以及为实现TARA结果所要求的安全对策，需要提前准备流程和资源，以确保安全技术应用于产品，并为该产品进行安全测试。对Tier供应商而言，重要的是确保应用于所供应控制器的安全技术，并准备保证其质量的安全测试体系。 最后，对于已获得UN认证的OEM及Tier供应商，需要基于《韩国汽车管理法》及CSMS认证标准，进行现有CSMS的审查及补充的内化工作。并且，提交给韩国国土交通部的成果必须是韩文版，因此需要对成果进行韩文化处理。6. 应对韩国汽车管理法时，控制器软件是否会发生变化？是的，会有变更。并且，我认为需要选择能够灵活应对未来将持续发展的网络安全技术的软件形态和软件开发方案。韩国《汽车管理法》中并没有关于非常具体的方法论说明。但是，查看第2条（定义）中4之4关于“汽车网络安全管理系统”的定义：/ “汽车网络安全管理系统”是指为保护汽车免受汽车网络攻击·威胁，包含管理性·技术性·物理性保护措施在内的综合性管理体系。/为便于理解，我们来看一下UNR155中的内容（参考UNR的原因前面也已说明）。 UNR155的5.1.1列出了车辆制造商为了获得认证必须在车辆上部署的必要措施：(a) 说明不仅需要车辆制造商，还需要与合作公司一起完成；(b) 说明车辆上必须部署安全对策；(c) 说明必须在车辆设计本身中适当实现网络安全措施；(d) 说明车辆必须能够检测和响应网络安全攻击；(e) 对(d)进行了更具体的方法论说明，即需要具备能够检测网络安全攻击并分析该攻击的取证能力，因此还需要Log数据处理能力。从SW角度解读刚才提到的法规内容。最终，需要在车辆中加入保护车辆免受外部攻击以及能够管理车辆中可能发生的网络安全事件的功能，该需求也可以看作是需要应用到控制器级别的安全功能。即我们熟知的 Secure Boot、Secure Storage、Secure Debug、Runtime Tuning Protection、Memory Protection、HSM、OS Hardening、控制器通用安全要求、安全编码、开源漏洞管理等保护控制器本身安全的要求。以及保护车辆与外部、车辆内控制器之间通信安全的 Secure Access、Secure Unlock、SecOC、TLS、IPSec、MACSec、Firewall等，防御车辆免受外部攻击的要求。此外，CAN-IDS、Ethernet-IDS、统一安全日志以及OEM从运营角度建立的vSOC (vehicle Security Operation Center)，是用于检测车辆中可能发生的安全事件并据此制定适当对策的方法。如此多的要求大部分通过软件实现，而且要求还在不断演进，因此需要选择能够更有效、高效应对这些要求的软件形态和软件开发方法论那么哪种软件方法论比较好呢？事实上，在有效开发和管理软件的方法论方面，不仅局限于网络安全角度，而是在汽车软件重要性开始提升很久以前就已经开始推进，并且使用了多种方法。例如像 Autosar、Automotive Grade Linux、Android Automotive、QNX 这样的标准组织或专业企业，不仅如此，OEM自身也在进行此类活动。其他产业领域也早在很久以前就具体推进了有效管理和软件开发的相关活动，其核心关键词——标准化，旨在确保软件开发的便利性和可重用性。在汽车软件领域，是AUTOSAR主导了这项活动，并且可以说是被使用最多的软件平台，AUTOSAR是于2003年由主要的汽车制造商和控制器制造商共同成立的团体，同时也是被称为Automotive Open System Architecture（开放型汽车标准软件架构）的汽车软件标准。7. 一定要使用 AUTOSAR 吗？  不是强制性的。但是，我想回答“现在是不是应该应用呢？” 汽车网络安全重要性增加并最终实现法制化的根本原因在于，随着汽车互联性增加以及车辆电子化，软件的重要性呈爆发性增长。未来的汽车，不，即便是现代的汽车，也正在向C.A.S.E (Connectivity, Autonomous, Sharing, Electrification) 发展，而为了实现这一目标，方法论正在向软件定义汽车(SDV)的范式大转换。高性能车载控制器增加、E&E架构变化、互联化、电动化、SW高度化等变化，不仅影响着汽车制造商，也深刻影响着控制器制造商。随着软件在车辆中所占比重的增加，车辆中发生的缺陷因素，一半以上表现为软件问题。但是，从源头上杜绝此类软件缺陷，在现实中几乎是不可能的。必须通过使包括软件结构在内的控制器系统更加精密化，以及通过严格且有效的反复验证进行测试，以此来加强事前预防，并且在量产之后，可以持续快速响应的SW质量活动也十分必要。 不仅如此，在开发车辆或控制器时，需要遵守的法规和国际标准也在增加。同时具体的要求也在落实。例如今天也提到过的与网络安全管理、软件更新管理相关的法规 UNR155, 156，网络安全工程标准 ISO/SAE 21434，功能安全与SOTIF，以及A-SPICE等，这些都是我们必须熟知并在开发车辆或控制器时需要考虑的内容。而且，现在已成为汽车必备的OTA也必须准备好。正如前面问题中提到的那样，为了应对这些多样且复杂的软件需求和变化，比我们更早开始思考的人们，他们创建的成果就是AUTOSAR，通过这些活动，汽车软件开发及管理效率化开始具体化。如上图所示，通过标准化，在难以应对各种变化的旧软件结构中，实现了开发的便利性、可重用性、模块化，从而优化开发所需的时间和成本，使应对新需求或提高质量具有代表性的方法论，就是AUTOSAR。通过对于AUTOSAR的清晰讲解，我们理解得很透彻。虽然不是强制的，但为了便利性、可重用性、模块化等，建议采用。虽然我刚才说得好像必须应用AUTOSAR一样，但即便如此，我再次回答：“不是强制性的”。理由是控制器的特性、其生命周期、在车辆中的作用和比重、制造商的情况都各不相同，特别是应用AUTOSAR需要一定的费用和努力。考虑到控制器的特性和各种环境因素，来决定是否应用AUTOSAR才是正确的选择。飞斯柯罗不仅拥有网络安全领域的专业能力，还具备与AUTOSAR相关的专业能力。我们开发、量产的控制器中不仅应用了AUTOSAR，我们还与多家控制器制造商开展了AUTOSAR相关的开发项目。若您有相关困扰，请联系我们，我们将全力支持您做出最佳选择。8. 可以自己开发AUTOSAR吗？ 首先，从第一层意义上回答，是的，可以。但是，汽车或控制器制造商通常不会那样做。正如前面提到的，AUTOSAR是称为Automotive Open System Architecture（开放型汽车标准软件架构）的汽车软件标准。并且AUTOSAR是一个团体。该团体定义了为实现开放型汽车标准软件架构所需的标准，并就实现这些标准所需的各种要求进行了定义。如果能充分理解并实现这些内容，当然可以自己开发AUTOSAR。但是，考虑到各种成本和效率等因素，各公司通常专注于自己擅长的领域，并找到与之匹配的角色定位，从而利用AUTOSAR制造控制器，进而制造汽车。 例如：生产控制器中使用的MCU（Microcontroller）等半导体的企业，为了使AUTOSAR能在自家芯片上良好运行，会制作MCAL；根据AUTOSAR标准制作能够运行的BSW和RTE等软件，并制作能更高效管理、生成这些软件的各种工具，则是AUTOSAR Solution供应商的工作；而利用这些AUTOSAR套件，制作适用于控制器的SW Components，换言之即制作应用软件(Application SW)，并执行最终的集成(Integration)，则是控制器开发公司的工作。因此，站在控制器开发者的立场上，考虑到OEM的要求、产品所选MCU的支持情况、有效的工程服务以及优化的成本，选择合适的AUTOSAR解决方案才是正确的方法。飞斯柯罗与主要的AUTOSAR解决方案供应商也保持着紧密的合作关系。如果您在选择哪种解决方案上有困扰，也请联系我们，我们将支持您选择最优方案。9. 应用于AUTOSAR时需要考虑哪些方面？ 应用AUTOSAR时需要考虑的事项主要有：首先是客户的需求。其次是使用哪种MCU，同时成本也需要考虑。此外，还需考虑内部开发能力、日程、熟练度等因素。众所周知，制造车辆需要大量的控制器。OEM为制造车辆，会制作符合目标控制器需求的规格书，提供给合作公司。合作公司在收到需求后，通过分析决定如何实现以满足该需求的方向。在决定方向时，以往只需考虑控制器功能，但如今还必须同时考虑网络安全、功能安全、OTA等附加但必备的要素。通过这些审查，会选择合适的MCU，并决定平台软件。在决定平台软件的过程中，会综合考虑控制器功能的复杂度、可重复使用性、业务的扩展性、OEM的要求、MCU的支持情况、成本等因素做出决定。最近的趋势是很多公司选择AUTOSAR作为平台软件。即使OEM没有要求，考虑到确保产品竞争力、可重复使用性以及扩展性等，选择采用的情况很多。即使选择AUTOSAR，如前所述，也无法自己制作，因此需要选择合适的解决方案。此时需要考虑：该供应商是否已准备好相应的解决方案支持所选MCU？是否已具备满足客户所有需求的功能？工程服务质量如何？费用是否合理？等等。 通常AUTOSAR包含很多功能。在确定使用哪家公司的AUTOSAR之后，还需要确认在AUTOSAR BSW中，我们产品所需的服务和组件是什么，并进行选择，这一过程也是必要的。若购买AUTOSAR，通常Configuration Tool、BSW、RTE会从AUTOSAR解决方案供应商处获得，而AUTOSAR MCAL，有时直接从MCU供应商处获得，有时也会包含在AUTOSAR套件中一并提供。 飞斯柯罗是韩国领先的汽车网络安全专业企业。我们通过为客户量身定制解决方案，根据客户的实际情况和环境，提供务实的技术突破口，解决复杂的技术问题。 从专用的网络安全控制器SGW，到无需更换芯片即可满足法规要求的HSM安全解决方案，再到支持网络安全持续优化的“一站式运营管理平台”——CSMS门户，飞斯柯罗致力于以务实的方式解决行业面临的困境，立志成为基于SDV（软件定义车辆）的未来移动出行产业中的重要参与者。我们的团队由汽车电子控制系统开发专家和白帽黑客组成，具备卓越的专业实力。

正如大家所了解的，以欧洲“UN R155”法规的实施为起点，韩国汽车管理法、中国的“GB 44495-2024”等各国纷纷推动汽车网络安全法制化，并持续加强相关监管。为应对各国汽车网络安全法规，全球整车制造商（OEM）也开始要求Tier方进行控制器网络安全管理。所以，有很多Tier客户对于密钥管理系统（KMS）的构建方法，以及安全解决方案的具体应用方式存在困惑。 将简要介绍一下飞斯柯罗在KMS系统及安全解决方案方面具备的核心能力。首先，我们已成功为OEM及Tier方构建了高度适配汽车环境的KMS系统。同时，自主开发了KMS系统、控制器（ECU）、生产工厂诊断程序三大核心模块，实现了有机协同运作的整车网络安全体系构建。 其次，我们的解决方案具备国际可信度。不仅获得了美国FIPS 140-2加密算法与模块认证，还严格遵循各项国际网络安全标准与法规，持续推进合规性开发。 最后，飞斯柯罗与全球客户及合作伙伴保持紧密协作。目前我们的安全解决方案已应用于8家整车厂的160余种控制器量产项目中，并已实现与8家车规级半导体厂商共计50余款产品的兼容性适配。 在此次的网络研讨会中，我们将基于这些成功案例，为大家分享飞斯柯罗在KMS及网络安全解决方案方面的实战经验与专业洞察。 ■ 问题LIST 1. OEM要求我们应用KMS，为什么需要KMS？ 2. 在构建 KMS 时也要求应用 SecOC，它们之间有什么关联性呢？  3. 想了解 KMS 的构建方法 4. 我想了解一下构建KMS时OEM通常会提出哪些要求 5. 我想了解KMS实际构建的案例 6. 引入 KMS 会不会对控制器的生产造成问题？ 7. 想了解 OEM 通常要求的典型安全功能 8. 理解和分析 OEM 的安全需求很困难 9. 实现安全功能后，不知道该如何制作产出物 ■ 视频 Ver. ■ 文本 Ver. 1. OEM要求我们应用KMS，为什么需要KMS？ KMS是“Key Management System”（密钥管理系统）的缩写，在IT产业中应用广泛。比如说：聊天软件中的消息加密与解密，或是金融交易中的用户身份验证证书，其实都是KMS的应用实例。 近年来，汽车产业中对KMS的要求也逐渐增加。KMS是一套安全地发行与管理密钥的系统， 它会向用户分发加密密钥与解密密钥。数据发送端通过加密密钥进行信息加密，而接收端则使用对应的解密密钥来还原信息内容。 那么接下来我们继续探讨一下：为什么在汽车行业，对KMS的需求会不断上升呢？随着汽车的“连接功能“不断增强，软件驱动的开发趋势日益明显，汽车正在面临越来越多的网络安全威胁。例如，黑客可能通过入侵ECU（电子控制单元），篡改固件或植入恶意代码发起攻击。如今，汽车网络安全已在多个国家被纳入法律监管。包括欧洲的 UN R155、韩国的汽车管理法，中国也将在2026年起正式实施强制标准 GB 44495-2024（汽车网络安全国家标准）。在这样的趋势下，这些网络安全法规是为了加强安全性，OEM要求各级Tier应用KMS。KMS可以针对数十万、甚至上百万辆车，安全地管理每台车的“独立密钥”与“认证证书”。未来，连同负责ECU生产的合作伙伴（Tier）也将自行建设并运营KMS，以整体提升汽车产业链的网络安全防御能力。 KMS是用于为车辆及ECU发放和管理密钥的系统。通过KMS，可以建立起仅授权用户才能访问车辆或ECU的安全体系。虽然不同OEM对KMS的具体要求不尽相同，但Secure Debug、Secure Flash、SecOC 是当前应用最为广泛的三大核心功能。简单来说：Secure Debug 是一种利用专属密码访问ECU的安全机制Secure Flash是确保仅使用经过认证的固件的功能SecOC则是通过密钥来验证消息完整性的功能这些安全功能都可以通过KMS发行的密钥和认证书来实现，即使发生网络安全事件，也可以通过KMS更换出厂后车辆与ECU的密钥，从而持续维护整车的网络安全性。2. 在构建 KMS 时也要求应用 SecOC，它们之间有什么关联性呢？ SecOC是为确保ECU之间通信消息的完整性和可信性而设计的安全功能。在车载网络中进行广播通信时，需要验证是哪一个ECU在何时发出的指令、又是哪一个ECU在何时作出回应。常见的黑客攻击方式包括消息篡改（Tampering）与重放攻击（Replay Attack）。SecOC为防止这些攻击，会在请求和响应消息中包含MAC值和FV值，而生成这些MAC值所需的密钥，则是由KMS提供与管理的。即使使用了SecOC，长时间使用同一密钥也有可能被利用，通过KMS的密钥再发行功能，可以控制MAC值。目前OEM普遍要求系统必须具备密钥可随时更换的能力。3. 想了解 KMS 的构建方法 在金融和IT产业中，KMS一般部署在互联网或企业网络环境的服务器端。但在汽车行业中，由于KMS必须从OEM需求分析、服务器间的联动，到ECU的密钥注入与安全功能实现，因此所需的技术体系更为复杂，涵盖了IT技术、信息安全技术，以及嵌入式系统能力。以典型的OEM需求为例：OEM的主服务器需要与Tier的KMS服务器建立联动连接，只有通过认证的KMS系统，才被允许接收密钥。在车辆生产线环节，会通过识别MCU的唯一ID，由KMS生成绑定该ID的密钥。然后通过ECU的调试接口，将密钥注入到MCU中的安全模块（HSM）内。这一过程就是KMS在汽车生产中的全流程应用。 在KMS构建过程中，系统的运营方式分为“统一运营型”与“本地化部署型”。KMS 的建设必须遵循各OEM的具体要求。其中，比较典型的两种KMS运营模式这两者的关键区别，在于KMS系统部署的位置是否因应生产地而分布。统合运营模式是指在中央设施中部署KMS，然后将密钥远程分发到各个生产基地。这种方式要求对KMS部署地点具备物理安全性但如果已有合规的安保设施，部署KMS可以节省时间与成本。但如果要从中央服务器向多个生产基地分发密钥，就需要提前规划KMS服务器的规格。相较之下，本地运营模式是指在每个生产基地分别建设一套KMS系统，这种方式的优点是网络结构更简单，数据传输路径更短，但缺点是：每个生产地都需具备符合标准的安保设施、配备专业运维人员，如果生产地分布较多，整体运营成本也会相应提高。4. 我想了解一下构建KMS时OEM通常会提出哪些要求 关于KMS的要求，其实每家OEM都有很大不同，所以很难用一句话来统一定义。有些OEM会提供非常详细的规范，从硬件规格到密钥注入流程都清晰定义；也有OEM只是大致要求要引入一个可以管理密钥或证书的系统。此外，Secure Debug、Secure Flash、SecOC等安全功能的应用范围与实现方式也各不相同。因此，能否在满足OEM要求的前提下，结合Tier自身的实际情况，制定出最优解决方案，是决定KMS是否成功部署的关键。飞斯柯罗已经有多个成功的KMS项目案例。5. 我想了解KMS实际构建的案例 在此分享一个飞斯柯罗为Tier客户成功构建KMS系统的案例。该客户并不希望针对每一家OEM单独构建KMS，而是希望通过一个统一的KMS系统来应对多个OEM的不同需求。因此，飞斯柯罗在设计系统时，充分考虑了客户从OEM处收到的技术要求、以及他们未来业务的扩展计划，构建了一个兼顾灵活性与扩展性的KMS系统，便于未来应对新增OEM或新增控制器项目。客户可以自主注册OEM与控制器并进行映射管理，通过一次系统构建，就能够满足后续多个项目中可能出现的KMS需求。此外，我们还引入了项目级、控制器级的权限管理机制，确保只有被授权的人员才能访问与操作相关功能模块，显著提升了系统的安全性。通过业务流程的系统化与自动化，极大提升了工作效率与操作便利性为了满足OEM对安全功能的不同需求。飞斯柯罗实现了可根据项目选择性地应用如Secure Debug、Secure Flash等OEM需求的机制。提供了可以根据OEM要求的安全功能，如使用的加密算法、电子签名类型等进行选择的功能。 近年来，越来越多的OEM开始强调要求导入KMS系统，很多Tier企业的负责人也在为如何应对这些要求而苦恼。建议与其找只会“被动对接需求”的厂商，不如选择能够主动分析OEM需求、结合自身现状提出专业建议的合作伙伴。如果能找到一家能与OEM及内部相关部门积极沟通、并能提前提出适配客户的安全概念与政策的合作企业，对项目的长期推进会更加有利。飞斯柯罗确实积累了多个成功服务OEM与Tier企业的KMS建设经验，我们始终致力于为客户量身打造最合适的KMS系统，并确保其稳定落地。6. 引入 KMS 会不会对控制器的生产造成问题？ KMS作为一道新增的工序，大家可能会担心它带来的副作用（Side Effect）。例如，服务器故障或网络中断时，是否会导致生产线停滞？流程增加是否会影响整体生产效率？后期生产线扩充时，是否会大幅增加建设成本？这些都是合理的担忧。特别是当客户的生产基地在海外的情况下，这些问题会更加敏感。因此建议大家一定要选择能够综合考虑客户实际情况与OEM要求、并具备风险控制设计能力的合作伙伴。 飞斯柯罗曾为客户构建过专门优化以降低副作用的KMS架构，我们聚焦于最小化生产时间的增加，以及最小化因通信故障导致的生产中断，并从中得出了与生产线高度整合的最佳方案。  最终，我们采用了如上图所示的方式构建KMS：KMS服务器会提前生成大量密钥，并在预定时间发送一定数量的密钥。例如，在生产线的空闲时间内，EOL（End of Line）流程程序会与服务器通信并接收密钥。一旦生产重新开始，EOL流程程序就可以使用已接收的密钥继续注入作业。 此结构并非在需要时才生产密钥，也无需每次注入时都与服务器通信，因此可以最大程度减少每个生产单元的时间增加。此外，由于生产线从服务器预先获取了充足的密钥，即便出现通信问题，也能较好地避免副作用。再加上是集中式服务器，在扩展生产线时无需新增服务器，因此还可节省扩展成本。借助KMS不仅可以实现安全性，还能同时兼顾效率、稳定性与可扩展性！像飞斯柯罗这样，在构建KMS时就提前规划如何最小化副作用的企业，无疑是值得信赖的合作伙伴。7. 想了解 OEM 通常要求的典型安全功能 整车制造商，即OEM所要求的安全功能，是为了保障车辆的安全性、防止黑客攻击、保护用户隐私等目的，因此包含多项技术性要求。首先是Secure Boot（安全启动）。Secure Boot是在车辆启动过程中验证系统完整性后再进行启动的动作，可以防止恶意软件或篡改过的固件在控制器中被执行。例如，只加载带有电子签名的固件，并阻止未签名的固件启动，从而防止车辆系统遭到污染或被黑客攻击。接着是Run-Time Tuning Protection（运行时调试保护）。Secure Boot适用于启动过程的安全功能，而Run-Time Tuning Protection是在控制器系统运行中起作用的功能，简称RTP。RTP通过实时检测与应用程序或控制器运行相关的重要数据区域的完整性，防止控制器运行时被外部攻击篡改数据，保障系统安全性和可预测的运行。接下来是Secure Debug（安全调试）。它是限制对像JTAG这类调试接口的访问，指量产后的产品通过调试端口被外部访问控制器内部的敏感信息。通过禁用调试端口，或限制仅认证用户才能进入调试模式，可以防止攻击者掌握系统漏洞或植入恶意程序。通常使用密码或 Challenge-Response（挑战应答）方式进行身份验证，有些OEM还要求每个控制器单独配置唯一密码，以提升安全等级。然后是Access Control（访问控制）。即对车辆系统的访问权限进行管理与限制。确保只有特定用户或进程才能访问敏感数据或系统。可以保护车辆的关键组成部分和数据，防止未经认证的用户访问系统。代表性示例有UDS 0x27（安全访问）服务，DAC（自主访问控制）、MAC（强制访问控制）等策略。接下来，Secure Flash是用于安全更新车辆闪存中软件或固件的功能。在固件更新过程中使用加密通信，并验证新固件的电子签名，仅允许已授权的固件重新编程。还可以通过控制对闪存的写入权限，防止外部篡改或插入恶意代码。最后是Secure Storage，指的是用于保护安全功能所需加密资产的安全区域。将车辆内部的重要数据（如密钥、密码、证书等）加密保护，防止外部攻击者提取或篡改数据。通常会搭配使用HSM（硬件安全模块）或Memory Protection等要求。此外，OEM还会要求SecOC（安全车载通信）、FOTA（远程固件更新）、安全编码规范、静态/动态验证等。这些安全功能对于保护车辆硬件和软件系统，防止外部攻击与未授权访问是必不可少的。如果这些功能一旦失效，就有可能让车辆暴露在攻击风险中，导致被恶意控制、数据泄露，甚至被远程操控等严重后果。为了从源头防御这些网络威胁，建议大家可以考虑引入飞斯柯罗的专业汽车网络安全解决方案。8. 理解和分析 OEM 的安全需求很困难  由于每家OEM在制定安全规范时都有各自的标准、策略和术语，确实让不少人感到无从下手。比如说，看似统一的安全功能如 Secure Boot 或 Secure Flash，但各家OEM可能会对此作出不同的定义，或附加额外的要求。下面以OEM的实际安全要求为例，总结几条分析技巧：第一，区分安全要求中的R&R（角色与责任）是非常关键的。第二，通过各项要求之间的上下文关系，可以推导出需要实现的具体条目。第三，凡是涉及使用加密密钥的安全要求，要明确以下几点：谁负责生成和管理密钥？密钥在哪个阶段注入？密钥是否支持更新？例如，当OEM提出需要Secure Flash功能时，控制器、供应商EoL、KMS或OEM自身，各自适用的要求可能都不一样。 在此将引用 M 公司关于 Secure Flashing 的一部分安全要求进行说明。第1条要求：“KMS必须保存用于生成 Secure Flashing 的电子签名所需的关键加密数据。”这一条写得非常明确，说明了 KMS 的职责。可以从中看出，KMS 既是生成 Secure Flash 用电子签名的主体，也是管理相关数据的主体。第2条要求：“只有当签名证书所对应的角色具有对闪存逻辑块的签名权限时，该证书才应被认可。”与第1条不同，第2条并未直接说明执行主体是谁。但可以结合第1条判断：电子签名的生成者是KMS，因此这条要求主要适用于KMS与其使用者之间的权限关系。也就是说，KMS 用户必须持有具有签名权限的认证角色证书，如果没有相应角色，就无法为新的固件生成签名。第3条要求：“KMS在进行电子签名时必须使用 RSA_SSA_PSS 算法。”这一条对 KMS 在生成签名时所用的算法进行了明确指定。从中可以推断，控制器开发人员也必须提供对应的RSA签名验证功能，以便在 UDS 协议下完成固件的安全烧录与验证。接下来是第4条要求：“MES系统必须确保设备在出厂前配有系列密钥。”如果KMS由供应商（Supplier）负责运营，那么这条中所说的“系列密钥”应该就是由供应商KMS生成的密钥。因此，这条要求其实适用于供应商的生产流程，而非OEM的总装工艺。那么，为了满足这条要求，每个相关角色需要实现哪些功能呢？首先，在供应商的 EoL（End of Line）阶段，KMS 需要与 MES 进行联动，将 RSA 公钥发送给 MES 系统。MES 再将密钥传送给控制器，最后控制器需从 MES 接收 RSA 公钥并进行编程。那么，对于控制器开发人员来说，这里就可能引出一系列新的问题：比如，“公钥应该存储在控制器的哪个区域？”，“是否可以硬编码到 Pflash 中？”，或者“是否需要存入 HSM 中？”再比如，“如何从工艺系统中接收该RSA公钥？”，“能否通过UDS进行传输？”，“接收时只保证数据完整性即可？还是需要加密？”，“如果要加密，用什么密钥、什么算法加密？”这样就会不断产生连锁问题。那面对这类连锁式问题，该如何理清楚它们之间的逻辑关系？ 可以参考第 5 条要求：“ECU必须将 HSM 用作 Secure Flashing 的信任根（Trust Anchor）。”这一要求表明，只要将 RSA 公钥保存于 HSM 中，并通过 HSM 验证电子签名，就能满足要求。第 4 条要求所产生的第一个问题，在第 5 条要求中得到了明确的回答。就像这样，在分析 OEM 的安全要求时，需要进行综合理解，进而识别出需要在哪些系统上实现哪些具体功能。再补充几个实用的小技巧。第四个，即便是“相同的安全功能”，其实现方式也可能存在差异。以下是L公司关于 Secure Software Update（安全软件更新）的一部分安全要求节选：第 1 条要求，“软件镜像必须使用 ECDSA 签名。”第 2 条要求，“为了获取镜像哈希的签名，需提供访问OEM代码签名服务器的代码签名客户端（code signing client）。”前面提到的 M 公司 Secure Flashing 要求中，重新编程时要求使用 RSA，而 L 公司则要求软件更新时使用 ECDSA 签名。此外，从“使用 OEM code-sign server “这一表述可以推断出，L公司采用的是OEM自行运营签名服务器并集中管理密钥的机制。因此，在这种情况下，可以由 OEM 在其 EoL 阶段直接编程 ECC 公钥，也可以从 OEM 获取用于生产的密钥，在供应商 EoL 阶段进行编程来满足要求。 第五个提示是，针对 Secure Boot 或 RTP 这样要求固件完整性验证的条目，需要明确“验证对象“。如果 OEM 要求 Root of Trust（信任根），但控制器又面临启动时间限制，那么可以适当结合使用 Secure Boot 与 RTP 功能，在启动时验证部分对象，运行时再验证其他对象，这也是一种方法。第六个提示是，对于像 SecOC 这类要求通信安全的条目，需要明确“通信对象“和”保护对象“，也就是需要保护的消息。特别是 SecOC 一般基于对称密钥的安全机制，因此需要掌握当前开发中的控制器与哪些控制器通信、需要保护哪些消息、密钥是否为控制器唯一、是否使用通用密钥、Freshness Value（防重放机制）是否有专门的控制器管理等。 虽然各 OEM 所用术语可能不同，但基本的安全要求大体相似。只要能灵活运用以上介绍的方法，准确解读术语，理清职责分工，明确实现路径，就能更高效地应对OEM的安全要求。9. 实现安全功能后，不知道该如何制作产出物 如果准确分析了要求，那么编写产出物并不困难。产出物虽然是技术性的文档，但要用明确且易于理解的语言撰写。此外，要确保从安全要求、各安全功能的实现、验证过程到变更内容等整体可追溯性。必须将每项要求如何被解决的过程记录成文档，并明确指出已完成验证与改进。而且在安全要求、功能实现、验证过程中若有变更，必须通过版本管理将其记录在文档中，详细记录“何时、何事、为何”发生变化。 那么控制器合作公司在网络安全方面需要提交哪些正式文档呢？大致可以归纳为 4 类文档：1. 安全需求规格说明书：分析客户的安全要求，并提取出满足该要求所需的安全功能。例如身份认证、数据加密、访问控制、数据完整性验证等必要的安全功能。若有不明确之处，必须加以确认，并确保要求与实际实现一致。2. 安全功能详细设计书：在设计阶段，明确各安全元素如何在系统中交互。例如定义需要加密的数据，并设计处理这些数据的方法。3. 安全验证计划与结果报告：为了验证安全功能是否正常工作，需要进行功能单元测试和集成验证测试。记录测试所用的环境，并检查测试过程中是否存在安全漏洞，确认是否满足要求，将测试结果详细记录以完成验证。此时可以使用自动化安全检查工具或渗透测试工具。4. 风险评估与应对措施文档：实现安全功能后，评估残留风险并制定应对措施。必要时可追加安全补丁或引入系统监控工具。飞斯柯罗会在项目完成前一直积极协助客户满足 OEM 的安全要求。如果您对汽车安全解决方案及产出物有任何疑问，欢迎联系飞斯柯罗！ 飞斯柯罗是韩国领先的汽车网络安全专业企业。我们通过为客户量身定制解决方案，根据客户的实际情况和环境，提供务实的技术突破口，解决复杂的技术问题。 从专用的网络安全控制器SGW，到无需更换芯片即可满足法规要求的HSM安全解决方案，再到支持网络安全持续优化的“一站式运营管理平台”——CSMS门户，飞斯柯罗致力于以务实的方式解决行业面临的困境，立志成为基于SDV（软件定义车辆）的未来移动出行产业中的重要参与者。我们的团队由汽车电子控制系统开发专家和白帽黑客组成，具备卓越的专业实力。

在2022年，欧洲率先实施了与汽车网络安全相关的法规，并且这一措施已扩展到多个国家。值得注意的是，中国也于去年8月发布了关于汽车网络安全的国家标准（GB）。并计划于2026年正式实施。为了有效应对这一即将生效的标准，深入理解并提前分析欧洲先行的联合国法规显得尤为重要。特别是，理解并掌握具体细则的“汽车网络安全工程国际标准”ISO/SAE 21434是必不可少的。 飞斯柯罗拥有国际汽车网络安全四大认证的成功案例，分别是CSMS、ISO/SAE 21434、VTA和SUMS。飞斯柯罗自主开发的安全解决方案，获得了美国FIPS 140-2加密算法和模块认证，具有国际可靠性。这一解决方案已成功应用于8家整车制造商的160多个控制单元。此外，飞斯柯罗的解决方案兼容全球8家汽车半导体制造商的50多种车型，并与Vector、ETAS、Electrobit等全球AUTOSAR供应商保持密切合作。 此次的网络研讨会将结合我们在ISO/SAE 21434的成功经验，重点介绍面向实际操作人员的网络安全解决方案和工程技术。 ■ 问题LIST 1. 每个OEM的网络安全规格应该如何分析？ 2. 针对哪些控制器设定安全等级，应该应用哪些安全功能？ 3. 在现有开发的控制器上应用新的网络安全时，是否必须更换AUTOSAR解决方案或半导体芯片？ 4. OEM要求的安全功能有哪些？ 5. 没有HSM的情况下，是否可以应用安全解决方案？ 6. 接收到的安全解决方案的"部署过程"是怎样的？ 7. 网络安全解决方案本身是如何验证的？ 8. 在量产应用网络安全功能之后，应该如何管理汽车安全？ ■ 视频 Ver. ■ 文本 Ver. 1. 每个OEM的网络安全规格应该如何分析？ 网络安全应对策略，也可以称为安全解决方案、安全对策（Control）或安全需求。主要有两个目的：一是保护内容，二是保护处理内容的系统。为了帮助大家更好地理解，举个例子，大家熟悉的Netflix也会制定安全应对策略，这时候同样会从两个角度来应用。一个是保护Netflix通过互联网传播的内容本身的策略，例如应用Widevine等DRM解决方案；另一个是保护播放这些内容的播放器设备免受外部攻击。从汽车的角度来看，类似的概念也适用。保护车内/外传输的数据，比如CAN通信数据、控制器的固件镜像等；同时保护处理这些数据的车载控制器。最终，所有OEM都会从这两个角度来制定安全需求和规格。记住这一点，您在分析OEM的需求时，面对稍有不同的术语、短语或项目时，会更有帮助。 例如，像Secure Flash、Secure Access这样的诊断相关需求，是为了保护内容而需要的；而Secure Boot、Secure Debug等，是为了保护控制器本身而需要的需求。通过理解各项需求的目的，分析时我们可以更清楚地知道，如何采取措施来应对，因此能够帮助制定有效的安全需求应对策略。 不过，通常OEM发布的安全规格是没有区分控制器的，这也导致了一些客户在应对时遇到困难。 因此，了解我们所开发的控制器是否符合要求，并在此基础上区分出需要反映的需求和不需要反映的需求后，再通过与OEM的协商确定，这一点非常重要。毕竟，这一活动会影响到开发周期、资源、控制器材料费用等方面，因此，必须与OEM进行事先的协商，这一点务必要记住。 2. 针对哪些控制器设定安全等级，应该应用哪些安全功能？ 我们飞斯柯罗与OEM合作，曾经参与过确定控制器安全等级的工作，也为许多OEM应用了他们要求的安全功能。通过这些经验，我们了解到，确定控制器安全等级的标准在不同的OEM之间略有不同。但普遍来说，通常会参考ISO/SAE 21434标准中，区分与网络安全相关的控制器的方法来做出决定。首先 ，根据以下标准来划分是否为安全控制器：⦁ 是否为电气电子控制器, ⦁ 是否与安全相关, ⦁ 是否收集和处理驾驶员或乘客的信息、车辆位置等信息；⦁ 是否为网络基础控制器，换句话说，是否与车辆内部网络连接，是否存在外部通信接口，是否与无线通信的传感器或执行器连接。通过这些标准，经过TARA(威胁分析与风险评估)过程，安全等级最终会确定。那么，哪些控制器会获得最高的安全等级呢？虽然可能存在偏差，但从大致框架来看，首先，如果控制器具有与外部直接接触的通信接口，如OBD-II、Telematics、WIFI、Bluetooth、USB等，那么它将获得最高的安全等级。接下来，属于第二等级的是那些直接连接到车辆内部网络并对车辆行驶或安全产生直接影响的控制器。如果是连接到车辆内部网络，但不直接影响行驶或安全的控制器，则安全等级较低。安全功能是根据已确定的安全等级和控制器具备的功能来决定的。通常共同应用的功能包括与诊断相关的功能，例如Secure Access、Secure Flash、Secure Unlock等。而保护控制器系统的安全功能包括Secure Boot、Secure Debug、Secure Storage、Runtime Tuning Protection、Memory Protection等。在实现这些功能时，通常会要求使用硬件安全模块（HSM）。 3. 在现有开发的控制器上应用新的网络安全时，是否必须更换AUTOSAR解决方案或半导体芯片？ 根据联合国的网络安全和软件更新相关法规，从2024年7月起，所有在欧洲生产的车辆将需要符合这些要求。同样，参考联合国规定制定的中国的GB标准44495-2024和44496-2024也将在2026年1月开始适用于新车，而在2028年1月开始适用于所有车辆。根据UN法规，对于已开发的控制器，确实需要新增网络安全功能。然而，如果所使用的软件平台（如AUTOSAR等）供应商或半导体芯片制造商不支持这些网络安全功能，那么就不可避免地需要进行新的开发。由于新开发会涉及额外的开发周期和成本，可能会带来一些困难。在这种情况下，建议您考虑软件平台供应商和半导体芯片制造商以外的企业提供安全解决方案。如果找到：⦁ 拥有自主安全解决方案⦁ 拥有汽车安全相关专业人才和团队⦁ 并且具有为各种软件平台和半导体芯片进行解决方案移植经验的公司那么就可以在不更换AUTOSAR解决方案或半导体芯片的情况下，成功地将网络安全功能应用于现有控制器。那么，哪些公司能够满足这些所有要求呢？没错，正是飞斯柯罗。飞斯柯罗不仅与全球软件平台供应商合作过，还与车辆用半导体芯片制造商合作过，参与了多个项目。飞斯柯罗的安全解决方案可以直接应用到已开发的控制器上，从而有效节省新开发的投资成本，并缩短开发和验证所需的时间，带来显著的效益。4. OEM要求的安全功能有哪些？ 分析OEM的安全需求时，主要可以分为保护控制器内外通信数据的需求和保护控制器本身的需求。控制器数据保护需求包括诊断通信的Secure Access、Secure Flash等要求，以及CAN/Ethernet通信中的Secure Onboard Communication、TLS安全要求。控制器保护需求可以从防止固件篡改和检测篡改两个角度进行分析。在防止固件篡改方面，常见的功能包括保护MCU内存的Memory Protection功能，以及阻止外部调试接口的Secure Debug功能。而在应用了Linux操作系统的控制器中，还包括具有访问控制功能的操作系统硬化需求，如DAC/MAC。在固件篡改检测方面，涉及到检测引导加载程序完整性的Secure Boot功能，以及在控制器应用程序运行期间验证固件完整性的Run-time Tuning Protection需求。 从密码学安全技术的角度来看，常见的技术包括AES-128/256的加解密、AES-CMAC、SHA2 HASH等消息认证码方式，以及基于RSA的PKCSv1.5、v2.2，基于ECC的ECDSA等签名验证方式。此外，还要求X.509证书管理、NIST SP 800-90B、BSI AIS 31标准的随机数生成方式等。特别是OEM要求的安全技术，通常会包括利用椭圆曲线的ECDSA签名验证方式的Secure Flash功能，以及不仅仅是Seed & Key认证方式，而是通过验证诊断消息本身的完整性，采用基于消息的Secure Access等更为加强的安全技术。我们飞斯柯罗的安全解决方案应用了多种安全技术，能够主动应对OEM的安全需求。5. 没有HSM的情况下，是否可以应用安全解决方案？ 首先从结论来说，是可以的。对于没有HSM的控制器，可能会有客户在考虑是否需要更换为带有HSM硬件核心的芯片。更换芯片时，可能会担心额外的开发周期和成本。 飞斯柯罗提供的安全解决方案可以分为四种类型：诊断安全解决方案、vHSM解决方案、HSM解决方案和HSE解决方案。  “诊断安全解决方案”即使没有HSM，也能提供诊断通信保护所需的必备功能，如Secure Access和Secure Flash。 “vHSM解决方案”是一种将HSM硬件核心以软件方式虚拟化的安全解决方案，能够实现与HSM相当的安全功能。“vHSM解决方案”所提供的安全功能包括AES-128 加密/解密、 AES-CMAC, SHA2 消息认证码、 RSA PKCSv1.5, v2.2, X.509 证书管理、符合NIST SP 800-90B标准的随机数生成，以及利用MCU内的数据闪存和MPU功能的Secure Storage功能。如果将飞斯柯罗的vHSM解决方案应用于没有HSM硬件核心的现有量产车控制器， 它的优势在于无需更改现有控制器硬件，这不仅能够显著缩短开发周期，还能在应用HSM安全解决方案时有效降低成本。6. 接收到的安全解决方案的"部署过程"是怎样的？ 首先，控制器开发商需要与OEM协商确定需要应用的安全规范和安全等级。协商完成后，飞斯柯罗将开发针对控制器需要应用的安全规范的安全解决方案，并将其传递给合作伙伴。根据安全解决方案的种类，集成过程可分为vHSM解决方案、HSM解决方案·HSE解决方案两种形式。诊断安全和vHSM解决方案需要使用控制器MCU内的数据闪存、MPU、定时器等硬件资源，因此，控制器开发商可能需要实现相应的HAL API。飞斯柯罗将提供实现HAL API所需的详细指南手册和验证库。完成HAL API的实现和验证后，就可以像HSM解决方案·HSE解决方案的集成过程一样，利用部署的安全解决方案来实现OEM的安全要求。飞斯柯罗的安全解决方案仅提供为OEM安全需求定制的必要功能，旨在帮助控制器开发商更轻松地集成安全解决方案并实现规格。此外，我们还提供了详细的指南手册，说明安全解决方案提供的功能及其应用示例，并在开发过程中提供技术支持。关于安全解决方案应用时是否会影响现有控制器功能，有些人感到担忧。首先，关于诊断安全解决方案，只有在UDS诊断通信和重新编程等特定环境下，诊断设备连接时才会起作用，因此它对控制器的基本操作没有影响。对于没有硬件安全核心的MCU应用的vHSM解决方案，由于安全解决方案需要与HOST CPU共享资源，物理上可能会有所影响，但我们已经尽量设计安全解决方案以减少对控制器基本操作的影响，并且它已经在160多种量产控制器上验证过，证明是安全的解决方案。最后，对于具有硬件安全核心的MCU，如HSM或HSE，启用Secure Boot功能后，HOST引导加载程序启动时间将增加约10毫秒，除此之外，对基本操作几乎没有影响。7. 网络安全解决方案本身是如何验证的？ 目前即使我们开发了强大的黑客防御措施，或者说网络安全解决方案，黑客技术依然在不断发展，因此可以说没有100%安全的网络安全解决方案。不仅是我，许多网络安全专家也持有类似的看法。因此，在UNR 155、GB 44495-2024等汽车网络安全法规中也要求在车辆发布后，能够应对可能发生的网络安全事件，并建立相应的组织和程序体系，并要求进行认证。这就是CSMS认证。这并不意味着可以随便开发网络安全解决方案。法律要求网络安全解决方案必须使用国际上公认的加密算法标准，并且必须证明其已按照这些标准使用。飞斯柯罗的安全解决方案——vHSM解决方案，包含了通过美国国家机构NIST认证的FIPS 140-2安全模块，值得大家信赖。此外，这一解决方案已应用于160多种控制器，并推动了量产，因此它的稳定性得到了保障。但是，安全事件是持续进化和发展的。正如上面所说，即使应用了可靠的安全解决方案来保护控制器，安全事件仍然可能发生，因此我们需要持续监控并制定应对措施。这种监控活动需要持续进行，因此通常会引入操作系统。我们称这些系统为SIEM（Security Information & Event Management系统）或SOC（Security Operation Center，安全运营中心）。飞斯柯罗已经为汽车OEM提供了这一系列与安全相关的操作系统，通过这些系统，我们帮助客户获得了UNR 155相关的CSMS认证和UNR 156相关的SUMS认证，并推动了VTA的获得。不仅是OEM，预计今后包括Tier在内，也会越来越具体地被要求引入能够有效管理此类安全事件的系统。8. 在量产应用网络安全功能之后，应该如何管理汽车安全？ 总的来说，不仅是客户，供应合作伙伴也需要建立并运营一个紧密的安全管理体系。具体来说，通过收集与网络安全相关的信息，来检测安全事件。检测到的安全事件会根据漏洞管理流程进行评估。在漏洞管理流程中，我们参考“TARA方法论”，分析已识别的安全漏洞并评估风险，进而决定处理方案。然后，跟踪和管理在整个车辆生命周期中识别出的漏洞处理情况。这些评估后的安全事件会根据事故响应流程进行缓解措施的实施。制定事故响应计划，并执行如安全补丁更新等实施措施。飞斯柯罗曾为7款乘用车车型和2款商用卡车车型的整车制造商，成功构建并运营了“网络安全监控及事件响应IT基础设施”。飞斯柯罗不仅自身的安全解决方案已具备高度可靠性，并且，我们还拥有刚才提到的这类“IT基础设施系统”。通过这样的系统，我们可以为客户持续稳定地提供安全监控服务和最新安全补丁等运维支持。基于这些丰富的实战经验，我们进一步开发了将 IT 基础设施高度集成并产品化的 CSMS 门户平台。这款平台预计将于6月发布，届时也欢迎大家多多关注！如果您在直接应对OEM安全需求方面有困难，或者在汽车网络安全相关的专业人员和组织运营上遇到挑战，或许可以通过与飞斯柯罗合作来解决。 飞斯柯罗是韩国领先的汽车网络安全专业企业。我们通过为客户量身定制解决方案，根据客户的实际情况和环境，提供务实的技术突破口，解决复杂的技术问题。 从专用的网络安全控制器SGW，到无需更换芯片即可满足法规要求的HSM安全解决方案，再到支持网络安全持续优化的“一站式运营管理平台”——CSMS门户，飞斯柯罗致力于以务实的方式解决行业面临的困境，立志成为基于SDV（软件定义车辆）的未来移动出行产业中的重要参与者。我们的团队由汽车电子控制系统开发专家和白帽黑客组成，具备卓越的专业实力。

近年来，汽车网络安全已成为全球汽车行业面临的主要挑战之一。为积极应对这一问题，欧洲于2022年率先实施了相关法规，并引领了全球汽车网络安全的合规进程。24年8月，中国也发布了关于汽车网络安全的国家标准（GB），该标准将于2026年正式实施。为了成功应对这一挑战，对欧洲率先推进的联合国法规进行深入了解和前期分析将带来极大的帮助。同时，理解提供具体指导的“汽车网络安全工程国际标准”——ISO/SAE 21434，也是必不可少的。 飞斯柯罗在国际汽车网络安全的四大认证领域，即CSMS、ISO/SAE 21434、VTA和SUMS，都拥有成功案例。基于此，我们为了解决控制器开发商（Tier）的困扰，特别准备了此次研讨会。作为一家专注于网络安全的企业，飞斯柯罗经常收到相关的咨询问题。此次研讨会将围绕我们从供应链厂商那里“最常被问到”的7个核心网络安全问题展开。我们将探讨以下内容：全球OEM对Tier的要求、TARA的执行主体、CSMS的应对策略、网络安全产出物编写时现有成果的可复用性及注意事项、安全漏洞管理方案、网络安全的后续应对工作，以及Tier是否需要获得网络安全相关认证等。 ■ 问题LIST 1. 全球OEM对Tier提出的网络安全相关要求有哪些？如果要求内容复杂或模糊，应该如何解读呢？ 2. TARA不是应该由OEM来执行吗？ 3. 我不知道应该从哪里开始应对CSMS 4. 在编写网络安全交付物时，我想复用现有的成果，需要一些建议 5. 希望能获得关于安全漏洞管理方案的建议 6. 由于缺乏网络安全背景知识，每次与OEM开会后，后续的应对工作都会增加 7. Tier也需要获得网络安全相关认证吗？ ■ 视频 Ver. ■ 文本Ver. 1. 全球OEM对Tier提出的网络安全相关要求有哪些？如果要求内容复杂或模糊，应该如何解读呢？ 在当前汽车行业快速发展的背景下，网络安全已成为整车制造商（OEM）和供应商（Tier）之间合作的重要组成部分。为确保车辆在整个生命周期内的网络安全性，OEM对Tier提出了多项安全相关要求。尽管不同OEM的具体要求存在差异，但通常涉及以下几个方面。 项目（控制器）层级的TARA 在项目初期，OEM通常会在整车层级执行TARA（威胁分析与风险评估），以确定各个项目的网络安全目标和需求。对于对网络安全要求较高的OEM，有时还会要求Tier在控制器（ECU）层级执行TARA，以实现双向验证并提高系统整体的安全防护能力。 网络安全工程（安全解决方案应用与安全测试验证） 为满足OEM设定的网络安全需求，Tier需要在控制器中开发多种安全功能与应用，常见的包括： ⦁ Secure Boot（安全启动）：防止恶意软件篡改系统。 ⦁ Secure Flash（安全闪存）：保障固件更新过程中的数据完整性。 在开发完成后，Tier还需开展一系列安全测试活动，以验证安全应用是否满足OEM的技术规范和性能要求。 网络安全相关的组织及流程 & CIA 为有效执行与网络安全相关的开发、验证和运营任务，Tier内部必须建立完善的： ⦁ 网络安全管理组织 ⦁ 工作流程 这一要求就是OEM与Tier之间网络安全相关工作中的职责与分工协商及合同签订的核心内容，也就是所谓的CIA（网络安全接口协议）。 不过在收到OEM的要求时，在遇到解读困难或不明确的情况下，最好的做法是确保满足OEM获得UNR 155认证所需的“最低”要求，同时从Tier的立场出发，争取最有利的解释。这也是为什么在项目初期，与OEM进行关于网络安全相关工作的协商非常重要的原因。 负责这些工作的人员通常被称为网络安全经理。网络安全经理的职责是，在确保OEM能够满足认证最低要求的同时，为Tier争取最大的利益，例如通过与OEM负责人进行适当的协商，尽可能重用现有的交付物，从而减少重复工作量和资源浪费。 要充分发挥网络安全经理的作用，必须准确理解OEM获得UNR 155认证的整体流程。简而言之，OEM与Tier需先建立网络安全组织和工作流程，并针对认证车型在车辆、系统和控制器层级执行TARA（威胁分析与风险评估），以确定网络安全目标和需求。为满足这些需求，OEM会发布通用的安全设计与验证规范书。然而，由于难以完全契合控制器特性、新车型需求或Tier自身情况，OEM通常需与Tier协商以缩小差距（GAP）。这正是网络安全经理的重要职责之一。差距协调完成后，网络安全工程流程将正式启动，并推进至量产启动（SOP）阶段。即便在SOP之后，直至车辆退役，Tier仍需持续进行安全威胁监测和事件响应。总结来说，对于OEM获得认证所需的关键事项，Tier应尽量予以满足。而对于可以由Tier自由发挥的部分，则应尽可能复用已有的成果和资源，以降低开发成本和提高效率。2. TARA不是应该由OEM来执行吗？TARA（威胁分析与风险评估）不仅是概念阶段的工作，Tier也需在项目全周期内持续执行。目前，大多数情况下仅在概念阶段开展一次TARA，作为一次性活动。然而，网络安全风险贯穿整个车辆生命周期，TARA在开发阶段及量产后同样重要。当发生网络安全事件时，TARA有助于：⦁ 分析威胁并评估风险⦁ 确定应对的紧急性与优先级⦁ 制定合适的安全对策与处理方案 因此，TARA是贯穿全流程的风险管理方法论，不仅限于初期应用。为了高效应对持续变化的安全威胁，Tier必须在内部系统化和常态化TARA活动，这也是确保网络安全管理有效性的关键环节。3. 我不知道应该从哪里开始应对CSMS 从Tier的角度来看，应对CSMS（网络安全管理体系）可以分为以下两种情况。 ⦁ 需要建立基于ISO/SAE 21434的网络安全管理体系 ⦁ 需要建立能够应对OEM和Tier之间签订的CIA（网络安全接口协议）的体系。 总结来说，无论是哪种情况，都可以通过建立符合ISO/SAE 21434的网络安全管理体系来进行应对。建立网络安全管理体系时，需要包含以下内容。⦁ 针对OEM与Tier之间CIA签订流程（即网络安全接口协议流程）的应对指南⦁ 包括网络安全组织在内的网络安全管理系统和规则的建设⦁ 网络安全威胁分析与风险评估指南（TARA指南）⦁ 将OEM的网络安全需求规范融入产品开发并进行验证的方案⦁ 针对生产工艺的网络安全应用指南⦁ 建立网络安全信息和事件的监控体系，并对发现的漏洞进行分析与管理⦁ 针对网络安全事件的响应指南通过建立这样的网络安全管理体系，可以全面应对OEM的各种相关需求。如果建立了这个“符合ISO/SAE 21434的网络安全管理体系”，是能够满足OEM提出的大部分要求的。不仅是OEM，还有许多Tier企业都会向像我们这样的专业公司寻求帮助。不过，从长远来看，将这种网络安全管理体系“内化”是必要的。网络安全是一个长期重要的领域，因此拥有一个能够帮助组织建立并“优化”到适应其环境的管理体系，并进一步实现“内化”的合作伙伴尤为重要。从“专业咨询”的角度来看，应该从什么开始，接下来“如何”推进呢？我们将网络安全管理体系建设的专业咨询工作大致分为三个阶段。 第一阶段，咨询服务将通过差距分析（Gap Analysis），为组织的现状量身设计并构建适合的网络安全管理体系。第二阶段，通过选择适合网络安全内化的项目，根据相关流程提供项目执行过程的咨询服务。具体包括：⦁ 支持组建网络安全应对项目团队并制定计划⦁ 支持CIA（网络安全接口协议）的签订过程⦁ 支持产品的TARA（威胁分析与风险评估）过程，如有需要，可派遣TARA专家参与⦁ 在产品开发过程中，支持安全解决方案的设计、应用和验证，如有需要，可派遣红队（Red Team）协助⦁ 支持在生产工艺中实施安全措施⦁ 在车辆全生命周期内，支持事件监控和漏洞管理第三阶段，ISO/SAE 21434要求进行网络安全审查和项目评估，我们也为这一过程提供支持。对于开发和质量管理团队来说，每个项目都要逐次应对流程审查是一项极大的负担。为此，我们建议通过获取权威的CSMS认证，来提高效率和生产力。如果不想每次都重复应对整个流程，获取CSMS认证是一个不错的选择。4. 在编写网络安全交付物时，我想复用现有的成果，需要一些建议网络安全交付物的工作范围由OEM与Tier之间签订的CIA（网络安全接口协议）决定。对于CIA中列出的各项交付物，可以分为复用现有交付物和全新编写交付物。是否可以复用交付物，至少需要在审查项目定义文档和网络安全规范文档后才能决定。在审查项目定义文档时，需要确认项目功能、安全资产以及运行环境的变化情况；在审查网络安全规范文档时，需要确认安全需求或安全控制是否发生了变化。 为了方便说明交付物的复用情况，我们可以根据CIA中的交付物，将其分组归类如下。⦁ 网络安全流程交付物 → 大部分可以直接复用⦁ 网络安全管理交付物 → 需要根据相关指导进行修改或更新⦁ TARA及验证交付物 → 可以复用，但需考虑网络安全规范的更改、运行环境的变化，以及相关威胁场景或漏洞的变化⦁ 网络安全开发交付物 → 可以复用，但需考虑网络安全规范的变更除了第9、10、11条款外，大多数交付物都可以较为轻松地实现复用为了更深入地探讨， 9、10、11条款的交付物需要进行复用分析。例如，如果新增了网络安全功能需求，则需要在产品中新增或修改相应的安全功能，并完善验证测试用例。另一个例子是，即使产品规格没有发生变化，但运行环境发生了变更，也需要重新执行TARA。例如，增加外部接口会导致新增安全资产；车辆安全模型的变更会影响安全风险评估。总结来说，虽然交付物可以复用，但复用之前需要进行分析，并且在此过程中，需要考虑运行环境和网络安全规范的变更；还要评估由此引发的威胁场景和漏洞变化。基于复用分析的结果，可以决定是否需要更改规范或重新设计。5. 希望能获得关于安全漏洞管理方案的建议网络安全漏洞管理需要从以下两个方面进行考虑.⦁ 全生命周期管理：从产品开发、量产到量产后的整个生命周期，必须对安全漏洞进行管理⦁ 多种来源识别出的漏洞管理 : 不同渠道发现的漏洞都需要纳入管理范围。网络安全问题在产品开发完成后（即SOP之后）依然可能发生。这是因为，现实中黑客技术的发展速度往往快于安全解决方案的演进速度。每当发生网络安全事件（Cybersecurity Incident），都需要开发、验证并发布安全对策，而这些活动将贯穿汽车的整个生命周期。听起来确实如此。5年的量产周期，再加上10年的保修期，已经有15年了。实际上，这一周期可能接近20年。在这样长的时间内，现有的安全技术很难完全经得住考验。因此，需要实施ISO/SAE 21434第8章"持续性网络安全活动"。让我们通过具体案例来进行说明。该界面是漏洞管理台账的示例。如图所示，漏洞的来源渠道多种多样。⦁ 通过网络安全信息和事件监控识别的漏洞⦁ TARA结果中识别出的风险清单⦁ 在产品开发/验证过程中发现的漏洞⦁ 在量产后现场发生的安全事件正如这个例子所示，至少每个项目都需要维护一个漏洞管理清单。正如之前简要提到的，漏洞需要根据项目的特性进行管理。此外，这些网络安全活动必须遵循ISO/SAE 21434第8条款，即持续网络安全活动的指导原则来执行：⦁ 必须实施并记录网络安全信息和事件监控；⦁ 评估识别的事件是否属于安全弱点；⦁ 通过TARA确认该弱点是否会成为项目中的漏洞；⦁ 这些漏洞需要在产品的整个生命周期内进行管理。漏洞管理清单的格式并不是固定的。之前提到的Excel管理清单是最低限度的形式。如果条件允许，建议通过系统化的方式进行管理。为了将网络安全漏洞管理内化，建立并运行SIEMS(Security Information and Event Management System)系统是最佳实践。 6. 由于缺乏网络安全背景知识，每次与OEM开会后，后续的应对工作都会增加 这个问题是我在与控制器制造商的负责人交流时非常常见的提问，我自己在实际工作中也经常遇到类似的情况。之前已经有类似的应对方案介绍过，最终要想高效应对OEM提出的各种需求，可以用一句话概括：标准化和战略性应对方案的制定是关键。 根据产品特性定制安全需求；通过遵循国际标准编写交付物，尽量减少因OEM需求变化而带来的修改工作量。 正如之前提到的，OEM通常会有自己的标准网络安全功能需求规范。然而，这些规范通常是一个“超集”（Super Set），并不能完全适用于每个控制器的特性。 因此，我们需要准确了解OEM的需求，明确区分我们能够完成的部分与不能完成的部分。对于不能完成的内容，需要提出替代方案，或者清晰说明无法完成的原因，同时必要时提供后续应对计划。OEM会将这些控制器制造商提供的说明材料用于形式认证。 从CIA的角度来看，OEM对交付物的要求级别也各有不同，这使得控制器制造商的应对非常困难。为解决这些问题，可以基于ISO/SAE 21434标准编写交付物，并充分解释其符合国际标准，以最大限度减少重复工作和修改需求。然而，现实问题是，大多数控制器制造商并没有专门的网络安全团队，因此无法开展上述活动，导致与OEM讨论的越多，模糊性越高，工作量也随之增加。要解决这些困难，制造商需要具备网络安全专业能力的协助者，而像我们这样的专业公司可以提供有效的解决方案。 飞斯柯罗不仅为全球OEM提供CSMS咨询、网络安全解决方案以及安全测试服务，还深知OEM为了获得UNR155认证所需要控制器制造商配合的事项。此外，我们还拥有丰富的经验，包括为多家控制器制造商提供CSMS咨询服务、支持网络安全经理应对、销售安全解决方案，以及提供工程服务。因此，我们能够为您提供优化的指导，帮助您高效完成相关工作。7. Tier也需要获得网络安全相关认证吗？明确来说，认证是汽车制造商（OEM）的强制要求，而不是Tier的。根据UNR 155的规定，CSMS认证是汽车制造商（OEM）的强制要求。不过，它也要求CSMS必须能够管理控制器制造商的网络安全活动。具体的方法论在ISO/SAE 21434的第7章《分布式网络安全活动》中有所说明。OEM通过CIA（网络安全接口协议）来确认控制器制造商是否已经建立了CSMS。因此，虽然控制器制造商并不直接需要认证，但根据OEM的要求，必须建立CSMS。目前，一些控制器制造商在建立CSMS的基础上，还通过测试机构（目前主要是测试机构TS）取得了ISO/SAE 21434认证。通过这样的认证，企业可以证明自己在网络安全方面的应对准备充分，从而提升在其他项目或新OEM项目竞标中的竞争力。需要注意的是，目前尚无正式的认证机构或审查员资格，因此负责UNR 155认证的测试机构（TS）也负责为Tier提供ISO/SAE 21434认证服务。飞斯柯罗与多家测试机构（TS）有合作经验。例如，我们曾协助某控制器制造商成功获得ISO/SAE 21434认证。基于这些合作关系和丰富的经验，我们完全有能力帮助有意获得认证的控制器制造商高效完成认证。 今天的网络研讨会对大家是否有所帮助呢？希望飞斯柯罗专家小组的回答能够帮助大家解决一些疑问和困惑。未来，我们将继续为大家准备更多能带来实质性帮助的项目，敬请大家多多关注。 飞斯柯罗是韩国领先的汽车网络安全专业企业。我们通过为客户量身定制解决方案，根据客户的实际情况和环境，提供务实的技术突破口，解决复杂的技术问题。 从专用的网络安全控制器SGW，到无需更换芯片即可满足法规要求的HSM安全解决方案，再到支持网络安全持续优化的“一站式运营管理平台”——CSMS门户，飞斯柯罗致力于以务实的方式解决行业面临的困境，立志成为基于SDV（软件定义车辆）的未来移动出行产业中的重要参与者。我们的团队由汽车电子控制系统开发专家和白帽黑客组成，具备卓越的专业实力。