一文搞懂系列——《GB 44495-2024 汽车整车信息安全技术要求》 解读

1. 背景

        在与tier1的前期技术沟通中，我主要负责信息安全相关内容。在这个过程中，有一些技术和信息安全需求也是我第一次接触，学习到很多新的知识。

        虽然最终的结果，我们并没有承接相关的信息安全需求开发。但是我就在思考，客户提出的这些信息安全是否在其它车型也需要，在以后的项目中是否也是必须具备的功能。于是，我查阅了相关资料和咨询相关人员，了解到《GB 44495-2024 汽车整车信息安全技术要求》是行业的信息安全标准，在2026.1后所有新车型必须要满足该规范。并且tier1的信息安全，基本全部都被包含在内。

        因此，我希望通过走读该标准，了解汽车行业中信息安全的相关标准及需求。目的有二：

1. 提升整车信息安全方面的专业度。深入理解各个规范需求，在这之上了解对应的解决方案。下一次，再与客户交流，可以站在客户的角度上，去引导，支撑客户需求。
2. 从整车的信息安全规范中，识别出对软件架构的影响。以及会涉及到技术栈，提前做好相关技术预研及积累，做好战斗储备。

2. GB 44495-2024 解读

        GB 44495-2024 《汽车整车信息安全技术要求》国家强制性标准已于2024年8月23日正式发布，并将于2026年1月1日实施。标准规定了汽车信息安全管理系统要求、信息安全一般要求、信息安全技术要求、检查试验方案及以同一型式判定。其标准内容框架如下：

2.1 适用范围

        该标准适用于M类、N类及至少装有一个电子控制单元的O类车辆。基本已经适用我们常见的所有车型。

        M类、N类、O类车辆是根据车辆的用途和类型进行分类的。

车辆类型	定义	用途
M类	指主要用于运载人（最多含9人，包括驾驶员）的车辆 M1类。用于载人且不超过8个座位（不包括驾驶员）的汽车，通常是私人轿车、SUV、MPV等 M2类。最大设计乘员数为9至22人的小型客车 M3类。最大设计乘员数超过22人的大型客车	主要用于运载人，适用于乘客运输
N类	指主要用于运输货物的车辆，按照最大总质量（车辆与货物的总和）进行分类 N1类。最大总质量不超过3.5吨的轻型货车 N2类。最大总质量超过3.5吨但不超过12吨的中型货车 N3类。最大总质量超过12吨的重型货车	用于运输各种类型的货物，适用于物流、运输等行业
O类	指通常没有动力装置，必须与一辆主动车辆（M类或N类）连接使用的车辆。 O1类：最大总质量不超过0.75吨的小型挂车。 O2类：最大总质量超过0.75吨但不超过3.5吨的中型挂车。 O3类：最大总质量超过3.5吨的重型挂车。 O4类：超过4吨的超重型挂车。	用于为其他车辆提供额外的载货能力，常见于物流运输中，例如挂车、拖车

        总结：从该规范的适用范围来看，若想在国内汽车行业生存，该规范是无法越过的门槛。因此，该标准的理解是所有从事汽车行业人的必备素养。

2.2 汽车信息安全管理体系要求

        该标准指出了车辆制造商应具备车辆全生命周期的汽车信息安全管理体系，规定车辆产品开发流程应遵循汽车信息安全管理体系，同时对车辆制造商对风险识别、管理、评估的组织流程、责任和治理措施提出了明确的要求。

        总结：该要求主要针对车辆制造商，与我们tirl1、tirl2关系并不大。但实际规范评审过程中，主机厂需要提供很多文档进行验证。因此我们在执行相关技术要求过程中，需要做好相关文档输出，配合主机厂。

2.3 信息安全技术要求

        该标准中涉及的信息安全技术要求包括四类：外部接口安全要求、通信安全要求、软件升级安全要求、数据安全要求。

