HW期间，为防范钓鱼，即日起FreeBuf将取消投稿文章的一切外部链接。给您带来的不便，敬请谅解~

密码学与物联网安全

密码学是网络互联的安全基石，互联网离不开密码学，物联网也离不开密码学。密码学本质是应用数学的分支，研究领域需要较强的数学（主要是代数、概率论和数论等）功底，本文不涉及密码（后文中的密码都指代密码学）算法细节，笔者仅总结出一些易于理解的密码与物联网安全关联，提出物联网可能的涉及密码安全风险，并给出一些个人拙见。

一、密码学简介

密码可提供加密和认证两大服务，其目的就是解决网络互联中的CIA问题，即机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)。不同应用场景对CIA程度要求不同，使用密码工具侧重点也相异，三者在动态中形成平衡。

零信任是这几年的热门话题之一，尤其去年疫情催生更多远程办公场景，VPN又饱受诟病，零信任赚足眼球。简单来看，零信任虽然概念较新，但是所应用的技术并不新颖，就是将之前的在(传统)外网应用的密码工具一视同仁的应用在(传统)内网上，通过动态认证完成整套信任体系。

密码的应用场景远不止如此，比如区块链实现的基础就是Hash函数这样的密码工具，在此就不一一列举。抛开复杂的数学实践，下面简单介绍密码提供的常见工具，包括：

单向散列(Hash)函数

将任意长度的输入消息串变化成固定长的输出，所谓单向就是过程不可逆。不同的消息串生成的Hash值不同，否则就称其存在碰撞，这也是MD5被逐步淘汰的原因。

系统不会直接存你的密码明文(口令)，而是存其Hash过后的输出值(现实环境还会加盐或者加密进一步增强安全性)，因为定长方便存储，也不至于在系统存储中直接获得口令，需要认证时再动态计算比对。

消息认证码

消息认证码是经过特定算法后产生的一小段信息，用来检查在消息传递过程中，其内容是否被更改过，即确保消息的完整性。

这里的算法就可以用到上面介绍的Hash函数，通过计算Hash对比收到消息中的认证码即可判断完整。当然仅使用Hash会有明显漏洞，篡改者将消息和Hash一起修改就bypass了认证，现实使用中还会加入密钥作为认证凭据，这里不再展开。

对称加密算法

加密与解密大家都很熟悉，两个过程都需要密钥，当这个密钥相同时，加密方法就称为对称加密。

公钥密码算法

与对称密码相应，公钥密码又称非对称密码，即加解密密钥不同。

公钥密码一般基于数学难题，其发明在密码史上是一次里程碑式的飞跃，有了公钥密码理论才建立起现代网络安全基石PKI(公约基础设施)。因为加解密不同，个人只保管自己的私钥，不用分别与所有人通信的密钥(每个都不同)。值得注意的是，公钥密码算法效率较低，一般只做密钥协商，消息还是使用对称密码加密。

数字签名

利用私钥加密(签名)，公钥解密(验签)可以保证消息的不可否认性，因为私钥就是个人身份的象征。

伪随即生成器

世界是随机的吗？自然世界好像有规矩可循，量子世界似乎没有，不管怎样人造序列很难真随机，除非一直掷硬币。在加密中我们希望密文无规律可循，但是明文是有规律的，所以密钥序列越随机加密效果越好，但事与愿违，只要足够长总能找到些规律，真随机做不到就引入了伪随机生成器。

依据加解密时是否给消息分组，加密可分为分组加密和序列(流)加密。伪随机生成器一般用于序列密码的密钥生成，可以用LFSR(线性反馈移位寄存器)或者RC-4这种面相字节的算法。

二、密码学与物联网

2.1 物联网安全中密码学的应用

物联网继承了互联网的密码技术，其中有大量与传统互联网相同的网络协议、流量加密和认证方法这等就不再赘述，仅列举一些特别的应用。

固件加密

有些物联网设备选择加密自己的固件，网上能下载到固件是加密过的，用以提高分析门槛，只有在刷机时由升级程序解密写入Flash。一些设备会加密bootloader，甚至调试接口也是需要认证，此类设备通常对安全性要求很高，另一些更复杂设备会使用硬件加密，加密模块由单独的芯片提供。

怎样判断固件是否被加密？

