网络安全：全流程开发-CSDN博客

本文链接：https://blog.csdn.net/Galaxy_0/article/details/141431635

1、概述

从一开始的话是由奥迪、宝马、大众，戴姆勒等公司，他们成立了一个联盟，推出了一个叫做SHE的这样一个标准。这个SHE它的全称叫做secure hardware extension，就是安全硬件扩展模块，它是最早的一种类型。SHE它相对而言是比较简单的一种硬件安全模块，它常规只能支持对称的AES-128的这种密码算法，而且最多只能支持到20把密钥。也就是在我们的这个芯片里面，SHE模块的话，它的性能是相对而言比较有限。首先它支持的算法只有对称的AES-128，并且它能够支配来做这种密码学运算的这个密钥也只有20把。

EVITA所推出的这三类的HSM，它会有一些区别，分别是full、medium和light。从字面上大家能够看到，从light到medium到full，这个等级是不断递增的，它所支持的这个功能也会逐渐的丰富。比如说我们在EVITA medium和full这两个类型的HSM上，full拥有的资源会比light更多，甚至于light它都没有内置的RAM和NVM（Non-volatile memory）。

同样只有在medium和full这两个等级才会有我们的CPU，有了这个CPU的话，我们可以在这上面去做一些自己的代码开发，这样的话我们能够更好的来使能我们这个HSM当中的一些特性，同时我们只有在EVITA full这样一个等级的HSM当中，才会有非对称算法的这些加速的引擎，我们有了它之后，是可以来做一些密码学运算的这些加速的。

2、SHE

SHE它所实现的功能，我们概括起来其实就两个，一个叫做保险箱，我们可以把一些密钥存储在这个安全区域里面来做一个安全的存储，之所以说它安全，是在于往这里面存的这个东西，存的一些密钥，一般情况下是不允许去把它读出来的，而是我们也可以利用它来实现一些密码学的运算，也就是当我们要去做一些加密解密数据的时候，我们就把数据给到我们的这个安全区域，由安全区域自主的调用预存在芯片里的密钥，以及去使用对应的这些密码算法加速引擎来执行运算，最后他只是把结果给过来，整个过程当中，密钥它是不会出我们这个安全区域的，这个就是属于保险箱的一个作用。

刚才也说到了，就是我们这里面可以有一些密码算法的这种加速的引擎。这就是应用安全模块的一个另外一个作用，它本质上就是一种隔离的这种概念。我们把一些密码运算的这种敏感的这种运算放在一个专门的区域里面来执行，使得它独立于我们正常的这个业务区域来实现我们的安全的这样一个理念。

在SHE这个标准上，我们刚才有说到，它只支持十把密钥，后来的话做过一次迭代叫做HSE+，它会有额外的十把。那也就是总共有20把额外的密钥。每一个密槽的话，它是有各自的用途的，十把槽每一把槽各自所做的运算，在标准里面都已经定义好了。举几个例子，就好比我们住的酒店，每一个楼层它会有不一样的用途。比如说最下面一号的就是我们的这个大厅，二号是运动房，三层是餐厅，四到再往上的话，就是我们的这个客房区。

在SHE的这个标准里面的话，它的一号槽的话默认是叫做主密钥master key，就是有点像我们看的这个魔戒，有一个指环王，它是能够号令群雄的，那么这个master key它是可以用来更新后续所有的密钥槽，这个密钥它是号令天下的那一把密钥。然后二号槽的话，它主要是用来做这个安全启动secure boot。然后三号槽的话就是我们常规的那个boot MAC，我们在做这个对称，基于对称算法来做这个安全启动的时候，我们是需要有一个基准值的，这个基准值我们是存在这个三号槽，把它当成是一个密钥，然后4到10是用户可自定义的这种密钥，user defined。所以在这样一个设计下，我们只能按照它既定的这样一个密钥槽的这种存储方案来指派相应的密钥存在对应的槽里面，才能使得我们的这个产品在实现一些安全功能的时候，能够比较能够正确的来实现。

常规意义上来讲的这个AES128的这种算法，它正常的密钥是16个字节的，按照序的这个格式，它不会出现这个标准的16字节的这样一个密钥。而是把那把密钥派生成M1到M3，也就是我原本一个16字节的这个密钥。我们是靠M1，是十六字节，然后靠M2，三十二字节，然后再靠M3，一个十六字节来存储的。

要让这个序去认得我们要往里面写的这个密钥，首先得把16字节的这个密钥派生成M1到M2到M3，然后我们再利用这个载入密钥的接口，把M1到M3载入到SHE里面，它会在自己的这个模块里面去，把它复原成原始的16字节。之所以这么操作，它是可以保证我的这个密钥在传输的这个过程当中不会特别容易的被攻击者破译我原始的这个密钥是什么，而是用这个M1到M3的这种方式来弄。这种方式的话能够比较好的来保证我们这个密钥在传输整个生命周期过程当中的一个安全性。但是这个也会给开发者增添不少麻烦，也就是我们的这个派生，包括它原本16字节这样一扩展，变成了64个字节。这样的话我们在传输过程当中的一些时间的这种开销会相应的增大。对于我们做密钥的时候的一些报文，也会有额外的这种空间的这种占用的这种要求。所以这是我们在这块的一些SHE的格式，它的一些优势和劣势。

后来我们在08到11年，欧洲那边推出了一个叫做EVITA的项目。这个项目它是针对于我们车载网络的这个体系，一个电子电器架构做了相应的这一些网络安全方面的一些探讨。在整个项目过程当中，首先它针对的是我们这样一个车辆车上的一种功能域的这种电子电气架构。他会去划分动力，车身、电子底盘，还有一些信息娱乐的这种域。围绕这个架构，他们来探讨一下在整个电器架构里面会有怎样的一些安全威胁，以及我们怎样去做这种网络安全的这块的一些防护。

在整个项目里面，我个人觉得有一个非常有意义的就是打造了这样一个车内安全模块的这样一个架构。跟刚才SHE的那个架构很像，它是独立于我们正常的这个业务应用核心，也就是我们常规讲的这个host，会额外再开辟出一个专门的HSM的模块，来做一些专用的这种密码学的运算。它的作用也是刚才我们所说的两个。第一个叫做保险箱，我们可以利用这个HSM模块所能访问的一个专属的一个内存分区域，来存储我们的一些密钥证书或者一些敏感数据，我们可以在这里面来做一个安全存储，同时这里面可以去做一些密码算法的这种加速的引擎。

因为一旦你的这个芯片选定了之后，它其实是会决定你整个产品功能的一个实现的一个天花板的。

我们在做这个产品开发的时候，要重点关注一下我们所选的这个芯片，它所支持的这样一个安全特性是什么？HSM的话刚才也说到了，就是包括light medium和full这几个类型。不论是怎样的一个分类，它实际上本质都是主打一个隔离的一个概念。对于light，它其实对标的是我们老版本的she的这个标准，它只支持对称算法，也就是AES128，不支持这种其他的这种二次编程，还有非对称算法的这种运算。所以如果我们选了这个EVITA light的这种芯片，不好意思，你只能用这个对称算法来做。就它决定了你的天花板。你没有办法在这上面去做这些非流程算法，以及去做二次编程。

而到了medium这个等级的话，它会首先它是往下兼容的，它里面也有AES128的这种运密码的算法的这种运算的加速,同时它这里面的话会有自己的CPU，会有自己的RAM，也就意味着我们可以把它当成是一个单片机，我们可以在这上面自己去写一些程序，来实现我们更丰富的这样一些密码学的这种功能。

而到了full这个等级的话，它同样也是会向下兼容兼容light，兼容medium。同时它会有额外的椭圆曲线算法的这种硬件加速，也就是我们在medium层面它同样可以实现非对称算法。但是它没有这种硬件加速所实现的那些密码学非对称的这种算法，它的这个性能会弱于我们有硬件加速的这种full等级的这的密码学算法。所有的这些跟我们刚才讲的一样，就是属于隔离的一个概念。我们应用核心要执行的一些密码学的运算操作，他会把指令和数据发给我们的这样一个隔离的区域，再由他把运算结果给出来，这就是我们HSM他的这样一个使用。

讲了这么多铺垫，实际上我们在说我们用的这个ST chorus的这个芯片SPC58系列的这样一个架构里面，它其实是内嵌了HSM。跟刚才我们所讲的很类似，就是会在我们正常的这个应用核心之外，再开辟出一个HSM来通过我们芯片内的这些总线来实现的不同模块之间的一些通讯，取决于我们所选的这个SPC course这个芯片它会有不同的EVITA的产品的这种类型和等级。

现在大家去看一些芯片厂的这些解决方案，大家已经不流行提我的这个是遵循she的这个标准的，一般都会去提我们这个芯片是支持EVITA哪个等级的这个标准。我们所有的这个EVITA low，medium和full都是可以用软件的方式来模拟实现这个she的。所以现在大家如果选的一些芯片还用这个she的话，已经是属于怎么说呢？有点过时的那种状态。但不是说大家不能用这个东西啊，照样可以用。只是它的这个性能，还有它所支持的这个功能已经不太能够满足我们现在行业里面对于一些安全功能的这种应用了。

我给大家举个例子好了，就像我们所说的，这个安全刷新，通常我们会走这种非对称算法。如果我们继续选择用这种she这种对称的算法来做的话，那么在不论是在这个性能上，还是说实现这个功能的一个完备性上，其实都是会有相应的打折的。所以现在大家去看这个she的话，一般不会有厂商去highlight自己的产品，是遵循she的这个标准。而一般会讲EVITA这个标准。而EVITA这个标准通常是能够向下兼容she的。

刚才我们有说到，就是取决于我们所选的这个SPC58系列的一个芯片，有的是chorus一兆的，有的是两兆的，也有四兆以及更多。我们可以看ST那边的这个芯片的技术路线，会发现在不同的这个family下，它会有不同的EVITA它的等级，我们就根据自己所选的这个芯片的这个型号。我们就能反向的推导出我们这个芯片它所支持的安全性能的一个天花板在哪，比如说你看到这个EVITA full，刚才我们也讲到了，就是你能自然而然反映到它这里面是有非对称算法的这种硬件加速的总体的性能会比EVITA medium和EVITA light要更好。而看到EVITA medium的话，你就知道它这上面可以去做这种二次编程，但是它不支持这种非对算法的这种硬件加速，所以它的性能相对而言是居中的。

这边大家在用这个SPC58系列芯片的时候，这边有一个坑，我给大家稍微分享一下。大家如果选用了chorus两兆的芯片，大家注意一下它的这个HSM会有一个致命伤。我们实际上来用的时候，所选的那个host和HSM。他们其实在整个的内存空间里面，它其实是同一片的flash，这样一个问题只出现在chorus两兆的一个芯片，也就是在我们整个的这个内存空间，flash的这个空间，我们是靠host和HSM共同去通过我划分不同的这个片区使得他们来访问自己专属的那块地址，互不干扰。那么他在这个flash的地址的时候，他的这个flash设计存在一个上硬伤，也就是哪怕你划分了不同的flash的区域，在一些极端的情况下，当我的HSM和host同时在执行。比如说我的一些加密解密操作的时候，他们要同时去访问我的某一个flash区域里的block，或者bank的时候。这时候它的这个芯片设计的时候是不允许同时会有对某一块区域有这种读和写的这种操作的。就这两种操作它是不允许同时对某一个black 、bank做访问。所以我们在使用这个或者是两兆的时候，我们要在设计上去规避一下，就是会不会出现host和HSM对同一片flash区域。哪怕你这么划分了之后，但是它因为它分同属于同一个bank，它是没有办法同时的去访问某一个特定的地址的。

