Showing Posts From

Bluetooth

详细总结EddyStone BLE广播包协议规范

EddyStone简介 Eddystone 是专门针对蓝牙低功耗（BLE）广播包定义的数据格式。 它是由 Google 在 2015 年推出的开源 Beacon 协议，旨在提供比苹果 iBeacon 更开放、功能更丰富的广播标准。 !image.png 在蓝牙的协议栈中，Eddystone 运行在 GAP（Generic Access Profile） 层之上。它利用了BLE 广播包中 31 字节的载荷（Payload）进行通信，实际上也就是基于这个31字节的数据长度所规定的一套标准化的数据结构 。 - 因为是工作在 BLE 的广播模式之下，因此进行通信的设备双方不需要建立配对连接。在通信过程中，广播设备只是单向地定时向外发射信号，任何在其覆盖范围内的扫描设备负责监听这些信息 。 - 不同于 iBeacon 在广播通信的过程中只发出一组 ID，Eddystone 允许设备轮流广播不同类型的广播帧（Frames），这是 EddyStone的一大特色。 EddyStone的四种主要的帧类型 UID（身份与状态帧） 这种帧类型主要用于标识设备的身份 。其帧结构如下： - Namespace ID (10 Bytes)：类似于设备的姓名，用于标识某个特定的公司或者产品类型/系列 。所以一般情况下某个公司生产的同一型号的设备的Namespace ID都是相同的。 - Instance ID (6 Bytes)：类似于设备的名称，用于标识具体的某台设备。即使是同一型号的设备，其Instance ID也是不同的，用于区分不同的设备。 - 自定义空间：这部分空间可自定义其具体的含义 。 TLM（遥测帧） 这个帧一般用于广播设备的状态，如电量、温度、开机时间等，是设备的状态帧。 URL（网页跳转帧） 这个帧类型是 Eddystone 最著名的功能。它用于直接广播一个压缩后的 URL 地址（如 https://goo.gl/...）。 其实这也是Beacon类型的蓝牙设备的典型应用场景： - 手机靠近某个公交站，会自动弹出附近的路线信息网页，无需安装 App。 - 手机靠近超市的某个区域，会收到一个网页URL，其中包含有这个区域对应商品的促销信息。 EID（安全帧） 这个帧类型主要用于对 ID 进行加密处理，每隔一段时间变换一次 ID，防止设备被他人非法追踪。 EddyStone的包结构 首先总结一下典型的BLE广播包的整体包结构。在空气中传输的原始数据包长度通常为 8 到 47 字节： !affce66d-09d8-4bec-b2a5-72a72a1fe8d1.png EddyStone的所有数据结构就包含在其中的Payload中。Payload部分的长度为6-37字节，其中包含了设备的 MAC 地址和实际的广播数据 (ADV Data) ，除去 6 字节的设备地址以外，剩下的 31 字节 就是用户可定义的广播数据区。它由多个 AD Structure 组成（如上图的AD 0到AD N），每个AD Structure结构的格式为：[长度] [类型] [数据]。 对于 Eddystone 协议而言，其通常包含以下三个标准的 AD Structure： - Flags ：对于所有的EddyStone设备而言，这部分是相同的 用于告知扫描者该设备的物理特性（如：仅限发现模式、不支持经典蓝牙）。 • 字节流：02 01 06 ◦ 02: 后面数据的长度。 ◦ 01: 类型（Flags）。 ◦ 06: 数值（代表 LE General Discoverable Mode + BR/EDR Not Supported）。 - 16-bit Service UUID：对于所有的EddyStone设备而言，这部分是相同的 用于告知扫描者这是一个符合 Eddystone 标准的设备。 • 字节流：03 03 AA FE ◦ 03: 后面数据的长度。 ◦ 03: 类型（16-bit Service UUID）。 ◦ AA FE: Eddystone 的官方注册 UUID (0xFEAA)，采用小端序存储，所有的EddyStone设备都必须包含这个UUID。 - Service Data (核心载荷)：这是广播协议存放实际数据的地方。 • 字节流示例 (UID Frame)：17 16 AA FE 00 xx xx xx ◦ 0-17: 长度可根据包内容长度变换，最长23 字节。 ◦ 16: 类型为Service Data，即0x16，固定不变。 ◦ AA FE: UUID 0xFEAA，固定不变。 ◦ 00/10/20/30: Eddystone Frame Type。 ◦ 后续为不同的帧数据 因此，可以简单认为：对于所有标准的 Eddystone 设备包和广播包，前 7 个字节（02 01 06 03 03 AA FE）是完全相同且固定的。各个设备真正的差异化竞争和业务逻辑的区分，全部集中在类型为 16 之后的 Service Data 载荷中。 EddyStone的帧类型与Service Data结构的对应 以上提到，对于所有的EddyStone设备的广播包而言，其广播包的Payload部分包含有三个AD Structure，其中前两个AD Structure的数据内容完全固定并且相同，只有最后一个AD Structure即Service Data部分真正用于承载差异化的数据。 Service Data部分的第一个字节为Length，其对应了这个部分的长度有多长；第二个字节固定为0x16，即代表这个部分为Service Data类型，因此是固定不变的；第3-4个字节同样为固定的UUID 0xFEAA。所以 EddyStone 广播包真正的应用层差异主要体现在Service Data第五个字节及其以后的部分。 以下安装不同的EddyStone帧类型对其帧结构进行总结，后续的解释以Service Data的第五个字节位置（即EddyStone Frame Time）为起始点。 UID帧（身份与状态帧） - Byte 0，Frame Type，1 Byte，固定为 0x00 - Byte 1，TX Power，1 Byte，0米处的校准接收信号强度 (RSSI)，范围为 -100 到 +20 dBm - Byte 2-11，Namespace ID，10 Bytes，用于区分不同的范围/组织/厂商/产品类型 - Byte 12-17，Instance ID，6 Bytes，用于标识具体的设备即设备ID，每个设备都不同 - Byte 18-19，Reserved，2 Bytes，官方规范预留，通常填充0 URL帧（网页跳转帧） - Byte 0，Frame Type，1 Byte，固定为 0x10 - Byte 1，TX Power，1 Byte，0米处的校准 RSSI 值 - Byte 2，URL Scheme，1 Byte，前缀编码（如0x00代表http://www. ，0x03代表https:// 。 - Byte 3-19，Encoded URL，1-17 Bytes，经过压缩后的网址内容（非 ASCII，有专门的后缀压缩码） TLM (遥测帧) - Byte 0，Frame Type，1 Byte，固定为 0x20 - Byte 1，TLM Version，1 Byte，协议版本（目前通常为0） - Byte 2-3，VBATT，2 Bytes，电池电压，单位为毫伏 (mV) - Byte 4-5，Temperature，2 Bytes，设备温度（8.8 固定小数点格式，单位摄氏度） - Byte 6-9，ADV_CNT，4 Bytes，自重启以来发送的广播包总数 - Byte 10-13，SEC_CNT，4 Bytes，自重启以来的运行时间（单位 0.1 秒） EID（安全帧） - Byte 0，Frame Type，1 Byte，固定为 0x30 - Byte 1，TX Power，1 Byte0米处的校准 RSSI 值 - Byte 2-9，Ephemeral ID，8 Bytes，随时间变化的 8 字节加密标识符 补充1：以上提到的8.8固定小数点格式是什么意思？ 8.8 固定小数点格式是一种用 2 个字节（16 位）来表示带小数点的数值的高效方法。它将 16 位划分为两个相等的部分：高 8 位表示整数，低 8 位表示小数。 一个 16 位的字段被拆分为： • 高 8 位 (Most Significant Byte, MSB)：有符号整数部分。采用补码形式（即大于0x80为负数，小于0x80为正数），范围是 -128 到 +127。 • 低 8 位 (Least Significant Byte, LSB)：无符号分数部分。它代表 256 分之几（即 n/256）。 补充2：以上提到的Encoded URL的压缩流程是什么？ 在 Eddystone-URL 规范中，为了在蓝牙广播有限的 31 字节 空间内塞入尽可能长的网址，Google 并没有使用复杂的通用压缩算法，而是采用了一种基于查表法的字节替换技术。这种方法分为两部分：前缀压缩 和 后缀/常用词压缩。 前缀压缩。用 1 个字节代表网址的开头，常见的映射关系如下： - 0x00：http://www. - 0x01: https://www. - 0x02: http:// - 0x03: https:// 后缀压缩。其他普通的 ASCII 字符（如 a-z, 0-9, -）直接按原样存储。但对于顶级域名（TLD）和常用路径符号，规范定义了一套特殊的单字节替换码（通常在 0x00 到 0x0D 范围内）： - 0x00：.com/ - 0x01：.org/ - 0x02：.edu/ - 0x03：.net/ - 0x07：.com - 0x08：.org - 0x0B：.net

蓝牙BLE通信的安全模式和安全级别总结

