蓝牙BLE学习-安全

1.基本概念

蓝牙标准规定了5种基本的安全服务

  1. 身份验证:根据通信设备的蓝牙地址验证其身份。蓝牙不提供本地用户身份验证。
  2. 保密性:确保只有授权的设备才能访问和查看传输的数据,防止窃听造成的信息泄露。
  3. 授权(Authorization):在允许设备使用某项服务之前,确保该设备已被授权,从而实现对资源的控制。
  4. 消息完整性:验证在两个蓝牙设备之间发送的消息在传输过程中没有被更改。
  5. 配对/绑定:创建一个或多个共享密钥,并存储这些密钥用于后续连接,以形成可信设备对。

蓝牙不解决其审计和不可否认安全服务;如果需要这种服务,应通过其他途径提供。

Paring (配对)

配对包括配对能力交换,设备认证,密钥生成,连接加密以及机密信息分发等过程,配对的目的有三个:加密连接,认证设备,以及生成密钥。从手机角度看,一旦设备跟手机配对成功,蓝牙配置菜单将包含该配对设备,如下所示:

如果用户需要主动删除配对设备,点击配对设备右边的"设置"菜单,出现如下界面,选择"取消配对"或者"忽略该设备",设备的配对信息即被手机删除。

Bonding (绑定)

配对过程中会生成一个长期密钥(LTK,long-term Key),如果配对双方把这个LTK存储起来放在Flash中,那么这两个设备再次重连的时候,就可以跳过配对流程,而直接使用LTK对蓝牙连接进行加密,设备的这种状态称为bonding。

如果paring过程中不存储LTK(不分发LTK)也是可以的,paring完成后连接也是加密的,但是如果两个设备再次重连,那么就需要重走一次paring流程,否则两者还是明文通信。

在不引起误解的情况下,我们经常把paring当成paring和bonding两者的组合,因为只paring不bonding的应用情况非常少见。在不引起混淆的情况下,下文就不区分paring和bonding的区别,换句话说,我们会把paring和bonding两个概念等同起来进行混用。

SM (security manager)

蓝牙协议栈的安全管理层,规定了跟蓝牙安全通信有关的所有要素,包括paring,bonding,以及下文提到的SMP。

SMP (security manager protocol)

安全管理协议,SMP着重两个设备之间的蓝牙交互命令序列,对paring的空中包进行了严格时序规定。

OOB (out of band,带外)

OOB就是不通过蓝牙射频本身来交互,而是通过比如人眼,NFC,UART等带外方式来交互配对信息,在这里人眼,NFC,UART通信方式就被称为OOB通信方式。

Passkey

又称pin码,是指用户在键盘中输入的一串数字,以达到认证设备的目的。低功耗蓝牙的passkey必须为6位。

Numeric comparison (数字比较)

Numeric comparison其实跟passkey一样,也是用来认证设备的,只不过passkey是通过键盘输入的,而numeric comparison是显示在显示器上的,numeric comparison也必须是6位的数字。

MITM (man in the middle)

MITM是指A和B通信过程中,C会插入进来以模拟A或者B,并且具备截获和篡改A和B之间所有通信报文的能力,从而达到让A或者B信任它,以至于错把C当成B或者A来通信。

如果对安全要求比较高,需要具备MITM保护能力,在SM中这个是通过认证(authentication)来实现的,SM中实现认证的方式有三种:OOB认证信息,passkey以及numeric comparison,大家根据自己的实际情况,选择其中一种即可。

LESC (LE secure connections)

又称SC,蓝牙4.2引入的一种新的密钥生成方式和验证方式,SC通过基于椭圆曲线的Diffie-Hellman密钥交换算法来生成设备A和B的共享密钥,此密钥生成过程中需要用到公私钥对,以及其他的密码算法库。

LESC同时还规定了相应的通信协议以生成该密钥,并验证该密钥。需要注意的是LESC对paring的其他方面也会产生一定的影响,所以我们经常会把LESC看成是一种新的配对方式。