2.3.1 外部接口安全要求

        出于对当前复杂网络环境的安全考量，随着信息技术的快速发展，外部有线和无线连接成为攻击者常用的入侵途径，非法外联，数据泄露，恶意软件感染等安全威胁日益严峻。该标准的目的，旨在防止通过外部连接通道进入汽车系统内部造成敏感数据泄露、非法访问和恶意攻击，确保业务的连续性和稳定性。

        主要测试对象：T-Box 蜂窝以太网接口、WI-FI接口、关键零部件固件、第三方应用、远程控车APP、USB接口、CAN诊断接口等。

序号	测试项目	测试内容	解决方案	后续计划
1	系统漏洞安全测试	车端具备远程控制功能的系统、授权的第三方应用不应存在由汽车行业权威漏洞平台6个月前公布且未经处置的高危及以上的安全漏洞	目前国内的权威机构有车联网产品安全漏洞专业库（简称CAVD）。它是由中国汽车技术研究中心有限公司（以下简称“中汽中心”）通过聚集汽车行业漏洞资源，联合行业共同构建的首个汽车漏洞数据库。其中汽车漏洞覆盖T-BOX、IVI、车内网络、ECU、无线电、APP、云平台、其他八大类型。 因为CAVD主要面向汽车企业用户，其它企业用户需要满足特定的条件才能获取相关漏洞信息。	漏洞信息需要车企定期去获取，通知给供应商。供应商再进行针对修复。
2	非业务必要网络端口安全测试	车辆开放端口清单应与车辆业务端口清单保持一致；不应存在可非授权连接的端口	统计T-Box、IVI、ICU中需要联网的业务，得到IP+PORT列表 在T-Box(5G蜂窝网)、IVI(蓝牙+WI-FI)常见防火墙白名单，仅允许指定IP+PORT请求通过。	加强防火墙相关操作积累。输出常见使用场景及示例文档。
3	远程控制安全测试	应对远程控制指令进行真实性和完整性验证安全测试   对远程控制指令设置访问 具备记录远程控制指令的安全日志功能 对车端具备远程控制功能的系统进行完整性验证	非对称加密+数字签名。非对称加密用于保护指令的机密性，数字签名用于确保指令的真实性和完整性。 基于PKI证书实现双向身份认证+角色的访问控制（RBAC）。双向认证保证指令的有效性，角色的访问控制，保证了功能安全。 属于功能需求部分，可以定义日志格式，如： json { "timestamp": "2024-03-15T14:22:35Z", "command": "车门解锁", "source_ip": "203.0.113.12", "user_id": "user_123", "result": "成功" } 其中需要关注的是日志安全存储。加密+安全存储。日志加密是保证日志文件安全性，防止篡改、泄露。安全存储防止丢失，可以考虑存放在HSM芯片或TEE环境中。 4. 安全启动。根据客户的要求不同，可以进行启动链逐级验证，每个环节校验哈希值或数字签名。 BootROM → 验证Bootloader签名 → 加载Bootloader   Bootloader → 验证OS镜像哈希 → 加载OS   OS → 验证应用签名 → 执行远程控制服务 一般只要做到OS镜像哈希验证即可。	掌握PKI流程 掌握常见的数字签名算法 掌握RBAC实现方案 掌握MTK TEE环境使用方式 了解安全启动流程及方案
4	第三方应用安全测试	对授权的第三方应用的真实性和完整性进行验证； 对非授权的第三方应用的安装进行提示； 对已安装的非授权的第三方应用进行访问控制。	数字签名+哈希白名单。数字签名确保完整性，哈希白名单保证真实，有效性。 应用白名单+安装源管控。指运行安装指定应用，并且这些应用只能从指定源安装，比如车企应用商店或指定URL安装。 动态权限管理。基于android 原生的权限管理。	该信息安全需求主要针对android 系统，暂不关注。后续了解android组方案，可以支撑与客户沟通即可。
5	外部接口安全测试	对车辆外部接口进行访问控制保护 对接入设备中的文件进行访问控制 对病毒风险进行处置 诊断接口身份鉴别安全测试	物理接口访问控制+协议访问控制。默认关闭非必要物理接口，仅在需要时启动。基于设备指纹（如MAC地址、厂商ID）建立授权设备列表，非白名单设备拒绝连接。过滤非预期CAN ID、通过VLAN隔离各车载网络通信。 文件扫描及过滤+权限最小化。文件类型限制，仅允许特定格式（txt,bin）,禁止可执行文件（apk、exe）。接入U盘时，以只读模式挂载，禁止写入车机系统目录。基于SELinux或AppArmor策略,限制文件访问权限。 车载杀毒引擎。安装供应商杀毒软件程序，实时监听异常行为。并进行相关处理。 双向认证+安全存储。双向认证确保身份安全，安全存储保证证书密钥的安全。	掌握如何动态启动、关闭各物理端口驱动的方法 掌握MTK 提供的AppArmor 策略使用方式

