基于OTA流程的分节点安全防控思考

基于OTA流程的分节点安全防控思考

在汽车行业，OTA（Over-The-Air）技术被广泛应用于车辆的软件和固件更新，为车主和制造商带来了诸多便利和优势。但与此同时也引入了新的网络安全攻击面。本文将基于OTA的三大主要流程节点分别讨论我们认为可能存在的问题及需重点实施的安全卡点方案。

术语和缩略语

附赠自动驾驶最全的学习资料和量产经验：链接

01 升级包生成

1.1 OTA包生成流程

OTA包生成，一般步骤为：生成OTA包 -> 打包OTA包 -> 计算软件包哈希值HASH-A -> 签名OTA包 -> 打包签名文件到OTA包中。

A. 生成OTA包：开发团队完成软件更新后，上传至软件仓库。上传的包里通常包含：更新的固件/软件、元数据（通常为json文件，包含版本号、升级部件、升级类型、安装包的签名值等）等。

B. 打包OTA包：在进行OTA时，OTA管理员会创建升级任务，指定升级的车型、软件版本等信息。OTA服务端会到软件仓库拉取指定版本的包。

C. 计算哈希值：OTA服务端使用安全的哈希算法（如SHA-256）对固件包生成一个哈希值HASH-A。HASH-A用于验证固件包的完整性。

D. 签名OTA包：OTA服务端上传打包好的包到签名服务器进行签名。签名服务器通常使用PKI生成一对公私钥A。私钥A保留在PKI中，用于生成OTA包的签名值。公钥A放在OTA包中。用于车端安装时校验整包的完整性。

E. 签名服务器OTA Server对元数据文件进行哈希计算得到HASH-B；（常见哈希计算算法有SHA256、HMAC）。

F. 签名服务器OTA Server使用PKI中的私钥对HASH-B进行加密生成一个二进制的签名文件;（常见的加密算法RSA、DSA 等）。

G. 签名服务器OTA Server打包签名文件：OTA Server服务端将签名文件、公钥证书与软件包、元数据一起打包，形成最终的OTA升级包。

1.2 安全卡点

OTA平台安全

OTA包的发布和分发阶段往往由OTA平台承载，因此安全性往往由ota平台承载；在此阶段ota平台的安全需建立完善的版本控制系统和分发机制以规避安全问题：

A. 版本号唯一性：R156中强调每个OTA包都具有唯一的版本号，以便于追踪和管理。车型需要具有RXSWIN-Regulation X Software Identification Number（软件标识码）. RXSWIN是指一个唯一的标识符，因此平台对于版本管理的功能需要限制一个正式生效的商用OTA版本号仅可被使用一次，在遇到重复命名配置时进行校验并提示操作者当前操作存在不合规性，并不生效此次操作。

B. 平台应访问控制策略：OTA平台应通过账号角色权限限制对OTA软件包在平台侧的非法访问和篡改，基于RBAC的模型严格限制可对OTA包进行上传、编辑、下载及下发动作触发的账号权限，权限的管控粒度应细到BUTTON级别的操作；其实大多数被改装厂利用的OTA包泄露都是内鬼明文泄密，简单粗暴。

C. 分发机制安全卡点：在任何ota版本的下之前平台需通过技术管控强卡点信息安全确认，包括对ota包本身的安全性检查及下发版本。

升级包加密安全

对OTA固件包的加密，通常是在打包OTA包的过程中完成。OTA管理员再运营平台创建OTA任务时，选择对升级包进行加密，OTA服务端会到软件仓库拉取指定版本的包，先将升级包进行加密，再执行后续的签名步骤。

OTA的固件包中，通常包含零部件的核心逻辑、设备配置文件、加密密钥、加密算法等敏感信息。因此OTA包可以被视为企业核心代码资产，从攻击者视角而言，OTA包也具备被hack的经济价值，例如竞品分析、或泛滥的改装市场（例如对原需付费的升级配代码刷写方式），我们认为小作坊改装市场兴盛的源头就是OEM侧的OTA代码包泄露。这里就分两种泄露状态了：