Legacy paring

在LESC引入之前的密钥生成方式,称为legacy paring,换句话说,legacy paring是相对LESC来说的,不支持LESC的配对即为legacy paring(legacy配对)。

TK (Temporary Key,临时密钥)

legacy paring里面的概念,如果采用just work配对方式,TK就是为全0;如果采用passkey配对方式,TK就是passkey;如果采用OOB配对方式,TK就是OOB里面的信息。

STK (short term key,短期密钥)

legacy配对里面的概念,STK是通过TK推导出来的,通过TK对设备A和B的随机数进行加密,即得到STK。

LTK (long term key,长期密钥)

legacy配对和LESC配对都会用到LTK,如前所述,LTK是用来对未来的连接进行加密和解密用的。Legacy paring中的LTK由从设备根据相应的算法自己生成的(LTK生成过程中会用到EDIV(分散因子)和Rand(随机数)),然后通过蓝牙空中包传给主机。

LESC配对过程中,先通过Diffie-Hellman生成一个共享密钥,然后这个共享密钥再对设备A和B的蓝牙地址和随机数进行加密,从而得到LTK,LTK由设备A和B各自同时生成,因此LTK不会出现在LESC蓝牙空中包中,大大提高了蓝牙通信的安全性。

IRK (Identity Resolving Key,蓝牙设备地址解析密钥)

有些蓝牙设备的地址为可解析的随机地址,比如iPhone手机,由于他们的地址随着时间会变化,那如何确定这些变化的地址都来自同一个设备呢?

答案就是IRK,IRK通过解析变化的地址的规律,从而确定这些地址是否来自同一个设备,换句话说,IRK可以用来识别蓝牙设备身份,因此其也称为Identity information。IRK一般由设备出厂的时候按照一定要求自动生成。

Identity Address (设备唯一地址)

蓝牙设备地址包括public,random static, private resolvable,random unresolved共四类。

如果设备不支持privacy,那么identity address就等于public或者random static设备地址。

如果设备支持privacy,即使用private resolvable蓝牙设备地址,在这种情况下,虽然其地址每隔一段时间会变化一次,但是identity address仍然保持不变,其取值还是等于内在的public或者random static设备地址。

Identity Address和IRK都可以用来唯一标识一个蓝牙设备。

IO capabilities (输入输出能力)

是指蓝牙设备的输入输出能力,比如是否有键盘,是否有显示器,是否可以输入Yes/No两个确认值。

Key size (密钥长度)

一般来说,密钥默认长度为16字节,为了适应一些低端的蓝牙设备处理能力,你也可以把密钥长度调低,比如变为10个字节。

2. 配对与绑定

Paring(配对)和Bonding(绑定)是实现蓝牙射频通信安全的一种机制,有两点需要注意:

Paring/bonding实现的是蓝牙链路层的安全,对应用层来说是完全透明的。也就是说,不管有没有paring/bonding,应用层数据的收发方式都是一样的,不会因为加了paring/bonding而使应用层数据传输需要做某些特殊处理。

安全有两种选项:加密或签名。目前绝大部分应用都是选择加密

实现蓝牙通信安全,除了paring/bonding这种底层方式,用户也可以自己在应用层去实现相同的安全功能。从功能上来说是没有太大区别的,不同的是应用层安全自己实现的话,需要自己选择加密算法、密钥生成、密钥交换等。如果不是这方面的专家,很有可能会有安全漏洞。而蓝牙的paring/bonding则把上述过程标准化,放在了蓝牙协议栈里。并且其安全性得到了充分的评估,用户可以"无感"使用安全的蓝牙通信。

paring/bonding是蓝牙sercurity manager(SM)的一部分,SM定义了蓝牙通信的安全架构,里面涉及安全架构、密码工具箱、paring协议等。其中paring协议是关键,所以经常把paring和SM二者等价。

2.1 配对

