Guide to Bluetooth Security phần 4 pot

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

mended
Status
Consider
Practice
Operational Recommendations
22
Ensure that Bluetooth devices
are turned off when they are not
used.
Bluetooth capabilities should be
disabled on all Bluetooth devices,
except when the user explicitly
enables Bluetooth to establish a
connection. Shutting down
Bluetooth devices when not in use
minimizes exposure to potential
malicious activities.


23
Perform pairing as infrequently
as possible, ideally in a secure
area where attackers cannot

realistically observe the passkey
entry and intercept Bluetooth
pairing messages. (Note: A
“secure area” is defined as a
non-public area that is indoors
away from windows in locations
with physical access controls.)
Users should not respond to any
messages requesting a PIN,
unless the user has initiated a
pairing and is certain the PIN
request is being sent by one of
the user’s devices.
19
Pairing is a vital security function
and requires that users maintain a
security awareness of possible
eavesdroppers. If an attacker can
capture the transmitted frames
associated with pairing, determining
the link key is straightforward for
pre-v.2.1 devices (security is solely
dependent on PIN entropy and
length). This is also recommended
for v2.1 devices, although similar
attacks against Secure Simple
Pairing have not yet been
documented.


24
A service-level security mode
(i.e., Security Mode 2 or 4)
should only be used in a
controlled and well-understood
environment.
Security Mode 3 provides link-level
security prior to link establishment,
while Security Modes 2 and 4 allow
link-level connections before any
authentication or encryption is
established. It is highly
recommended that devices use
Security Mode 3. (However, note
that v2.1 devices cannot use
Security Mode 3.)


25
Ensure that portable devices with
Bluetooth interfaces are
configured with a password to
prevent unauthorized access if
lost or stolen.
Authenticating users to a portable
Bluetooth device is a good security
practice in the event the device is
lost or stolen, which provides a layer
of protection for an organization’s
Bluetooth network.



26
In the event a Bluetooth device is
lost or stolen, users should
immediately unpair the missing
device from all other Bluetooth
devices with which it was
previously paired.
This will prevent an attacker from
using the lost or stolen device to
access another Bluetooth device
owned by the user(s).



19
Derived from requirement 2.2 in DoD’s Bluetooth Smart Card Reader Security Requirements Matrix (01 June 2007),
available at
/>4-8
GUIDE TO BLUETOOTH SECURITY
Checklist
Security Need, Requirement, or
Recom-
Security Recommendation
Should
Justification

mended
Status

Consider
Practice
27
Install antivirus software on
Bluetooth-enabled hosts that are
frequently targeted by malware.
Antivirus software should be
installed on frequently targeted
Bluetooth-enabled hosts to ensure
that known malware is not
introduced to the Bluetooth network.
Organizations may also choose to
deploy antivirus software on less-
often targeted Bluetooth-enabled
hosts.



28
Fully test and deploy Bluetooth
software patches and upgrades
regularly.
Newly discovered security
vulnerabilities of vendor products
should be patched to prevent
malicious and inadvertent exploits.
Patches should be fully tested
before implementation to ensure that
they work.


29
Users should not accept
transmissions of any kind from
unknown or suspicious devices.
These types of transmissions
include messages, files, and
images.
With the increase in the number of
Bluetooth-enabled devices, it is
important that users only establish
connections with other trusted
devices and only accept content
from these trusted devices


30
Fully understand the impacts of
deploying any security feature or
product prior to deployment.
To ensure a successful deployment,
an organization should fully
understand the technical, security,
operational, and personnel
requirements prior to
implementation.


31
Designate an individual to track

the progress of Bluetooth
security products and standards
(perhaps via the Bluetooth SIG)
and the threats and
vulnerabilities with the
technology.
An appointed individual designated
to track the latest technology
enhancements, standards (perhaps
via Bluetooth SIG), and risks will
help to ensure the continued secure
use of Bluetooth.