A. 明文泄露：如果主机厂完全不具备对OTA包进行整包或部分加密的能力，在不考虑通道或平台本身安全性的条件下，OTA代码包以裸奔形式奔出圈外，那实在是覆水难收。

B. 加密泄露：其实对于黑客来说，逆向分析，获取OTA包提取其中的核心代码信息虽有可能，但存在技术壁垒与较大的时间成本。但整包加密的方式往往对于智能座舱这样的零部件不适用，因其升级包大小在3~5G甚至以上，升级包较大，加解密的时间较长。且加解密速度依赖零部件性能，整包解密会大幅增加升级时间且过程中频繁出现升级失败的现象。当前，我们认为具备可行性的方案是：

1. OTA平台对升级代码包中的核心商密代码部分加密；

2. 对于比较大的升级包，采用抽样加密的方式进行加密。

02 升级包下发

2.1 OTA包下发流程

OTA包下发，一般步骤为：云端检测到有新版本 -> 查询车端版本 -> 根据车端版本匹配软件包 -> 将包放到CDN -> 告知车端更新包下载地址 -> 车端从CDN下载对应的软件包。

在OTA包下发的流程中，涉及到的车云与车端的指令交互，及指令通过后的软件包传输。OTA控制指令通常基于MQTT、TCP等可建立长链接的协议实现；软件包的传输，通常基于https协议实现。

2.2 常见的攻击场景

OTA传输通道作为连接云端和车载终端的通道，承担着将软件升级包可靠地传输至车载终端并传回升级结果的重要任务。通常情况下，OTA管端采用4G/5G/Wi-Fi等通信载体，传输的内容包括下行的升级包和上行回传的升级结果。

我们认为，在OTA过程中，OTA升级包的下发阶段相对于近端解包升级阶段更容易受到黑客攻击。

由于通道存在窃听和中间人攻击等威胁，如果升级包在传输过程中采用弱认证或明文传输，可能会被拦截并遭到篡改，导致软件功能逻辑和关键数据信息泄露。此外，如果通信协议安全防御能力不足，可能遭受重放攻击或拒绝服务攻击，进而导致升级失败等安全威胁。如图：

2.3 安全卡点

TLS传输

从上图中我们可以看出当涉及到升级包的下发时，传输通道的安全性变得至关重要。传输通道安全通常通过TLS证书认证来进行保障。

**A. 单向认证：**在单向认证模式下，通常由客户端（车端）对服务器进行验证，而服务器对客户端（车端）不进行验证。客户端通过检查服务器的证书来确保连接的安全性和可信度。服务器只需提供自己的证书给客户端，客户端使用预先安装的根证书以及设备证书来验证服务器的证书。

**B, 双向认证：**在双向认证模式下，不仅客户端验证服务器，服务器也会验证客户端的身份。双向认证可以防止中间人攻击（MITM）和伪装攻击，因为双方都需验证彼此的身份。与单向认证相比，双向认证需要在客户端和服务端上配置和管理证书，因此实现和管理成本更高。

单向和双向的优缺点

TLS双向认证不仅服务器验证客户端身份，客户端也验证服务器身份，确保双方的真实性，可有效的防止中间人攻击。通过双向认证，防止未经授权的客户端访问服务器，提高了整体安全性。因此，在传输过程中，优先考虑双向认证的方式建立链接。

单向认证通常比双向认证更简单实现且更容易管理。在建立链接时，相比双向认证，单向认证会更快。但同时也存在一定的安全风险，如：单向认证不支持对客户端进行身份验证，因此难以控制哪些客户端能够访问受保护资源。比如：OTA包的链接仅使用了单向认证，一但url泄露，任何人即可从该链接下载对应的包。这种场景需使用双向认证。