SPC的这个HSM的话，大家可以根据我们所选的这个芯片的情况，是能够反向查到我们HSM它所遵循的安全的等级，这就决定了我们的功能的天花板。在整个的理念上，它同样也是独立于host之外，开辟了一个HSM这样一个核心。然后在这里面的话取决于我的不同的EVITA等级，它里面所支持的这个密码学的引擎。还有它这里面所占用的这个flash或者这个CPU，它其实是不一样的。

在整个隔离上的话，它是会靠自己host跟HSM之间的一些中断，还有共享内存的方式来实现这种数据的交，也就是host要让HSM来做一些运算，它会首先把待计算的这些数据放在一片共享内存，并且触发HSM的一个中断，由他通知他去我们的这个共享内存里面去取数据，然后再做相应的运算，再把运算好的结果在同样放到这个HSM的共享内存里面，再触发一个中断通知host来取相应的数据。

如果是我们这里所选的这个SPC58，这一款的芯片的话，它遵循的就是HSM的EVITA的media。他就是在这个过程当中做了一些隔离，我们通常这个HSM它的核心是不允许外部的调试器随意的去访问的。这就是他所实现的这样一个安全的理念。对于HSM里面的这些密码学的引擎，它只能为我们HSM的这个核心来访问，host是没有办法直接去去访问的。

我分两块来讲，首先我们来看这个HSM的fireware，对于ST的这个芯片，首先ST它自己有原厂的这个fireware，但是听我听到的版本是好像它的这个功能比较有限。哪怕它的这个HSM，它是full或者million，它本身这个软件所带的一些接口和功能，也没有把那个HSM给彻底完整的用起来，这是ST原厂的。

大家如果有比较多的预算，可以去找vector去定制我们course上的一些商业版的formal。常规的这个菜单里面都会有哪些呢？比如说我们可以去勾选我们要这个部件所支持的这个算法。比如说我们有对称算法的这个AES128，我也可以在这个菜单里勾选AES256，也可以去勾选一些非对称算法，比如说我要5把RSA2048密钥的密钥槽，以及我十把ECC256椭圆曲线算法的这个密钥槽。我们可以在这里面去勾选对应的菜单，以及我们可以去勾选一下它有没有一些应用功能。比如说我得让HSM勾选安全启动那个功能，我才能用这个HSM来实现我整个系统的安全启动。

第二步事情是需要我们在这个host里面去集成一些安全驱动或者一些AUTOSAR的这种模块，使得我们的这个HSM的这些接口，能够按照AUTOSAR接口的标准来提供给我们的这个BSW底层软件，或者我们的这个应用层软件。在这个过程中，很关键的一个就是cryptodry。这个cryptodry如果没有的话，我们就只能通过很原始的方式跟让我们的这个应用程序去直接访问fireware的这个接口。这种它不利于做成标准化。而有这个cryptodry的话，它可以把这个fireware的这个接口再重新包装一场，变成能够跟我们Autosar BSW像是CSM模块或者一些密码学接口的模块的一些天然无缝衔接的这样一些奥特萨的接口。这样的话对于开发者而言是会比较友好的来使用这个HSM的这些功能。所以我们后续的这块也需要去配置一些这种奥特萨的软件模块，以及去集成我们对HSM的这样一个底层的驱动。这样的话我们两部分结合起来，才能把这个HSM的能力，把它彻底的用足。

AUTOSA里面能够实现跟HSM做交互的这样一些模块。第一个模块叫做CSM，叫做crypto service manager，第二个叫做crypto interface，第三个叫做cryptography driver。还有就是我们的这个HSM的fireware。如果我们把整个ECU抽象出这样一个模型，我们由硬件所提供的这个HSM，根据我们所选的这个安全模块的不一样，我们可以选这个内置的HSM，也可以通过一些底层的这种驱动去使用一些外置的HSM。

我不知道大家有没有听过一种叫做secure element，叫做SE，这种芯片，它是独立于我们的主控的MCU，主控的芯片。通过外挂一两个模块，它所实现的理念也是隔离，也就是我们可以把它当成是一个保险箱，我们把密钥安全的存在芯片里面，同时可以把它当成一个寄存器。我们所有的这些请求的操作，都是通过这些接口发给硬件安全模块，再由它来执行对应的结果，执行对应的运算密码结果反馈过来。

不论我们采取怎样的一些硬件安全模块的这种形式，我们往上就都会需要有这样一个cryptography driver来实现我们这个模块的接口的二次封装，使得它能够往上提供更友好的这样一些接口，比如说给到我们的这个crypto interface，然后再给到我们的这个CSM。

在CSM这块，它所提供的接口，包括这么几个，第一个叫做密钥管理，第二个就是任务队列的这种调度的这种接口，还有一些基础的密码学函数库。

大家不用觉得这个特别抽象，实际上这些模块在AUTOSA的BSW里面都有，只要我们买的AUTOSA的技术软件里面有这个模块的话，我们只要配一下就好了。那么它一旦配好之后，他其实对上提供的就是类似于这种函数，就是一堆的函数，它会有自己的命名方式，并且会有自己的这个参数定义。我们在实际使用的时候，就直接去根据我们的这个函数的这些接口的这种使用方式去配置对应的这些参数就好了，使用起来还是相对比较方便。

以上就是host的一些模块。之所以它的过程会比较特殊，是在于我们整体的HSM的和它的这个资源并不是无限扩大。它相比于我们MCU里的host，它的资源是相对是有限的。所以我们在这块的升级，它会有一些特殊性。它的特殊性是在于是说当我host发起对HSM的这个升级之后，他必须要考虑一个容错。比如说我们在大家可能都知道，我们这个刷新的一个过程，首先你得把老的这个物件给它擦除掉，然后再把新的给填进去。如果说我们HSM在这个过程中，你升级失败了，而我第一步把这个固件都给擦掉了，这样的话我下一次是没有办法再重新去对它做升级。

所以在这样一个资源有限的这样一个盒上，它的这个升级是需要做一些特殊的这种设计。这个过程是在于当我正常的这种情况下，我的HSM里面会有boot loader，也会有自己的这个应用程序。我要去做升级的时候，首先我会通知HSM把它升级的一个关键的boot loader 做一次备份，然后再切换一下我的这个HSM的一个启动的地址，我在把新的boot loader作为擦除掉老的boot loader，把新的boot loader给替换到这。那么在这一步操作，我们把这个HSM的启动地址切换到了这样一个back up的这样一个过程。

当我在擦除老的book loader，并且把新的boot loader 这个过程中，如果发生了一些意外，我的这一步留了一手的操作，能够保证我下一次上线的时候，我的HSM还是会有一段boot loader是能够运行的。这样的话我是能够当我发生这些错误的时候，我是还有办法能让HSM 继续升级。这个boot loader，因为它的资源有限，所以它会侵占一部分的应用程序。因为我要做升级的时候，我其实是不太care我的这个HSM的这个功能有或者没有的。于是做了这一步操作之后，我们会把新的当我这个boot loader升级好了之后，我会再同样的再切换一下HSM的这个启动地址，再更新这个application。这样的话就完成了这样一个HSM的一个更新。所以他的这个操作会考虑我们HSM上的这样一个资源的一个有限性，来设计我们固件的这样一个升级的策略。

而对于vector这块给大家分享一个安全启动的这样一个策略。对于一个严格的安全启动，我们首先会让我们host的那块的代码处于一个reset的一个状态，由HSM先行启动。这时候HSM会调用自己的这样一个固件里的这个功能模块扮演一个哨兵，他会去主动访问host那块flash当中的这个二进制的代码，把所有数据给到我们的这个HSM里面。用比如说用密码学算法，用CMAC来算一个结果，并跟我本地预存的这样一个参考值做比对。

当我的host那一块的代码，我算出来的结果跟我本地的这个结果是一样的。这时候我认为我host的那块的代码是可信。于是我就会释放我host那块，不论是boot loader或者我的application。通过这样一个哨兵的一道一道的检查，使得我们的这样一个host的那块的代码，能够在验证通过之后再行启动。这就是我们安全启动的一个严格的这种做法。

这种做法下，当我的这个过程当中出现了一些bug。这种严格的这种安全启动，会让我的host永远起不来。因为每次都是HSM先行把host那块的代码先hold住，让他不起来。当我这时候如果formal里面出了现了一些bug，算错了，使得我算出来的这个结果跟我预存的这个结果是不一样的。这时候我的host是永远不会启动它不启动我的boot loader就没有办法运行。

于是我是没有办法再通过软件升级的这种方式再更新我host的那块的代码，以修正我的这个错误的。这种是属于串行式的这种安全系统，这种是最严格而并行式的。这种和并行式的话他不会做的，而是host的那块跟HSM这边同时启动，并且后续的那块会有一些应用代码运行。这时候我的校验过程是需要host的那块去调HSM的接口，由他来做这样一个验证的。这时候就能规避掉刚才那个问题。但这种模式下我们是需要host的那块有一个专门的一个信任根来做这样一个接口的一个调用，使得他不会出现贼喊捉贼的情况。

这里我讲几个场景，生成密钥的那个操作。第一个场景是在于我们安全启动的过程，当我们在研发阶段配置或者在工厂的生产的时候，我们当我们切那个life cycle 的时候，我们的这个分布上它有一个逻辑，就是他会去检测一下我的安全启动有没有开启。如果开启了，他会在判断安全启动的那把密钥有没有？如果没有的话，他会这时候随机生成。所以通常我们用这个固件来做这种安全启动的时候，那个安全启动的一般密钥都是一机一密的，它都是在初次初始化的时候自动来生成。

第二个用途，当我们这个固件里面它有一些临时密钥的这种生成的这种诉求。举个例子，比如说我们的这个ECU要跟外部的这个，比如说我跟云平台去做一些通讯，或者跟手机或者什么的，做一些v to x 的这种通讯。这时候我们如果双方约定好，是会去协商这个密钥的。比如说我们的这个人跟我的这个ECU要去协商我当前的一个会话密钥。我们约定双方协商的这个密钥，每次就都基于这个，比如说椭圆曲线的这种算法。并且，我们做的比较严，就是用这种动态的这种密钥。我们可以靠HSM去临时的生成一堆会话的的这种公私钥对，这时候ECU可以生成一对临时的公私钥对，并且把公钥给到我们的这个手机这边，他同样会有自己的这个公私钥，然后双方交换一下这个公钥，然后再用密钥协商算法去完成彼此的这样一个握手，这种是第二个场景，就是我们有一些临时的这种绘画密钥要生成。并且我们约定的这个过程会需要靠HSM来生成一些临时的密钥，那这时候就会把它派上用场了。

还有一些，比如说我们的那个host 那块儿。当我的host 要跟外部去做，比如说我们的这个产品是车辆的一个密钥管理的一个中枢。比如说中央网关或者某一些这种车载计算的这种平台。我的这个产品扮演的是车上的一个密钥分发的一个中枢的这样一个作用。这时候我也可以靠HSM去派生一些临时的这种会话密钥，再通过host 派生给其他的这些ECU。

3、国密算法

就是国密跟这种国外的算法有没有什么区别？

