BLE蓝牙安全

韩乔落

前言

学习参考 https://www.nordicsemi.cn/,此外请先阅读博客种无线电安全专题的蓝牙安全部分。

常见攻击类型

身份跟踪:

利用蓝牙地址来跟踪设备。这可以通过使用随机变化的可解析私有地址(Resolvable Random Private Address)来避免,其中只有绑定/可信设备才能解析私有地址。IRK(身份解析密钥)用于生成和解析私有地址。

被动窃听(嗅探):

就是攻击者偷偷窃听设备之间的数据传输。可以通过加密对等设备之间的通信来防止这种情况。这里的挑战是对等设备如何生成和/或交换密钥以建立安全地加密连接。Bluetooth LE 传统配对的密码生成和交换存在不足,然后提出了LE secure Connections。

主动窃听(中间人MITM):

在主动窃听(或中间人)攻击中,攻击者冒充合法设备来欺骗另外两个设备,与他们建立连接。为了防止这种情况,我们需要确保我们正在通信的设备实际上是我们想要与之通信的设备,而不是未经身份验证的设备。可靠的身份验证过程可以有效的防止中间人攻击。

640

BLE 安全相关术语

  • 临时密钥 (Temporary Key,TK): 临时密钥的生成取决于所选的配对方法。每次配对过程发生时都会生成 TK(仅用于传统配对)。
  • 短期密钥 (Short Term Key,STK): 此密钥由设备之间交换的 TK 生成。每次配对过程发生时都会生成 STK,并用于加密当前连接中的数据(仅用于传统配对)。
  • 长期密钥 (LongTerm Key,LTK): 此密钥在传统配对的第三阶段和 LE 安全连接的第二阶段期间生成和存储,是一个 128 位密钥,用于生成session key。它存储在绑定的两个设备中的每一个上,并用于两个设备之间的后续加密连接。
  • 加密多样化(Encrypted Diversifier,EDIV)和 随机值(Random Number,Rand): 这两个值用于创建和识别 LTK。它们也会在绑定过程中储存起来。
  • 身份解析密钥 (ldentity Resolving Key,IRK): 用于生成和解析随机私有可解析地址(Resolvable Random Private Address)。该密钥对于每个设备都是唯一的,因此主设备的 IRK 将存储在从设备端,而从设备的IRK 将存储在主设备端。
  • 连接签名解析密钥(Connection Signature Resolving Key,CSRK): 如果启用,该密钥将存储在两个绑定设备中的每一个上,用于对数据进行签名并验证附加到另一端数据的签名(used in signing data sent over an unencrypted link )。
  • ECDH(Elliptic-curve Diffie–Hellman)椭圆曲线diffie-hellman密钥交换算法

可解析随机私有地址

可解析随机私有地址可以防止被未知设备扫描和追踪

图片

如图,由两部分组成:高位24bits是随机数部分,其中最高两个bit为”10”,用于标识地址类型;低位24bits是随机数和IRK经过hash运算得到的hash值,运算的公式为hash = ah(IRK, prand)。

当对端Bluetooth LE设备扫描到该类型的蓝牙地址后,会使用保存在本机的IRK,和该地址中的prand,进行同样的hash运算,并将运算结果和地址中的hash字段比较,相同的时候,才进行后续的操作。

这个过程称作resolve(解析),这也是Non-resolvable private address/Resolvable private address命名的由来。

以T_GAP(private_addr_int)为周期,定时更新。哪怕在广播、扫描、已连接等过程中,也可能改变。

Bluetooth LE安全等级

Bluetooth LE 在安全模式 1 中定义了 4 个安全级别:

  • 1 级:无安全性(开放文本,意味着无需身份验证且无需加密)

  • 2 级:未经身份验证的配对加密

  • 3 级:经过身份验证的配对加密

  • 4 级:经过身份验证的 LE 安全连接配对加密(LE Secure Connections)

安全等级1代表没有加密。安全等级2,3对应传统配对(Legacy pairing),安全等级4对应LE安全连接(LE Secure Connections)

  • 传统配对(Legacy pairing)