BLE安全模式的定义：在蓝牙规范所定义的应用场景中，是指产品使用蓝牙BLE通信的时候，对于其通信过程中安全性的具体要求和相对应的工作流程、解决方案对策。不同的安全级别对应了不同的工作流程，也对应了不同的保护级别，用户可以根据产品对于安全性保护的需求以及产品本身的特性/IO能力等选择合适的安全级别。 基于对通信中安全性的具体要求，BLE在产品中的使用流程主要共有三种安全模式：LE Security Mode 1， Mode 2，Mode 3。每个安全模式下又包含有不同的安全级别。 这三个Security Mode之中，最常用的还是Mode 1的几个级别。 值得注意的是，对于安全模式以及安全级别的选择，与产品的具体应用场景、产品本身所具备的IO能力以及对于数据的保护程度和要求息息相关，并不一定是安全级别越高就越好。 Security Mode 1 Mode 1主要用于决定两个BLE设备之间配对的安全需求和执行流程，通过配对流程来对蓝牙设备使用的安全级别进行控制。Mode1是最常用的一种安全模式。 有关BLE设备之间的配对流程，我在其他的笔记中有非常详细的总结。 - BLE设备配对模式和流程详细解析（一） - BLE设备配对模式和流程详细解析（二） - BLE设备配对模式和流程详细解析（三） 对BLE配对流程及其连接状态下的通信密钥有清楚的认识，才能完整的理解各种不同的安全模式和安全级别。 以下解释Mode 1中所包含的不同安全级别。 Mode 1 Level 1: 无安全特性 Level 1没有任何安全特性，进行BLE通信的两个设备之间既不需要进行设备硬件身份的认证，通信过程的所有数据也不需要进行任何加密处理。配对的流程会完整走一遍，但是基本上也就只是走一个过程而已，对于安全性方面没有明确的要求。 所有工作在这个级别下的BLE外设设备，可以被任意的BLE Central设备直接连接，并且两者之间的通信全部是明文，不做任何加密处理，也不对数据包的内容进行完整性和真实性的验证，数据包的内容可以被任何BLE Sniffer工具监听到和解析。 当然Level 1的好处则是提供了最好的用户设备访问的体验，连接通信的速度最快，相互连接和数据访问的整个流程不做任何限制，因此使用起来最方便。 因为没有任何安全性保护，比较适合那些对于通信数据没有任何安全性保护需求的应用场景，例如蓝牙温湿度传感器。 Mode 1 Level 2: 数据加密+无硬件身份认证 在Level 2级别中，两个BLE设备之间进行配对的过程中不进行硬件身份认证，但是会完成整个配对流程，并在配对流程的最后交换双方的数据通信加密密钥。双方通信连接建立以后，所有的通信数据都是通过AES算法+IRK所衍生的会话密钥进行加密的，即使BLE Sniffer进行监听数据包也无法解出明文。 实际上这个级别实际上就对应于配对流程中的Just Works模式，进行配对的设备既没有显示屏用于显示配对数字，也没有键盘用于输入配对数字，因此配对过程中用户无法参与进去，也就没有办法做很有效的设备身份认证。 该安全等级相比Level 1提高了一些，但是缺少了配对过程的硬件身份认证环节，无法满足对数据安全性要求很高的应用。但是该过程不需要人为参与，用户使用的体验更好更方便。 这个级别也是Just Works这个配对模式能够支持的最高安全级别。 Mode 1 Level 3: 数据加密+硬件身份认证 Lever 3级别的配对流程中，要求对进行配对双方的硬件身份进行认证，这个认证要么需要用户人为参与（Passkey Entry），要么通过蓝牙之外的带外传输（OOB），因此能够通过完整的配对流程，也就是相当于完成了相互之间硬件身份认证的确认。在配对过程中完成双方硬件身份确认后，才进行后续密钥的交换流程，因此安全性保护方面更为完整。 只不过Level 3默认使用的是LE Legacy Pairing这种相对较老的配对方式，安全性方面相对Level 4稍差。 Mode 1 Level 4: 数据加密+硬件身份认证+强制使用SC Level 4跟Level3类似，都是提供了数据加密和硬件身份认证的全面保护，但是Level 4在Level 3的基础上强制要求进行BLE配对的双方设备，在配对的流程中一定要使用更安全的LE Secure Connections配对流程和机制，不能使用之前的LE Legacy Pairing模式。这使得工作在Level4的设备安全等级相对更高，而且可以支持Numerical Comparison这种硬件身份认证的执行流程。 Security Mode 2 Mode 2主要针对的是BLE设备连接状态下双方进行通信的数据包签名机制的问题。 所谓的数据包签名机制，就是对于BLE连接的两个设备所发出的每个数据包，按照一定的算法对这个数据包的内容进行签名，把数据包的内容和签名一起发出，接收端按照相同的签名算法和密钥验证这个数据包数据内容的完整性（这个数据包的内容是完整的，没有被修改的）和通信身份的真实性（这个数据包确实是由自己信赖的通信对端所发出的）。 针对Mode 2和BLE通信中的数据签名，我的看法是：如果数据包已经通过双方所共享的密钥进行加密了，那么这个数据包就没有必要再做用户身份的数据签名确认了，因为只有持有相同密钥的通信对端才能正确解析。既然都已经能够成功解密出来数据包，那也就说明通信对端是自己信赖的通信方。所以对于BLE通信而言，Mode 2、数据签名、CSRK密钥应该都是针对通信数据包内容不需要加密、但是需要确认通信双方身份的应用场景。 数据签名的计算逻辑如下图所示，主要依赖于双方配对流程中所协商的CSRK密钥。 !1734933198600.png - 数据签名的运算逻辑在我的另外一篇笔记中有非常详细的解释： Mode 2包含有两个安全级别。 Mode 2 Level 1：无身份认证+数据签名 在这个级别中，两个BLE设备在配对流程中使用不需要用户人为介入的association model，最典型的就是Just Works。这种方式无法提供有效的策略去进行硬件设备的身份认证以及对抗中间人攻击，因此使用这种方式最好是在一个安全的环节中进行设备之间的配对流程操作。 对于该级别的支持，在两个设备的配对流程中一定要协商和共享CSRK密钥，因为后续的连接状态下的数据通信机制，需要依赖这个CSRK密钥对数据包进行签名和匹配比较。 这个级别存在的最大问题是，因为Just Works没法有效的验证对方的硬件身份，所有的Central设备都可以与当前的这个BLE外设设备完成配对，分享CSRK密钥以及在后续的通信中使用CSRK密钥对收发的数据包进行签名验证。如果当前的产品应用对于通信对端的硬件身份认证有要求，这个level 1就不合适了。 Mode 2 Level 2：身份认证+数据签名 在该级别中，进行配对的两个BLE设备需要在配对流程中使用能够支持硬件身份认证和防止中间人攻击的association model，实际上也就是OOB、Passkey Entry以及Numerical Comparison这三种之一。 当然对于这种级别，两个设备的配对流程同样需要共享CSRK密钥。这样的话，通过配对过程中完整的身份认证机制确认只有自己信任的硬件设备才能够与自己完成配对过程分享CSRK密钥，后续通信中再基于CSRK密钥+数据签名等机制就可以确保通信双方的连接是在双方所信任的硬件上进行的，提升了通信的安全性。 Security Mode 3 Mode 3专门用于针对BLE外设设备广播数据的加密保护需求。即是否需要对广播数据进行加密？对广播数据进行加密是在蓝牙规范v5.4版本中引入的新功能，也就是所谓的Encrypted Advertising Data (EAD) 。加密广播功能的实现依赖于一个在同一个广播组内共享的16字节Broadcast Code。 实际的使用中，因为EAD功能是在v5.4版本才新推出，而且一般只会在LE Audio这类同步数据流（Isochronous Streams）的应用中才会用到广播加密功能，所以这种安全模式的实际应用场景很少。 针对不同的需求，Mode 3包含有3个安全级别。 Mode 3 Level 1：无加密 在该安全级别下，这个BLE外设设备不对广播数据做任何加密处理，广播数据以明文形式发布，所有的Central设备都可以正常扫描并解析出来。安全性最差，但是可以提供最方便的用户使用体验。 无加密广播的工作模式是蓝牙规范5.4版本之前默认的数据广播模式。 Mode 3 Level 2：广播加密+Broadcast Code无认证 处于该安全级别下的BLE外设设备所发出的广播包都会使用Broadcast Code进行加密保护，只有持有相同Broadcast Code的Central设备才能对这些广播包进行正确的解析。因此安全性相比Level 1有所提升，但是对于设备加入同步数据流广播组BIG（Broadcast Isochronous Groups），并没有身份验证环节，所有的设备都可以加入BIG并获取Broadcast Code，所以安全性方面仍然存在欠缺。 Mode 3 Level 3：广播加密+Broadcast Code身份认证 在Level 2的基础上，对加入同步数据流广播组BIG的BLE设备进行身份认证，要求提供验证码才能获取Broadcast Code对广播包进行解码，否则就会报错。 参考资料 - Bluetooth LE: Security Modes and Procedures Explained - Technical Articles - Securing BLE Connections—An Overview of the Security Protocol - Technical Articles

BLE设备配对模式和流程详细解析