只要他的这个部件支持，那你就可以在你的产品当中去实现这个国密算法。在技术上其实跟我们你比如说SM2，它其实就是本质上就是一个椭圆曲线的一个算法。SM3它就是哈希的SHA-256，SM4就是AES-128这个算法。所以在本质上，它其实跟这种国际算法没有啥差别，国密算法这边有一个特殊性是在于中国的那个密码管理局，他会要求厂商在市场上去宣传自己做产品，能支持这个国密算法上他要有一张国密二级的认证证书。所以你在技术上用软件也好，用各种各样的方法来实现，其实没什么难度的。但是难就难在你能不能拿到国密二级的证书，就有一个潜规则。中国这边虽然说我是开放包容的，鼓励全行业，国内国际厂商都来参与国民算法的推广。但实际中国那边不会给这种国际厂商去发这个国密二级的证书。因为他考虑到保护我们国产的这些芯片行业，所以你像英飞凌、ST、恩智浦，他们死活都拿不到这个国密二级的证书。所以哪怕他在硬件上，或者这些做软件的这些供应商，他们能实现这个算法，他们拿不到这个国密二级证书的。

所以我们将来在实现这个算法的时候，如果客户在提到了是说我要有这种国密二级的这种证书，技术路线基本上就确定了。你只能用这种外挂式的国产的SE的安全芯片。你如果要有继续用这种HSM那种方式的话，你只能是拿不到这个证书。但是你能在技术上实现，你就得跟客户那边去去谈那个偏差了。

国密二级这个证书其实没啥的，就比如说我们作为一个芯片厂，他可以国密局去申请。我想申请国密二级的证书，然后这时候他会提交所有芯片的那些收集材料，还有我们的一些生产，还有一些测试报告。由国密局那边去做一些认可。最后，他给你发一个证，就跟一个三好学生证书一样。这个就是会有一个厂商的产品认证证书的一个编号，有那个编号是值钱。

就可以理解，就是像国内这些SM234和那些ECC、AES差别就在于这个二级证书。

4、JTAG口调试

接下来看一看这个调试口锁定的这个功能。我们最常见的在汽车上用的就是这个JTAG了。

他简单来讲就是两个作用。第一个就是我们去下载程序，我们通过这几个数据输入数据输出等等一些接口，我们可以去下载那个软件到我们的这个芯片里面。同时我们可以用这个调试口去做这个在线的debug，来看我们芯片的运行状态，主要就是这么两个作用。在安全人员的眼中，这样两个特性其实可能会暴露很多的这些安全性的问题的，你比如说我们要下载软件，那我就把一个篡改的软件能够by-pass 掉你的一些身份认证权限，直接写到我们的这个芯片里面，达到篡改我们整个产品工作逻辑的这样一个目的。

第二个是我们可以去debug，这样的话我可以在不改变我代码的这种情况下，我来去监控你整个系统当中的一些资源。比如说我访问我host 那块的一些地方，或者我去做这个数据的提取。我们可以通过这样两个功能来达到很多的这些网络安全的这种不法的目的。对于JTAG的话，实际我们在这个产品上会有一些很明显的这种调试的触点，或者一些焊盘。

这个当我攻击者要去搞我们的某一个芯片或者某一个产品的时候，我最简单的我就是把外壳拆了。我来看你PCB板上有没有这些像是甚至于有一些白色的这种丝印，或者标识符，能告诉到这几个pin角都是干嘛的，甚至于我们可以哪怕我没有这些标识符，我可以通过这个芯片的这个手册去看几个pin角是干嘛的。

再不济，我们也有一些黑客的这种工具和手段能够去探测，比如说我在这个焊盘里面没有任何标志符，我来看哪几个pin角是实现什么样的功能。比如说我上电的时候，我的JTAG可能会有一些初始化。我通过示波器，我来看我哪个pin角是不是有这种规律的，这种时钟的这种波形，我是能够推测出对应的这些pin角是什么含义的。再不济我可以就傻瓜式的，我排列组合我就一个一个来试，对吧？那么这种都是属于我们JTAG可能会暴露出来的一些潜在的安全问题。

考虑到这些安全问题？很多的芯片厂在比较新的这些MCU上，会做一些额外的这种保护。像我们的电脑通过一些软件调试器能够去访问JTAG。我们芯片厂会在访问的这个接口路径上设置一道门槛儿，就跟我们进房间一样，我们会开锁输密码，或者有合法的钥匙。当我把这个就跟一夫当关，万夫莫开。当我把这个调试口管理模块的去配置好了，对应的这些密码或者一些身份认证的这种机制之后，它会去断开外部调试器，对CPU内部的这些资源的这种访问的这种接口。当且仅当我们成功的通过了这个身份认证之后，才会重新的把这个flash的这个区域把它合上，这样的话就能在我们的这个访问权限上做好这个管控，使得外部想下载软件或者通过调试接口去访问我芯片的这种资源不那么容易实现。

我们实际芯片能够提供的这种安全访问，身份认证那种机制有这么几种。

第一种，最简单的，我们来做这个口令，我在这里面写一个密码，就跟我们以前看那个动画片，阿里巴巴与与四十大盗，要说一个什么芝麻开门，对吧？以及我们一些以前老的电影里面有一些口令，要对个上联下联，我们最常规的就是要输入一个口令才能重新的去打开我们调试器对flash的这样一个访问的一个权限。那么ST那个SPC58的芯片大家可以去看一下DCF里面。我没记错的话，应该是在DCF里面可以去配这个jtag的这样一个密码。这样的话我们能够保护好我们的这个调试接口。

第二种机制，在一些芯片里面的话，它支持这个挑战应答，也就是当我的这个外部设备要去访问我芯片的资源的时候。我会建立跟外部设备跟我本机的一个挑战应答，也就是我会去生成一些随机数，或者有一些这种固定的这种挑战，然后他会需要外部设备去反馈一个与这样一个随机数或者挑战码相对应的一个应答challenge response。然后会由芯片的一个调试接口的一个管理模块去比对应答是否符合预期，来决定是否打开我们的这个调试口。

所有的这些认证，应答的机制，都是需要我们在研发阶段提前配置好我们的这个芯片里的一些功能。借此我们能够实现对于调试接口的一个访问控制。当然这种机制，比如说再选一些做一些其他产品，选一些新的芯片的时候，提前关注一下我们芯片它所支持的这个调试接口的一些保护的机制，我们得事先知道我们怎么样把那些安全的这些措施把它用好，把它用起来。这个是我们在做芯片选型的时候，作为安全开发人员要有意识去关注一下我们这个产品所提供的一些安全的功能。在配置这个的时候，有的芯片它是支持我通过不同的安全模式，就跟我们刚才讲的那个life cycle 一样。我们通过配置不同的安全模式，使得我的这个芯片它能进入不一样的认证的这样一个模式下，这样的话我们能够开启和关闭我们的调试接口的一个访问的一个身份认证的一个机制。

还有一类是做这个签名认证，数字签名有点像我们每个人的身份证，当我要去住酒店，或者我要去买一些火车票，我们会出具我们的这个身份证。对于jtag认证这边是相似的。也就是当我的外部设备要去访问我芯片的接口的时候，我会提前把我的一个数字证书发给目标的这个ECU，由目标ECU去验证这个数字证书是否合法，这种对于我们比如说一个产品，我们就拿BMS来说，当我们出货量达到100万台之后，我们完全可以用一对公私钥来做保护。你可以不做一机一密，这种对于我们管理这个密码材料或者身份认证凭证会相对有利一点。

这一类的这种认证，在一个典型的瑞萨的R卡的芯片，首先我们在研发阶段，我们会靠我们的一个密钥管理服务器去生成一对公私钥，我们会把那个公钥写入到我们的这个e fuse里面，作为一个信任根，e fuse这个概念，大家从字面上来讲就是一个电子保险丝。我们日常生活当中像是老式的那种保险丝，一般烧断了之后，那个保险丝就废了。所以这个在我们芯片里面所提的这个e fuse，它它所起的这个作用跟那种概念很像的。也就是我的这个数据只能往里面写一次，他就再也不能改了。

这种是一个很好的一种叫做信任根的这种特性。因为你要信任某一个东西，那他至少得保证他的这个完整性，不然他变来变去的，我怎么信任他？对于黑客而言，我可以去篡改这个数据的内容，使得我也没有办法去信任它。

在这个e fuse里面，我们事先会把那把公钥的哈希值，或者如果容量比较大的话，我们直接把公钥写到我们的这个e fuse里面。我们在做认证的时候，我的电脑会事先把我的那个认证凭证发给我们的这个ECU。这时候我们的调试口管理模块，会首先把e fuse里的公钥读出来，或者公钥的哈希读出来，他会去比对我们这个证书里面所携带的公钥，是不是跟我e fuse里的这样一个不可篡改的数据是对应的，如果是对应的，那我信任这个证书里的这个公钥，然后我再用这把公钥去验证我的证书是否合法。

就有点像我们住酒店，我们会刷身份证，在其他的刷我们的身份证那个设备，它会自动连到公安局的某一个后台，他会来判断一下这张身份证是不是真的。我们验证好的那把公钥，我们同样会去用它来验证我们这个证书是否合法，如果合法的话，那我就信任外部的设备，这张数字证书的持有者是可信的。于是我就打开我的这个jtag的调试接口，这样的话我们就能实现对这个接口的一个重新的一个访问了。

除了刚才的这个挑战应答，还有数字签名，还有口令这三种方式，我们一定会再关注一个问题。就是当我们的这个出货量特别大的时候，我们如果用相同的口令或者相同的密钥，就势必会带来一个潜在的风险。就是我的黑客，破解了一台汽车或者一个零件。既然你的产品用的这个密钥都是一模一样的，那么我们是不是就可以把这样一个密钥用在破解其他的这个零件上了？这种是属于我们设定这些口令或者认证密码的时候的一个很重要的注意事项。

就是我们如何避免木桶效应里面的一块短板，导致我整个系统都崩塌。于是我们会考虑做这一机一密的这种密钥。除了这个数字签名，因为数字签名我们常规意义上来讲就是一对公私钥，我只要保护好那个私钥，公钥丢出去无所谓的。但是这些挑战应答的这些密钥，或者这些口令，一旦被人家知道，那就这个身份认证机制就彻底报废了，所以我们会在这个情况下考虑去做一机一密，这个一机一密的话有两种方案。一种是我们通过这个随机数生成器来派生，这个怎么来做呢？就是当我们在我们工厂批量去生产零件的时候，我们就在我们工厂部署一个密码机或者服务器。我们每生产一个零件的时候，我们随机生成一个密钥或者一个口令，我们把它写到我们的这个调试口的这个模块里面。这样的话是不是我就能做到每一个零件有不一样的密码了，这种会给我们的工厂是有一些特殊的这些设备或者服务器，会要重新去买，去部署。

另外一种，我们可以利用这个零件号去派生，因为我们每个芯片或者某一个零件出厂都会有自己的一个唯一的不重复的一个序列。也就是我们可以用一个密钥派生函数，结合一个主密钥来派生我们的这个调试的密钥或者密码，然后再写到我们的这个芯片里面，使得来做这种一机一密。这种的好处是在于我不用管特别多的这些密钥。比如说我生产了10万个，那我的随机数至少我得存，不然我后面返工或者查问题，我得找到我原先锁的这个调试和密码。那这种方案下我要管很多的密码，所以我们对于这个服务器的要求会有比较大的存储容量或者空间的这种要求。对于这种派生的话，我只要管这个密钥派生函数的一个主密钥就可以了。我不用去记N多个的密码，只要我有办法能够读出这个零件号，我可以实时的利用这个函数来派生我们所有的这些密码，这种的两种方案都可以取决于咱们的一个实际的一个情况。

