Is there a way in iOS or Android to set up a Bluetooth passkey passcode whenever another device wants to connect to my device via Bluetooth?
My application involves a BLE client connecting to a BLE server and the two devices will transmit data between each other. However, the data transmitted will be very sensitive security-wise. So beyond the standard encryption my goal is to not initiate data transmission until both devices have authenticated each other (e.g., with a passkey).
It seems like a Bluetooth passkey is something set up by the device manufacturer and not something able to be configured by the user. If so and there is no passkey pairing, would an acceptable alternative be to require a passkey to be exchanged (after the devices are paired) before the devices can transmit any sensitive data?
On a Android phone, assuming the phone is GATT server (which provides data for a client device to read), you can safeguard that data held in a characteristic by setting its read permission to PERMISSION_READ_ENCRYPTED_MITM .
For example, when you create a characteristic to be registered with the Bluetooth stack in Android, you do
BluetoothGattCharacteristic characteristic = new BluetoothGattCharacteristic(YOUR_UUID, BluetoothGattCharacteristic.PROPERTY_READ, BluetoothGattCharacteristic.PERMISSION_READ_ENCRYPTED_MITM)
In this way, anyone who wants to read the characteristic needs to create a secure bonding with your phone first, either by entering a passcode or compare two numerical values. The exact way for pairing is up to the Bluetooth stacks of both devices to negotiate (based on available IO on the client).
On the other hand, if the data you want to access is stored in a third remote device, and you don't need authentication (bonding/pairing) to read from it, and you cant access the firmware. Then you can not enforce secure transmission unilaterally from your phone.
Related
I'm using BlueZ 5.49 and trying to connect, pair, and pass information between two different bluetooth devices.
It's seems like i have problem with enforcing security and authentication between the two.
I'm configuring each hci device with:
hciconfig hci0 pscan auth encrypt which as i read, is setting the device to security mode 3.
In addition i'm creating manualy this path in both sides: /var/lib/bluetooth/<local_bdaddr>/<remote_bdaddr>/info with LinkKey.
I've noticed that if i'm creating the path for only one device, and then trying to connect using rfcomm connect from the device without the infofile, the connection succeed, even though the device is lacking the info file which containts the LinkKey.
If i'm trying rfcomm connect from the device with the info file i'm getting Key Exchange Error, which is acceptable since the other device doesn't have the key.
My base line is that it seems that security and authentication are not enforced.
Many Thanks,
Liad
Apparently hci device is by default set to work in Secure Simple Pairing also known
as sspmode. Simple Pairing originaly generated to support devices that can't insert pin code during pairing process (such as headset).
Hence when a device is in sspmode enabled, it use a default pin key - say 0000, and then based on the pin, generating LinkKey to encrypt and authenticate, and thus not truely enforcing authentication as i mentioned before.
The line hciconfig hci0 sspmode disable is disabling the Secure Simple Pairing mode, and finally enforce authentication using the static LinkKey you supply
in the info file which located in /var/lib/bluetooth/<your_mac>/<remote_mac>/info.
I am investigating the types of security available in Bluetooth Low Energy (BLE) related to GATT. More specifically, what kind of operations are done when using gatttool with different security levels specified (low, med, high)? My understanding is that the Security Manager in BLE supports 4 different security properties:
no pairing
pairing with an association model that doesn't support man-in-the-middle (MitM) protections (JustWorks)
pairing with MitM protections (passkey entry, numeric comparison, OOB)
LE Secure Connections pairing.
Are these security properties related to the security levels specified with gatttool or is there some other security feature I missed while reading the Bluetooth Specification?
Edit: I would like to extend my question in order to clarify the issue. How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
You are correct but you forget one main threat in BLE communication. Here are the three basic threats :
Man In The Middle (MITM) :
A MITM requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel
Eavesdropping :
Passive Eavesdropping is secretly listening (by using a sniffing device) to the private communication of others without consent
Privacy/Identity tracking :
Since most of the Bluetooth LE advertisement and data packets have the source addresses of the devices that are sending the data, third-party devices could associate these addresses to the identity of a user and track the user by that address
The quotes come from developer.bluetooth.org.
You already mentioned the protections against MitM and Eavesdropping, however there is still the problem of identity tracking.
The protection against identity tracking is to use a MAC address that cannot be linked to the same device through time, i.e. a MAC address that changes (typically every 15 minutes). There are four types of MAC address :
Public address : This address is unencrypted and contains your company unique ID and your device ID. It's unsafe since it does not change through time.
Random static address : This address is random (and known as random thanks to flags inside) and unencrypted. Once it does change, you loose the ability to reconnect with the devices that already knows you, you've got to restart the connection from scratch.
Random resolvable private address : This address can be resolved by the devices that know its IRK, a shared secret between the devices. As for the static random address it changes often but is always resolvable. It's the most common option since it preserves privacy and allow to restore a connection.
Random non-resolvable private address : This address cannot be resolved. The Core Spec doesn't say that much about it and it seems not to be very common. The difference with the static address is that it is not stored since it's a private address (i.e. a device doesn't expect to be able to restore a connection with a private address device).
This is explained in BLE Core Spec 4.2 Vol. 3 Part C 15.1.1 Bluetooth Device Address Types.
Concerning the security level, I don't know gatttool but I will assume it's somehow similar to nRF Connect/Master Control Panel or LightBlue. What you see here is probably the security level associated with each attribute. There are four security levels and they can be different for each attribute :
Mode 1 Level 1 :
No encryption required. The attribute is accessible on a plain-text, non-encrypted connection.
Mode 1 Level 2 :
Unauthenticated encryption required. The connection must be encrypted to access this attribute, but the encryption keys do not need to be authenticated (although they can be).
Mode 1 Level 3 :
Authenticated encryption required. The connection must be encrypted with an authenticated key to access this attribute.
Mode 1 Level 4 :
Authenticated LE Secure Connections pairing with encryption. The connection must be encrypted using the Secure Connection Pairing, which was introduced in Bluetooth LE since version 4.2.
The definitions of modes 1 level 1-3 come from 'Getting Started with Bluetooth Low Energy' by Robert Davidson, Akiba, Carles Cufi, Kevin Townsend.
The device can also be in a mode called Secure Connection Only in which all its services, except the one in Mode 1 Level 1, can only be accessed in Mode 1 Level 4.
How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
During the pairing feature exchange stage, if the Secure Connections (SC) flag is set in the Pairing Request and Pairing Response PDUs, then LE SC is used. It indicates that both devices support LE SC and agree to use it.
If LE SC is used, the logs will show "Pairing Public Key" and the "Pairing DHKey Check" PDUs being exchanged. These are specific to LE SC.
Yes it's correct but you should note that their are still exists security mode,LE security mode 1 and LE security mode 2, which is combined by different security levels. And before Bluetooth 4.2, LE is not secure i.e. you can sniffer the encrypt key at the just beginning of the LE connection.
Right now I can successfully pair and connect a phone to my machine without any user interaction in this way:
$bluetoothctl
#power on
#discoverable on
#pairable on
#agent NoInputNoOutput
#default-agent
from my phone I search for the BT device and it pairs and connectly automatically. Now I have two problems:
it still asks to authorize services:
Authorize service
[agent] Authorize service 0000110e-0000-1000-8000-00805f9b34fb (yes/no):
but this is not good because I've specified NoInputNoOutput!
how to trust a device? It's enough to type trust but I need to do this automatically for the same reason.
In general, is there any reliable C++ library to handle bluetooth connections and common profiles like A2DP and HFP?
I used bt-agent with NoInputNoOutput capabilities and that didn't ask for any permissions for A2DP and HFPprofiles.
bt-agent --capability=NoInputNoOutput
check the link for more details.
https://www.kynetics.com/docs/2018/pairing_agents_bluez/
In general, two communicate between bluetooth devices, first we perform a bluetooth pairing between two devices and then starts further communication between them.
My problem scenario is simply to transfer a hello packet from one bluetooth device to another bluetooth device.
For this i am planning to use sockets programming technique i.e. RFCOMM sockets.
I got some help about this from http://people.csail.mit.edu/albert/bluez-intro/x502.html
So, my query is do we require bluetooth pairing between two devices before initiating communication with RFCOMM socket connection.
Or does 48 bits device address is only necessary to transfer some data packet from one bluetooth device to other and bluetooth pairing could be avoided.
No, it is not.
Bluetooth device can be in one of the four modes:
Broadcaster
Observer
Peripheral
Central
In broadcaster mode device can only send advertisement messages. This includes name and HwID.
In Observer mode device can only receive advertisement messages.
Peripheral = Broadcaster + can take in connect requests
Central = Observer + can send out connect requests.
If you have an application which does not want to connect use first two modes above.
Please let me know if this addresses your question.
I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.