正如大家所了解的，以欧洲“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通常会提出哪些要求
有些OEM会提供非常详细的规范，从硬件规格到密钥注入流程都清晰定义；也有OEM只是大致要求要引入一个可以管理密钥或证书的系统。此外，Secure Debug、Secure Flash、SecOC等安全功能的应用范围与实现方式也各不相同。
因此，能否在满足OEM要求的前提下，结合Tier自身的实际情况，制定出最优解决方案，是决定KMS是否成功部署的关键。
飞斯柯罗已经有多个成功的KMS项目案例。
5. 我想了解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 会不会对控制器的生产造成问题？
例如，服务器故障或网络中断时，是否会导致生产线停滞？流程增加是否会影响整体生产效率？后期生产线扩充时，是否会大幅增加建设成本？这些都是合理的担忧。特别是当客户的生产基地在海外的情况下，这些问题会更加敏感。
因此建议大家一定要选择能够综合考虑客户实际情况与OEM要求、并具备风险控制设计能力的合作伙伴。
飞斯柯罗曾为客户构建过专门优化以降低副作用的KMS架构，我们聚焦于最小化生产时间的增加，以及最小化因通信故障导致的生产中断，并从中得出了与生产线高度整合的最佳方案。
最终，我们采用了如上图所示的方式构建KMS：KMS服务器会提前生成大量密钥，并在预定时间发送一定数量的密钥。例如，在生产线的空闲时间内，EOL（End of Line）流程程序会与服务器通信并接收密钥。一旦生产重新开始，EOL流程程序就可以使用已接收的密钥继续注入作业。
此结构并非在需要时才生产密钥，也无需每次注入时都与服务器通信，因此可以最大程度减少每个生产单元的时间增加。此外，由于生产线从服务器预先获取了充足的密钥，即便出现通信问题，也能较好地避免副作用。再加上是集中式服务器，在扩展生产线时无需新增服务器，因此还可节省扩展成本。
借助KMS不仅可以实现安全性，还能同时兼顾效率、稳定性与可扩展性！
像飞斯柯罗这样，在构建KMS时就提前规划如何最小化副作用的企业，无疑是值得信赖的合作伙伴。
7. 想了解 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 的安全需求很困难
比如说，看似统一的安全功能如 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（软件定义车辆）的未来移动出行产业中的重要参与者。我们的团队由汽车电子控制系统开发专家和白帽黑客组成，具备卓越的专业实力。