在蓝牙 v4.2 之前,传统配对是Bluetooth LE中唯一可用的配对方法。它非常简单,但存在风险,因为用于加密链接的短期密钥 (STK) 很容易被破解。在传统配对中使用 Just Works 时,TK 设置为 0,这在窃听或中间人 (MITM) 方面不提供任何保护。攻击者可以轻松暴力破解 STK 并窃听连接,而且也没有办法验证设备。

  • 带密钥输入

使用密钥输入会好一些,因为 TK 现在是一个 6 位数字,由用户在设备之间传递。例如,其中一个设备在其屏幕上显示该数字,用户使用键盘在其他设备上输入该数字。不幸的是,攻击者可以轻松嗅探正在交换的值,然后很容易找出 STK 并解密连接。即使无法直接确定 TK,也可以通过尝试所有 999999 种组合轻松破解密钥。

  • 带外配对(OOB)

在带外配对(OOB)中,TK 通过Bluetooth LE以外的其他方式进行交换,例如使用 NFC。此方法支持使用最大 128 位的 TK,从而提高了连接的安全性。交换期间使用的 OOB 通道的安全性也决定了Bluetooth LE 连接的安全性。如果 OOB 通道受到保护以免遭受窃听和 MITM 攻击,那么Bluetooth LE链路也是如此。

蓝牙 SIG 不推荐使用传统配对,但如果必须使用,请使用 OOB 方式。OOB身份验证与传统配对配合使用可被视为安全的方法。

  • LE安全连接(LE Secure Connections)

因此,在蓝牙 v4.2 中引入了 LE 安全连接(LE Secure Connections)。LE 安全连接不使用 TK 和 STK,而是使用椭圆曲线 Diffie-Hellman (ECDH) 加密技术来生成公钥-私钥对。设备交换公钥。它们将使用四种配对方法之一(Just Works, Passkey entry, OOB or Numeric Comparison)来验证对等设备的真实性,并根据 Diffie-Hellman 密钥和身份验证数据生成 LTK。

尽管 Just Works 在使用 LE 安全连接时更安全,但它仍然不提供身份验证,因此不建议将其用作配对方法。密钥输入(Passkey entry)配对方式,使用密钥、ECDH 公钥和 128 位任意数字来验证连接。这意味着它比传统配对要安全得多。使用 OOB 配对仍然是推荐的选项,因为只要 OOB 通道是安全的,它就会提供保护,就像在传统配对中一样。

此外,此功能引入了一种称为数字比较(Numeric Comparison)的新配对方式。虽然它遵循与 Just Works 配对方式相同的程序,但它在最后增加了另一个步骤来防止 MITM 攻击,即让用户根据两个对等点上显示的值,进行手动检查和确认。

对等点之间交换的唯一数据是公钥。使用 ECDH 公钥加密使得破解 LTK 变得极其困难,与传统配对相比,这是一个显著的改进。

注:尽管大多数设备都支持 LE 安全连接,但仍有一些蓝牙 LE 产品仅支持传统配对。因此,除了 LE 安全连接之外,启用对传统配对的支持也是一个好主意,以便在您的应用程序中实现更好的兼容性。

SMP安全管理协议

在蓝牙核心规范中,有三个主要的架构层:控制器、主机和应用程序,如下图所示。在主机层,有一个名为安全管理器 (SM) 的模块,它定义了配对和密钥分发的方法和协议、相应的安全工具箱,以及安全管理器协议 (SMP)。SMP定义了配对命令帧格式、帧结构和超时限制,用于配对和传输特定的密钥分发。

Image

SMP具体命令如下图:

Image

Image

Bluetooth LE配对过程

配对是为了创建密钥,然后可以使用这些密钥来加密链接。配对过程中还可能传输特定的密钥和数据,以便双方共享一些机密信息。这些机密信息可用于在未来重新连接时加密链接、验证签名或执行随机地址解析。

