unam.яe

Recenlty I have been working with the Bluetooth protocol. I had knwoledge about bluetooth for a Master Degree I studied (Master en Telematica y redes de telecomunicaciones of University of Malaga). Obviously, It was a lot of years ago, so to remember this time, I got the Bluetooth Core Specification and; this time it will not be only teorical because I should to perform some tests like this:

These kind of tests are very complex since mostly of tools implement correctly the protocol, thus, if anyone wants to test this maybe should use commercial tools, or with the enough knowledge could modify the Bluetooth sources (e.g. Linux kernel) in order to modify how the Bluetooth works.

In this post, the second case will be aborded, why? because we like hard stuff and buy a commertial-tool would be so easy (and expensive). And; also, If we would like modify something probably we can not with the commercial tool .

Mention also that in this post it is only regarding to security of Bluetooth, not about other functionalities, like frequencies or other specific configurations.

Bluetooth Security Specification are different for BR/EDR and LE;

There is five security features:

• Pairing: It is the process for creating the secret keys
• Bonding: How to store the keys during the pairing in order to use in the new connections with trusted devices
• Authentication: It is the verification that two devices have the same keys
• Encryption: Confidentiality of the messages (prevent to MITM attacks)
• Integrity: Prevent message forgeries

Different security mechanisms:

• BR/EDR
  • Legacy
    • Device authentication: E1 algorithm (challenge-response) - SAFER+
    • Encryption: E0 algorithm - SAFER+
      
    • Pairing: E21 & E22 (SAFER+)
    • Integrity: CRC (None)
  • Secure Simple Pairing (SSP):
    • Device authentication: E1 algorithm (challenge-response) - SAFER+
    • Encryption: E0 algorithm - SAFER+
    • Pairing: HMAC-SHA256 and P-192 ECDH
    • Integrity: CRC (None)
  • Secure Connections
    • Device authentication: HMAC-SHA-256 and AES-CTR
      
    • Encryption: AES-CCM
      
    • Pairing: HMAC-SHA256 and P-256 ECDH
    • Integrity: MIC (when AES-CCM) after CRC
• LE
  • Legacy
    • Device authentication: AES-CCM*
      
    • Encryption: AES-CCM
      
    • Pairing: TK and STK with AES128
    • Integrity: MIC (when AES-CCM) after CRC
    • Adding signed data and privacy
      
  • Secure Connections
    • Device authentication: AES-CCM*
      
    • Encryption: AES-CCM
    • Pairing: AES-CMAC and P-256 ECDH
    • Integrity: MIC (when AES-CCM) after CRC
    • Adding signed data and privacy

* There is no dedicated device authentication algorithm in LE.

Security Mechanism	Legacy	Secure Simple Pairing	Secure Connections
Encryption	E0	E0	AES-CCM
Authentication	SAFER+	SAFER+	HMAC-SHA256
Key Generation	SAFER+	P-192 ECDH HMAC-SHA-256	P-256 ECDH HMAC-SHA-256

BR/EDR Security modes

Legacy security modes

It applies only when Controller or Host does not support SSP.

Three modes:

• Security mode 1: Non-secure
• Security mode 2: Service level enforced security
  
  • Authorization
    
  • Authentication
  • Encryption
    
• Security mode 3: Link level enforced security

Security mode 1 can be considewred as a special case of security mode 2 where no service has registered any security requirements.

Security mode 4: Service level enforced security

Depending of SSP supports

• Authenticated link key required (MITM protection)
  
• Unauthenticated link key required (numeric comparison)
  
• Security optional; limited to specific services
  

In security mode 4, Bluetooth has four levels:

• Level 4: MIMT protection, authenticated, FIPS-approved algorithms (when SSP), encryption required
  
• Level 3: MITM protection, authenticated, encryption required
• Level 2: Unauthenticated, encryption required
  
• Level 1: Unauthenticated, minimal user interaction
  
• Level 0: No security, no user interaction
  

Secure Simple Pairing

Four stages and five phases:

1. IO Capabilities exchange
   
2. Public key exchange (Phase 1)
   
3. Authentication stage I (Phase 2)
   
   1. MITM protection is not required -> Numeric comparison
   2. MITM protection is required -> Passkey entry (when KeyboardOnly is available)
      
4. Authentication stage II (Phase 3)
   
   1. DHKey check
      
5. Link key calculation (Phase 4)
   
6. LMP Authentication and Encryption (Phase 5)
   

LE Security modes

Three modes:

• LE Security mode 1
  • No security (unauthentication and no encryption)
  • Unauthenticated pairing and encryption
  • Authenticated pairing with encrypttion
  • Authenticated LE Secure Connections pairing with encryption using 128-bit encryption key size.
    