蓝牙的配对过程主要是为了生成双方蓝牙设备所共享的秘钥,即链接秘钥LK(Link Key),这个LK可能是暂时性秘钥(temporary)或半永久秘钥(semi-permanent)。暂时性秘钥表示每一次会话(session)该秘钥都会改变,主要用于一对多的场景中;半永久秘钥表示在当前会话终止时,该秘钥会保存在非易失性存储中(Non-Volatile Memory,NVM),以便下一次相同双方设备间的会话使用该秘钥,即会被用于下一次连接时的设备认证以及消息的加密过程。

配对是找到并确定需要和自己通信的设备,也就是身份确定。接着是安全密钥共享,而这一过程仅仅是由启动加密到得到短期密钥(STK)为止。其包括配对能力交换、设备认证、密钥(固定128bit)生成、连接加密以及机密信息分布等过程。配对的目的有三个:加密连接、认证设备、生成密钥。

区别于传统蓝牙的配对过程,BLE的配对过程发生在连接过程之后。

和经典蓝牙一样,协议为处于连接状态的BLE设备,定义了两种Link Layer角色:Master和Slave。Master是连接的发起方,可以决定和连接有关的参数。Slave是连接的接收方,可以请求连接参数,但无法决定。

在SM(Security Manager)的规范中,配对时指"Master和Slave通过协商确立用于加(解)密的Key的过程",主要由三个阶段组成:

配对是一个三阶段的过程。前两个阶段时必须的,第三阶段时可选的。

第一阶段:配对特征交换。称作"Pairing Feature Exchange",用于交换双方有关鉴权的需求(authentication requirements),以及双方具有怎样的人机交互能力(IO Capabilities)。

第二阶段:短期密钥(STK)生成。通过SMP协议进行实际的配对操作,根据阶段一"Feature Exchange"的结果,有两种配对方法可选:LE legacy pairing和LE Secure Connections

第三阶段:传输特定密钥分配。该阶段时可选的,经过阶段一和阶段二之后,双方已经产生了加密key。因此可以建立加密的连接。加密连接建立后,可以互传一些私密的信息,例如Encryption Information、Identity Information、Identity Address Information等。

注:STK的生成规则如下:

Just work:没有加密,TK=0x00。Just works方式不能抵抗窃听者和中间人攻击,只有在配对过程时没有遭受攻击,后面加密的链路数据才是可信的。安全级别很低。

passkey entry:密码输入。如果passkey是"019655" ,TK的值就是0x00000000000000000000000000004CC7。(0x4cc7就是19655的16进制数)。将输入的值作为一个6位数的十进制,转换为15字节的十六进制。

OOB(Out of band):带外的TK值,是一个16字节的随机数,通过非BLE的方式传递给对端。例如二维码或IR红外。对于蓝牙窃听者/攻击者而言,这个data的传输是不可见的,因此会显得安全很多。

配对请求的数据格式

IO capabilities表明输入,输出的能力。

输入是按键、键盘,输出是显示数字用的界面。

0x00(Display Only)只能 显示000000~999999的数字

0x01(Display YesNo)显示Yes/No的按钮

0x02(Keyboard Only)只能输入000000~999999的数字

0x03(No input No output)没有输入也没有显示,只能用Just work工作方式

0x04(Keyboard Display)能输入000000~999999的数字,也能有屏幕显示。

OOB data flag

0x00 OOB数据没有发送

0x01 OOB数据通过远端设备发送(如IR)

0x02-0xFF 保留

2.2 绑定

绑定就是把已配对设备的秘钥等信息进行保存的过程,以便与对端蓝牙设备断开连接后,下一次连接时能够使用该秘钥等信息进行快速验证和加解密消息,提高效率。在Android中,绑定实质上就是保存已授权连接的蓝牙设备的信息(包括LK),并把该设备加入到自己的已配对列表中。

配对过程中会生成一个长期密钥(LTK,long-term key),如果配对双方把这个LTK存储起来放在Flash中(有的时候是长期密钥、身份解析密钥、连接签名解析密钥这三个秘密要的某一个或组合进行交换,然后将交换的密钥存储到数据库中),那么这两个设备再次重连的时候,就可以跳过配对流程,而直接使用LTK对蓝牙连接进行加密,设备的这种状态称为绑定(bonding)。

