随着无线移动互联网的普及，现在家家户户中几乎都会有那么一两个支持无线接入和远程管理的智能设备：烘干机会在工作完成后给主人发来提示“衣物已烘干”，体重秤可以提示主人“您今天是不是吃得有点多”，甚至连冷冰冰的门锁都能够摇身一变，成为那些喜欢弄丢钥匙的马大哈主人的贴心管家。这些曾经只是在科幻电影里面看到的场景，已经真真实实地“飞入寻常百姓家”了。
尽管智能家居设备的安全性一直是各方关注的焦点，但是在诸多安全研究者的眼中，针对智能家居设备的安全建模仍然还集中在“传统程序+运行于嵌入式设备”，更多地把过去安全分析的经验迁移到新的应用场景上：例如如何去挖掘嵌入式设备固件上的代码漏洞，抑或是寻找智能设备所对应的手机APP的安全问题。除此以外，少有研究关注那些智能家居设备所独有的应用场景中可能存在的安全隐患。不幸的是，往往是这些新出现的应用场景更容易发现严重的安全问题：在那些从已有桌面平台和智能手机平台迁移至嵌入式平台的代码中，安全漏洞大多已经修复，算法和协议的设计也从已有的经验中获益良多，唯独新出现的应用场景无法借鉴过往经验，更容易产生独特而高危的安全漏洞。
从去年开始，GoSSIP小组对一类智能家居上独有的安全问题——智能家居设备配网安全问题开展了深入的研究。所谓智能家居设备配网，是为智能家居设备（例如智能体重秤、智能空气净化器、智能洗衣机等）提供所接入Wi-Fi网络所需要的SSID和对应密码的过程。由于智能家居设备大多缺乏输入界面，使用者没有办法像使用计算机或者智能手机一样手工输入相关的信息，因此往往需要依赖于其他的一些途径（例如手机APP以及辅助的AP热点等）来向设备提供所需要的登陆凭据。我们的研究表明，这种在智能家居设备上独有的应用场景存在诸多安全问题。特别地，我们针对一类无线配网方案——SmartCfg配网方案开展的安全分析表明，当前市场上广泛使用的各类SmartCfg配网方案（来自于八家主流无线芯片商）中，多数方案均会导致Wi-Fi密码被攻击者解密获取，而针对市面上常见的超过60款智能家居设备的实际调查更是证实了这种危害的广泛存在：超过三分之二的设备确确实实受到此问题影响！我们的工作已经撰写了学术论文——Passwords in the Air: Harvesting Wi-Fi Credentials from SmartCfg Provisioning，并被无线安全领域顶级的国际学术会议WiSec'18录用，同时也将会在今年5月13日在北京举办的首届DEF CON China安全会议上做相关报告。为了让大家更好地了解我们发现的相关安全问题，我们论文的主要作者李昶蔚和蔡洤朴同学对这一议题进行详细的介绍，在专栏上第一时间和大家分享：
0x0 智能家居应用场景
一个典型的智能家居系统由三个部分组成：智能设备、App、物联网云平台。智能设备用来完成某一特定的功能（比如控制开关，监控室内温湿度），这些设备往往带有通信功能（通常利用Wi-Fi模块连入互联网）。同时，智能设备所属的物联网云平台还会提供相应的App，用来控制设备并了解设备的状态。云平台用来管理数据的存储和实现远程控制。
如果App和智能设备处于同一个Wi-Fi环境下，App就可以与设备直接通信，此时，通过App向设备发送控制指令而不需要与云平台交互，智能设备可以向云平台上传自身的状态。为了支持在家庭外面（如在公司）远程管理物联网设备，智能设备还支持通过App远程控制，这种模式下，App通过云平台作为中转实现改变设备的状态，而智能设备只需向云平台同步状态即可。
在智能家居的领域中，目前大多数智能设备都采用无线网络连接，设备入网便是一个必不可缺少的环节。智能设备入网后，用户可通过移动端上的App来远程操控设备，让其按照设定的功能执行一系列操作。假如用户买了一个智能插座，因为插座本身没有输入界面，无法通过自身连入互联网，此时就要借助 App输入SSID对应的PASSWORD来完成配网操作。这种配网技术是一种新的应用场景，因此也会引入新的安全风险。
0x1 SmartCfg配网方案
Texas Instruments（TI）在2012年首次推出Smart Config这种新型的配网技术，该技术旨在帮助那些没有用户交互界面的智能设备（例如插头，门锁，冰箱）连接到无线网络。经过五年的发展，这种技术已经被各种无线芯片厂商广泛接受。诸如Realtek，MediaTek，MXCHIP和Espressif等无线芯片制造商也实现了他们类似的技术。在本文中，我们将使用SmartCfg来指代所有这些类似的技术。通常，SmartCfg配网技术具有三个典型的特征：
- 智能设备需要依赖App将Wi-Fi密码进行编码并通过广播发送给设备。
- 智能设备开启无线网卡的混杂模式被动监听数据，并且不知道发送者的身份。
- Wi-Fi密码被编码到一连串802.11数据包的元数据中（例如数据包的长度）。
所以，即使802.11数据包中的数据字段使用WEP或WPA2加密，设备仍然可以通过监听空中数据并解码元数据的信息，而不管数据的实际内容，可以理解为一种侧信道的传输方式。
如图1所示，根据数据被编码的方式，我们可以把SmartCfg的数据编码模式分为三类：
1. Data in Multicast Addresses （DMA）
此时数据被编码在Destination Mac Address的后23bit，即每一次发包过程可以传输23Bit。显而易见，这种模式的效率比DPL更高。
2. Data in Packet Length （DPL）
此时数据被编码在一连串802.11数据包的Length这一字段，即每个数据包的长度随着发送数据每一字节的ASCII值的改变而改变。
3. Hybrid
在实际使用中，也可以同时以上两种方式。比如在Destination Mac Address字段中存放Index，在Length字段存放Data。使用Index的优点是当解码时，可以根据Index的序号得知数据包的顺序。
根据我们的观察，前导码是SmartCfg的一个很重要的特征。前导码是一连串固定模式的数据包。使用前导码有两个好处，（1）可以通过前导码识别出符合特定协议的数据包的开始，以便过滤掉空中其他来源的数据。（2）数据包的数据经过不同的终端进行加密，加密后的数据长度会发生变化，通过前导码可以矫正这个偏倚。
0x2 SmartCfg安全分析
我们假设攻击者把配网过程中最有价值的Wi-Fi密码（和相应的Wi-Fi SSID）作为主要目标。并且攻击者处于在无线局域网（WLAN）之外，无法物理或远程连接到设备（否则认为他已经可以访问内部网络）。要获得此凭证，攻击者只能从无线数据中恢复Wi-Fi密码（即使数据可能被加密）。我们还假设攻击者不会事先知道被攻击者所使用的智能家居设备和移动应用程序，但他可以事先收集典型的SmartCfg解决方案，然后对其进行逆向工程并恢复使用的数据编码方案。
分析SmartCfg的安全性的困难性包括：
1. 如何识别智能设备中使用的SmartCf配网方案
尽管我们事先知道多种SmartCfg的解决方案，但我们的分析设备都是真实的智能家居设备，而不是开发板。设备制造商通常不会标注哪种解决方案用于某个设备。因此，我们应该利用不同种类的旁路信息（例如，使用的无线芯片的型号）来帮助推导设备使用的SmartCfg解决方案。识别目标设备使用的是哪个SmartCfg方案为后续的安全分析打下了基础。
2. 如何恢复配网协议中经过编码的Wi-Fi凭据
即使知道了目标设备采用哪种SmartCfg方案，我们仍然无法确定其配网协议。因为芯片供应商提供的解决方案仅供设备制造商参考。制造商可以修改模板并实现自己的配网协议。要了解数据的编码方案，我们还需要针对智能家居设备的代码（即，固件和应用）进行逆向工程。由于制造商通常不会提供源代码，对这些不同架构的二进制代码逆向分析通常来说是比较困难的。有时甚至可能无法获得设备的二进制代码，唯一可用于分析的数据只有网络流量。
基于SDK代码的安全分析
SmartCfg的SDK可以分为两类：device SDK和mobile app SDK。Device SDK用来帮助设备固件的开发，mobile app SDK用来帮助移动终端与智能设备通信。如果一个设备（及其相应的应用）采用某种SmartCfg解决方案并集成了该解决方案的SDK，我们可以利用该SDK的功能来识别其使用的解决方案。我们发现大多数芯片供应商通常在其网站上提供SDK和文档。因此，我们可以直接下载它们作为我们分析的参考。尽管我们收集的SDK包含device SDK和mobile
app SDK，但是逆向分析只需关注mobile app SDK，原因有二：首先，device SDK通常用于帮助分析设备固件。但是，如果制造商不提供固件并且Flash被保护以免被读取，就很难获取固件。而且，大多数智能设备的固件都是封闭的，对这种二进制程序的逆向工程通常是非常耗时的。其次，移动应用程序和设备之间的通信协议可以只通过分析移动应用程序来恢复。明显，移动应用程序的分析受益于一系列成熟的工具。简而言之，我们可以从芯片供应商的网站下载mobile app SDK，然后从应用市场收集应用。为了检查收集的应用程序是否包含某些mobile app SDK，我们利用Android第三方库检测器libscout来检查目标应用程序与SDK的jar包之间的相似性。我们对native code也有相应的检查。由于Native code通常编译为共享库（.so），并通过JNI调用其导出的函数。我们可以在mobile app SDK的共享库中收集函数导出表作为特征。当在Native code中找到相同的函数名称，我们就可以确定某种方案被使用。
单纯基于流量的分析
1 嗅探
我们使用TL-WN722N这块网卡来对空中的数据进行嗅探，将无线网卡设置为监听模型，抓取空中所有的符合802.11协议的数据包。然后使用Scapy库编写了一个程序将数据解析并记录下来。我们定义了一个三元组(source mac address,destination mac address,data length)。同时，我们还记录了当前环境下存在的SSID信息和其对应的BSSID。
2 定位前导码
我们发现，App在配网时都会先发出一段前导码（或者是同步码），目的是通过前导码过滤出符合特定协议的数据包。从监听者的角度，匹配前导码是确定配网特征和配网发生最好的特征。通过前导码还可以确认source mac address，并通过source mac address过滤掉其他所有非配网相关的数据包。我们可以根据三元组来定位其数据存储的位置。比如，如果destination mac address=ff:ff:ff:ff:ff:ff，那么可以认为数据是存在data length。
3 差分分析
既然我们知道了数据所处的位置，我们就可以通过输入不同的password字段，并触发配网流程。通过程序记录下每次的三元组，通过三元组的特征判定其存储数据的位置，提取出数据，生成一条payload。然后比较两条payload的不同之处，通常来说，改变password的一个字节，payload对应的位置也会发生细微的改变，但是用于校验的CRC值却会发生明显的变化，这个观察使得我们能有效的定位password的位置。
0x3 安全分析结果
我们分析了市面上八家主流无线芯片厂商所提供的SDK（其市占率如图2所示，图中各解决方案仅显示头两个字母）。
其中有六款产品的SDK存在严重的安全问题，直接导致Wi-Fi密码的泄露（安全问题如图3所示）。
同时，通过对市面上821款流行的智能家居应用，我们发现其中有64款应用使用SmartCfg技术，而在其中，42款应用存在上述分析中的安全隐患，而这无疑显示出了在智能家居领域所存在的广泛安全隐患。以A厂家为例，其下的一款产品是一款装备有Tensilica 32位微处理器的低功耗高整合度的Wi-Fi芯片模组。其设计的SmartCfg提供通信格式的内容如图4所示
其中apPwd和apSsid是明文传送的信息，设备在混杂模式下接收Wi-Fi配置信息，而在这段时间中任何人（包括用户和攻击者）都能直接监听到该数据流。由于信息直接以明文进行传输，攻击者很容易就可以获取隐私信息。
而在另几家公司B、C厂家所设计的方案中，其在SmartCfg的配置环节使用了预共享或硬编码的密钥。因而即便设计者使用了合理的如AES的加密方式，攻击者仍然可以通过对市面上已有的产品进行逆向分析得到加密密钥后，解密与上述相同方式得到加密传输信息从而获得用户的Wi-Fi凭据。
而在两家著名公司D、E当中，其设计了一套复杂的通信协议格式（图5）：
在这套协议中我们可以发现，为了实现SmartCfg配网过程中的执行效率，SSID和密码并没有进行任何加密，而是通过对每个字符的ASCII码值加上一组确定的等差数列作为基底的方式对Wi-Fi凭据进行编码后再传输。因此即便攻击者无法通过逆向分析获得这组等差数列的具体数字分布，其也可通过简单的差分分析的方法恢复出传递的消息内容，进而获得用户的Wi-Fi凭据隐私信息。
0x4 安全防护对策
截止我们的学术论文投稿前，我们都已通过官方联系途径对涉及到的厂商及其协议中存在的问题进行了通报。许多厂商也及时进行了相应。同时，我们也提出如下一种较为合理的安全设计实践。
如图6所示，首先，智能家居App通过物理接触（如扫描产品上的二维码等特定标识）来获得产品密钥和设备ID。从而攻击者无法通过枚举来获得产品信息。
之后，App向云端服务器发送用户自身的身份信息和第一步中获得的产品密钥和ID，服务器计算生成用于独有的UUID并传回给App。
接下来，App通过HMAC算法（如HMAC_SHA256），使用设备ID和密钥生成加密传输数据用的对称加密密钥。注意由于攻击者并不能实际接触到设备，无法获得需要物理接触来获得的二维码等信息，因此其无法生成该密钥。
App生成密钥后使用该密钥在802.11协议下对Wi-Fi凭据和UUID信息进行加密后发送。
设备在使用SmartCfg技术接收到数据后，使用在其固件中预烧录的特定设备密钥（即使用HMAC算法生成的加密密钥）对消息进行解密。如果解密出的结果符合其设计的特定格式，其提取出其中的Wi-Fi凭据信息，连接上家庭无线网络并发送UUID至云服务器验证，如果UUID非法，设备应拒绝来自智能家居应用的远程控制。
0x5 总结
上海交通大学GoSSIP软件安全小组长期致力于物联网和智能家居安全研究。通过审计Wi-Fi提供的SDK芯片供应商和分析智能家居应用程序，我们针对真实世界的智能家居设备进行Wi-Fi配备的一类常见解决方案——SmartCfg解决方案开展了系统性安全分析，并对821个流行的智能家庭应用App进行了安全审计。我们发现，尽管SmartCfg方案方便了Wi-Fi配置，现有的SmartCfg解决方案很少认真考虑并采用隐私保护，因此引入了较多的安全威胁。我们希望我们的研究可以提高相关产业安全问题的意识，并指导芯片和设备的开发人员构建更安全的SmartCfg配网解决方案。
声明：本文来自信息安全GoSSIP，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
