• No results found

Encryption algorithm

In document Bluetooth Security pdf (Page 45-47)

Overview of the Bluetooth Security Architecture

2.4 Link privacy

2.4.2 Encryption algorithm

When it comes to the selection of which encryption algorithm to use, there are some considerations that need to be taken into account:

• Algorithmic complexity; • Implementation complexity; • Strength of the cipher.

Algorithmic complexity relates to the number of computations needed for encryption and decryption, while implementation complexity relates to the size of the implementation on silicon. These two items boil down to power con- sumption and cost—crucial properties for the battery-powered units Bluetooth is designed for. A complex algorithm will almost certainly require a larger foot- print on silicon than does a simple algorithm, leading to higher cost. For the implementation, sometimes the speed obtained from dedicated hardware can be traded for flexibility and smaller size using a programmable component such as a

digital signal processor(DSP) or a small central processing unit(CPU). For such solutions, an increased algorithmic complexity will inevitably demand higher clocking frequency, which also increases power consumption.

The last item on the list may be the most important. Should the ciphering algorithm prove to be vulnerable to some “simple” attack, the whole foundation of link privacy falls. Of course, the question of whether an attack is “simple” or not remains to be discussed, but, in general, even the smallest suspicion regard- ing strength is enough to cast doubts over the system’s overall security quality. Do not confuse algorithmic complexity of encryption/decryption with the

strength of the cipher. In fact, the goal is to keep the algorithmic complexity low while having the computational complexity for all types of attacks as high as possible.

Bluetooth deploys a stream cipher (see Section 1.2.2) with the desired properties of a small and simple hardware solution while being difficult to break. A key stream is added modulo 2 to the information sequence. Thus, the scheme is symmetric, since the same key is used for encryption and decryption. This means the same hardware can be used for encryption and decryption, something that will actively keep down the size of the implementation. Moreover, stream ciphers are built efficiently using linear feedback shift registers (LFSR), which helps to reduce the die size even further.

The encryption/decryption consists of three identifiable parts: initialization of a payload key, generating the key stream bits, and, finally, the actual process of encrypting and decrypting the data. These functions are depicted in Figure 2.2. The payload key is generated out of different input bits that are “randomized” by running the sequence generating circuitry of the key stream generator for a while. Then the payload key is used as the starting state for the key stream generator in the encryption process. Since the sequence generating circuitry is used also for generating the payload key, the implementation is mainly concentrated in this part. The last part simply consists of XORing2the key stream bits with the out- going data stream (for encryption) or the demodulated received sequence (for decryption). The details for all this can be found in Section 4.3.

The choice of a stream cipher was to a large extent based on implementa- tion considerations. Clearly, a key stream generator needs to fulfill a whole range of properties to make it useful for cryptographic purposes. For instance, the

2. Addition modulo 2. Random number Clock Address Constrained encryption key Payload key generator Key stream generator Plaintext/Ciphertext Ciphertext/Plaintext ⊕

Figure 2.2 Stream cipher usage in Bluetooth. Encryption and decryption use the same circuitry.

sequence must have a large period and a high linear complexity, and satisfy stan- dard statistical and cryptographic tests. A more thorough discussion about this can be found in Section 4.1.2.

As can be seen in Figure 2.2, there are some parameters involved in creat- ing the payload key,KP. The secret constrained encryption key,KC′, is generated

by both units at the time a decision is made to switch encryption on. This key is fixed for the duration of the session or until a decision is made to use a tempo- rary key (which will require a change of the encryption key). Even though the constrained encryption key always consists of 128 bits, its true entropy will vary between 8 and 128 bits (in steps of 8 bits), depending on the outcome of the link key negotiation that the involved units must perform before encryption can be started. Theaddressrefers to the 48-bit Bluetooth unit address of the master, while theclockis 26 bits from the master’s native clock. Finally, there is a 128- bitrandom numberthat is changed every time the encryption key is changed. This number is issued by the master before entering encryption mode and it is sent in plaintext over the air. The purpose of it is to introduce more variance into the generated payload key.

In Bluetooth, the key stream bits are generated by a method derived from the summation stream cipher generator in Massey and Rueppel [3]. This method is well investigated, and good estimates of its strength with respect to currently known methods for cryptanalysis exist. The summation generator is known to have some weaknesses that can be utilized in correlation attacks, but, thanks to the high resynchronization frequency (see Section 2.4.3) of the gen- erator, these attacks will not be practical threats to Bluetooth. In Section 7.1 this will be discussed in greater detail.

In document Bluetooth Security pdf (Page 45-47)