物联网中的密码安全风险

仅有合适的算法仍然无法避免因系统设计、代码实现和存储方式等方面漏洞带来的安全风险，下面从协议、实现和使用三方面分别列举一些风险实例。

1.1 协议造成
WiFi密钥重装攻击

密钥重装攻击(Key Reinstallation Atacks， 即Krack)，该攻击对加密安全构成理论性的威胁，某些条件下，可以恢复用户明文数据、实施重放攻击、或者会话劫持。

攻击者与station完成四次握手，但不转发四次握手的第四帧Msg4给AP。此时station认为四次握手完成，开始加密并发送数据，AP会重传Msg3，station收到重传的Msg3后重装会话密钥PTK，重置报文序号，重置密钥流，重新开始加密数据。

BIAS攻击
BIAS(Bluetooth Impersonation Attacks)，即蓝牙仿冒攻击，是蓝牙通信标准的安全机制漏洞造成的，包括缺乏强制相互身份认证、角色转化过度轻松、认证过程降级等。
虽然细节较复杂，但是整体来看该漏洞还是比较容易理解的。

该攻击针对设备处理长期密钥(link key)的过程，首先需要知道：

(1) 两个之前配对的设备会共享一个长期密钥(LK)，该密钥用于对设备进行相互认证，并激活安全通信，LK协商好会长期使用。
(2) 蓝牙的通信标准包含LSC（传统安全连接）和SC（安全连接）两种连接机制，其中LSC只是单向认证，SC双向认证，但是可以并不强制。
(3) 蓝牙通信设备分为主从，一般由主设备向从设备发送连接请求。

下图展示设备利用LSC单向认证和SC双向认证过程：

简单来说，BIAS攻击可以做到

(1) 由于LSC单向认证，当冒充主设备向从设备发起请求时无需验证主设备是否知道LK，从而绕过认证。

(2) 由于LSC可以角色转化，可以冒充从设备发送角色转化包变成主设备，再重复(1)的攻击。

(3) 由于SC不是强制的，攻击者可以发包声称自己不支持SC，从而降级LSC，再重复(1)的攻击。

3.2 实现造成
开源供应
开源供应链攻击大家应该不陌生，尤其前段时间沸沸扬扬的solarwinds事件长期霸屏安全新闻首页。物联网设备系统一大特点就是包含大量开源代码，有些系统直接基于Openwrt，有些系统中web等模块基于开源软件。一旦这些开源(系统)软件爆出漏洞，影响的就是大量不同类型的设备，例如去年的Ripple20，19个0day漏洞影响数了十亿物联网设备。
传统服务都依赖开源，更何况满是数学公式的密码算法，估计几乎没有自己实现的。最常见的是openssl库，bleeding heart漏洞已经载入史册，不用过多介绍。

mbedtls也许是最小巧的ssl代码库，其高效、便于移植的特点使其在物联网设备开发中愈发流行。由于笔者对其涉猎不深，没有对其安全性作评估，在此不再展开。

逻辑接口
在不同功能模块衔接时可能会出现密码相关问题，例如某路由器直接传输用户的口令明文给cloud服务器，虽然设备与服务器通信外包裹着SSL，但是直接将用户信息明文发给厂商也暴露出很大安全隐患。笔者善意的认为可能是云服务认证和设备认证功能都已实现，比想改变某一方的逻辑，所以图省事直接发送明文，不善意的揣测大家都懂。

有些信息泄露漏洞会使得攻击者得到用户口令明文，如果不是内存泄露漏洞或者存在某种缓存机制，那么说明该设备的问题不仅限于信息泄漏漏洞。因为一般情况下设备存储(落地)中是不会有口令明文信息的。

3.3 使用造成
弱口令

弱口令不用过多解释，口令是密钥的种子，密钥通过口令扩展而来。从密码角度来说，现代密码基本遵循Kerchoff原则，即保密性基于密钥的保密性。

使用弱口令是谁的责任？

乍一看当然是用户缺乏安全意识，笔者想到CISSP应试时做到的一道练习题：安全人员在安全检查时怎样证明部门所属人员没有使用弱口令？打开所有设备逐个展示吗？答案其实很简单，就是展示设置弱口令在部门设备上无法通过安全策略。

是否联想到很多产品或者网站注册会强制要求大小写字母数字等，这样用户有经常忘记，所以找回密码功能非常重要，很多安全漏洞都处在找回密码的逻辑当中，所以对用户的认证并不是登录那一下，而是构建完善的AAA体系。所幸认证并不只有口令一种方式，越来越多的设备开始使用多种认证因素。

安全选项

但也并不是所有锅都是厂商来背，有些设备提供的可选的安全配置，用户不使用也没有办法，只能作建议，安全之路还是任重而道远。