单向认证更适合实时要求较高，使用较频繁，但不包含关键信息的API，可使用单向认证的方式。比如：App端查询云端的OTA的版本信息，app端实时查询车端电量，更新进度等场景，使用单向认证即可。

TLS1.2 VS TLS1.3

A. 算法差异

在算法层面，TLS 1.2和TLS 1.3之间存在显著的区别。主要差异集中在密钥交换、握手过程、加密套件等方面。

● 在TLS 1.2中，主要使用的密钥交换算法是基于RSA和ECC的密钥交换协议。

● 在TLS 1.3中，新增了安全性更高的密钥交换算法，例如基于ECDH的密钥协商协议。

B. 握手流程优化

除此之外，TLS 1.3对握手过程进行了优化：

● 握手流程简化：TLS 1.3通过优化算法和协议流程，减少了握手所需的往返次数。在TLS 1.2中，握手过程相对复杂，涉及到多次客户端与服务器之间的信息交换。而TLS 1.3通过协议改进，使得握手过程更加简洁高效。

● 支持早期数据发送：TLS 1.3引入了“零往返时间”的概念，允许在握手过程中早期就发送应用数据。这一特性大大缩短了握手时间，提高了通信效率。（客户端发送带有密钥共享信息的问候（Client Hello with Key Share）消息至服务器；此消息可能包含客户端支持的最佳密码套件等信息。可减少一次往返时间确认密钥信息交换流程，从而更快速地完成安全通信的准备）。

● 重协商机制的改进：在TLS 1.2中，握手重协商过程存在安全隐患。而TLS 1.3通过改进重协商机制，提高了协议的安全性。（在证书过期、被撤销或需要更换的情况下，通过重协商机制，服务器可以在连接过程中动态更换证书，确保通信的持续性和安全性。更换证书，确保通信的持续性和安全性）。

TLS 1.3解决前置泄露证书或私钥的问题：

TLS 1.3引入了前向保密性和更好的密钥派生功能，前向保密性可以确保即使某个版本的密钥泄露，后续的通信仍然能够保持安全。我们在这里举一个常见的场景：一家公司的内部应用程序需要使用HTTPS进行通信，但存在前置泄露证书或私钥的风险。在这种情况下，大多数公司会优先考虑在原有TLS1.2的基础上优化优化证书密钥管理策略。证书密钥管理策略如私钥保护、定期更新证书等，确实可以大大降低证书或私钥泄露的风险，此部分工作对于企业往往存在一定运营成本例如推动证书或私钥的更新迁移。对于互联网企业尽管存在潜在的泄露风险，通过最佳实践和适当的配置，可有效应对此类问题。

不幸的是，对于车联网场景，如果要对已量产车辆端侧的证书与私钥更新替换，其实施难度直提高至mountain top。残酷的现实是，车联网场景中所使用到的证书或者私钥，因早期建立产线时安全自动化的不全面性，往往在产线传递过程中存在泄露风险。对于主机厂造车的现状而言，一条生产经营汽车的产线早在5-10年前甚至更早就逐步建设完成，一个证书的泄露涉及到的也许是多款共用产线的车型。而如果在此节点推动产线的证书传递预灌或生成方式的全面变更，一不小心就会显有点反骨之才跟历史丰功伟绩作对的意味。

针对未来智能车产业更高的安全性和性能需求，无论对于证书的管理更新运营推动还是TLS版本的升级迁移都会产生集中时间段的大量人力成本，在成本相近的情况下，我们不如评估考虑咬咬牙逐步迁移到更先进的TLS 1.3。

03 升级包端侧校验

3.1 升级包校验流程

车端收到OTA包之后，一般会执行以下步骤：验证签名HASH-B -> 验证哈希值 HASH-A -> 安装OTA包 。

签名值验证：

车端OTA Manager接收到 OTA 包后，解压后在文件中提取出的用于验签的公钥A。使用公钥A对包中的数字签名进行验证：

