Security Mode 4
the Bluetooth specification specifies four levels of security for Bluetooth
services for use during Secure Simple Pairing (SSP):
Service Level 3
requires man-in-the-middle (MITM) protection and encryption; user interaction is acceptable.
Service Level 2
requires encryption only; MITM protection is not necessary.
Service Level 1
does not require MITM protection and encryption; user interaction is minimal.
Service Level 0
does not require MITM protection, encryption, or user interaction.
5.2.1.1 Security mode 1 (non-secure)
When a remote Bluetooth device is in security mode 1 it will never initiate any
security procedure (i.e., it will never send LMP_au_rand, LMP_in_rand or
LMP_encryption_mode_req).
5.2.1.2 Security mode 2 (service level enforced security)
When a remote Bluetooth device is in security mode 2 it will not initiate any
security procedure before a channel establishment request
(L2CAP_ConnectReq) has been received or a channel establishment procedure
has been initiated by itself. (The behavior of a device in security mode 2 is
further described in [11].) Whether a security procedure is initiated or not
depends on the security requirements of the requested channel or service.
A Bluetooth device in security mode 2 should classify the security requirements
of its services using at least the following attributes:
• Authorization required
• Authentication required
• Encryption required
Note: Security mode 1 can be considered (at least from a remote device point
of view) as a special case of security mode 2 where no service has registered
any security requirements.
5.2.1.3 Security modes 3 (link level enforced security)
When a remote Bluetooth device is in security mode 3 it will initiate security
procedures before it sends LMP_setup_complete. (The behavior of a device in
security mode 3 is as described in [3].)
A Bluetooth device in security mode 3 may reject the host connection request
(respond with LMP_not_accepted to the LMP_host_connection_req) based on
settings in the host (e.g. only communication with pre-paired devices allowed).
5.2.2 Security mode 4 (service level enforced security)
A Bluetooth device in security mode 4 shall classify the security requirements
of its services using at least the following attributes (in order of decreasing
security):
• Authenticated link key required
• Unauthenticated link key required
• No security required
An authenticated link key is a link key where either the numeric comparison,
out-of-band or passkey entry simple pairing association models were used. An
authenticated link key has protection against man-in-the-middle (MITM)
attacks. To ensure that an authenticated link key is created during the Simple
Pairing procedure, the Authentication_Requirements parameter should be set
to one of the MITM Protection Required options. An unauthenticated link key is
a link key where the just works Secure Simple Pairing association model was
used. An unauthenticated link key does not have protection against MITM
attacks.
When both devices support Secure Simple Pairing, GAP shall default to requiring
an unauthenticated link key and enabling encryption. A profile or protocol
may define services that require more security (e.g. an authenticated link key).
or no security. To allow an unauthenticated link key to be created during the
Simple Pairing procedure, the Authentication_Requirements parameter may be
set to one of the MITM Protection Not Required options.
When the device is in Bondable Mode, it shall enable Secure Simple Pairing
mode prior to entering Connectable Mode or establishing a link.
Device rejected?
LMP_not_accepted LMP_accepted
yes no
Authentication /
Pairing
Encrypt
26 July 2007 Security Aspects
BLUETOOTH SPECIFICATION Version 2.1 + EDR [vol 3] page 198 of 268
Generic Access Profile
A Bluetooth device in security mode 4 shall respond to authentication requests
during link establishment when the remote device is in security mode 3 for
backwards compatibility reasons.
A Bluetooth device in security mode 4 enforces its security requirements before
it attempts to access services offered by a remote device and before it grants
access to services it offers to remote devices. Service access may occur via
L2CAP channels or via channels established by protocols above L2CAP such
as RFCOMM.