这里要明确一个概念,配对绑定只有在两个设备之间第一次配对时才会发生,后续的连接由于第一次的配对绑定已经有"Bonding"过程(即存储),如果存储的数据库没有被认为的清空,后续的连接不需要再次配对。并不是所有的通信都需要加密进行数据保护,因此,建立连接之前不一定需要配对和绑定,可以直接建立连接。

2.3 总结

BLE的配对和绑定是一连串的动作,总结下来可以用下图来表示。

阶段1:配对特征交换,得到临时密钥(TK)值(配对请求、配对响应)

阶段2:身份确认以及短期密钥(STK)生成(通过安全管理协议(SMP)配对),确定自己正在和一个真正想要通信的设备通信,而非第三方。即确定对方身份。

阶段3:传输特定密钥(密钥分配)。绑定所需存储到安全数据库的数据也是在此阶段发送的。

上述三阶段总结:

配对认证:主从机一方提供密码,一方输入密码,如果双方密码一致,那么此密码将作为TK(临时密码)。

加密链路:利用得到的TK(临时密码)等信息计算出STK(短期密码)用来做加密认证

绑定:加密认证通过后,利用STK等信息生成LTK(长期密码),把LTK保存下来,用于下次连接时做加密认证,不需要再次配对就可以加密链路。这就是绑定。

绑定后通讯过程:每次连接时,从机会向主机发送安全请求。如果主从机相互绑定过,主机不会发送配对请求,主机直接利用绑定时保存的LTK发送加密请求。从机也会利用绑定时保存的LTK来做加密回复,三次握手成功后(加密成功,三次握手通讯由底层完成,用户不可见),从机回复主机加密状态success。

建立连接是使用的静态密码,解除绑定/配对是使用的动态密码。回连也需要密码,使用的是动态密码,这是为了防止窃听,起保护作用。为了防止泄露信息,用户也可以自行在应用层去实现相同的功能。

配对和绑定的区别:

1.连接:通讯的基础,通讯数据为明文

2.配对:配对仅仅是为了在连接的基础上加密(通讯数据经过加密为密文)。提高蓝牙链路传输的安全性。不配对也能连接进行通信。

3.绑定:绑定是配对发起时的一个可选配置。把配对信息记录下来,下次不用配对自动进入加密的连接。所以没有在bonding列表里的设备不影响连接。

在不引起误解的情况下,经常把paring当成paring和bonding两者的组合,因为只paring不bonding的应用情况非常少见。

3.Bluetooth BR/EDR/HS安全特性

蓝牙BR/EDR/HS定义了可以在对等设备之间通信建立的不同阶段实施的认证和加密安全过程。链路层安全机制在蓝牙物理链路完全建立之前进行的身份验证和加密设置过程。服务层安全机制在蓝牙物理链路完全建立和逻辑通道部分建立之后发生的身份验证和加密设置过程。

在蓝牙2.0之前,定义了三种模式,分别指定身份验证和加密是链路层安全机制还是服务层安全机制,并且是可配置的。

在蓝牙2.1中增加了第四种模式,重新定义了配对时的用户体验,要求如果两个设备都是蓝牙2.1及以上,则需要使用第四种模式。

蓝牙BR/EDR/HS系列规范共定义了四种安全模式。每个蓝牙设备必须在其中一种模式下工作,即安全模式1到安全模式4。这些模式决定蓝牙设备何时启动安全性,而不是它是否支持安全特性。

安全模式1设备被认为是不安全的。安全功能(身份验证和加密)从未启动,设备和连接容易受到攻击者的攻击。这种模式下的蓝牙设备不会采用任何机制来阻止其他蓝牙设备建立连接。但是,如果远程设备发起安全请求,例如配对、身份验证或加密请求,则安全模式1设备将参与。根据各自的蓝牙规范版本,所有2.0及更早版本的设备都可以支持安全模式1,而2.1及更高版本的设备可以使用安全模式1来向后兼容旧设备。 NIST建议永远不要使用安全模式1。

