Elvis Wiki - User contributions [en]

Bluetooth Security Features

2020-12-21T19:49:07Z

SVeseli: /* Summary */

== Summary ==

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

== Basic Security Services ==

* '''Authentication:''' verifies the identity of communicating devices based on their Bluetooth address. User authentication is not provided by the Bluetooth Specification.
* '''Confidentiality:''' prevents eavesdropping of the transmitted data by an untrusted third person in the piconet. Confidentiality is created by data encryption.
* '''Authorization:''' controls the access of the resources. It assures that only authorized devices get permitted to access a service.
* '''Message Integrity:''' checks if the data was altered during the transmission.
* '''Pairing/Bonding:''' creates shared secret keys to use them in subsequent connections.

== Bluetooth Classic Security ==

[[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.

=== Security Mode 1 ===
This mode is considered as non-secure because it doesn’t use authentication nor encryption. Security Mode 1 is only supported by today's Bluetooth devices to communicate with old devices that are not capable of the other security modes.

=== Security Mode 2 ===
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 ===
This security mode is a link level security mode and security procedures get initiated before the physical link is fully established. Authentication and Encryption is fully supported by security mode 3 connections. Furthermore, service discovery can only be performed with an authenticated device which encrypts its traffic.

=== Security Mode 4 ===

[[File:Table_3-2.png|500px|thumb|right|BR/EDR/HS Security Mode 4 Levels Summar]]

Security mode 4 was introduced in Bluetooth version 2.1 and is a service level enforces security mode which security mechanisms get initiated after physical and logical link setup. Security mode takes advantage of the Secure Simple Pairing (SSP) Mechanism. SSP in Bluetooth version 4.1 uses the P-256 elliptic curve to generate the link key. Bluetooth 4.1 uses Hash Messages Authentication Codes Secure Hash Algorithm with 256-bit (HMAC-SHA-256) for integrity checks. For encryption the AES-Counter with CBC-MAC (AES-CCM) cypher is used. The P-256 elliptic curve, HMAC-SHA-256 and AES-CCM are security mechanisms which got approved by the Federal Information Processing Standard (FIPS). Security mode 4 gets differentiated into 5 different layers with different security levels.

* '''Layer 0:''' Layer 0 is only used by the Service Discovery Protocol (SDP). This layer doesn’t have any security features.
* '''Layer 1:''' Layer 1 doesn’t use any security.
* '''Layer 2:''' Layer 2 uses an unauthenticated link key.
* '''Layer 3:''' Layer 3 required an authenticated link key.
* '''Layer 4:''' Layer 4 uses secure connection in addition to the authenticated link key

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

=== 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. 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]]

==== Numeric Comparison ====
Numeric comparison was designed for devices, where both can display a six-digit number and allow a user input to accept and deny the connection. During the Paring both devices show a six-digit code on their displays. The user can accept the parring if the displayed numbers are the same. The connection is secure against MITM attacks and eavesdropping, if the paring was done correctly.

==== Passkey Entry ====
This model can be used where one device a has a display that sows a six-digit number and the other device has a digit input. Device a show a code that must be entered into the keyboard of the other device to establish the connection. This model is also secure against MITM attacks and eavesdropping.

==== Out of Band (OOB) ====
The out of band model uses an additional wireless or wired technology like Near Field Communication (NFC) to exchange the needed cryptographic keys. This model’s security is only as secure as the out of band technology. Even though, this association model is associated to be secure against eavesdropping and MITM attacks.

==== 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.

==== SSP Phases ====
Secure Simple Pairing consists of 5 phases:

* '''Public key exchange:''' Each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair. Pairing starts when the initiating device sends its public key to the receiving device. The responding device replies with its own public key, when both devices support Secure Connections then P-256 elliptic curve will be used, if at least one device does not support Secure Connections the P-192 elliptic curve will be used.
* '''Authentication stage 1:''' Phase 2 consist of three protocols: Numeric Comparison, Out-of-Band and Passkey Entry. The protocol is selected depending on the IO capabilities of the device.
* '''Authentication stage 2:''' Phase 3 confirms that the exchange between the two participants has been successfully completed. Both devices calculate a new confirmation value that takes into account the previously exchanged values and the new shared key. The initiator sends the new confirmations value to the responding device and is checked by it. If a failure occurs, the protocol should abort.
* '''Link key calculation:''' After both devices confirm the pairing, a link key is calculated using the shared key and the publicly exchanged data. The link key is used to maintain pairing.
* '''Link Manager Protocol Authentication and Encryption:''' Authentication and generation of the encryption key.

=== Legacy Pairing ===
With PIN / Legacy Pairing, the link keys are derived from a PIN entered by the user in one or both devices, depending on the configuration and device type. If the PIN is smaller than 16 bytes, the Bluetooth address of the initializing device is used for filling. After the key generation has been completed, the devices authenticate each other to ensure that both are using the same link key.This method only serves to mutually identify the devices and cannot prevent a man-in-the-middle attack. An attacker who knows the PIN can calculate the key from it.

=== Key Generation ===

==== Legacy Key Generation ====
The link key is a 128-bit random number, shared between two or multiple participants, and is the basis of all security transactions between these participants. The link key must be created and then distributed to the associated devices in order to be used for the authentication procedure. The initialization key is used temporarily during initialization and should be discarded afterwards. The initialization key is the result of the E22 algorithm the input parameters are a Bluetooth address, a PIN and a random number. The initialization key is used for the key exchange during the generation of a link key.

==== Secure Key Generation ====
Phase 4 (Link key calculation) of Secure Simple Pairing the link key will be established by using Elliptic Curve Diffie-Hellman public/private key pairs.

=== Confidentiality of the data ===
The Bluetooth standard defines three encryption modes for data traffic, but only two of them actuals provide confidentiality. The modes are as follows:
* '''Encryption Mode 1:''' The data traffic is unencrypted
* '''Encryption Mode 2:''' Individually addressed traffic is encrypted based on individual link keys but broadcast traffic is not.
* '''Encryption Mode 3:''' Individually addressed traffic and broadcast traffic is encrypted using an encryption key based on the master link key.
For encryption mode 2 and 3 is either the AES-CCM or E0 stream cipher used. Bluetooth Security Mode 4 encrypts all data traffic, expect service discovery messages

=== Trust Levels and Service Security Levels.===
In addition to the security modes, exist different levels of service security and trust.
The trust levels can be differentiated into trusted and untrusted. A trusted device has an established relation ship to the device and has full access to all the services. The untrusted device doesn’t have a relationship to the other device and has only a restricted access to the services.
The Service security level depend on the used Security mode. There are no Service security levels defined for Security mode 1 and 3. Security mode 2 has the following Service security levels:
* '''Authentication required'''
* '''Encryption required'''
* '''Authorization required'''

