We're starting to see Bluetooth Low Energy (BLE) show up everywhere. Fitness trackers, IoT doohickeys, deadbolt locks and even security tokens are showing up with BLE. By treating your cell phone as the center of life, things have never been more convenient.
BLE itself is simple in all axes. It uses a well understood and simple physical layer. It limits the number of link layer states, keeping relationships between devices simple. There's even a standard for encrypting and authenticating data going across the link. Programmers can focus on messaging based on capabilities (General Attributes, or GATT), rather than building complex transport protocols.
This simplicity comes with at a cost. The modulation for the channel allows for a theoretical top transmission rate of 1Mbps. Considerations around modulation, negotiated channel transmit rates and power consumption will impact this. And of course, SnR is a dominant factor in performance, too.
BLE lives in the same spectrum as Bluetooth, WiFi, ZigBee and other wireless protocols. This is a busy chunk of spectrum, from 2.4000 GHz to 2.4835 GHz. Of course, this lowers your SnR, which will not help your situation. In a practical sense you are better off designing for a rate closer to 0.075 Mbps (~10KiB/sec). But then again, this is a lightweight, low-energy protocol. You weren't expecting oodles of bandwidth, right?
We've talked a bit about building a lightweight secure channel in the past. As always, this is about making the right trade offs. Pairing devices is a first step. Pairing is not a security feature, though. An attacker can intercept, man-in-the-middle and inject traffic without much pain. Even when paired, we're suffering from the threats inherent in any wireless medium.
BLE has a provision for AES-CCM-128 encryption of all traffic between two 'bonded' devices. This is great for avoiding snoopers. But, you're still faced with the challenge of key exchange. The specification punts on this, more-or-less. So you either swap the initial keys in plaintext ('just works' mode), or you derive a key using out of band functionality on your device. This isn't the end of the world, but it isn't making life easier, either.
So What Needs to be Secure?
To sound like a broken record, what this all comes down to is your threat model. What information is sensitive, where could interoperability be more important? What messages are sensitive and who do you want to verify sent those messages? Where are you rooting trust anyways? If you're using the user's phone, this opens a whole can of worms. Can you even trust the phone? This could render the BLE Security Manager features moot for your application's purpose*.
For example, let's say your peripheral device has a battery. Would exposing the Battery Service disclose sensitive information? Maybe not, especially if you integrate that value over seconds.
Say your device requires accurate timestamps for cryptographic purposes. Would you want to use the Current Time Service or Time Profile Service? Trustworthy time is central to many cryptographic operations. The BLE profiles rely on the link layer enforcing trust, so this might not be desirable. Assuming you don't trust one of the devices, this can make life challenging.
There's no standard profile for a cryptographic token though. You'll likely expose such services through custom GATT attributes.
Encrypting the Link
A lot of engineers feel like AES is a silver bullet in this case. By using AES at the link layer, all their communications are secure, right? Depending on how you derive the key, this is likely not the case. In BLE 'just works' mode, your initial keys get sent about in plaintext. No thank you, a determined attacker could watch that exchange. You're as well off as if you were sending the attacker the keys by email. Let's not even get into the fact that the link layer key is only as secure as the peripheral and central devices, too.
Running with the example of a cryptographic token, any good token will have a trusted display. This display might be an OLED or eInk display that shows messages, prompts and codes for the user. An eInk display could even display a QR code. A user could photograph this with their smartphone, to communicate details about the device. This can help with pairing devices, providing the needed key material exchange. This raises the bar for an interloper to snag your communications.
The BLE standard uses the term 'Authentication' to imply many things. Usually this centers around two devices pairing with eachother. In a cryptographic sense, we want to verify what key generated a 'signature' for a message. To authenticate the sender as a particular central device, the AES-CCM-128 this will do just fine. But if you don't trust the device relaying the messages, then you need to be a bit more clever.
Authenticating the Message Origin
For custom GATT attributes we could attach a running HMAC to each message on that attribute. You would attach the HMAC to a message at your back-end service. This way, there's a lower chance of the central device tampering with your message.
We've discussed why HMAC is great for this use case (with the right policy). By using HMAC, we know the sender was in possession of a shared secret. Keying a device with an HMAC key is beyond the scope of this, but we've discussed some ideas in the past.
If you need to authenticate commands to and from a back-end service, you can't use the built-in profiles, at least not as-is. But that isn't the end of the world, since custom GATT attributes are easy to define and use.
Wrapping it Up
BLE is an enticing way to swap data between two embedded devices. But like any wireless link, it's easy to intercept messages and inject malicious traffic into the conversation.
The Security Manager enciphers and authenticates messages at the Link Layer. But, this only allows you to authenticate the originating device. If your application requires authenticating messages from a back-end service, you'll need something custom. We've discussed how to build a lightweight secure channel in the past. By applying these principles, we can make certain guarantees about for our application. Using the link layer Security Manager features means we can give our users a measure of privacy.
* If your application's security model doesn't allow you to rely on link layer security, you should still use it. With proper device bonding, you can at least provide a measure of privacy for your user.
Addendum
Some further research has led me to the realization that BLE link layer security is a hopeless mess. In iOS, Apple has chosen to only allow third-parties to support link layer security through a 6-digit passcode or 'just works' at bonding time. The out-of-band mechanism seems to only be available to the iWatch.