基于微控制器的汽车 OTA 更新
文章转自：牛喀网
↓聊一聊自动驾驶OTA↓
现如今，一辆高级汽车系统中所包含的代码比一架普通飞机还多，可能超过1 亿行。尽管现在的汽车系统可以监控汽车的运行、帮助实现功能的自动化、并满足用户娱乐需求，但在较长的汽车使用寿命期间，新功能的部署、版本发布和维护以及安全问题仍是一项严峻的挑战。在这一背景下，为了保证安全可靠地系统更新， OTA 更新发挥了越来越重要的作用，制造商们纷纷开发性价比较高的技术基础设施和解决方案，从而提高汽车驾驶的舒适性、安全性和可靠性。
分析报告显示，今后配备 LTE 网络连接的车辆将成为主流。
OTA 更新在信息娱乐系统中很常见，但在动力总成、底盘、车身和安全应用中则较少，因为这些领域的应用不仅要求更高的可靠性和安全性，同时需要 OTA 更新拥有额外运算和存储能力。然而，近几年随着车辆各种软件配备数量的不断增多，与软件相关的车辆召回也相应变得更加频繁。
相比于其他基于微控制器的应用程序，信息娱乐系统通常在具有较大外部存储器的高性能处理器上运行。除了需要基于新代码的闪存，OTA 更新还要求系统能够：
显示其ID
验证自身的完整性
与服务器建立安全连接
验证所接收更新的完整性和真实性
保护存储的数据免受网络攻击
在所有运行状态下支持更新程序的下载和安装
故障时回到上次更新
简而言之，客户端必须确保系统安全地接收和存储更新，并在不中断车辆运行的情况下正常运行。
安全更新
随着高级驾驶员辅助系统在车辆中作用的提升，汽车系统对于车辆操作和安全的管控变得尤为重要。因此，需要通过可靠和安全的方式来对系统中的所有更改进行处理。OTA 更新是指将 OTA 对象（新代码）从制造商（云服务器）传递到车辆（客户端）。在此过程中，客户必须：
1. 验证服务器ID
2. 检查OTA对象是否完好无损地被接收
3. 保护和存储相关信息
这些步骤是通过加密以及对称和非对称这两种类型的算法实现来的。
服务器和客户端之间共享的密钥是对称加密的基础，所以，只有将密钥保密才能保护 OTA 对象。
为此，在整个供应链环节，包括在制造和交付过程中，必须不断选择和存储密钥。同时，为了控制相关风险，不同的系统可能使用不同的密钥，并且主密钥系统管理着所有系统中的所有密钥，而当每辆车都有一组不同的密钥时的情况会更加复杂。由于共享密钥通常更容易出现安全漏洞，因此 OTA 更新不能仅仅依赖于对称算法。
非对称加密使用私钥/公钥配对，所以它对于对称加密是一个很好的补充。其中，公钥是公开的，因此不需要保护。这里假设公钥是从可信来源获得的，密钥管理系统维护一个私钥列表，这个列表永远不会离开制造商的安全服务器。而从获得只能通过适当私钥进行解密的消息开始，客户端和服务器就已经建立了安全的通信通道。
当服务器成功解密消息时，客户端便可确定该服务器的正确性。这种方法通常用于互联网通信（如 HTTPS），同时它能够成功验证连接到网络的节点（服务器和客户端）身份。
与对称加密相比，非对称加密的一大缺点是需要更加密集的计算。因此，为了提高安全性和加快处理速度，OTA 系统将对称加密和非对称加密的优点进行了结合。
真实固件无线传导更新（True FOTA）
汽车 OTA 更新所面临的另一个挑战是决定执行更新的时间和地点。这是因为，一方面，对不同地区的经销商进行实地访问费用较高，另一方面，需要为数据更新提供足够的网络带宽。
作为一项带有嵌入式系统的功能，True FOTA （真实固件无线更新）可以在任何时间和地点执行更新。也就是说，无论车辆是否在运行以及网络带宽是否可用，都会在后台安静地下载更新。驾驶员在发动车辆时会看到更新提示，而整个更新过程无需实地访问经销商或驻车便可完成。
OTA 激活微控制器的要求
为满足这些系统级要求，ECU 中的微控制器需要：
显示其ID
验证其代码
执行非对称加密，例如 RSA 或 ECC，从而安全地连接和验证收到的更新
将秘密消息存储在安全存储器中
在正常操作期间存储更新的代码
透明地从旧代码切换到新代码
回到旧代码
此外，由于 OTA 主要用于满足不同制造商的不同要求，微控制器应该能够适应 OEM/Tier 1的不同 OTA 要求/应用，同时还需要有能力支持对称和非对称加密。
尽管微控制器与更新过程没有直接关系，但它必须支持车辆安全启动，从而确保在启动期间加载正确的代码。否则，微控制器中运行的可能是未经授权或损坏的代码。为了启用现场故障分析，应该通过某种机制来解除设备保护，例如设置设备之间共享通用密码，或者开发其他比简单软件后门更安全的方法。