IoT技术架构与安全威胁

                                            IoT技术架构与安全威胁

来源：http://www.broadview.com.cn/article/62

物联网IoT的英文全称是“The Internet of Things”，即物联网就是物物相连的互联网，也就是人们常说的万物互联。万物互联是一把双刃剑，它既能会给生活带来巨大的生活便利，同时也会带来巨大的安全风险。

本文选自《智能硬件安全》一书，将从技术层面向您介绍IoT技术架构与安全威胁。

1 IoT安全概述

IoT的英文全称是“The Internet of Things”，即物联网就是物物相连的互联网，也就是人们常说的万物互联。

IoT时代，所有设备都将内置一个智能芯片和智能OS，所有设备都能通过各种网络协议进行通信，而且是7*24小时相连，能够产生真正海量的大数据；并且，伴随大数据应用的逐步升级，也会让机器变得更加智能，甚至具备自己的意识。万物互联的背后，用户所使用的联网设备，都有可能存在安全漏洞。目前，国内智能硬件的生产和研发都处于起步阶段，以互联网创业公司为主，很多创业公司都参考国外标准的基础架构，然后快速实现产品使用流程、上线、众筹及发布，在整个阶段没有过多地考虑安全的问题。然而，安全问题会给用户带来极大的困扰，甚至对互联网造成一定的威胁。IoT所暴露的安全问题越来越多，被关注度也与日俱增。

2015年7月，菲亚特克莱斯勒美国公司宣布召回140万辆配有Uconnect车载系统的汽车，黑客可通过远程软件向该车载系统发送指令，进行各种操作。例如减速、关闭引擎、让刹车失灵等，严重危害人身安全。在2015年8月的黑帽大会和世界黑客大会上，包括汽车在内的各种智能设备都被爆出安全漏洞，黑客利用安全漏洞可以控制智能手机、汽车、交通红绿灯，甚至搭载有智能狙击镜的高级狙击步枪。在2016年的RSA2016大会上，隐私顾问Rebecca Herold表示，大量IoT设备的发布，没有任何安全和隐私控制。一些暴露在互联网上的IoT设备被感染了蠕虫病毒，并定期发起拒绝服务攻击。

2 IoT技术架构分析

IoT技术应用虽然复杂，但是从逻辑上看可以把它的技术架构分为云平台、设备终端和手机终端三个方面。能实现的流程是通过手机端下载APP与云端进行通信，发送控制指令，再由云端转发控制指令给设备终端。这样就能够实现在任何环境下，控制一台连接互联网的智能设备，从而实现智能化。

2.1 云平台

云平台是控制IoT的控制核心，它将用户的APP和设备终端控制紧密地联系到了一起，云平台将智能设备接入公网增加了安全风险。居民家中、工作场所及公共空间里的物联网设备生成的潜在敏感型数据，会在公共互联网中来回穿梭。对于制造商及这些联网设备的用户来说，确保这些数据的安全可谓是重中之重。

IoT云平台按照功能类型大致可分为三类：转发云、功能云和第三方云平台。每种云平台对于手机终端和设备终端的功能的偏重程度不一样，这也是我们在研究IoT安全时需要注意的。

1.转发云

转发云顾名思义就是指云端功能用于流量转发使用。这类云平台属于轻量级，自身代码和功能不多，主要功能是起到反向代理的作用，将处于内网的智能终端设备流量转发给手机，将手机控制流量转发给智能终端。转发云平台自身没有过多的功能。这类云平台的主要特点是快速转发，云端的功能负担比较小，成本低。手机客户端收到的数据和IoT终端产生的数据是一致的。所以以后对于这类云平台的分析，只需分析一种状态的数据包即可。

2．功能云

功能云实际上就是所有控制、信息等功能全部集中在云端的平台。这类平台的主要特点是手机终端和设备终端都是轻量级的，自身代码量非常少。在安全研究过程中，从手机终端和设备终端上来看是发现不了太多信息的。对使用功能云的智能硬件的安全研究，应将重点工作放在如何通过渗透测试手段获取功能云的权限，从而反向控制智能终端设备上。反之，对于功能云的防护，也应当把防护重心部署在功能云上。

3．第三方云平台