Bluetooth LE配对之前需要先建立连接。配对过程可以分为三个过程,前两个过程是必须的,第三个过程是可选的。

  • Phase1 Pairing Feature Exchange: 配对特征交换
  • Phase2 (LE legacy pairing): Short Term Key (STK) Generation: STK密钥生成
  • Phase2 (LE Secure Connections): Long Term Key (LTK) Generation: LTK密钥生成
  • Phase3 Transport Specific Key Distribution: 传输特定密钥分发(在传统配对中,LTK 也在该阶段被派发)

配对过程如下图所示:

Image

配对特征交换

配对特征交换(Pairing Feature Exchange)

1. 配对命令

两个设备之间的配对信息交换是通过配对请求(pairing request)和配对响应(pairing response)数据包完成的。只有主机才能发送配对请求命令,从机发送配对响应命令进行回复。如果从机也想发起配对,那么可以发送安全请求(security request )命令,主机收到这条命令后,可以选择发送配对请求,也可以拒绝。处理逻辑如下:

Image

主机,从机都可以调用int bt_conn_set_security(struct bt_conn *conn, bt_security_t sec)函数来发起配对。这个函数的处理逻辑里面会判断当前的身份是主机还是从机,从而发送不同的命令。

2. 配对命令格式

Pairing Feature Exchange主要交换I/O能力,是否支持OOB,是否支持绑定,是否支持MITM,是否支持安全连接(SC)等,还有分发密钥的相关的信息。格式如下:

Image

1)I/O能力包括:

  • DisplayOnly:仅有显示能力
  • DisplayYesNo:有显示能力,并可选择“是”或“否”
  • KeyboardOnly:仅有键盘输入能力
  • NoInputNoOutput:没有输入和输出能力
  • KeyboardDisplay:有键盘输入和显示能力

I/O能力编码,如下图:

Image

2)OOB 数据flag如下图:

Image

3)AuthReq中各个字段的含义如下:

  • Bonding Flags:指示是否支持绑定
  • MITM:如果设备需要请求 MITM 保护,则必须设置此位字段。这将启用设备的身份验证。
  • SC:代表安全连接,如果支持安全连接功能,则设置此字段。如果设备支持 LE 安全连接配对,则必须将 SC 字段设置为 1,否则必须将其设置为 0。如果两个设备都支持 LE 安全连接配对,则必须使用 LE 安全连接配对,否则将使用 LE 传统配对。
  • Keypress:仅在 Passkey Entry 协议中使用,其他协议将忽略它。设置此字段后,输入 passkey 时将使用按键通知。这将一次交换一位(one bit)passkey,这是蓝牙 4.2 相对于之前的机制(蓝牙 4.1 或更早版本)的一项重要增强。蓝牙 4.2之前的处理中,整个passkey在一次确认操作中交换。这增强了passkey交换机制,现在在 MITM 攻击中预测passkey变得更加困难。
  • CT2:表示加密过程可以使用名为 h7 的安全功能。
  • RFU:保留以备将来使用。

4)最大加密密钥大小 (Maximum Encryption Key Size):由于不同设备的处理能力不同,此字节表示设备可以处理的最大密钥大小。大小可以是 7 到 16 个字节。Nordic支持16个字节。

5)发起方密钥分发(Initiator Key Distribution):此字段表示发起方希望在后续阶段生成和分发哪些密钥。

6)响应方密钥分发 (Responder Key Distribution):此字段表示发起方希望请求响应方生成和分发哪些密钥。

密钥的种类如下:

Image

EncKey代表LTK;IdKey代表IRK ;SignKey代表 CSRK;Bluetooth LE中LinkKey不被分发。

3. 配对模式选择

通过综合考虑双方的OOB标志、MITM标志和I/O能力,来决定使用哪种配对方法。OOB和MITM标志首先确定是直接使用OOB配对方法还是根据I/O能力确定配对方法。如下图所示:

Image

Image

1) Initiator和Responder两方都设定了OOB flag的情况下,选用OOB

