浅析车联网OTA数据安全解决方案之加密验签

随着软件定义汽车的发展，汽车逐步转变为一个智能化、可拓展、可持续迭代升级的移动电子终端。为实现这一目标，整车在标准操作程序前便预埋了性能超前的硬件，并通过OTA在生命周期中逐步解锁和释放功能和价值。

由于OTA主要通过网络连接升级，因此升级过程中存在一定的安全风险，例如在FOTA流程中存在传输风险和升级包篡改风险，如终端在升级流程中缺少验证机制，黑客可通过网络手段篡改升级包至车辆终端，进而篡改系统，造成行车安全等隐患。

那么汽车在OTA升级过程中如何保证安全性呢？今天，我们就先来聊一聊OTA过程中的确保传输安全的加密验签方案。

安全性需求

让我们先来看看我们传输软件数据过程中可能发生的四个主要问题：

1

窃听

A向B发送的数据在传输中被C窃听。

2

假冒

A以为向B发送了数据，然而B有可能是C冒充的，反过来毅然。

3

篡改

B确实收到了A发送的消息，但是消息中途被C进行了修改。

4

事后否认

B从A那里收到了消息，但是作为消息发送者A事后声称“这不是我发的消息“。

第一个存在的问题，比较简单，运用“加密”技术就可以解决。

那么后面三个问题，该如何应对呢？这个就需要运用到数字签名和验签机制了。

加密验签的安全流程设计

众所周知，常用的加密方法包括非对称加密和对称加密，比如艾拉比OTA解决方案中，就可以根据车厂的要求采用对称和非对称的加密手段，以保证OTA升级过程中的安全。目前来说，对称加密在安全方案中比较常见，这里不再赘述。以下对非对称加密的安全流程设计做分享讨论。

首先，非对称加密算法需要包含一对公钥、私钥。假设A和B均准备好了一对公钥、私钥，同时A、B的公钥已提前告知对方，而私钥都仅自己可知。准备工作就绪后， A要给B发送软件数据，加密验签流程如下：

第一步加密：A使用B的公钥将要发送的明文加密，生成密文；

第二步加签：A将密文通过算法生成摘要，并使用A的私钥对摘要进行加密，即生成签名值；

传输过程：A将密文及签名值一同发送给B。

第三步验签：B将收到的密文通过相同的算法生成摘要，并使用A的公钥对收到的签名解密生成摘要，两个摘要进行对比，若相同，则验签成功，若不同则验签失败；

第四步解密：B将验签后的密文使用B的私钥进行解密得到明文；

以上整个加密验签流程概括来说就是：公钥加密，私钥解密；私钥签名，公钥验证。

总结和思考

1.除了上述这种流程，是否可以设计成其他流程呢？

2.假如明文就是一些无规律的且不可破解的二进制流，那么加密步骤①是不是可以省去了呢？

3.假如加密步骤①使用对称加密算法或者自定义的算法呢？

4.另外，对于签名步骤②中的生成摘要，目前一般应用较多的就是MD5或哈希算法，摘要加密可使用RSA算法。那是否还有其他算法呢？

这些都留给朋友们来一起沟通和讨论吧。

今天的OTA安全解决方案之加密验签就分享到这里了。如果你对OTA技术有任何疑问，欢迎添加下面OTA小助手微信进群讨论。针对常见问题，我们将不定期召开专题讨论，为大家打造一个开放的技术沟通平台。

编辑：jq