Chapter 11. Security
There are two types of encryption: one that will prevent your sister from reading your diary, and one that will prevent your government.
—Bruce Schneier
11.1. Security Concepts
Security is a complex subject that for many people is just a black box. If the technology is secure, that is enough for lots of people. However, there are many things about security that need to be understood in the context of Bluetooth low energy. These include the following topics:
• Authentication
• Authorization
• Integrity
• Confidentiality
• Privacy
11.1.1. Authentication
Authentication is defined as a way to prove that the device with which you are connecting is actually the device it claims to be and not a third-party attacker. This is done by using two basic methods:
• Initial authentication and sharing of a secret
• Re-authentication using a previously shared secret
For example, when a user opens a bank account, she must provide documentation to prove that she is who she says she is. This authenticates the user to the bank, typically because the bank trusts the issuers of these documents. Passports, identification cards, and other government-issued documents such as a driver’s license are typically used for this. The bank then gives the customer a plastic bank card and a Personal Identification Number (PIN) that she can use at a later time to re-authenticate herself with the bank. When the customer wants to remove money out of this bank account she must authenticate herself to the machine by using the card and the shared secret PIN. Any person who has that card and that PIN can authenticate himself as the account holder to the bank—even if he isn’t in actuality.
In Bluetooth low energy, authentication is performed in three different ways:
• During the initial pairing of devices, an authentication algorithm is used to authenticate the connecting device. This might involve entering a passkey into one or both devices. This allows the link to be encrypted, and any shared secrets that will be required later can be distributed. When these shared secrets are stored, the devices are said to be “bonded.”
• When reconnecting to a device with which you have previously bonded, one of these devices can send a signed command to the other device to authenticate that it knows the shared secret that was previously distributed. The signature is created by using the shared secrets exchanged at bonding, and as such, it cannot be falsified by a third party. Part of this signed command must be a counter that is incremented for each message sent to prevent replay attacks.
• When reconnecting to a device with which you have previously bonded, either device can initiate encryption. Each and every data packet that is transmitted from then on will incorporate a message integrity check (MIC) value that authenticates the sender of that message to the other device by using the previously distributed shared secrets.
11.1.2. Authorization
Authorization is defined as the assignment of permission to do something. This is usually done in two ways:
• Documentation that provides authorization
• Authorization that is actioned directly
A concert normally has few, if any, authentication requirements, but authorization to enter the concert is typically enforced by using something called a ticket. These tickets are provided by the event organizer to the guest who presents the ticket at the concert as authorization to enter. There is no authentication that the person holding the ticket is the same person who authenticated the payment for these tickets; in other words, no photo identification is needed.
Another example of authorization is the instant approval to allow somebody to do something. For example, if you quickly lent somebody your computer and ask him only to use a single program, you are authorizing him to use that program and no others.
This same authorization model can also be used wirelessly. When something connects with your device, you can authorize it to access certain parts of your device, but not everything within it.
11.1.3. Integrity
Integrity is defined as the internal consistency and lack of corruption of data. When any data is sent from one device to another, either by using a wired or wireless communications protocol, the data is subject to introduced errors. These errors are important to detect and guard against.
From a security point of view, some errors could be introduced by a third-party attacker to attempt to change a valid message into a malicious message. For example, by replaying a captured message but changing one bit in a message that means “lock door” to “unlock door,” the security of a building could be severely compromised. It should be noted that cyclic redundancy checks (CRC) are used to protect against bit changes, but these are typically too weak to be considered a security measure. It is too easy to change not only a few bits in the message but also a few bits in the CRC to match. To ensure integrity, a much stronger form of message authentication is required that also checks the integrity of the original message.
11.1.4. Confidentiality
Confidentiality is defined as the intent to keep something secret. The most common representation of confidentiality is in films when you see the characters handling company or government reports marked as “confidential.” Unfortunately, this is not a good use of the word because anybody who can see that report can read it. In Bluetooth low energy, confidentiality means that even if a third-party eavesdropper receives a message, she cannot decode it. The process of enciphering a message is called encryption. The enigma machine developed during the second world war is a classic example of a device that could encrypt or decrypt a message.
11.1.5. Privacy
Another security concern that should be considered is how private any communication is. Complete anonymity is difficult to provide. Take, for example, a famous person boarding an aircraft; there are plenty of people who will recognize him just by his face. It is therefore almost impossible to be granted complete anonymity in every location.
Wireless communications should not make it easy to track somebody. If the devices that somebody carries are constantly allowing other parties to track his movement throughout a space, there could be some interesting and spooky consequences. For example, stores might give you special offers based on what you have bought in other stores. That’s not so bad, right? But a stalker could seed an area with devices and automatically track you through that area, which is a less attractive prospect than getting a few discounts.
Thus, privacy is the ability to prevent others from recognizing you by the devices that you are carrying, and not to allow them to track your movement throughout a space.
11.1.6. Encryption Engine
Within Bluetooth low energy, there is a single cryptographic block that is used as a one-way function to generate keys and also to encrypt and provide integrity checks. This encryption engine is called the Advanced Encryption System (AES) as defined by the NIST publication FIPS-197.1 Bluetooth low energy uses the 128-bit version of this, known as AES-128.
A generic way of looking at AES is to consider a single function, E, that takes both a key and some plain-text data, and results in a cipher-text data block. AES is therefore a block cipher. The key is 128 bits in length, the plain-text data is 128 bits in length, and the resultant cipher-text is 128 bits in length. This can be expressed as shown in Equation 11-1:
It is interesting to note that if the key doesn’t change rapidly, the algorithm is very efficient. Each time a new key is used, lots of calculations need to be performed to set up the internal state of the encryption engine. After the setup is performed, each new plain-text value that is input can be quickly converted into cipher text. The security algorithms in Bluetooth low energy make use of this property of the AES encryption engine.
11.1.7. Shared Secrets
Virtually all security is based on shared secrets. You bank card’s PIN is a secret that is shared between you and your bank. Your computer password is a secret that is shared between you and either your computer or your company’s information systems departmental computers. Your house key is a shared secret between the metal that you hold in your hand and the physical formation of the metal within the door lock.
Within Bluetooth low energy, there are many shared secrets known as keys. A key is just a shorthand way of saying “shared secret.” There can be plenty of keys, just like you have a car key, a door key (or two or three), a bicycle lock key, or a key to access your work.
There are five main keys in Bluetooth low energy:
• Temporary Key
• Short-Term Key
• Long-Term Key
• Identity Resolving Key
• Connection Signature Resolving Key
11.1.7.1. The Temporary Key
The Temporary Key (TK) is used during the pairing procedure. It is set to a value that is determined by the pairing algorithm and used to calculate the Short-Term Key.
“Just Works” is a mode designed to make connection to Bluetooth low energy devices possible when very limited user interfaces prevent user entry or verification of pass key values. The TK value when using “Just Works” is zero. This means that there is no authentication being performed and therefore this connection and any keys distributed over it would be vulnerable to man-in-the-middle attacks.
“Passkey Entry” is a mode used when the user interfaces on both devices allow at least the display or entry of a number value. The TK value when using the “Passkey Entry” algorithm would be set to the numeric value that is to be input on both devices. This numeric value is a value from 0 to 999999. This means that there is a significant probability that a man-in-the-middle attack will not guess the same value that is being used by the connection. There is only a one-in-one-million chance that the right value is guessed. For authentication, this is a reasonable probability; therefore, a key generated using this algorithm is considered an authenticated key, protected from man-in-the-middle attacks.
The last TK value is when the “Out Of Band” algorithm is used. This is when both devices have information that has been acquired by using another technology than Bluetooth. For example, if Near-Field Communication (NFC) was used to transfer a value between the two devices, this value can be used as the TK value for authentication. A key generated by using out-of-band data is considered authenticated and protected from man-in-the-middle attacks because it is assumed that the out-of-band technology is also not subject to these types of attacks.
11.1.7.2. Short-Term Key
The Short-Term Key (STK) is used as the key for encrypting a connection the very first time two devices pair. The STK is generated by using three pieces of information: The Temporary Key is used as the key for the encryption engine, and two random numbers, Srand and Mrand, are contributed by both the slave and master devices in the initial pairing request. Srand and Mrand are concatenated with the | symbol, as illustrated in Equation 11-2 and then encrypted using the Temporary Key.
The contribution of random numbers by both the slave and the master increases the security of the whole system because any attacker can only contribute 64 bits of the 128-bit random value. It is much harder for a man-in-the-middle attacker to guess which one of 264 possible values the peer device used.
11.1.7.3. Long-Term Key
The Long-Term Key (LTK) is distributed once the initial pairing procedure has encrypted the connection. The LTK can be a random number that is stored in a security database. It is also possible that the LTK is generated on the slave device.
Slaves are by design resource-constrained, so having a security database might be considered too much. To solve this problem, the slave also distributes two other values: EDIV and Rand. These two values are stored on the master and sent upon a reconnection to the slave. The slave can then calculate the LTK that should be used, or more accurately, the LTK that it had previously given to the master.
Upon reconnection to a previously paired and bonded device, the LTK is used to encrypt the link. This means that full pairing is not required each and every time a device connects.
11.1.7.4. Identity Resolving Key
The Identity Resolving Key (IRK) gives a device that knows a peer device’s IRK the ability to resolve (work out) a peer device’s identity. Privacy could be performed by always using a fully random address. These devices could change their random addresses at random times, and the device would not be trackable or even connectable by any trusted device. The problem is how to be both private due to using a random address, and also be identifiable by trusted devices.
To solve this problem, the IRK is used when generating the random address. This is done by splitting the address into two parts: a random part, and a hash of this random part with the IRK, as shown in Equation 11-3.
By placing both the random number and the hash into the address field, a peer device that knows the IRK can be checked to see if they match.
One way to think of this is to consider a private person who uses a different alias each time he talks to another person. To keep this simple, assume that instead of 224 possible name pairs, we have just three. The first time he could be known as “Floella Benjamin,” the next time as “Bob Hope,” and the next time as “Charlie Dimmock.” If you see the names Floella with Benjamin, or Bob with Hope, and so on, then you know it is that person. If the name were “Floella Hope” or “Bob Dimmock,” it is not that person because “Floella” always comes with “Benjamin.”
Therefore, it’s possible for a device that has a list of IRKs for each separate bonded device to do an exhaustive match on each of these IRKs with the received private addresses. A match likely means that the correct device has been found.
It should be noted that there is not a one-to-one correspondence of devices to random numbers and hash values. There are approximately 70,000 billion possible fixed device addresses and, therefore, devices, yet there are only 4 million random numbers that can be used. Therefore, there is a reasonably high probability that for two given devices with the same random number and different IRKs, it would be possible to have the same hash value. This is why privacy is typically combined with authentication to ensure that it really is the correct device and not somebody who has the same combination of address parts.
11.1.7.5. Connection Signature Resolving Key
The Connection Signature Resolving Key (CSRK) gives a receiving device the ability resolve a signature and therefore authenticate the sender of the message. The CSRK is distributed from the source of the message to the destination device for the message. Once distributed over an encrypted link, the link can be disconnected. Upon reconnection, because the message only needs to be authenticated and not sent in a confidential matter, the message can be signed.
To sign the data, the CMAC function defined by NIST Special Publication 800-38B2 is used. This uses the CSRK as the key for this function, along with a Sign-Counter. The SignCounter is a 32-bit value that must be incremented for each message from the source device to the destination device for the duration of the bond. The SignCounter is set to zero immediately after bonding and incremented for each new packet sent, regardless of whether the devices disconnected in the meantime.
11.2. Pairing and Bonding
To enable most of the security features in Bluetooth low energy, two things must happen: The devices must pair with each other, and then once the connection is encrypted, they must distribute keys that can be used to encrypt, enable privacy, and authenticate messages. If these keys are saved for a future time, the devices are bonded.
Therefore, to understand how security works, it is essential to understand how the pairing and key distribution system works. It is also important to understand that the initial connection between two devices is different from the subsequent connections between the same two devices.
11.2.1. Pairing
Two devices that initially have no security but wish to do something that requires security must first pair with each other. Pairing involves authenticating the identity of the two devices to be paired, encrypting the link, and then distributing keys to allow the security to be restarted on a reconnection much more quickly the second time around.
Pairing has three distinct phases:
• Exchange of pairing information
• Authentication of the link
• Key distribution
11.2.2. Exchange of Pairing Information
The first phase of pairing involves the exchange of pairing information that is used to determine both how to pair the two devices and what keys are distributed during the last phase.
It is important to note that just because there can be very complex algorithms used during the pairing operation, how the devices pair is probably the biggest single opportunity to have the user reject the whole wireless technology. If pairing is difficult and complex for the user, there is a risk that the user will fail to pair the device the first time around and take the product back to the store.
Bluetooth low energy uses the same pairing process as that used for the Secure Simple Pairing feature in Bluetooth classic.
Each device first determines its input and output capabilities, together with other paring information. The input and output capabilities are selected from a list of possible capabilities:
• No Input No Output
• Display Only
• Display Yes/No
• Keyboard Only
• Keyboard Display
To determine which of these five possible values should be used, the device determines its input and output capabilities and feeds them into a matrix, which is shown following this paragraph. The input capabilities can be either “no input,” the ability to select “yes/no,” or the ability to input a number by using a “keyboard.” The output capabilities can be either “no output” or “numeric output.” Numeric output in this context means the ability to display a six-digit number.
These five device input and output capabilities are communicated between the devices by using the Pairing Request message.
The Pairing Request message is sent as the first security message from a device. This contains not only the capabilities but also other pairing information, including a bit stating if out-of-band data is available, and what the authentication requirements are, if any. It also includes the list of the keys that are being requested to be distributed at the end of the pairing procedure. The authentication requirements include whether bonding is enabled and whether man-in-the-middle protection is required.
In response to this, a Pairing Response message or a Pairing Failed message can be sent.
The Pairing Response message includes basically the same information as the Pairing Request. However, if the request indicated that out-of-band data was present but the responder doesn’t have any out-of-band data, then the Pairing Failed message is sent instead. In fact, the Pairing Failed message can be sent at any time during the pairing procedure to give devices the opportunity to fail the current pairing; for example, when a parameter doesn’t match what is supported or expected.
Once the Pairing Request and Pairing Response have been exchanged, the two devices can then move to the second phase of the pairing procedure.
11.2.3. Authentication
Using the information from the Pairing Request and Pairing Response, the two devices can deterministically use the pairing algorithm. The two input and output capabilities are used in the following table to determine which algorithm is used:
It should be noted that for some combinations, it is entirely possible to lead the users into doing the right thing. For example, if device A has a Display Yes/No capability while device B has a Keyboard Display capability, then device A can display a six-digit number, and the user of device B can see that number and type it into device A. That value can then be used for the TK value.
Once the TK value has been determined, a really simple but hard-to-attack procedure is used to help stop a man-in-the-middle attack. A random number is generated by each device, and a confirmation value is also calculated based on that random number, the TK value, the known values of the pairing so far including the device addresses, and the parameters from the pairing request and response messages see Equation 11-4.
This value confirms that all the known parameters and addresses used so far are the same on both peer devices. This protects against man-in-the-middle attackers.
Both devices exchange the random numbers and the confirm values; therefore, they can check that the confirmation values match the random numbers and all the other shared information. The interesting twist is that the confirmation values are sent before the random numbers are exchanged. By doing this, an attacker would have to guess which one of the 2128 possible random numbers the peer device would use to calculate the confirmation value, before it knows what that random number might be.
If the confirmation values do not match the random numbers, then a Pairing Failed message would be sent to terminate the pairing because something was wrong. If the confirmation values do match the random numbers, both devices have the same input parameters from the pairing request and response, the same address information, the same TK value, and the correct random numbers.
Assuming that everything is confirmed correctly, the random numbers exchanged during the authentication are then used to calculate the STK value as described in Section 11.2. This STK value is then used to encrypt the link by using the Link Layer encryption procedures, as described in Chapter 7, The Link Layer, Section 7.10.3.
11.2.4. Key Distribution
Once the connection is encrypted by using the STK, it is then possible to distribute the required keys. These keys are distributed one at a time because at 128 bits in length, they only just fit into a single packet.
The following keys can be distributed:
• LTK
• IRK
• CSRK
The LTK is distributed along with EDIV and RAND because the slave does not have a security database. The slave can use these bits of information to generate the LTK for that master directly.
Both the master and slave can distribute all the types of keys. This is because for the current connection, the topology might be that device A is a master and device B is a slave; however, in subsequent connections the topology might be reserved such that device A is the slave and device B is the master. It is therefore possible to distribute the LTK from the master to the slave so that if they reconnect in a different topology, they can still reconnect quickly.
A slight issue that must be considered is that the addresses used during the pairing might not be the actual address of the device; the addresses used during pairing can be either a random or a private address. It is therefore also useful to distribute the identity information of the two devices so that this information can be used as the unique value in the database. This allows future connections to be performed by using this identity information rather than a random address that could be out of date.
11.2.5. Bonding
Bonding is really a Generic Access Profile discussion; however, it is useful to consider its operation at this point also. Bonding is nothing more than the saving of the keys and associated identity information in a security database. If the device does not save these values, the devices will have paired but not bonded. If one device saves them but the other doesn’t, upon reconnection, only one device will have the LTK, and thus the starting of encryption will fail.
To avoid this prospect, both devices exchange bonding information during the initial pairing so that they know whether the other device saves this bonding information. If the other device does not save the information, then once the attempt at starting encryption fails, the hosts will attempt to pair again.
11.3. Signing of Data
When a device is connected but not encrypted, it is possible to send data that is authenticated without confidentiality. To do this, a CSRK is exchanged during the very first connection at which pairing occurred. After this point, as long as no data is exchanged that requires confidentiality, signing can be used.
To sign the data, the CMAC algorithm is used. This algorithm takes the message to be authenticated, a SignCounter, and the CSRK used to authenticate the sender and then generates a signature value.
The message that is authenticated is typically an attribute protocol Signed Write Command and consists of the opcode, handle, and value that is being written.
The SignCounter is a 32-bit value that must be incremented on each new data packet that is sent. This is used to stop replay attacks. If the same SignCounter is transmitted in a subsequent data packet, it must be assumed that an attacker has received the previous message and is attempting to replay the message in the hope that it might do something interesting. Unfortunately for the attacker, the receiver just discards any message with a SignCounter that is less than the next expected value. It should be noted that the peer device needs to store this next expected SignCounter value for each device with which it is bonded if signed data is supported.
The SignCounter value must be included in the message that is sent because the receiver doesn’t know if the next message received has the next expected Sign-Counter. Consider the case when this is used to open and close the garage door. The message that commands the garage door to open or close is not confidential; anybody watching from the street will see the car turn up, followed by the garage door opening. If you go out one day far away from the garage and press the garage door remote control button a number of times, each time it is pressed a new message needs to be generated. By the time you return home and press the button to actually open the garage door, the SignCounter value might be higher than what is expected. The garage door itself won’t consider this a threat because the value is not one that has been previously used.