BLE设备的配对流程，主要就是在两个设备之间建立相互信任的配对和绑定关系，产生两者后续加密通信和身份认证的密钥，并安全的交换这些密钥用于后续连接模式下的加密通信。 整个BLE配对过程的细节非常繁琐，因此大致分为三篇笔记的篇幅对完整的配对和绑定的流程进行深入的解析，以建立对蓝牙安全性的更深入理解： 1. 对BLE设备之间进行配对和绑定的过程以及支持的配对模式进行简要总结，详细描述配对流程第一阶段的实现步骤； 2. 对BLE设备配对流程的第二阶段LE Legacy Pairing模式的执行流程进行详细解释和说明。 3. 对BLE设备配对流程的第二阶段LE Security Connections模式的执行流程，以及第三阶段对密钥的分发流程进行详细解释和说明。 BLE设备的配对和绑定流程简述 BLE配对流程的主要作用既然是产生和交换密钥，那就必须要保证整个密钥交换流程的安全性，否则被攻击者监听到，这个密钥也就泄露了。此外，BLE设备之间在进行配对之前还要进行必要的硬件设备身份确认，身份确认通过以后（确认正在执行配对流程的两个设备是合法而且正确的，避免错配）才能执行后续的配对流程。 与配对（Pairing）流程相关联的还有一个绑定流程（Bonding）。这两个概念是先后的关系，简单的总结就是配对流程是在两个BLE设备之间建立信任关系，产生和交换用户后续加密通信的密钥；而绑定流程则是把配对流程所产生的密钥保存起来，后续两个设备之间重新连接的时候就可以直接使用之前已经交换和保存好的密钥，这样加密连接的建立速度更快，用户使用体验更好。因此，一旦经过了配对+绑定的完整过程，下次两个设备重新连接的时候，就可以跳过重新进行新的密钥协商和传递的过程，直接使用之前绑定流程中在两端保存的密钥信息来对通信进行加密和保护。 - 实际上配置之后自动执行一个绑定流程安全性也更好，这样就不需要每次两个设备之间建立连接的时候，都执行完整的身份认证、密钥协商和交换的过程，密钥和其他敏感信息泄露的风险更小。 符合蓝牙4.2及其之后版本规范的BLE设备有两种配对流程可以选择：经典的LE Legacy Pairing，以及更加安全的LE Secure Connections。这两者的区别主要是后者的配对密钥生成和交换方法更加安全，以及后者可以支持更完整的配对模式（Association model）。 整个BLE配对流程从顺序上可以分为三个阶段，其中第一阶段和第三阶段对于LE Legacy Pairing和LE Secure Connections来讲是完全一样的，两者的区别主要就在第二阶段。而对于两个BLE设备在进行配对操作的时候究竟会选择LE Legacy Pairing还是LE Secure Connections，则依赖于其支持的蓝牙规范版本（4.2之前版本只能使用LE Legacy Pairing）以及配对特性交互环节所交换的SC（Secure Connections）选项：如果配对的两者都支持SC选项，那么就会走LE Secure Connections流程，只要有一方不支持SC选项就走LE Legacy Pairing流程。 !1734512982950.png 配对流程阶段一：双方配对特性/能力交换 整个BLE配对流程的执行包含两个角色：Initiator和Responder。而配对流程总是由Initiator发起，Initiator向Responder发出一个Pairing Request包，Reponder收到以后返回一个Pairing Response消息。这两个消息中包含了双方各自的能力和特性等信息。 !image.png - IO Cap：用于表示进行配对操作的双方具备的输入（例如键盘，按键等）或者输出（例如显示屏等）设备方面的能力，由此来决定后续执行配对操作可以采用的安全等级和密钥的产生方法。根据双方IO能力的不同，可以支持的IO选项包括：DisplayOnly, DisplayYesNo, KeyboardOnly, NoInputNoOutput和KeyboardDisplay。 - DisplayOnly：该设备只有一个显示屏可用于显示数字字符串，无法接受输入 - KeyboardOnly：该设备具备输入数字的能力 - DisplayYesNo：该设备既有一个显示屏可以显示数字，也可以允许用户以某种方式（例如确认按键）选择YES或者NO - NoInputNoOutput：该设备没有可供用户使用的输入输出能力（显示屏或者键盘/按键） - KeyboardDisplay：该设备既可以支持输入数字/字符串，又有显示屏显示字符串/数字 - OOB Data Flag：用于标记双方是否具备BLE通信之外的其他手段（也就是所谓的带外通信，out of band）可以协助进行这个配对操作和设备认证操作，例如NFC或者二维码。可选的选项只有两个：OOB Authentication Data Not Present和OOB Authentication Data from a Remote Device Present. - AuthReq（Authentication Requirements）：这个field用于定义该设备对于配对流程所需要的安全性认证的需求，每个bit表示一个需求：BF（Bonding Flags）, MITM (Man In The Middle Protection)， SC（Secure Connections）和KP（Keypress）。 - BF（Bonding Flags）：用于决定后续配对过程完成后是否需要把本次配对交换的密钥保存起来用于两者以后的连接通信，也就是绑定过程是否自动运行。 - SC（Secure Connections）：用于决定后续的配对流程的执行是走LE Legacy Pairing还是LE Secure Connections流程。 - MITM (Man In The Middle Protection)：用于标记本设备后续的配对过程要能够应对中间人攻击。 - Max Encryption Key Size：配对过程中加密Key的最大长度，取值范围为7-16个字节，会影响后续通信连接的加密强度。 - Initiator Key Distribution / Responder Key Distribution：对于Initiator和Responser而言，可以支持分发的密钥类型。在配对过程中需要在两个设备之间交换和分发的密钥包括以下三个： Long Term Key (LTK)，Identity Resolving Key (IRK)和Connection Signature Resolving Key (CSRK)。这个设置表示在配对过程中这些密钥应该由哪一端分发。 在进行配对的两个BLE设备之间交换Pairing Request包和Pairing Response包以后，双方就都了解了本次配对的IO交互能力以及对于配对的安全性需求等方面的信息，下一步就是决定具体的配对流程执行的模式，也就是所谓的Association Model。 配对流程Association Model的协商 具体的Paring执行的流程，依据于配对双方所具备的IO能力以及对于配对安全性的具体需求，可以分为以下几种Association Model： - JW（Just Works）：安全性最低的配对流程操作方式，适用于两个设备都没有合理的手段去显示配对数字以及确认配对过程的执行。完全依赖于两个设备之间的通信，不需要用户参与配对操作的交互流程，这种配对方式无法应对中间人攻击MITM。 - PKE（Passkey Entry）：至少需要一个设备具备显示屏，另外一个设备具备输入能力。配对流程中，设备A显示一个数字，然后在设备B上输入这个数字后进行设备配对关系验证。因为它需要用户在这个流程中参与物理交互，因此有助于防止MITM攻击。 - 对于LE Secure Connections模式下，也可以是两个设备都没有显示屏，但是都有键盘，此时两个设备都通过键盘输入一个相同的数字。 - NC（Numeric Comparison，数字比较）：适合于两个设备都有显示屏用以显示匹配数字的内容，以及有手段确认两端显示的一致性（例如确认按键）。配对过程中用户通过比较两个设备上显示的数字是否一致来保证配对流程的安全执行。与PKE一样，需要用户参与配对过程的验证环节，可以有效应对中间人攻击。 - NC模式只在LE Secure Connections模式中存在，在LE Legacy Pairing模式中不存在。 - OOB（Out of Band，带外通信）：适合于两个设备都有蓝牙之外的带外通信能力。如果配对的双方都具备除蓝牙以外的另外一种带外通信能力的话，可以通过这种蓝牙通信之外的通信方式来交换安全性信息。 LE Legacy Pairing可以支持JW，PKE和OOB这三种association model，而LE Secure Connections则可以支持以上所有的四种association model。 下一步就是根据BLE设备之间交换Pairing Request包和Pairing Response包中所包含的配对设备IO能力，以及对于配对安全性的需求（SC，MITM等），就可以按照下面的逻辑来选择合适的配对模型。 !image.png - 首先检查两个设备的SC（Secure Connections）标注，如果两个设备都设置了这个标志，后续的配对流程就走LE Secure Connections；只要有一方没有设置这个标志，就走LE Legacy Pairing流程。无论是走哪个流程，接下来就是选择合适的association model。 - 接下来检查两个设备的OOB（Out of Band）标志，如果两个设备都通过这个标志表示具备除蓝牙之外的其他带外通信能力，则使用OOB association model。只要有一方不具备OOB标志，就没法使用OOB，接下来判断MITM标志的设置情况。 - 如果两个设置都没有设置MITM (Man In The Middle Protection)标志，后续的配对流程就会选择JW association model，这种情况下的配对流程无法应对中间人攻击。而如果有一方或者两方都设置了MITM标志，则接下来根据两端具备的IO能力来选择合适的association model以应对MITM攻击。 - 接下来就是要分析两端所具备的IO能力：是否有显示屏可以用于显示数字？是否有键盘可以用于输入数字和字符？具体如何选择按照两者所具备的IO能力进行选择。 !image.png 至此，蓝牙配对的第一阶段就结束了，这个阶段主要就是通过双方明文交互的Pairing Request和Pairing Response消息来确定配对的流程、需求以及Association Model。 接下来就要进入第二阶段，主要是进行双方硬件的身份认证，然后建立加密链接以方便在第三阶段传输密钥信息。 --- 配对流程阶段二：配对流程加密链路的建立LE Legacy Pairing 第一阶段双方通过交换Pairing Request和Pairing Response消息，完成了配对方式以及Association model的协商。 第二阶段主要的作用就是： - 完成双方硬件身份认证的流程，确认对方就是自己要进行配对的设备。 - 为第三阶段配对密钥在两个设备之间交换和传输提供一个加密链路。 而如前所述，BLE配对流程存在两种模式：LE Legacy Pairing和LE Security Pairing。两者在配对流程的第二阶段差异极大，因此需要完整的分开来进行描述。这部分是LE Legacy Pairing模式下第二阶段工作流程的详细总结。 对于LE Legacy Pairing模式而言，配对流程加密链路的建立需要依赖于一个短期的加密密钥STK（short term key），这个STK仅用于配对过程中加密通信链路的建立，不会在两个设备之间长期保存和使用。 LE Legacy Pairing模式的阶段二执行流程大致如下所示。 !1734689246347.png 临时密钥TK的生成 STK的生成又要依赖于一个临时密钥TK（Temporary Key）。这个临时密钥TK长度是128位，依赖于具体的association model： - 对于Just Works模式，TK是一个全0的值。因此最不安全。 - 对于Passkey Entry模式，由一端在屏幕上显示，以及用户在另一端设备上输入以进行确认的一个6位数字密码，这个数字密码占据TK的20bit，其他108bit使用0填充。安全性介于JW和OOB之间。 - 对于OOB模式，TK是一个通过OOB方式在两边传输的128bit随机数密钥。安全性最好。 通过这一步，进行配对的双方共享同一个TK，但是这个TK并不是通过此时还不安全的BLE发给对方的。 设备身份认证 这一步两个BLE设备会各自计算出来一个confirm value的128位值。confirm value的计算需要使用一个c1函数，其参数是前一步已经在BLE两端共享的TK，各自产生的随机数，以及在Pairing Request和Pairing Response消息中两者共享的数据。 对于Central设备而言，其产生的随机数是LP_RAND_I，计算出来的confirm value是LP_CONFIRM_I；对于Peripheral设备而言，其产生的随机数是LP_RAND_R，计算出来的confirm value是LP_CONFIRM_R。在两端参与计算的函数都是c1，计算参数除了LP_CONFIRM_I和LP_CONFIRM_R以外都是相同的，因此各自计算出来的LP_CONFIRM_I和LP_CONFIRM_R是不同的。 !1734603029013.png 然后Central设备把自己计算出来的confirm value也就是LP_CONFIRM_I发给Peripheral设备，Peripheral设备则把自己计算出来的LP_CONFIRM_R发送给Central设备。 Central设备收到Peripheral设备发过来的LP_CONFIRM_R以后，就把自己进行c1运算的随机数LP_RAND_I再发给Peripheral设备。此时Peripheral设备就同时有了Central设备的LP_RAND_I和LP_CONFIRM_I，然后Peripheral设备就会使用自己的TK以及收到的LP_RAND_I再进行以此c1运算，把计算结果与收到的LP_CONFIRM_I进行比较，如果两者匹配的话，对于Peripheral设备而言就可以确认它们两端参与c1运算的TK是相同的。此时Peripheral设备就完成了对Central设备身份的认证。 然后接下来同样的逻辑，Peripheral设备把自己的随机数LP_RAND_R发送给Central设备，此时Central设备就有了计算LP_CONFIRM_R的所有信息，同样执行一遍新的c1运算，把计算结果与之前收到的LP_CONFIRM_R进行比较。如果匹配的话，对于Central设备而言，它就可以清楚的知道自己的TK与Peripheral设备的TK是相同的。此时就是完成了Central设备对Peripheral设备身份的认证。 至此以上就通过确认双方的TK是一样的，Central设备和Peripheral设备之间完成了相互之间的身份认证，确定对方就是自己要进行配对和绑定的设备。当然因为Just Works模式下双方的TK是全0，这个身份确认是没有任何意义的，所以Just Works模式实际上没有配对设备的身份认证流程，无法应对中间人攻击MITM。只不过Just Works模式通过以上流程在两端传输了两个随机数LP_RAND_R和LP_RAND_I，这两个随机数要在后面生成STK的时候使用。 下图就是两个设备之间进行身份认证的完整通信和判断逻辑： !1734604490831.png 生成STK密钥 接下来就是生成用于在配对流程中对通信链路进行加密的128bit短期密钥STK。STK的生成需要用到一个s1函数。 STK = s1(TK, LP_RAND_R, LP_RAND_I) 从以上s1函数的参数来看，TK，LP_RAND_R和LP_RAND_I全部在前一个设备之间相互认证的环节中已经双向传输了。因此对于两个设备而言，就可以分别使用s1函数来计算STK。 - 对于两端STK的计算而言，s1函数是一样的，两端共享的TK，LP_RAND_R和LP_RAND_I这三个参数也是一样的，那么其计算结果STK肯定就是一样的。 - 而从传输安全的角度看，LP_RAND_R和LP_RAND_I这两个随机数是在设备认证阶段的未加密链路中传输的，存在泄露的风险。但是对于OOB和Passkey两种模式而言，TK是使用OOB和Passkey传输和确认过的，根本就没有通过BLE链路传输，因此不存在泄露的风险，那么TK没有泄露的情况下STK的计算肯定就是安全的。 - 只不过对于Just Works模式而言，TK是全0，LP_RAND_R和LP_RAND_I这两个随机数是在设备认证阶段的未加密链路中传输的，所以STK仍然存在有泄露的风险。 至此，Central设备和Peripheral设备就都有了可以用于对配对通信链路进行加密的STK密钥，后续配对流程的第三阶段就可以基于STK密钥来实现对配对流程的加密保护了。 --- 配对流程阶段二：配对流程加密链路的建立LE Security Pairing 与LE Legacy Pairing迥异的是，LE Security Connections模式下采用了公私钥体系来实现对配对流程通信链路加密密钥的传递：该模式下会使用公私钥体系来生成和交换一个长期密钥LTK（Long Term Key），这个LTK不光用于配对流程第三阶段的通信链路进行加密，还会保存起来用于后续连接状态下数据通道的加密。 如前所述，大体的执行流程方面，LE Security Connections也分为三个大的阶段，其中第一阶段和第三阶段与LE Legacy Pairing没有区别，两者的区别主要就是体现在这个第二阶段，而且执行流程上的差异还很大，就一定要完整的分开来进行描述。 LE Security Connections模式第二阶段的总体流程如下图所示。 !1734656427648.png 当配对流程使用LE Security Connections模式时，根据第一阶段Pairing Request和Pairing Response双方的协商，可以使用全部四种Association Model：Just Works，Numerical Comparison，Passkey Entry以及OOB。比LE Legacy Pairing多了一个Numerical Comparison。 LE Security Connections模式的第二阶段主要可以分为四个步骤。 公钥交换 LE Security Connections模式的第二阶段首先由配对流程的发起方Initiator（也就是发出Pairing Request的那一方，即Central设备）发起流程。Initiator向Responder（也就是在第一阶段发出Pairing Response的那一方，即Peripheral设备）发出自己的公钥PKa，Responser则向Initiator发回自己的公钥PKb。至此通信双方都有了对方的公钥。 PKa和PKb都是在未加密的链路上传输的，但因为是公钥，所以对于安全性来讲没有威胁。 计算DHKey 下一步两个设备各自基于蓝牙规范中定义的P256算法生成一个DHKey。 - Initiator设备：DHKey=P256（SKa，PKb）。SKa是Initiator设备的私钥，PKb是Responder设备的公钥。 - Responder设备：DHKey=P256（SKb，PKa）。SKb是Responder设备的私钥，PKa是Initiator设备的公钥。 也就是说，对于通信双方而言，这个P256算法的输入参数都是自己的私钥和对方的公钥。经过P256算法的巧妙设计，两端使用自己的私钥和对方的公钥计算出来的DHKey是相同的，也就是说，此时通信双方就计算出来一个相同的DHKey。 尽管PKa和PKb此前是在未加密的链路上以明文传输的，但是两个设备的私钥SKa和SKb只保存在自己设备内部，所以DHKey的计算就是安全的。 设备硬件身份认证 设备身份认证这一步的具体执行，就跟前面根据双方IO能力所协商出来的Association Model相关。可选的Association Model包括Just Works，Numerical Comparison，Passkey Entry以及OOB这四种。这一步的目的就是要确认进行配对的设备的身份的正确性，当然，Just Works因为缺少必要的身份认证手段，在LE Security Connections模式实际上仍然是不具备设备身份认证的能力，只是走一遍流程而已。 为方便描述整个身份认证环节的执行流程，以下统一把配对流程的发起方Initiator称为Device A，把Responder称为Device B。 设备身份认证之JW/NC Device B产生一个128bit的随机数Nb，然后以这个Nb还有两个设备的公钥（在公钥交换步骤已经拿到）作为参数，使用蓝牙规范所定义的f4算法计算出来一个confirm value B即Cb： - Cb=f4（PKa，PKb，Nb，0） 然后Device B把计算出来的这个Cb发送给Device A。（此时Device A还不知道Nb） 下一步Device A生成自己的128bit随机数Na，然后把这个随机数发给Device B，Device B则向Device A返回自己之前生成的随机数Nb。现在Device A就有了所有用于计算Cb的参数，因此Device A基于收到的Nb重新执行一次f4算法，把自己计算的confirm value结果与前面收到的Cb相比较。如果两者一致的话（双方一致就说明前面阶段在双方之间共享的PKa和PKb信息是相同的）就继续往下走，否则就退出配对流程。 到了这个阶段，实际上对于Just Works模式而言，设备身份认证的环节就结束了。这部分后面的步骤只是针对NC模式的。可以看到，上面的步骤只是通信双方生成并交换了随机数，并确认了双方持有的公钥信息的正确性，实际上并没有办法确认对方硬件身份的合法性。 现在两个设备都确认过了双方的公钥PKa和PKb，以及双方所产生的随机数Na和Nb，那么接下来双方都通过蓝牙规范所定义的g2函数，以（PKa，PKb，Na，Nb）为参数计算出来自己的Confirm value，并且显示在自己的屏幕上。因为g2函数以及以上的四个参数都是相同的，所以双方计算和显示出来的confirm value肯定是相同的。 接下来就需要用户检查两个屏幕上显示的六位数字是否相同，如果相同的话通过按键操作确认，这样就保证了进行配对操作的两个设备之间的身份的合法性和正确性。 !385bc5cf-7ede-460e-8cdd-c2975b2c27ae.png 设备身份认证之Passkey Entry 对于Passkey Entry而言，默认的标准使用流程是需要进行配对的两个设备，一端有显示屏用于显示配对数字，另外一端有键盘输入这个数字以确认双方配对的硬件身份。而在LE Secure Connections模式下，Passkey Entry也能够支持两端都没有显示屏，但是都有键盘的使用场景，此时在两端配对的过程中通过键盘输入相同的数字来辅助进行设备认证。 接下来的身份认证阶段的运算流程比较复杂，基于两端匹配的6位数字的每一个bit，要进行20次（6位十进制数字最高是999999，对应于十六进制的0xF423F，因此总共最多有20位）反复的迭代运算和比较。 整个迭代比较的流程如下： !image.png - 2a和2b步骤就是在device A和device B上输入相同的配对数字，是一个六位数字，输入正确的情况下两者应该是相同的。然后在A和B两端分别把这个数字ra和rb按照二进制进行分解，分解为20个bit，后续的每一轮迭代计算用到其中一个bit。每个bit的命名就是rai和rbi，i表示第几次迭代。 - 3a和3b步骤分别在A和B两端各自产生一个128bit的随机数Na和Nb。每一轮迭代都产生新的随机数，所以每一轮的随机数就是Nai和Nbi。 - 4a和4b步骤分别在A和B两端使用蓝牙规范定义的f4算法，以两者前面阶段已经交换的公钥PKa和PKb，各自产生的随机数Na/Nb，以及本次迭代的验证数字的这一个bit位rai/rbi参数进行计算，在两端分别计算得到这一轮的Confirm Value，也就是Cai和Cbi。 - 5-8这几步就是在两端分别交换各自这一轮产生的随机数Nai和Nbi，各自计算出来的Cai和Cbi，然后在两边交叉计算后进行比较验证两端计算出来的confirm value是否一致。 - 第8步骤在计算出来的confirm value匹配的情况下，进行下一轮迭代，选择配对数字ra/rb的下一个bit重新执行3-8这几个步骤，直到所有的bit全部验证通过。 经过以上非常繁琐的运算和判断的过程，两个设备上输出的六位数配对数字更是被拆解为bit进入运算，即使在配对的流程中使用MITM中间人攻击对配对流程的数据交互进行监听，也大大增加了破解的难度，因此安全性方面比LE Legacy Pairing要好很多。 设备身份认证之OOB 与LE Legacy Pairing过程的OOB模式类似，LE Security Connections流程下OOB模式也需要通过非蓝牙通信以外的带外通信方式（NFC、二维码等）辅助进行设备硬件身份认证流程执行中部分信息的传输，只不过两者的执行流程差异极大。 下图是LE Security Connections流程下OOB模式的身份认证通信流程： !image.png - 首先两者各自产生一个随机数ra和rb，然后各自使用f4算法，以自己的公钥和产生的随机数作为参数计算出来各自的confirm value也就是Ca和Cb。 - 然后通过蓝牙之外的带外通信能力，把自己用于配对通信流程的随机蓝牙地址BD_ADDR_A/BD_ADDR_B，两端产生的随机数ra/rb，以及两端各自计算出来的confirm value Ca/Cb传递给对端。 - 两端分别基于OOB信道传递过来的信息重新以f4算法，使用对方的公钥和对方产生的随机数，再计算出来一个confirm value，对这个confirm value和对方通过OOB传过来的Ca/Cb进行对比是否一致。如果一致的话表示双方的硬件身份认证成功。 - 最后就是双方各自产生一个新的随机数Na和Nb，并传递给对方，用于在下一阶段生成长期密钥LTK。 LTK的生成和校验 接下来就是在两端各自计算LTK。为了确保前面所有的环节都是正确的，以及确保两端计算的LTK是一致的，还需要通过另外一个MacKey来执行这个验证和确认的环节。 对于LTK和MacKey的计算而言，需要用到蓝牙规范中定义的f5算法。这个算法的输入参数包括DHKey，两端生成的随机数Na和Nb，以及两端在配对过程中所使用的蓝牙MAC地址BD_ADDR_C和BD_ADDR_P。 MacKey || LTK = f5(DHKey, Na，Nb, BD_ADDR_C, BD_ADDR_P) - 经过前面所有的环节，DHKey，随机数Na和Nb，蓝牙MAC地址BD_ADDR_C和BD_ADDR_P这几个值两端都已经知道了，所以就可以分别使用f5函数来独立的计算出来MacKey和LTK。如果没有出现意外的话，两端计算出来的LTK和MacKey应该是一样的。 至此后续用于对数据连接链路加密的长期密钥LTK就诞生了。那么怎么保证两端生成的这个LTK是一致的呢？此时还要再对MacKey进行一次校验，如果MacKey相同的话，LTK也就没问题了。 MacKey验证的过程依赖于蓝牙规范定义的f6算法，参数是两端各自计算出来的MacKey，两端之前阶段交换的随机数Na和Nb，两端在配对过程中交换的IOCap信息（包含在Pairing Request和Pairing Response信息中），两端在配对过程中所使用的蓝牙MAC地址BD_ADDR_C和BD_ADDR_P。 MacKey验证的逻辑流程如下： - Initiator按照f6算法计算出来自己的校验值EA，Responder按照6算法计算出来自己的校验值EB。注意两个计算的参数稍有差异，一个是IoCapA一个是IoCapB，所以EA和EB应该是不同的。 - Initiator把自己计算出来的EA发给Responder，Responder在自己这边重新按照与Initiator计算EA一样的参数和算法计算出来自己这边的EA，比较两个EA是否一致。如果一致的话，Responder就清楚的了解两端的MacKey和LTK是一致的。 - 相同的逻辑，Responder把自己计算出来的EB发给Initiator，Initiator在自己这边重新按照与Responder计算EB一样的参数和算法计算出来自己这边的EB，比较两个EB是否一致。如果一致的话，Initiator就清楚的了解两端的MacKey和LTK是一致的。 - 至此，Initiator和Responder就通过以上流程确认了两端MacKey和LTK的一致性。 可配合下图来完整理解LTK的生成和验证的逻辑： !image.png 下一步就可以使用两端生成并且确认过的LTK对通信链路进行加密保护进入配对流程的第三阶段了。 --- 配对流程阶段三： 到了第三阶段，就是基于第二阶段所生成的STK密钥（LE Legacy Pairing）或者LTK密钥（LE Secure Connections）对通信链路进行保护，后续配对流程的通信就全部是加密的了。 而第三阶段的主要作用也就是按照第一阶段双方在Pairing Request和Pairing Response消息中协商的要分享哪几个密钥（LTK, CSRK, IRK），密钥的长度，各个密钥由哪一端来分发等信息来安排好对于密钥分发的流程，最终的目的就是在两端同步后续进行数据通信的真正密钥。配对流程结束以后，短期密钥STK也就被废弃了（对于LE Legacy Pairing模式而言）。 - LTK, CSRK, IRK这三个才是两个设备之间后续数据通信过程中真正的通信密钥。 - 对于LE Security Connections模式而言，因为LTK在第二阶段已经交换过了，所以第三阶段就只需要通过加密连接在双方之间传输CSRK和IRK就好了。对于LE Legacy Pairing模式则需要在第三阶段的加密连接中传输上面的三个密钥。 以上在两端共享的密钥只会用于本次连接的后续通信，不会自动保存。下一次两个设备如何还要建立连接进行通信的话，那么就要按照以上配对流程完整的重新走一次以交换新的连接通信密钥。这样的话，看起来整个过程就太繁琐了。因此，如果在配对流程结束以后，把这次在两端共享的通信密钥保存下来，直接用于后续的通信过程，这样就可以省去每次连接都要配对的流程，而把配对密钥第三阶段通过加密连接交换的通信密钥保存起来的动作，就是绑定（Bonding）。经过绑定操作以后，两个设备以后重新连接就可以直接使用之前保存起来的通信密钥了。 - 配对流程结束后是否需要保存密钥（即执行bonding过程），取决于第一阶段Pairing Request和Pairing Response消息中所包含的Bonding Flags标志位。 !image.png 参考资料 - Understanding Bluetooth LE Pairing—Step by Step - Technical Articles - Developer Study Guide: Bluetooth® Low Energy Security V1.2.1 - BLE蓝牙技术详解

