从车联网安全到BLE安全(二)

2018-08-14 160362人围观 ,发现 1 个不明物体 终端安全

* 本文作者:麦片与老干妈,本文属FreeBuf原创奖励计划,未经许可禁止转载

0×00前言

文章迟到了3个月,太忙自己又太懒对不住~~

上次文章主要描述了智能网联汽车,整体上可能遭受的攻击风险;同时对OBD设备的安全性进行了简单的分析,提供了一些外部攻击的思路。此文着重从BLE(低功耗蓝牙)方向对智能设备的安全进行分析。

0×01 BLE安全基础

先看看BLE的基础知识,以及BLE自身在安全方面的考虑。

BLE的基础知识,雪碧已经对其进行了详细的描述,我再啰+/嗦几句

【传送门】http://www.freebuf.com/news/88281.html

其实我们蓝牙协议主要分为传统蓝牙和低功耗蓝牙。

对 于传统蓝牙来讲,当提出主动连接的设备(搜索设备)和被连接的设备(被搜索设备)打算进行连接时,搜索设备会以极快的速度进行跳频,被搜索设备会以极低的速度跳频,这样两个设备一定会同时跳跃到同一频段(79个频段中的一个)。

随后,搜索设备和被搜设备进行连接,并会将连接信道按照跳频图(由发起连接的设备)进行有规律的变化。当中,发起连接的一方被称为Master,接受连接的一方称为Slave此外,在建立连接后,双方根据已建立逻辑、基于 BR/EDR controller的l2cap 可以沟通各自是否具备可以使用的Altemate的AMP Controllers,具备的话则会判定是否将传输的data,转移到这些Controllers(极大提供蓝牙传输效率)。

对于低功耗蓝牙来讲,同样存在两方,称为Adversting的一方,发 送adversting packets(广播包),接收的一方称为Scanner,当Scanner接受到 “connectable advertisingpacket” 回应 “connection request”  建立起点对点链接(Initiators),Initiators发起连接即为Master ,Scanner为Slave。频道的选择则是在有Master生成的Hopping Pattern决定。

了解了握手的过程,接下来简单看下协议结构

从车联网安全到BLE安全

Physical Layer:

40个物理信道与RF特性的定义

Link Layer:

在这些Physical Channel上收发数据

解 决Physical Channel的共享:对时延不是很敏感的场景→在3个逻辑传输广播通道上进行传输;对时延较敏感的场景,37个Physical Channel中,选取一个,为这种场景里面的通信双方建立单独的通道(datachannel),这就是连接(connection)的过程,再结合跳频技术

因为是通过LinkLayer进行数据收发,过程中存在五种状态:Standby,Advertising,Scanning,Initiating,Connection

当建立连接后:Initiater方称作Mater,Advertiser方称作Slave

L2CAP Protocol

在 用户类XXX-U Logical Link的基础上,抽象出和具体技术无关的数据传输通道(包括单播和广播两类),L2CAP channel endpoints的概念(类似TCP/IP中的端口),为具体的应用程序(profile)提供独立的数据传输通道。在构建了点对点的逻辑通道,将这个 LogicalChannel换为L2CAP Channel,实现逻辑信道复用和长数据的分片传输

ATT(Attribute Protocol )

是一套允许Client和Server(传感器节点)通过属性的形式共享信息的机制,由Attribute Type、Attribute Handle(唯一识别Attribute server上的所有Attribute)和Attribute Value组成。定义一些权限:访问有关的权限 ,加密有关的权限,认证有关的权限,授权有关的权限。

GAP(Generic Attribute Profile)

简单理解为,应用场景,功能,使用方式都被规定好的应用

定义GAP层的蓝牙设备角色,定义GAP层的、用于实现各种通信的操作模式(Operational Mode)和过程(Procedures),定义User Interface有关的蓝牙参数。

信道复用实现:

通信之前,先建立一个基于Logical Channel的虚拟通道,L2CAP会为这个通道分配一个编号(CID),数据发送时,将用户数据分割为一定长度的数据包(L2CAP PacketData Units,PDUs),加上一个包含特定“ID”的header后,通过逻辑链路发送出去。数据接收时,从逻辑链路接收数据,解析其中的“ID”,并以此判断需要将数据转发给哪个应用

关于安全的 SMP(SecurityManagerProtocol)

SMP即安全管理协议,为BLE设备提供建立加密连接需要的key(STK or LTK)

SMP 位于L2CAP 与 GAP之间 为消息传递进行了安全加密。将生成加密key的过程称为Pairing(配对),并详细定义了Pairing的概念、操作步骤、实现细节等。定义一个密码 工具箱(CryptographicToolbox),其中包含了配对、加密等过程中所需的各种加密算法。定义一个协议(SecurityManager Protocol,简称SMP),基于L2CAP连接,实现master和slave之间的配对、密码传输等操作。

BLE整体的配对->加密->传输的过程如下图

从车联网安全到BLE安全

配对->权鉴->获取密钥->加密过程:

第一阶段:

Pairing Feature Exchange :配对的发起者(Initiator,总是Master)和配对的回应者(Responder,总是Slave)可以交换足够的信息,以决定在阶段2使用哪种配对方法、哪种鉴权方式、等等

配对方法:LE legacy pairing 和 LE Secure Connections(新方法优先支持)

配对码:

1)用户在两个设备上输入相同的6个数字(要求两个设备都有数字输入的能力),接下来的配对过程会进行相应的校验;

2)一个设备(A)随机生成并显示6个数字(要求该设备有显示能力),用户记下这个数字,并在另一个设备(B)上输入。设备B在输入的同时,会通过SMP协议将输入的数字同步的传输给设备A,设备A会校验数字是否正确,以达到鉴权的目的