2) Initiator和Responder一方设定了OOB flag的情况下,需要判断SC flag

  • Secure connection的情况下,选用OOB。
  • Legacy的情况下,需要去判断MITM flag,只要一方设定了MITM flag,就要通过I/O能力去选择pairing mothed。如果两方都没有设定MITM flag,那么直接用Just works

3) Initiator和Responder都没有设OOB的情况下,判断MITM flag

  • 只要一方设定了MITM,需要去判断I/O能力
  • 两方都没设定MITM的情况下,使用Just Works

密钥生成阶段

1. 传统配对方式,生成STK,流程如下:

Image

传统配对方式中,首先交换临时密钥 (TK),用于生成短期密钥 (STK),然后使用短期密钥 (STK) 加密链路,传输长期密钥(LTK)。

1.1 传统配对定义了三种不同的方法来交互 TK

  • Just Works:TK默认为0,不提供身份验证,因此无法防御 MITM 攻击。
  • Passkey Entry :一台设备上显示 6 位数字密码(passkey),另一台设备上需要输入。设备的 I/O 能力决定了哪台设备显示数字以及哪台设备输入数字。用户输入的6位数字passkey,用前导零填充以得出 128 位TK值。
  • Out of Band:在设备之间通过带外通信,传递完整 128 位TK值,例如使用 NFC传输。

注:Just Works 配对不提供身份验证,无法防御 MITM 攻击。

1.2 传统配对的认证(authentication)过程:

首先,每个设备计算一个 128 位的确认值(confirm value)。确认值是使用名为 c1 的函数计算的,该函数接受多个参数,包括 TK。除了 TK 值之外,还包括两个设备都知道的字段以及一个随机数,在这个阶段,只有创建确认值的设备知道这个随机数。在主机上,这个值称为LP_RAND_I。在从机上,称为LP_RAND_R。

Image

然后,主机将其确认值 (LP_CONFIRM_I) 发送到从机,从机以其确认值 (LP_CONFIRM_R) 进行响应。

收到 LP_CONFIRM_R 后,主机发送自己的随机数 LP_RAND_I给从机。从机计算出LP_CONFIRM_I 值,并将其与主机端发送过来的 LP_CONFIRM_I 值进行比较。如果它们匹配,则从机已对主机进行了身份验证,因此它将发送自己的随机数LP_RAND_R进行响应。主机计算 LP_CONFIRM_R 值并将其与之前收到的值进行比较。如果它们匹配,则主机完成了对从机的身份验证。

以Passkey为例,认证流程如下:

Image

1.3传统配对中,STK的生成公式如下:

STK=s1(TK,LP_RAND_R,LP_RAND_I)

注意:TK值是不会被蓝牙链路传输的,这确保了一定的安全性。TK的密码强度直接影响了STK的密码强度,显然OOB要好一些。

2.安全配对方式, 生成LTK

Image

LE 安全连接使用椭圆曲线 Diffie-Hellman (ECDH) 密钥交换算法交换数据,然后使用数据创建对称密钥,称为长期密钥 (LTK)。

2.1 Public Key Exchange

发起配对的设备(发起者)将其公钥发送给另一台设备(响应者),后者用其公钥进行回复。公钥在收到后进行检验,以检查它们是否在正确的椭圆曲线上。注意,LE 安全连接仅使用 P-256 曲线。

2.2 Calculate DHKey

每个设备都会计算一个称为 Diffie-Hellman key (DHKey) 的密钥。假设一方是Alice,一方是Bob,Alice 和 Bob 这两个设备按以下方式计算 DHKey:

1
Alice: DHKey = P256(SKa, PKb) Bob: DHKey = P256(SKb, PKa)

两个设备 A 和 B 的私钥分别表示为 SKa 和 SKb。PKa和PKb是它们的公钥,交换之后,双方都知道对方的公钥。基于公钥和私钥作为参数,两边能计算出相同的DHkey。DHKey 是一个对称共享密钥。

上述过程如下图所示(图一描述过程,图二描述协议):