BLE设备之间安全密钥总结

BLE安全性保证的三大基础密钥 总的来说，BLE通信连接的安全性是建立在加密通信、签名、随机地址这三大基础之上。 为了保证BLE设备之间在通信过程中的加密通信，主要用到了三种类型的密钥。这三个密钥都是在设备完成配对以后在两个设备之间加密安全传输的。 - Long Term Key (LTK)：用于对加密连接通信情况下的数据进行加密保护。在两个设备的配对过程中产生和交换相同的LTK，配对和绑定流程执行完成后LTK会分别保存在两个设备之中。后续在两个设备的连接状态数据通信过程中，LTK会被用于产生对数据包使用AES-128算法进行加解密的会话密钥，确保连接后在双方之间传输的数据包都是加密的。 - Connection Signature Resolving Key (CSRK)：用于对非加密连接情况下的数据收发进行完整性和身份真实性的验证。在通信链路不使用加密机制的情况下，BLE通过数据签名机制来保证收到数据包的完整性和真实性。通过给每个数据包增加签名，确定这个数据包是完整的（没有被修改过），并且是由自己信任的通信对端（与自己配对过的设备）发过来的。CSRK密钥就用于这个数据签名的流程中，BLE连接通信的过程中，每个要发出的数据包，会使用CSRK密钥对这个数据包签名，然后把数据包和签名一起发给对方。对方收到以后对收到的数据包的内容使用系统的签名算法逻辑和CSRK密钥再进行一次运算，然后比较自己计算到的签名值与收到的签名值是否匹配。两个签名匹配的情况下，表示这个数据包是完整的，并且确实是由自己信任的通信对端发过来的。 - Identity Resolving Key (IRK)：用于对蓝牙外设设备的蓝牙MAC地址进行保护。针对恶意攻击者利用设备的蓝牙地址来尝试持续长时间跟踪用户蓝牙设备通信所存在的安全性隐患，BLE规范引入了一种Resolvable Private Addresses的随机地址对用户设备的真实蓝牙地址进行保护。蓝牙外设设备在运行过程中定期（默认为15min）使用这个128位的IRK产生一个随机蓝牙地址，与其他设备之间的通信空中包中使用这个随机MAC地址进行通信，而只有与这个蓝牙外设设备之前完成配对和绑定流程的蓝牙设备才能够从这个随机地址中解析出来外设蓝牙设备的真实地址，这样的话无论是广播还是连接状态下，外设蓝牙设备的MAC地址就总是处于周期性的变化之中，通过这个措施来实现对蓝牙通信过程中非授权跟踪和攻击的保护。 The Long Term Key ( LTK) !image.png 在BLE连接建立以后，BLE连接的通信双方会使用AES128加密算法对所有的通信包数据进行加解密。AES128算法的密钥基于LTK和双方本次建立连接时协商的随机数生成，因此每次连接通信所使用的AES加密key都是不一样的。 - 基于LTK生成临时密钥。在连接建立的过程种，通信双方会产生并交换一个随机数，使用这个随机数与两端各自在配对时保存的LTK配合生成一个随机密钥，用于本次后续连接中双方通信的加解密密钥。每次连接建立时所产生的随机数都是不同的，因此每次连接所使用的加解密密钥也就不同。这个密钥可以称之为是这次连接的Session Key。 - 加密数据。以上步骤生成Session Key以后，这次连接后续的相互通信都使用AES-CCM配合这个Session Key进行加解密操作。AES-CCM算法对数据包进行加密的过程中，同时还会生成这个包的四字节长度的消息完整性检查码MIC。然后把加密后的数据包及其MIC一起发给通信对端，来确保BLE通信数据的机密性和完整性。 - 解密数据。通信对端收到密文数据以后，使用相同的Session和AES算法进行解密得到明文，同时通过对这个数据包的MIC进行匹配比较，确认一致的情况下才表示收到了完整未被篡改的数据信息。 The Connection Signature Resolving Key (CSRK) 需要注意的是，BLE连接模式下的通信，并非所有的数据都要进行加密传输，对于一些安全级别不高的数据和应用场景的情况下（例如一些非敏感的传感器数据），也可以直接传输明文数据。但需要在通信双方之间确保传输的数据是由自己信任的通信对端所传输的。在这种情况下，就要使用CSRK来确保双方通信数据的完整性及发送者身份的合法性。 BLE使用签名机制来实现以上两部分功能。具体的实现上，BLE的签名机制实现和运行依赖于CSRK和一个用于防止重放攻击的累进计数器。 !image.png 具体的实现上，BLE采用AES-CMAC算法来生成消息明文的消息验证码MAC（ Message Authentication Code）。这个MAC可以同时为数据包提供完整性和验真性两方面的确认功能。 对于AES-CMAC这个签名算法而言，需要有三个输入： - 要进行签名计算的消息明文，可以是任意长度。 - CSRK密钥，128bit长度。 - SignCounter，一个32bit的累加计数器，每进行一次签名运算累加一次。 AES-CMAC运算的结果，就是这个明文消息的消息验证码MAC，MAC的长度是固定的。在BLE通信时，消息验证码、明文数据包以及MAC计数器SignCounter一起会被发到通信对端。 通信对端收到以后，把消息明文、SignCounter和MAC码分开（SignCounter和MAC的长度都是固定的），然后对明文使用相同的逻辑进行计算，得到自己计算出来的MAC码。然后比较两个MAC码，如果一致就表示收到的明文消息是完整的，并且确实是由自己所信任的通信对端发过来的。 此外，接收端还会去比较自己新收到的SignCounter以及上次计算所使用的SignCounter，如果新的SignCounter大于之前运行所使用的SignCounter（因为发送端的SignCounter每次运算都会累加1），表示这个消息进行MAC计算的SignCounter是合法的，否则就是非法的，以此来应对重放攻击。 The Identity Resolving Key (IRK) IRK也是两个BLE设备在配对过程中在配对双方之间共享的密钥，用于解析后续通信中所使用的蓝牙随机MAC地址，以避免恶意攻击者持续监听某个固定蓝牙MAC地址的通信。 BLE外设设备每隔一段时间会基于IRK生成一个新的随机MAC地址。具体的生成步骤和逻辑是，BLE外设设备先生成一个22bit随机数prand，这个随机数和配对过程中双方交换和保存的IRK密钥一起被用于产生一个可解析的随机私有地址RPA（Resolvable Private Address）。IRK的长度固定为128bit，随机数prand的固定长度为22bit，RPA的计算以IRK和prand为输入，计算算法使用蓝牙规范中定义的ah哈希算法： - _hash = ah (IRK, prand)_, truncated to 24 bits 以上Hash计算的结果会被截断为24bit长度，然后与22bit的随机数prand、最高位的0b01（BLE MAC最高位为0b01表示这个地址是一个可解析私有地址）一起构成随机MAC地址RPA： !image.png - 这个可解析私有地址包含了两方面的信息，prand以及ah算法计算出来的hash值。 那么当包含这个RPA随机地址的数据包被Master设备收到的时候，就需要对其中包含的RPA进行解析，从中解析出来真正的外设MAC地址。如果解析失败，就说明这个数据包不是给自己的，直接丢弃就好了。 两个BLE设备进行配对时，双方都要交换一系列密钥，其中就包含外设设备的IRK密钥，这个外设真实的固定BLE MAC地址等信息。因此每个配对后的BLE设备都会维护一个地址解析表，包含有配对设备的IRK以及真实固定BLE MAC地址等信息。 !6782a46a-db27-49b7-8c83-19f3fdb22f06.png BLE Master设备接收到数据包以后，如果这个包中包含的MAC地址是可解析私有地址类型（最高两个bit为0b01），就按照下面的流程确认这个包的发包设备的IRK信息是否包含在以上的解析表中，及其对应的真实BLE MAC地址是多少： !76496ea7-d40b-4ce6-80cf-d4b2694aaf32.png - 收到数据包的BLE设备，从数据包中取出其中包含的RPA可解析地址，分为两个部分，hash value和prand，然后从地址解析表中取出一个Peer IRK，使用相同的ah哈希算法计算（IRK，prand）的哈希值，然后与hash value相匹配。如果不匹配，就继续使用地址解析表中下一个表项里面的Peer IRK继续进行相同的计算和匹配比较，直到找到两个hash value匹配为止，然后就可以从这个表项中找到与其对应的真实BLE MAC地址（即Peer Device Identity Address）。如果轮询整个地址解析表，没有找到与之匹配的Peer IPK，那么就表示这两个设备之前没有配对过。这个数据包不是发给自己的，因此丢弃即可。 RPA的定时更新 为了对BLE外设设备的安全性和隐私进行更严密的保护，除了以上对其BLE MAC地址进行随机数加密以外，这个BLE设备还会定时更新其RPA随机地址，避免随机地址使用时间过长的情况下被攻击者持续跟踪。 RPA随机地址的可用时长在BLE controller的_HCI_LE_Set_Resolvable_Private_Address_Timeout_ 命令中进行设置，可设置的时间范围在1s到11.5小时之间，超时后连接层就需要重新生成随机数并更新使用新的RPA通信地址。 BT规范中建议使用的RPA更新时间是15min。 参考资料 - Understanding Security Keys in Bluetooth Low Energy - Technical Articles - BLE 配对加密相关问题分享_ble安全等级 模式-CSDN博客

