蓝牙低耗能加密和数据安全 [英] Bluetooth Low Energy encryption and data safety

问题描述

我需要在智能手机（iOS的＆安培; Android的）之间的蓝牙低功耗（BLE）数据连接发送一些敏感数据和嵌入式设备（CC2540芯片）。

由于我不认为在手机上的APP-code是世界上黑客攻击的安全，我需要靠BLE安全得到从服务器到设备一旦我的加密包传递和一次（我必须假定任何第二次尝试为客户提供包装，必须从攻击者）。

我一直在浏览网现在几天，来看看我的数据是安全的，在什么条件下。不幸的是我一直没能拿出一个简单的回答我的问题。

1. 我的数据安全的，如果我配对的手机的设备？ - 我想是这样，但我明白，配对过程本身是有缺陷的，所以它在理论上是可能对一些人在这方面的中间人（MITM）在配对过程中嗅出了加密密钥，从而影响连接

2. 我需要每个设备进行配对，以多部电话（但只有通信以一次一个）。什么是对配对PR的最大数量。设备？ - 不幸的是我需要配对，而大量电话到我的设备（S）

。

3. 我或许可以从设备配对数据（长期键等），并将其存储在某些外部存储器，增加此限制。

4. 我可以让没有配对一个安全的数据连接到设备上，或者通过重新配对时，我必须这样做？ - 如何安全是这个程序的问候MITM攻击

？

我似乎无法找到明确地回答这些问题的任何文件。任何想法或指针将是最欢迎的。

解决方案

这里是我的两分钱：

1. AFAIK，BLE配对/加密过程是不是有缺陷的。然而，有三个层次的中间人保护可用加密：

   • 无，这将已知关键== 0，因此，如果窃听者映入你在配对过程中的所有数据包，他可以按照你的加密连接。
   • 低MITM保护，这是当你使用一个用户输入万能密钥配对，与关键＆LT; 1.000.000。在这里，窃听者只需要尝试一百万钥匙。
   • 高的MITM保护，使用带外的一个键。这将提供一个完整的128位的强度为您的加密，和窃听者需要知道遵循即使捕捉整个配对处理的会话密钥。由于在BLE没有密钥交换方法（然而，至少），这里最薄弱的环节。将密钥分配，但是这将是同样的问题在应用层具有加密的附加层时相同。

2. 这是实现有关。您的设备不具有粘结，即与主机建立一个永久的关系。如果设备不粘结，没有国家讲述更早连接（而不是交换的数据等，但就是应用程序域，不BLE堆栈）。如果设备不粘结，他们将在下次连接到Exchange受保护的数据再次进行配对。如果设备所键合的加密连接，可以继续进行，没有应用程序/用户交互，具有相同的安全级别如前面。对于一次性连接设备，邦定是没有意义的，所以你可以有一个无状态的实现与连接设备的数量没有限制。对于多时间连，你也可以拥有一个无状态的实现，这取决于你如何分发/存储键（S），然后独立BLE的。不同选项的可用性这里取决于你正在使用，但该设备/ BLE栈的实现，但规范允许这一切。

3. 如果你的债券，从而交换长期的按键等，这些都可以，取决于BLE实现你的基础上，但是被存储你喜欢的。

4. 正如我在2说，你可以建立不绑定一个安全（加密）连接。该设备，那么需要他们希望建立一个安全的连接，下一次再次配对。如果你不想/不能配对出于某种原因，那么你就只能有明文通信。

I need to send some sensitive data over a Bluetooth Low Energy (BLE) data connection between a smartphone (iOS & Android) and an embedded device (CC2540 chip).

Since I don't consider the app-code on the phones to be safe from hacking, I need to rely on BLE safety to get my encrypted package delivered from the server to the device once and once only (I must assume that any second attempt to deliver the package, must be from an attacker).

I have been browsing the net a few days now, to find out if my data is safe, and under which conditions. Unfortunately I haven't been able to come up with a simple answer to my questions.

1. Is my data safe if I pair the phone to the device? - I suppose so, though I understand that the pairing process itself is flawed, so it is theoretically possible for some man-in-the-middle (MITM) to sniff the encryption keys during the pairing process and thus compromise the connection.

2. I need each device to be paired to several phones (but only communicating to one at a time). What's the maximum number of pairings pr. device? - unfortunately I need to pair a rather large number of phones to my device(s).

3. Can I perhaps get the pairing data (Long term keys etc.) from the device and store it on some external memory, to increase this limit.

4. Can I make a safe data connection to the device without pairing, or maybe by re-pairing when I need to do so? - How safe is this procedure with regards to MITM attacks?

I can't seem to find any documents that answer these questions unambiguously. Any ideas or pointers will be most welcome.

解决方案

here's my two cents:

1. AFAIK, BLE pairing/encryption process is not flawed. There are however three levels of MITM protection available with encryption:

   • None, this uses a known key == 0, so if an eavesdropper catches all your packets in the pairing process, he can follow your encrypted connection.
   • Low MITM protection, this is when you use a user input pass key for pairing, with key < 1.000.000. Here the eavesdropper would only need to try a million keys.
   • High MITM protection, using an out-of-band key. This would give a full 128-bit strength for your encryption, and an eavesdropper would need to know the key to follow the conversation even if catching the whole pairing process. As there is no key-exchange method in BLE (yet, at least), the weakest point here would be the key distribution, but that would be the same problem as when having an additional layer of encryption at the application level.

2. This is implementation dependant. Your device doesn't have to bond, i.e. establish a permanent relationship with the host. If the devices don't bond, there is no state telling about earlier connections (other than exchanged data, but that is application domain, not BLE stack). If the devices are not bonded, they would have to pair again the next time they connect to exchange protected data. If the devices are bonded, the encrypted connection can be continued without app/user interaction, with the same security level as earlier. For one-time-connect devices, bonding doesn't make sense, so you can have a stateless implementation with no restrictions on number of connected devices. For multiple-times-connect, you could also have a stateless implementation, depending on how you distribute/store the key(s) which is then independent of BLE. The availability of the different options here depends on the device/BLE stack implementation you are using, though, but the spec allows all this.

3. If you bond and thus exchange long term keys etc, these can, dependent on the BLE implementation you're building on, be stored however you like.

4. As I said under 2., you can establish a secure (encrypted) connection without bonding. The devices then need to pair again the next time they want to establish a secure connection. If you don't want to/aren't able to pair for some reason, then you can have only plaintext communication.

这篇关于蓝牙低耗能加密和数据安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！