Table 4-3 provides guidelines and recommendations on Bluetooth headsets based on the Department of
Defense’s (DoD) Bluetooth Headset Security Requirements Matrix (Version 2.0, 07 April 2008)
20
. These
recommendations are only intended for situations where the organization is concerned about threats
within physical range of the Bluetooth headset usage. Note that most commercially available Bluetooth
headsets, handsets, and hands-free devices cannot be configured to meet the recommendations in Table 4-
3. Most of those devices do not provide encryption and often use a four-digit PIN with a default value
like “0000” that cannot be changed.


20

4-9
GUIDE TO BLUETOOTH SECURITY

Table 4-3. Bluetooth Headset Security Checklist
Checklist

Security Recommendation
Security Need, Requirement, or
Justification
Recom-
mended
Practice
Should
Consider
Status
1
Bluetooth v1.2 or later should be
used.
The Bluetooth 1.2 specification
deprecated the use of unit keys for
link key generation. It also included
enhancements such as adaptive
frequency hopping (AFH) which
improved resistance to radio
frequency interference in the
crowded 2.4 GHz band (which is
used by IEEE 802.11b/g and other
protocols).


2
Bluetooth radios should be Class
2 or Class 3.

Bluetooth Class 1 radios provide
100mW of power with an
approximate range of 100 meters,
which facilitates discovery and
eavesdropping by attackers.



3
Bluetooth pairing passkeys
should be at least eight decimal
digits in length and generated
randomly for each pairing.
For pre-v2.1 devices, this is
essential to prevent link key cracking
if pairing messages have been
successfully eavesdropped by an
attacker.
Note that v2.1 devices using the
Numerical Comparison or Passkey
Entry association models will always
use a 6-digit passkey per the
Bluetooth specification. This is
currently deemed adequate since
v2.1 passkeys used during Secure
Simple Pairing—by design—cannot
be used to derive the associated link
key.


4
Perform pairing as infrequently
as possible, ideally in a secure
area where attackers cannot
realistically observe the passkey
entry and intercept Bluetooth
pairing messages. (Note: A
“secure area” is defined as a
non-public area that is indoors
away from windows in locations
with physical access controls.)
Key establishment is a vital security
function and requires that users
maintain a security awareness of
possible eavesdroppers. If an
attacker can capture the transmitted
frames associated with pairing,
determining the link key is
straightforward for pre-v.2.1 devices
(security is solely dependent on PIN
entropy and length). This is also
recommended for v2.1 devices,
although similar attacks against
Secure Simple Pairing have not yet
been documented.



4-10
GUIDE TO BLUETOOTH SECURITY

Checklist
Security Need, Requirement, or
Recom-
Security Recommendation
Should
Justification

mended
Status
Consider
Practice
5
The Bluetooth headset/audio
gateway device should remain
undiscoverable to other
Bluetooth devices at all times
other than the initial pairing
process. It should only support
the minimal amount of Bluetooth
services required for use as a
headset for a handheld device.
While a Bluetooth device is in
discoverable mode, any inquiring
device within range can capture
important connection information
including device address and clock,
which is the first stage of any
Bluetooth attack.


6
Bluetooth Security Mode 3 (link
level security) should be used by
both the headset and the audio
gateway device along with 128-
bit Bluetooth encryption.
Security Mode 3 provides link-level
security, which requires
authentication and encryption prior
to link establishment. (However,
note that v2.1 devices cannot use
Security Mode 3.) 128-bit
encryption is the maximum provided
by the Bluetooth specification, so it
should be used to mitigate potential
attacks against lower entropy (weak)
cryptographic keys.


7
Devices should support only a
single headset connection
between one headset and one
handheld device or audio
gateway device.
Bluetooth headset support for
multiple simultaneous connections
would provide an additional attack
vector.


8
The user should be able to
authorize all initial incoming
connection requests, and there
should be an indication of any
active Bluetooth link on both the
handheld device and the
Bluetooth headset.
The user should be made aware of,
and explicitly authorize, all
connections associated with the
headset to preclude potential
attacks.