2.3.2 通信安全要求

        通信网络是现代社会不可或缺的基础设施，承载着海量数据的传输与交换任务。车辆在行驶过程中，也需要经过通信网络与外界设备进行数据交互。在这一过程中，通信安全显得尤为重要，它直接关系到传输过程中数据的保密性、完整性和可用性。然而，通信安全正面临着日益复杂的威胁和挑战，黑客攻击、病毒传播、数据泄露等安全事件频发，这些不仅会给企业带来巨大的经济损失，还可能严重威胁到国家安全和社会稳定。该标准，旨在确保信息系统的稳定运行和数据的安全传输。

        主要的测试对象有：网络通信协议、WLAN、蓝牙、V2X通信、射频钥匙、OBD口等。

序号	测试项目	测试内容	解决方案	后续计划
1	云平台通信身份真实性验证安全测试	车辆与车辆生产企业云平台通信时，应对其通信对象的身份真实性进行验证。	基于证书实现双向身份认证。保证了通信对象的身份真实性。	掌握证书双向认证流程及常见方案。
2	V2X通信身份认证安全测试	车辆与车辆、路侧单元、移动终端等进行V2X直连通信时，应进行证书有效性和合法性的验证。	基于证书实现双向身份认证。保证了通信对象的身份真实性。	同上
3	通信通道完整性安全测试	车辆应采用完整性保护机制保护除RFID、NFC之外的外部无线通信通道。	无线通信通道有蜂窝网络、WI-FI、蓝牙。这里的数据完整性指传输过程中，数据没有被未被篡改、损坏或伪造。我们可以再应用层实现，也可以在协议层实现。从性能稳定的角度，一般推荐协议栈实现。WPA2以上算法+蓝牙协议4.2版本以上+AES-GMAC 或 SNOW 3G（5G蜂窝）、EPS Integrity Algorithm (EIA) （4G蜂窝）。	了解我们当前各无线通道的协议版本及支持的算法类型。
4	防非授权操作安全测试	车辆应具备对来自车辆外部通信通道的数据操作指令的访问控制机制。	指令白名单+角色的访问控制（RBAC）。只允许执行预定义的指令集，并对不同的角色设置对应指令权限。
5	关键指令数据有效性或唯一性验证安全测试	车辆应验证所接收的外部关键指令数据的有效性或唯一性。	数字签名+时效性控制。指令签名可以保证真实性，请求中包含时间戳，可以保证有效性。
6	敏感个人信息保密性安全测试	车辆应对向车外发送的敏感个人信息实施保密性保护措施。	数据脱敏+安全存储。首先对敏感数据进行加密，进行传输。并且进行分级加密策略：车主身份信息（硬件级加密）、车辆位置（应用级加密），避免单点暴露。密钥的生成与销毁由HSM管理。	确认车辆上的敏感信息有哪些。
7	防御物理操纵攻击安全测试	车辆应具备安全机制防御物理操纵攻击，至少具备与外部直接无线通信的零部件的身份识别机制。	通过测试方式分析，其对应的异常场景是换件。硬件身份识别。每个无线通信模块在建立通信时，需要进行硬件身份认证，若认证失败，则拒绝建立通信。	识别业务场景：比如UWB数字钥匙，一般的方案需要多个UWB模块。
8	车辆与外部直接通信零部件防非授权特权访问安全测试	车辆与外部直接无线通信的零部件应具备安全机制防止非授权的特权访问	权限隔离。系统定制，在量产后，root用户无法登录，普通用户可以登录，但禁用sudo各类提权操作。	掌握Linux用户管理方案，提权操作有哪些？如何禁用
9	车内安全区域隔离安全测试	应对车辆内部网络进行区域划分并对区域边界进行防护。跨域请求应进行访问控制，并遵循默认拒绝原则和最小化授权原则。	这个应该是整车的角度去实现，隔离不同域之间的通信，比如动力域、座舱域、车身域、自动驾驶域。其实现方式分为两种：物理隔离、逻辑隔离。 从我们的角度，只能做到逻辑隔离，可以通过防火墙设置相关的逻辑。	掌握iptables相关配置指令。
10	拒绝服务攻击识别防护安全测试	车辆应具备识别车辆通信通道遭受拒绝服务攻击的能力，并对攻击进行相应的处理。	根据测试手顺，DDos攻击对象有移动蜂窝网络、V2X、CAN总线、车载以太网等通信通道。IDSP+CANID 过滤。SOC侧可以通过集成IDSP库，实现DDos的识别与防护，MCU侧可以通过仅收发指定CANID，若CANID负载增加，则进行限制。	了解IDSP使用方式
11	恶意数据识别安全测试	车辆应具备识别恶意的V2X数据、恶意的诊断数据能力，并采取保护措施	V2X数据过滤+诊断能力限制。V2X对消息的格式进行校验；诊断协议限制，比如一些诊断请求要通过27服务验证
12	通信信道安全日志安全测试	应具备记录关键的通信信息安全时间日志的功能，安全事件日志存储时长不少于6个月	日志生成规范+安全存储方案+存储时长保障。日志生成格式如下： json {"timestamp": "2024-03-20T08:15:23.456Z", "event_type": "CAN_DoS_Alert", "source": "can0", "detail": "帧速率超阈值(1500fps/1000fps)", "action": "限速触发"} 日志生成后，可以保存在eMMC分区或TEE中。当日志文件存储超越预定大小，或超过日期，可以将日志文件压缩保存至云端。

