Headset security model

As shown in Figure 1, Bluetooth profiles, the “Headset Profile” depends on
both the “Serial Port Profile “and the “Generic Access Profile”. The “Serial
Port Profile” provides RS-232 serial cable emulation for Bluetooth wireless
devices. The “Generic Access Profile” (GAP) [1] describes several security
aspects of Bluetooth wireless connections. Since the Headset Profile inherits
characteristics from the GAP, these aspects also apply to the “Headset
A typical headset configuration consists of two devices, a Headset (HS) and
an Audio Gateway (AG) as shown in Figure 2. The AG is typically a cellular
phone, laptop, PC, or any other type of audio player device, such as a radio,
CD player, etc. For reasons, which include personal privacy and preventing
infringement on others, it is recommended that communication between the
HS and AG be protected by the Bluetooth Baseband [1] authentication and
encryption mechanisms. How and when these mechanisms should be used is
determined by policy rules, which may be preset or configurable by the end
user. In order to set up secure connections, the HS and AG need to store the
necessary Bluetooth passkeys and link keys.
Read the rest of this entry »

Service Discovery Application Profile

Security methods for use with the Service discovery application profile [4] are
discussed in this section.
The Service discovery application profile describes the features and
procedures used to discover services registered on other Bluetooth wireless
devices using the Bluetooth Service Discovery Protocol (SDP). The user,
independently of other profiles, specifically initiates the SDP. Service
discovery procedures may be associated with other profiles, such as the LAN
access profile to display network resources. In these situations the security
procedures associated with the specific profiles should be applied.
The SDP uses only connection-oriented channels, however the SDP itself is a
connectionless datagram service. It relies on the L2CAP layer to create and
manage connections. This is significant in that the basis for security in the
SDP is the initial connection and pairing of devices. The SDP itself does not
require the use of authentication and/or encryption for SDP transactions. If
authentication is performed on the Bluetooth wireless devices to be involved in
an SDP procedure, then the devices must pass the authentication test to
perform SDP procedures. Therefore any security procedures applied to the
SDP are determined by those used to negotiate the connections between the
specific Bluetooth wireless devices. SDP is not available to devices that do
not pass this test.
Read the rest of this entry »

Short passkey values

During the pairing procedure [1] both units calculate an initialisation key. The
only secret input to the key calculation is the passkey (PIN). In the next step
the combination or unit key is calculated. This calculation is protected using
the initialisation key. Directly after the exchange of the link key, the
authentication procedure is performed. The authentication uses the newly
derived link key. All key derivation algorithms are symmetric algorithms that
can be implemented in hardware or in software. The computational complexity
of the algorithms is not large. Assume that an intruder records all
communication during the key exchange and the first authentication between
two units. He can then calculate, for each possible passkey value, the
corresponding initialisation key. Furthermore, for each initialisation value, he
can calculate the corresponding link key. Finally, for each link key value he
can then check the response value for the observed challenge (or he can
issue a challenge himself towards the victim device). If he finds a match, he
has obtained the correct link key. Since all calculation steps have low complexity, unless the passkey space is large, the intruder can easily compute
the correct link key.
Read the rest of this entry »

Bluetooth Pairing

As discussed in Section 4.0 pairing is the procedure where a relationship (link
key) is established between two previously unknown devices. The link key is
derived when the devices are initially paired (i.e. the link key does not exist
before the pairing procedure). Pairing is facilitated with yet another key, the
initialization key. This key is computed by a pair of devices using the Bluetooth
addresses of each device, a random number, and a shared secret (PIN). Since it
is only used in the initial pairing, the initialization key is only used once.
The initial pairing is the most profitable area of attack on a Bluetooth device. If
the attacker can guess or steal the PIN during the initial pairing, then he can
perform a much more efficient search to derive the link key. This search is
further simplified if the communications occurring while the devices are paired is
recorded [5]. For this reason the Bluetooth SIG strongly encourages the use of
long, random PINs and suggests that pairing be performed only in a private
place. Assuming that both devices have a man-machine interface (such as a
keypad) it is also suggested that the PIN be manually entered into both devices
or in any case communicated out-of-band (not transmitted over the Bluetooth
wireless link). Thus, long PINs provide improved security since the PIN cannot
be received over-the-air. To steal the PIN an attacker must guess or record it by
some other means such as direct observation of the user, a more difficult
procedure if the PIN is long and the pairing is performed in private.

Data Eavesdropping

The Bluetooth standard does not use RC4 but rather the stream cipher E0, which
is specifically designed to run over a Bluetooth wireless packet network. A
unique encryption key is generated for each session, from which per-packet keys
are derived, in a manner that avoids the problem in 802.11b caused by frequent
reuse of per-packet keys.
Direct attacks on the E0 cipher are known but are of significant complexity.
Jakobsson and Wetzel present two such attacks [5] the first is of 2100 complexity,
the second is a “birthday-type attack” of 266overall complexity. Fluher and Lukas
[6] present an attack using observed keystream and the public knowledge of the
encryption mechanism used in E0 to compute the encryption key. Their method
requires from O(273) to O(284), depending on how much cleartext is available for
the algorithm. They contend that the upper limit of E0 is actually about 80 bits
and question the extension of the E0 key size to 128 bits as suggested in the
Bluetooth specification [7]. As discussed by Jakobsson and Wetzel [5], attacks
with a high order of complexity are not of practical value, but may point the way
to a more efficient attack. As yet, a more efficient direct attack on E0 has not
been reported.
Read the rest of this entry »

False Authentication

To gain access to a network, a user must be authenticated. While authentication
is typically done at a higher network level, 802.11b and Bluetooth technologies
also support device authentication.
In 802.11b authentication is performed by a challenge response procedure using
a shared secret. After requesting authentication, the authenticator sends the
initiator a 128-octet random number challenge. The initiator encrypts the
challenge using the shared secret and transmits it back to the authenticator.
Encryption is performed by XORing the challenge with a pseudo-random string
formed by the shared secret and a public IV. Note that the only thing that
changes from authentication to authentication with a specific user is the plaintext
Read the rest of this entry »