键盘|蓝牙自动配对时警惕PIN码漏洞攻击

键盘|蓝牙自动配对时警惕PIN码漏洞攻击

文章图片


蓝牙自动配对时警惕PIN码漏洞攻击
配对是蓝牙设备间身份认证的一个过程 , 只有成功配对的两个设备才能连接并进行数据交互 , 所以配对是蓝牙操作中必不可少的流程 。
在《蓝牙配对协议分析一》和《蓝牙配对协议分析二》中已经简单介绍了配对的相关协议知识 , 还不清楚的同学可以先查看下这两篇文章 , 回来再阅读本篇分享可以更加地得心应手 。
蓝牙标准配对流程:

  • PIN码配对:蓝牙2.0及以前版本使用的流程
  • SSP简单安全配对:蓝牙2.1及之后版本新增的流程
因为SSP相较于PIN码配对具有更高的安全性、更方便的操作性等优点 , 所以PIN码配对方式已经退出历史舞台 , 当前市面上的蓝牙设备基本上都是采用SSP配对方式 。
SSP安全简单配对在主要应用场景中也有如下三种模型:
  1. Numeric Comparison:数字比较模型 , 连接的两个设备都具有输入、输出能力 。 比如手机、车机、平板、个人电脑等设备间配对连接 。
  2. Passkey Entry:密码输入模型 , 连接是两个设备中有一个设备只具有输入能力 , 另一个设备具有输出能力 。 比如手机和键盘配对连接 , 只有键盘正确输入手机上显示的数字才能配对成功 。
  3. Just Works:直接工作模型 , 类似 Numeric Comparison , 这里一起放到数字比较模型中讲解 。
结合以上三种SSP配对模型 , Passkey Entry密码输入模型无法做到自动配对 , 可以有效防止MITM攻击 。 Numeric Comparison数字比较模型却可以实现蓝牙自动配对目标 , 以下内容都是以Numeric Comparison配对模型进行分享 。
参照《蓝牙配对协议分析二》中Step 7: Authentication——Numeric Comparison 可知当两个设备都具有输入、输出功能时 , 或者其中一个设备没有输入或输出功能 , 则将执行数字比较步骤 。 如果一个或两个设备没有输出功能 , 则使用相同的协议 , 但是协议栈Host将跳过要求用户确认的环节 , 这就是Just Works模型 。 数字比较模型的交互流程图如下:

所以自动配对的实现可以在用户确认数字这块 , 程序默认直接接受配对 , 达到让用户无感实现自动配对的目标 。
实现方案:有多种方案 , 只要在协议栈bluedroid接收到 User Confirmation Request 的HCI请求命令处理上报流程中都可以添加自动接受配对的逻辑 , 为了最大程度上符合一般的流程设计 , 建议放到应用层中模拟用户确认接受配对的动作进行处理 。 即应用监听到系统广播BluetoothDevice.ACTION_PAIRING_REQUEST后 , 直接调用接口 BluetoothDevice .setPairingConfirmation(true)。
蓝牙自动配对虽然实现了 , 但是配对漏洞攻击也随之而来 。 因为不需要用户的参与 , 本端实现的自动配对的主机都会默认接收远端蓝牙设备发起的配对请求 , 这就给攻击者可乘之机 。
蓝牙配对中会对设备进行IO能力的获取 , 蓝牙设备的IO能力总体上大概分为以下这五种:
  1. DisplayOnly , 只有输出能力
  2. DisplayYesNo , 有输出、输入能力 , 手机、车机、个人电脑
  3. KeyboardOnly , 只有键盘
  4. NoInputNoOutput , 即没输入、也没输出能力 , 耳机、音箱
  5. KeyboardDisplay , 键盘输出能力 , 带显示器的键盘
IO能力为KeyboardOnly或Keyboard display的设备明显会使用 Passkey Entry 模型进行配对 , 因此另一端设备必须将passkey展示出来才能在键盘上输入 , 不适合实现自动配对功能 。
其他三种IO能力的设备都会采用 Numeric Comparison 模型配对 , 在这三种设备间攻击者就可以利用自动配对的漏洞实行进一步的攻击 。 因此自动配对和防止漏洞攻击不可兼得 , 望大伙警惕 。
那有没有办法能让自动配对和防止漏洞攻击兼得呢?
方法肯定是有的 , 实现自动配对功能的本机首次配对连接时只允许本机发起的配对连接请求 , 拒绝其他设备主动来配对连接本机 , 后续的重连两端设备都可以发起 , 此方案大大增加本机的私密性 。
【键盘|蓝牙自动配对时警惕PIN码漏洞攻击】感兴趣的小伙伴欢迎私信留言一起讨论 , 共同学习 , 一起进步!


    推荐阅读