2.3.3 软件升级安全要求

        软件升级已成为保持系统性能、修复安全漏洞和提升用户体验的重要手段。然而，软件升级过程本身也伴随着一定的安全风险。不当的升级操作可能会导致系统不稳定、数据丢失，甚至可能被恶意软件利用，从而对信息系统的整体安全构成严重威胁。

        主要的测试对象有具备车载软件升级系统的ECU、网络通信协议、升级包、升级日志等。

序号	测试项目	测试内容	解决方案	后续计划
1	安全保护机制测试	车载软件升级系统应通过安全保护机制，保护车载软件升级系统的可信根、引导加载程序、系统固件不被篡改，或在被篡改后，通过安全保护机制使其无法正常启动。	安全启动链+HSM。将证书、私钥保存在HSM中，启动过程进行逐级验证： BootROM → 验证Bootloader签名（RSA-3072/SM2） → 加载Bootloader   Bootloader → 验证OS镜像哈希（SHA-256/SM3） → 加载OS   OS → 验证应用签名 → 启动应用 一般实现OS镜像哈希验证即可。	同上
2	漏洞安全测试	车载软件升级系统应不存在由汽车行业漏洞平台6个月前公布且未经处置的高位及以上的安全漏洞	主机厂与汽车行业漏洞平台（如CAVD）沟通，获取最新的安全漏洞，并要求供应商修改。 被动支持	同上
3	在线升级安全测试	车辆和在线升级服务器应具备身份认证机制； 对下载的在线升级包进行真实性和完整性校验； 应具备安全事件日志，日志存储时长应不少于6个月。	双向认证+HSM。双向认证确保身份的真实性，HSM保存根证书，确保安全。 数字签名+hash校验。数字签名确保真实性、哈希校验确保完整性。 安全事件日志格式+安全存储方案+存储时长保障，如：时间戳、事件类型、源IP、升级包哈希、操作结果。并加密存储到EMMC分区。当日志文件存储超越预定大小，或超过日期，可以将日志文件压缩保存至云端。
4	离线升级安全测试	使用车载软件升级系统进行离线升级时，车辆应对离线升级包真实性和完整性进行验证。 不使用车载软件升级系统进行离线升级时，应采取保护措施保证刷写接入端的安全性。	数字签名+hash校验。对离线包进行校验，确保其真实性和完整性。 物理接口管控。量产车辆关闭JTAG/SWD，仅保留授权OBD-II端口。