Security mode 2 defines the following five Service security levels:
* '''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 2:''' Requires encryption only; MITM protection is not necessary.
* '''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.

=== Authentication ===

==== 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.[[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 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.

== Bluetooth Low Energy security ==
Fundamentals of the BLE Standard can be found in 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.

*Low energy Security Mode 1 is associated with encryption
*Level 1 does neither use authentication nor encryption.
*Level 2 uses unauthenticated pairing with encryption.
*Level 3 uses authenticated pairing with encryption.
*Level 4 which uses authenticated low energy Secure Connections pairing with encryption.

*Low energy Security Mode 2 is associated with encryption data integrity
*Level 1 uses unauthenticated pairing with data signing.
*Level 2 uses authenticated pairing with data signing.

Security Mode 1 Level 4 is considered to create the strongest connections because it uses AES-CMAC and P-256 elliptic curve for pairing and encryption. Security Mode 1 Level 3 is less secure because it doesn’t use elliptical curve cryptography. Because Security Mode 2 does not provide encryption, it is strongly recommended to use Security Mode 1 Level 3 and 4.

== Bluetooth Classic and Bluetooth Low Energy security differences ==

[[File:Key_Differences_Between_Bluetooth_BR_EDR_and_Low_Energy.png|600px|Key Differences Between Bluetooth BR/EDR and Low Energy ]]

== References ==

* 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]]

Bluetooth Security Features

2020-12-21T19:48:47Z

SVeseli: /* Security Mode 4 */

== 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.

== Basic Security Services ==

* '''Authentication:''' verifies the identity of communicating devices based on their Bluetooth address. User authentication is not provided by the Bluetooth Specification.
* '''Confidentiality:''' prevents eavesdropping of the transmitted data by an untrusted third person in the piconet. Confidentiality is created by data encryption.
* '''Authorization:''' controls the access of the resources. It assures that only authorized devices get permitted to access a service.
* '''Message Integrity:''' checks if the data was altered during the transmission.
* '''Pairing/Bonding:''' creates shared secret keys to use them in subsequent connections.

== Bluetooth Classic Security ==

[[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.

=== Security Mode 1 ===
This mode is considered as non-secure because it doesn’t use authentication nor encryption. Security Mode 1 is only supported by today's Bluetooth devices to communicate with old devices that are not capable of the other security modes.

=== Security Mode 2 ===
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 ===
This security mode is a link level security mode and security procedures get initiated before the physical link is fully established. Authentication and Encryption is fully supported by security mode 3 connections. Furthermore, service discovery can only be performed with an authenticated device which encrypts its traffic.

=== Security Mode 4 ===

[[File:Table_3-2.png|500px|thumb|right|BR/EDR/HS Security Mode 4 Levels Summar]]

Security mode 4 was introduced in Bluetooth version 2.1 and is a service level enforces security mode which security mechanisms get initiated after physical and logical link setup. Security mode takes advantage of the Secure Simple Pairing (SSP) Mechanism. SSP in Bluetooth version 4.1 uses the P-256 elliptic curve to generate the link key. Bluetooth 4.1 uses Hash Messages Authentication Codes Secure Hash Algorithm with 256-bit (HMAC-SHA-256) for integrity checks. For encryption the AES-Counter with CBC-MAC (AES-CCM) cypher is used. The P-256 elliptic curve, HMAC-SHA-256 and AES-CCM are security mechanisms which got approved by the Federal Information Processing Standard (FIPS). Security mode 4 gets differentiated into 5 different layers with different security levels.

* '''Layer 0:''' Layer 0 is only used by the Service Discovery Protocol (SDP). This layer doesn’t have any security features.
* '''Layer 1:''' Layer 1 doesn’t use any security.
* '''Layer 2:''' Layer 2 uses an unauthenticated link key.
* '''Layer 3:''' Layer 3 required an authenticated link key.
* '''Layer 4:''' Layer 4 uses secure connection in addition to the authenticated link key

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

=== 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. 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]]

==== Numeric Comparison ====
Numeric comparison was designed for devices, where both can display a six-digit number and allow a user input to accept and deny the connection. During the Paring both devices show a six-digit code on their displays. The user can accept the parring if the displayed numbers are the same. The connection is secure against MITM attacks and eavesdropping, if the paring was done correctly.

==== Passkey Entry ====
This model can be used where one device a has a display that sows a six-digit number and the other device has a digit input. Device a show a code that must be entered into the keyboard of the other device to establish the connection. This model is also secure against MITM attacks and eavesdropping.

==== Out of Band (OOB) ====
The out of band model uses an additional wireless or wired technology like Near Field Communication (NFC) to exchange the needed cryptographic keys. This model’s security is only as secure as the out of band technology. Even though, this association model is associated to be secure against eavesdropping and MITM attacks.

==== 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.

==== SSP Phases ====
Secure Simple Pairing consists of 5 phases:

* '''Public key exchange:''' Each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair. Pairing starts when the initiating device sends its public key to the receiving device. The responding device replies with its own public key, when both devices support Secure Connections then P-256 elliptic curve will be used, if at least one device does not support Secure Connections the P-192 elliptic curve will be used.
* '''Authentication stage 1:''' Phase 2 consist of three protocols: Numeric Comparison, Out-of-Band and Passkey Entry. The protocol is selected depending on the IO capabilities of the device.
* '''Authentication stage 2:''' Phase 3 confirms that the exchange between the two participants has been successfully completed. Both devices calculate a new confirmation value that takes into account the previously exchanged values and the new shared key. The initiator sends the new confirmations value to the responding device and is checked by it. If a failure occurs, the protocol should abort.
* '''Link key calculation:''' After both devices confirm the pairing, a link key is calculated using the shared key and the publicly exchanged data. The link key is used to maintain pairing.
* '''Link Manager Protocol Authentication and Encryption:''' Authentication and generation of the encryption key.

=== Legacy Pairing ===
With PIN / Legacy Pairing, the link keys are derived from a PIN entered by the user in one or both devices, depending on the configuration and device type. If the PIN is smaller than 16 bytes, the Bluetooth address of the initializing device is used for filling. After the key generation has been completed, the devices authenticate each other to ensure that both are using the same link key.This method only serves to mutually identify the devices and cannot prevent a man-in-the-middle attack. An attacker who knows the PIN can calculate the key from it.

=== Key Generation ===

==== Legacy Key Generation ====
The link key is a 128-bit random number, shared between two or multiple participants, and is the basis of all security transactions between these participants. The link key must be created and then distributed to the associated devices in order to be used for the authentication procedure. The initialization key is used temporarily during initialization and should be discarded afterwards. The initialization key is the result of the E22 algorithm the input parameters are a Bluetooth address, a PIN and a random number. The initialization key is used for the key exchange during the generation of a link key.

==== Secure Key Generation ====
Phase 4 (Link key calculation) of Secure Simple Pairing the link key will be established by using Elliptic Curve Diffie-Hellman public/private key pairs.

=== Confidentiality of the data ===
The Bluetooth standard defines three encryption modes for data traffic, but only two of them actuals provide confidentiality. The modes are as follows:
* '''Encryption Mode 1:''' The data traffic is unencrypted
* '''Encryption Mode 2:''' Individually addressed traffic is encrypted based on individual link keys but broadcast traffic is not.
* '''Encryption Mode 3:''' Individually addressed traffic and broadcast traffic is encrypted using an encryption key based on the master link key.
For encryption mode 2 and 3 is either the AES-CCM or E0 stream cipher used. Bluetooth Security Mode 4 encrypts all data traffic, expect service discovery messages

=== Trust Levels and Service Security Levels.===
In addition to the security modes, exist different levels of service security and trust.
The trust levels can be differentiated into trusted and untrusted. A trusted device has an established relation ship to the device and has full access to all the services. The untrusted device doesn’t have a relationship to the other device and has only a restricted access to the services.
The Service security level depend on the used Security mode. There are no Service security levels defined for Security mode 1 and 3. Security mode 2 has the following Service security levels:
* '''Authentication required'''
* '''Encryption required'''
* '''Authorization required'''

Security mode 2 defines the following five Service security levels:
* '''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 2:''' Requires encryption only; MITM protection is not necessary.
* '''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.

=== Authentication ===

==== 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.[[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 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.

== Bluetooth Low Energy security ==
Fundamentals of the BLE Standard can be found in 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.

*Low energy Security Mode 1 is associated with encryption
*Level 1 does neither use authentication nor encryption.
*Level 2 uses unauthenticated pairing with encryption.
*Level 3 uses authenticated pairing with encryption.
*Level 4 which uses authenticated low energy Secure Connections pairing with encryption.

*Low energy Security Mode 2 is associated with encryption data integrity
*Level 1 uses unauthenticated pairing with data signing.
*Level 2 uses authenticated pairing with data signing.

Security Mode 1 Level 4 is considered to create the strongest connections because it uses AES-CMAC and P-256 elliptic curve for pairing and encryption. Security Mode 1 Level 3 is less secure because it doesn’t use elliptical curve cryptography. Because Security Mode 2 does not provide encryption, it is strongly recommended to use Security Mode 1 Level 3 and 4.

== Bluetooth Classic and Bluetooth Low Energy security differences ==

[[File:Key_Differences_Between_Bluetooth_BR_EDR_and_Low_Energy.png|600px|Key Differences Between Bluetooth BR/EDR and Low Energy ]]

== References ==

* 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]]

KNOB Attack

2020-12-21T19:48:11Z

SVeseli: /* Key negotiation protocol */

== Summary ==

The attack was found 2019 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
Bluetooth specification has an encryption key negotiation protocol to negotiate encryption keys. Attackers can manipulate this protocol to force encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. This enables brute forcing the encryption keys in real time.
[[File:bluetoothKNOB.PNG|300px|thumb|right|Key negotiation protocol]]

== Key negotiation protocol ==

The goal of this protocol is to compute a session key starting from a long term shared secret
At the top is Encryption Key Generation Function that takes as input the longterm secret a bunch of nonces and Bluetooth address of Slave and is computing Kc a key with 16 Bytes of entropy this key is not used as session key it is processed by an entropy reduction function that is used to modify the entropy to N bytes and this N number is computed from an entropy negotiation phase that is performed by alice and bob. This session key is used to encrypt and decrypt the packets using E0 stream cipher in case using legacy security mode or AES-CCM if both devices supporting Bluetooth secure connections.

== Stages of Attack ==
KNOB Attack has 4 Main stages
* '''First stage:''' Alice and Bob (Victims) are pairing using the strongest security mechanisms Secure Simple pairing. They are establishing a long term secret and the attacker is not there.
* '''Second Phase:''' Alice and Bob wants to establish a new encrypted session and Charlie(Attacker) is in Bluetooth range with the victim.
* '''Phase 3:''' Charlie is able to manipulate the entropy negotiation phase of Bluetooth and let the two victim negotiate an encryption key with one byte of entropy.
* '''Phase 4:''' Charlie is able to eavesdropping ciphertext and using the ciphertext to bruteforce the encryption key and the brute force is in real time because If you use an encryption key with 1 Byte of entropy then you have to brute force one key out of 256 possibilities.

== Requirements ==