BLE的跳频机制和流程实现详细总结

Connection Event与Connection Interval 对于BLE跳频机制工作流程的理解，首先要从理解connection event和connection interval的概念开始。因为BLE设备建立连接后的通信是以connection event为单位进行跳频操作的。 两个BLE设备建立连接以后，设备之间的通信时间就会被按照connection interval分割为一个个独立的connection event。 具体的connection interval参数在两个BLE设备建立连接时的request connection参数中进行协商，理论上这个时间周期在7.5ms到4s之间，以1.25ms为步进单位。 在每个connection event，总是由master（也就是central设备）发起。master向slave（也就是Peripheral设备）发出一个数据包，slave再向master发回一个响应包。 下图就演示了在每个connection event中，central设备和Peripheral设备进行空包交互（即使没有数据通信需求，也需要收发一个空包来维持连接）、central设备发出数据、central设备从Peripheral设备读取数据以及Central设备和Peripheral设备相互收发数据的示意图。 !image.png - 如果双方之间的第一次通信交互之后还有更多的通信数据要收发，master就再向slave发出一个数据包，slave再发回响应包，如此循环往复。因此一个connection event中可以传输多个BLE包，但不同的BLE硬件设备和操作系统对于一个connection event中能够传输的BLE包的最大个数有不同的规定。因此，如果两个设备之间有很多的数据要收发的话，需要按照顺序把这些数据分割到多个connection event中进行通信。 - 在每个connection event之内，每次通信交互都由Central设备发出一个数据包，然后Peripheral设备返回一个应答包。当一个connection event中有多个包要收发时，两端收发的流程也始终是以Central-Peripheral-Central-Peripheral-…这样的顺序来循环往复。那么当Central设备没有数据要发送、Peripheral未能收到Central所发出的数据包、Peripheral因为各种原因未能发回响应包、Central设备没有收到Peripheral所发回的响应包等情况发生，当前connection event中两个BLE设备的通信中断，两个设备的TX和RX均关闭以降低功耗，等到下一个connection event周期再重新重新。 - 即使BLE通信的两个设备之间当前没有数据要收发，也要在每个connection event的开头对传一个空包用于同步两者之间的通信时钟。 BLE设备建立连接后的通信是以connection event为单位进行跳频操作的，也就是说在每个独立的connection event中，Central设备和Peripheral设备始终维持在同一个BLE信道中进行交互通信，等到了下一个connection event所在的时间周期，两个设备都同时切换到下一个信道来进行下一个connection interval时间周期内的通信。 而connection interval参数，以及两者每个connection event结束后如何选择和切换到一个新的BLE信道的工作逻辑，则在两个设备在建立连接时的连接参数中进行协商。 BLE连接建立的参数 BLE连接的建立总是从Central设备向Peripheral设备发起一个连接请求包开始。 在广播模式下，Peripheral设备定时、循环在37，38，39这三个广播信道上发出广播包，每次发出广播包以后打开RX监听信道一段时间，然后切换到下一个信道继续进行广播。Central设备建立连接之前，必须先在广播信道对广播包进行监听，在接收到要连接的Peripheral设备发出的广播包时，向Peripheral设备发出connection request尝试建立连接。 !62981bb7-688f-4fbd-ac50-482c7297f887.png 两个设备在尝试建立连接的connection process过程中，会对连接后的通信连接参数进行协商。以下对连接参数中与跳频机制以及通信两端收发包的逻辑相关的参数进行总结和解释： Connection Interval connection interval在前一部分已经做了详细的解释。就是BLE连接成功建立以后，Central设备和Peripheral设备之间通信的connection event的周期时间长度。 也就是说，在BLE连接通信的过程中，连接通信的双方每隔connection interval时间唤醒一次，在两者之间收发几个数据包以后重新进入休眠状态，等到下一个connection interval周期的到来。这样的情况下，绝大多数时间中通信设备的TX和RX都处于休眠状态，以此来实现低功耗的功能特性。 Supervision Timeout BLE连接通信建立过程中还会协商一个supervision timeout的时间参数，这个参数定义了双方之间的通信超时的判断条件。对于Central设备和Peripheral设备，当距离其成功接收到对端最后一个数据包的时间长度超过supervision timeout所制定的时长时，就会认为当前连接已经断开，下次通信就需要重新扫描广播包和建立连接。 supervision timeout参数就是用于Central设备和Peripheral设备任意一端的通信发生异常（如运行崩溃，没电了，走出信号覆盖范围之外）的情况下，两者能够从通信的故障状态中恢复出来。 Peripheral latency 按照以上所描述的connection event，即使没有数据要收发的情况下，Central设备和Peripheral设备之间也需要在每个connection event开始的时候，由Central发起进行一次空包的交互。但是如果两个设备之间长期没有数据要收发，而每次connection event都要进行一次空包交互的话，对于BLE的省电特性会有很大的影响。 因此，在Central设备和Peripheral设备建立连接的时候，双方之间也会协商一个peripheral latency的参数。这个参数用于指定在Peripheral设备没有数据要发给Central的时候，最多可以在多少个connection event不需要等待接收和应答来自Central设备的空包数据。在设置peripheral latency参数的情况下，Peripheral设备在没有数据要发出的情况下，就不需要每次connection event中都去监听和响应来自Central的数据包，只需要每隔几个connection event给Central的发出一个应答包就可以维持双方之间的通信连接（当然这个时间不能超过前面介绍的supervision timeout的时间长度）。 peripheral latency参数对于Peripheral设备而言，因为不需要每次connection event都去唤醒接收和应答数据包，因此低功耗和省电的特性更好，但是毫无疑问的会劣化通信的实时性表现。如果Central设备有数据要发给Peripheral的话，必须要等到每个peripheral latency指定的connection event通信周期内，Peripheral设备才有机会接收这个数据并响应。因此这个参数的具体设置，需要在省电和实时响应之间做出一定的取舍。 Channel Map Channel Map信息在BLE连接建立时所协商的连接请求包中占据5个字节，这5个字节中的每一个bit代表一个BLE信道的好坏状态，因此Channel Map就是在Central设备和Peripheral设备之间共享当前无线环境下40个BLE通信信道的好坏状态列表，由此来决定后续BLE连接建立后跳频算法可用的通信信道。 Channel Map的每一个bit用于标记这个信道的可用状态，used表示这个信道可以被用于后续的通信中，unused表示这个信道不应该被用于后续通信之中。 Hop Increment Hop Increment是BLE连接建立时，通信双方所协商的一个随机数值，取值范围在5-16之间。 Hop Increment用于BLE的跳频信道选择算法，Central设备和Peripheral设备使用相同的跳频信道选择算法、Hop Increment参数以及Channel Map独立计算出来每个connection event应该使用的BLE通信信道。因为信道选择算法、Hop Increment以及Channel Map对于两者都是一样的，所以Central设备和Peripheral设备在后续连接后每个connection event所选择的信道肯定都是一致的，否则就没法稳定通信了。 BLE连接跳频通信的信道选择逻辑 如上所述，在BLE连接建立以后，两个设备之间就以之前协商好的Connection Interval为周期进行不同的通信信道之间跳频操作。每个Connection Interval通信周期都使用不同的信道进行通信，避免2.4GHz频段下复杂的无线干扰对于通信稳定性的影响。 设备之间在各个信道之间的跳频算法：unmappedChannel = (lastUnmappedChannel + hopIncrement) mod 37。 lastUnmappedChannel 是当前Connection Event周期中两个设备所使用的信号编号；hopIncrement是两者在建立连接时协商出来的跳频步进参数，其取值在5-16之间；unmappedChannel 就表示下一个Connection Event两者通信应该使用的信号。 !image.png 考虑到2.4GHz频段上运行的各种RF通信应用五花八门，这个频段的存在严重的干扰问题，部分信道可能会因为与当前环境中存在的路由器工作频段相重叠，如果BLE通信建立后也在这些信道通信的话，势必会产生严重的无线信号冲突的问题，因此。BLE跳频算法还提供了一个Channel Map的机制对于当前环境中可用的BLE信道进一步筛选。Channel Map参数在BLE连接建立的过程中在两个设备之间同步，用5个字节的长度标记BLE所有通信信道的可用情况。 按照以上的跳频算法所计算出来的通信信道，如果被Channel Map参数标记为可用信道，则下一次connection event就使用这个信道进行通信。而如果跳频算法计算出来的下一跳信道被Channel Map参数标记为不可用，则还要按照下面的信道重映射逻辑进行更进一步的处理。 不可用信道的重映射算法：remappingIndex = unmappedChannel mod numUsedChannels。 在这个重映射算法中，unmappedChannel 是重映射之前的信道编号，实际上也就是跳频算法所计算出来，但是被Channel Map标记为不可用状态的信道编号；numUsedChannels是Channel Map中所有处于可用状态的信道的数量；remappingIndex 就是重映射以后的信道编号。那么接下来，真正会被下一个connection event用于通信的信道编号，就是使用remappingIndex 从channel map中所有可用信道列表中找到的那个通信信道。 整个BLE模式下通信信道跳频的计算逻辑如下图所示： !image.png 广播信道下的跳频 为了应对2.4GHz频段所存在的复杂通信环境，BLE在广播模式下的通信同样使用了跳频通信的机制。BLE的40个信道之中，其中最后的三个信道37，38，39就这三个信道就专门用于广播模式下的通信，用两个设备之间的自动发现、辅助建立连接以及Beacon模式等的通信。 如上所述，在广播模式下，Peripheral设备会定时、循环在37，38，39这三个广播信道上发出广播包。在这三个广播信道上跳频广播，以及这三个广播信道的频点的选择就很有讲究了。如下图所示，三个广播信道的频点分别对应于2402MHz，2426MHz，2480MHz，刚好完美的避开了最常用的三个互不混叠的wifi信道1，6，11所在的频谱空间，这样就可以最大限度上避免WiFi信道上的通信对于三个广播信道所造成的干扰。 !image.png 参考资料 - Bluetooth® Low Energy Channels - Developer Help - Ultimate Guide to Managing Your BLE Connection | Punch Through - Connection process - Nordic Developer Academy - BLE链路层信道选择算法浅析 - 浮生问道 - 博客园 - 蓝牙跳频算法分析【经典蓝牙 vs BLE 4.x vs BT 5.0 BLE部分】_ble跳频算法2-CSDN博客