2.3.4 数据安全要求

        汽车信息化程度的不断加深，使得数据在生产、存储、传输、访问、使用、销毁等全生命周期中的安全问题日益凸显。网络攻击、数据泄露、内部人员误操作等安全事件频发，给个人、企业和国家带来了巨大的损失。车内数据的安全不仅关乎个人隐私保护，确保驾乘人员的敏感信息不被泄露和滥用，还直接关系到行车安全，因为关键参数的任意修改可能导致严重的后果。

        主要的测试对象有IVI、TBOX、网关、ADAS域控制器等车内关键零部件。

序号	测试项目	测试内容	解决方案	后续计划
1	密钥防非法获取和访问安全测试	车辆应应采取安全访问技术或安全存储技术保护私钥信息	TEE或HSM。将密钥保存在HSM或TEE中。
2	敏感个人信息防泄漏安全测试	车辆应采取安全访问技术、加密技术或其它安全技术保护存储在车内的敏感个人信息	HSM+数据脱敏。将敏感个人信息进行脱敏处理，并保存在TEE或HSM中。
3	车辆身份识别数据防非授权删除和修改安全测试	车辆应采取安全防御机制保护存储在车内的车辆识别号（VIN）等用于车辆身份识别的数据	HSM+数字签名。数字签名确保VIN未被修改，HSM确保存储安全。
4	关键数据防非授权和修改安全测试	车辆应采取安全防御机制保护存储在车内的关键数据	HSM+数字签名。数字签名确保VIN未被修改，HSM确保存储安全。
5	日志文件防修改和非授权删除安全	车辆应采取安全防御机制保存存储在车内的安全日志	安全事件日志格式+安全存储方案+存储时长保障，如：时间戳、事件类型、源IP、升级包哈希、操作结果。并加密存储到EMMC分区。当日志文件存储超越预定大小，或超过日期，可以将日志文件压缩保存至云端
6	个人信息清除功能测试方法	车辆应具备个人信息删除功能	功能需求开发。供用户提供删除个人信息的接口，可以是APP或IVI界面。
7	防数据直接出境测试方法	车辆不应直接向境外传输数据	防火墙过滤。统计各应用对外的域名或IP，进行iptables 白名单控制。对于非白名单域名、IP，则丢弃。

3. 总结

        根据标准的实施计划：

对于新申请型式批准的车辆，自本文件实施之日起开始执行。 对于已获得型式批准的车型，自本文件实施之日起第25个月开始执行。

        也就是说，在2028年2月1日起，所有车辆都应该满足该标准。因此，上述的信息安全技术要求，我们不仅要掌握，还应该精通，方案还要成熟。这样才能指导我们不成熟的客户或承接来自主机需求。