9
Bluetooth stack lockdown
techniques should be used on
the handheld device to disable
unauthorized Bluetooth
connections (headset profile and
serial port profile are authorized).
Unnecessary Bluetooth services,
user controls, and applications
should be either removed from
the handheld device or reliably
disabled permanently so that
users cannot enable them.
Note: This feature may already

be included with the handheld
device security policy manager.
The Bluetooth stack on the handheld
device should only support the
minimal services/profiles approved
for use. Supporting unauthorized
services/profiles could introduce
vulnerabilities.




4-11
GUIDE TO BLUETOOTH SECURITY
Table 4-4 provides recommendations on Bluetooth smart card readers based on DoD’s Bluetooth Smart
Card Reader Security Requirements Matrix (01 June 2007)
21
. Note that FIPS-140 validated encryption is
recommended in addition to native Bluetooth authentication and encryption.
Table 4-4. Bluetooth Smart Card Reader Security Checklist
Checklist

Security Recommendation
Security Need, Requirement, or
Justification
Recom-
mended
Practice
Should
Consider

Status
1
Bluetooth mutual authentication,
128-bit Bluetooth encryption, and
FIPS 140-validated cryptography
should all be used for all
communications between the
smart card reader and the host
device.
Strong authentication and encryption
is essential to network security,
especially wireless connections.
Mutual authentication confirms both
devices have the appropriate link
key, and 128-bit encryption is the
maximum key length provided by the
Bluetooth specification. FIPS 140-
validated cryptography should also
be used to compensate for
weaknesses in the native Bluetooth
encryption.


2
Bluetooth pairing passkeys
should be at least eight decimal
digits in length and generated
randomly for each pairing.
For pre-v2.1 devices, this is
essential to prevent link key cracking

if pairing messages have been
successfully eavesdropped by an
attacker.
Note that v2.1 devices using the
Numerical Comparison or Passkey
Entry association models will always
use a 6-digit passkey per the
Bluetooth specification. This is
currently deemed adequate since
v2.1 passkeys used during Secure
Simple Pairing—by design—cannot
be used to derive the associated link
key.



3
Perform pairing as infrequently
as possible, ideally in a secure
area where attackers cannot
realistically observe the passkey
entry and intercept Bluetooth
pairing messages. (Note: A
“secure area” is defined as a
non-public area that is indoors
away from windows in locations
with physical access controls.)
Key establishment is a vital security
function and requires that users
maintain a security awareness of

possible eavesdroppers. If an
attacker can capture the transmitted
frames associated with pairing,
determining the link key is
straightforward for pre-v.2.1 devices
(security is solely dependent on PIN
entropy and length). This is also
recommended for v2.1 devices,
although similar attacks against
Secure Simple Pairing have not yet
been documented.


4
Bluetooth mutual authentication
should occur immediately after
the initial establishment of any
Bluetooth connection.
Devices should authenticate each
other as soon as possible and
certainly before providing access to
any offered services.




21

4-12
GUIDE TO BLUETOOTH SECURITY

Checklist
Security Need, Requirement, or
Recom-
Security Recommendation
Should
Justification

mended
Status
Consider
Practice
5
The Bluetooth smart card reader
should remain undiscoverable to
other Bluetooth devices at all
times other than the initial pairing
process and cannot initiate
Bluetooth connections on its
own. It should only support the
minimal amount of Bluetooth
services required for use as a
smart card reader for a single
host device.
While a Bluetooth device is in
discoverable mode, any inquiring
device within range can capture
important connection information
including device address and clock,
which is the first stage of any
Bluetooth attack.



6
Unnecessary Bluetooth services,
user controls, and applications
should be either removed from
the host device or reliably
disabled permanently.
The Bluetooth stack on the host
device should only support the
minimal features approved for use.
Supporting other features could
introduce vulnerabilities
unnecessarily.


7
All Bluetooth profiles except for
Serial Port Profile should be
disabled at all times, and the
user should not be able to enable
them.
Additional profiles could introduce
vulnerabilities unnecessarily. The
Serial Port Profile is the only profile
needed for smart card readers.