第三方云平台是指智能硬件产品原厂提供的云服务以外的云平台，如“某某微联”等智能硬件接入平台。这类平台的主要功能是为用户接入提供统一的接口，用户在拥有多个智能硬件的环境下，使用一个APP就可以实现统一控制。对于第三方云平台的安全研究，重点在于分析云端和设备终端的流量。目前，市面上大多数第三方IoT云平台都做得比较安全，而第三方云和原厂的云平台之间会统一API接口，有时找到API接口的文档，会对安全研究有帮助。

2.2 手机客户端

现今，大多数智能硬件都使用手机客户端作为控制终端，手机客户端可以作为智能硬件功能呈现和控制的主要手段。主流的手机客户端为iOS版本APP和Android版本APK。在开发智能硬件的过程中，由于iOS版本需要苹果公司审核，所以流程非常长，很多厂商都是先开发测试iOS版本，等到功能全部开发完成，就可以提交审核，然后快速开发APK版本。最终保证两个版本同时上线。

手机客户端的主要功能有信息查询、设备控制、状态反馈、远程升级、设备配对连网等，在这些功能背后有很多网站接口、引用的第三方库、类等。

目前，智能终端手机控制功能集成在第三方APP中，这样的开发方式需要第三方提供标准的SDK接口，统一标准的数据调用格式从而使智能终端控制和第三方APP完美兼容。

在IoT安全分析过程中，手机客户端是非常重要的一个步骤，而且手机客户端的分析门槛低，不需要有智能硬件就可以进行分析。通过手机客户端的漏洞去控制一台设备是非常有效的路径，安全人员应多加防范。

本书后面章节会详细介绍APP和APK的逆向分析方法。

2.3 智能硬件终端

1．硬件结构

从硬件上看，智能终端普遍采用的是计算机经典的体系结构——冯·诺依曼结构，即由运算器（Calculator，也叫算术逻辑部件）、控制器（Controller）、存储器（Memory）、输入设备（Input Device）和输出设备（Output Device）5大部件组成，其中的运算器和控制器构成了计算机的核心部件——中央处理器（Center Process Unit，简称CPU）。每一个处理单元都可以看作是一个单独的计算机系统，运行着不同的程序。每个处理单元通过一定的方式与应用处理单元通信，接受应用处理单元的指令，进行相应的操作，并向应用处理单元返回结果。

这些特定的处理单元芯片往往是以ASIC的形式出现的，但实际上仍然是片上计算机系统。

2．软件结构

在智能终端的软件结构中，系统软件主要是操作系统和中间件。操作系统的功能是管理智能终端的所有资源（包括硬件和软件），同时也是智能终端系统的内核与基石。操作系统是一个庞大的管理控制程序，大致包括 5 个方面的管理功能：进程与处理机管理、作业管理、存储管理、设备管理和文件管理。常见的智能终端操作系统有Linux、Tiny OS、BusyBox、OpenWrt、RIOT、Contiki等。

中间件一般包括函数库和虚拟机，使得上层的应用程序在一定程度上与下层的硬件和操作系统无关。应用软件则提供供用户直接使用的功能，满足用户需求。从提供功能的层次来看，可以这么理解，操作系统提供底层API，中间件提供高层API，而应用程序提供与用户交互的接口。在某些软件结构中，应用程序可以跳过中间件，直接调用部分底层API来使用操作系统提供的底层服务。

ARM优秀的设计和商业模式，使其非常适合智能终端的应用场景，因此目前智能终端所使用的CPU内核以ARM居多，主要有ARM9、ARM11、ARM Cortex A8等几种架构。另外，Marvell公司的PXA解决方案采用的XScale内核也有一定的应用。

3 IoT安全威胁分析

随着智能硬件创业的兴起，大量智能家居和可穿戴设备进入了人们的生活，根据Gartner报告预测，2020年全球IoT设备的数量将高达260亿个。由于安全标准滞后，以及智能设备制造商缺乏安全意识和投入，IoT安全已经埋下极大隐患，是个人隐私、企业信息安全，甚至国家关键基础设施的头号安全威胁。

目前，IoT存在5大安全隐患。

3.1 数据存储不安全

毫无疑问，移动设备用户面临的最大风险是设备丢失或被盗。任何捡到或偷盗设备的人都能得到存储在设备上的信息。这很大程度上依赖于设备上的应用为存储的数据提供何种保护。很多智能硬件手机客户端的开发者对智能硬件的配置信息和控制信息都没有选择可靠的存储方式，可以通过调试接口直接读取到明文或者直接输出至logcat中。用户身份认证凭证、会话令牌等，可以安全地存储在设备的信任域内，通过对移动设备的破解，可达到劫持控制的目的。