* Clone Github https://github.com/francozappa/knob
* Rooted Nexus 5 running the internalblue/android_bluetooth_stack/nexus5_android6_0_1/bluetooth.default.so custom Android Bluetooth stack
* Computer running Linux operating system
* Wireshark

Internalblue is a framework which can patch the firmware from the operating system.
This attack is simulating an attacker using Internalblue, because the setup is easier, has a higher reliability, and it is cheaper than over the air.

== Perform Attack ==

* Connect Nexus 5 via USB to the computer
* Configure and install modified internalblue v0.1
** Edit '''internalblue/internalblue/core.py''' and set '''NEXUS5_MODE''' to which mode you want to perform
** Set '''NEXUS5_MODE = MASTER_MITM''' then the Nexus 5 is the master device or '''NEXUS5_MODE = SLAVE_MITM''' to set Nexus 5 to the slave device
** In terminal, switch into the '''internalblue''' directory, and run '''sudo python2 setup.py install'''
** Open a terminal and run internalblue (Internalblue is inserted in PATH Variable)
* In the internalblue menu start LMP monitoring with monitor lmp start
** A Wireshark window should pop up
* Pair target with Nexus 5
* When Nexus 5 is as the master configured ('''NEXUS5_MODE = MASTER_MITM''') then you have to start the connection from the Nexus 5 to the target device.
* When the Nexus 5 is as the slave configured ('''NEXUS5_MODE = SLAVE_MITM''') then you have to start the connection from the victim to the Nexus 5.
* In Wireshark you can see that the devices have negotiated an encryption key with 1 byte of entropy.

== Countermeasures ==
* Force minimum and maximum amount of entropy that cannot be easily brute forced.
* Encryption keys with a fixed number of entropy.

== References ==

* https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli
* https://www.usenix.org/system/files/sec19-antonioli.pdf
* https://francozappa.github.io/publication/knob/
* https://github.com/francozappa/knob

[[Category:Documentation]]

KNOB Attack

2020-12-21T19:48:04Z

SVeseli: /* Countermeasures */

BIAS Attack

2020-12-21T19:46:37Z

SVeseli: /* Requirements */

== Description ==
Bluetooth Impersonation AttackS (BIAS) was found 2020 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
The Bluetooth specification includes authentication mechanisms based on long term pairing key, which are created to protect against impersonation attacks. This attack shows that this mechanisms are not reliable and that an attacker can use the mechanisms to impersonate any master or slave device.

== Example ==
* Victims Alice & Bob share a long term key and support mutual authentication
*Attacker Charlie presents to Bob as Alice and downgrades mutual authentication to unilateral authentication.
* Abuses Bluetooth role switching to become the new authenticator. Authenticates bob and starts a secure session with Bob as Alice without having to authenticate.

== Requirements ==

* Clone Github https://github.com/francozappa/bias
* CYW920819 devboard
* Google Pixel 2
* Linux laptop that can parse diagnostic messages from CYW920819 devboard and run internalblue. Can be achieved by using vanilla linux-4.14.111 kernel compiled with provided modifications of github.

== Perform Attack ==
* Open '''IF_PIXEL2''' File
** Change the '''btadd''' to the Bluetooth address of the impersonated device
** Change the '''btname''' to the Bluetooth name of the impersonated device
** Change lmin and lmax to set the max and min entropy value for the session key
* Connect the devboard to laptop via USB
* Attach to the devboard with '''btattach -B /dev/ttyUSB1 -S 115200 &'''
* Enable the devboard diagnostic mode with '''sudo python2 enable_diag.py'''
* Start internalblue with '''sudo internalblue'''
* Start wireshark monitoring from internalblue
* Use '''make generate''' to create '''bias.py'''
* Pair the impersonated victim (Pixel 2) and the other victim device
* Disconnect them and disable Bluetooth on the impersonated device (Pixel 2)
* Start a connection from the victim to the impersonated device (BIAS slave impersonation)
* Start a connection from the attack device to the victim (BIAS master impersonation)

== Countermeasures ==
To reduce the lack of integrity protection during secure connection establishment, the standard should force to use the long term key to protect the connection establishment. Before creating a secure connection the long term key should be available. The standard should force to always use the legacy authentication procedure mutually.

== References ==

* https://francozappa.github.io/publication/bias/paper.pdf
* https://github.com/francozappa/bias
* https://francozappa.github.io/about-bias/
* https://www.youtube.com/watch?v=fASGU7Og5_4&feature=emb_title

[[Category:Documentation]]

BIAS Attack

2020-12-21T19:46:13Z

SVeseli: /* Counter Measures */

== Description ==
Bluetooth Impersonation AttackS (BIAS) was found 2020 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
The Bluetooth specification includes authentication mechanisms based on long term pairing key, which are created to protect against impersonation attacks. This attack shows that this mechanisms are not reliable and that an attacker can use the mechanisms to impersonate any master or slave device.

== Example ==
* Victims Alice & Bob share a long term key and support mutual authentication
*Attacker Charlie presents to Bob as Alice and downgrades mutual authentication to unilateral authentication.
* Abuses Bluetooth role switching to become the new authenticator. Authenticates bob and starts a secure session with Bob as Alice without having to authenticate.

== Requirements ==

* Clone Github https://github.com/francozappa/bias
* CYW920819 devboard
* Google Pixel 2
* Linux laptop that can parse diagnostic messages from CYW920819 devboard & run internalblue. Can be achieved by using vanilla linux-4.14.111 kernel compiled with provided modifications of github.

== Perform Attack ==
* Open '''IF_PIXEL2''' File
** Change the '''btadd''' to the Bluetooth address of the impersonated device
** Change the '''btname''' to the Bluetooth name of the impersonated device
** Change lmin and lmax to set the max and min entropy value for the session key
* Connect the devboard to laptop via USB
* Attach to the devboard with '''btattach -B /dev/ttyUSB1 -S 115200 &'''
* Enable the devboard diagnostic mode with '''sudo python2 enable_diag.py'''
* Start internalblue with '''sudo internalblue'''
* Start wireshark monitoring from internalblue
* Use '''make generate''' to create '''bias.py'''
* Pair the impersonated victim (Pixel 2) and the other victim device
* Disconnect them and disable Bluetooth on the impersonated device (Pixel 2)
* Start a connection from the victim to the impersonated device (BIAS slave impersonation)
* Start a connection from the attack device to the victim (BIAS master impersonation)

== Countermeasures ==
To reduce the lack of integrity protection during secure connection establishment, the standard should force to use the long term key to protect the connection establishment. Before creating a secure connection the long term key should be available. The standard should force to always use the legacy authentication procedure mutually.

== References ==

* https://francozappa.github.io/publication/bias/paper.pdf
* https://github.com/francozappa/bias
* https://francozappa.github.io/about-bias/
* https://www.youtube.com/watch?v=fASGU7Og5_4&feature=emb_title

[[Category:Documentation]]

KNOB Attack

2020-12-21T19:45:46Z

SVeseli:

KNOB Attack

2020-12-21T19:45:03Z

SVeseli: /* Perform Attack */

== Summary ==

The attack was found 2019 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
Bluetooth specification has an encryption key negotiation protocol to negotiate encryption keys. Attackers can manipulate this protocol to force encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. This enables brute forcing the encryption keys in real time.
[[File:bluetoothKNOB.PNG|300px|thumb|right|Key negotiation protocol]]

== Key negotiation protocol ==

The goal of this protocol is to compute a session key starting from a long term shared secret
At the top is Encryption Key Generation Function that takes as input the longterm secret a bunch of nonces and Bluetooth address of Slave and is computing Kc a key with 16 Bytes of entropy this key is not used as session key it is processed by an entropy reduction function that is used to modify the entropy to N bytes and this N number is computed from an entropy negotiation phase that is performed by alice and bob. This session key is used to encrypt and decrypt the packets using E0 stream cipher in case using legacy security mode or AES-CCM if both devices supporting Bluetooth secure connections.

== Stages of Attack ==
KNOB Attack has 4 Main stages
* '''First stage:''' Alice and Bob (Victims) are pairing using the strongest security mechanisms Secure Simple pairing. They are establishing a long term secret and the attacker is not there.
* '''Second Phase:''' Alice and Bob wants to establish a new encrypted session and Charlie(Attacker) is in Bluetooth range with the victim.
* '''Phase 3:''' Charlie is able to manipulate the entropy negotiation phase of Bluetooth and let the two victim negotiate an encryption key with one byte of entropy.
* '''Phase 4:''' Charlie is able to eavesdropping ciphertext and using the ciphertext to bruteforce the encryption key and the brute force is in real time because If you use an encryption key with 1 Byte of entropy then you have to brute force one key out of 256 possibilities.

== Requirements ==

* Clone Github https://github.com/francozappa/knob
* Rooted Nexus 5 running the internalblue/android_bluetooth_stack/nexus5_android6_0_1/bluetooth.default.so custom Android Bluetooth stack
* Computer running Linux operating system
* Wireshark

