【0x0011】HCI_Authentication_Requested下令详解

目次
一、下令概述
二、下令格式及参数阐明
2.1. HCI_Authentication_Requested下令格式
2.2. Connection_Handle
三、天生变乱及参数阐明
3.1. HCI_Command_Status变乱
3.2. 安全简单配对模式（Secure Simple Pairing Mode）启用时的变乱天生
3.2.1. HCI_Link_Key_Request变乱
3.2.2. 主机复兴与变乱后续
3.3. 安全简单配对模式未启用时的变乱天生
3.4. HCI_Authentication_Complete变乱
四、下令实验流程
4.1. 发送认证哀求
4.2. 吸收下令状态变乱
4.3. 处置惩罚Link Key哀求变乱
4.4. 处置惩罚PIN码哀求变乱（如实用）
4.5. 吸收认证完成变乱
4.6. 后续操纵
4.7. 示例代码
五、利用场景
5.1. 装备配对与安全验证
5.2. 高安全需求服务访问
5.3. 蓝牙装备毗连状态变更
六、注意事项
6.1. 参数准确性与正当性
6.2. 装备兼容性与安全计谋适配
6.3. 认证效果处置惩罚与毗连维护
6.4. 安全风险与隐私掩护
6.5. 其他注意事项

---

HCI_Authentication_Requested下令重要用于在蓝牙装备之间创建安全毗连时，哀求对远端装备举行认证。这是蓝牙安全机制的一部门，确保只有颠末认证的装备才华创建毗连并互换数据。
一、下令概述

在蓝牙通讯中，安全性是一个非常紧张的思量因素。通过认证过程，可以验证装备的身份，防止未经授权的装备接入网络，从而掩护数据的机密性和完备性。

当主机（Host）决定与某个远端蓝牙装备举行通讯时，大概会发送HCI_Authentication_Requested下令给蓝牙控制器（Controller）。这个下令包罗了要认证的毗连的毗连句柄（Connection_Handle），用于指定哪个毗连必要举行认证。
一旦吸收到这个下令，蓝牙控制器会实验与远端装备举行认证。涉及到一系列复杂的交互，包罗互换认证信息、验证身份等。如果认证乐成，控制器会向主机发送一个认证完成变乱（Authentication Complete Event），表明远端装备已经乐成通过认证，可以创建安全毗连。
如果认证失败，控制器通常不会主动断开毗连。这时，主机必要决定是否继续实验认证，大概断开与远端装备的毗连。
二、下令格式及参数阐明

2.1. HCI_Authentication_Requested下令格式

HCI_Authentication_Requested下令的格式依照蓝牙核心规范中界说的HCI下令格式。

通常包罗以下几个部门：

• Opcode（操纵码）：2字节。指示下令的范例。对于HCI_Authentication_Requested下令，操纵码为0x0411。
  
• Parameter_Total_Length（参数总长度）：1字节。表现下令参数的总长度。对于HCI_Authentication_Requested下令，参数总长度为0x02（即2个字节）。
  
• Parameters（参数）：可变长度（根据Parameter_Total_Length确定），对于HCI_Authentication_Requested下令，只有一个参数：
  
  
  
  • Connection_Handle（毗连句柄）：2字节。指定要认证的蓝牙毗连
    
  
  

2.2. Connection_Handle

Connection_Handle用于唯一标识ACL毗连或某些情况下的SCO毗连的句柄。该句柄是在毗连创建时由蓝牙控制器分配的，并用于后续的HCI下令和数据包中，以指定要操纵的详细毗连。

• 有效性：固然Connection_Handle是一个16位的值，但根据蓝牙核心规范，通常只有此中的12位是有效的。意味着在实际利用中，某些高位不被利用。
  
• 范围限定：Connection_Handle的值必须在0x0000到0x0EFF的范围内。如果实验利用超出此范围的值，蓝牙控制器大概会返回一个错误状态。
  

三、天生变乱及参数阐明

