感谢看雪的邀请，去年团队在看雪峰会分享了数字硬件钱包的攻防。今年我自己在看雪峰会上分享了IoT设备和SE芯片方面的一些看法。
以下是峰会的速记内容。
-----------------------------------------------------------------------
2019 SDC 议题回顾 IoT中的SE芯片安全
潘少华：大家下午好！去年我们团队在这里分享了智能硬件钱包的破解，讲了固件的提取、分析、挖掘和发现。
今天和大家分享一下我们最近做的IoT中的安全问题，刚才主持人问大家有5件以上智能硬件的，我没想到这么多人举手。
这个题目也是给自己挖了个坑，3月份报题目时让我们讲讲智能家居、智能硬件的问题，直接讲锁太具体了，说讲讲SE芯片问题，但没想到把自己装进去了。为什么？我们今年测了前前后后100款智能云锁，最后发现能够在锁里接触到SE芯片的机会实在是太低了。
根据统计2025年750亿智能硬件终端，那么有多少在公网上，这的确是超乎想象了。在我们认知里，摄像头、路由器不应该都是隐蔽的，在公网上探测不到。但是根据ZoomEye结果发现，今年暴露的物联网设备就有超过6000万台。这两年基于物联网设备、智能终端的一些安全事件，像导致2016年美国断网的攻击是来自于很多物联网设备，包括上个月我们也刚跟腾讯一起新发现了利用台湾AVTECH摄像头漏洞的蠕虫网络。
这里很关键的问题是，这么多设备放在野外，有可能在家里，有可能在办公网络，有可能是室外部署的，它跟我们个人电脑、服务器不一样，服务器中病毒了我们可以很快定位找到问题。摄像头，不说别的问题，光说机站，运营商机站的地址跟我们实际找到东西根本不在同一个地方，无论是市政施工还是其他因素，甚至是登记时错了，有各种各样的的偏差。
去年CCTV4和中央2台连续报道两期智能家居问题，比如锁突然开了，窗帘被拉开了等等，有些近场通讯无线信号劫持，有些是APP漏洞。这是6月份的一个报道，通过这个案件发现，第一，物联网终端是不是我们厂商发出去的终端？里面的东西是不是跑我们的脚本？第二，物联网设备跟服务器通信时是不是连接的真正服务器，下载的固件是不是已经被动过手脚了？
尤其从DDoS的情况来看，跟10年前、8年前DDoS完全不一样，动不动就上百台设备组成僵尸网络，动不动就T。这里比较核心的一个问题是，身份认证和加密出了问题？因为很多时候通过漏洞攻击进去是源自身份鉴权方面的问题。
根据2016年的paper的分享，讲到IoT的攻击面，这里有嵌入式的，可能是硬件层的，也可能是网络层的、服务层的、第三方API的，里面最核心的问题是身份鉴权的问题。到具体的智能家居，比如门锁，以前锁是揣在自己兜里的，丢了之后我自己是知道的，虽然我知道有物理开锁，但现在随着我上网之后，我的锁连网了，谁还对我这个锁有管控权，这个问题就比较深了，智能门锁系统本质上是密钥管理系统，就涉及到密钥分发、涉及到双向认证、涉及到ID标识。除了锁之外，比如物联网的表，水表、电表都存在相似的wen体。比如嵌入式系统给我的密钥也本身容易被黑客攻击，那么接下来如何通过安全的技术手段来保证核心的信任根的安全？
今年12月1号物联网等保2.0将正式实施，其中一项是有关于物联网安全的扩展要求，里面提到等保三级一定实现可信计算，要有可信任根，要有安全硬件的保障。那要所有的电表、水表、上网设备都达到等保三级，相关的投入好像有点大。成本和功耗怎么平衡，用什么级别的可信计算？硬件方面是不是用了安全芯片就安全了？
安全元件一般简称SE（Secure Element），包含两部分，一个是硬件部分，一个是软件部分，硬件可以理解成单独的嵌入式电脑，它可能包含一个CPU等等在里面。最核心的，第一，要支持加密算法，比如一种是AES进行加密和解密的，第二就是身份认证，比如椭圆曲线用来非对称性加密。还有一个比较重要的事情，唯一的ID，包括随机数的生成。今天来了很多搞硬件的朋友、搞区块链的朋友，对随机数的重要性非常清楚。
从3月份到现在，我们测了100多个门锁相关的APP、30多个门锁实体，最后发现很郁闷的一个点是什么？我列出来的这30多个锁基本上没有SE芯片。在此基础上，这么多APP和门锁硬件，统计下来的数字平均高危漏洞数量有这么多个，有些洞比较多，拖后腿比较厉害，当然也有个别的APP做得相对比较安全的。最常见的是逻辑漏洞，可以充值任意用户的密码、使用任意手机后来注册，直接进入管理后台等等。还有一些通过固件进而分析它的协议、云服务接口。
我们发现绝大多数APP是明文传输的，只要把固件扒下来，甚至明文密钥都没有，就是直接明文通讯、直接是IP地址，这是大多数门锁的情况。少数进行了通信加密也基本是固定密钥，在通讯协议里。这种情况下如果是WiFi的锁，我只要劫持WiFI做解锁就非常容易。还有一些锁是NB网络，通过4G机站的方式把NB信号进行劫持，门锁本身的加密通信破解就根本不是问题了。这些门锁、水电表、煤气表，如果能够正确的使用SE芯片，就没有那么容易被中间人劫持、破解协议。
SE芯片本身的应用场景有很多种，其中通信密钥的安全加密存储就非常重要。实际上很多智能IoT设备用的最常见的是MCU，很多设备是基于MCU来存储固件和密钥。做好PCB和芯片层面的安全防护，防止固件被导出分析，防止内存被读取，也是一个办法。类似的PC上比较常见的是TPM，很多电脑上已经有这个芯片了。像TEE芯片更多在手机上应用比较多，TEE不仅是密钥加密存储，还有其他的授信和一部分可执行代码。
最常见的是SE芯片是这个结构，一般包括一个Flash，包含一个SRAM，包含相关的计算单元。以这个智能表的发展为例，最开始我们的表都是每隔1个月或者3个月抄表的人过来敲门，再过几年前是智能卡，营业厅冲了费用后，拿这个卡刷一下就行。这两年都开始推广使用NB表或者其他联网的方式进行远程传输，避免了人力上门抄表。
正常用SE系统时一般包含这几部分，首先，在MCU嵌入式里有相关的调入接口，最后是在云端系统的匹配，如果涉及第三方业务，还要有第三方业务的对接。最核心的是密管系统，因为类似于KPI体系里的根证书机构，要确保密钥的初始化和分发都是安全的。
我们发现难得个别智能门锁用了SE芯片，但是还是没办法做就端到端的安全通信，为什么？在产业链情况下，比如我做锁的并不代表我也会做APP，能做APP的平台也只是根据厂商需求来定制开发。目前平台和硬件部分很难把这个事情协调好，这是实际存在的一个困难，也没有懂安全的专业团队来落实安全需求。
顺便提一下很多锁的PCB做工非常好，比如JTAG、UART调试接口在哪里，哪个地方跳线了，都标得一清二楚，这样带来的问题就是攻击者就很方便了，看一眼就可以直接着手硬件破解。
以智能门锁这种智能家居为例，一般有这几种SE使用场景。第一种，把SE芯片加入到主控板上，主控板在需要时去调随机数生成，去调加密接口，或者调签名和其他功能。第二种常见的是比较简单的方式，尤其是NB模块，在通讯模块里单独加这样一个安全芯片。为什么？因为在实际的工业应用中、生产使用中，比如锁厂的主控板都已经定好了，你让我突然加个安全芯片，我真的做不到，因为我要找供应商解决这个问题，我的核心部件都得跟着改，固件得重新开发。所以通讯模块直接加这个安全芯片。为什么？比如我传到NB模组时是明文通信的，在NB模组里自动去调这样一个加密芯片的协议，然后去进行加密传输到云端，云端自动做解密。因为云端改动相对好一些、随时可以升级。这里大家能想到一些问题，比如把我的安全模块加到通讯模组里，主控板不用动。系统层面在主控板MCU里加载相应的函数，去相应的工作就可以了。
随着网络安全法和等保2.0马上正式实施，我们也请教了相关专家。可以说，智能门锁厂商不做等保三级备案，不能保护好用户数据是属于“违法”的。等保2.0三级要求物联网系统要有态势感知平台，要化被动防御变主动防御，就是要知道有没有人在尝试入侵，要知道所有通信的是不是都是可控终端、都是可信任的。这些都是SE芯片能够发挥作用的。
另外，SE芯片本身又存在哪些问题呢，以及在使用SE的时候会有哪些坑？
最基本的针对SE的攻击手段，比如一种SDMA溢出攻击，通过CH0、CH1去设置通信长度，通过把这个长度调整之后就可以发出这样的溢出攻击，这是一种攻击模式。二是针对时钟系统构建干扰信号，产生故障。像错误注入攻击在我们测试时，包括在汽车，都可以用这样的手段，通过这个方式绕过一些安全机制。
像侧信道攻击，我们这几个月工作里侧信道攻击其实都用不上，通过固件提取已经把MCU里的密钥拿出来了。但是假如做好了MCU相关的保护，那么侧信道攻击就有意义了。比如针对目标门锁，首先去抓它的PCB板子上电压变化的信号，然后再进行分析，这个可能调到AES加密那一段，然后通过这个功能就可以把密钥分析出来了。整个执行过程比较简单，网上有现成教程，github上也能找到。加载过后就可以开始自动去跑了。我们自己跑过几个门锁的测试，都有几十秒时间都能完成128位AES的密钥提取。
除了在硬件层面，在固件和APP层面也有很多问题，比如加密引擎，有SE芯片，但是根本没有正确使用调用这个接口。相关保护机制是有的，但我没有去调用。有一个智能门锁也是这样的情况，它已经注重安全、使用了ATECC508A的加密芯片，是第一款支持椭圆曲线加密认证的芯片，但是它有一个问题是芯片的IIC通信没有进行加密，直接取得IIC的通信信号就可以读取出来了。这种情况就是要更换SE。 可以理解，开发人员去找了个安全芯片就觉得很安全了，但实际上安全芯片有什么特性什么适用场景，比如它的功耗、它的工作环境，一般的开发人员不会在安全上想得这么全面。
再比如这是我们去年分享的数字钱包破解案例。它本身用了SE芯片，也用了MCU，但是比特币的价值非常高，我针对它攻击时可以花更多精力去做这个事情。黑客拿到钱包后根本不用折腾安全芯片，直接在MCU部件层面做手脚。这种情况下我们通过JTAG把它的固件读取出来，改完之后再传上去。这样我还是正常调用SE，但是在钱包交易时可能就被做了手脚，攻击者的目的就已经达成了。
说到SE，TEE是可信计算的一个主要方向，国内现在主要推的。但是在IoT方面，TEE有它的问题，第一，它的东西太多了，其实想得非常不错，一部分在系统里做相关的功能，一部分功能是放到TEE中被保护起来的。但是在实践过程中最大的问题是，一般的开发人员来自己的MCU都做不好，要再把一段代码抠出来放在TEE里，太复杂了反而是不可控的因素。第二，TEE的功耗问题，一个智能门锁可能16节5号干电池，一年半，但如果是TEE就变成半年不到，这对用户使用来讲是非常大的影响。所以TEE在手机或者有其他稳定供电的地方会比较适用。
TEE还有个问题是它的可信计算实在太大了，一层层套起来，从系统加载的每个环节都要算。另外，接口定得比较死一些。最大的问题归根到底还是依赖上层MCU的工作，把这个事情做完之后再去调这部分TEE的代码，本身是在MCU的保护层。针对TEE也有相应的攻击手段，比如载体攻击，把东西导出来。固件回滚攻击等攻击手段等等。每个安全产品都有它自身的特点和带来的新特性，怎么用好这个特性，就需要我们关注。
最后刚才抛出了一个像这种智能门锁的安全架构存在什么问题？一个城市里几万个撒出去了，以前没有加密通信，传统的IDS等设备还能发现一些安全攻击事件。现在我们强调要主动防御，主动防御的过程中，比如前面布探针，后面做好流量监控。但是在现实架构下，我把那个通信的模块里加上SE，这样能保证端到端加密了，这有什么问题？假如我是攻击者，去路上随便把拆个设备，直接调用加密模块去发起攻击，过程中所有的攻击请求在旁路都没法发现，直到核心业务系统之后才发现这可能是个异常请求。反而是其他安全设备没有办法使用，没有办法检测到终端到底是不是我们真正的自己门锁在用、水表在用，还是给拆下来接上别的东西了，冒充可信的接入者来干些其他的事情。
所以说，要解决好智能IoT的安全问题还是需要丰富的安全经验，需要解决很多单点安全问题、更需要通盘考虑，硬件特性、软件特性，从底层硬件到后面的专业安全产品和服务都是需要了解的。
最后于 4小时前 被CCkicker编辑 ，原因：
如有侵权请联系:admin#unsafe.sh