物联网开发愈加深化，应用安全如何保障？
导语 | 随着物联网技术的发展与应用深化，开始对我们的社会生活产生广泛影响，然而物联网安全技术却发展缓慢，无疑会带来极大隐患。云+社区邀请到腾讯云物联网产品中心技术专家肖影老师，为大家分享如何构建物联网安全能力，为你的产品保驾护航！
一、 引言
1. 物联网安全背景
物联网业务深入多个行业，全方位影响人民生活，相应的安全问题也将带来严重威胁，甚至包括生命和财产安全。虽然物联网市场发展迅速，终端数量剧增，但安全隐患大，物联网产业链中安全环节占比低。
以家庭网络为例，根据信通院《2019年智慧家庭网络安全态势报告》，智慧家庭中 IoT 设备安全风险居高不下。
在工业物联网中，由于物联网设备负责重要的民生设施的控制，由于网络安全隐患带来的风险就更大。
2003 年 8 月14 日美国东北部地区和加拿大联合电网由于网络与 XA/21 系统的漏洞，被攻击后致使主服务器崩溃，导致发生大面积停电事故。
2008 年，黑客劫持了南美洲某国的电网控制系统，导致电力中断几分钟。
2008 年美国中央情报局 (CIA) 官员汤姆唐纳休 (Tom Donahue) 在“SANS”( 系统和网络安全 ) 贸易大会上透露，美国曾发生数起黑客通过互联网攻破当地供电网络导致数个城市出现照明中断的事故。
2008 年，美国国土安全局演示通过攻击电力控制系统后致使一台发电机物理损坏。
2011 年夏天在美国黑帽大会上黑客展示了可以利用执行内存转储、捕捉密码的 PLC 的后门程序。如对 PLC 进行 24 小时的攻击可导致电厂爆炸，这意味SCADA(Supervisory Control And Data Acquisition) 系统也将成为直接攻击的目标。
2016 年美国东海岸网络瘫痪攻击事件：2016 年的攻击发生后，据统计全球感染Mirai 的设备已经超过 100 万台，攻击采用了大量 IoT 设备，例如网络摄像头、路由器、DVR 等，实验表明，8 万个 IoT 僵尸能发起 500Gbps 的 DDoS 攻击；89 万个僵尸足以打垮全球任何一个电信运营商。
2. 物联网安全和互联网安全的区别
互联网安全领域存在的问题，物联网应用都存在。物联网安全是互联网安全的延伸，物联网只会带来新的安全风险，如下：
由于物联网应用设备类型碎片化严重（从单片机到 ARM A系列、从没有 OS 到Linux、Android），大多数情况下物联网设备资源都受限，无法运行一个具备完整安全策略的操作系统，甚至连基于证书认证的 TLS 都无法运行。
物联网设备通常是常年开机，没有人机交互，或者人机交互不频繁。很多时候，物联网设备被攻击了都无法被感知。比如：家里的路由器、IP 摄像头，如果被黑客获取权限用来作为发起攻击的肉鸡，用户通常是无感知的。
协议的安全风险：物联网的通信协议诸如 ZigBee、蓝牙、NB-IOT、2\3\4\5G 等等，这些协议的在互联网应用上并没有使用到，互联网安全策略也无法覆盖到这些协议，物联网协议带来了协议的安全风险。
边界的安全风险：互联网时代更多的应用模式是 C/S（B/S），即客户端/服务端模式。这个模式有一个非常清晰的“边界”。企业可以通过部署防火墙、IPS 等网关类设备来提高企业服务的安全性。但在物联网时代，设备遍布全球各地，黑客可以直接对设备发起攻击，没有“边界”的存在了，传统网关类防护设备用处不大。
系统的安全风险：互联网时代的终端保护（EDR），主要针对 Linux 和 Windows 两类系统，而物联网时代，设备采用的嵌入式操作系统诸如 UClinux、Freertos 甚至是无操作系统的设备等等，传统的终端系统安全方案无法适用于物联网时代的嵌入式操作系统。
APP 的安全风险：互联网时代的 APP 主要也是 C/S 模式，但物联网时代，APP 不仅要与云端通信，更可能与设备直接通信，APP to Device 这个链路中包含了许多如设备身份认证、硬件加解密、OTA 升级等安全策略，这也是互联网时代没有的。
业务的安全风险：物联网的业务场景会产生许多互联网时代收集不到的数据，比如传感器数据、用户行为数据、生理数据、地理位置数据等等。这些数据的产生-传输-处理过程涉及到整个业务体系的安全架构，这些数据的收集、传输、处理过程需要新的安全防护策略和监管体系。
研发的安全风险：物联网产品的研发流程涉及到嵌入式的安全开发，这是互联网应用中不存在的。在嵌入式端的开发又涉及到：嵌入式系统安全、逻辑安全、加解密安全、认证安全、接口安全、存储安全、协议安全等等新的安全风险。
合规的安全风险：目前物联网行业还没有一套业内普遍使用的完整法规要求，虽然等保0 涵盖了物联网安全，但 2019 年中才正式发布，还处于行业推广期。此外，对于物联网设备的安全测评与互联网产品的测评方式完全不同，目前也缺乏一套国家发布的安全测评规范。现阶段安全测评都是“以结果为导向”而非“以合规为导向”。
二、物联网安全能力构建之路
物联网安全要解决的两个核心问题：身份认证和链路安全。
腾讯云物联网产品中心在探索物联网安全的过程中经历了以下演进：TLS 证书 -> SE 安全芯片 -> ARM TEE 安全 -> 软件加固。
在互联网中，基于 TLS 证书认证的 https 协议已经成为现代互联网安全的重要基石。物联网中也经常会使用如下 X509 证书进行身份认证和安全通信：
1. TLS证书链认证
但 TLS 证书认证要在物联网设备上落地会有不少的挑战，首先就是资源太大，比如：
（1）使用TLS证书：
RAM：55.949 KB ROM：105.308 KB
（2）使用TLS PSK：
RAM：35.996 KB ROM：104.023KB
这里多出的50+KB RAM 和 100+ KB 的 ROM 在物联网终端设备上是一个非常大的不可接受的资源消耗。以出货量较大的STM32F103系列为例：
由于 MCU 上通常还需要运行一个 rtos 系统，那就算是最贵的系列，也无法提供足够的资源运行 TLS 证书认证。
除了资源问题之外，还有一个存储安全的问题：其证书或者密钥如何存储也是一个大问题，一旦证书或者密钥被批量攻破，那么 TLS 的安全性也大打折扣。
为了解决资源消耗太大的问题，物联网产品中心和桌面安全管家团队一起制定了一个具备双向认证、前向安全且资源消耗少的安全认证协议 TID，其中借鉴了部分 TLS1.3协议中的一些优点。
对于存储安全的问题，我们引入了基于安全芯片或者 ARM TEE 进行身份密钥信息的存储。
2. 安全芯片
（1）从智能卡到安全芯片
智能卡很早就在我们的日常生活中扮演了重要角色，主要分为无接触智能卡和接触智能卡。
最常用的无接触智能卡就是我们的身份证了，里面含有一块芯片，包括：射频模块、存储模块、加密模块和控制芯片。
最常见的接触式智能卡就是手机中的sim卡，安全芯片就是由接触式智能卡演变而来，且在物理硬件设计上就具备了很好的安全性，如：防侧信道攻击、防拆技术等。现在一些高端的智能手机，比如iphone、华为高端手机中都会采用SE安全芯片来存储指纹这类重要的隐私数据。
（2） 安全芯片接入规范
由于安全芯片行业是从智能卡发展而来，所以安全芯片的接口也大都沿用了智能卡时期的通信协议 ISO7816。
为了使安全芯片厂家能够接入腾讯云 TID 物联网安全认证体系，我们吸收了各家安全芯片厂家（NXP、ST、复旦微电子、华大电子、为远电子等）安全芯片接口的优点，加上 TID 认证协议的要求，制定了《安全芯片接入腾讯云TID的规范》。
在规范中，定义了11条 APDU 指令，涵盖了高端安全芯片和低端安全芯片在不同场景下的使用需求，如下表所示：
指令 |
CLA |
INS |
说明 |
GetChallenge |
00 |
84 |
生成随机数 |
ImportSessionKey |
80 |
5A |
导入临时会话密钥，用于对称加解密 |
SymCrypto |
80 |
F0 |
对称加解密 |
AsymCrypto |
80 |
F2 |
非对称加解密 |
GenerateKeyPair |
80 |
F4 |
生成临时密钥对 |
GenerateSharedKey |
80 |
F6 |
生成共享密钥 |
GenerateSessionKey |
80 |
F8 |
在SE内部生成SessionKey |
ComputeDigest |
80 |
FA |
计算摘要 |
GetTid |
80 |
FC |
获取设备TID |
GetVendor |
80 |
CA |
获取芯片厂商信息 |
SecurityStorage |
80/84 |
E2 |
支持自定义数据的存储和读取 |
（3） 安全芯片TID SDK
架构如下图所示：
主要是将不同厂家和不同总线的适配代码剥离成一个抽象层，方便进行SDK的适配移植。
3. TEE 物联网安全
由于安全芯片会带来额外的物料和硬件开发成本（需要额外添加一个安全芯片及相应的电路），对于 ARM Cortex-A 系列的芯片，可以利用 TEE（Trusted Execution Environment）来接入 TID 认证体系。
其中，TEE 所能访问的软硬件资源是与 Rich OS 分离的。TEE 提供了授权安全软件（可信应用，TA）的安全执行环境，同时也保护 TA 的资源和数据的保密性，完整性和访问权限。
为了保证TEE本身的可信根，TEE在安全启动过程中是要通过验证并且与 Rich OS 隔离的。在 TEE 中，每个 TA 是相互独立的，而且不能在未授权的情况下不能互相访问。
目前腾讯云物联网已经基于 OPTEE OS 开发了进行 TID 认证的 Trusted Application 和 Client Application，且符合 TEE GP规范。
4. 软件加固
软件加固和以上几种安全方式相比，成本最低，不需要额外增加芯片，也不需要进行芯片支持 TEE 进行 TA 的开发。目前实现软加固通常有两种方案：白盒密钥和代码混淆，也可以将两者混合使用。
（1）白盒密钥
白盒密钥的核心就是在设备端不存储密钥，而是存储进行白盒处理过的动态库或者对应的白盒密钥表，确保没有密钥存储在设备中也能实现相应的加解密操作。详细原理如下图所示。
左图是正常的解密操作，需要输入密钥以及密文，通过算法获取到明文。而右图中，无需输入密钥，只需输入密文，即可获取明文。白盒处理过的解密操作复杂度大大提升，提升了黑客攻击破解的难度。
目前已有基于白盒密钥的 TID 端侧实现方案并已经上线。
（2）代码混淆
代码混淆是将物联网设备上的代码，转换成功能上等价但是难于阅读和理解的形式的。最著名的和代码混淆相关的开源项目就是 Obfuscator-LLVM，主要是三种方式：控制流扁平化、指令替换、虚假控制流程。
上图为 Obfuscator-LLVM 提供的一个 Control-Flow-Flattening，通过控制流扁平化之后，二进制代码更难进行逆向。
指令替换是一种比较简单的替换规则，就是将一些简单的运算复杂化，比如汇编指令中最常见的加法可以被混淆成若干个条带有随机数的指令。比如 a = b + c; 可以被混淆为（r = rand(); a = b + r; a = a + c; a = a – r;）在进行大量的指令替换之后，也会极大的增加黑客攻破代码的难度。
虚假控制流是在代码中加入大量控制流，这些加入的控制流又不会影响代码的正常运行，只是起到了提高代码逆向的目的。
由于 Obfuscator-LLVM 应用太广泛，这些混淆技术被大量研究，市面上已经有deobfuscator 的工具，可以辅助进行混淆代码的逆向分析。
基于这个原因，腾讯云物联网产品中心已经和桌管安全团队进行了合作进行基于指令级别（Obfuscator-LLVM是基于代码块）的随机混淆的 TID 工具库，即将上线。
三、物联网安全行业规范
我们在和物联网厂家沟通时，发现大家普遍都会有一个痛点：虽然花费了不少成本来提供物联网产品的安全，但是怎样才能被终端用户所认可呢？物联网安全虽然有国标，但都是进行最低限度的要求，符合国标并不能给产品带来额外的价值。
目前腾讯云物联网产品中心通过和 TEG 安全平台团队合作，制定了物联网安全的行业规范，全方位的制定了物联网安全规范，如下图所示：
比如：针对门锁行业，我们定义了一套安全打分标准，对于不同得分的产品授予不同的徽标。最后也希望未来有更多小伙伴加入进来，和我们一起交流合作，促进整个行业安全规范的完善和落地。
近期沙龙
7月30日，腾讯云数据安全沙龙讲座即将开启。扫描海报二维码或点击文末「阅读原文」，即可预约本场沙龙直播~