Is a no-pairing, no-password Bluetooth RFCOMM connection secure?

Question

I have programmatically established a Bluetooth RFCOMM connection between a Desktop PC (client) and a Raspberry Pi (server, Bluetooth 4.1). There is no request for password and no request for pairing during the process. I am sure the connection works because I am able to send data between them.

I am not sure the RFCOMM connection is encrypted, though. Information found on the web is either vague, or seems to qualify the security condition to only paired devices or situations where passwords are supplied. There are also hints that RFCOMM connections may be secure after all (e.g. here). I am just not sure.

Can anyone give a definite answer?

Answer 1

Chances are you have no resistance against man-in-the-middle attacks.

There are two standards here, Bluetooth (BT) and Bluetooth Low Energy (LE). Each has a different approach to encryption and authentication and can support multiple levels of security.

NIST has a fairly fantastic paper on Bluetooth security which I'll draw upon for my answer, since it's very comprehensive but also quite easy to follow.

BT has four security modes that a device can operate in. The details of what each mode can do are rather complex, so I'll simplify it thusly: Security Mode 1 has no authentication or encryption, Security Mode 2 enforces authentication and encryption at a per-service level but does not authenticate or encrypt the link layer, Security Mode 3 is authentication and encryption at the link later, and Security Mode 4 is a more secure version of mode 2 with multiple levels of security enforcement allowing for the selection of authentication, no authentication, or security entirely disabled for each service offered.

When authenticating, BT uses any of a number of key exchange methods. The most commonly seen is a 4-digit PIN, which is a legacy authentication mode. There is support for longer pins too, including alphanumeric entry, which provides more security. Then you've got Secure Simple Pairing (SSP) which works with Security Mode 4, allowing for authentication by PIN, password, an unauthenticated mechanism called "Just Works" (encryption but no resistance to MitM), and out-of-band (OOB) key exchange over the internet, NFC, or another channel.

LE has support for authentication, encryption, and signing, but must be put into one of two security modes. Each mode has levels controlling the type of security in use.

• Security Mode 1 has the following options:
  1. No authentication or encryption.
  2. No authentication, but traffic is encrypted.
  3. Authenticated pairing and traffic encryption.
• Security Mode 2 has the following options:
  1. Unauthenticated pairing with data signing.
  2. Authenticated pairing with data signing.

Authentication is also fairly configurable. You can perform OOB authentication, which involves exchanging the temporary key over another transport mechanism (e.g. internet, NFC), or you could use PIN entry (this is very common) to generate the temporary key on each device. There's also a mechanism called "Just Works", the same as in BT, which sets the temporary key to all zeroes, which still enables transport encryption, but anyone monitoring the communications during the handshake can get the long-term key and decrypt the traffic.

RFCOMM is a service under both BT and LE, so your security depends on which protocol you're using, which security mode you're in, and which level you're using where applicable. As you mentioned that you're not pairing at all, it makes me think you're probably using LE, which isn't really designed for pairing in the same way that BT is. In either case, you're not entering a PIN or performing any kind of authentication, which means that you either have no transport encryption at all (e.g. BT Security Mode 1 or LE Security Mode 1, Level 1) or you have transport encryption enabled but on an unauthenticated key exchange (e.g. LE Security Mode 1, Level 2). In either case you can sniff the traffic with a tool such as the Ubertooth One and dump the contents.