Guide to Bluetooth Security phần 3 pot

GUIDE TO BLUETOOTH SECURITY
If authentication fails, a Bluetooth device waits an interval of time before a new attempt is made. This
time interval increases exponentially to prevent an adversary from attempting to gain access by defeating
the authentication scheme through trial-and-error with different keys. It is important to note that this
suspend technique does not provide security against sophisticated adversaries performing offline attacks
to exhaustively search PINs.
Note that the security associated with authentication is solely based on the secrecy of the link key. While
the Bluetooth device addresses and random challenge value are considered public parameters, the link key
is not. The link key is derived during pairing and is never disclosed outside the Bluetooth device or
transmitted over wireless links. The link key is passed in the clear from the host to the host controller
(e.g., PC to USB dongle) if the host is used for key storage. The random challenge, which is a public
parameter associated with the authentication process, is designed to be different for every transaction.
The random number is derived from a pseudo-random process within the Bluetooth device. The
cryptographic response is public as well and part of the encryption establishment process.
3.4 Confidentiality
In addition to the Security Modes, Bluetooth provides a separate confidentiality service to thwart
eavesdropping attempts on the payloads of the packets exchanged between Bluetooth devices. Bluetooth
has three Encryption Modes, but only two of them actually provide confidentiality. The modes are as
follows:
 Encryption Mode 1—No encryption is performed on any traffic.
 Encryption Mode 2—Individually addressed traffic is encrypted using encryption keys based on
individual link keys; broadcast traffic is not encrypted.
 Encryption Mode 3—All traffic is encrypted using an encryption key based on the master link key.
Encryption Modes 2 and 3 use the same encryption mechanism.
As shown in Figure 3-5, the encryption key provided to the encryption algorithm is produced using an
internal key generator (KG). The KG produces stream cipher keys based on the 128-bit link key, which is
a secret that is held in the Bluetooth devices, a 128-bit random number (EN_RAND), and the 96-bit ACO
value. The ACO is produced during the authentication procedure, as shown in Figure 3-4.
The Bluetooth encryption procedure is based on a stream cipher, E
0
. A key stream output is exclusive-

OR-ed with the payload bits and sent to the receiving device. This key stream is produced using a
cryptographic algorithm based on linear feedback shift registers (LFSR).
10
The encryption function takes
the following as inputs: the master identity (BD_ADDR), the 128-bit random number (EN_RAND), a slot
number, and an encryption key, which when combined initialize the LFSRs before the transmission of
each packet, if encryption is enabled. The slot number used in the stream cipher changes with each
packet; the ciphering engine is also reinitialized with each packet while the other variables remain static.


10
LFSRs are used in coding (error control coding) theory and cryptography. LFSR-based key stream generators (KSG),
composed of exclusive-OR gates and shift registers, are common in stream ciphers and are very fast in hardware.
3-7
GUIDE TO BLUETOOTH SECURITY

Figure 3-5. Bluetooth Encryption Procedure
The encryption key (K
C
) is generated from the current link key and may vary from eight bits to 128 bits.
The key size negotiation process occurs between the master and slave devices. During negotiation, a
master device makes a key size suggestion for the slave. The initial key size suggested by the master is
programmed into the host controller by the manufacturer and is not always 128-bit. In product
implementations, a “minimum acceptable” key size parameter can be set to prevent a malicious user from
driving the key size down to the minimum of eight bits, making the link less secure.
It is important to note that E
0
is not a Federal Information Processing Standards (FIPS) approved
algorithm and has come under scrutiny recently in terms of algorithmic strength.
11

A recently published
theoretical known-plaintext attack has been discovered that can recover the encryption key in 2
38