• LE Security mode 2
  
  • Unauthenticated pairing with data signing
    
  • Authenticated pairing with data signing
• LE Security mode 3:
  • No security (no authentication and no encryption)
  • Use of unauthenticated Broadcast_Code
  • Use of authenticated Broadcast_Code
    
• Mixed security modes
  

Secure Connections Only Mode

Also called, FIPS-Mode, that is when our Bluetooth connections are using FIPS-approved algorithms, that means that it is using:

• Pairing: P-256 ECDH (Host enforce it during pairing)
  
• Device authentication: HMAC-SHA-256 and AES-CTR / AES-CCM
  
• Encryption: AES-CCM
• Integrity: MIC
  

Depending of the technology we are using we can see differences between LE and BR/EDR.

• LE legacy pairing: Just works and Passkey Entry do not provice passive eavesdropping since LE legacy does not use ECDH.
  
• LE Secure connections is equivalent to BR/EDR.
• LE Secure connections only mode is LE security mode 1 and level 4.
  

In order to verify which algorithms are being using during pairing, we can identify the Link Key Notification event, where key type:

• 0x04: Unauthenticated Combination Key generated from P-192
• 0x05: Authenticated Combination Key generated from P-192
• 0x07: Unauthenticated Combination Key generated from P-256
  
• 0x08: Authenticated Combination Key generated from P-256

Association models

The association models are the proccess that the user/device see during the pairing, e.g. the PIN number confirmation in both devices.

• Just works: It is equal to unauthenticated, it is when no display is available. Uses numeric comparison with fixed 6-digits. No MITM protection and passive protection eavesdropping.
  
• Numeric Comparison: A 6-digit PIN is showed in each device display and just, accept with a "yes" or "no", It is just a confirmation in order to see that the device is the correct. MITM protection.
  
• Passkey Entry: Not protection against eavesdroping, a 6 numeric digits are passed out of band between devices.
• Out-of-Band: The association (authentication) is performed in other channel, e.g. NFC.
  

There is differences bettween BR/EDR and LE;

Just works and Passkey Entry do not provide passive eavesdropping protection, this is because who provides passive eavesdropping is the SSP (ECDH) and LE does not have SSP.

Encryption

The encryption is negotiated through the event "Encryption Change"; It can be observed in a packet sniffer like Wireshark:

Always is the Controller which propose the encryption algorithm that should be used to encrypt the messages.

I have observed that Android devices does not use Secure Connections Only Mode since for BR/EDR uses 0x01 which is the encryption algorithm E0 and not AES-CCM (for secure connections).

The encryption key size shall be between 7 bytes (56 bits) and 16 bytes (128 bits) and the smaller value of the initiating and responding devices maximum encryption key length parameters shall be used as encryption key size.

In past it was a security issue because some implementations allowed 1 byte encryption key size, so an attacker with a MITM attack could set the encryption key size to 1 byte and decrypt the traffic easily. This attack was known as KNOB attack

Privacy

This feature is only available in Bluetooth LE, and it provides the ability of make difficulties to an attacker track the device by changing the Bluetooth device address on a frequent basis over a period of time.

There is two modes:

• Device Privacy Mode: The own privacy of the device. (e.g. Only receive advertisement messages from peers that contains our identity address and privacy address)
• Network Privacy Mode: The device will only accept advertising packets from peers devices that contains private addresses.
  

Device Address

Devices are identified by an address, and the address can be of two types:

• Public device address
• Random device address

Random Device Address

Two types:

• Static address: 48-bit randomly generated address (at least one bit shall be 1 and 0)
  
• Private address
  • Non-resolvable: 48-bit randomly generated address (at least one bit shall be 1 and 0, and shall be not equal to public address)
  • Resolvable: Needs IRK and random 24-bit number

Summary

Depending of the Bluetooth technology you are using, you will have available multiple security mechanisms, being the more secure the Secure Connections Only Mode which uses FIPS-approved algorithms.

If you are using BR/EDR, you can choose between Legacy, Secure Simple Pairing and Secure Connections, and if you are using LE, Legacy and Secure Connections.

I have tried multiple configurations of Bluetooth in Linux and depending of the peer and the controller used It will choose a different security level.

The security levels defined in Linux:

The following table shown the configuration you need to have in btmgmt

Security (based on Linux categories)	Android	Windows
BT_SECURITY_MEDIUM	br/edr secure-conn	br/edr secure-conn
BT_SECURITY_HIGH	ssp secure-conn	ssp br/edr secure-conn
BT_SECURITY_FIPS	ssp br/edr le secure-conn	ssp br/edr le secure-conn

Next post will be an update of this post. Since I have modified the Linux kernel to dump information about the Bluetooth connections.