Bluetooth Security Features - Revision history

NKirnbauer at 18:23, 22 August 2024

2024-08-22T18:23:05Z

← Older revision		Revision as of 18:23, 22 August 2024
Line 16:		Line 16:
	[[File:Table_3-1.png\|500px\|thumb\|right\|BR/EDR/HS Security Modes ]]		[[File:Table_3-1.png\|500px\|thumb\|right\|BR/EDR/HS Security Modes ]]

	Bluetooth Classic defines encryption and authentication during two different stages of the communication setup. The stages can be ~~differed in~~ Link-level and Service-level. Link-level enforced security features occur before the Bluetooth physical link is fully established. Service-level enforced security features occur after the physical link is already established and while the logical link gets established.Security mode one to ~~the~~ three were defined before Bluetooth version 2.1 came out. Bluetooth version 2.1 added the fourth security mode.		Bluetooth Classic defines encryption and authentication during two different stages of the communication setup. The stages can be differentiated as Link-level and Service-level. Link-level enforced security features occur before the Bluetooth physical link is fully established. Service-level enforced security features occur after the physical link is already established and while the logical link gets established. Security mode one to three were defined before Bluetooth version 2.1 came out. Bluetooth version 2.1 added the fourth security mode.

	=== Security Mode 1 ===		=== Security Mode 1 ===

SVeseli: /* Summary */

2020-12-21T19:49:07Z

Summary

← Older revision		Revision as of 19:49, 21 December 2020
Line 1:		Line 1:
	== Summary ==		== Summary ==

	~~'''This Page is work in progress please come back later.'''~~

	This documentation is a survey about the security features of Bluetooth Classic and Bluetooth Low Energy.		This documentation is a survey about the security features of Bluetooth Classic and Bluetooth Low Energy.

	== Basic Security Services ==		== Basic Security Services ==

SVeseli: /* Security Mode 4 */

2020-12-21T19:48:47Z

Security Mode 4

← Older revision		Revision as of 19:48, 21 December 2020
Line 45:		Line 45:

	Whether or not a link key is authenticated depends on the SSP association model used.		Whether or not a link key is authenticated depends on the SSP association model used.


	=== Secure Simple Pairing (SSP) ===		=== Secure Simple Pairing (SSP) ===

SVeseli at 18:31, 21 December 2020

2020-12-21T18:31:26Z

← Older revision		Revision as of 18:31, 21 December 2020
Line 145:		Line 145:

	* https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final		* https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final
			* https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=478726


	*[[Category:Basic]]		*[[Category:Basic]]

SVeseli: /* Security Mode 2 */

2020-12-21T18:30:19Z

Security Mode 2

← Older revision		Revision as of 18:30, 21 December 2020
Line 23:		Line 23:

	=== Security Mode 2 ===		=== Security Mode 2 ===
	~~This mode establishes security at Link-level by using a local security manager that controls the~~ access ~~of supported~~ services~~. It’s even possible to restrict access~~ on ~~a part of~~ the services ~~depending on the trust~~ to ~~the accessing device~~. ~~Bluetooth~~ service ~~discovery can~~ be ~~performed without any security challenges~~.		Security Mode 2 is called Service Level Enforced Security, access to services depends on the device. Trusted devices may use all services, untrusted devices only to a limited extent. There are three service security levels.
			* Level 1 open to all devices. It is a default mode that also allows outdated applications.
			* Level 2 authentication required, a permanently installed PIN is sufficient.
			* Level 3 requires authentication and authorization, a PIN must be entered.

	=== Security Mode 3 ===		=== Security Mode 3 ===

SVeseli at 16:26, 21 December 2020

2020-12-21T16:26:55Z

SVeseli: /* Bluetooth Classic Security */

2020-12-20T18:30:09Z

Bluetooth Classic Security

@@ Line 102: / Line 102: @@
 * '''Service Level 3:''' Requires MITM protection and encryption; user interaction is acceptable.
 * '''Service Level 4:''' Requires MITM protection and encryption with 128-bit strength; user interaction is acceptable.
 == Bluetooth Low Energy security ==

SVeseli: /* Secure Simple Pairing (SSP) */

2020-12-19T17:30:18Z

Secure Simple Pairing (SSP)

@@ Line 46: / Line 46: @@
 === Secure Simple Pairing (SSP)  ===
-Secure Simple Pairing was introduced with Security Mode 4 at Bluetooth Version 2.1 and got improved in Version 4.1. SSP provide several association models suited for all input/output capability combinations. Some of these association models are protected against passive and active man-in-the-middle (MITM) attacks during pairing by using ECDH public key cryptography.
+Secure Simple Pairing was introduced with Security Mode 4 at Bluetooth Version 2.1 and got improved in Version 4.1. The main goal of secure simple pairing is to simplify the pairing process for users. The secondary goal is to maintain or enhance the security of Bluetooth. SSP has two security goals, passive eavesdropping protection and man-in-the-middle protection. SSP provide several association models suited for all input/output capability combinations. Some of these association models are protected against passive and active man-in-the-middle (MITM) attacks during pairing by using ECDH public key cryptography.
 [[File:Association models.png|500px|thumb|right|Association models]]
@@ Line 61: / Line 61: @@
 ==== Just Works ====
 The just works model is not secured against eavesdropping and MITM attacks. This model is designed for connection where both devices have no input or output capabilities.
 === Confidentiality of the data ===

Cskallak: /* Bluetooth Low Energy security */