4-13

GUIDE TO BLUETOOTH SECURITY
Appendix A—Glossary of Terms
Selected terms used in the publication are defined below.
Access Point (AP): A device that logically connects wireless client devices operating in infrastructure to
one another and provides access to a distribution system, if connected, which is typically an
organization’s enterprise wired network.
Ad Hoc Network: A wireless network that dynamically connects wireless client devices to each other
without the use of an infrastructure device, such as an access point or a base station.
Claimant: The Bluetooth device attempting to prove its identity to the verifier during the Bluetooth
connection process.
Flooding: An attack in which an attacker sends large numbers of wireless messages at a high rate to
prevent the wireless network from processing legitimate traffic.
Infrared (IR): An invisible band of radiation at the lower end of the electromagnetic spectrum. It starts
at the middle of the microwave spectrum and extends to the beginning of visible light. Infrared
transmission requires an unobstructed line of sight between transmitter and receiver.
Infrastructure Network: A wireless network that requires the use of an infrastructure device, such as an
access point or a base station, to facilitate communication between client devices.
Jamming: A device emitting electromagnetic energy on a wireless network’s frequency to make it
unusable.
Media Access Control (MAC): A unique 48-bit value that is assigned to a particular wireless network
interface by the manufacturer.
Piconet: A small Bluetooth network created on an ad hoc basis that includes two or more devices.
Range: The maximum possible distance for communicating with a wireless network infrastructure or
wireless client.
Scatternet: A chain of piconets created by allowing one or more Bluetooth devices to each be a slave in
one piconet and act as the master for another piconet simultaneously. A scatternet allows several devices
to be networked over an extended distance.
Verifier: The Bluetooth device that validates the identity of the claimant during the Bluetooth connection
process.
Wireless Bridge: A device that links two wired networks, generally operating at two different physical

locations, through wireless communications.
Wireless Local Area Network (WLAN): A group of wireless AP and associated infrastructure within a
limited geographic area, such as an office building or building campus, that is capable of radio
communications. WLANs are usually implemented as extensions of existing wired LANs to provide
enhanced user mobility.

A-1
GUIDE TO BLUETOOTH SECURITY
Wireless Personal Area Network (WPAN): A small-scale wireless network that requires little or no
infrastructure and operates within a short range. A WPAN is typically used by a few devices in a single
room instead of connecting the devices with cables.

A-2
GUIDE TO BLUETOOTH SECURITY

Appendix B—Acronyms and Abbreviations
Selected acronyms and abbreviations used in the publication are defined below.

ACO Authenticated Cipher Offset
AFH Adaptive Frequency Hopping
AP Access Point

dBm Decibels referenced to one milliwatt
DISA Defense Information Systems Agency
DoD Department of Defense

ECDH Elliptic Curve Diffie Hellman
EDR Enhanced Data Rate

FHSS Frequency Hopping Spread Spectrum

FIPS Federal Information Processing Standard
FISMA Federal Information Security Management Act

GHz Gigahertz

HCI Host Controller Interface

IBC Iterated Block Ciphers
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
IPSec Internet Protocol Security
IR Infrared
ISM Industrial, Scientific, and Medical
ITL Information Technology Laboratory

Kbps Kilobits per second
KG Key Generator
KSG Key Stream Generator

L2CAP Logical Link Control and Adaptation Protocol
LAN Local Area Network
LFSR Linear Feedback Shift Register
LMP Link Manager Protocol

MAC Medium Access Control
Mbps Megabits per second
MITM Man-in-the-Middle
mW Milliwatt

NFC Near Field Communication

NIST National Institute of Standards and Technology

OMB Office of Management and Budget
OOB Out of Band

B-1
GUIDE TO BLUETOOTH SECURITY


P2P Peer to Peer
PC Personal Computer
PDA Personal Digital Assistant
PHY Physical Layer
PIN Personal Identification Number
PKI Public Key Infrastructure

RF Radio Frequency
RNG Random Number Generator
RSSI Received Signal Strength Indication