对广芯微车钥匙PKE方案的深入学习总结

之前在另外一片笔记中，我对目前汽车电子领域中的主流无钥匙进入解决方案（RKE/PKE/PEPS）进行了总结，在本文中重点针对国产广芯微电子所推出的一整套PKE解决方案的完整工作原理进行更细致的描述，增强对PKE技术实现的更深入理解。 广芯微电子的PKE完整方案 所有的无钥匙进入方案大致都是如此，分为两个部分，钥匙端和安装在车辆（既包括汽车，也包括两轮电动车）内部的基站端。总体来讲，钥匙端因为使用纽扣电池供电，所以对各种应用场景下的功耗极其敏感；而基站端是提前安装到车辆内部，是由车辆的蓄电池供电，这一点是整个方案设计的基础。否则如果不考虑钥匙端功耗的话，整个方案完全可以大幅度简化。例如手机上的蓝牙车钥匙功能，不需要考虑手机端的蓝牙功耗，那么只需要通过蓝牙或者NFC就可以实现这个无钥匙进入系统了，系统设计更简单，通信的安全性还更好，但是蓝牙的功耗是纽扣电池供电的PKE钥匙端无法承受的，所以采用了这样的RFID LF+433MHz HF通信的模式。 !1733557146591.png 从通信的角度上，钥匙端和基站端都有低频LF和高频HF两个部分，其中LF部分一般采用RFID的125KHz，HF则可以采用433MHz或者2.4GHz进行通信。 - 基站端通过LF向外发出信号，LF没有接收功能；通过HF等待接收钥匙端的信号，没有发送HF信号的功能。 - 钥匙端刚好相反，通过LF接收信号，但是不具备LF发送信号的功能；而需要向车辆发送的控制信号则从钥匙端的HF发射器发出，钥匙端的HF部分没有接收功能。 其实对于通信的HF部分，绝大多数情况下两端的HF实际上都处于sleep的状态。只需要在被唤醒的时候打开TX或者RX进行通信即可。所以HF的技术选型并不是很重要，例如在以上的架构图中既可以选用Sub1G频段的433MHz，也可以使用常用的2.4GHz。为了尽可能降低钥匙端的功耗，HF部分的设计一般是单向的收发关系，钥匙端固定是HF的发射器，通过这个发射器向基站端发出车门的控制指令；而基站端是固定的HF接收器，固定的接收来自钥匙端的控制信号。既然是这种单向的收发关系，应对中继攻击、中间人攻击这类破解手段就难以有合理的技术手段，因此这样的方式其实是存在一定的安全性隐患。如果HF设计为双向通信，通信的安全性方面倒是可以有效的改善，但是通信过程中两端HF的TX和RX要始终保持打开的状态，这对于低功耗设计尤其是纽扣电池供电的钥匙端无疑是一个非常大的挑战。因此这种HF端的单向收发算是在安全性和功耗方面的一个折衷设计。 HF端通信的逻辑相对比较简单，就是钥匙端在被唤醒（LF RFID扫描唤醒或者钥匙端的按键唤醒）时通过HF发射器向基站端发出一条指令即可。因此整个系统设计方案的关键实际上在于LF部分。 基站的LF发射流程 基站端的LF部分的电路包括MCU和一个125KHz信号的发射器UM12020D。 广芯微的UM12020D 用于驱动125KHz低频天线，峰值输出电流 5A，连续输出电流可达 3A，最高工作电压 38V。通过输入端 IN1、IN2 输入 PWM 控制信号，可驱动低频天线。芯片内部集成同步调节电路可以降低PWM控制过程中的功耗。 UM12020D与MCU之间连接的典型参考设计如图所示。 !1733814928976.png - OUT1与OUT2引脚之间连接125KHz的发射天线，IN1和IN2连接MCU端的PWM引脚，nSLEEP引脚连接MCU的GPIO用于控制OUT的输出。 - 使用nSLEEP引脚可控制 LF 驱动芯片 UM12020D 进入工作状态或休眠状态。当驱动芯片处于工作状态，INA、INB引脚的互补 PWM 信号可以驱动 UM12020D 将数字信号转换成模拟信号。当驱动芯片处于休眠状态，即使 INA、INB脚输入互补 PWM 信号，UM12020D 也不会进行模拟信号调制。后续就可以利用这个特性把要发给钥匙端LF的信号调制到125KHz的载波信号中。 MCU向IN1和IN2两个引脚输入两路反向互补的125KHz PWM信号，这个125KHz的PWM周期性信号就是载波。真正要通过载波发送给接收端的实际数据通过控制nSLEEP引脚来发出。 本质上以上的UM12020D电路实际上就是一个ASK调制信号驱动器，具体的使用中在IN1和IN2输入稳定的125KHz PWM作为ASK的载波信号，以nSLEEP信号作为ASK的调制波。实际要发出的数据就包含在调制波信号上。对于ASK调制的原理参考下图就比较清楚了： !image.png - s(t)就是在nSLEEP上输出的调制波信号，载波就是在IN1和IN2上同时输入的反向互补的125KHz的PWM波。 当要通过LF发送给钥匙端的调制波信号是1KHz的情况下，只需要以1ms为单位控制nSLEEP引脚为0或者1即可。 通过nSLEEP引脚向钥匙端发出的LF信号应进行通信数据帧格式的配置。配置用户数据帧中前导码长度、匹配码数据、用户数据等内容，方便在接收端进行解析。 钥匙的LF接收流程 在以上钥匙端的系统设计方案中，主要包含了一个内置125KHz接收功能的UM2082F08的低功耗MCU和一个HF的发射器。广芯微也有一个独立的125KHz Reciver的芯片系列UM2020，因此也可以使用这个独立的125KHz Reciver芯片跟任意的低功耗MCU配合来一起实现UM2082F08的功能。 低功耗MCU的功能相对比较简单，以下以UM2020为例来解释125KHz接收端的工作流程。 UM2020 是一款三通道、超低功耗的 ASK 接收芯片，可检测 30 ~ 300KHz 范围的 LF（低频）载波频率数据并触发唤醒信号，唤醒之后 MCU 可通过 IO 实时采集后续接收到的数据，也可以通过SPI 或 I2C 直接从寄存器读取（最长保存 8 字节数据）。 UM2020基于RFID的125KHz的工作原理工作，整个钥匙端处于深度休眠的状态，当基站端周期性发出125KHz扫描信号时，UM2020的LF接收电路会被唤醒，在UM2020进行初步的数据接收和判断以后，把接收到的数据缓存在UM2020的buffer中，确认是自己的基站端发出的扫描信号的情况下，UM2020会通过其Wake pin唤醒钥匙端的低功耗MCU，低功耗MCU端通过SPI或者I2C引脚读出UM2020缓存的数据信息，进行进一步逻辑判断后，再打开钥匙端的HF模块向基站端发出解锁或者加锁的指令。 因此钥匙端设计整个中心在于其LF接收电路，而LF接收电路的核心则在于UM2020. !1733732316332.png 基于UM2020的电路设计参考图如下： !1733791548441.png - 其中LFP1，LFP2，LFP3连接一个125KHz的三向天线，采用三向天线的原因是对于各个方向的接收感应灵敏度的问题，确保任意方向上都能接收到较好的感应信号。 - MCU和UM2020可以通过SPI或者I2C进行数据端的连接，用于对UM2020进行配置，以及从UM2020的缓存buffer中读取其接收到的数据。 - UM2020通过其Wake引脚在接收到数据后唤醒MCU。 LF的唤醒对码过滤功能 对于以上工作逻辑的理解，存在的两个问题： - 如果所有的车辆都使用类似的125KHz进行类似的扫描的话，这也就意味着每次UM2020都会被唤醒，UM2020再进一步唤醒MCU，那么在一个停车场，很多车辆都同时周期性发出125KHz扫描信号的话，UM2020和MCU被频繁唤醒，对于钥匙端的低功耗是一个非常大的问题。 - 同样的逻辑，如果同时有多个车辆周期性发出125KHz的扫描信号，对于钥匙端而言，如果判断是自己车辆的信号，只有接收到自己车辆信号的时候才会发出解锁信号。 以上两个问题都可以通过UM2020上的对码过滤功能在很大程度上解决。 UM2020的125KHz信号的接收和唤醒流程中有一个对码检测模式。所谓的对码实际上是一个16bit的数据。在LF通信的过程中，基站端周期性发出125KHz的扫描信号，这个扫描信号大致包含载波、对码以及8个字节的数据三部分。钥匙端和基站端可以通过对码数据和8字节数据中的部分数据来验证这个信号是否是自己车辆所发出的信号。不同的地方在于，对码数据的检测和对比直接在UM2020中自动检测，而如果要依赖于8字节数据部分的解析，则需要把MCU唤醒，在MCU的执行逻辑中读取数据并进行解析和判断。 钥匙端会在接收到125KHz载波信号时被唤醒，开始接收对码，当接收到的对码数据与自己内置的对码数据不一致时，UM2020重回监听模式，不去唤醒MCU；而如果对码一致的情况下，则唤醒MCU，在MCU上通过SPI或者I2C读取数据，对读取的数据进行进一步的解析判断，决定该数据是否是自己的数据，以及是否需要通过HF向基站端发出解锁信号。 通过以上所描述的对码检测以对接收数据的解析和判断，就可以解决频繁唤醒带来的功耗问题，以及判断是否是自己车辆所发出信号的问题。 !1733792907719.png 两端的HF通信流程 HF部分的通信逻辑比较简单，完全受LF端接收数据事件的驱动： - 基站端每次周期性的发出125KHz扫描信号后，都会同时把HF的RX打开一段时间，等待接收来自钥匙端的HF信号，如果能够接收到钥匙端发出的信号，表示钥匙就在附近。 - 而钥匙端则在LF部分接收到自己车辆所发出的125KHz扫描信号的情况下，通过MCU控制HF部分向基站的HF接收器发出一条指令，告知基站端自己就在附近。 HF通信的安全性隐患 对于HF端的通信而言，钥匙端是单发功能，基站端是单收功能。这种通信模式没有办法很好的应对中间人的重放攻击。 例如在国外网站上看到的典型偷车案例，钥匙在家里，车辆在户外，本来这个距离的情况下，车辆上的基站信号扫描不到钥匙的位置，钥匙也就不会发出HF信号去控制车门开锁。但是如果一个中间人在家门口使用一个同时有LF收发+HF收发的攻击设备，在这个攻击设备上接收来自基站的125KHz扫描信号，把这个信号的功率放大以后再发射出去，这个信号就会被室内的钥匙端收到，钥匙端检测这个信号来自于自己的车辆，就会通过自己的HF向外发出解锁的信号，这个解锁的信号会被攻击设备的HF接收端捕获，再次放大以后发给车辆基站的HF Receiver，基站就会认为钥匙就在附近从而控制开锁，盗贼就可以堂而皇之的把车门打开。 这个问题对于以上PKE方案几乎无解，根源还是在于，为了尽可能降低功耗，HF通信的设计是单向收发的，通信双方缺乏有效的手段去验证对方身份的合法性。如果采用蓝牙这类双向具备身份认证机制的通信方式，这个问题就可以得到完整的解决。 参考资料： - 广芯微电子PKE 评估开发套件应用手册 - UM2020数据手册 - UM2020用户手册 - UM12020D数据手册 - 5 数字通信之ASK调制解调——理论篇（1）_ask信号-CSDN博客

