闲聊汽车芯片的信息安全需求和功能

谈到汽车芯片的信息安全，估计大多数读者朋友脑袋里就会弹出HSM等字样，马上就会联想到TC3xx、S32K3等等芯片的HSM子系统。

但看了那么多家的HSM子系统，我有点困惑：为什么这些子系统设计思路都差不多。

只能从源头找答案，这又得回到需求分析环节，从需求来推导出信息安全功能。

由于汽车ECU种类太多了，细化每个系统的需求对我来说太难，所以我在想能不能抽象出一个通用方法来做出需求假设。

思路是这样：ECU通常想要保护的资产是什么？ECU会遇到什么通用威胁场景？落实到芯片上有哪些具体机制（软硬件都可以）来减少或者防止威胁？

不管是什么汽车ECU，受保护的资产大致可归为三大类：代码、运行时数据、密钥\身份标识等敏感数据。

这些资产的哪些方面需要被保护？自然就是它们的完整性、可用性、机密性、真实性等。

我们通过假设威胁场景或者提问的方式，来进一步推导芯片信息安全功能。

1.如何保证ECU每次都是运行目标应用程序

从另一个角度看，这个问题就是在问如何保证我们自己代码的完整性、真实性。

完整性确保代码没有被篡改，真实性确保是自己的代码。

这就需要信息安全最基本的一项功能：安全启动，它通过构建信任链来验证每一级程序的签名，确保程序数据的完整和可信，以防止在启动过程中运行了未经授权的程序，在启动的任何阶段，如果签名验证失败，则启动过程会被终止。

安全启动只是被动防止不受信的程序运行，但如果攻击者通过调试口来访问代码、数据，怎么办？

很明显我们要考虑是否禁用调试接口，再不济也要利用密码机制、C&R机制来加强调试权限管控。

例如STM32H57H提供了debug authentication机制允许受信任的调试器在不泄露敏感信息的情况下重新打开访问，RH850 U2A也提供了相关机制来允许内核调试。

调试口我们是管控了，但针对软件漏洞，一方面我们考虑要把密钥、敏感数据存到一块独立区域，另一方面我们还需要对这些数进行加密存储；

那么这就要求芯片在设计时就要考虑到这部分内容，单独设计独立存储区域，且这部分区域仅有部分Master能够访问，安全存储的需求就诞生了。

但这还不够，因为软件漏洞已经被发现了，就很有可能通过操作CPU、DMA等Master来访问到这些资产。

因此，就需要一个独立的受信安全执行环境，只有在受信环境里运行的代码才有资格访问资产，例如有独立内核的HSM，如果没有独立内核有类似ARM的TrustZone机制也可以。

我们考虑了调试口、安全启动、软件漏洞，但是在软件更新时，如果保证待更新软件的正确？

这就需要对待更新软件进行签名，类似安全启动保证完整性和真实性，如果安全等级要求再严格，我们可以再对其进行加密。

上述操作可以满足我们对软件更新最基本的信息安全要求，但结合目前智能网联的大趋势，对OTA的速度要求是越来越高，如何保证在已有成熟协议上拥有比较好的性能？

芯片设计上可以综合考虑IPsec、MACsec、TLS等硬件加速IP或者软件优化。

除了车云通信，还有车内ECU间通信，目前CAN、UART等还是比较常见，如何保证数据的完整性、真实性甚至机密性？

毫无疑问，如果有硬件加速引擎来支持MAC、Hash等算法，可以有效提升通信报文的验证效率。

这类共性问题总结出来的安全启动、安全调试、安全升级、安全通信、安全存储、安全执行环境等需求最终演变成大差不差的芯片共性信息安全功能，所以才有HSM子系统架构都比较类似的情况。

突然想到还有一些跟芯片密切相关的，例如如何防止侧信道攻击、如何防物理攻击，后面再学习学习再说。