Internalblue is a framework which can patch the firmware from the operating system.
This attack is simulating an attacker using Internalblue, because the setup is easier, has a higher reliability, and it is cheaper than over the air.

== Perform Attack ==

* Connect Nexus 5 via USB to the computer
* Configure and install modified internalblue v0.1
** Edit '''internalblue/internalblue/core.py''' and set '''NEXUS5_MODE''' to which mode you want to perform
** Set '''NEXUS5_MODE = MASTER_MITM''' then the Nexus 5 is the master device or '''NEXUS5_MODE = SLAVE_MITM''' to set Nexus 5 to the slave device
** In terminal, switch into the '''internalblue''' directory, and run '''sudo python2 setup.py install'''
** Open a terminal and run internalblue (Internalblue is inserted in PATH Variable)
* In the internalblue menu start LMP monitoring with monitor lmp start
** A Wireshark window should pop up
* Pair target with Nexus 5
* When Nexus 5 is as the master configured ('''NEXUS5_MODE = MASTER_MITM''') then you have to start the connection from the Nexus 5 to the target device.
* When the Nexus 5 is as the slave configured ('''NEXUS5_MODE = SLAVE_MITM''') then you have to start the connection from the victim to the Nexus 5.
* In Wireshark you can see that the devices have negotiated an encryption key with 1 byte of entropy.

== References ==

* https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli
* https://www.usenix.org/system/files/sec19-antonioli.pdf
* https://francozappa.github.io/publication/knob/
* https://github.com/francozappa/knob

[[Category:Documentation]]

KNOB Attack

2020-12-21T19:44:02Z

SVeseli: /* Stages of Attack */

== Summary ==

The attack was found 2019 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
Bluetooth specification has an encryption key negotiation protocol to negotiate encryption keys. Attackers can manipulate this protocol to force encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. This enables brute forcing the encryption keys in real time.
[[File:bluetoothKNOB.PNG|300px|thumb|right|Key negotiation protocol]]

== Key negotiation protocol ==

The goal of this protocol is to compute a session key starting from a long term shared secret
At the top is Encryption Key Generation Function that takes as input the longterm secret a bunch of nonces and Bluetooth address of Slave and is computing Kc a key with 16 Bytes of entropy this key is not used as session key it is processed by an entropy reduction function that is used to modify the entropy to N bytes and this N number is computed from an entropy negotiation phase that is performed by alice and bob. This session key is used to encrypt and decrypt the packets using E0 stream cipher in case using legacy security mode or AES-CCM if both devices supporting Bluetooth secure connections.

== Stages of Attack ==
KNOB Attack has 4 Main stages
* '''First stage:''' Alice and Bob (Victims) are pairing using the strongest security mechanisms Secure Simple pairing. They are establishing a long term secret and the attacker is not there.
* '''Second Phase:''' Alice and Bob wants to establish a new encrypted session and Charlie(Attacker) is in Bluetooth range with the victim.
* '''Phase 3:''' Charlie is able to manipulate the entropy negotiation phase of Bluetooth and let the two victim negotiate an encryption key with one byte of entropy.
* '''Phase 4:''' Charlie is able to eavesdropping ciphertext and using the ciphertext to bruteforce the encryption key and the brute force is in real time because If you use an encryption key with 1 Byte of entropy then you have to brute force one key out of 256 possibilities.

== Requirements ==

* Clone Github https://github.com/francozappa/knob
* Rooted Nexus 5 running the internalblue/android_bluetooth_stack/nexus5_android6_0_1/bluetooth.default.so custom Android Bluetooth stack
* Computer running Linux operating system
* Wireshark

Internalblue is a framework which can patch the firmware from the operating system.
This attack is simulating an attacker using Internalblue, because the setup is easier, has a higher reliability, and it is cheaper than over the air.

== Perform Attack ==

* Connect Nexus 5 via USB to the computer
* Configure and install modified internalblue v0.1
** Edit '''internalblue/internalblue/core.py''' and set '''NEXUS5_MODE''' to which mode you want to perform
** Set '''NEXUS5_MODE = MASTER_MITM''' then the Nexus 5 is the master device or '''NEXUS5_MODE = SLAVE_MITM''' to set Nexus 5 to the slave device
** In terminal, switch into the '''internalblue''' directory, and run '''sudo python2 setup.py install'''
** Open a terminal and run internalblue (Internalblue is inserted in PATH Variable)
* In the internalblue menu start LMP monitoring with monitor lmp start
** A Wireshark window should pop up
* Pair target with Nexus 5
* When Nexus 5 is as the master configured ('''NEXUS5_MODE = MASTER_MITM''') then you have to start the connection from the Nexus 5 to the target device.
* When the Nexus 5 is as the slave configured (NEXUS5_MODE = SLAVE_MITM) then you have to start the connection from the victim to the Nexus 5.
* In Wireshark you can see that the devices have negotiated an encryption key with 1 byte of entropy.

== References ==

* https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli
* https://www.usenix.org/system/files/sec19-antonioli.pdf
* https://francozappa.github.io/publication/knob/
* https://github.com/francozappa/knob

[[Category:Documentation]]

BIAS Attack

2020-12-21T19:10:13Z

SVeseli: /* Requirements */

== Description ==
Bluetooth Impersonation AttackS (BIAS) was found 2020 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
The Bluetooth specification includes authentication mechanisms based on long term pairing key, which are created to protect against impersonation attacks. This attack shows that this mechanisms are not reliable and that an attacker can use the mechanisms to impersonate any master or slave device.

== Example ==
* Victims Alice & Bob share a long term key and support mutual authentication
*Attacker Charlie presents to Bob as Alice and downgrades mutual authentication to unilateral authentication.
* Abuses Bluetooth role switching to become the new authenticator. Authenticates bob and starts a secure session with Bob as Alice without having to authenticate.

== Requirements ==

* Clone Github https://github.com/francozappa/bias
* CYW920819 devboard
* Google Pixel 2
* Linux laptop that can parse diagnostic messages from CYW920819 devboard & run internalblue. Can be achieved by using vanilla linux-4.14.111 kernel compiled with provided modifications of github.

== Perform Attack ==
* Open '''IF_PIXEL2''' File
** Change the '''btadd''' to the Bluetooth address of the impersonated device
** Change the '''btname''' to the Bluetooth name of the impersonated device
** Change lmin and lmax to set the max and min entropy value for the session key
* Connect the devboard to laptop via USB
* Attach to the devboard with '''btattach -B /dev/ttyUSB1 -S 115200 &'''
* Enable the devboard diagnostic mode with '''sudo python2 enable_diag.py'''
* Start internalblue with '''sudo internalblue'''
* Start wireshark monitoring from internalblue
* Use '''make generate''' to create '''bias.py'''
* Pair the impersonated victim (Pixel 2) and the other victim device
* Disconnect them and disable Bluetooth on the impersonated device (Pixel 2)
* Start a connection from the victim to the impersonated device (BIAS slave impersonation)
* Start a connection from the attack device to the victim (BIAS master impersonation)

== Counter Measures ==
To reduce the lack of integrity protection during secure connection establishment, the standard should force to use the long term key to protect the connection establishment. Before creating a secure connection the long term key should be available. The standard should force to always use the legacy authentication procedure mutually.
== References ==

* https://francozappa.github.io/publication/bias/paper.pdf
* https://github.com/francozappa/bias
* https://francozappa.github.io/about-bias/
* https://www.youtube.com/watch?v=fASGU7Og5_4&feature=emb_title

[[Category:Documentation]]

BIAS Attack

2020-12-21T19:09:21Z

SVeseli: /* Summary */

== Description ==
Bluetooth Impersonation AttackS (BIAS) was found 2020 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
The Bluetooth specification includes authentication mechanisms based on long term pairing key, which are created to protect against impersonation attacks. This attack shows that this mechanisms are not reliable and that an attacker can use the mechanisms to impersonate any master or slave device.

== Example ==
* Victims Alice & Bob share a long term key and support mutual authentication
*Attacker Charlie presents to Bob as Alice and downgrades mutual authentication to unilateral authentication.
* Abuses Bluetooth role switching to become the new authenticator. Authenticates bob and starts a secure session with Bob as Alice without having to authenticate.

== Requirements ==

* Clone Github https://github.com/francozappa/bias
* CYW920819 devboard
* Google Pixel 2
* Linux laptop that can parse diagnostic messages from CYW920819 devboard & run internalblue. Can be accomplished by using vanilla linux-4.14.111 kernel compiled with provided modifications of github.