当然我们对于这个调试接口，我们还可以去做这种一次性的这种熔断，就是彻底没有回头路的。也就是在我们的工厂，我们可以用这种激光，直接去物理破坏我们这个芯片调试接口。这种就是彻底的一次性的。如果说我们要重新去打开这个调接口的话，我们是没有办法再弄的。因为它从物理上就把那个pin角给断开了，这种会对我们的这个芯片造成一些物理的这种损伤，所以不推荐大家来做。

还有的这种JTAG的这种保护，我们可以去把一些选择一些BGA或者LGA封装的这种芯片。我们把这些pin角隐藏在肚子里面，这种只能在一定程度上削弱被探测被破解的这种风险。他不能彻底解决所有的问题。同样的，我们要留意一下，就是不在我们的这个PCB板上有这些明显的这些标识符，或者一些这种指示性的这种丝印，这样的话也能缓解一部分被探测

OTP它是属于一种特性，叫做one time process，只能写一次。所以衍生的概念比如说OTP的区域或者OTP的某一个寄存器是OTP的，它更多的是一种属性，而e fuse 是一个专门的一个地方，它具备OTP的属性，但是芯片或者某一些这种当中的一个专用的一个区域，就数据往里面写，就只能写一次。我可能会把它定义成OTP是一种属性，e fuse是一个专用的一个区域。

E fuse你可以把它理解成是一个仓库，刚才我们给大家举的那个例子，是在这个仓库里面，我们放了一个公钥，这个公钥会用于我们做这个jtag这个认证过程当中，相当于它就是一个仓库，我在做这个认证的时候，我会从这个e fuse 一次性的区域里面读一个东西，我来做验证。

我往e fuse 里面写东西，不代表我能直接开启jtag 的那个锁，他可能还要去配置芯片的其他的一些区域。

5、安全刷新

安全刷新我们分两个词来看，一个叫做安全，另外一个就是叫做刷新。我们实际在车上不论是什么芯片，一般都是支持这个刷新功能，它可以帮我们来修复问题，修复bug，修复漏洞，也可以帮我们去做这个功能的升级和迭代。既然这个功能这么好，但就跟一个双刃剑一样。我们实际上而言，我的刷新的操作，其实里面也会蕴含很多的这些安全性的这种风险。一方面我们可以把原先的这个数据，通过这种刷新的指令，把它擦掉。这种大家可以想一想，就是我们的某一个ECU，我通过一些擦除flash 的这种指令，我是不是可以发动这种拒绝服务，这样的话你的整个产品的功能全都被我擦掉了。

第二种是我们可以在这上面去写入新的数据，这个新的数据比如说我作为ECU而言，收到的东西，如果不做判断的话，其实就是一对二进制数，所以在这个过程当中，我的黑客其实是可以去篡改我的这个数据。使得对于ECU而言，如果不做额外校验的话，我就会误认为收到的这个数据就是一个合法的一个数据，这就是我们因为刷新功能作为一个双刃剑所带来的一些潜在的就这种影响。

那么我们ECU这种刷新的，通常现在行业里面比较多的，像是我直接通过这个芯片的调试接口jtag。我们做这种芯片的这种直接的烧录，这种烧录通常是可以by-pass掉所有的这些安全机制的，当然那个jtag的那个锁肯定是要过的一关，就是你哪怕你去做一些身份认证，或者一些数字签名，你在应用层做的这些东西，我通过这个芯片的直接烧录，就是可以直接by-pass掉的，因为我的这个芯片这时候都没有运行，你何谈去做这种应用层的这种认证。

还有的是我们通过这种OBD接口，我们的这种刷新设备，通常这背后是走UDS的这种刷新协议，我们来支持我们的这个ECU的升级。还有的是通过这种OTA，这种OTA的这种方式，通常是中间会有一个OTA manager 的这种角色，要么就是t-box，要么就是网关由他扮演一个刷新设备，直连到我们的ECU去做这个刷新，这块可以走UDS，也可以走非UDS，所以这是我们汽车上常见的这种刷新的这种过程。它能修复系统缺陷，也可以帮助我们来做这个产品的功能迭代，来提升我们的这个产品的一些使用的这种用户体验。

我给大家介绍一下，我们的这个UDS的刷新。首先我们的ECU里面的话会有对应的boot loader。我们的boot loader 它就是我们ECU内部的一个刷新的代理，它所承载的功能，一个是对外支持我们的这个UDS的这些协议，外部通过UDS的协议，把一些数据给过来，我的boot loader它是有办法去解析，去提取里面的一些关键的数据的。第二个功能，它是可以有这种flash 的这种驱动，它可以去把应用层的这些数据把它擦掉，以腾出空间把新的数据往里面填。所以在整个ECU当中，现在那个boot loader是很关键的一个软件组件，它可以来帮助我们实现软件升级的操作。

在整个的这个刷新的这个过程当中，既然boot loader扮演那么重要的一个角色，我们实际上而言是会对boot loader潜台词会有一个不应该被更改的这样一个属性的一个要求。我们从传统意义上来讲，这个boot loader不应该被更改，有几种实现方式。第一种是不是我们就设计的整套的这个刷新流程，是不会对boot loader这一块的地址段去做更改的。这种相对而言会比较弱，因为它是靠我的软件的这种策略来做的。

第二种是我们直接在我的某一个flash的区域去配置这个OTP的属性，刚才我们有说到这个OTP的这个属性，我们直接去把某一块flash的地址段，我们去配置这个OTP的属性。那么这个地址段，就把boot loader那块，就直接覆盖掉了。但我相信现在不一定会有Tie one，就是这个开发者或者Tie one去做这么决绝的操作，因为我们很难保证100%我的boot loader不出问题。所以你把这个芯片的boot loader做成OTP，那你售后如果要去查问题，或者要去做一些零件的这种返修，那么我的这个产品就彻底报废了。我没有办法再去做这个返修。

所以对于这个安全刷新，我们会有若干的这种注意事项。像我们在做这个靠boot loader这边来做刷新的时候，比如说我把这个boot loader做成特别简单，我们把它做成这种OTP的，然后我们靠一个临时的在RAM里的这样一个flash driver，再来做一个小的一个代理。当我也就是我的boot loader做的简单一点，使得它不太容易出问题，或者我们做的比较稳定,我们实际的刷新的操作，我们靠一个flash driver这边来做，使得我们的刷新的过程能够不容易出问题。

讲完了我们boot loader本身，对于内部的这种flash的这种管理，还有他的一些刷新的操作，我们还要去关注一下他对外所承载的这种UDS的这种协议。像大家应该不陌生，像什么10服务，11服务、0x27服务、31服务，这个都是我们常规的这种UDS刷新过程当中会用到的一些诊断服务。作为刷新的这个设备，我们会有这种功能寻址或者物理寻址来要么做这种并行刷新，要么走这种点对点的这种单点的这种刷新。

大家如果上过一些密码学的这种课程的话，会知道CRC的这种校验其实是很弱的。首先它的这个算法是公开，并且通过这种多项式的这种运算，其实是很容易就伪造的。

我们可以在后续的这种刷新的这种概念上，去考虑引入一些升级版的这种密码学的这种运算。像是走这种CMAC，我们每次传的这样一个data block，一个数据块，我们在背后带一个CMAC，或者我们系统的性能开销比较充裕的话，我们可以做这种数字签名，都可以。所以取决于我们的这个应用场景，我们在每一步这个操作的时候都可以去做这样一个包的一个完整性的一个校验和检查。最后我们在刷新完成之后，我们切换一下我们的这个诊断setting，并且把这个通讯、DTC clear掉，这样的话就能完成我们整个的一个刷新。

稍微总结一下。首先我们要做刷新，ECU里面要有boot loader，这是一个刷新的代理。同时我们在整个刷新的流程当中，走UDS的这种话，你得切换session，做这种通讯控制，做身份认证，传数据，校验数据的这种完整性，以及最后我们切换回我们的这样一个默认的一个session。

我们接下来来看一看这个安全刷新怎么样来操作。通常分两步，第一步我们在刷新之前，我们要用一些密码学的手段去签发我们的这个软件包，我们通常推荐的一个做法是要有一个密钥服务器，这个密钥服务器里面的话会管理我们签名用的这个公私钥对，其中的私钥会靠这样一个密码机来做这种安全存储。这种是类似于我们HSM的这样一个操作，只是它在我们的这个IT环境下是一个专门的这种服务器，大家可以把它想象成是一个保险箱，也有这种密码学的运算，一个寄存器。

作为开发者，我们每次编译好的这个软件，会到我们的这个密码机里面去走一遭，我们的密码机会事先用私钥去对我的软件包做一个数字签名，相当于盖了一个章。这个盖章的操作会让我们的一个软件变得可信。同时我们与私钥相对应的公钥会预置在我们的ECU当中，通常是放在我们的boot loader，或者我们放在那个HSM里面。我们要把这个公钥作为一个可信的一个待保护的一个资产，我们要做这种安全存储，使得它不被非法的替换。我们在实际刷新完之后，我们经过刚才那个刷新数据流的一系列这种操作，我们带数字签名的这个软件，会用我们预置在ECU当中的公钥去做一次验证。验证的过程。首先我用公钥解开我用私钥加密出来的这个数字签名。同时我跟我软件里的这个明文算出来的一个数字还要做一个比对，如果是一样的话，代表我的这个软件是可信的。

可信的两层意思。第一个，我的这个软件没有被非法的篡改，因为这个数字摘要和这个数字签名里的这个是对应的。第二个意思是我的这个软件来自于合法的签发方，因为我的公钥解开的东西，既然成功解开了，就代表它是由我这个公钥对应的那把私钥生成的签名。所以这两层意思都保证之后，我们就可以信任我的这个软件来把它写到我们的这个flash里面。这样的话我们就能信任我们的这个软件，包括它是一个完整的并且是可信的。这就是我们常规的刷新的这样一个操作。

我们会有一些的这种技术方案，首先我们最简单的就是一级签名。我们生成的这个软件就直接靠后台里的这个密钥去做一次加密，由这个加密得到的数字签名再与我们预置在ECU当中的公钥做一个验证，来判断我们的这个软件包是不是合法的。但是我们也可以做的更复杂一点，我们可以有这种多级证书。所谓的多级证书，就是我们根据一个根证书去派生各种各样的层级的这个证书，来形成一个证书的一个信任链。我们下一级的这个证书会依靠上一级的私钥来做签发。最后我们这种多级的这种证书的这种方案，会随着我们的这个软件一起把这个证书链，我们会在这个软件的基础上额外增加一个证书链。以及我们对应的数字签名，这种包的这种格式，会相对而言更复杂。

我们在做验证的时候，其实万变不离其宗，就是拿根证书逐级的去验证。我们最终用来生成这个签名的那个证书的里面的公钥是不是合法。如果是的话，我们再用那把最终的公钥来验证我们的这个软件包的完整性，还有真实性。

这个是我们多级证书的一个结构，就是靠上一级去签发下一级的这个证书。我们最后在刷新的时候，会把整个证书链一起下发给我们的这个ECU。ECU内部所存的公钥，是属于我们根证书的对应的那个公钥，我们就这么逐级的去验证。最后我们来拿到我们用于做软件签名的证书里面的这个公钥。我们来验软件包的签名是不是合法。

这个就是属于我们二级的刷新签名的这样一个例子。我们首先会有一个根，信任根我们是靠这个密码机来构建的，里面会有一个私钥。我们首先会把这个根证书对应的这个公钥放到我们的这个软件里面，一起下发给我们的这个ECU。同时我们会靠根去派生出一个用来做签名的二级的公私钥，我们会拿二级的公私钥专门来生成我们软件包，以及公钥对应的签名，然后把二级的证书一起预支在我们的这个ECU里面。