Image

Image

2.3 Authentication Stage 1

不同的配对模式,对应的算法略有不同。LE安全配对有4种模式,除了前面提到的传统配对中的3种模式以外,还引入了一种新模式,称为数字比较(Numeric Comparison)

1) Just Works 和Numeric Comparison身份验证阶段1:

首先,设备 B 生成一个伪随机数 Nb,并将其与两个设备的公钥一起,作为 f4 (函数)的参数,来计算确认值Cb 。Cb=f4(PKb, PKa, Nb, 0),然后将 Cb 发送到设备 A。由于设备 A 不知道 Nb 的值,因此它无法在此阶段对确认值执行任何操作。

设备 A 现在将其自己的伪随机数 Na 发送到设备 B,设备 B 则用其随机数 Nb 回复。现在,设备 A 拥有 f4 函数的所有参数,因此它使用在公钥交换期间获取的公钥和刚刚收到的另一台设备的随机数 Nb 重新计算确认值。它将计算出的确认值与从设备 B 收到的 Cb 值进行比较。如果它们不相同,则配对中止。

如果使用 Just Works,则身份验证第 1 阶段已完成。如果使用Numeric Comparison,则还需要执行一步。

每个设备使用两个公钥 PKa 和 PKb 以及两个伪随机数 Na 和 Nb,通过g2 函数计算出一个六位数字。然后,每个设备显示其计算出的数字。用户被邀请确认两个设备是否显示相同的六位数字,也可以通过按下特定按钮来实现。通过指示两个数字相同,用户确认参与通信的两个设备确实是用户尝试配对的设备。换句话说,用户参与了配对设备的身份验证。对设备进行身份验证后,就会进入身份验证阶段 2。

另一方面,如果用户发现两个数字不相同,则身份验证阶段 1 失败,并且终止该过程。

具体流程如下图所示:

Image

2) Passkey Entry身份验证阶段1:

用户输入密码(Passkey)后,设备会计算、交换和检查确认值 Ca 和 Cb。但是,与 Just Works/Numeric Comparison 中的单次确认不同,使用密码(Passkey)输入,确认过程是迭代和增量的。

在每次迭代过程中,每个设备都会生成一个 128 位随机数 Na 或 Nb,并且每次将密钥值的一位纳入确认值的计算中。确认值函数 f4 的输入包括两个公钥、本次迭代的随机数以及从本次迭代的密码位值派生的值。

每次迭代都会交换和检查确认值。Cai=f4(Pka, PKb, Nai, rbi),Cbi=f4(PKb, PKa, Nbi, rbi)(i=0 to 19)(ra=rb=passkey)rai和rbi是passkey二进制值对应的每一位。

六位密码(passkey)对应 20 位二进制数字(999999=0xF423F),因此计算、交换和检查完整确认值的过程需要迭代20次,每次迭代都会合并或披露密码的新位。这种方法称为“逐步披露”,其优点是 MITM 攻击在实际应用中更加困难,大多数攻击在攻击者尚未看到完整和最终确认值的情况下就会提前失败。缺点是计算过程比较复杂,数据交互的次数较多,耗时耗电。

具体流程如下图所示:

Image

3) OOB身份验证阶段1:

使用 OOB 方式,整个过程使用非蓝牙的数据交换机制进行的。

具体流程如下图所示:

Image

Image

使用带内接收的公钥和带外接收的随机数 ra 和 rb 重新计算接收到的确认值 Ca 和 Cb,这个是基于OOB双向数据传输的情况。如果 OOB 通信只能在一个方向上进行(单方向传输数据),则接收 OOB 数据的设备的认证将基于该设备知道通过 OOB 发送的随机数 r(ra或rb)。

在这种情况下,r 必须是保密的:r 可以每次重新创建,或者必须限制对发送 r 的设备的访问。如果设备未发送 r,则设备会将其假定为 0。计算出的确认值必须与接收到的 OOB 值匹配。如果两者之一不匹配,配对将中止。