== Perform Attack ==
* Open '''IF_PIXEL2''' File
** Change the '''btadd''' to the Bluetooth address of the impersonated device
** Change the '''btname''' to the Bluetooth name of the impersonated device
** Change lmin and lmax to set the max and min entropy value for the session key
* Connect the devboard to laptop via USB
* Attach to the devboard with '''btattach -B /dev/ttyUSB1 -S 115200 &'''
* Enable the devboard diagnostic mode with '''sudo python2 enable_diag.py'''
* Start internalblue with '''sudo internalblue'''
* Start wireshark monitoring from internalblue
* Use '''make generate''' to create '''bias.py'''
* Pair the impersonated victim (Pixel 2) and the other victim device
* Disconnect them and disable Bluetooth on the impersonated device (Pixel 2)
* Start a connection from the victim to the impersonated device (BIAS slave impersonation)
* Start a connection from the attack device to the victim (BIAS master impersonation)

== Counter Measures ==
To reduce the lack of integrity protection during secure connection establishment, the standard should force to use the long term key to protect the connection establishment. Before creating a secure connection the long term key should be available. The standard should force to always use the legacy authentication procedure mutually.
== References ==

* https://francozappa.github.io/publication/bias/paper.pdf
* https://github.com/francozappa/bias
* https://francozappa.github.io/about-bias/
* https://www.youtube.com/watch?v=fASGU7Og5_4&feature=emb_title

[[Category:Documentation]]

BIAS Attack

2020-12-21T19:08:44Z

SVeseli: Created page with "== Summary == Bluetooth Impersonation AttackS (BIAS) was found 2020 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen. The Bluetooth specification includes a..."

== Summary ==
Bluetooth Impersonation AttackS (BIAS) was found 2020 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
The Bluetooth specification includes authentication mechanisms based on long term pairing key, which are created to protect against impersonation attacks. This attack shows that this mechanisms are not reliable and that an attacker can use the mechanisms to impersonate any master or slave device.

== Example ==
* Victims Alice & Bob share a long term key and support mutual authentication
*Attacker Charlie presents to Bob as Alice and downgrades mutual authentication to unilateral authentication.
* Abuses Bluetooth role switching to become the new authenticator. Authenticates bob and starts a secure session with Bob as Alice without having to authenticate.

== Requirements ==

* Clone Github https://github.com/francozappa/bias
* CYW920819 devboard
* Google Pixel 2
* Linux laptop that can parse diagnostic messages from CYW920819 devboard & run internalblue. Can be accomplished by using vanilla linux-4.14.111 kernel compiled with provided modifications of github.

== Perform Attack ==
* Open '''IF_PIXEL2''' File
** Change the '''btadd''' to the Bluetooth address of the impersonated device
** Change the '''btname''' to the Bluetooth name of the impersonated device
** Change lmin and lmax to set the max and min entropy value for the session key
* Connect the devboard to laptop via USB
* Attach to the devboard with '''btattach -B /dev/ttyUSB1 -S 115200 &'''
* Enable the devboard diagnostic mode with '''sudo python2 enable_diag.py'''
* Start internalblue with '''sudo internalblue'''
* Start wireshark monitoring from internalblue
* Use '''make generate''' to create '''bias.py'''
* Pair the impersonated victim (Pixel 2) and the other victim device
* Disconnect them and disable Bluetooth on the impersonated device (Pixel 2)
* Start a connection from the victim to the impersonated device (BIAS slave impersonation)
* Start a connection from the attack device to the victim (BIAS master impersonation)

== Counter Measures ==
To reduce the lack of integrity protection during secure connection establishment, the standard should force to use the long term key to protect the connection establishment. Before creating a secure connection the long term key should be available. The standard should force to always use the legacy authentication procedure mutually.
== References ==

* https://francozappa.github.io/publication/bias/paper.pdf
* https://github.com/francozappa/bias
* https://francozappa.github.io/about-bias/
* https://www.youtube.com/watch?v=fASGU7Og5_4&feature=emb_title

[[Category:Documentation]]

Bluetooth Security Features

2020-12-21T18:31:26Z

SVeseli:

Bluetooth Security Features

2020-12-21T18:30:19Z

SVeseli: /* Security Mode 2 */

KNOB Attack

2020-12-21T18:27:38Z

SVeseli:

== Summary ==

The attack was found 2019 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
Bluetooth specification has an encryption key negotiation protocol to negotiate encryption keys. Attackers can manipulate this protocol to force encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. This enables brute forcing the encryption keys in real time.
[[File:bluetoothKNOB.PNG|300px|thumb|right|Key negotiation protocol]]

== Key negotiation protocol ==

The goal of this protocol is to compute a session key starting from a long term shared secret
At the top is Encryption Key Generation Function that takes as input the longterm secret a bunch of nonces and Bluetooth address of Slave and is computing Kc a key with 16 Bytes of entropy this key is not used as session key it is processed by an entropy reduction function that is used to modify the entropy to N bytes and this N number is computed from an entropy negotiation phase that is performed by alice and bob. This session key is used to encrypt and decrypt the packets using E0 stream cipher in case using legacy security mode or AES-CCM if both devices supporting Bluetooth secure connections.

== Stages of Attack ==
KNOB Attack has 4 Main stages
* '''First stage:''' Alice and Bob are pairing using the strongest security mechanisms Secure Simple pairing. They are establishing a long term secret and the attacker is not there.
* '''Second Phase:''' Alice and Bob wants to establish a new encrypted session and Charlie is in Bluetooth range with the victim.
* '''Phase 3:''' Charlie is able to manipulate the entropy negotiation phase of Bluetooth and let the two victim negotiate an encryption key with one byte of entropy.
* '''Phase 4:''' Charlie is able to eavesdropping ciphertext and using the ciphertext to bruteforce the encryption key and the brute force is in real time because If you use an encryption key with 1 Byte of entropy then you have to brute force one key out of 256 possibilities.

== Requirements ==

* Clone Github https://github.com/francozappa/knob
* Rooted Nexus 5 running the internalblue/android_bluetooth_stack/nexus5_android6_0_1/bluetooth.default.so custom Android Bluetooth stack
* Computer running Linux operating system
* Wireshark

Internalblue is a framework which can patch the firmware from the operating system.
This attack is simulating an attacker using Internalblue, because the setup is easier, has a higher reliability, and it is cheaper than over the air.

== Perform Attack ==

* Connect Nexus 5 via USB to the computer
* Configure and install modified internalblue v0.1
** Edit '''internalblue/internalblue/core.py''' and set '''NEXUS5_MODE''' to which mode you want to perform
** Set '''NEXUS5_MODE = MASTER_MITM''' then the Nexus 5 is the master device or '''NEXUS5_MODE = SLAVE_MITM''' to set Nexus 5 to the slave device
** In terminal, switch into the '''internalblue''' directory, and run '''sudo python2 setup.py install'''
** Open a terminal and run internalblue (Internalblue is inserted in PATH Variable)
* In the internalblue menu start LMP monitoring with monitor lmp start
** A Wireshark window should pop up
* Pair target with Nexus 5
* When Nexus 5 is as the master configured ('''NEXUS5_MODE = MASTER_MITM''') then you have to start the connection from the Nexus 5 to the target device.
* When the Nexus 5 is as the slave configured (NEXUS5_MODE = SLAVE_MITM) then you have to start the connection from the victim to the Nexus 5.
* In Wireshark you can see that the devices have negotiated an encryption key with 1 byte of entropy.

== References ==

* https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli
* https://www.usenix.org/system/files/sec19-antonioli.pdf
* https://francozappa.github.io/publication/knob/
* https://github.com/francozappa/knob

[[Category:Documentation]]

File:BluetoothKNOB.PNG

2020-12-21T18:25:38Z

SVeseli: Key negotiation protocol of Bluetooth Source: https://www.usenix.org/system/files/sec19-antonioli.pdf

== Summary ==
Key negotiation protocol of Bluetooth

Source: https://www.usenix.org/system/files/sec19-antonioli.pdf

KNOB Attack

2020-12-21T18:25:00Z

SVeseli: Created page with "== Summary == The attack was found 2019 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen. Bluetooth specification has an encryption key negotiation protoco..."

== Summary ==

The attack was found 2019 by Daniele Antonioli, Nils Ole Tippenhauer and Kasper B. Rasmussen.
Bluetooth specification has an encryption key negotiation protocol to negotiate encryption keys. Attackers can manipulate this protocol to force encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. This enables brute forcing the encryption keys in real time.

== Key negotiation protocol ==

The goal of this protocol is to compute a session key starting from a long term shared secret
At the top is Encryption Key Generation Function that takes as input the longterm secret a bunch of nonces and Bluetooth address of Slave and is computing Kc a key with 16 Bytes of entropy this key is not used as session key it is processed by an entropy reduction function that is used to modify the entropy to N bytes and this N number is computed from an entropy negotiation phase that is performed by alice and bob. This session key is used to encrypt and decrypt the packets using E0 stream cipher in case using legacy security mode or AES-CCM if both devices supporting Bluetooth secure connections.