安全模式2是一种服务层的安全模式,安全过程可以在连接之后,但在逻辑通道建立之前发起。对于这种安全模式,本地安全管理器(蓝牙架构中规范的)对特定服务的访问控制。集中安全管理器维护访问控制策略以及与其他协议和设备用户的接口。可以为并行操作的具有不同安全需求的应用程序定义不同的安全策略和信任级别来限制访问。可以授予对某些服务的访问权而不提供对其他服务的访问权。在这种模式下,引入了授权的概念,即决定是否允许特定设备访问特定服务的过程。通常,蓝牙服务发现可以在任何安全挑战(即身份验证、加密和/或授权)之前执行。然而,所有其他的蓝牙服务应该都需要这些安全机制。

注意:安全模式2的身份验证和加密机制是在控制器中实现的,所有早于蓝牙2.0版本的设备支持安全模式2,如果2.1及之后的版本和2.0及之前的版本只能通过安全模式2进行兼容。

安全模式3是连接层安全模式,在物理链接完全建立之前启动。应用安全模式3的蓝牙设备对与之所有的设备连接进行授权和加密。因此,在服务发现之前,就进行了身份认证、加密和授权。一旦设备具备安全模式3的认证,服务层的认证一般不再执行。NIST建议即使使用安全模式3,服务级授权也应使用,以防止"身份验证滥用"。

安全模式4和安全模式2类似,安全模式4(在蓝牙2.1+EDR中引入)是一种服务层安全模式,在物理和逻辑链接建立之后启动。安全模式4使用安全简单配对(SSP, Secure Simple Pairing),其中链接密钥的生成通过ECDH协议产生。在蓝牙4.0之前,P-192椭圆曲线算法用于链接密钥生成,设备认证和加密算法与蓝牙2.0+EDR和早期版本中的算法相同。蓝牙4.1引入安全连接特性,使用P-256椭圆曲线算法生成连接密钥。在蓝牙4.1中设备认证算法升级到FIPS批准的消息认证码(Hash Message Authentication Code Secure Hash Algorithm 256-bit,HMAC-SHA-256)。加密算法升级到FIPS批准的基于AES-CCM模式的CBC-MAC,提供消息完整性保护。安全模式4保护的服务安全需求分为以下几项:

• Level 4: Authenticated link key using Secure Connections required

• Level 3: Authenticated link key required

• Level 2: Unauthenticated link key required

• Level 1: No security required

• Level 0: No security required. (Only allowed for SDP)

是否需要连接密钥取决于SSP关联模型。当本地和远程设备都支持安全连接特性时,连接密钥是通过安全连接生成的,这也是NIST推荐的。安全模式4需要对所有服务进行加密(除服务发现之外),并强制用于蓝牙2.1和以后的BR/EDR设备之间通信。为了向后兼容,安全模式4可以与蓝牙2.0和不支持安全模式4的设备通过其他三种安全模式进行通信。

BR/EDR/HS Security Mode 4 Levels Summary

Most Secure Mode for a Pair of Bluetooth Devices

Most Secure Level in Mode 4 for a Pair of Bluetooth Devices

**4.**配对和连接密钥生成

蓝牙的认证和加密是通过对称密钥进行的。经典蓝牙BR/EDR是Link key, BLE低功耗蓝牙是LTK(Long Term Key)。传统低功耗蓝牙先生成STK(Short Term Key),使用STK加密连接后再分发LTK给对端设备, 在低功耗安全连接模式下LTK是各个设备生成,不需要分发。经典蓝牙有2种配对方式:Security Modes 2 and 3使用PIN码进行配对,Security Modes 4使用SSP(Secure Simple Pairing)。在蓝牙4.0和4.1中配对时可以认证也可以不认证,蓝牙4.2中,在配对时使用安全连接验证设备。