2.4 Authentication Stage 2

身份验证阶段 2 有四个步骤。

1)使用函数 f5 计算长期密钥 (LTK) 和 MacKey ,MacKey || LTK = f5(DHKey, Na, Nb, BD_ADDR_C, BD_ADDR_P)

2)设备 A 计算称为 Ea 的检查值并将其发送到设备 B,在设备 B 中重新计算该值并将其与收到的值进行比较

3)设备 B 计算称为 Eb 的检查值并将其发送到设备 A,在设备 A 中重新计算该值并将其与收到的值进行比较

4)使用计算出的 LTK 在链路上启动加密,为阶段 3 做好准备

Ea,Eb的计算公式如下表:

Image

如果步骤 2 或 3 中的任何一个检查失败,配对将中止。具体流程如下图所示:

Image

密钥分发

  • 对于传统配对和LE安全连接,它们分发的内容是有区别的。另外,传统配对密钥分发的链路是通过STK加密的;LE安全连接的密钥分发是通过LTK加密的。传统配对可能分发的内容如下:
  1. LTK by the Peripheral
  2. EDIV AND Rand by the Peripheral
  3. IRK by the Peripheral
  4. BD_ADDR by the Peripheral
  5. CSRK by the Peripheral
  6. LTK by the Central
  7. EDIV and Rand by the Central
  8. IRK by the Central
  9. BD_ADDR by the Central
  10. CSRK by the Central
  • LE安全连接可能分发的内容如下:
  1. IRK by the Peripheral
  2. BD_ADDR by the Peripheral
  3. CSRK by the Peripheral
  4. IRK by the Central
  5. BD_ADDR by the Central
  6. CSRK by the Central

Bluetooth LE绑定

创建绑定后,每个设备都会存储已分发的密钥信息,并在下一次连接中使用这些密钥,这样就可以跳过配对过程,从而节省能源并减少用户操作设备时必须等待的时间。

LTK 存储在安全数据库中,并通过 EDIV 和 Rand 值进行标识。执行绑定后,每次后续重新连接都将使用已分发的 LTK 生成的密钥来加密链接。

NCS中可以通过配置编译选项使能绑定功能(CONFIG_BT_BONDABLE=y)。注意,绑定信息存储在settings区,更具体的是bt settings区域,所以,使能绑定功能的同时也要使能bt settings区。具体信息如下:

Image

Image

Image

如果要删除绑定信息,可以调用int bt_unpair(uint8_t id, const bt_addr_le_t *addr)函数,函数说明和使用示例如下:

1
2
3
4
5
6
7
8
9
/**
* @brief Clear pairing information.
*
* @param id Local identity (mostly just BT_ID_DEFAULT).
* @param addr Remote address, NULL or BT_ADDR_LE_ANY to clear all remote * devices.
*
* @return 0 on success or negative error value on failure.
*/
int bt_unpair(unit8_t id, const bt_addr_le_t *addr);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
void button_changed(unit32_t button_state,unit32_t has_changed)
{
int err;
unit32_t buttons = button_state & has_changed;

if(buttons & KEY_BOND_REMOVE_MASK) {
err = bt_unpair(BT_ID_DEFAULT,NULL);
if (err) {
printk("Bond remove failed err: %d\n", err);
} else {
printk("All bond removed\n");
}
}
}
1
2
3
4
5
6
7
8
9
10
static int remove_peers(unit8_t identity)
{
LOG_INF("Remove peer on identity %u", identity);

int err = bt_unpair(get_bt_stack_peer_id(identity), BT_ADDR_LE_ANY);
if (err) {
LOG_ERR("Failed to remove");
}
return err;
}
  • Title: BLE蓝牙安全
  • Author: 韩乔落
  • Created at : 2024-08-19 11:12:11
  • Updated at : 2024-09-09 11:45:54
  • Link: https://jelasin.github.io/2024/08/19/BLE蓝牙安全/
  • License: This work is licensed under CC BY-NC-SA 4.0.
Comments