A. OTA Manager使用公钥A对压缩包中的签名文件（二进制格式）使用车企规定好的算法（通常为RSA、DSA等）进行解密，解密后可得到元数据文件的哈希值HASH-B。

B. OTA Manager进一步再根据元数据文件（json格式）以及车企规定好的算法（通常为SHA256、HMAC）计算出哈希值HASH-B’。

C. OTA Manager比对HASH-B是否等于HASH-B’，若相等则签名值校验通过。

签名有效则代表验证了包的来源合法性；签名值验证通过后，开始验证升级包的哈希值。

验证哈希值：

A. OTA Manager读取升级包中的bin文件，并依据车企预先规定好的算法自动计算升级包的哈希值HASH-A’。

B. OTA Manager计算出哈希值后，将其与OTA软件包元数据中保存哈希值HASH-A进行比对，当HASH-A和HASH-A’相等，则代表哈希值验证通过。

哈希值验证则代表验证了包的完整性。

3.2 常见攻击场景

以上校验逻辑，会存在公钥证书伪造的风险。设想如下场景，攻击者通过中间人攻击，同时替换OTA包中的固件包、元数据、签名文件以及验证签名的公钥证书A。车端在校验升级包时，使用的是攻击者的公钥去验证。这样就绕过了OTA的校验流程。

具体攻击步骤如下：

A. 攻击者篡改OTA的升级包中的固件包（可篡改bin文件，定向篡改镜像文件中的配置或尝试修改某可执行程序中的重要功能）

B. 攻击者可通过逆向分析OTA Manager，拿到哈希值HASH-A的计算方式，并替换元数据中的哈希值HASH-A。

C. 攻击者自行生成一对公私钥对B。其中，私钥B用于伪造OTA包的签名值，公钥B用于替换合法的公钥A。

D. 先将生成的公钥B直接替换原有OTA升级包中的合法公钥A。

E. 攻击者可通过逆向分析OTA Manager，拿到哈希值HASH-B的计算方式，再用自己的私钥B对已截获OTA软件包中的元数据进行签名，生成新的签名文件，并用以替换原有OTA包中合法的签名文件。

F. 攻击者通过以上步骤，可绕过车端的签名值校验。

3.3 安全卡点

证书合法性验证

为解决证书伪造的风险，车端在升级包验证之前，需要先验证OTA包中的证书的合法性。

验证证书的合法性，通常包含两部分：服务端生成签名证书的过程，车端校验OTA包中的数字证书的过程，如下图所示。

服务端生成证书签名过程：

A. 首先 PKI 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值。

B. 然后 PKI 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 PKI 对证书做了签名。

C. 最后将 Certificate Signature 添加在文件证书上，形成数字证书。

D. 车端校验OTA包中的数字证书的过程，如上图右边部分：

a). 首先车端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；

b). 通常车在出厂前，会预置公钥，使用 公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；

c). 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

在验证了OTA升级包中的证书是合法的之后，再使用该证书验证OTA包的完整性，可防止公钥证书伪造的风险。

04 总结

OTA 安全具有至关重要的必要性，不安全的 OTA 可能导致车辆的功能异常甚至失效，影响用户的正常使用体验，甚至可能引发安全事故，危及用户的生命和财产安全。我们需要在每个节点来保障OTA安全。

在升级包生成这个关键节点，做好升级包的签名、敏感内容的加密、以及OTA运营平台的安全管控，为后续的流程奠定安全基础；升级包下发阶段，使用安全的通信协议，并做好TLS安全认证的安全卡点，从而保障升级包能够安全、完整的传输到车端；升级包端侧校验是确保整个OTA安全的关键节点，通过安全的签名验证方式，来确保正常安装到车端。

通过在每个节点设置这些针对性的安全卡点，能够极大地提升 OTA 流程的安全性，为用户和车辆提供坚实可靠的安全保障，让他们免受潜在网络攻击的侵害。