SAFER Secure And Fast Encryption Routine
SDP Service Discovery Protocol
SIG Special Interest Group
SP Special Publication
SRES Signed Response
SSP Secure Simple Pairing

TDM Time Division Multiplexing

USB Universal Serial Bus

WLAN Wireless Local Area Network
WPAN Wireless Personal Area Networks


B-2
GUIDE TO BLUETOOTH SECURITY

Appendix C—References
The list below provides references for the publication.
Bluetooth Special Interest Group, Bluetooth 2.0 and 2.1 specifications,
/>Bluetooth Special Interest Group, “Bluetooth Security White Paper”, May 2002,
/>C9578E0AE21D/0/security_whitepaper_v1.pdf
Bluetooth Special Interest Group, “Simple Pairing Whitepaper”, August 2006,
/>F2CCFA26F70F/0/SimplePairing_WP_V10r00.pdf
C. Gehrmann, J. Persson, and B. Smeets, Bluetooth Security, Artech House, 2004

Defense Information Systems Agency (DISA), “DoD Bluetooth Headset Security Requirements Matrix”,
Version 2.0, 07 April 2008,
/>0_7april2008.pdf
Defense Information Systems Agency (DISA), “DoD Bluetooth Smart Card Reader Security
Requirements Matrix”, Version 2.0, 01 June 2007,
/>Smart-Card-Reader-Security-Requirements-Matrix.pdf
Y. Lu, W. Meier, and S. Vaudenay, “The Conditional Correlation Attack: A Practical Attack on Bluetooth
Encryption”,

Y. Shaked and A. Wool, “Cracking the Bluetooth PIN”, In Proc. 3rd USENIX/ACM Conf.
Mobile Systems, Applications, and Services (MobiSys), pages 39-50, Seattle, WA, June 2005

C-1
GUIDE TO BLUETOOTH SECURITY

Appendix D—Online Resources
The lists below provide examples of online resources related to Bluetooth technologies and wireless
network security that may be helpful to readers.
Documents
Name URL
Bluetooth SIG Specifications
/>cifications/
DoD Bluetooth Headset Security Requirements
Matrix (Version 2.0, 07 April 2008)
/>urity_requirements_matrix_v2-0_7april2008.pdf
DoD Bluetooth Smart Card Reader Security
Requirements Matrix (Version 2.0, 01 June 2007)
/>Reader-Security-Requirements-Matrix.pdf
FIPS 140-2, Security Requirements for
Cryptographic Modules
/>FIPS 180-2, Secure Hash Standard (SHS)
/>2withchangenotice.pdf
FIPS 197, Advanced Encryption Standard />FIPS 199, Standards for Security Categorization of
Federal Information and Information Systems
/>final.pdf
GAO-05-383, Information Security: Federal
Agencies Need to Improve Controls over Wireless
Networks

GRS 24, Information Technology Operations and
Management Records

NIST SP 800-30, Risk Management Guide for
Information Technology Systems

NIST SP 800-32, Introduction to Public Key
Technology and the Federal PKI Infrastructure
/>NIST SP 800-48 Revision 1, Guide to Securing
Legacy IEEE 802.11 Wireless Networks
/>48r1.pdf
NIST SP 800-50, Building an Information
Technology Security Awareness and Training
Program
/>50.pdf
NIST SP 800-53 Revision 2, Recommended
Security Controls for Federal Information Systems
/>53-rev2-final.pdf
NIST SP 800-63, Electronic Authentication
Guideline
/>63V1_0_2.pdf
NIST SP 800-63-1 (Draft), Electronic
Authentication Guideline

NIST SP 800-64, Security Considerations in the
Information System Development Life Cycle
/>64.pdf
NIST SP 800-70, Security Configuration Checklists
Program for IT Products – Guidance for Checklists
Users and Developers

NIST SP 800-111, Guide to Storage Encryption
Technologies for End User Devices

/>111.pdf
NIST SP 800-114, User's Guide to Securing
External Devices for Telework and Remote Access
/>114.pdf

D-1