== Stages of Attack ==
KNOB Attack has 4 Main stages
* '''First stage:''' Alice and Bob are pairing using the strongest security mechanisms Secure Simple pairing. They are establishing a long term secret and the attacker is not there.
* '''Second Phase:''' Alice and Bob wants to establish a new encrypted session and Charlie is in Bluetooth range with the victim.
* '''Phase 3:''' Charlie is able to manipulate the entropy negotiation phase of Bluetooth and let the two victim negotiate an encryption key with one byte of entropy.
* '''Phase 4:''' Charlie is able to eavesdropping ciphertext and using the ciphertext to bruteforce the encryption key and the brute force is in real time because If you use an encryption key with 1 Byte of entropy then you have to brute force one key out of 256 possibilities.

== Requirements ==

* Clone Github https://github.com/francozappa/knob
* Rooted Nexus 5 running the internalblue/android_bluetooth_stack/nexus5_android6_0_1/bluetooth.default.so custom Android Bluetooth stack
* Computer running Linux operating system
* Wireshark

Internalblue is a framework which can patch the firmware from the operating system.
This attack is simulating an attacker using Internalblue, because the setup is easier, has a higher reliability, and it is cheaper than over the air.

== Perform Attack ==

* Connect Nexus 5 via USB to the computer
* Configure and install modified internalblue v0.1
** Edit '''internalblue/internalblue/core.py''' and set '''NEXUS5_MODE''' to which mode you want to perform
** Set '''NEXUS5_MODE = MASTER_MITM''' then the Nexus 5 is the master device or '''NEXUS5_MODE = SLAVE_MITM''' to set Nexus 5 to the slave device
** In terminal, switch into the '''internalblue''' directory, and run '''sudo python2 setup.py install'''
** Open a terminal and run internalblue (Internalblue is inserted in PATH Variable)
* In the internalblue menu start LMP monitoring with monitor lmp start
** A Wireshark window should pop up
* Pair target with Nexus 5
* When Nexus 5 is as the master configured ('''NEXUS5_MODE = MASTER_MITM''') then you have to start the connection from the Nexus 5 to the target device.
* When the Nexus 5 is as the slave configured (NEXUS5_MODE = SLAVE_MITM) then you have to start the connection from the victim to the Nexus 5.
* In Wireshark you can see that the devices have negotiated an encryption key with 1 byte of entropy.

== References ==

* https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli
* https://www.usenix.org/system/files/sec19-antonioli.pdf
* https://francozappa.github.io/publication/knob/
* https://github.com/francozappa/knob

[[Category:Documentation]]

Bluetooth Security Features

2020-12-21T16:26:55Z

SVeseli:

== 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.

== Basic Security Services ==

* '''Authentication:''' verifies the identity of communicating devices based on their Bluetooth address. User authentication is not provided by the Bluetooth Specification.
* '''Confidentiality:''' prevents eavesdropping of the transmitted data by an untrusted third person in the piconet. Confidentiality is created by data encryption.
* '''Authorization:''' controls the access of the resources. It assures that only authorized devices get permitted to access a service.
* '''Message Integrity:''' checks if the data was altered during the transmission.
* '''Pairing/Bonding:''' creates shared secret keys to use them in subsequent connections.

== Bluetooth Classic Security ==

[[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.

=== Security Mode 1 ===
This mode is considered as non-secure because it doesn’t use authentication nor encryption. Security Mode 1 is only supported by today's Bluetooth devices to communicate with old devices that are not capable of the other security modes.

=== 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 3 ===
This security mode is a link level security mode and security procedures get initiated before the physical link is fully established. Authentication and Encryption is fully supported by security mode 3 connections. Furthermore, service discovery can only be performed with an authenticated device which encrypts its traffic.

=== Security Mode 4 ===

[[File:Table_3-2.png|500px|thumb|right|BR/EDR/HS Security Mode 4 Levels Summar]]

Security mode 4 was introduced in Bluetooth version 2.1 and is a service level enforces security mode which security mechanisms get initiated after physical and logical link setup. Security mode takes advantage of the Secure Simple Pairing (SSP) Mechanism. SSP in Bluetooth version 4.1 uses the P-256 elliptic curve to generate the link key. Bluetooth 4.1 uses Hash Messages Authentication Codes Secure Hash Algorithm with 256-bit (HMAC-SHA-256) for integrity checks. For encryption the AES-Counter with CBC-MAC (AES-CCM) cypher is used. The P-256 elliptic curve, HMAC-SHA-256 and AES-CCM are security mechanisms which got approved by the Federal Information Processing Standard (FIPS). Security mode 4 gets differentiated into 5 different layers with different security levels.

* '''Layer 0:''' Layer 0 is only used by the Service Discovery Protocol (SDP). This layer doesn’t have any security features.
* '''Layer 1:''' Layer 1 doesn’t use any security.
* '''Layer 2:''' Layer 2 uses an unauthenticated link key.
* '''Layer 3:''' Layer 3 required an authenticated link key.
* '''Layer 4:''' Layer 4 uses secure connection in addition to the authenticated link key

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

=== 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. 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]]

==== Numeric Comparison ====
Numeric comparison was designed for devices, where both can display a six-digit number and allow a user input to accept and deny the connection. During the Paring both devices show a six-digit code on their displays. The user can accept the parring if the displayed numbers are the same. The connection is secure against MITM attacks and eavesdropping, if the paring was done correctly.

==== Passkey Entry ====
This model can be used where one device a has a display that sows a six-digit number and the other device has a digit input. Device a show a code that must be entered into the keyboard of the other device to establish the connection. This model is also secure against MITM attacks and eavesdropping.

==== Out of Band (OOB) ====
The out of band model uses an additional wireless or wired technology like Near Field Communication (NFC) to exchange the needed cryptographic keys. This model’s security is only as secure as the out of band technology. Even though, this association model is associated to be secure against eavesdropping and MITM attacks.

==== 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.

==== SSP Phases ====
Secure Simple Pairing consists of 5 phases:

* '''Public key exchange:''' Each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair. Pairing starts when the initiating device sends its public key to the receiving device. The responding device replies with its own public key, when both devices support Secure Connections then P-256 elliptic curve will be used, if at least one device does not support Secure Connections the P-192 elliptic curve will be used.
* '''Authentication stage 1:''' Phase 2 consist of three protocols: Numeric Comparison, Out-of-Band and Passkey Entry. The protocol is selected depending on the IO capabilities of the device.
* '''Authentication stage 2:''' Phase 3 confirms that the exchange between the two participants has been successfully completed. Both devices calculate a new confirmation value that takes into account the previously exchanged values and the new shared key. The initiator sends the new confirmations value to the responding device and is checked by it. If a failure occurs, the protocol should abort.
* '''Link key calculation:''' After both devices confirm the pairing, a link key is calculated using the shared key and the publicly exchanged data. The link key is used to maintain pairing.
* '''Link Manager Protocol Authentication and Encryption:''' Authentication and generation of the encryption key.

=== Legacy Pairing ===
With PIN / Legacy Pairing, the link keys are derived from a PIN entered by the user in one or both devices, depending on the configuration and device type. If the PIN is smaller than 16 bytes, the Bluetooth address of the initializing device is used for filling. After the key generation has been completed, the devices authenticate each other to ensure that both are using the same link key.This method only serves to mutually identify the devices and cannot prevent a man-in-the-middle attack. An attacker who knows the PIN can calculate the key from it.

=== Key Generation ===

==== Legacy Key Generation ====
The link key is a 128-bit random number, shared between two or multiple participants, and is the basis of all security transactions between these participants. The link key must be created and then distributed to the associated devices in order to be used for the authentication procedure. The initialization key is used temporarily during initialization and should be discarded afterwards. The initialization key is the result of the E22 algorithm the input parameters are a Bluetooth address, a PIN and a random number. The initialization key is used for the key exchange during the generation of a link key.

==== Secure Key Generation ====
Phase 4 (Link key calculation) of Secure Simple Pairing the link key will be established by using Elliptic Curve Diffie-Hellman public/private key pairs.

=== Confidentiality of the data ===
The Bluetooth standard defines three encryption modes for data traffic, but only two of them actuals provide confidentiality. The modes are as follows:
* '''Encryption Mode 1:''' The data traffic is unencrypted
* '''Encryption Mode 2:''' Individually addressed traffic is encrypted based on individual link keys but broadcast traffic is not.
* '''Encryption Mode 3:''' Individually addressed traffic and broadcast traffic is encrypted using an encryption key based on the master link key.
For encryption mode 2 and 3 is either the AES-CCM or E0 stream cipher used. Bluetooth Security Mode 4 encrypts all data traffic, expect service discovery messages

=== Trust Levels and Service Security Levels.===
In addition to the security modes, exist different levels of service security and trust.
The trust levels can be differentiated into trusted and untrusted. A trusted device has an established relation ship to the device and has full access to all the services. The untrusted device doesn’t have a relationship to the other device and has only a restricted access to the services.
The Service security level depend on the used Security mode. There are no Service security levels defined for Security mode 1 and 3. Security mode 2 has the following Service security levels:
* '''Authentication required'''
* '''Encryption required'''
* '''Authorization required'''

