Secure Provisioning
In this next part of his article series on Bluetooth mesh, Bob looks at how to create secure provisioning for a Bluetooth Mesh network without requiring user intervention. He also takes a special look at an attack called Man-in-the-Middle which Bluetooth’s asymmetric key encryption is vulnerable to.
By Bob Japenga
Both of our cars are more than 15 years old. My only new car envy is with the lack of a modern audio system. With a rental car, I’m always envious of the Bluetooth support and the seamless way I can connect and reconnect my phone to the car’s system. Most of the new audio systems are well thought out and easy to use. For my birthday, I got a Bluetooth device that would connect my phone to my dumb audio system in both cars. I have been very happy with the devices although they have two quirks. One is that they don’t work when the car has been left outside and it’s below zero. After the car warms up, it will happily function. But it doesn’t like subzero temperatures.
The other quirk—pointed out by my grandchildren—is that when it powers up, it announces: “Waiting for Pairing.” And then when it is paired, it reports “Paired.” The quirk is that instead of saying “Waiting for Pairing” it sounds like it is saying “Waiting for Perry.” The first time my grandkids were in the car, they asked: “Who is Perry and why are we waiting for him?” Now I can only hear “Waiting for Perry” when I turn on the car.
Pairing is the way two standard Bluetooth devices establish the initial link for one-to-one networking (Figure 1). Bluetooth mesh needs a much more sophisticated and secure method of linking the many-to-many network. That method is called provisioning. I introduced Bluetooth mesh provisioning in my last article (Circuit Cellar 345, April 2019) [1]. So, if you haven’t read that article, as a minimum, it will be important to go back to understand the terms that were defined in that article and which I will be using in this article.
— ADVERTISMENT—
—Advertise Here—
Figure 1
Pairing is the way two standard Bluetooth devices establish the initial link for one-to-one networking.
As I mentioned last time, the Bluetooth specification [2] states that only if an Out-of-Band (OOB) public key is used or if an OOB action is taken to pass the public key (using user supplied information), “provisioning is Insecure Provisioning.” This statement will basically jettison any project that does not use one of these two OOB methods when presented to a savvy IT group. It did for us. Imagine presenting to your CEO a new product line using Bluetooth mesh that doesn’t use one of these two methods. Most likely the savvy CEO will ask: “What is the projected return on our investment?” AND “Is it secure?” Would you want to say: “Well, we are using Insecure Provisioning but other than that it is secure?”
I’m not convinced that the specification is entirely accurate in this statement and would appeal to the Bluetooth SIG to reconsider their wording. I want to elaborate on this idea in this article and provide some means for making provisioning secure without using either of the two OOB methods to pass the public keys.
Man-in-the-Middle
As I mentioned last time, Bluetooth uses asymmetric key encryption during the first part of provisioning. Asymmetric key encryption has one basic security flaw. It is subject to what is called a Man-in-the-Middle (MitM) attack. Let me illustrate this attack.
Imagine that Bob and Barbara are happily married. I know, normally everyone uses Alice in these illustrations, but my wife’s name is Barbara. They want to communicate some secret birthday plans about their grandson Sean. So, they both send over clear text their public keys (B1 and B2) (Figure 2). Bob encrypts all of his messages with Barbara’s public key B2, and sends them to Barbara. Barbara decrypts all of Bob’s messages using her private key B2P. Barbara sends all of her messages to Bob using Bob’s public key B1 to encrypt the data. Bob decrypts Barbara’s messages with Bob’s private key B1P.
Figure 2
Shown here is an example exchange that would be insecure because it would be subject to a Man-in-the-Middle attack. However, during normal asymmetric key encryption, the attack can be prevented through authentication.
Imagine that grandson Sean is a curious computer whiz and wants to know what’s he is going to get for his birthday. He intercepts the public key exchange B1 and B2 between his grandparents. Instead of passing on their public keys, he sends them his public key S1. So, when Bob and Barbara send their messages encrypted with S1 to each other he intercepts them and decrypts them using his private key S1P since they are encrypting their messages with his public key S1. He finds out what he is getting for his birthday and then encrypts the messages using Bob and Barbara’s public keys and sends them back to them. Bob and Barbara are clueless to the fact that Sean now knows what he is getting for his birthday.
That example illustrates that, if during the provisioning process, the public keys are not exchanged OOB, the process would be insecure because they would be subject to a MitM attack. However, during normal asymmetric key encryption, the way this can be prevented is through authentication. If Bob can know that a key is authentically from Barbara, he would immediate recognize that the key that Sean sent was not from Barbara. During normal Internet asymmetric key encryption this authentication is done through Certificates of Authority created by a trusted signing authority.
The Bluetooth provisioning process includes authentication of the device as part of the process. Authentication can either be using an OOB technique or without OOB. So, I would contend that if you use some means of authenticating that does not transfer the credentials over the Bluetooth network, your provisioning process would be secure in spite of what the Bluetooth specification says (I am definitely treading on thin ice here!).
…
Read the full article in the June 347 issue of Circuit Cellar
— ADVERTISMENT—
—Advertise Here—
Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
Circuit Cellar's editorial team comprises professional engineers, technical editors, and digital media specialists. You can reach the Editorial Department at editorial@circuitcellar.com, @circuitcellar, and facebook.com/circuitcellar
