蓝牙低能量链路层加密的安全性

Question

蓝牙低能( BLE )的S链路层加密安全吗?攻击者窃听两个设备之间的一些随机BLE连接，但没有窃听两个设备之间的第一个连接？

背景:当这两个设备最初配对时，它们使用密钥交换协议获得一个长期密钥。任何能够窃听初始配对的人都可以学习长期密钥，但就这个问题而言，假设对手没有窃听初始配对(例如，因为对手不在附近)。然后，这两个设备使用这个长期密钥来加密未来所有连接上发送的数据。布尔使用AES-CCM进行链路层加密，如果长期密钥不可预测，则应该是安全的.

然而，在WOOT 2013年，Mark发表了一篇论文，推测可能会对BLE发起攻击。在他的攻击中，攻击者向一个设备注入一条伪造的LL_REJECT_IND消息。显然，这将导致接收者忘记当前的长期密钥，并强制新的密钥交换来派生新的长期密钥。攻击者可以窃听此新密钥交换，了解新的长期密钥，并解密所有后续通信量。至少瑞恩也是这么推测的。

这次攻击真的有效吗？即使攻击者没有捕获两个设备之间的初始配对，BLE的链路层加密是否不安全？

参考资料: Mike，"蓝牙:低能量带来低安全性"，WOOT，2013年。https://www.usenix.org/conference/woot13/workshop-program/presentation/Ryan

Answer 1

这次攻击确实有效。我一直在玩我五年前在DEF CON买下的Ubertooth，并对实现BLE标准的各种IoT设备进行了测试。迈克·瑞安的论文是正确的。

在“滥用物联网”一书中，作者讨论了Mike的工作及其与Ubertooth的实现。

ubertooth-btle -f -c ble.pcap

作者还讨论了如何使用LightBlue iOS应用程序进行进一步的故障排除，因为它可以复制蓝牙设备并进行仿真。它需要一些工作与BLE，因为它使用许多渠道，因此在网络捕获评估期间打开和关闭接口是强烈建议。

标准BLE加密数据通过选择基于AES的临时密钥(TK)使用密钥交换协议.Mike发布了裂纹工具来强制使用这个键。

crackle -i ble.pcap -o decrypted-ble.pcap

这种技术对OOB (也由BLE定义的128位可选键)模式并不有效，但是，正如在[医]牙齿邮寄名单上所看到的，开发团队正在收集示例并排除打破OOB模式的可能性。

一个著名的支付技术博客和相关的基础设施也一直在猜测蓝牙安全的消亡，包括一些关于打破BLE模式的评论。12/29/15更新:有更多关于BT 2.1的讨论。同时也遇到了BTLE，希望能很快支持BTLE。我遇到的另一个教程是利用UbertoothOne嗅探和破解蓝牙。

然而，(正如这本书“黑客暴露的无线，第3版”)，修复蓝牙的想法首次在(http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05)的论文“破解蓝牙PIN”中公布。对手可以通过模拟两个设备中的一个设备的BD_ADDR来使用“修复攻击”来操纵两个设备之间的存储配对状态。

工具巴德尔是该技术的主要实现。

gcc -obdaddr -lbluetooth bdaddr.c
hciconfig hci0
sudo bdaddr -i hci0 <new bdaddr>
(asks to reset device now)
sudo bccmd -d hci0 warmreset
(check that it changed)
hciconfig hci0
sudo hcitool cc <bdaddr of target to repair to>
sudo hcitool enc <bdaddr target again> enable

重新回到干净的石板上

sudo bccmd -d hci0 coldreset
hciconfig hci0