验证的过程，就是一个逆运算。首先我们用这个ECU的公钥去验证我们的刷新的这个公钥是不是合法。然后再用它去验证我们的二级的公钥。二级公钥验证成功之后，再来验我们的这个软件包和它软件包的签名是不是合法。这样的话就完成了一个信任链的一个传递。从根证书当中的公钥传递到我们的二级的这个证书。再有二级证书再来验我们的这个软件包的数字签名。

6、PKI申请证书

首先我们讲的各种各样的PKI也好，或者这种数字证书的这种发证机构也好。其实它的本质是要建立我们在一个公开网络上彼此身份的一个互信。像我们在日常生活当中，我们的身份证可以来佐证我们持证人的这个合法身份。他因此可以去办理酒店入住，或者去买高铁票，或者去办一系列这种事情。我们在这些场景下，我们第一件事情就是去出示我们的这个证书。

在整个的这个PKI的这个系统里面，我们会有一个中央的一个授信的机构，就是我们所说的那个公安局。这个公安局有一个门户网站，我们把它叫做RA。然后在这个门户网站之后，我们会有一个叫做CA的一个一个服务器。这个CA叫做certificate authority证书管理机构。你可以把它想象成我们整个PK系统的一个信任的核心，所以它相应的安全性的等级会更高，它主要是用来发证，以及去管理各种各样证书状态的这样一个终端。

作为后台而言，他会去管理一个叫做证书注销清单的这样一个东西。有点像我们政府去管理的一个失信人员名单，他会向社会去公开我们当下的一些失信人员。这样的话大家可以去那个网站上去查，当前有谁列入了我们这种失信人员的名单，这就是一个由政府信任背书的这样一个终端。

我们之所以相信这个PKI，就在于他扮演了我们数字世界的一个公安局。由于这个上面所做的一些安全等级保护，以及它基于一些密码学所构建的这样一个信任的一个链条。我们选择相信这个PKI这样一个中央集权式的信任中心。在这个后台，我们会有对应的管理员，作为我们某一个终端。这个终端有可能是我们某一台车，或者说上的ECU。他要在整个信任链条当中去注册自己的这样一个型号的话，他会介入向公安局去申请我们的这个证书的这样一个过程。

我们来看一下这个证书的申请过程。比如说我们的某一个ECU下线，或者我们某一台车下线，或者我们在售后买了一台车。我们要去绑定我们用户的个人信息，绑定用户信息跟我们的某一台车。

首先我会去像后台去申请我们的这个证书，申请这个证书我们在日常生活当中会填一张身份证的申请表。所以我们这样一个应用服务，它会提交自己的这个信息，同时它会生成自己的这个公私钥。我们把生成的这个公钥和和这个信息一起提交给我们的后台。私钥的话，由对应的应用服务自己管理好，私钥是永远不允许外发的，并且要妥善的存储好。因为私钥一丢，我们的这个非对称算法，他就没有办法再去完成对应的这种可靠的可信的这种身份认证了。

后台收到这个信息之后，这个门户网站就是这个RA叫做registration authority。他收到这个请求之后，他会去判断这个用户的申请是不是可以被批准。他的判断依据他会去审核用户所提交的这些信息，他甚至于他会去查我们这样一个失信人员名单上面有没有这样一个终端。

如果这样一个请求被审批通过的话，RA会发起给我们这样一个信任中心的一个请求。由CA的信任中心，对用户提交上来的这个公钥做一个数字签名，相当于会信任我们这个证应用服务所提交的公钥证书，以及他个人的这些信息。最后反馈我们的这个证书给到我们的这个应用服务，由应用服务再去接收。

在这个过程当中，CA会把自己的根证书一并的发给我们的这个应用服务，以及用根证书当中公钥对应的私钥所签名的用户的这个证书。所以他会给他发两个证书，一个是后台的根证书，还有一个就是用户提交的公钥所对应的生成的那张证书。这两个的目的，第一个是有了这个根证书，它可以用来验证由CA所授信别的这些节点的合法身份。同时后台所签发的这个应用服务的证书，可以用来佐证应用服务它本身的一个可信和合法身份，以向别人来披露，我是一个合法的人，合法的终端，这是这背后的一个申请过程，希望大家能够理解。

当我们出现了一些极端的情况，比如说我们的这样一个车被破解了，或者我的这样一个ECU被检测到破解了。这时候我们用户可以主动的去介入这样一个应急的事件。作为用户而言，他可以向后台去提交一个注销的一个申请。就有点像我们的这个身份证丢了。这时候作为用户，我知道我这时候的老的身份证就没有办法被信任了。因为很有可能有人会拿这个证书来冒领，冒充我身份去办事情，或者买东西。这时候用户会主动的向公安局提交一个挂失的一个申请，挂失的申请同样由这个门户网站RA来审批同意。如果他审批通过了，这时候他会核准当前的这样一个注销的一个请求。

于是，他会向这个信任中心去发起这样一个注销证书的这样一个请求。CA在这个过程当中，他其实不会做什么特别的密码学的操作。只是会更新一下我们的这个CRL就叫做失信人员名单，或者这样一个黑名单。于是他把这个注销之后的这样一个名单，在公开发到这个公网上，供别人来查询。并且有这样一个门户网站，再将更新之后的这个CRL这个证书注销清单，要么是提供给用户，就通过一个邮件或者一个信息告知到用户你的这样一个身份证已经成功挂失，同时他会把这样一个CRL的一个清单同步发到一个公网上。

那个公网是靠一个叫做LDAP的这样一个服务器来做管理的，这个的用途是在于当我有一个用户2的时候，如果说某人在发送用户一的这样一个证书给到用户二的时候。用户二可以去这个LDAP的网站上去查询一下这个用户一的证书状态是不是可信。如果发现这个用户的证书，其实已经注销了，那这时候他就可以不信任他。这就是我们在整个数字世界去维系不同节点和终端之间可信身份的一个过程。我们会有对应的这个证书的一个申请过程，也有我们去查询我们的某一个终端是不是被注销了这样一个过程，这种就是我们在数字世界里面去发证书的这样一个作用。

还有的一个场景是在于我们v to x 的这种场景。因为像v to x它一般而言是会牵扯到很多的这种基础设施的这种建设的。比如说红绿灯，比如说我们的某一个蜂窝通讯的基站，以及我们的这个车辆等等。

可以看到在整个和v to x的这样一个游戏里面，参与方其实是很多的。比如说红绿灯，可能是我们的某一个城市或者某一个地方，某一个区的这些交通管理部门。而对于车辆的这些基础设施，可能是某一个车厂。这里就会有一个问题，我们如何建立起道路交通，主管部门跟我们某一个车企的这样一个互信。

大家可以想一想，因为这两两类的机构，它它其实是会有自己的利益，以及主管的部门的。所以你很难要求说彼此都相信对方，因为可能会互不买账。比如说我作为某一个OEM, 我凭什么要听交通，一个管红绿灯的人，我来信任你的这个证书，或者我的一个做交通红绿灯？我凭什么要听你某一个OEM，而我不听另外一个OEM的。所以大家在自己的这种利益驱使下，其实是很难形成这样一个互信。在这种PKI的这种架构下，我们其实是可以去搭建这样一个层级的这种的。

比如说我们将来建立起一个国家级的这种中央的这样一个部门，由国家的这种交通主管部门去建立他所信任的这样一个公证书。并且有比如说工信部，或者交通部出来说好，我这次来做一个中立的裁判。你们所有的不论是叫管红绿灯的，做生产汽车的，你们统一的来听我的，我来给你们发证，这样一个权限，可以进一步的下放到我们的省市，或者说我们的某一个区委。再由下一级的这个证书，再去给当地辖区内的这些机构或者部门再来发二级的证书。这样的话这样一个PKI是不是就能形成一个层级化的这种树状的这种结构，那么在整个的这个PKI 里面，其实背后都离不开像是CA、RA或者一些证书管理清单。只是在我们的这种v to x的场景下，他可能会考虑更多的一些应用场景。比如说个人隐私，所以他这里面的话可能会有这种伪名证书。

这个伪名证书他发他也可以发证，但是，每张证书的这个有效期特别短。比如说一周他就要换一次，这个的目的是在于我们不会让一张证书长期的跟某一个终端做真实的绑定。之所以这么搞，是在于如果说我的黑客要盯准了某一台车，我完全可以不知道这个证书的，真实的ID我只要去查这个证书的一个指纹，我就知道它一定对应到某一个终端。

所以这种伪名证书它的用途就是在于我过一段时间换一个，使得你长时间在跟踪某一台终端的时候，过了一段时间跟踪的这样一个凭据就失效了。于是他会有这样一些中间的这种伪明证书，这个背后其实都离不开像我们刚才说的这样一些数字签名，证书链等等一些做法。只是它的这个用途，可以灵活的根据我们的这个功能场景做一些调整，这种是另外一个PKI的这种场景。在我们将来的这种v to x的这种应用场景下，会是比较好的，比较适用的这种信任的这种建立的这种关系。

在有了这些证书我们实际还有的一些场景，像是我们比如说我们的这个车要连后台，这时候我们可以去建立跟后台的一个TLS的一个握手协议。大家不要觉得这个很陌生。如果大家手边的电脑可以上网的话，大家可以去搜。比如说我们的某一个网站，比如搜索引擎或者百度，大家可以在浏览栏里面看到在整个地址。比如说百度，前面会有一个锁，那个锁就代表我们当前电脑在连这个服务器的时候，背后就用到了我们数字证书交换的这种TLS的这种认证协议。它其实是建立的是我们的电脑，要验一下我们这个网站是真的，这个搜索引擎网站还是中间被人家伪造了。

在这里面的话离不开我们的这个终端和服务端去交换彼此的一个证书。在收到对方证书的时候，我们会拿一个公钥的根证书的一个当中的公钥去验对方的一个身份是不是合法。对于我们电脑而言，这样一张根证书，是在我们电脑生产商生产这个电脑的时候，他就已经预制了一批根证书的公钥在我们的电脑里面。用这种方式来建立我们整个的身份的互信和授权认证的过程。

这里的话我要highlight一下，并不是所有的机构随随便便就能去生产这一类型的这种产品。上午我给大家介绍到了一个叫做国密二级认证的证书。这一类密码的产品是严格受国家管控的，所以某一家企业要去生产这样一些密码机，或者一些这些中央密码服务器，是需要在国家那边注册备案的。他会去给你发对应的这些产品的这种认证和主管部门授权的这些证书，你才允许在市场上去卖。这样一些密码机，其实就是我们刚才所介绍的PKI，或者CA背后的一个幕后黑手。你可以看到像我们这种密码服务器，这种密码机其实是可以布在我们的这个后台，来支撑我们刚才讲的那个CA去生成各种各样的公私钥去发证书，去做各种各样的这种安全存储的这些事情。背后都是有这样一些服务器和机柜或者电脑来拼接，搭乐高积木一样的把它存储起来的。同样在这边的话，他可以用来协助来做这些证书和密钥管理。

像派生一机一密的jtag 密码，我们完全也可以在我们的工厂去布设一台这种密码机，当我要去派生对应的jtag密码的时候，我们可以把这个生成密钥的这个请求发给这个密码机，由他算好之后，把结果给到我们，我们再写到这个MCU 里面，写到我们的芯片里面。这也是一种密码机的用途。

