4

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?

2

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.

  • 1
    thank you. That's a very enlightening answer. That NIST document you mentioned, I actually downloaded and read it a few months ago, but I just wasn't confident in my own interpretation and wasn't able to apply the knowledge to my situation like you do. Another thing is, I think I am using Bluetooth Classic (BT in your term) because all the programming techniques I use were old (from 10+ years ago). In any case, your analysis is convincing. Thank you very much. – Nick Lee Sep 1 '17 at 11:37
  • @NickLee You mentioned that you're running Bluetooth 4.1, so the approach can't be older than December 2013. – Polynomial Sep 1 '17 at 13:31
  • 1
    The Bluetooth adapter on Raspberry Pi is 4.1. That's what I meant. Software-wise, I use techniques that have existed since the very early days. – Nick Lee Sep 2 '17 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.