2020-03-05T17:38:12Z

Bluetooth Low Energy security

← Older revision		Revision as of 17:38, 5 March 2020
Line 84:		Line 84:

	== Bluetooth Low Energy security ==		== Bluetooth Low Energy security ==
	Fundamentals of the BLE Standard can be found at the [[BLE Fundamentals]] documentation.		Fundamentals of the BLE Standard can be found in the [[BLE Fundamentals]] documentation.

Cskallak: /* Bluetooth Low Energy security */

2020-03-05T17:37:53Z

Bluetooth Low Energy security

← Older revision		Revision as of 17:37, 5 March 2020
Line 84:		Line 84:

	== Bluetooth Low Energy security ==		== Bluetooth Low Energy security ==
			Fundamentals of the BLE Standard can be found at the [[BLE Fundamentals]] documentation.


	Bluetooth Low Energy security modes are similar to the Security Modes 2 and 4 of Bluetooth Classic, but each service can have its own security requirements. Furthermore, Bluetooth Low Energy has two security modes with multiple security levels.		Bluetooth Low Energy security modes are similar to the Security Modes 2 and 4 of Bluetooth Classic, but each service can have its own security requirements. Furthermore, Bluetooth Low Energy has two security modes with multiple security levels.

← Older revision		Revision as of 16:26, 21 December 2020
Line 96:		Line 96:
	* '''Encryption required'''		* '''Encryption required'''
	* '''Authorization required'''		* '''Authorization required'''

	Security mode 2 defines the following five Service security levels:		Security mode 2 defines the following five Service security levels:
	* '''Service Level 0:''' No MITM protection, encryption, or user interaction required.		* '''Service Level 0:''' No MITM protection, encryption, or user interaction required.
	* '''Service Level 1:''' MITM protection and encryption not required. Minimal user interaction.		* '''Service Level 1:''' MITM protection and encryption not required. Minimal user interaction.
	* '''Service Level 2:''' Requires encryption only; MITM protection is not necessary.		* '''Service Level 2:''' Requires encryption only; MITM protection is not necessary.
	* '''Service Level 3:''' Requires MITM protection and encryption; user interaction is acceptable.		* '''Service Level 3:''' Requires MITM protection and encryption; user interaction is acceptable.[[File:LABluetooth.PNG\|350px\|thumb\|right\|Legacy Authentication ]]
	* '''Service Level 4:''' Requires MITM protection and encryption with 128-bit strength; user interaction is acceptable.		* '''Service Level 4:''' Requires MITM protection and encryption with 128-bit strength; user interaction is acceptable.

Line 106:		Line 107:

	==== Legacy Authentication ====		==== Legacy Authentication ====
	~~[[File:LABluetooth.PNG\|400px\|thumb\|right\|Legacy Authentication ]]~~
	Legacy authentication uses a challenge-response scheme, in which a symmetric key is used to check the claimant’s key knowledge through a two-step protocol. In legacy authentication, the verifier is not required to be the master, the application indicates which device has to be authenticated. The second implies that the correct claimaint/verifier pair share the same secret keys. The verifier challenges the claimaint to authenticate a random input. Some applications only require a one-way authentication. Some peer-to-peer applications should use two authentication procedures in which each device is the challenger. In Figure is an example of a legacy authentication. The verifier has 3 input parameters, random input, bluetooth address and the link key the result is the SRES. The verifier sends the random message to the claimaint and does the same as the verifier and send back its SRES.		Legacy authentication uses a challenge-response scheme, in which a symmetric key is used to check the claimant’s key knowledge through a two-step protocol. In legacy authentication, the verifier is not required to be the master, the application indicates which device has to be authenticated. The second implies that the correct claimaint/verifier pair share the same secret keys. The verifier challenges the claimaint to authenticate a random input. Some applications only require a one-way authentication.[[File:SABluetooth.PNG\|400px\|thumb\|right\|Secure Authentication ]] Some peer-to-peer applications should use two authentication procedures in which each device is the challenger. In Figure is an example of a legacy authentication. The verifier has 3 input parameters, random input, bluetooth address and the link key the result is the SRES. The verifier sends the random message to the claimaint and does the same as the verifier and send back its SRES.

	==== Secure Authentication ====		==== Secure Authentication ====
	~~[[File:SABluetooth.PNG\|500px\|thumb\|right\|Secure Authentication ]]~~
	Secure Authentication follows the same principle but with two algorithms and several input parameters. Both devices act as a verifier and claimaint in the same sequence. Master Sends a random message to the Slave and vice verca. Both parties do their calculations and send each other their results.		Secure Authentication follows the same principle but with two algorithms and several input parameters. Both devices act as a verifier and claimaint in the same sequence. Master Sends a random message to the Slave and vice verca. Both parties do their calculations and send each other their results.
	The input parameter BD_ADDRm is the Bluetooth Address from the Master, BD_ADDRs is the bluetooth Address from the Slave, btdk is a secret string, Link Key is the shared key, AU_RANDm is the random message from the Master, AU_RANDs is the random message from the Slave, SRESm is the result of the Master, SRESs is the result of the Slave.		The input parameter BD_ADDRm is the Bluetooth Address from the Master, BD_ADDRs is the bluetooth Address from the Slave, btdk is a secret string, Link Key is the shared key, AU_RANDm is the random message from the Master, AU_RANDs is the random message from the Slave, SRESm is the result of the Master, SRESs is the result of the Slave.