Conference PaperPDF Available

Bluetooth Security Risks and Mitigation in wireless networks

Authors:

Abstract

Bluetooth is a standard and communications (wireless) protocol operates on the unlicensed1 2.4GHz band primarily designed for low power consumption, with a short range (power-class-dependent: 1 meter, 10 meters, 100 meters). Bluetooth technology was originally conceived by Ericsson in 1994. Ericsson, IBM, Intel, Nokia, and Toshiba formed the Bluetooth Special Interest Group (SIG), a not-for-profit trade association developed to drive the development of Bluetooth products and serve as the governing body for Bluetooth specifications2. This version is backward compatible and can easily be connected to transfer data to/from Bluetooth devices of earlier versions (specially of v1.1). Version 2 (actually v2.0 + EDR, enhanced data rate) is also quite ideal in perspective of security; that means it supports more security tools (services in operation with 4 security modes) than earlier versions. From the point of view of security issues it is seen that some security modes are secured and some are non secured. In basic mode of Bluetooth layers, L2CAP (Logical link control & Adaptation Protocol) provides reliable sequenced packets with a payload configurable up to 64kB, with 672 bytes as the minimum mandatory supported size. As the specification (v2+EDR) or v2+ becomes more widely adopted, it is likely that additional vulnerabilities will be discovered and additional recommendations needed for securing v2.1 technologies effectively. Organizations’ planning on deploying v2.1 technologies should monitor developments involving new vulnerabilities and threats and additional security control recommendations. In this research work we are going to have a look and analyze on how Bluetooth risks/threats arrive in single point of network (specially in Pico nets, threats in multipoint networks will be discussed in the extended version of this paper.) and what security measures can be taken in several versions of Bluetooth with those security modes.
Bluetooth Security Risks and Mitigation in wireless networks
MD. SADEK IMAM SHAIKH, 0616604@beds.ac.uk, Asstt. Prof. & Head, ICT, USTC,
KAZY NOOR E- ALAM SIDDIQUEE, knas_112000@yahoo.com, Lecturer, USTC
ABSTRACT
Bluetooth is a standard and communications (wireless) protocol operates on the unlicensed1 2.4GHz band
primarily designed for low power consumption, with a short range (power-class-dependent: 1 meter, 10 meters, 100
meters). Bluetooth technology was originally conceived by Ericsson in 1994. Ericsson, IBM, Intel, Nokia, and Toshiba
formed the Bluetooth Special Interest Group (SIG), a not-for-profit trade association developed to drive the
development of Bluetooth products and serve as the governing body for Bluetooth specifications2. This version is
backward compatible and can easily be connected to transfer data to/from Bluetooth devices of earlier versions
(specially of v1.1). Version 2 (actually v2.0 + EDR, enhanced data rate) is also quite ideal in perspective of security;
that means it supports more security tools (services in operation with 4 security modes) than earlier versions. From the
point of view of security issues it is seen that some security modes are secured and some are non secured. In basic
mode of Bluetooth layers, L2CAP (Logical link control & Adaptation Protocol) provides reliable sequenced packets
with a payload configurable up to 64kB, with 672 bytes as the minimum mandatory supported size. As the specification
(v2+EDR) or v2+ becomes more widely adopted, it is likely that additional vulnerabilities will be discovered and
additional recommendations needed for securing v2.1 technologies effectively. Organizationsplanning on deploying
v2.1 technologies should monitor developments involving new vulnerabilities and threats and additional security
control recommendations. In this research work we are going to have a look and analyze on how Bluetooth
risks/threats arrive in single point of network (specially in piconets, threats in multipoint networks will be discussed in
the extended version of this paper.) and what security measures can be taken in several versions of Bluetooth with
those security modes.
INTRODUCTION
Bluetooth, the wireless technology, was named
after a tenth-century king, Harald Bluetooth,
King of Denmark and Norway. Bluetooth was
originally started as a project by the Ericsson
Company and is an anglicized version of Harald
Blaatand, who was known for his unification of
previously warring tribes from Denmark and
Norway. Bluetooth likewise was intended to
unify devices of different functions used in
Wireless technologies, such as personal
computers, mobile phones, telephones,
notebooks, cameras, printers, coffee makers and
so on.[10][11][12][13].
The key features of Bluetooth technology are
robustness, low power, and low cost. The
Bluetooth
specification defines a uniform structure for a
wide range of devices to connect and
communicate with each other. Bluetooth is a
wireless protocol utilizing short-range
communications technology defined by the IEEE
802.15 standard facilitating data transmission
over short distances from fixed and mobile
devices, creating wireless personal area networks
(PANs). The intent behind the development of
Bluetooth was the creation of a single digital
wireless protocol capable of connecting multiple
devices and overcoming problems arising from
synchronization of these devices[9][10].
Bluetooth links usually use optional pre-shared
key authentication and encryption algorithms,
which are considered as strong when both of
them are implemented and used correctly.[14] In
this case, the strength of links relies primarily on
the length and randomness of the passed key
used for the pairs who mutually authenticate
each other for the first time and latterly a link for
authentication and encryption is set up in
between them.
LITERATURE REVIEW
Bluetooth security is provided only between the
mobile phone and the laptop computer. IEEE
802.11 security protects the wireless local area
network link between the laptop and the IEEE
802.11 AP. However, the communications on the
wired network are not protected by Bluetooth or
IEEE 802.11 security capabilities. End-to-end
security is not possible without using higher-
layer security solutions in addition to the security
features included in the Bluetooth specification
and IEEE 802.11 standards.[10][11][12][13]
The different combinations of connectability and
discoverability capabilities can be divided into
three categories, or security levels[15][16]:
-Silent: The device will never accept any
connections. It simply monitors Bluetooth
traffic.
-Private: The device can not be discovered (so-
called non-discoverable device). Connections
will be accepted only if the device's BD ADDR
(Bluetooth Device Address) is known to the
prospective master.
-Public: The device can be both discovered and
connected to (so-called discoverable device).
There are also three different security modes that
a device can implement. A device can be only in
one security mode at a time[15][16]:
1. No secure: Bluetooth device does not initiate
any security measures.
2. Service-level enforced security mode: Two
Bluetooth devices can establish a no secure
Asynchronous Connection-Less (ACL) link.
Security procedures, namely authentication,
authorization and optional encryption, are
initiated when a L2CAP (Logical Link Control
and Adaptation Protocol) Connection-Oriented
or Connection-Less channel request is made.
3. Link-level enforced security mode: Security
procedures are initiated when an ACL link is
established.
The following are the three basic security
services specified in the Bluetooth
standard:[11][13]
i. Authentication: verifying the identity of
communicating devices. User authentication is
not provided natively by Bluetooth. In the
Bluetooth world the authentication between two
devices covers only the knowledge of a common
secret key (called PIN) and the knowledge of the
device addresses1. In the context of [6] we could
say that the form of this authentication protocol
is an agreement protocol. The authentication
process is a simple challenge and response
protocol and involves the following steps:
1. generation of an initialization key
2. generation of an authentication key2
3. authentication
These are discussed later in this paper.
ii. Confidentiality: preventing information
compromise caused by eavesdropping by
ensuring that only authorized devices can access
and view data.
iii. Authorization: allowing the control of
resources by ensuring that a device is authorized
to use a service before permitting it to do so.
The three security services offered by Bluetooth
and details about the modes of security are
described below. Bluetooth does not address
other security services such as audit and non-
repudiation; if such services are needed, they
must be provided through additional means.[13]
(GUIDE TO BLUETOOTH SECURITY (DRAFT)).
Security Mode 1 is non-secure where
functionalities (authentication and encryption)
are bypassed and it is a risk indeed. In Security
Mode 2 (supported by almost all versions), a
service level-enforced security mode, security
procedures are initiated after LMP link
establishment but before L2CAP (which resides
in data link layer) channel establishment. In
Security Mode 3 authentication and encryption
are mandatory. In security mode 4 security
procedures are initiated after link setup. Secure
Simple Pairing uses Elliptic Curve Diffie
Hellman (ECDH) techniques for key exchange
and link key generation. [13] (Guide to
Bluetooth Security, Special publication 800-121
(Draft) by National Institute of Standard and
Technology (US department of Commerce)).
INITIALIZATION KEY
The initialization key is created during the first
pairing attempt and is there to protect the transfer
of the initialization parameters. It is also used
even though the addresses are not verified using
a third party, one can be assured that the device
he speaks to used the given address to advertise
itself. Thus attacks like man in the middle
between two distinct devices that are not willing
to talk with are avoided. This is called the link
key in the Bluetooth specification[21].
to generate the authentication key. This key is
generated using the following formula[21]
Kinit = E22 (BD ADDR, PIN, length(PIN), IN
RAND)
where PIN is a user provided sequence of bytes
and IN RAND is an 128 bit random number
exchanged during the pairing initiation and BD
ADDR is the address of the device that received
the IN RAND value. E22 is a cryptographic hash
functions and the star in E_ 22 indicates a
difference between this function and the actual
one defined in [21]. In more detail the Kinit is
calculated as[21]
Kinit =E22(PIN, RAND, L) =SAFER +one way
(expand128(PIN),IN RAND[0..14] U (IN
RAND[14] _ L)
PIN0 = (PIN [ BD ADDR), up to 16 bytes,
L0 = min {16, length(PIN) + 6 }
The algorithm SAFER + one way is a version of
the SAFER+[10] encryption algorithm, modified
in a way to make it non invertible [21]. The first
parameter is an 128 bit key and the second is the
128 bit input data. The expand128 algorithm just
copies its input as many times are required to
produce an 128 bit output. If the output is larger
then the output is truncated at the first 128 bits.
Note that the initialization key is only generated
at the first pairing attempt. On subsequent
attempts the initialization key is the same as the
previous authentication key.
Authentication key
In order to perform the authentication step of the
protocol a common secret key is required for the
parties. This is the role of the Authentication
key. This key is generated during the pairing
process; however some older versions of the
Bluetooth protocols supported a permanently
stored key option. Those permanent keys, called
unit keys, are now deprecated, thus we will not
discuss them further. When only two parties are
involved the authentication key is called a
combination key. After this exchange algorithm
is completed the two devices share a common
authentication key. Here we explain the
algorithm in detail[21].
The verifier device sends this message to the
claimant device that consists of
where V RAND is a random number known to
verifier only, V ADDR is verifier’s address.
After the receipt of CA message, the claimant
responds with this message. This consists of
where C RAND is a random number known to
claimant only, C ADDR is claimant’s address.
After this exchange of the messages both parties
can calculate a common authentication key as:
Verifier device
Claimant device
E21 is a cryptographic hash function, similar to
E22 is defined to be
Authentication Method
We need to highlight the actual authentication
method depicted in fig:1. This method is
executed twice in a pairing procedure, in order to
authenticate both parties. Here the knowledge of
the common authentication key and the right
addresses are the basis of authentication and the
knowledge of the common authentication key
indirectly implies that parties have used the same
PIN to produce it.
The method is derived below[21].
The verifier device sends a challenge message to
the claimant device that consists of an 128 bit
random number.
After the receipt of RAND message, the claimant
responds with this message. This consists of
SRES, that is calculated as the first 32 bits of
E1(KEY, ADDR, RAND), where KEY is the
authentication key and ADDR is the claimant’s
device ad-dress.
The verifier then calculates SRES0 = E1(KEY,
ADDR, RAND) and if the output matches the
received SRES the authentication is complete. In
that case the rest 96 bits of the output of E1 are
assigned the name ACO and stored. The E1
algorithm is based on the SAFER+ block
algorithm and is shown below.
The linear transformation of the key is (for 128
bits keys) performed in byte level and is given
below [21].
ENCRYPTION
Encryption is a separate process that starts after
authentication is successfully finished. For
encryption a different key is used, called the
encryption key and it allows for sizes from 8 to
128 bits. The fact that the encryption key is not
fixed is political rather than technical. Since
devices are constructed in countries with
different laws about encryption of data, it was
allowed in the specification for devices to
negotiate the encryption key size (see [21] p.
749). The process of enabling encryption
consists of the steps:
‹encryption negotiation;
‹generation of the encryption key;
‹encryption of all traffic using this key.
The encryption applies only to the payload of the
Bluetooth packets. The headers are never
encrypted.
Encryption negotiation
The process of negotiating encryption is shown
in Figure 9 and explained further in this section.
Initially the initiator device sends an encryption
mode request message to the peer device. The
encryption mode can be either enable encryption
or not. If usage of encryption is requested a
negotiation of the encryption size follows. This
negotiation may occur multiple times until an
acceptable by both sides key size is negotiated.
The last phase includes the sending of a random
number by the initiator device in order for both
peers to calculate the encryption key. After this
key is calculated encryption is enabled. It should
be noted that this process is clearly vulnerable to
man in the middle attacks, thus both devices
must terminate the negotiation if the negotiated
values are considered to be weak or insecure.
Encryption key The encryption key is generated
using the current authentication key, an 128 bit
random number exchanged during the encryption
negotiation and the 96 bit value of ACO as
generated in the authentication process. To
generate the key the E3 algorithm is used that is
defined as:
Encryption algorithm
For performing encryption as to the nature of the
device, no block cipher is used as an encryption
algorithm in Bluetooth. For efficiency reasons
and power consumption a stream cipher called
E0, based on Linear Feedback Shift Registers
(LFSR) was used. Four shift registers are used in
the algorithm as a non-linear part that combines
their output. The plaintext is then combine with
the output key stream using an exclusive or. The
operational mode of the algorithm is quite
peculiar. The stream cipher is initialized on
every new packet to be encrypted with the
following data
‹the encryption key;
‹the master device address;
‹the 26 bits of the master clock.
Although it will not be discussed in detail the
cipher initialization phase includes an encryption
key reduction to whatever bits it has been
negotiated and setting the cipher’s initial
encryption state. The cipher is being initialized
on every packet transfer (receive or send). In a
typical packet, such as the one depicted in Figure
11 the payload data including the header and
the CRC code are encrypted.
Packet authenticity
After Bluetooth authentication and encryption
are enabled all the exchanged packets are
transferred with an encrypted payload. As we
saw before there is no message authentication
code or any authentication payload per packet
appended except for the encryption. Thus the
only protection is the encrypted 16 bit CRC
code. However because of the linearity of the
encryption, which is just an exclusive OR over
the plaintext, it is very easy to manipulate the
CRC code and the cipher text in order to produce
a different output when the transmitted data are
known. Thus it should be noted that Bluetooth
offers NO packet authenticity.
NETWORKING PROTOCOLS
Bluetooth provides two networking protocols
that resemble the Internet UDP and TCP
protocols. These are the L2CAP and the
RFCOMM protocols. L2CAP is a high level
protocol that provides a connection oriented and
connectionless messaging to upper layer
protocols. Its features are connection flow
control, error detection and segmentation and
reassembly of messages. It is built around the
concept of channels, a notion similar to the TCP
ports. Any L2CAP channel is described by a
number between the range 1-65535. L2CAP can
operate in several modes, such as basic, flow
control mode and retransmission mode. All the
modes deliver unreliable communication similar
to UDP except for the retransmission mode. In
retransmission mode a more complex format is
used and also supervisory frames are introduced
to handle for acknowledge packets.
RFCOMM
Before retransmission of L2CAP mode was
introduced, the only way to use a reliable
network mode such as TCP was to use the
RFCOMM channels. This protocol is built over
the L2CAP protocol and offers an emulation for
a serial cable. It was intended as a wireless
replacement for RS-232 serial communication
applications and included the control signals. It
offers 20 connection channels, as opposed to
65535 of L2CAP and this made tricky the
allocation and usage of the RFCOMM channels.
Despite being a serial communication emulator,
it is very often used as a reliable transport layer.
ATTACKS IN THE PROTOCOLS
Attacks so far have been found on the E0 stream
cipher such as [16], [17] and [18] that reduce the
effective key length from 128 bits to 84 bits.
These attacks and the lack of integrity suggest
that the Bluetooth security protocols should not
be used for transactions that require a high level
of security. Other attacks such as [20] recover a
PIN used to secure a connection in a few seconds
for PINs of less than 8 characters. This can be
done by just an eavesdropper since this is an off-
line attack.
SECURITY RISKS:
Several Security Risks are identified. These are
stated below (Some of them are derived which
are not often common or has a general risk).
1. BlueBug
BlueBug is the name of a bluetooth security
loophole on some bluetooth-enabled cell phones
of limited range of 10 -15 meters (class 2 range).
This security flaw does allow a vast number of
things that may be done when the phone is
attacked via Bluetooth[8]:
initiating phone calls
sending SMS to any number
reading SMS from the phone
reading phonebook entries
writing phonebook entries
setting call forwards
connecting to the internet
forcing the phone to use a certain
service provider etc.
2. Long Distance Snarf
It is still under experiment but can be treated as
one of the vulnerabilities[8].
3. Bluetooone
This is the practice to send or receive
information to/from a Bluetooth enabled device
by connecting an external (directional) antenna
(i.g. helix-antenna) to the Bluetooth dongle (here
Linksys Bluetooth USB Adapter can be used
since it has an external antenna). This Bluetooth
tuning makes it possible to concentrate the
emission of bluetooth signals to one direction
instead of any direction. This direction of signals
enhances the range of bluetooth radios. An
enhanced range could be used for experiments
like the long distance snarf[8].
4. Blooover
Blooover is a proof-of-concept tool that is
intended to run on J2ME-enabled cell phones
and is intended to serve as an audit tool that
people can use to check whether their phones
and phones of friends and employees are
vulnerable[8].
5. BT Audit
From the Bluetooth architecture we can see that
it has main two protocols, L2CAP and
RFCOMM which is layered on top of L2CAP.
Since these protocols utilize ports (as they are
named in the popular TCP/IP UDP/IP
architecture) it makes sense to have the ability to
scan these in order to find so called open ports
and possible vulnerabilities bound to them.[8]
6. BlueSmack
BlueSmack is a Bluetooth attack that knocks out
some Bluetooth-enabled devices immediately.
This Denial of Service attack can be conducted
using standard tools. On the L2CAP layer there
is the possibility to request an echo from another
Bluetooth peer. As for the ICMP ping, the idea
of the L2CAP ping (echo request) is also to
check connectivity and to measure roundtrip
time on the established link [8].
7. BTClass - Bluetooth device class cloaking
Each Bluetooth device has a device class (type of
device and services it provides) which has a total
length of 24 bits and is separated in three parts
and is part of the responds to an inquiry. First
there is the Service Class which is a bit field
(first 11 bits) and second and third are the Major
(5 bits) and Minor (6 bits) device class. The last
two bits indicate the format.[8].
8. BlueSnarf
The BlueSnarf attack is probably the most
famous Bluetooth attack, since it is the first
major security issue related to Bluetooth enabled
devices. In this type of attack, the attacker needs
to connect to the OBEX Push Profile (OPP),
which has been specified for the easy exchange
of business cards and other objects while this
service does not require authentication. The
BlueSnarf attack connects to an OBEX Push
target and performs an OBEX GET request for
known filenames such as 'telecom/pb.vcf' for the
devices phone book or 'telecom/cal.vcs' for the
devices calendar file[8].
9. BlueSnarf++
It is quite similar to the bluesnarf attack but the
difference is where the attacker has full
read/write access to the device's filesystem. The
manufacturers of the devices that are known to
be vulnerable have been informed about this
issue. [8]
10. HeloMoto
The HeloMoto attack the combination of
Bluesnarf and bluebug attack has been
discovered by Adam Laurie. The attack is called
HeloMoto, since it was discovered on Motorola
phones[8].
11. BlueBump
“The BlueBump attack is the Bluetooth
equivalent to a very cool physical security thread
called key bumping. When used correctly, an
appropriate bump key can be used to open any
lock in seconds. Since the BlueBump attack is
also about keys (link keys in this case) we named
this attack after this amazing technique.” [8]
12. BlueDump
“BlueDumping is the act of causing a Bluetooth
device to 'dump' it's stored link key, thereby
creating an opportunity for key-exchange
sniffing to take place. The attacks on link keys
and PINs were first publicised by Ollie
Whitehouse, at CanSecWest, in which he
describes a method by which the PIN and link-
keys can be obtained if a pairing event can be
witnessed with a Bluetooth sniffer. More
recently, Shaked and Wool have proposed a
method by which the key attack can be
enhanced, bringing it to near-realtime, as well as
a method for forcing the key-exchange to take
place at a time of the attacker's choosing.” [8]
Here the attacker needs to know the BDADDR
of a set of paired devices and then the attacker
spoofs the address of one of the devices and
connects to the other. Since the attacker has no
link key, when the target device requests
authentication, the attacker's device will respond
with an
'HCI_Link_Key_Request_Negative_Reply,
which will, in turn cause the target device to
delete it's own link key and go into pairing mode.
[8]
13. Car Whisperer
The car whisperer (cw) project intends to
sensibly manufacturers of car kits and other
Bluetooth appliances without display and
keyboard for the possible security threat
evolving from the use of standard passkeys.[8]
After establishing the connection, the car
whisperer starts sending audio to and recording
audio from the headset. This allows attackers to
inject audio data into the car. This could be fake
traffic announcements or nice words. Attackers
are also able to eavesdrop conversations among
people sitting in the car. [8]
Ideally, the car whisperer is used with a toned
dongle and a directional antenna that enhances
the range of a Bluetooth radio quite a bit.
13.1 Recommendations
In order to avoid getting attacked by car
whisperer, manufacturers should not use
standard passkeys in their Bluetooth appliances.
Moreover, there should be some kind of direct
interaction with the device that allows a device
to connect. Another recommendation would be
to switch the hands free unit to invisible mode,
when no authorized device connects to it within
a certain time.
Not all Bluetooth carkits are subject to this
threat. There is quite a few Bluetooth carkits that
use random passkeys that are generated for every
individual device during the production process.
Carkits that are integrated with a full
infotainment system could use (and sometimes
already do use) the infotainment system's UI for
acquiring a passkey from the user. [8]
14. Nokia 770
The Nokia 770 Internet Tablet is a Linux based
tablet PC with built in Wi-Fi and Bluetooth
capabilities. It’s own ports and 3rd party
packages for this platform will be published by
“trifinite”, to enable it to be used as a compact,
portable auditing device. [8]
15. Blooover II
Blooover II is the successor of the very popular
application Bloover. Besides the BlueBug attack,
Blooover II supports the HeloMoto attack (which
is quite close to the BlueBug attack), the
BlueSnarf and the sending of malformed objects
via OBEX. [8]
16. BlueChop
BlueChop is an attack that disrupts any
established bluetooth piconet by means of a
device that is not participating the piconet. A
precondition for this attack is that the master of
the piconet supports multiple connections (a
feature that is necessary for building up
scatternets).
In order to BlueChop a piconet, a device that is
not participating into this piconet, spoofs a
random slave out of the piconet and contacts the
master of the piconet. This leads to confusion of
the master's internal state and disrupts the
piconet. This attack is not specific to any device
manufacturer and seems to have general validity.
[8]
17. RFIDIOt
RFIDIOt a python library for manipulating RFID
devices provides support for external (currently
Compact Flash/USB/Serial) readers, and
functions are provided for standard operations
such as READ, WRITE, DEBIT, LOGIN etc.
Supported standards are ISO 14443A and
ISO14443B in the 13.56MHz band, and devices
include all MIFARE types, SLE 55Rxx, SLE
66CL160S, SLE 66CLX320P, SR176, SRIX4K,
Jewel Tag (IRT0302B11 KSW DIY Eng.
Sample), Sharp B, ASK GTML2ISO,
TOSMART P064. Support for Smartcards and
other RFID operating frequencies and standards
are in the pipeline. [8]
PROFILES OF BLUETOOTH AND
SECURITY ARCHITECTURES
Bluetooth maintains a set of profiles which
defines generally a selection of messages and
procedures (generally termed capabilities)
derived from Bluetooth SIG specifications[2][3].
Here security can be defined by four
fundamental elements such as- Availability,
access, integrity and confidentiality. The security
expert group is mainly focusing on developing
general security architecture models. We can
state sample security architectures for the
following five common Bluetooth application
profiles[2][3]:
· Service discovery application profile
· Headset Profile
· Dial-up Networking Profile
· LAN Access Profile
· Synchronization Profile
-Bluetooth Base band authentication and
encryption
-PPP authentication (and encryption)
-Different application level security mechanisms
-IP security authentication, integrity protection
and encryption
“For a communication service several different
security aspects must be taken into account.
These aspects cover everything from protection
of communication links (provided by encryption
and/or data integrity protection), authentication
of devices or users and access control. Different
security mechanisms can be applied at different
layers in the communication stacks.
Furthermore, protection at one layer does not
exclude protection at another level. The security
demands depend on the application, the
environment and usage scenario. For one usage
scenario basic authentication of devices might be
a sufficient security level, while for yet another,
link level encryption, link level authentication
and authentication and authorization at the
application level are needed. Different security
mechanisms at different protocol levels are
indicated. The Bluetooth Baseband provides
authentication and encryption.”[2][3]
Fig2: Protocol Stack and security protocol
options
COUNTER MEASURES:
By the followings countermeasures can be taken
for security purpose of the Bluetooth network.
1 Unit key is reusable and becomes public once
used[13][13].
A unit key should be used as input to generate a
random key. A key set should be used instead of
only one unit key.
2 Unit key sharing can lead to eavesdropping. A
corrupt user may be able to compromise the
security between two other users if the corrupt
user has communicated with either of the other
two users. This is because the link key (unit
key), derived from shared information, has been
disclosed. (Versions Before Bluetooth v2.1)
3 Short PINs are allowed. Weak PINs, which are
used for the generation of link and encryption
keys, can be easily guessed. People have a
tendency to select short PINs.
4 PIN management is lacking. Establishing use
of adequate PINs in an enterprise setting with
many users may be difficult. Scalability
problems frequently yield security problems.
5 Encryption key stream repeats after 23.3 hours
of use. The encryption key stream is dependent
on the link key, EN_RAND, Master BD_ADDR,
and Clock. Only the Master’s clock will change
during a particular encrypted connection. If a
connection lasts more than 23.3 hours, the clock
value will begin to repeat, hence generating an
identical keystream to that used earlier in the
connection.
6 Link keys are stored improperly. Link keys can
be read or modified by an attacker if they are not
securely stored and protected via access controls.
7 Attempts for authentication are repeated. A
limiting feature needs to be incorporated in the
specification to prevent unlimited requests. The
Bluetooth specification currently requires a time-
out period between repeated attempts that will
increase exponentially.
8 Strength of the challenge-response pseudo-
random generator is not known. The Random
Number Generator (RNG) may produce static
number or periodic numbers that may reduce the
effectiveness of the authentication scheme.
9 Encryption key length is negotiable. The
specification allows devices to negotiate
encryption keys as small as one byte. A more
robust encryption key generation procedure
needs to be incorporated in the specification.
10 The master key is shared. A better broadcast
keying scheme needs to be incorporated into the
specification.
11 No user authentication exists. Only device
authentication is provided by the specification.
Application-level security, including user
authentication, can be added via overlay by the
application developer.
12 The E0 stream cipher algorithm used for
Bluetooth encryption is weak. More robust
encryption needs to be incorporated in the
specification.
13 Privacy may be compromised if the Bluetooth
device address (BD_ADDR) is captured and
associated with a particular user. Once the
BD_ADDR is associated with a particular user,
that user’s activities could be logged, resulting in
a loss of privacy.
14 Device authentication is simple shared-key
challenge-response. One-way-only challenge-
response authentication is subject to MITM
attacks. Bluetooth provides for mutual
authentication, which should be used to provide
verification that users and the network are
legitimate.
15 End-to-end security is not performed. Only
individual links are encrypted and authenticated.
Data is decrypted at intermediate points. End-to-
end security on top of the Bluetooth stack can be
provided by use of additional security controls.
16 Security services are limited. Audit, no
repudiation, and other services are not part of the
standard. If needed, these services can be
incorporated in an overlay fashion by the
application developer.
17 Discoverable and/or connectable devices are
prone to attack. Any device that must go into
discoverable or connectable mode to pair should
only do so for a minimal amount of time. A
device should never be in
discoverable or connectable mode all the time.
REFERENCE
1. Newton, Harold. (2007). Newton’s
telecom dictionary. New York: Flatiron
Publishing.
2. "How Bluetooth Technology Works".
Bluetooth SIG. Retrieved on 2008-02-
01.
3. "Wii Controller". Bluetooth SIG.
Retrieved on 2008-02-01, Bluetooth
security white paper - Bluetooth SIG
Expert group, prepared by Christian
Gehrmann, 19-04-2002.
4. "The Bluetooth Blues", Information
Age (2001-05-24). Retrieved on 1
February 2008.
5. Specification Documents". Bluetooth
SIG. Retrieved on 2008-02-04.
6. "HTC TyTN Specification" (PDF).
HTC. Retrieved on 2008-02-04.
7. (2006-08-03). "Simple Pairing
Whitepaper" (PDF). Version V10r00.
Bluetooth SIG. Retrieved on 2007-02-
01.
8. "BlueBug". Trifinite.org. Retrieved on
2007-02-01.
9. John Oates (2004-06-15). "Virus attacks
mobiles via Bluetooth", The Register.
Retrieved on 1 February 2007.
10. How Bluetooth got its name
11. Data Communications and Networking
[Book]
[Author: Behrouz A. Forouzan,
Chapter: 15- Wireless LANs, pg- 361-
381]
12. http://en.wikipedia.org/wiki/Bluetooth
13. Guide to Bluetooth Security
-- Special publication 800-
4121 (Draft) by National Institute of
Standard and Technology (US
department of Commerce), Special
publication 800 -48.
14. Systems and Network Analysis Center
Information Assurance Directorate,
National Security Agency, Government of
USA, www.nsa.gov/snac
15. Bluetooth SIG, Bluetooth speci¯cations
1.0, 1.1, 1.2 and 2.0+EDR. Bluetooth SIG,
technical speci¯cations, 1999-2004.
https://www.bluetooth.org
16. IEEE Standards Association, IEEE
802.11 speci¯cations. IEEE Standards
Association, technical speci¯cations, 1999-
2004.
http://standards.ieee.org/getieee802/802.11.h
tml
17. O. Levy and A. Wool. A uniform
framework for cryptanalysis of the
Bluetooth e0 cipher.
Cryptology ePrint Archive, Report
2005/107, 2005. Available from
http://eprint.iacr.org/2005/107.pdf.
18. Lowe. A hierarchy of authentication
specifications. In PCSFW: Proceedings of
The 10th Computer
Security Foundations Workshop. IEEE
Computer Society Press, 1997.
19. Y. Lu, W. Meier, and S. Vaudenay. The
conditional correlation attack:
A practical attack on bluetooth
encryption. In Advances in Cryptology -
Crypto 2005. Springer- Verlag, 2005.
Available from
http://www.iacr.org/conferences/crypto2005
/p/16.pdf.
20. Y. Shaked and A. Wool. Cracking the
bluetooth pin. In 3rd USENIX/ACM Conf.
Mobile Systems, Applications, and
Services (MobiSys). ACM, 2005. Available
from http://www.eng.tau.ac.il/ yash/
shaked-wool-mobisys05/index.html.
21. "About the Bluetooth SIG". Bluetooth
SIG. Retrieved on 2008-02-01, version 2.0 + edr,
2004.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
This paper describes the implementation of an attack on the Bluetooth security mechanism. Specifically, we describe a passive attack, in which an attacker can find the PIN used during the pairing process. We then describe the cracking speed we can achieve through three optimizations methods. Our fastest optimization employs an algebraic representation of a central cryptographic primitive (SAFER+) used in Bluetooth. Our results show that a 4-digit PIN can be cracked in less than 0.3 sec on an old Pentium III 450MHz computer, and in 0.06 sec on a Pentium IV 3Ghz HT computer.
Article
The technology of long-distance voice and data communication incorporates millions of details. The business of selling that technology involves plenty more. Anyone hoping to navigate this jungle of facts and terminology had better keep a copy of Newton's Telecom Dictionary close at hand. It's the single best resource for quick explanations of diverse telecommunications technologies. While engaging in its loopiness, this book backs up its famous joviality with technical expertise that's unsurpassed by any other similarly comprehensive resource. Entries in this dictionary--many of them more closely resembling encyclopedia articles in their thoroughness--cover the hardware, protocols, and government regulations that define telecommunications systems worldwide. Whether you're interested in landline technologies, wireless standards, medium-neutral data protocols, or the systems that have developed to properly bill telecommunications users, Newton's Telecom Dictionary has the information you need. Once in a while, you'll find a careless error in these pages, such as the claim that Windows for Workgroups 3.11 is about to be made obsolete by Windows 95. These errors seem to reflect a bias among the members of Newton's team toward large-scale communications systems and away from consumer-oriented computer technology. Nonetheless, Newton's Telecom Dictionary earns its keep in a world where personal computers and communications appliances seem to be merging. --David Wall
Conference Paper
Motivated by the security of the nonlinear filter generator, the concept of correlation was previously extended to the conditional correlation, that studied the linear correlation of the inputs conditioned on a given (short) output pattern of some specific nonlinear function. Based on the conditional correlations, conditional correlation attacks were shown to be successful and efficient against the nonlinear filter generator. In this paper, we further generalize the concept of conditional correlations by assigning it with a different meaning, i.e. the correlation of the output of an arbitrary function conditioned on the unknown (partial) input which is uniformly distributed. Based on this generalized conditional correlation, a general statistical model is studied for dedicated key-recovery distinguishers. It is shown that the generalized conditional correlation is no smaller than the unconditional correlation. Consequently, our distinguisher improves on the traditional one (in the worst case it degrades into the traditional one). In particular, the distinguisher may be successful even if no ordinary correlation exists. As an application, a conditional correlation attack is developed and optimized against Bluetooth two-level E0. The attack is based on a recently detected flaw in the resynchronization of E0, as well as the investigation of conditional correlations in the Finite State Machine (FSM) governing the keystream output of E0. Our best attack finds the original encryption key for two-level E0 using the first 24 bits of 223.8 frames and with 238 computations. This is clearly the fastest and only practical known-plaintext attack on Bluetooth encryption compared with all existing attacks. Current experiments confirm our analysis. KeywordsStream Ciphers-Correlation-Bluetooth-E0
Conference Paper
Many security protocols have the aim of authenticating one agent to another. Yet there is no clear consensus in the academic literature about precisely what “authentication” means. We suggest that the appropriate authentication requirement will depend upon the use to which the protocol is put, and identify several possible definitions of “authentication”. We formalize each definition using the process algebra CSP, use this formalism to study their relative strengths, and show how the model checker FDR can be used to test whether a system running the protocol meets such a specification
Virus attacks mobiles via Bluetooth
  • John Oates
John Oates (2004-06-15). "Virus attacks mobiles via Bluetooth", The Register. Retrieved on 1 February 2007.
IEEE Standards Association, IEEE 802.11 speci¯cations. IEEE Standards Association, technical speci¯cations
  • Sig Bluetooth
Bluetooth SIG, Bluetooth speci¯cations 1.0, 1.1, 1.2 and 2.0+EDR. Bluetooth SIG, technical speci¯cations, 1999-2004. https://www.bluetooth.org 16. IEEE Standards Association, IEEE 802.11 speci¯cations. IEEE Standards Association, technical speci¯cations, 1999-2004.
How Bluetooth Technology Works
. "How Bluetooth Technology Works". Bluetooth SIG. Retrieved on 2008-02-01.