3)Numeric Comparison,两个设备自行协商生成6个数字,并显示出来(要求两个设备具有显示能力),用户比较后进行确认(一致,或者不一致,要求设备有简单的yes or no的确认能力)

4)Just Work,不需要用户参与,两个设备自行协商

5)不需要权鉴

权鉴方法:OOB(out of band)protocol额外信息交互;

权鉴原则:

1)如果双方都支持OOB鉴权,则选择该方式(优先级最高)。

2)否则,如果双方都支持MITM鉴权,则根据双方的IO Capabilities(并结合具体的配对方法),选择合适的鉴权方式

3)否则,使用Just work的方式(不再鉴权)

第二阶段:

LE legacy pairing配对:最终生成STK用户建立加密连接,建立加密连接后再自行生成LTKS,通过Transport Specific Key Distribution共享双方生成EDIV和Rand用于索引LTK

STK=SHA1(MRand+SRand+TK(可以为配对码或OOB))

LE Secure Connections配对:直接生成LTK(利用了椭圆曲线加密算法(P-256 elliptic curve))

隐私信息由以下几个部分组成:

Encryption Information (Long Term Key)
Master Identification (EDIV, Rand)
Identity Information (Identity Resolving Key)
Identity Address Information (AddrType, BD_ADDR)
Signing Information (Signature Key) 

0×02 BLE安全实战测试

1.LE legacy pairing

如图(XX手环二旧版):

1).master告知slave要求设置LTK IRK CSRK三类密钥,同时master支撑MITM(需要人参与的权鉴),OOB权鉴方式无额外数据,IO通过keyboard进行输入

*注

LTK:长期密钥

IRK:身份解析密钥   当私有地址周期性变化时可通过IRK并依据list对周期性变化的地址向MAC地址映射(BLE地址随机性)

CSRK:连接签名解析密钥  连接使用数据签名来保护连接(其提供了完整性和认证)

从车联网安全到BLE安全

2)slave告知master自己支持 LTK和CSRK,不支持MITM(需要人参与的权鉴)和IRK,OOB权鉴方式无额外数据,IO无输入

从车联网安全到BLE安全

3)所以权检的方式应该为JUSTWORK(不进行权鉴直接进行通信)后直接进行pairing confirm的value值的确认 

4)根据请求内容可知使用的配对方式是—LE legacy pairing(32位LTK=STK=S1(MRand,SRand))

从车联网安全到BLE安全

5) 传递 Encryption Information (LongTerm Key) ,Master Identification (EDIV, Rand) ,Identity Information (Identity Resolving Key) ,Identity Address Information (AddrType, BD_ADDR) ,Signing Information (Signature Key)  进行LTK的生成(128位)

**注:

master和slave都要生成各自的LTK/EDIV/Rand组合,并共享给对方。因为加密链路的发起者需要知道对方的LTK/EDIV/Rand组合,而Master或者Slave都有可能重新发起连接

为什么LE legacy pairing的LTK需要EDIV/Rand信息呢?因为LTK是各自生成的,不一样,因而需要一个索引去查找某一个LTK(LE Secure Connections,LTK是直接在配对是生成的,因而就不需要这两个东西)。

从车联网安全到BLE安全

6)在此之后对数据进行了加密(因为数据已经加密,未获取到LTK(被STK加密)同时Wireshark无解密功能,故此处数据解密失败失败)

从车联网安全到BLE安全

2.LE Secure Connections 权鉴、配对、加密的过程

如图(XX手环二新版):

从车联网安全到BLE安全

3.未进行配对加密过程

如图(XXOBD智存版)

整体建连到数据传输过程中未见LTK参与,未见数据加密

1)首次和OBD设备建即进入仪表盘,App向OBD请求诊断数据。图中:ATAUTORUN0

从车联网安全到BLE安全

2)OBD发送App诊断结果可见

从车联网安全到BLE安全

是不是很有趣呢,OBD诊断的命令和诊断结果都没有进行加密,一旦通过劫持的手段注入恶意的数据,就像前一篇片文章一样,CAN命令注入。

0×03 BLE安全另类测试

讲一个实际项目中的案例,根据对BLE整个的安全性分析过程,将安全测试的重点放在,蓝牙地址随机性,安全协商,SMP和CSRK(连接签名解析密钥)的正确使用以及LTK的使用几个方面

这个奇怪的东东,根据APP端发送的信号,调节震动频率以及震动的时长

从车联网安全到BLE安全

这里仅看下传输的数据

在配对的过程中的协议,并未发现使用SMP,所以BLE模块和APP之间并不会进行安全的权鉴

从车联网安全到BLE安全同样,没有SMP就不会使用LE legacy pairing 和 LE Secure Connections 

从车联网安全到BLE安全

在APP下发命令:

选择震动类型时使用时,handle使用的是4c,value值从0-7

从车联网安全到BLE安全

增加震动等级,handle使用的是4e,value的值为02xx-10xx

例如,使用4级震动value为04xx

从车联网安全到BLE安全

启动震动,handle使用的是4e,value值为xx01

从车联网安全到BLE安全

停止震动时,handle使用的是4e,value值为xx00

从车联网安全到BLE安全

所以~~~,根据规则 伪造数据,就可以远程恶意控制该硬件了

0X04 安全展望

随着IOT融入到我们的生活当中,智能设备的功能性和信息化循序增强,我们必须在危险真正到来之前未雨绸缪,给原本就脆弱的IOT增加安全的保证,不仅保证信息安全,更是保证生命安全。

* 本文作者:麦片与老干妈,本文属FreeBuf原创奖励计划,未经许可禁止转载

更多精彩
相关推荐
发表评论

已有 1 条评论

取消
Loading...
麦片与老干妈

这家伙太懒,还未填写个人描述!

3 文章数 22 评论数 0 关注者

特别推荐

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php