HCI_Authentication_Requested 下令本身没有直接返回的参数。主机在发送该下令后，不会立即吸收到像传统函数调用那样带有明确返回值的数据来知晓下令实验情况，而是必要通过后续控制器发送的各类变乱来获取相干信息，以此判断下令实验的进度和最闭幕果。
3.1. HCI_Command_Status变乱

当控制器（Controller）吸收到 HCI_Authentication_Requested 下令时，起首会向主机发送 HCI_Command_Status 变乱。这个变乱重要起到告知主机下令已被吸收的作用，主机可以通过分析该变乱来确认下令是否乐成送达控制器，不外此时还不能得知下令是否真正实验乐成以及后续认证流程的详细情况，只是一个开端的反馈。

3.2. 安全简单配对模式（Secure Simple Pairing Mode）启用时的变乱天生

3.2.1. HCI_Link_Key_Request变乱

如果安全简单配对模式被启用，控制器会天生HCI_Link_Key_Request变乱。这个变乱表现与特定蓝牙装备的毗连必要一个链接密钥（Link Key）。

3.2.2. 主机复兴与变乱后续

此时，后续的操纵取决于主机复兴的下令：

• 如果主机没有对应的链接密钥，它会复兴HCI_Link_Key_Request_Negative_Reply下令。此时，将启动安全简单配对过程。【0x000C】HCI_Link_Key_Request_Negative_Reply 下令详解-CSDN博客
  
• 如果主机有对应的链接密钥，它会复兴HCI_Link_Key_Request_Reply下令。此时，仅实验认证步调，不启动安全简单配对。【0x000B】HCI_Link_Key_Request_Reply下令详解-CSDN博客
  

3.3. 安全简单配对模式未启用时的变乱天生

如果安全简单配对模式未启用，控制器大概会（但不应该）利用已存储的链接密钥举行认证。如果认证失败，大概会天生HCI_PIN_Code_Request变乱，要求输入PIN码举行认证。
然而，当安全简单配对模式未启用时，利用已存储的链接密钥是不被保举的，由于这不能为主机提供一种加强现有链路安全性的方法。比方，当在某个已经通过较短PIN码认证的链路上启动必要更长PIN码的服务时，这种方法就无法提供充足的安全性。 
3.4. HCI_Authentication_Complete变乱

无论是否启用了安全简单配对模式，当毗连的认证完成时，都会天生HCI_Authentication_Complete变乱。这个变乱表现HCI_Authentication_Requested下令已完成，而且毗连的认证过程已经竣事。

主机可以通过分析该变乱获取认证的最闭幕果（乐成或失败），进而根据本身的安全计谋和业务需求来决定后续对该毗连的操纵，比如继续保持毗连、断开毗连大概实验重新认证等。
   蓝牙HCI认证过程中涉及的变乱天生与是否启用安全简单配对模式以及主机的复兴密切相干。这些变乱为蓝牙装备的认证和毗连管理提供了紧张的反馈和指示。
  四、下令实验流程

4.1. 发送认证哀求

主机（Host）向控制器（Controller）发送HCI_Authentication_Requested下令，哀求对远端装备举行认证。该下令中包罗一个Connection_Handle参数，用于表现本地装备和远端装备之间的ACL毗连。
4.2. 吸收下令状态变乱

控制器在吸收到HCI_Authentication_Requested下令后，会立即向主机发送一个Command Status变乱，表现该下令是否乐成发送。
4.3. 处置惩罚Link Key哀求变乱

如果Simple Pairing模式已启用，控制器会向主机发送一个Link Key Request变乱，哀求一个Link Key。Link Key是用于加密和认证蓝牙装备之间毗连的密钥。

• 主机在吸收到Link Key Request变乱后，有以下两种选择：
  
  
  
  • 如果主机有对应的Link Key，则利用HCI_Link_Key_Request_Reply下令将Link Key发送给控制器。
    
  • 如果主机没有对应的Link Key，则利用HCI_Link_Key_Request_Negative_Reply下令举行复兴，表现无法提供Link Key。
    
  
  