像密码机的这种常见供应商，大家感兴趣的话也可以去了解一下。成都卫士通、天融信，江南信安，先安科技等。

你像阿里云，我知道他们是能够提供这种线上的这种发证服务的。对于阿里云而言，他其实就是用这些乐高积木搭建起了一个发证的一个PKI的一个服务。你可以详细的去关注一下他们背后要搭建起那样一个在线的这种PKI的这种平台，可能背后都是会有这样一些机柜，一些密码机作为这个密码服务的这样一个核心来提供的，可能对用户暴露的这样一个接口，你看看不到这些密码机。但是你的一些请求的这种数据，最终还是会靠有阿里或者某一些这种在线平台维护的这样一个机房里的这些密码机来实现。

7、安全通讯

安全通讯常规意义上来讲，就是我们如果是狭义的来理解的话，就是我们通常讲的那个SecOC，车间安全通信叫做secure on-board communication，这是狭义的一个做法。但是广义的做法，这个的概念就大了去了。比如说针对于我们车上的这种CAN，他可能会有自己的这种安全通信的这种协议，针对以太网可能又会有自己的这种安全通信，涉及到车云跟cloud之间的这种又会有自己的，甚至于有的企业他会自己定义一套这种私有的这种安全通讯协议。所以我们这次的话就把这个范围定义在一个狭义的SecOC上。那么这个SecOC他要解决我们车内网所面临的一些安全威胁，比如说有一些非法数据，可能会有一些占用带宽，或者伪造的、篡改的以及重放的，所谓的SecOC，要明白一点，它不是万能的。

这些典型的这种车联网安全威胁并不是单一一个措施就能解决的。像我们现在在整个行业里面的话，遇到过的一些这种技术手段。比如说防火墙，可能给这种中央网关提的会比较多，还有这种入侵检测系统IDPS或者IDS，这个其实也是近几年汽车行业一个特别火的一个应用。还有就是我们这个SecOC了，包括我们常规的这些报文加密，或者一些27的这种身份认证。

对于SecOC这样一个措施，它只能解决两个问题，第一个叫做篡改数据，第二个叫做重放数据。比如说我们做这种零部件的这种测试的时候，我可能会用一些总线监控设备去模拟一些抽象的这种节点，或者我去读我的ECU它发出来的一些数据，这时候我可以去在我的这个监控设备的上位机上去改我的信号，然后发送一些报文，这种是辅助我们来做这个产品的这种功能验证的。大家想一想，如果黑客用同样那种手法来攻击我们这个ECU，是不是对于一些很脆弱的这种车内通信协议，其实是很容易做的。你像CAN总线，它在上个世纪推出来的时候，其实不会去考虑一些加密，或者一些伪造的这种做法。这就直接带来了我们要去伪造一些CAN的这种数据，要去篡改里面的内容。或者我不用去钻研你的这个通讯的格式，报文格式或者一些协议，我直接录上几次的数据我重放出来，这种其实是很容易就能发动对于车内网络攻击的。大家如果看过历史上的一些像是特斯拉这些被破解的这种事件，会发现对于车内网，其实在黑客的眼中其实很脆弱。这也就是SecOC等等一些技术所推出来的背景。

SecOC是怎么样来解决这种数据防伪的这种事情呢？它会利用到我们的AES128的这种CMAC，为什么用这种对称算法？大家有想过吗？为什么我不用数字签名？这个的话也是会涉及到密码学当中的一些注意事项。原因就是在于对称算法，它的这个运算速度快。大家想想我们这个车内的这种总线报文，通常而言都是毫秒级的，快的话可能1毫秒或者2毫秒。如果我们用这种数字签名，首先它会侵占我们的这个报文当中的一些字节。比如说我们CAN就八个字节，你还要分出一些空间来存那个数据签名，这个其实是会让我们整个车内网的这种通信效率变得很低的。而且不是特别经济有效的这种做法，所以我们会用一些轻量的运算速度比较快的，所以就自然而然会想到这个AES这种算法。而且我们用的是目前比较精简的又相对安全的这个AES128，也就是SecOC这个技术的背后，很关键的一个措施就是CMAC，那么CMAC就离不开密钥，因为这是一个密码学。在一个交互的AB双方，A要给B发数据，他要把一个原始数据PDU增加两个字段，一个字段是Counter（是用来标识报文的唯一性，在整个生命周期中，单项递增），另一个是用密钥连带的Counter以及原始的数据一起算一个防伪的验证码（MAC值），最后我们把它打包在一起，考虑到我们这个通讯报文字节数有限，我们会截断Counter和MAC，使得这个数据不拥挤。

所以SecOC的核心就是一个CMAC，并且它会做两次比对。第一次是我收到这个counter比我本地的要大。第二个是这个MAC，我验下来是对的。当我这两步验证之后，我会把当下收到的这个counter更新到我的本地，下一次又参与到下一帧报文的运算。这样既然我的counter是单项递增的，那这个是不是就水涨船高。这就是我们在SecOC来防报文伪造以及消息重放的这样一个方案。

在整个SecOC里面，我们分几个要素。第一个要素是我们的这个密钥，刚才我们也说到参与这个CMAC运算，我们如果站在整车的这个角度，当我的这个车上会有几十条或者几百条报文的时候，他可能会在多个ECU之间流转。所以如果做的特别复杂的话，我们可以针对于某一个报文的group去定义不同的这个密钥。

所以我们对于SecOC如果做的特别复杂，那也就是它的这个密钥的管理的难度特别大。大家能理解吗？所以这种的话对于咱们做零部件的这个角色来讲，我们其实是很难去推动OEM去上这种SecOC，因为他我们其实是很难左右非我们自己做的这个ECU里面所做的这个密钥的。所以通常而言是由OEM来管理所有的这些密钥的。他们可以根据我们车的这种安全性要求，不同的车哪怕是同一个ECU，它可以设不同的密钥。这种通常也会在OEM的这个下线的最后一道环节，来做这个密钥注入，这是目前比较流行的这个做法。

对于单个的ECU而言，它是不是只要留出对应的这个密钥注入接口就可以了，我不管OEM注什么密钥，我把这个接口给你。

第二个要素是刚才我们讲的那个counter，这个counter我们刚才有举到一个例子，就是它是一个单向递增的，整个车辆生命周期里的这样一个都不会溢出，我们在这块设计的时候，还有几个注意事项。第一个我们这个counter是一定不能掉电丢的，比如说我们虽然这个策略设计的很完美，就是我整个生命周期内不丢。那么我如何保证我生命周期内不丢呢？最直接一点，我的休眠唤醒，我的这个ECU掉电，我不能让我的这个本地的counter丢了。

然后就是我们的这个CMAC了，刚才我们有给大家讲到，因为车载的这种通讯环境，通常是这种实时性要求比较高的。所以我们尽量的选择一些轻量化的这种密钥的这种运算。我们首选的是AES128的这种加密，利用刚才我们的这个密钥，滚码和报文的payload，甚至于这个报文的ID作为input来算一个带这种完整性校验和真实性校验功能的CMAC，把它打包在这个PDU这一帧报文里面。我们在验证的时候就做两步验证。第一个是我要比较我的这个counter，我收到这个counter要比我本地的要大。第二个我来验我的这个CMAC是不是正常？

8、安全启动

安全启动这个功能，在我看来，首先它有用，但是它并不是那么不可替代的有用。就它所实现的这个防护的功能，它是防代码篡改，也就是当我整个系统启动的时候，我会利用HSM作为一个可信根，它扮演一个哨兵的角色，他会去校验我host的那块的代码有没有被非法篡改，校验过程：首先它会有本地预存的一个参考值，用一个CMAC1撇表示，同时在我启动的过程当中，我会去读我host的那块的代码，我实际算的跟我本地预存的那个CMAC值做比对，比对成功之后，我允许对应的那个host的地址段启动。（先是boot代码而后才是app的代码）

原理很简单，但这里的注意事项，首先我们在芯片起来的时候，我就要去做校验，势必会让我整个系统的启动时间延长，这个应该好理解，我会在启动时候做一些额外的这种密码学操作。虽然HSM算的很快，但架不住我host的那块的代码写的很大。你比如说你的flash，如果是两兆，你两兆都用到了1.8兆。我的这个速度虽然快，但是我每读一块host那块的codeflash的里的block过来的时候，我的这个任务调度、内存读取，这个是要花时间的，这个会增加我们整个系统的启动时间。大家知道像我们车载的ECU，它其实性能有的要求还挺高的，比如说我在上电之后100毫秒之内要发出第一帧报文。

如果你最后做个启动时间，分分钟超过这个时间。所以我们在对这种性能有限的这种芯片做这种安全的话，一般走对称算法。因为保证要保证这个启动速度，所以你这时候如果用一个非对称算法，这个速度只会更慢，所以一般是走这种对称算法来做的。

第二个是我们在设计整套安全启动的时候，我个人感觉这个安全启动的策略不见得那么有用啊，因为既然是防篡改代码，我是不是上一个安全刷新就可以了，或者把芯片调试口给锁了，是不是能达到在一定程度上我认为我的这个系统里的代码不太容易被更改，是不是我可以拿着那两个数值来组合一下，来达到同样的效果。但是有的这些企业他们不见得这么看。他就说我要武装到牙齿，我要做纵深防御，所以你好歹给我做一个安全启动，就是我既做调试口保护，又做安全刷新，我再做一个安全启动，这个只会让我的系统更安全。所以在实际开发的时候，大家悠着点来，根据我们整个系统的这个启动时间，然后来选择我们的这个安全启动的这样一个校验的一个策略。

第三个注意事项是我们的安全启动是依赖于安全刷新的，就当我们每次升级我的这个host里面代码的时候，我们在验好了我们这个代码的一个可信度之后，我们是不是要同步的来更新我的这个参考值，因为这是我正常的一种更新我代码的这种行为，我们防止的是非法篡改。我作为开发者，我刷一版合法的软件进来的时候，这种情况下安全系统不能把我拦截掉，不然我刷一个软件，我的系统就起不来了。所以我们每次做完这个刷新的时候的代码校验的时候，我们在最后一步是要去触发HSM去更新当前CMAC值。这样的话保证我下一次启动的时候，我的这个CMAC是与时俱进的，能够跟我实际算出来的新指标是对应的。

然后第四个注意点是在于你不是你校验的代码越多，你越花时间吗？所以我们是不是可以挑选一下，我不是完整的校验，我挑一些重要的代码来做校验，这样的话我是不是能缩短一些时间。

我们来看一下工程上怎么来实现把安全启动。刚才我们有说到一个词叫做信任根，所谓的这个信任根，在安全启动这个场景下，他要满足几个特性。

第一个特性是我们要做这种安全存储，也就是我的密钥放在这里面很安全，用来做校验的那个密钥，尤其是对称算法，因为你对称算法，你的这个密钥是绝对不能丢，你的密钥丢了之后，很容易被人家伪造。它不像非对称算法，我如果公钥丢了之后就丢了，他没有私钥的话，伪造不了，所以这个信任根要存在，要有这样一个安全存储的一个特性。

第二个特性，他要保证这个完整性，也就是我的这个HSM不能随意被人家篡改里面的这个参考值，密钥也不能篡改，我的整个的这个校验逻辑不能被人家篡改，这是他要保证的第二个特性叫完整性。像我们这种MCU，刚才我们不是讲的这种case里面吗？我的HSM是可以扮演这个角色的，首先东西丢里面很安全。第二个它的这个代码不太容易被人家篡改，所以可以靠它去校验host那块的这种这个应用。