Nordic nRF54L系列信息汇总

大概在四五月份跟供应链技术支持人员的沟通中了解到，Nordic预计在第三季度会发布新的蓝牙芯片系列nRF54，届时可以申请开发板和SDK。最近几天连续看到Nordic nRF54L这个系列正式发布的信息，因此对相关的资料进行以下学习和整理。 !image.png nRF54L系列规格参数总结 总的来说，nRF54L是之前的nRF52系列的迭代版本，毕竟nRF52作为2015年发布的产品，在消费类电子的应用中已经用了10年，Nordic也亟需要有新的产品系列在处理性能、执行效率、功耗、RF能力以及近几年出现的新的应用场景中提出更好的解决方案。 目前发布的nRF54L系列主要包含三个芯片：nRF54L15，nRF54L10，nRF54L05。这三个芯片除了内包的NVM和RAM空间不同，以及TX Power稍有差异以外，其他方面的配置和支持能力完全相同。 - nRF54L15：NVM 1.5MB，RAM 256KB，TX Power 8dbm - nRF54L10：NVM 1.0MB，RAM 192KB，TX Power 7dbm - nRF54L05：NVM 0.5MB，RAM 96KB，TX Power 7dbm !image.png 与nRF52系列相对比，nRF54L系列的重点参数规格如下： - nRF52系列最高能够支持蓝牙5.3版本，而nRF54L系列则可以支持最新的蓝牙6.0版本。 - nRF52系列内部的CPU核是64MHz的ARM Cortex-M4，而nRF54L系列的CPU核是128MHz的ARM Cortex-M33核心，功耗更低，处理能力更强。 - nRF54L系列使用的ARM Cortex-M4，该CPU核内部可支持TrustZone，因此可集成更高级的安全功能，包括安全启动、安全固件更新、安全存储、由TrustZone支持的可信执行环境等。而nRF52系列受限于Cortex-M4比较老的核心技术，不支持TrustZone，安全性相对较差。 - 在芯片SOC内部架构上最大的不同在于，nRF54L内部增加了一个128MHz RISC-V的协处理器，这个协处理器主要用于运行一些对于实时性要求比较高的任务，与ARM核上所允许的RF处理相关的应用程序任务分开独立运行，可以满足一些对于实时性和无线通信均有较高要求的应用场景。这样的话，针对这类实时性要求较强的应用的设计而言，就不需要额外增加其他MCU了。 - 在2.4GHz无线协议的支持方面，nRF54L系列除了能够支持nRF52也能够支持的低功耗蓝牙、蓝牙 Mesh、Thread、Matter、Zigbee、Amazon Sidewalk、Apple Find My、Google Find My Device 和 2.4 GHz专有协议以外，还能够支持高达 4 Mbps 数据传输速率（使用2.4GHz私有协议的情况下）等增强功能，支持蓝牙 6.0规范，包括蓝牙信道探测(Bluetooth Channel Sounding)等方面的新特性。 - 生产工艺方面，nRF54L系列使用台积电22 nm工艺技术制造，而nRF52系列因为是10年前的产品，仍然采用的是55nm的制造工艺。从55nm到22nm工艺的巨大提升，对于蓝牙产品所需要的低功耗特性非常重要。 - 封装方面，nRF54L系列提供了6 x 6mm的QFN48（31 GPIO）和更小的2.4 x 2.2 mm WLCSP 300um（32 GPIO）两种尺寸的封装。更小的封装尺寸对于该系列在可穿戴产品这类对产品外形尺寸非常敏感的应用中极其重要，以更小封装的WLCSP进行对比，下图是nRF52系列的芯片封装信息，可以看到，nRF54L15的尺寸即使是跟nRF52系列最低端的nRF52805相比仍然要小一些，如果跟nRF52840相比的话，更是要小50%，这一点对于可穿戴产品的设计而言非常重要。 !1733193512667.png 参考资料 - nRF54L15 - Nordic Semiconductor中文官网 - nRF54L15 | nRF54L10 | nRF54L05 Preliminary Datasheet

Apple Find My的Unwanted Tracking Alert功能详细解析