• 如果Simple Pairing模式未启用，控制器同样会发送Link Key Request变乱。此时，主机的处置惩罚方式与上述类似。但如果主机复兴了HCI_Link_Key_Request_Negative_Reply下令，而且即将用到的服务必要一个认证的Link Key，那么在之后的IO Capability中，主机应设置Authentication_Requirements为MITM Protection Required的选项。
  

4.4. 处置惩罚PIN码哀求变乱（如实用）

• 如果主机在Link Key哀求阶段复兴了HCI_Link_Key_Request_Negative_Reply下令，而且Simple Pairing模式已启用，那么控制器大概会向主机发送一个PIN Code Request变乱，哀求一个PIN码举行认证。
  
• 主机在吸收到PIN Code Request变乱后，必要复兴PIN码。如果PIN码认证乐成，控制器会天生并发送一个Link Key Notification变乱给主机，表现Link Key已天生并可用于后续的毗连加密和认证。
  

4.5. 吸收认证完成变乱

如果认证过程乐成完成，控制器会向主机发送一个Authentication Complete变乱，表现认证已乐成完成。
4.6. 后续操纵

• 如果身份验证乐成，主机可以继续举行后续操纵，如数据传输等。
  
• 如果身份验证失败，主机必要决定是否断开链路。如果必要断开，主机应发送 HCI_Disconnect 下令。
  

必要注意的是，在整个认证过程中，如果任何一步出现错误或超时，都大概导致认证失败。此时，主机大概必要重新发起认证哀求或采取其他步伐来处置惩罚认证失败的情况。
别的，HCI_Authentication_Requested下令的实验流程还大概受到蓝牙装备型号、固件版本、配对计谋等因素的影响。因此，在实际应用中，大概必要根据详细的装备和情况对流程举行得当的调解和优化。
4.7. 示例代码

下面是一个简化的伪代码示例，来概述主机和控制器之间怎样交互以实验HCI_Authentication_Requested下令。请注意，这只是一个概念性的示例，并不是可编译的代码。