对于配对(LK秘钥的生成)、设备认证以及加密这三个过程所使用的安全算法和流程由于历史的原因主要分为了三类,即三个安全机制:Legacy、SSP(Secure Simple Pairing)以及SC(Secure Connections)如下表所示。现在许多的蓝牙设备由于兼容性考虑,同时具有这三个安全机制。

Master和Slave有两种可选的配对方法:legacy pairing和Secure Connections。选择的依据是:当Master和Slave都支持Secure Connections(新方法)的时候,则使用Secure Connections。否则使用legacy pairing。

4.1 PIN/Legacy Pairing

对于PIN/传统配对,当用户在一个或两个设备上输入完全相同的机密的PIN码时,根据配置和设备类型,两个蓝牙设备同时获得链接密钥。下图从概念上描述了PIN码输入和密钥获得过程。注意,如果PIN码小于16字节,会用发起设备的地址(BD_ADDR)来补足PIN值以生成初始密钥。那些Ex框代表了蓝牙链接密钥获得过程所使用的加密算法。

从图中可以看到,初始化秘钥Kinit是由PIN和一个共同的随机数通过E22算法所生成的,E22算法基于SAFER+,在协议规格说明书中有详细说明[4, 980],这里不再对这些算法进一步介绍,只对其的输入和输出进行关注。其输入的PIN可以是设备提供的固定值,也可以是用户输入到这两个设备中。如果设备都是可输入设备,则规格说明书更建议使用后者[4, p955]。PIN的大小为1到16字节,若是其小于16字节,则需要加入发起连接设备的MAC地址(BD_ADDR)来共同生成初始化秘钥Kinit。Kinit然后会经过一系列的算法最终生成链接秘钥Klink。然后Klink会被用于通信设备的认证

蓝牙配对中使用的PIN码可以是1到16个字节的二进制数或更常见的字母数字字符。对于低风险应用场景,典型的4位数PIN码可能是足够的;对于要求更高安全级别的设备,应当使用更长的PIN码(例如, 8个字符的字母数字)

完成链接密钥生成后,设备通过互相认证彼此来完成配对,以验证他们拥有相同的链接密钥Link key,即Klink是否一致,其包含有两个角色:申验者(Claimant)和验证者(Verifier),当然,一般来讲,它们也可以叫作外设(Peripheral)和中心(Central)。整个设备验证过程分为5个步骤[5]:

1)验证者向申验者发送128位随机数(AU_RAND)。

2)申验者使用E1算法并使用48位自己的蓝牙设备地址(BD_ADDR)、链接秘钥Link Key和AU_RAND作为输入来进行计算。验证者执行相同的计算。其计算获得的结果一共有128位数据,其中使用32位最高有效位(即SRES)用于认证,其余的96位称为ACO值,稍后加入到蓝牙会话加密密钥Kc的创建。

3)申验者将签名响应SRES返回给验证者。

4)验证者将申验者的SRES与其计算的值进行比较。

5)如果两个32位值相等,认证被认为是成功的。如果两个32位值不相等,认证失败。

设备成功验证后,就进入加密秘钥的生成以及消息的加密流程了,如下图所示

首先,Master方(或者叫Central)会生成一个128位的随机数EN_RAND发送给Slave方(或者叫Peripheral),它们两者利用该EN_RAND以及链接秘钥Link Key、COF来通过算法E3来计算获得加密秘钥Kc。这里的COF实质上就是前面的设备认证阶段生成的ACO,在协议规格说明书上COF的由来如下所示:

当然,这里的Kc为16字节,但是由于兼容性和功耗的考虑,蓝牙联盟最开始规定的加密秘钥长度可以是从1字节到16字节的,只要设备双方共同协商好。但由于之前的KNOB漏洞[4],其规定最低的加密秘钥长度改为了7,也就是说加密秘钥的长度,设备双方可以协商的最小长度为7。这个协商加密秘钥长度的过程就是图中的Constraining Mechanism,其根据协商的长度,从而去取Kc的前几字节的字段来获得最终的加密秘钥。最后使用该加密秘钥通过E0算法来加解密明文数据包。