但是大家来想一想，这种情况下他能做这个安全信任的吗？考虑一种场景，就是我的这种外置的这种芯片，我是不是很容易，我把PCB板上的芯片把它吹吹掉，我把它吹下来，我替换成自己的一个这种，是不是就不能保证那个完整性了？因为很容易被人家改，所以在这种外挂式的，就比如说我的MCU里面没有内置的HSM，内置的这种HSM的，反倒不容易被人家改。你要么就把我的把芯片全都替换掉，当我没有这个HSM的时候，我外挂一个SE，这种是逻辑上来讲，他做不了安全启动，因为它容易被人替换。

我们来看一下这个内置的这种情况下，我们所谓的这个叫做串行式的这种安全，我们只看我们内置的这种MCU，内置的HSM的。

芯片上电之后，HSM会先于MCU、host起来，这时候他会把host置于reset，我不让他跑。这时候他会去读取我flash里面的这个二进制代码段到我本地来做一次校验算CMAC，跟我预计的那个参考值做比对，如果验证成功，也就是两个值是一样的。那我就把这个host启动，这种验证不通过的话，那我就让我的这个host继续reset。

大家想一想，这种情况下会出现什么情况？我的HSM是会比host先起来。假如说我这时候我的校验出了一个bug，我固件里面有bug，他校验失败了，是不是我一直会让这个host reset。如果说我想给自己留一手，当我发现这个启动失败，我通过这个刷新再来更新一下我这个代码，是不是就不行了。因为我MCU这种升级，都是在我host的那块的boot loader里面。我这时候boot loader跑不起来，这种是不是很容易让我的这个产品变砖头，这种的安全性是非常好的。因为我的这个HSM会先于我的host起来，并且不让他运作。但是它的缺陷就是在于很容易让我的产品变砖头。

安全启动这块，有两个注意事项，刚才都有跟大家讲过，首先要有一个启动时间的考量，我们要么就用安全刷新或者调试口来替代这个安全启动功能。要么就是我减少一些校验的代码量，来缩短我的启动时间。第二个，我们的信任根是可以被更新的，但是更新的这个过程当中对于MCU 这一类的话，我们是要在安全刷新完成之后再进行更新，不能被人家非法的篡改。而MPU或者SOC是没有办法更新的。因为是在E－fuse，他只能写一次。

比如说缩短这个校验的代码段的话，哪部分是我必须要校验的。然后哪部分的话我是我可以考虑去不做校验的。然后这有没有一个提具体评估的一个标准，或者说一个指导这种呢？

这种的没有一个很清晰的一个标准，通常是我们把一些重要的代码来做校验。比如说你涉及到一些身份认证啊，或者一些核心的这些功能逻辑的。我的这个代码允许在一些情况下被篡改，但是我不希望我的核心代码涉及到我的这个产品安全的这种代码被篡改。你可以用这种原则去筛选一部分，然后跟客户那边达成一致就可以了。

9、安全诊断

下一个功能叫做安全诊断，这个功能我如果说成是UDS的0X27，我相信大家应该都不陌生了。我们首先来看一下，回顾一下这个0X27，其实它就是一个常规的挑战应答的这种方式。所谓的挑战应答就是我作为一个诊断仪在访问ECU的时候，我会首先发起请求种子的这样一个做法，ECU会回复种子，然后tester这边根据双方预制的一个算法或者密钥来算一个key，这个函数其实是可以由OEM这边来定的，像大家如果做过一些早些年的这种项目，我会发现这个私有算法，它其实都谈不上密码学，就是一些移位，现在的话可能会比较注重走这种标准密码学。

这样的话基于所选的这个方法不一样了，这个函数就不太一样了，tester把算出来的这个结果给到ECU。ECU在生成上一步的seed值的时候，会用同样的算法来算一个预期的一个应答值，二者来做一个比对，然后这个比对结果作为一个应答码，给到tester来选择是不是执行后续的这些操作。如果我们把它类比成是芝麻开门的的话，那就是我们通过这一次认证确认了tester的一个合法身份之后，我们在选择性的开启后续的这些UDS的这种诊断服务。

现在有一个新的算法叫做0X29。我不知道大家有没有听过这个在奥德萨的4.4的版本里面，已经提出来了，也就是我们UDS最新版的，我没记错的话，好像是2018还是2020版里面提到的这个0X29。这个在奥德萨的4.4版本也提出来了。但是我们如果项目当中用的时候，还是要看一看我们所选的那个BSW供应商有没有把这个东西给做进去，就是UDS这个14229的这个国际标准的，比如基于非对称算法的来做0X29，也有基于对称算法的。

那么0X29，跟刚才0X27或者0304类似，它也定义了一些sub function，有什么解除认证，有单向认证，有双向认证等等。我们一起来看一看，一个典型的0X29过程是怎么来做的。那我们就直接来看基于非对称算法的0X29。首先会有CA，这个发证的话它会有自己的一个公私钥，私钥一定不能丢，这个公钥可以同步的发给test和ECU，那么test和ECU会有自己的公私钥对，在实际工厂生产的时候，他会把自己的公钥给到CA，由CA的私钥对公钥做一次盖章，最后把证书发下来，与此同时还会把CA的根公钥，或者根证书一并发下来。

我们做好了这个准备工作。比如说ECU，我就比如说长城，让咱们在我们工厂下线的时候，把他的这个证书给过来，或者我们所有的ECU就生成相同的这个公私钥对。

那么实际怎么玩呢？首先他会敲门，我的test会你问一下ECU，你支持哪些算法？发的就是这个2９08，2708对应的就是不2908发过来的就是6908。这时候按照0X29的那个协议啊啊，他会回复02。也就是基于非对称算法，PK证书的这种认证的这个过程，他就把这个ARP的这种方式给过来。

我们常规的0X27是一种对称算法的这种认证，你可以认为它是一个单向认证，它其实不算一个双向认证。因为它的单项认证体现在是ECUEN test。他是把那个种子给过去，然后对方算一个结果过来，这是ECU来评判他。而这种双向认证是ECU评判了test，test也会去评判ECU，这就是一个双向的by direction。

10、攻击树

我们接下来还有不少内容下一个板块是叫做攻击树

攻击树这个概念，大家可以去看几个参考。一个是功能安全的function，safety的里面的叫做FTA。其实在这个方法上，其实都差不多就是一个FTA fortune analysis。我们在这个CS这个领域叫做攻击树，其实在这个方法理论上是相通的。

那么画这个攻击数的时候，对于网络安全这块，其实考察的是分析人员的这个黑客的攻击经验。所以这块其实大家如果去看这个21434的这个标准，它有个附录，里面提到的是大灯的这个分析。这个攻击数在这个case里面的话，他其实就给了这么一个一张图。就是我们上游的话是属于威胁场景，威胁场景我们通常会表述成通过什么什么的方法破坏什么资产、什么属性，达到什么效果。然后接下来我们就从一个攻击者的视角去围绕这个威胁场景去看我在整体的这个系统架构里面，通过怎样的一些手段能够达到那个攻击目标。

我给大家举个例子，假如说我们有一个资产是这样一个大灯的这种开关信号，那它有一个属性叫做完整性。我们的威胁场景如果定义成是说通过篡改我们的这个大灯的信号来破坏这个信号的完整性，使得我的这个大灯的控制处于一种非预期的状态。我本来让这个大灯开，但是我篡改了这里面的一些数据，使得他关了，这就是一个威胁场景，通过篡改信号的这种方式破坏这个资产的完整性，使得我的大灯控制的非预期。这就是按21434的套路所描述的一个威胁场景。我们做攻击树分析的时候，既然这个资产它留存在我们整个系统架构，是在车身控制的ECU和大灯开关之间。那我结合我的这个黑客的这种思维，我就会去想，我怎么样达到我攻击他的这个目标。

接下来就是考验我们这种黑客攻击的思维了。你想我的这个信号会由他举个例子，是由他发送出去的。是不是我在这一条链路上，我任何一个地方都有可能去改我的这个信号。这时候我就会想到这第一个，就是我来破坏我的这个ECU，我来发这种伪造的信号，是不是我在这一路总线上，我也可以去干扰，就是在整个的这个数据流上，我们可以去发一些恶意的信号来干扰这个大灯的控制指令，甚至于我可以去干扰我的这样一个开关模块。我使得他的工作逻辑处于一种错乱的状态，使得我的一个大灯的控制也处于一个非预期。

讲到这里，我其实想给大家传递一个理念，就是我们在做攻击树的时候，把一个威胁场景逐层的去细化，第一个需要结合我们整个系统的这个架构的，你的数据流，你的各种各样接口。第二个是你要有一些黑客的思维，你会去评判，去判断我以怎样的这种可行方式能够达到最终的攻击效果。做好这两方面，我们就能画好这样一个攻击树。

我们再来抽象出一个模型出来，也就是我们的威胁场景，我们会逐层的去分解，分解成子目标（叶子）和根。我们通过刚才的黑客思维以及整体的系统架构，我们把这样一个根分解成我们的这个叶子节点。每一个子目标，我们去掌握我们的黑客的攻击方法，去把它再进一步细分。这块的话，我们通过一些逻辑门，比如说与或者或来排列组合我们各种叶子节点的一个逻辑关系。

我们在做这个攻击路径打分的时候，其实就是从下往上，根据这个逻辑门来定义我们这个威胁场景的一个攻击可行性。怎么样来做呢？比如说我的攻击方法A跟B同时发生，我才能达到这个攻击目标。而我攻击方法A和攻击方法B我们按21434的打分。比如说你需要的工具，所需要的这种专家经验等等。我们可以定义它的一个攻击可行性。

接下来我们会算这个攻击目标一的这个攻击可行性的时候，我们就取最小的。因为这两个同时发生，我当然是选最难发生的，作为我的这样一个瓶颈，对吧？就两个同时的话，我只能选择最难的，也就是我的攻击概率最小的，作为我攻击目标一的这样一个攻击可行性。

11、漏洞分析

下一章是漏洞分析，不同的漏洞，它的这个成因，背后的原理其实是不一样的。所以我把讲解内容定义成了这么几块。第一个是一些常见的漏洞的分析的方法，会有一些general这种方法。第二个是我们对于漏洞的一个评分的一个模型。第三个是我们对于漏洞处置的这样一些流程。第四个是我们对于漏洞的这些披露的一些注意事项。

漏洞这件事情，其实有100%安全的系统。所以不同的这个系统里面肯定会有安全漏洞，这个有点像我们每个人的基因，都可能会有一些缺点，或者有一些意想不到的问题。从学术派来讲，你技术原因上并不是所有的这个系统越复杂就越好，反倒是你的这个系统越复杂，引入这种漏洞的这种概率会越高。第二个是我们这个智能网联汽车它其实是在逐渐开放的，在这种开放的这种生态里面，我们其实面对的这种新型的这种攻击手法，或者一些黑客的这种攻击手段，会暴露出一些我们以前不太常见发现的这种漏洞。第三个，我们系统可能会有一些与生俱来的这种特性。我给大家举一个例子，像这种冯诺依曼的这种现代计算机之父，它其实涉及的这样一个计算机系统结构理论，就天生蕴含了这样一个安全的问题。我不知道大家有了解过吗？我们的这种现在的这种计算的结构，有这种输入，有控制逻辑，还有输出。那么在中间的这样一个输入环节，冯诺依曼它会去划分不同的系统的这种模块，有的是数据区，有的是这种程序区，还有可能是一些处理数据处理区，还会有指针等等一些概念。