Security mode 2 defines the following five Service security levels:
* '''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 2:''' Requires encryption only; MITM protection is not necessary.
* '''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.

=== Authentication ===

==== 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.[[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 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.

== Bluetooth Low Energy security ==
Fundamentals of the BLE Standard can be found in 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.

*Low energy Security Mode 1 is associated with encryption
*Level 1 does neither use authentication nor encryption.
*Level 2 uses unauthenticated pairing with encryption.
*Level 3 uses authenticated pairing with encryption.
*Level 4 which uses authenticated low energy Secure Connections pairing with encryption.

*Low energy Security Mode 2 is associated with encryption data integrity
*Level 1 uses unauthenticated pairing with data signing.
*Level 2 uses authenticated pairing with data signing.

Security Mode 1 Level 4 is considered to create the strongest connections because it uses AES-CMAC and P-256 elliptic curve for pairing and encryption. Security Mode 1 Level 3 is less secure because it doesn’t use elliptical curve cryptography. Because Security Mode 2 does not provide encryption, it is strongly recommended to use Security Mode 1 Level 3 and 4.

== Bluetooth Classic and Bluetooth Low Energy security differences ==

[[File:Key_Differences_Between_Bluetooth_BR_EDR_and_Low_Energy.png|600px|Key Differences Between Bluetooth BR/EDR and Low Energy ]]

== References ==

* https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final

*[[Category:Basic]]

Bluetooth Security Features

2020-12-20T18:30:09Z

SVeseli: /* Bluetooth Classic Security */

== 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.

== Basic Security Services ==

* '''Authentication:''' verifies the identity of communicating devices based on their Bluetooth address. User authentication is not provided by the Bluetooth Specification.
* '''Confidentiality:''' prevents eavesdropping of the transmitted data by an untrusted third person in the piconet. Confidentiality is created by data encryption.
* '''Authorization:''' controls the access of the resources. It assures that only authorized devices get permitted to access a service.
* '''Message Integrity:''' checks if the data was altered during the transmission.
* '''Pairing/Bonding:''' creates shared secret keys to use them in subsequent connections.

== Bluetooth Classic Security ==

[[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.

=== Security Mode 1 ===
This mode is considered as non-secure because it doesn’t use authentication nor encryption. Security Mode 1 is only supported by today's Bluetooth devices to communicate with old devices that are not capable of the other security modes.

=== 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 3 ===
This security mode is a link level security mode and security procedures get initiated before the physical link is fully established. Authentication and Encryption is fully supported by security mode 3 connections. Furthermore, service discovery can only be performed with an authenticated device which encrypts its traffic.

=== Security Mode 4 ===

[[File:Table_3-2.png|500px|thumb|right|BR/EDR/HS Security Mode 4 Levels Summar]]

Security mode 4 was introduced in Bluetooth version 2.1 and is a service level enforces security mode which security mechanisms get initiated after physical and logical link setup. Security mode takes advantage of the Secure Simple Pairing (SSP) Mechanism. SSP in Bluetooth version 4.1 uses the P-256 elliptic curve to generate the link key. Bluetooth 4.1 uses Hash Messages Authentication Codes Secure Hash Algorithm with 256-bit (HMAC-SHA-256) for integrity checks. For encryption the AES-Counter with CBC-MAC (AES-CCM) cypher is used. The P-256 elliptic curve, HMAC-SHA-256 and AES-CCM are security mechanisms which got approved by the Federal Information Processing Standard (FIPS). Security mode 4 gets differentiated into 5 different layers with different security levels.

* '''Layer 0:''' Layer 0 is only used by the Service Discovery Protocol (SDP). This layer doesn’t have any security features.
* '''Layer 1:''' Layer 1 doesn’t use any security.
* '''Layer 2:''' Layer 2 uses an unauthenticated link key.
* '''Layer 3:''' Layer 3 required an authenticated link key.
* '''Layer 4:''' Layer 4 uses secure connection in addition to the authenticated link key

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

=== 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. 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]]

==== Numeric Comparison ====
Numeric comparison was designed for devices, where both can display a six-digit number and allow a user input to accept and deny the connection. During the Paring both devices show a six-digit code on their displays. The user can accept the parring if the displayed numbers are the same. The connection is secure against MITM attacks and eavesdropping, if the paring was done correctly.

==== Passkey Entry ====
This model can be used where one device a has a display that sows a six-digit number and the other device has a digit input. Device a show a code that must be entered into the keyboard of the other device to establish the connection. This model is also secure against MITM attacks and eavesdropping.

==== Out of Band (OOB) ====
The out of band model uses an additional wireless or wired technology like Near Field Communication (NFC) to exchange the needed cryptographic keys. This model’s security is only as secure as the out of band technology. Even though, this association model is associated to be secure against eavesdropping and MITM attacks.

==== 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.

==== SSP Phases ====
Secure Simple Pairing consists of 5 phases:

* '''Public key exchange:''' Each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair. Pairing starts when the initiating device sends its public key to the receiving device. The responding device replies with its own public key, when both devices support Secure Connections then P-256 elliptic curve will be used, if at least one device does not support Secure Connections the P-192 elliptic curve will be used.
* '''Authentication stage 1:''' Phase 2 consist of three protocols: Numeric Comparison, Out-of-Band and Passkey Entry. The protocol is selected depending on the IO capabilities of the device.
* '''Authentication stage 2:''' Phase 3 confirms that the exchange between the two participants has been successfully completed. Both devices calculate a new confirmation value that takes into account the previously exchanged values and the new shared key. The initiator sends the new confirmations value to the responding device and is checked by it. If a failure occurs, the protocol should abort.
* '''Link key calculation:''' After both devices confirm the pairing, a link key is calculated using the shared key and the publicly exchanged data. The link key is used to maintain pairing.
* '''Link Manager Protocol Authentication and Encryption:''' Authentication and generation of the encryption key.

=== Legacy Pairing ===
With PIN / Legacy Pairing, the link keys are derived from a PIN entered by the user in one or both devices, depending on the configuration and device type. If the PIN is smaller than 16 bytes, the Bluetooth address of the initializing device is used for filling. After the key generation has been completed, the devices authenticate each other to ensure that both are using the same link key.This method only serves to mutually identify the devices and cannot prevent a man-in-the-middle attack. An attacker who knows the PIN can calculate the key from it.

=== Key Generation ===

==== Legacy Key Generation ====
The link key is a 128-bit random number, shared between two or multiple participants, and is the basis of all security transactions between these participants. The link key must be created and then distributed to the associated devices in order to be used for the authentication procedure. The initialization key is used temporarily during initialization and should be discarded afterwards. The initialization key is the result of the E22 algorithm the input parameters are a Bluetooth address, a PIN and a random number. The initialization key is used for the key exchange during the generation of a link key.

==== Secure Key Generation ====
Phase 4 (Link key calculation) of Secure Simple Pairing the link key will be established by using Elliptic Curve Diffie-Hellman public/private key pairs.

=== Confidentiality of the data ===
The Bluetooth standard defines three encryption modes for data traffic, but only two of them actuals provide confidentiality. The modes are as follows:
* '''Encryption Mode 1:''' The data traffic is unencrypted
* '''Encryption Mode 2:''' Individually addressed traffic is encrypted based on individual link keys but broadcast traffic is not.
* '''Encryption Mode 3:''' Individually addressed traffic and broadcast traffic is encrypted using an encryption key based on the master link key.
For encryption mode 2 and 3 is either the AES-CCM or E0 stream cipher used. Bluetooth Security Mode 4 encrypts all data traffic, expect service discovery messages

=== Trust Levels and Service Security Levels.===
In addition to the security modes, exist different levels of service security and trust.
The trust levels can be differentiated into trusted and untrusted. A trusted device has an established relation ship to the device and has full access to all the services. The untrusted device doesn’t have a relationship to the other device and has only a restricted access to the services.
The Service security level depend on the used Security mode. There are no Service security levels defined for Security mode 1 and 3. Security mode 2 has the following Service security levels:
* '''Authentication required'''
* '''Encryption required'''
* '''Authorization required'''
Security mode 2 defines the following five Service security levels:
* '''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 2:''' Requires encryption only; MITM protection is not necessary.
* '''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.

=== 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.

==== 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.
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.

== Bluetooth Low Energy security ==
Fundamentals of the BLE Standard can be found in 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.

*Low energy Security Mode 1 is associated with encryption
*Level 1 does neither use authentication nor encryption.
*Level 2 uses unauthenticated pairing with encryption.
*Level 3 uses authenticated pairing with encryption.
*Level 4 which uses authenticated low energy Secure Connections pairing with encryption.

*Low energy Security Mode 2 is associated with encryption data integrity
*Level 1 uses unauthenticated pairing with data signing.
*Level 2 uses authenticated pairing with data signing.

Security Mode 1 Level 4 is considered to create the strongest connections because it uses AES-CMAC and P-256 elliptic curve for pairing and encryption. Security Mode 1 Level 3 is less secure because it doesn’t use elliptical curve cryptography. Because Security Mode 2 does not provide encryption, it is strongly recommended to use Security Mode 1 Level 3 and 4.

