闲聊汽车芯片的信息安全需求和功能
目录
1.如何保证ECU每次都是运行目标应用程序
2.攻击者通过调试口来访问资产，应该怎么办？
3.攻击者发现了软件漏洞，我们密钥、敏感数据等资产还安全吗？
4.软件更新时会遇到什么问题？
5.小结
谈到汽车芯片的信息安全，估计大多数读者朋友脑袋里就会弹出HSM等字样，马上就会联想到TC3xx、S32K3等等芯片的HSM子系统。
但看了那么多家的HSM子系统，我有点困惑：为什么这些子系统设计思路都差不多。
只能从源头找答案，这又得回到需求分析环节，从需求来推导出信息安全功能。
由于汽车ECU种类太多了，细化每个系统的需求对我来说太难，所以我在想能不能抽象出一个通用方法来做出需求假设。
思路是这样：ECU通常想要保护的资产是什么？ECU会遇到什么通用威胁场景？落实到芯片上有哪些具体机制（软硬件都可以）来减少或者防止威胁？
不管是什么汽车ECU，受保护的资产大致可归为三大类：代码、运行时数据、密钥\身份标识等敏感数据。
这些资产的哪些方面需要被保护？自然就是它们的完整性、可用性、机密性、真实性等。
我们通过假设威胁场景或者提问的方式，来进一步推导芯片信息安全功能。
1.如何保证ECU每次都是运行目标应用程序
从另一个角度看，这个问题就是在问如何保证我们自己代码的完整性、真实性。
完整性确保代码没有被篡改，真实性确保是自己的代码。
这就需要信息安全最基本的一项功能：安全启动，它通过构建信任链来验证每一级程序的签名，确保程序数据的完整和可信，以防止在启动过程中运行了未经授权的程序，在启动的任何阶段，如果签名验证失败，则启动过程会被终止。
2.攻击者通过调试口来访问资产，应该怎么办？
安全启动只是被动防止不受信的程序运行，但如果攻击者通过调试口来访问代码、数据，怎么办？
很明显我们要考虑是否禁用调试接口，再不济也要利用密码机制、C&R机制来加强调试权限管控。
例如STM32H57H提供了debug authentication机制允许受信任的调试器在不泄露敏感信息的情况下重新打开访问，RH850 U2A也提供了相关机制来允许内核调试。
3.攻击者发现了软件漏洞，我们密钥、敏感数据等资产还安全吗？
调试口我们是管控了，但针对软件漏洞，一方面我们考虑要把密钥、敏感数据存到一块独立区域，另一方面我们还需要对这些数进行加密存储；
那么这就要求芯片在设计时就要考虑到这部分内容，单独设计独立存储区域，且这部分区域仅有部分Master能够访问，安全存储的需求就诞生了。
但这还不够，因为软件漏洞已经被发现了，就很有可能通过操作CPU、DMA等Master来访问到这些资产。
因此，就需要一个独立的受信安全执行环境，只有在受信环境里运行的代码才有资格访问资产，例如有独立内核的HSM，如果没有独立内核有类似ARM的TrustZone机制也可以。
4.软件更新时会遇到什么问题？
我们考虑了调试口、安全启动、软件漏洞，但是在软件更新时，如果保证待更新软件的正确？
这就需要对待更新软件进行签名，类似安全启动保证完整性和真实性，如果安全等级要求再严格，我们可以再对其进行加密。
上述操作可以满足我们对软件更新最基本的信息安全要求，但结合目前智能网联的大趋势，对OTA的速度要求是越来越高，如何保证在已有成熟协议上拥有比较好的性能？
芯片设计上可以综合考虑IPsec、MACsec、TLS等硬件加速IP或者软件优化。
除了车云通信，还有车内ECU间通信，目前CAN、UART等还是比较常见，如何保证数据的完整性、真实性甚至机密性？
毫无疑问，如果有硬件加速引擎来支持MAC、Hash等算法，可以有效提升通信报文的验证效率。
5.小结
这类共性问题总结出来的安全启动、安全调试、安全升级、安全通信、安全存储、安全执行环境等需求最终演变成大差不差的芯片共性信息安全功能，所以才有HSM子系统架构都比较类似的情况。
突然想到还有一些跟芯片密切相关的，例如如何防止侧信道攻击、如何防物理攻击，后面再学习学习再说。