最近因为公司一个新项目的开发需求，开始学习Apple MFI Find My Network的协议文档。 因为是基于BLE的，而且功能也比较简单（主要就是防丢，帮助用户快速找到自己设备的位置），整个协议的工作逻辑还是简单的。但刚开始学习的时候，还是对其中的Unwanted Tracking Alert的功能特性和使用逻辑不是很清楚。 Apple Find My Accessory的四种工作状态 要搞明白Unwanted Tracking Alert，首先要弄清楚Apple Find My Accessory的四种工作状态： !Untitled.png 本质上，Apple Find My Accessory实际上就是一个基于BLE Beacon以及连接模式的位置跟踪器。那么对于任何的蓝牙设备而言，大致无非就是配对前的广播状态、配对后的广播状态（未连接），以及连接通信状态。所以以上的Unpaired和Connected状态是比较好理解的，但是Nearby和Separated是什么意思？区别是什么？ 实际上Nearby和Separated这两种状态的区别就跟Unwanted Tracking Alert功能息息相关了。 - Unpaired：就是Find My Accessory的未配对模式，所有的这类设备出厂后刚开机的时候就处于这种状态下，持续的发出广播包等待与用户的Apple设备进行首次配对。 - 除了一开始的初始状态以外，如果这个accessory解绑unpairing以后，每次开机也是处于这种状态之下。 - Connected：就是Accessory与用户Apple设备之间处于正常的连接状态，用户可以在apple设备的find my app上看到设备的位置，控制设置发出声音以更方便的进行定位。 - Nearby：当accessory和用户的apple设备之间的BLE连接断开后，总是首先会进入Nearby状态。这个Nearby状态本质上还是一种BLE的广播状态，这个状态的目的就是等待与用户的Apple设备重新建立连接。这种状态下不支持Unwanted Tracking Alert功能。 - Separated：Nearby状态下会维持一个倒计时器，当accessory处于Nearby状态的时间超过TNearBy（默认为15min，但是可以在apple device的find my app连接状态下修改）后，这个Accessory就会自动进入Separated状态。Separated状态与Nearby状态在实现上的最大区别就是，Separated状态有Unwanted Tracking Alert功能，而Nearby状态没有。 我自己对于以上状态的理解： - 实际上对于Find My Accessory而言，经过pairing操作以后，正常使用中绝大多数状态应该就是Connected和Nearby。Connected当然就表示手机跟Accessory之间的距离很近，双方一直保持正常连接；而Nearby则是手机和Accessory之间短暂离开（离开时间不超过15min）的状态。 - Separated状态则是表示手机跟Accessory之间已经超过15min不在一起了，存在丢失的风险或者已经丢失了。所以处于丢失状态下的Find My Accessory实际上就是处于这种状态 - 可以理解Nearby状态是用户Apple device与Accessory的临时断开状态，如果断开的状态时间太长进入了Separated状态，就认为是进入丢失状态了。 - 后续完整的Unwanted Tracking Alert功能全部都是与Separated状态来进行设计的。 那么Unwanted Tracking Alert功能究竟是什么？ 按照参考文档1第2.6.1 Unwanted Tracking Detection节的描述： - Unwanted tracking detection (UT) notifies the user of the presence of an unrecognized accessory that may be traveling with them over time and allows them to take various actions, including playing a sound on the accessory if it’s in Bluetooth LE range. 也就是说，Find My Accessory的基本功能实际上就是一个BLE防丢器，配合Apple的Find My Server以及强大的苹果产品生态，可以为用户方便的定位这个Find My Accessory所在的准确位置。 但是，这个功能也很容易被人恶意用于跟踪，最典型的就是：跟踪者把一个与自己Apple账号绑定的Find My Accessory放入被跟踪者的车辆、背包等里面，然后无论这个被跟踪者到哪里，跟踪者都可以很容易的用自己的find my app查到到被跟踪者的精确位置。 因此Apple Find My Accessory中的这个Unwanted tracking detection或者alert的功能就是通过： - Accessory在长时间进入Separated状态后，定期通过Motion Detector检测Motion，并主动发出告警声音。 - 以及在潜在被跟踪者的手机上监测到异常后弹出Alert的方式进行告警。 以上两种方式来提醒用户，以缓解和应对位置隐私信息泄露带来的危险。 Find My Accessory端的Unwanted Tracking Alert功能实现 正是因为find my accessory很容易被人用于恶意的跟踪他人的位置，所以在Apple的find my accessory specfication里面明确要求，小尺寸的Find My Accessory一定要有Sound Maker（例如喇叭，蜂鸣器）和一个Motion Detector（例如g-sensor）用于辅助快速找到隐藏的跟踪设备。 如果不满足以下尺寸要求，就一定要有Sound Maker和Motion Detector来实现Unwanted Tracking Alert功能： !Untitled.png 而对于这个accessory而言，Unwanted Tracking Alert功能的大致实现流程如下： - Accessory进入Separated状态后，等待TSEPARATED_UT_TIMEOUT时间（默认为3天），启用Motion Detector功能。 - 此后以TSEPARATED_UT_SAMPLING_RATE1为周期（默认为10s）使用Mition Detctor检测当前是否处于Motion。 - 如果检测到Motion，就通过Sound Maker播放一次声音，同时后续修改Motion Detector的检测周期为TSEPARATED_UT_SAMPLING_RATE2（默认为0.5s），同样每次检测到Motion就播放一次声音，以提醒用户注意。 - 如果已经播放过10次声音，或者以TSEPARATED_UT_SAMPLING_RATE2为周期连续检测到20秒Motion事件，则禁用Motion Dector一段时间 TSEPARATED_UT_BACKOFF（默认为6小时）。然后再周而复始。 通过以上流程，当Accessory处于Separated的状态下超过一定的时间后，就会定期的打开Motion Detector进行Motion检测，检测到Motion后再通过Sound Maker来提醒用户可能被跟踪。 iOS手机端的Unwanted Tracking Alert功能特性 除了Accessory自身在Separated状态下，周期性的通过Motion Detection+Sound的方式提醒可能被跟踪以外，用户的Apple设备端（例如iOS手机）也会在判断周围有处于Separated状态的Find My Accessory持续跟踪的情况下，在手机系统中推送Alert消息如下。当系统收到Alert消息以后，点击进入Find My APP就会找到自己附近的Find My Accessory设备。此时还可以通过Play Sound来控制这个跟踪器发出声音，从而更快速的找到这个跟踪器的位置。 !Untitled.png !Untitled.png 对于iOS手机系统如何判断自己是否被一个跟踪器持续跟踪，我的理解是： - 手机的BLE打开的情况下持续的扫描周期的BLE设备，当然也就包括使用BLE的Find My Accessory设备。 - 如果手机系统检测到自己周围有一个处于Separated状态下的Find My Accessory设备，默认情况下会按照Find My Server运行的流程，从Find My Accessory设备BLE广播包中包含的密钥，加密自己所在的位置上报给Apple Find My Server。 - 但是如果手机系统检测到这个处于Separated状态下的Accessory在自己周围的时间过长，就会在系统上弹出Alert警告用户可能被跟踪。 这里值得注意的一点是，用户可以通过Find My APP控制周围处于Separated状态下的Accessory发出声音，来更快的找到这个Accessory所在的位置。既然要控制，那么用户的手机就一定要能够与这个Accessory建立BLE连接才行，Beacon模式肯定是没法实现控制的。因此在整个Find My的工作流程中，Non Owner的apple设备也就是手机，是可以与Find My Accessory建立连接并进行控制通信的。这个情况下这个控制指令，实际上使用的是Accessory中所实现的BLE Find My Network service中的Non Owner Control Point Characteristic： !Untitled.png 其他问题 1. Android设备对于Apple Find My Accessory的Unwanted Tracking Alert特性的支持情况？ - 实际上Google在这个方面也已经在仿效Apple打造自己的Find My Accessory生态，根据Nordic代理渠道得到的信息，目前国内已经有厂家使用Nordic的nRF52系列配合Google的find my协议需求完成了这部分功能的实现。 - 而根据参考文档2中Apple官方网站提供的描述，Apple和Google已经针对Find My的Unwanted Tracking Alert特性达成了协议一致性的产业标准（draft-detecting-unwanted-location-trackers-01 - Detecting Unwanted Location Trackers (ietf.org)），以后无论用户是使用Android还是iOS的手机，都可以在触发Find My Unwanted Tracking Alert特性的情况下，在手机上收到可能被跟踪的警告信息。 !Untitled.png 1. 当通过手机系统的Alert Message或者Accessory的周期性Motion Detection+Sound的机制发现跟踪设备后，如何处理？ - 从参考文档3给出的信息，除了把这个跟踪器扔掉以外，另外一个办法就是把这个跟踪器强制关机或者拔掉电池。 参考文档 - Find My Network Accessory Specification Release R2 - Apple and Google deliver support for unwanted tracking alerts in iOS and Android - Apple (HK) - How to find out if an AirTag is tracking you | ZDNET - 浅析 Find My 原理 - Yibin! - 博客园 (cnblogs.com)

蓝牙设备的BQB认证

什么是BQB认证？ BQB：Bluetooth Qualification Body。 只有通过蓝牙SIG组织认证的产品才是真正的蓝牙产品，才能保证产品的兼容性和相关性能是符合蓝牙标准的，才能合法使用蓝牙或BLUETOOTH的LOGO以及相关蓝牙技术规范，不然被查到需要罚款。 _什么情况下需要做BQB认证？_ 凡带有蓝牙功能的产品必须通过蓝牙BQB认证，否则该产品就会被蓝牙技术联盟(Bluetooth Special Interest Group, 简称SIG) 视为侵权。其中针对蓝牙产品的BQB认证是蓝牙产品基本认证项目之一，目前由SIG负责管理。 BQB认证费用 BQB的认证费用包含两个部分：DID费用，测试费用。 - DID费用分为以下三种情况： - 对于年销售额小于100万美金的小公司，在18个月内有两次机会以 2500 USD/DID购买DID，而且必须在18个月内使用；18个月后，费用恢复正常。 - 对于SIG的免费会员，8000 USD/DID，次数不限； - 对于SIG的联盟会员： - 年销售额低于1亿美金的申请公司：年费：7500 USD/年;4000 USD/DID，次数不限。 - 年销售额高于1亿美金的申请公司：年费：35000 USD/年;4000 USD/DID，次数不限。 - 测试费用由具体的实验室和测试机构来确定。 例如以下的BQB认证费用的报价单： !Untitled.png - 对于免费会员而言，做一个蓝牙产品的BQB认证费用就是：DID费用8000$，再加上测试机构的测试费用22000人民币，总共就是接近80000人民币。 蓝牙BQB认证内容 - 射频(RF)一致性测试； - 协议(Protocol)一致性测试； - 配置文件(Profile)兼容性测试； - 符合性声明； - 相关技术文档审核。 蓝牙BQB认证程序 1. 成员在线启动项目； 2. 成员获得Bluetooth设计ID； 3. 成员选择产品特点(PICS)； 4. 成员完成测试计划； 5. 成员完成产品； 6. 成员测试产品； 7. 成员完成测试报告； 8. 成员向SIG提交测试报告； 9. 成员在线发布产品(QDL和EPL)； 10. 成员用ID号标记产品； 11. 成员签署DoChe SDoC； 12. 成员支付编号费用； 蓝牙BQB的查询 蓝牙产品经过BQB认证测试后，SIG会为这个产品分配一个独一无二的QDID编码（Qualified DID），可以在Bluetooth官网的BQB查询窗口中进行查询。 查询网址：Launch Studio - Listing Search (bluetooth.com)； 例如查询Realtek的RTL88XX系列BT芯片芯片对应的DID，得到的结果是： !Untitled.png 参考资料 - 蓝牙BQB认证是什么？BQB认证费用多少？ - 知乎 (zhihu.com）