4.2 Secure Simple Pairing(SSP)

Secure Simple Pairing(SSP)通过提供一些关联模型来简化配对过程。这些模型具有适应不同设备输入/输出能力的灵活性。SSP也通过增加ECDH公钥加密来改进安全性,以防止配对过程中的被动窃听和中间人(MITM)攻击。

SSP提供了如下四种关联模型:

Numeric Comparison : 数值比较是针对两种蓝牙设备都能显示六位数字并允许用户输入"是"或"否"回答的情况而设计的。在配对过程中,用户会在每台显示器上看到一个六位数的数字,如果数字匹配,则在每台设备上回答"是"。否则用户回答no,配对失败。这与传统配对中使用PIN的一个关键区别是,显示的数据不用作生成链接密钥的输入。因此,能够看到(或捕获)显示值的窃听者无法利用它来确定最终链路或加密密钥。

Passkey Entry:Passkey Entry设计用于一个蓝牙设备有输入能力(例如键盘),而另一个设备有显示但没有输入能力的情况。在这种模型中,只有显示屏的设备显示一个6位数的数字,然后用户在具有输入能力的设备上输入该数字。与数值比较模型一样,该交易中使用的6位数字没有包含在链路密钥生成中,对窃听者没有任何用处。

Just Works **:**是为至少一个配对设备既没有显示器也没有键盘输入数字(例如,耳机)的情况而设计的。它执行认证阶段1的方式与Numeric Comparison相同,只是没有显示。用户需要在不验证两个设备上计算出的值的情况下连接,因此Just Works不提供中间人攻击保护。

**Out of Band (OOB) :**为支持常见的额外的无线(例如,近场通信(NFC))或有线技术设备设计的,用于设备发现和密码交换。在NFC的情况下,OOB模型允许设备通过简单地"点击"一个设备与另一个设备进行配对,然后用户通过一个按钮接受配对。值得注意的是,为了使配对过程尽可能安全,OOB技术应该被设计和配置为减轻窃听和中间人攻击。

安全模式4要求蓝牙服务使用安全连接(第4级)、已验证链接密钥(第3级)、未验证链接密钥(第2级)或完全不安全(第1级)指定一个已验证链接密钥。在上述的关联模型中,除了Just Works模型之外,所有模型都提供已验证链接密钥。

下图是中描述的SSP的链接密钥Link Key的生成,值得注意的是这里使用的是ECDH公私钥对来进行生成的,而不是LSC那种使用PIN生成的对称密钥。图中的P-192和P-256为两种椭圆曲线算法,SC用的后者,SSP用的前者。其通过KDH最终生成了链接密钥Klink。

每个设备都会生成自己的ECDH公私密钥对。当两个设备都支持安全连接时,使用P-256椭圆曲线,否则使用P-192椭圆曲线。每台设备将公钥发送给另一台设备。然后,设备执行依赖于关联模型的第1阶段认证。在此之后,第一个设备计算确认值E1并将其发送给第二个设备,后者检查该值。如果成功,第二台设备将其确认值E2发送给第一台设备。假设E2确认值正确,两个设备都会计算出链接密钥。

设备验证阶段如下图所示,值得注意的是其与LSC(Legacy Secure Connections)不一样的地方在于,SSP的设备双方都是申验者和验证者,即通信的设备既会验证对方的Link Key,也会被对方验证本方的Link Key,只要有一方验证失败,则这整个阶段都验证失败。而LSC只有一方(Central)是验证者。

接下来的加密密钥的生成以及加密算法如下图所示,可以看到其大致与LSC一致,不过采用的算法完全不一样,这里采用h3来生成加密密钥,使用AES-CCM来加密数据包。

4.3 SSP 配对过程

Simple Pairing配对过程如图所示,主要由下面四部分完成:

4.3.1 Pairing Feature Exchange

用于交换双方有关鉴权的需求(authentication requirements),以及双方具有怎么

的人机交互能力(IO capabilities)。其中最重要的是IO capabilities exchange。

IO的能力可以归纳为如下的六种:

  1. NoInputNoOutput
  2. DisplayOnly
  3. NoInputNoOutput1
  4. DisplayYesNo
  5. KeyboardOnly
  6. KeyboardDisplay
    上述的IO能力决定了后续的鉴权方式。

4.3.2 Public key exchange

两个设备之间交换Public key。 一旦设备收到对端设备的公钥,它就可以开始计算Diffie Hellman Key(DHKey)。耗时较多,应该尽早开始,以便用户交互可以隐藏计算时间。 在步骤8之前不需要DHKey。
当 Public key的长度大于DM1包的长度时,要使用专门的PDU来进行数据发送。

4.3.3 Authentication

LESC paring会做两次认证。LESC第一阶段认证的原理是,设备A和B各生成一个随机数,然后认证这个随机数对不对。LESC第二阶段认证过程是:设备A和B通过MacKey各生成一个检查值,对方确认这个值对不对。通过SMP协议进行实际的配对操作,根据阶段1 "Feature Exchange"的结果,有三种

鉴权方法可选:

1) OOB鉴权

如果双方都支持OOB鉴权,则选择该方式(优先级最高)。由配对的双方,在配对过程

之外,额外的交互一些信息(譬如NFC),并以这些信息为输入,进行后续的配对操作。

这些额外信息也称作OOB(out of band),OOB的交互过程称为OOB protocol。

2) MITM鉴权

(man-in-the-middle)authentication,由两种方法:

Numeric Comparision方式鉴权:两个设备自行协商生成6个数字,并显示出来(要求两个

设备具有显示能力),用户比较后进行确认(一致,或者不一致,要求设备有简单的yes

or no的确认能力)。

3)Passkey Entry方式鉴权:通过输入配对码的方式鉴权。

4)Just Work

不需要用户参与,两个设备自行协商。

以LESC Numeric comparison为例,其第一阶段认证流程如下所示:

4.3.4 DH Key Checks

DH Key Checks就是LESC的第二阶段认证,一旦设备完成鉴权过程,并且DHKey计算已完成,则检查生成的DHKey值。 如果成功,则两个设备都将完成向用户显示关于该过程的信息,否则控制器向主机发送消息以通知其停止显示该信息。

以LESC Numeric comparison为例,其第二阶段全工作流程如下所示:

当配对过程完成后,link key就可以从DHKey中计算得到,并用做后续交互过程的输入(KEY + 明文 => 加密数据),通过HCI_Link_Key_Notification来通知host。

经过上述配对过程后,双方已经产生了加密key,因而可以建立加密的连接。加密连接建立后,可以互相传送一些私密的信息,例如Encryption Information、Identity Information、Identity Address Information等。

相关推荐
2401_857617624 分钟前
“无缝购物体验”:跨平台网上购物商城的设计与实现
java·开发语言·前端·安全·架构·php
thesky1234564 分钟前
活着就好20241226
学习·算法
士别三日wyx40 分钟前
HW护网分析研判思路,流量告警分析技巧
安全·web安全·网络安全
远离UE41 小时前
UE5 渲染管线 学习笔记
笔记·学习·ue5
张声录11 小时前
【ETCD】【实操篇(十六)】基于角色的访问控制:ETCD 安全管理指南
数据库·安全·etcd
cwtlw2 小时前
CSS学习记录20
前端·css·笔记·学习
紫罗兰盛开2 小时前
分布式调度框架学习笔记
笔记·学习
上海文顺负载箱2 小时前
程控电阻箱应用中需要注意哪些安全事项?
安全
Kobebryant-Manba2 小时前
kafka基本概念
分布式·学习·kafka
纯净的灰〃3 小时前
vulnhub-matrix-breakout-2-morpheus
安全·web安全·网络安全