首页
论坛
专栏
课程

[原创]2019 SDC 议题回顾 IoT中的SE芯片安全

2019-7-29 17:28 2045

[原创]2019 SDC 议题回顾 IoT中的SE芯片安全

2019-7-29 17:28
2045

感谢看雪的邀请,去年团队在看雪峰会分享了数字硬件钱包的攻防。今年我自己在看雪峰会上分享了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的安全问题还是需要丰富的安全经验,需要解决很多单点安全问题、更需要通盘考虑,硬件特性、软件特性,从底层硬件到后面的专业安全产品和服务都是需要了解的。




[公告]安全服务和外包项目请将项目需求发到看雪企服平台:https://qifu.kanxue.com

最后于 2019-7-29 19:52 被CCkicker编辑 ,原因:
上传的附件:
最新回复 (3)
Editor 2019-7-29 19:53
2
0
编辑按
crownless:在IoT设备中使用SE芯片可以带来更多的安全性。然而,SE芯片也不完全是安全的,可能受到侧信道攻击、错误注入攻击,导致泄漏加密密钥等等。
更让人担忧的是,很多设备如智能门锁根本就没有用到SE芯片。试问这样的设备你还敢用吗?其实,这个问题存在的原因是生产过程中的草草了事。所以,不仅要选购带有SE功能的IoT设备,还要提前了解心仪设备的安全风评哦!
backahasten 1 2019-8-27 14:59
3
0
se太贵了,微芯的se比一般的门锁主芯片还贵
lookzo 2019-8-27 15:04
4
0
解决了一些问题,提高了攻击门槛
游客
登录 | 注册 方可回帖
返回