== Bluetooth Classic and Bluetooth Low Energy security differences ==

[[File:Key_Differences_Between_Bluetooth_BR_EDR_and_Low_Energy.png|600px|Key Differences Between Bluetooth BR/EDR and Low Energy ]]

== References ==

* https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final

*[[Category:Basic]]

File:SABluetooth.PNG

2020-12-20T18:18:46Z

SVeseli: Secure Authentication of Bluetooth Source: Bluetooth Core Specification https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=478726

== Summary ==
Secure Authentication of Bluetooth

Source: Bluetooth Core Specification https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=478726

File:LABluetooth.PNG

2020-12-20T18:17:19Z

SVeseli:

== Summary ==
Legacy Authentication of Bluetooth

Source:
Bluetooth Core Specification
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=478726

File:LABluetooth.PNG

2020-12-20T18:15:21Z

SVeseli: Legacy Authentication of Bluetooth

== Summary ==
Legacy Authentication of Bluetooth

Bluetooth Security Features

2020-12-19T17:30:18Z

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

== 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.

== Basic Security Services ==

* '''Authentication:''' verifies the identity of communicating devices based on their Bluetooth address. User authentication is not provided by the Bluetooth Specification.
* '''Confidentiality:''' prevents eavesdropping of the transmitted data by an untrusted third person in the piconet. Confidentiality is created by data encryption.
* '''Authorization:''' controls the access of the resources. It assures that only authorized devices get permitted to access a service.
* '''Message Integrity:''' checks if the data was altered during the transmission.
* '''Pairing/Bonding:''' creates shared secret keys to use them in subsequent connections.

== Bluetooth Classic Security ==

[[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.

=== Security Mode 1 ===
This mode is considered as non-secure because it doesn’t use authentication nor encryption. Security Mode 1 is only supported by today's Bluetooth devices to communicate with old devices that are not capable of the other security modes.

=== 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 3 ===
This security mode is a link level security mode and security procedures get initiated before the physical link is fully established. Authentication and Encryption is fully supported by security mode 3 connections. Furthermore, service discovery can only be performed with an authenticated device which encrypts its traffic.

=== Security Mode 4 ===

[[File:Table_3-2.png|500px|thumb|right|BR/EDR/HS Security Mode 4 Levels Summar]]

Security mode 4 was introduced in Bluetooth version 2.1 and is a service level enforces security mode which security mechanisms get initiated after physical and logical link setup. Security mode takes advantage of the Secure Simple Pairing (SSP) Mechanism. SSP in Bluetooth version 4.1 uses the P-256 elliptic curve to generate the link key. Bluetooth 4.1 uses Hash Messages Authentication Codes Secure Hash Algorithm with 256-bit (HMAC-SHA-256) for integrity checks. For encryption the AES-Counter with CBC-MAC (AES-CCM) cypher is used. The P-256 elliptic curve, HMAC-SHA-256 and AES-CCM are security mechanisms which got approved by the Federal Information Processing Standard (FIPS). Security mode 4 gets differentiated into 5 different layers with different security levels.

* '''Layer 0:''' Layer 0 is only used by the Service Discovery Protocol (SDP). This layer doesn’t have any security features.
* '''Layer 1:''' Layer 1 doesn’t use any security.
* '''Layer 2:''' Layer 2 uses an unauthenticated link key.
* '''Layer 3:''' Layer 3 required an authenticated link key.
* '''Layer 4:''' Layer 4 uses secure connection in addition to the authenticated link key

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

=== 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. 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]]

==== Numeric Comparison ====
Numeric comparison was designed for devices, where both can display a six-digit number and allow a user input to accept and deny the connection. During the Paring both devices show a six-digit code on their displays. The user can accept the parring if the displayed numbers are the same. The connection is secure against MITM attacks and eavesdropping, if the paring was done correctly.

==== Passkey Entry ====
This model can be used where one device a has a display that sows a six-digit number and the other device has a digit input. Device a show a code that must be entered into the keyboard of the other device to establish the connection. This model is also secure against MITM attacks and eavesdropping.

==== Out of Band (OOB) ====
The out of band model uses an additional wireless or wired technology like Near Field Communication (NFC) to exchange the needed cryptographic keys. This model’s security is only as secure as the out of band technology. Even though, this association model is associated to be secure against eavesdropping and MITM attacks.

==== 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.

==== SSP Phases ====
Secure Simple Pairing consists of 5 phases:

* '''Public key exchange:''' Each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair. Pairing starts when the initiating device sends its public key to the receiving device. The responding device replies with its own public key, when both devices support Secure Connections then P-256 elliptic curve will be used, if at least one device does not support Secure Connections the P-192 elliptic curve will be used.
* '''Authentication stage 1:''' Phase 2 consist of three protocols: Numeric Comparison, Out-of-Band and Passkey Entry. The protocol is selected depending on the IO capabilities of the device.
* '''Authentication stage 2:''' Phase 3 confirms that the exchange between the two participants has been successfully completed. Both devices calculate a new confirmation value that takes into account the previously exchanged values and the new shared key. The initiator sends the new confirmations value to the responding device and is checked by it. If a failure occurs, the protocol should abort.
* '''Link key calculation:''' After both devices confirm the pairing, a link key is calculated using the shared key and the publicly exchanged data. The link key is used to maintain pairing.
* '''Link Manager Protocol Authentication and Encryption:''' Authentication and generation of the encryption key.

=== Legacy Pairing ===
With PIN / Legacy Pairing, the link keys are derived from a PIN entered by the user in one or both devices, depending on the configuration and device type. If the PIN is smaller than 16 bytes, the Bluetooth address of the initializing device is used for filling. After the key generation has been completed, the devices authenticate each other to ensure that both are using the same link key.This method only serves to mutually identify the devices and cannot prevent a man-in-the-middle attack. An attacker who knows the PIN can calculate the key from it.

=== Key Generation ===

==== Legacy Key Generation ====
The link key is a 128-bit random number, shared between two or multiple participants, and is the basis of all security transactions between these participants. The link key must be created and then distributed to the associated devices in order to be used for the authentication procedure. The initialization key is used temporarily during initialization and should be discarded afterwards. The initialization key is the result of the E22 algorithm the input parameters are a Bluetooth address, a PIN and a random number. The initialization key is used for the key exchange during the generation of a link key.

==== Secure Key Generation ====
Phase 4 (Link key calculation) of Secure Simple Pairing the link key will be established by using Elliptic Curve Diffie-Hellman public/private key pairs.

=== Confidentiality of the data ===
The Bluetooth standard defines three encryption modes for data traffic, but only two of them actuals provide confidentiality. The modes are as follows:
* '''Encryption Mode 1:''' The data traffic is unencrypted
* '''Encryption Mode 2:''' Individually addressed traffic is encrypted based on individual link keys but broadcast traffic is not.
* '''Encryption Mode 3:''' Individually addressed traffic and broadcast traffic is encrypted using an encryption key based on the master link key.
For encryption mode 2 and 3 is either the AES-CCM or E0 stream cipher used. Bluetooth Security Mode 4 encrypts all data traffic, expect service discovery messages

=== Trust Levels and Service Security Levels.===
In addition to the security modes, exist different levels of service security and trust.
The trust levels can be differentiated into trusted and untrusted. A trusted device has an established relation ship to the device and has full access to all the services. The untrusted device doesn’t have a relationship to the other device and has only a restricted access to the services.
The Service security level depend on the used Security mode. There are no Service security levels defined for Security mode 1 and 3. Security mode 2 has the following Service security levels:
* '''Authentication required'''
* '''Encryption required'''
* '''Authorization required'''
Security mode 2 defines the following five Service security levels:
* '''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 2:''' Requires encryption only; MITM protection is not necessary.
* '''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 ==
Fundamentals of the BLE Standard can be found in 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.

*Low energy Security Mode 1 is associated with encryption
*Level 1 does neither use authentication nor encryption.
*Level 2 uses unauthenticated pairing with encryption.
*Level 3 uses authenticated pairing with encryption.
*Level 4 which uses authenticated low energy Secure Connections pairing with encryption.

*Low energy Security Mode 2 is associated with encryption data integrity
*Level 1 uses unauthenticated pairing with data signing.
*Level 2 uses authenticated pairing with data signing.

Security Mode 1 Level 4 is considered to create the strongest connections because it uses AES-CMAC and P-256 elliptic curve for pairing and encryption. Security Mode 1 Level 3 is less secure because it doesn’t use elliptical curve cryptography. Because Security Mode 2 does not provide encryption, it is strongly recommended to use Security Mode 1 Level 3 and 4.

== Bluetooth Classic and Bluetooth Low Energy security differences ==

[[File:Key_Differences_Between_Bluetooth_BR_EDR_and_Low_Energy.png|600px|Key Differences Between Bluetooth BR/EDR and Low Energy ]]

== References ==

* https://csrc.nist.gov/publications/detail/sp/800-121/rev-2/final

*[[Category:Basic]]