判断方法可能很多，binwalk解析不出来，没有有意义的字符串。从密码的角度来看，因为密文是随机的，所以加密后的固件中包含的0 bit和1 bit个数相近(注意去掉固件头信息)，所以如果01相近，该固件很有可能是加密的。

怎样解密固件？

简单来说就是需要逆向升级程序，程序可以从设备提取、找历史固件解包或者通过shell传输，具体方法这里不再赘述，感兴趣的小伙伴可以看一下之前一篇固件相关的文章。

无线电协议

与网络协议相同，无线电协议在设计时也要将安全性考虑在内，这就离不开密码学。比如WEP/WPA/WPA2是为wifi设计的加密协议，ZigBee可选择AES-CCM作为安全方案，BLE在链路层完成加解密(LE)，网上还有许多诸如NFC读加密卡教程等等。

许多无线协议安全(加密)选项是可选的，由于很多设备，尤其智能家居，存放位置私密，不是在家就是随身携带，就有种不需要开启安全机制的错觉，随着近源渗透带来不断攀升的安全风险，必要的保护机制才是明智之举。

多因素认证

上文提到密码的两大范畴是加密和认证，认证依据凭据不同可分为三类：

(1) 你知道什么 (密码，口令)
(2) 你有什么 (卡，U盾)
(3) 你是谁 (指纹，虹膜)

物联网设备五花八门，认证方式也可以多种多样，比如一个智能门锁，可以输密码(1)，可以用手环(2)，还可以用指纹(3)。这背后每一种认证都离不开密码技术的支持。

指纹/虹膜是认证方式就一定比口令安全吗？诚然，指纹/虹膜信息比口令难获取和伪造的多，但是一旦泄露也难更换的多。所以一般可以叠加(1)(2)，就是所谓的多因素认证，多因素认证一般只在复杂设备上有需求。

隐私数据

与传统PC或服务器不同，物联网设备上很少有直接运行数据库服务的，其数据存储安全就需要其他解决方案。尤其当下，个人隐私保护需求和力度加大，设备中的配置、个人信息等敏感数据在设计安全存储及传输时也需应用适合的密码技术。

在设备逆向中发现一些厂商不知道是缺乏密码学常识还是刻意回避，在存储和传输中存在较大安全隐患。代码实现漏洞可能在所难免，但设计缺失只能代表该产品并不认为安全在自己的责任范围内了。

2.2 传统算法与物联网需求的矛盾

不同应用场景安全构建需寻求CIA的平衡，互联网安全更关注算法的安全强度，而物联网更加关注算法的执行效率。小型资源受限设备(如智能穿戴设备)需要根据其计算能力、内存需求和物理尺寸的大小来设计算法。所以在智能卡、智能电表、医疗植入设备或土壤传感器等设备可能无法承受RSA、AES和其他主流加密算法。

联网设备需要高效、轻量级的加密算法，当然基本安全性也必须保障。现在至少有24个轻量级分组密码算法在设计时考虑了这些约束。美国国家安全局提出Simon和Speck两类轻量级分组密码算法，分别针对硬件优化和软件优化，可以在CryptoLUX Wiki上找到其列表和技术特性。

三、物联网中的密码安全风险

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

3.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体系。所幸认证并不只有口令一种方式，越来越多的设备开始使用多种认证因素。

安全选项

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

四、写在最后

随着多种技术与物联网融合，随之而来的即有机遇也有挑战。智能家居等消费物联网方面，IPv6的普及使得每个设备都可能暴露在外网；工控设备方面，可用性高需求使简单的拒绝服务造成的损失也无法承受，而其安全防护水准远落后于传统网络；边界防护设备方面，SDN-WAN、远程办公等需求驱动很多厂商在设备上集成大量新功能，代码冗杂也带来新的安全隐患。笔者认为，对于这些问题，密码技术可能不是解决方案中的决定因素，但一定是绕不开的环节。

参考资料

https://mp.weixin.qq.com/s/R26uTLwxu22BppkV59LlzA

https://zhuanlan.zhihu.com/p/152579869

https://securitygossip.com/blog/2020/06/28/bias-bluetooth-impersonation-attacks/

https://www.infineon.com/dgdl/Infineon-The+Dangers+of+Using+OpenSSL+for+Secure+IoT-ABR-v03_17-EN.pdf?fileId=5546d4625b10283a015b1e96f2b100e3

https://pierrekim.github.io/blog/2017-09-08-dlink-850l-mydlink-cloud-0days-vulnerabilities.html