1. // 伪代码示例：HCI_Authentication_Requested流程
3. // 假设有以下函数和变量定义（这些在实际代码中需要由蓝牙协议栈提供）：
5. // 发送HCI命令给控制器的函数
6. void hci_send_command(uint16_t opcode, uint8_t* parameters, uint8_t parameter_length);
8. // 接收HCI事件的回调函数（由蓝牙协议栈在接收到事件时调用）
9. void hci_event_callback(uint8_t* event, uint8_t event_length);
11. // 全局变量，用于存储连接句柄
12. uint16_t connection_handle = 0x0001; // 示例连接句柄
14. // 认证过程中的状态变量
15. enum AuthenticationState {
16.     WAITING_FOR_COMMAND_STATUS,
17.     WAITING_FOR_LINK_KEY_REQUEST,
18.     WAITING_FOR_PIN_CODE_REQUEST,
19.     WAITING_FOR_AUTHENTICATION_COMPLETE,
20.     AUTHENTICATION_FAILED
21. } authentication_state = WAITING_FOR_COMMAND_STATUS;
23. // 用于存储Link Key和PIN码的变量（在实际代码中，这些可能需要更安全的存储方式）
24. uint8_t link_key[16] = {0}; // 示例Link Key（16字节）
25. uint8_t pin_code[16] = "0000"; // 示例PIN码（4字节，ASCII表示）
27. // 发送HCI_Authentication_Requested命令的函数
28. void send_authentication_request() {
29.     uint8_t parameters[2] = {
30.         connection_handle & 0xFF, // 连接句柄的低字节
31.         (connection_handle >> 8) & 0xFF // 连接句柄的高字节
32.     };
33.     hci_send_command(0x0011, parameters, sizeof(parameters)); // 0x0011是HCI_Authentication_Requested的操作码
34. }
36. // HCI事件回调函数的实现
37. void hci_event_callback(uint8_t* event, uint8_t event_length) {
38.     uint8_t event_code = event[0];
39.     uint8_t status = event[1];
41.     switch (event_code) {
42.         case 0x0F: // Command Status event
43.             if (status == 0x00) {
44.                 authentication_state = WAITING_FOR_LINK_KEY_REQUEST;
45.             } else {
46.                 authentication_state = AUTHENTICATION_FAILED;
47.                 // 处理命令发送失败的情况
48.             }
49.             break;
51.         case 0x05: // Link Key Request event
52.             if (authentication_state == WAITING_FOR_LINK_KEY_REQUEST) {
53.                 // 检查是否有可用的Link Key
54.                 if (has_link_key()) { // 这是一个假设的函数，用于检查Link Key是否存在
55.                     // 发送Link Key给控制器（这里省略了构建和发送HCI_Link_Key_Request_Reply命令的细节）
56.                     send_link_key_reply(link_key);
57.                 } else {
58.                     // 发送Link Key Request Negative Reply给控制器（同样省略了细节）
59.                     send_link_key_negative_reply();
60.                     authentication_state = WAITING_FOR_PIN_CODE_REQUEST; // 假设需要PIN码
61.                 }
62.             }
63.             break;
65.         case 0x06: // Link Key Notification event（在PIN码认证成功后由控制器发送）
66.             // 更新内部状态或执行其他操作（如记录新的Link Key）
67.             break;
69.         case 0x0E: // PIN Code Request event
70.             if (authentication_state == WAITING_FOR_PIN_CODE_REQUEST) {
71.                 // 发送PIN码给控制器（这里省略了构建和发送PIN码的细节）
72.                 send_pin_code_reply(pin_code);
73.             }
74.             break;
76.         case 0x0B: // Authentication Complete event
77.             if (status == 0x00) {
78.                 // 认证成功，执行后续操作（如加密连接）
79.                 authentication_state = -1; // 设置为无效状态，表示认证流程已完成
80.             } else {
81.                 authentication_state = AUTHENTICATION_FAILED;
82.                 // 处理认证失败的情况
83.             }
84.             break;
86.         // 其他事件的处理...
88.         default:
89.             // 未知事件的处理
90.             break;
91.     }
92. }
94. // 省略了其他必要的函数实现，如send_link_key_reply(), send_link_key_negative_reply(), send_pin_code_reply()等。
95. // 这些函数需要构建适当的HCI命令数据包，并通过HCI接口发送给蓝牙控制器。
97. // 主函数（或某个初始化函数中）调用发送认证请求的函数
98. int main() {
99.     // 初始化蓝牙协议栈和其他必要的设置...
101.     // 发送认证请求
102.     send_authentication_request();
104.     // 进入事件循环，等待并处理HCI事件...
105.     // 这通常是通过注册一个回调函数给蓝牙协议栈来实现的，当有事件发生时，蓝牙协议栈会调用这个回调函数。
107.     return 0;
108. }

复制代码

上面的代码是一个高度简化的示例，省略了许多细节，在实际开发中，必要参考蓝牙协议栈的文档和API来编写完备的代码。
五、利用场景

5.1. 装备配对与安全验证

• 初次配对后的加强验证：
  
  
  
  • 场景：蓝牙耳机与手机初次配对乐成后。
    
  • 目的：通过发送HCI_Authentication_Requested下令，利用配对时天生的密钥（如链路密钥）对从装备举行额外认证，防止中心人攻击，确保数据传输安全。
    
  
  
• 配对信息更新后的验证：
  
  
  
  • 场景：装备配对信息（密钥、装备标识等）发生更新。
    
  • 目的：利用HCI_Authentication_Requested下令重新验证毗连的装备，确保利用最新的安全信息举行通讯，保障数据安全。
    
  
  

5.2. 高安全需求服务访问

• 金融服务相干蓝牙装备毗连：
  
  
  
  • 场景：蓝牙移动付出终端与手机、蓝牙智能卡读卡器与电脑等金融相干装备毗连。
    
  • 目的：在认证乐成后，才答应访问和传输金融服务相干的数据，防止未经授权的装备获取金融信息，确保生意业务安全。
    
  
  