computations, as compared to a brute force attack, which would require the testing of 2
128
possible keys.
If communications require FIPS-approved cryptographic protection (e.g., sensitive information


11
Y. Lu, W. Meier, and S. Vaudenay. “The Conditional Correlation Attack: A Practical Attack on Bluetooth Encryption”.


3-8
GUIDE TO BLUETOOTH SECURITY
transmitted by Federal agencies), this can be achieved by employing application-level FIPS-approved
encryption over the native Bluetooth encryption.
3.5 Trust Levels, Service Levels, and Authorization
In addition to the four security modes, Bluetooth allows two levels of trust and three levels of service
security. The two Bluetooth levels of trust are trusted and untrusted. A trusted device has a fixed
relationship with another device and has full access to all services. An untrusted device does not have an
established relationship with another Bluetooth device, which results in the untrusted device receiving
restricted access to services. Three levels of security have been defined for Bluetooth services. These
levels allow the requirements for authorization, authentication, and encryption to be configured and
altered independently. The service security levels are as follows:
 Service Level 1—Requires authorization and authentication. Automatic access is granted only to
trusted devices; untrusted devices need manual authorization.
 Service Level 2—Requires authentication only; authorization is not necessary. Access to an
application is allowed only after an authentication procedure.

 Service Level 3—Open to all devices, with no authentication required. Access is granted
automatically.
The Bluetooth architecture allows for defining security policies that can set trust relationships in such a
way that even trusted devices can get access only to specific services. It is important to understand that
although Bluetooth core protocols can only authenticate devices and not users, it is possible to initiate
user-based authentication in an alternative manner. The Bluetooth security architecture (through the
security manager) allows applications to enforce more granular security policies. The link layer, at which
Bluetooth-specific security controls operate, is transparent to the security controls imposed by the
application layers. Thus, it is possible to enforce user-based authentication and fine-grained access
control within the Bluetooth security framework through the application layers.
3-9
GUIDE TO BLUETOOTH SECURITY
4. Bluetooth Vulnerabilities, Threats, and Countermeasures
This section describes vulnerabilities in Bluetooth technologies and threats against those vulnerabilities.
Based on the common vulnerabilities and threats, as well as the Bluetooth security features described in
Section 3, this section also makes recommendations for possible countermeasures that can be used to
improve Bluetooth security.
Organizations that are planning countermeasures for Bluetooth technologies that use the v2.1 + EDR
specification should carefully consider its security implications. The specification was released in mid-
2007, and as of mid-2008, few products that support the specification are yet available. As the
specification 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.
4.1 Bluetooth Vulnerabilities
Table 4-1 below provides an overview of some of the known security vulnerabilities with Bluetooth. The
Bluetooth security checklist in Section 4.4 addresses these vulnerabilities.
Table 4-1. Key Problems with Existing (Native) Bluetooth Security
Security Issue or Vulnerability
Remarks

Versions Before Bluetooth v1.2
1
Unit key is reusable and becomes public
once used.
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 keystream repeats after 23.3
hours of use.
Per Figure 3-5, the encryption keystream 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.

All Versions
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.
4-1
GUIDE TO BLUETOOTH SECURITY
Remarks
Security Issue or Vulnerability
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 E
0
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, nonrepudiation, 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.

4.2 Bluetooth Threats
Bluetooth offers several benefits and advantages, but the benefits of Bluetooth are not provided without
risk. Bluetooth technology and associated devices are susceptible to general wireless networking threats,
such as denial of service attacks, eavesdropping, man-in-the-middle attacks, message modification, and
resource misappropriation,
12
and are also threatened by more specific Bluetooth-related attacks, such as
the following:


12
Additional information on general wireless security threats is available in Section 3 of NIST SP 800-48 Revision 1, Guide to
Securing Legacy IEEE 802.11 Wireless Networks (

4-2
GUIDE TO BLUETOOTH SECURITY
 Bluesnarfing. Bluesnarfing
13
enables attackers to gain access to a Bluetooth-enabled device by
exploiting a firmware flaw in older devices. This attack forces a connection to a Bluetooth device,
allowing access to data stored on the device and even the device’s international mobile equipment
identity (IMEI). The IMEI is a unique identifier for each device that an attacker could potentially use

to route all incoming calls from the user’s device to the attacker’s device.
 Bluejacking. Bluejacking is an attack conducted on Bluetooth-enabled mobile devices, such as
cellular telephones, smart phones, and PDAs. Bluejacking is initiated by an attacker sending
unsolicited messages to a user of a Bluetooth-enabled device. The actual messages do not cause harm
to the user’s device, but they are used to entice the user to respond in some fashion or add the new
contact to the device’s address book. This message-sending attack resembles spam and phishing
attacks conducted against email users. Bluejacking can cause harm when a user initiates a response to
a bluejacking message that is sent with a harmful intent.
 Bluebugging. Bluebugging
14
exploits a security flaw in the firmware of some older Bluetooth
devices to gain access to the device and its commands. This attack uses the commands of the device
without informing the user, allowing the attacker to access data, place telephone calls, eavesdrop on
telephone calls, send messages, and exploit other services or features offered by the device.
 Car Whisperer. Car Whisperer
15
is a software tool developed by European security researchers that
exploits a key implementation issue in hands-free Bluetooth car kits installed in automobiles. The car
whisperer software allows an attacker to send to or receive audio from the car kit. An attacker could
transmit audio to the car’s speakers or receive audio (eavesdrop) from the microphone in the car.
 Denial of Service. Bluetooth is susceptible to DoS attacks. Impacts include making a device’s
Bluetooth interface unusable and draining the mobile device’s battery. These types of attacks are not
significant and, due to the proximity required for Bluetooth use, can usually be easily averted by
simply walking away.
 Fuzzing Attacks. Bluetooth fuzzing attacks consist of sending malformed or otherwise non-standard
data to a device’s Bluetooth radio and observing how the device reacts. When a device’s response is
slowed or stopped by these attacks, this indicates that a serious vulnerability potentially exists in the
protocol stack.
4.3 Risk Mitigation and Countermeasures
Organizations should mitigate risks to their Bluetooth implementations by applying countermeasures to

address specific threats and vulnerabilities. Some of these countermeasures cannot be achieved through
security features built into the Bluetooth specifications. The countermeasures recommended in the
checklists in Section 4.4 do not guarantee a secure Bluetooth environment and cannot prevent all
adversary penetrations. Also, security comes at a cost—financial expenses related to security equipment,
inconvenience, maintenance, and operation. Each organization needs to evaluate the acceptable level of
risk based on numerous factors, which will affect the level of security implemented by that organization.
To be effective, Bluetooth security should be incorporated throughout the entire life cycle of Bluetooth
solutions.
16



13

14

15

16
For more information about technology life cycles, see NIST SP 800-64, Security Considerations in the Information System
Development Life Cycle (

4-3
GUIDE TO BLUETOOTH SECURITY
FIPS Publication (PUB) 199 establishes three security categories—low, moderate, and high—based on
the potential impact of a security breach involving a particular system. NIST SP 800-53 provides
recommendations for minimum management, operational, and technical security controls for information
systems based on the FIPS PUB 199 impact categories.
17
The recommendations in NIST SP 800-53

should be helpful to organizations in identifying controls that are needed to protect Bluetooth
implementations in general, which should be used in addition to the specific recommendations for
Bluetooth implementations listed in this document.
The first line of defense is to provide an adequate level of knowledge and understanding for those who
will deal with Bluetooth-enabled devices. Organizations using Bluetooth technology should establish and
document security policies that address the use of Bluetooth-enabled devices and users’ responsibilities.
Organizations should include awareness-based education to support staff understanding and knowledge of
Bluetooth. Policy documents should include a list of approved uses for Bluetooth, and the type of
information that may be transferred over Bluetooth networks. The security policy should also specify a
proper password usage scheme. When feasible, a centralized security policy management approach
should be used in coordination with an endpoint security product installed on the Bluetooth devices to
ensure that the policy is locally enforced.
The general nature and mobility of Bluetooth-enabled devices increases the difficulty of employing
traditional security measures. Nevertheless, a number of countermeasures can be enacted to secure
Bluetooth devices and communications, ranging from distance and power output to general operation
practices. Several countermeasures that could be employed are provided in the checklists in Section 4.4.
4.4 Bluetooth Security Checklists
This section provides Bluetooth security checklists. For each recommendation or guideline in a checklist,
a justification column lists areas of concern for Bluetooth devices, the security threats and vulnerabilities
associated with those areas, risk mitigations for securing the devices from these threats, and
vulnerabilities. In addition, for each recommendation and justification, a checklist with three columns is
provided. The first column, the Recommended Practice column, if checked, means that this entry
represents a recommendation for all organizations. The second column, the Should Consider column, if
checked, means that the entry’s recommendation should be considered carefully by an organization for
one or more of the following reasons. First, implementing the recommendation may provide a higher
level of security for the wireless environment by offering some additional protection. Second, the
recommendation supports a defense-in-depth strategy. Third, it may have significant performance,
operational, or cost impacts. In summary, if the Should Consider column is checked, organizations
should carefully consider the option and weigh the costs versus the benefits. The last column, Status, is
intentionally left blank to allow organization representatives to use this table as a true checklist. For

instance, an individual performing a wireless security audit in a Bluetooth environment can quickly check
off each recommendation for the organization, asking, “Have I done this?”
Table 4-2 provides a Bluetooth security checklist with guidelines and recommendations for creating and
maintaining secure Bluetooth piconets. Additional checklists for Bluetooth headsets and smart card
readers are located later in this section.


17
FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems, is available at
NIST SP 800-53 Revision 2, Recommended Security
Controls for Federal Information Systems, is available at
/>rev2-final.pdf.
4-4
GUIDE TO BLUETOOTH SECURITY
Table 4-2. Bluetooth Piconet Security Checklist
Checklist

Security Recommendation
Security Need, Requirement, or
Justification
Recom-
mended
Practice
Should
Consider
Status
Management Recommendations
1
Develop an organizational
wireless security policy that

addresses Bluetooth technology.
A security policy is the foundation for
all other countermeasures.


2
Ensure that Bluetooth users on
the network are made aware of
their security-related
responsibilities regarding
Bluetooth use.
A security awareness program helps
users to follow security practices
that help prevent security incidents.


3
Perform comprehensive security
assessments at regular intervals
to fully understand the
organization’s Bluetooth security
posture.
Bluetooth products should support
upgrade and patching of firmware to
be able to take advantage of
Bluetooth security enhancements
and fixes.


4

Ensure that wireless devices and
networks involving Bluetooth
technology are fully understood
from an architecture perspective
and documented accordingly.
Bluetooth-enabled devices can
contain various networking
technologies and interfaces allowing
connections to local and wide area
networks. An organization must
understand the overall connectivity
of each device to identify possible
risks and vulnerabilities. These risks
and vulnerabilities can then be
addressed in the wireless security
policy.



5
Provide users with a list of
precautionary measures they
should take to better protect
handheld Bluetooth devices from
theft.
The organization and its employees
should be responsible for its
wireless technology components
because theft of those components
could lead to malicious activities

against the organization’s
information system resource.



6
Maintain a complete inventory of
all Bluetooth-enabled wireless
devices and addresses
(BD_ADDRs).
A complete inventory list of
Bluetooth-enabled wireless devices
can be referenced when conducting
an audit that searches for
unauthorized use of wireless
technologies.



Technical Recommendations
7
Change the default settings of
the Bluetooth device to reflect
the organization’s security policy.
Because default settings are
generally not secure, a careful
review of those settings should be
performed to ensure that they
comply with the company security
policy.



4-5
GUIDE TO BLUETOOTH SECURITY
Checklist
Security Need, Requirement, or
Recom-
Security Recommendation
Should
Justification

mended
Status
Consider
Practice
8
Set Bluetooth devices to the
lowest necessary and sufficient
power level so that transmissions
remain within the secure
perimeter of the organization.
Setting Bluetooth devices to the
lowest necessary and sufficient
power level ensures a secure range
of access to authorized users. The
use of Class 1 devices should be
avoided due to their extended range
(approximately 100 meters).


9
Choose PIN codes that are
sufficiently random and long.
Avoid static and weak PINs, such
as all zeroes.
PIN codes should be random so that
they cannot be easily guessed by
malicious users. Longer PIN codes
are more resistant to brute force
attacks. For Bluetooth v2.0 (or
earlier) devices, an eight-character
alphanumeric PIN should be used, if
possible. The use of a fixed PIN is
not acceptable for sensitive
Bluetooth connections.


10
Ensure that link keys are based
on combination keys rather than
unit keys.
The use of shared unit keys can
lead to successful MITM attacks.
The use of unit keys for security was
deprecated in Bluetooth v1.2.


11
For v2.1 devices using Secure
Simple Pairing, avoid using the

“Just Works” model.

The “Just Works” association model
does not provide MITM protection.
Devices that only support Just
Works should not be procured if
similarly qualified devices that
support one of the other association
models (i.e., Numeric Comparison,
Out Of Band, or Passkey Entry) are
available.


12
Service and profile lockdown of
device Bluetooth stacks should
be performed.
18
Many Bluetooth stacks are designed
to support multiple profiles and
associated services. The Bluetooth
stack on a device should be locked
down to ensure only approved
profiles and services are available
for use.


13
Bluetooth devices should be
configured by default as, and

remain, undiscoverable except
as needed for pairing.
Bluetooth interfaces should be
configured as non-discoverable,
which prevents visibility to other
Bluetooth devices except when
discovery is specifically needed.
Also, the default self-identifying or
discoverable names provided on
Bluetooth devices should be
changed to anonymous,
unidentifiable names.



18
Derived from requirement 6.0 in DoD’s Bluetooth Smart Card Reader Security Requirements Matrix (01 June 2007),
available at

4-6
GUIDE TO BLUETOOTH SECURITY
Checklist
Security Need, Requirement, or
Recom-
Security Recommendation
Should
Justification

mended
Status

Consider
Practice
14
Invoke link encryption for all
Bluetooth connections regardless
of how needless encryption may
seem (i.e., no Security Mode 1).
Link encryption should be used to
secure all data transmissions during
a Bluetooth connection, otherwise
transmitted data is vulnerable to
eavesdropping.


15
If multi-hop wireless
communication is being utilized,
ensure that encryption is enabled
on every link in the
communication chain.
Every link should be secured
because one unsecured link results
in compromising the entire
communication chain.


16
Ensure device mutual
authentication is performed for all
accesses.

Mutual authentication is required to
provide verification that all devices
on the network are legitimate.


17
Enable encryption for all
broadcast transmissions
(Encryption Mode 3).
Broadcast transmissions secured by
link encryption provide a layer of
security that protects these
transmissions from user interception
for malicious purposes.


18
Configure encryption key sizes to
the maximum allowable.
Using maximum allowable key sizes
provides protection from brute force
attacks.


19
Establish a “minimum key size”
for any key negotiation process.
Establishing minimum key sizes
ensures that all keys are long
enough to be resistant to brute force

attacks. Preferably, keys should be
at least 128 bits long.


20
Use application-level (on top of
the Bluetooth stack)
authentication and encryption for
sensitive data communication.
Bluetooth devices can access link
keys from memory and automatically
connect with previously paired
devices. Incorporating application-
level software that implements
authentication and encryption will
add an extra layer of security.
Passwords and other authentication
mechanisms, such as biometrics
and smart cards, can be used to
provide user authentication for
Bluetooth devices. Employing
higher layer encryption (particularly
FIPS 140-2 validated) over the
native encryption will further protect
the data in transit.


21
Deploy user authentication such
as biometrics, smart cards, two-

factor authentication, or public
key infrastructure (PKI).
Implementing strong authentication
mechanisms can minimize the
vulnerabilities associated with
passwords and PINs.







4-7