3.2 服务端控制措施部署不当

由于要降低对服务端的性能损耗，很多情况下现有智能硬件的安全策略是把安全的过滤规则部署在客户端，没有对所有客户端输入数据的输入检查和标准化。使用正则表达式和其他机制可以确保只有允许的数据才能进入客户端应用程序。在设计时并没有实现让移动端和服务端支持一套共同的安全需求。可以通过将数据参数直接提交至云端或客户端APK对参数过滤的限制，达到破解设备功能的目的。

3.3 传输过程中没有加密

在智能硬件的使用过程中，存在连接开放Wi-Fi网络的情况，故应设计在此场景下的防护措施。可以列一个清单，确保所有清单内的应用数据在传输过程中得到保护（保护要确保机密性和完整性）。清单中应包括身份认证令牌、会话令牌和应用程序数据。确保传输和接收所有清单数据时使用SSL/TLS加密（See CFNetwork Programming Guide）。确保你的应用程序只接受经过验证的SSL证书（CA链验证在测试环境中是禁用的；确保你的应用程序在发布前已经删除这类测试代码）。通过动态测试来验证所有的清单数据在应用程序的操作中都得到充分保护。通过动态测试、确保伪造、自签名等方式生成的证书在任何情况下都不被应用程序接受。

3.4 手机客户端的注入

手机客户端和Web应用程序的输入验证和输出过滤应该遵循同样的规则。要标准化转换和积极验证所有的输入数据，即使对于本地SQLite/SQLcipher的查询调用，也使用参数化查询。当使用URL scheme时，要格外注意验证和接收输入，因为设备上的任何一个应用程序都可以调用URL scheme。当开发一个Web/移动端混合的应用时，保证本地的权限是满足其运行要求的最低权限。另外，控制所有UIWebView的内容和页面，防止用户访问任意的、不可信的网络内容。

3.5 身份认证措施不当

授权和身份认证大部分是由服务端进行控制的，服务端会存在用户安全校验简单、设备识别码规律可循、设备间授权不严等安全问题。目前，可以在分析出设备身份认证标识规律的情况下（如MAC地址、SN号等都可以通过猜测、枚举的方式得到），批量控制大量设备。这个漏洞的危害在智能硬件里是最大的。

3.6 密钥保护措施不当

有些IoT产品在开发过程中考虑到了安全加密，比如使用AES128位加密作为传输加密的内容，使用MD5加密用户密码。在对于对称性加密方式的处理过程中，密钥的保存方式是至关重要的。在IoT解决方案中，手机客户端发起的请求需要对数据内容进行加密。也就是说，手机客户端内需要有AES的密钥。如果密钥存放的方式不当，可以轻而易举地将数据还原成明文进行逆向分析，从而进行进一步的攻击。在对大量的IoT设备进行安全研究后发现，设备基本上都会把AES的密钥存放在手机客户端中，有的做得很简单，写在了一个加密函数里。有的做得很深，放在一个lib库中。这些只是提高了技术门槛而已，不是解决安全问题的办法。

3.7 会话处理不当

很多智能设备都会因会话管理措施不当，受到攻击会话劫持，使设备被控制，所以说永远不要使用设备唯一标示符（如UDID、IP、MAC地址、IEME）来标示一个会话。保证令牌在设备丢失/被盗取、会话被截获时可以被迅速重置。务必保护好认证令牌的机密性和完整性（例如，只使用SSL/TLS传输数据）。另外，使用可信任的服务来生成会话。

3.8 敏感数据泄露

对于智能设备的安全研究，可以通过智能设备所泄露出来的数据，进行进一步分析，从而获得控制权限。所以必须保证安全的东西都不放在移动设备上，最好将它们（如算法、专有/机密信息）存储在服务器端。如果安全信息必须存储在移动设备上，尽量将它们保存在进程内存中。如果一定要放在设备存储上，就要做好保护。不要硬编码或简单地存储密码、会话令牌等机密数据。在发布前，清理被编译进二进制数据中的敏感信息，因为编译后的可执行文件仍然可以被逆向破解。

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-