-
Mobile policy serve
-
Mode 3, enforce link encryption for all traffic
-
Mode 2, leaving security up to each application
-
Mode 1, "non-secure" mode [By default]
EXPLANATION
Security Features of Bluetooth BR/EDR/HS
Cumulatively, the family of Bluetooth BR/EDR/HS specifications definesfour security modes.Each Bluetooth device must operate in one of thesemodes, called Security Modes 1 through 4.These modes dictate when a Bluetooth device initiates security, not whether it supports security features
Security Mode 1devices are considered non-secure.Security functionality (authentication and encryption) is never initiated, leaving the device and connections susceptible to attackers.In effect, Bluetooth devices in this modeare “indiscriminate” and do not employ any mechanisms to prevent other Bluetooth-enabled devices from establishing connections.However, if a remote deviceinitiates security—such as apairing, authentication, or encryptionrequest—a Security Mode 1 device will participate.Per their respective Bluetooth specification versions, all v2.0 and earlier devices can support Security Mode 1,andv2.1 and later devices can use Security Mode 1 for backward compatibility with older devices.However, NIST recommends never using Security Mode 1.
In Security Mode 2, a service level-enforced security mode, security procedures may beinitiated after link establishment but before logicalchannel establishment.For this security mode, a local security manager (as specified in the Bluetooth architecture) controls access to specific services.The centralized security manager maintains policies for access control and interfaces with other protocols and device users.Varying security policies and trust levels to restrict access can be defined for applications with different security requirements operating in parallel. It is possible to grant access to some services without providing access to other services.In this mode, the notion of authorization—the process of deciding whether a specific device is allowed to have access to a specific service—is introduced.Typically Bluetooth service discovery can be performed prior to any security challenges (i.e.,authentication, encryption,and/orauthorization).However, all other Bluetooth services should requireall ofthose security mechanisms.
It is important to note that the authentication and encryption mechanisms used for Security Mode 2 are implemented in the controller,as with Security Mode 3described below.All v2.0 and earlier devices can support Security Mode 2,butv2.1 and laterdevices can only support it for backward compatibility with v2.0 or earlier devices.
Security Mode 3isthe linklevel-enforced security mode, in which a Bluetooth device initiates security procedures before the physical linkis fully established.Bluetooth devices operating in Security Mode 3 mandate authentication and encryptionfor all connectionsto and from the device.Therefore, even service discovery cannot be performed until after authentication, encryption,and authorization havebeenperformed.Once a device has been authenticated, service-level authorization is not typically performedby a Security Mode 3 device. However, NIST recommends that service-levelauthorization should be performed to prevent “authentication abuse”—that is, an authenticated remote device using aBluetooth service without the local device owner’s knowledge.
All v2.0 and earlier devices can support Security Mode 3,but v2.1 and later devices can only support it for backward compatibilitypurposes.
Similar to Security Mode 2, Security Mode 4 (introduced in Bluetooth v2.1 + EDR) is a service-level-enforced security mode in which security procedures are initiated after physical and logical link setup.Security Mode 4 uses Secure Simple Pairing(SSP),in which Elliptic Curve Diffie-Hellman (ECDH) key agreement replaceslegacy key agreementfor link key generation(see Section 3.1.1).However, the device authentication and encryption algorithms are identical to the algorithms in Bluetooth v2.0 + EDRand earlier versions.Security requirements for services protected by Security Mode 4 must be classified as one of the following:
- Authenticated link key required
- Unauthenticated link key required
- No security required.
Whether or not a link key is authenticated depends on the SSPassociation model used(see Section 3.1.1.2).Security Mode 4 requires encryption for all services (except Service Discovery) and is mandatory for communication between v2.1 andlaterBR/EDR devices.However, for backward compatibility, a Security Mode 4 device can fall back to any of the other three Security Modes when communicating with Bluetooth v2.0 and earlier devices that do notsupport Security Mode 4.In this case, NIST recommends using Security Mode 3.