在他建立的这个系统计算机结构理论里面，现在看上去就会有一个固有的弱点。就是他会把数据区和代码区划分在一起，它是混杂在一起的，带来的一个问题是当我的数据区是接收一些数据的时候，我没有去校验这个数据的一个严格程度，那么这个数据它会导致这个缓冲区溢出，这个缓冲区溢出很有可能会冲抵掉某一些程序区的内容，之初就有的这样一个固有的一个弱点。

我们其实在全球范围内有一些通用的这种漏洞挖掘方法，往往大了分就是包括静态漏洞检测和动态漏洞检测。这一块的话都会关联到一些适用对象，还有一些常用的方法。对于静态的这种漏洞检测，简单来讲就是我们的代码不需要运行。我们直接去看我们的这个二进制代码或者源代码当中的一些特征。我们来判断一下是不是里面会有一些特征跟我们发现的一些漏洞的这种特征是吻合的。举个例子，就有点像我们去查这个指纹，或者我们的这个人脸的这种虹膜的这种检查。在这块的话会有很多的这些工具，比如说现在很高端的走这种AI算法，直接去扫这种二进制的这种是不需要代码运行起来的。

一种是针对于这种动态的这种漏洞检测，也就是我的这个产品能够正常的运作。我们会通过一些测试或者一些故障注入的这种方式。动态的这个漏洞扫描，我们可以通过一些测试的手段来发现我们系统当中可能存在的一些安全缺陷。首先我们做这种手工测试，可以看到在字面上我们就是通过一些工具去挖掘我们这个目标的客户端也好，或者终端，我们手动的向里面去发送一些特殊的数据，这个过程当中我们会去监控我们系统的一个状态，对于各种各样输入的一个反应，我们来发现这种检测的这种技术。给大家举一个例子好了，举一个生活化的例子。比如说登邮箱，可能会发现它你如果输入失败了，就是它会提示你的用户名或者密码，是错误的。这种就是属于一种测试，然后通过监测目标的这种状态来判断一下我们系统当中会不会有这种安全性的问题。

还有一个叫做模糊测试，这边这个模糊测试对于整个安全的这种漏洞挖掘，其实是很常见的。也就是他把目标对象当成是一个黑盒子，我们根据这个目标对象所接收的一些预期的这种数据，我们去产生各种各样的一种有效或者无效的这种构造过的这种输入，我们来看一下是不是会在一些特殊的这种场景下，我们的整个系统当中的一些安全漏洞或者bug，会导致整个系统的crash。这就是它背后的一个原理。我们在生成这些数据的时候，不同的这些渗透模糊测试工具，它所执行的效率是不一样的。

在这个过程当中还会有一个很关键的就是我们的这个工具，要去监控我们目标系统或者我的某一个黑盒的函数的状态，我们要精准的定位到我们这个系统有没有crash，有没有出问题，这种是模糊测试工具一个很关键的。对于我们车载ECU，我可以给大家分享几个我们监控这个ECU状态的这种对象。比如说我们去监控我们的ECU的这个电流，或者电压。当我的系统处于某一些极限的待崩溃的这种状态下，有可能我的这个系统的runtime 或者我的CPU占用会很高，这种是不是它反映在我的电流下，就可能我的这个产品的电流瞬间就飙升了。我们可以通过这样一些蛛丝马迹来反向推断我们整个系统当中的一些运作状态，以此来帮助我们来定位整个系统当中的一些状态。

另外一种是属于二进制的比对，也就是我们通过一些已知的这种漏洞模板，我们去扫描我二进制代码里面是不是有一些相同的特征。这块的话像是用IDACompare的这种工具，或者一些binary的这种比较的这种工具，我们是能够用这种静态的这种方式来挖掘整个系统当中的这种安全的漏洞。

对于静态的这种分析技术，业界也会有很多的这种工具，号称史上最强的这种漏洞的扫描工具，就是这个黑鸭子，他费用也不菲。也就是他可以通过我们这种语义的这种分析来发现我们系统当中的一些潜在的这种问题。比如说内存的这种访问或者管理的一些函数的这种缺陷，都是可以用它来做的。那么动态的这种分析，比如说我们的这种软件的debug，或者一些数据流的这种监控工具都可以。这些常见的这些漏洞挖掘，这种方法，都会需要有一些黑客的这种攻击经验来辅助，来挖掘整个系统当中的漏洞。

我们发现的这些漏洞是需要去评判它的这样一个漏洞的一个风险等级。这块的话我给大家推荐一个行业里面现在非常流行的一个叫做CVSS的一个方法。这个方法通过一些定量的这种打分，来定位我们这样一个漏洞的一个安全等级。

这个方法它会从这么三个维度来做打分。一个叫基本群，一个叫暂时群，还有一个叫做环境群。

怎么样去做这个安全生产控制计划。首先，我们按21434的这个要求，我们其实对于生产板块，它其实要达到几个目的。第一个目的是我们在这个生产供给计划里面，要把后开发阶段这些需求落实到我们的这个生产过程。第二个，我们要在这个生产控制计划里面去描述我们的整个的生产流程程序，还有一些配置方案。第三个是我们要有一些部件防篡改的这种保护性措施的这种声明，以及我们所做的这种技术落实需求的一些验证的方法。

我给大家一会儿举几个例子，我们生产的过程其实就是把原材料组装成我们的这些ECU。它会按照一个既定的这种生产工艺来落实对应的这些防护要求。比如说我们要做这个JTAG，他会需要在工厂去做一些密钥的生成和注入，我看到的大部分的汽车ECU的生产工艺，落实网络安全这块的要求的，通常是会在我们的这个程序烧录，还有一个零件这种功能测试的这个部位，不同企业可能叫法不太一样。我们在这个烧录工位，通常会把一些密钥写进去，开启调试口等等一些操作。可能都会在这边来做，而这个FT的这个工位，它因为在这个过程当中，它可能是一个裸板，没有装壳，所以我们可能会有一些工装设备是能够触碰到我们芯片板子上的一些调试触点的。而对于装了外壳之后，我们这时候就要访问芯片的资源，可能就只能通过CAN总线或者一些通讯总线来来做访问。

我相信咱们的这个生产工艺应该类似的，所以我们要去做落网是一些生产阶段网络安全要求，通常离不开这么几个工位，我带大家来稍微看一看，就是我们通常的这个生产工艺前面的这种PCVE：物料上料，刷漆膏、贴片，还有一些回流焊，这块与网络安全的这种关联度不太高。对于这种程序收录，我们通常是会需要有这样一份程序收录规范，咱们企业可能不同的这种叫法，还有一些叫做功能测试的这种规范，可能会有不同的角色来做。我们作为安全的这种要求，是需要把我们这种网络安全的这种技术需求分散融入到我们的不同的业务规范里面。举个例子，我们的这个烧录规范里面可能会去做这个JTAG密码的这种生成。可能会往一些芯片里面去写一些这种数据，还有的就是我们生产规范里面可能会有的像是去写一些电子标签或者注密钥，或者做这种身份认证。这个都是可以结合我们现有的这个生产工艺去考虑，把一些网络安全的这种要求给落进去。带大家来看一看，比如说我们的这个程序烧录里面，烧制程序，这里面的话，我们可能会把固件一并的烧进去。我们可能会预制根证书，所以我们这个程序烧录往里面烧，我们可能还会去改芯片的live cycle，对吧？我们会去改我的这个flash的这种锁定，可能会往里面写调试口密码。

从大的面上来讲都是会落到我们的生产阶段的一些需求。大家如果去看21434的话，会有一个词叫做post development，叫做后开发阶段。我们对于这个产品作为开发者，我们是可以定义到我们这个产品要上市之前，所要做的一些事情，其中落实到这个生产阶段，我们可以分解出一系列的这种测试的这种需求，或者生产的需求。我们要做的事情就是把相应的这些生产工艺分散到我们不同的这个测试步骤里面，然后通过规范的方式去把它描述出来。

我们一个光板要往里面刷程序，我们可以会用这些砧板去顶到我们这个PCB板上各种各样触点，其中可能就会有JTAG，我们通过烧录器，通过这些触点把芯片写到这把程序写到这个芯片里面来。而功能测试的这种可能就是我芯片窗格之后，我会通过一些夹具去接触到我们的这个产品的一些总线的这种接口。然后再把数据给弄进去，我们可能还会在工厂里面去住建这种生产密钥服务器。这个服务器如果说OEM它可能会要求，那我要去做一机一密，由客户那边来分发各种各样的密钥。理论上我们工厂的这些tie one的这些服务器，是需要去承接它，去下载对应的密码材料，然后再把它写到我们的不同的产品线，以及我们会把上传一些追溯性的信息给到OEM。这种都是可能会落到我们工厂的这样一些技术要求,所有的这些，我们会通过一份生产控制计划来呈现。

到了运维阶段，对应于21434的第八章节，这个是情报监控，漏洞管理。还有这边的时间响应这块，首先我们我相信大家应该都很熟了。1155法规里面是要求我们对整个产品全生命周期做好风险管理。对于OEM而言，这个要求会被分解到tie one，由tie one去协助他们来做好整个的风险的管理。法律法规的要求，比如说要建立这种情报监控，应急响应漏洞管理的这种机制。我相信咱们企业，我的感觉他应该是有一套现成的流程体系了。我们在运维这边就做三件事情，情报监控、漏洞管理，还有事件响应。

情报监控就是去监控一些内，情报员，漏洞管理就类似于我们做的这种bug管理，或者企业的这种内部管理问题管理的这种流程。而事件响应的包含漏洞管理的这样一些要求，以及包含一些内外部的这种公关工作。

安全运维这块，我看到的大部分企业会在组织里面去建一个叫做PSIAT（product security incidents response team）的一个团队，来统筹内外部的这种信息沟通，以及我们的这些事件的监控，漏洞管理，还有一些事件的这种处置，通常组织会有这样一个流程，我们会鼓励从搜集情报开始来判断一下我们产品有没有受影响，我们会来做相应的补丁和修补措施，这就是一个很常规的这种类似于bug管理的这样一个流程，所以大家按公司现有的流程来执行即可。

这边给大家分享几个，刚才我们也聊到了，我们要去不断的积累一些安全经验，来辅助我们来做一些情报的分析或者漏洞的管理。我给大家推荐几个情报的来源，比如说暗网或者一些公开的这种漏洞网站。大家可能都听过CVE，还有CNVD，CNNVD这些行业里能公开漏洞。

最后一个阶段给大家来介绍一下报废和退役。这个阶段其实对于很多的这些开发者而言，怎么说呢？不太好管控，我把我的二手车卖了，我为什么要告诉到车厂。所以很多时候我们对于这些报废或者退役，其实很多时候是不在我们的这个掌控范围的。

21434又提到了这块的这种要求，这块的话我首先给大家一个概念上的差别，就是decommissioning叫做退役，还有叫做end of support。这两个概念是不一样的。退役通常是指我的系统无法运行，比如说我的这个车开不了，那就是报废，而结束的支持，我的系统可能还运行，只是我不想提供支持了。

还有这个软件升级的这种服务。你可以看到在这里面有一些关键词，我们的一些注意事项，所做的这个承诺在什么时间点，这块的话我们可以去定的一些需求，我们产品需要支持这个软件升级更新升级我们为我们的尊贵的车主提供若干年的这样一个保险服务。我们团队要在流程上去建这样一个安全运维团队，来保证我们售后的这样一些运维的事项。不会掉链子，大概就这样。