• 企业级安全蓝牙装备通讯：
  
  
  
  • 场景：蓝牙门禁体系、蓝牙企业级传感器等装备与控制中央或管理装备毗连。
    
  • 目的：确保只有颠末授权的装备可以大概接入企业内部的蓝牙网络，访问企业敏感数据或实验关键操纵，符合企业安全计谋。
    
  
  

5.3. 蓝牙装备毗连状态变更

• 毗连规复后的安全确认：
  
  
  
  • 场景：蓝牙装备之间的毗连因信号停止、低功耗模式等缘故因由停止后规复。
    
  • 目的：通过发送HCI_Authentication_Requested下令，确保重新毗连的装备仍然是正当的，继续安全地处置惩罚数据。
    
  
  
• 毗连模式切换后的认证：
  
  
  
  • 场景：蓝牙装备之间的毗连模式从低功耗模式切换到高速数据传输模式，或从仅广播模式切换到可毗连模式。
    
  • 目的：确保在毗连模式厘革后，装备之间的通讯仍然是安全可靠的，防止非法装备利用毗连模式切换举行攻击。
    
  
  

六、注意事项

6.1. 参数准确性与正当性

• 毗连句柄的准确性：
  
  
  
  • 确保毗连句柄对应有效的、活动的ACL毗连。
    
  • 主机装备需维护毗连句柄的存储和更新机制。
    
  
  
• 参数取值范围服从：
  
  
  
  • 毗连句柄应在蓝牙协议规定的正当取值范围内。
    
  • 注意毗连句柄的有效位数量。
    
  
  

6.2. 装备兼容性与安全计谋适配

• 差异蓝牙版本兼容性：
  
  
  
  • 思量装备间蓝牙版本的兼容性，选择符合的认证方式。
    
  • 根据两边支持的最低共同标准实验下令。
    
  
  
• 安全计谋同等性：
  
  
  
  • 确保装备两边的安全计谋同等或兼容。
    
  • 在装备配对或设置过程中明确安全计谋，须要时举行协商或调解。
    
  
  

6.3. 认证效果处置惩罚与毗连维护

• 准确处置惩罚认证乐成情况：
  
  
  
  • 更新内部安全状态记载，标志毗连为已认证。
    
  • 答应受掩护的蓝牙服务访问或数据传输。
    
  
  
• 妥善应对认证失败情况：
  
  
  
  • 分析并记载认证失败缘故因由。
    
  • 根据失败缘故因由和计谋决定是否重新实验认证、提示用户或断开毗连。
    
  
  
• 毗连状态的维护与更新：
  
  
  
  • 在认证过程中维护毗连状态信息。
    
  • 根据认证效果和业务需求规复或调解毗连状态。
    
  
  

6.4. 安全风险与隐私掩护

• 防止中心人攻击风险：
  
  
  
  • 接纳充足强度的安全协媾和加密算法。
    
  • 确保密钥的安全性和保密性。
    
  
  
• 隐私掩护步伐：
  
  
  
  • 利用匿名装备标识或临时密钥举行认证。
    
  • 注意认证过程中数据传输的安全性。
    
  
  

6.5. 其他注意事项

• 认证过程的相应：根据Simple Pairing模式的状态，预备并复兴相应的Link Key或PIN码哀求。
  
• 认证失败的处置惩罚：主机需主动断开毗连，或在须要时重新实验认证或重新配对。
  
• 安全思量：在认证过程中利用安全的通讯方式。支持Secure Connections特性的装备应在断开毗连后删除Link Key。
  
• 下令格式和参数：按照HCI协议规范构造下令格式和参数。注意参数总长度和毗连句柄的准确性。
  
• 超时和重试机制：设置公道的超时时间，并在超时后思量重试认证哀求。计划重试机制以应对大概的认证失败情况。
  

综上所述，HCI_Authentication_Requested 下令是蓝牙 BR/EDR 控制器中用于发起长途装备身份验证的关键下令。通过准确利用该下令，可以确保蓝牙毗连的安全性，并答应主机在身份验证失败时采取得当的举措。