WK09‐03‐Bluetooth Security Securing Fixed and Wireless Networks COMP4337/9337
School of Computer Science and Engineering, UNSW
Bluetooth Evolution
Copyright By PowCoder代写 加微信 powcoder
• Bluetooth Special Interest Group (SIG)
• Founded in Spring 1998 by Ericsson, Intel,
IBM, Nokia, Toshiba
• Now more than 2,000 organizations have joined the SIG
• Versions have been evolving, currently v5.2
oThere are too many details, we will focus on broader issues, refer to standards for details or interest in implementation
Bluetooth was founded in 1998 and It has a Bluetooth Special Interest Group (SIG) founded by consortium of companies including Ericsson, Intel, IBM etc.
Now more than 2000 industrial organizations have joined this special interest group to evolve the standard and develop Bluetooth related devices and applications.
Bluetooth Evolution
• Classic version
– 1 Mpbs, 79 channels
– always connected –no power savings –Applications: handsfree,audio
• Bluetooth Enhanced Data Rate,
– Dual Mode for backward compatibility
A very quick look at older Bluetooth developments to see how it evovled
Bluetooth Low Energy (BLE)
• Introduced in Bluetooth 4.0 (2010), v5.2 (Jan 2020)
• New modulation and link layer for low power devices
– Incompatible with classic Bluetooth devices – PHY and link layer different (no channel
hopping in classic Bluetooth)
– High-level protocols reused (L2CAP, ATT)
Channel hopping is used in Bluetooth Low Energy protocol introduced in 2010. Also called Bluetooth 4.0
Introduce new modulation and link layer for low power devices It is not compatible with classic Bluetooth devices
High level protocols have been reused.
Bluetooth Low Energy (BLE) 4.1 and higher (40 channels), Event based (low power), can support mesh network (earlier only, master slave), competes with Zigbee for IoT, Better security, Application: Medical, FHSS (frequency hopping spread spectrum), more on channel hopping later.
Latest version 5.2 has introduced some more new features – again you can find out these detais if interested. Some interesting power‐control features useful in localisaiton.
Advertisement Pkt
No of Channels for Adv
Limited to BLE
IPv6 stack
BLE is used in high end smart phones, IoT =, sports/fitness medical devices such as blood glucose monitor.
Search for v5.2 for latest additions – Jan 2020
Table is self-explanatory.
Applicatons:High end smart phones
Sports/fitness devices
Door locks
Upcoming medical devices (e.g., blood glucose monitor)
BLE Protocol Stack
Details not needed to be memorized, good to have broader appreciation. Our focus is security so we are not going to discuss these in any details.
However, some of the protocols are useful for building applications in a standard way so that say a data‐reader can read values (e.g. hear‐rate from a heart‐rate monitory use standard higher layer protocols.
No need to memorise these
ATT (Attribute protocol) – how to discover/read/write attributes on a peer device
GATT (Generic Attribute Profile) – how to discover and provide services based on ATT
L2CAP (Logical Link Control and Adaptation Protocol) – packet segmentation and reassemble
Identifying Application
• Universal Unique Identifier (UUID)
– 16-bit: defined by Application: example: 0x180D – heart
rate, 0x180F –battery service, 0x180A – Device info
– 128-bit: custom application
• BLE uses Profile
– Profile- overall app functionality
– Service – sub-functionality
– Characteristics performs its service functionality
Not much to do with security. You can skip this, more for data access/application. Simply if you come across UUID etc in protocol fields, you can relate to this.
Example Bluetooth Link
This lecture
https://developer.amazon.com/en-US/docs/alexa/alexa-gadgets-toolkit/bluetooth-le-pair-connect.html
You can see the whole process – I recommend you follow this link (not for exam). Shows you various phases. Non‐security details in not within our scope.
Configurations
• Bluetooth-enabled devices can automatically locate each other
• Topology is established on a temporary and random basis
• Up to eight Bluetooth devices may be networked together in a master-slave relationship to form a piconet – COMP3331
• New standards allow mesh configuration ‐
Bluetooth enabled devices that most of you have used, they can automatically locate each other.
When you use one Bluetooth enabled device it searches for other Bluetooth enabled device that are available to connect. These devices form a network in a very ad‐hoc way.
If you go to your local shop (such as JB HiFi) to test the quality of a Bluetooth enabled speaker, you can use your Bluetooth enabled mobile device such as IPhone to connect to a Bluetooth speaker and then stream your music to the Bluetooth speaker to play your favorite songs.
The topology is formed on a temporary and random basis. You can thus connect up to 8 Bluetooth devices in a master slave relationship.
This Bluetooth network is called a Piconet. National Institute of Standards and Technology (NIST) defines this network as Wireless Personal Area Network (WPAN).
Configurations (Cont.)
• One is master, which controls and sets up the network (piconet)
• Two or more piconet interconnected to form a scatter net
• Only one master for each piconet
• A device can’t be masters for two piconet
• The slave of one piconet can be the master of another piconet
In a Piconet, there can be only one master to control and setup the network. And two or more Piconet can interconnect to form a Scatter net.
There is only one master allowed for each Piconet. A device cannot be a master for two Piconet
However, a slave of one Piconet can be the master of another Piconet.
With newer standards, terminologies get a bit mixed up.
They also use Initiator/Responder or Client/Server etc at various laeyrs of protocol rather than the master/slave used for connection establishsment.
Security Issues
• Authenticity: Are you the device you claim you are?
– Impersonation
• Confidentiality: Is the exchanged data only available to the intended devices?
– Packet sniffing
• Authorisation: Are only the intended devices accessing the specified data and control?
– Prerequisite: authenticity and confidentiality
In Bluetooth communications these 3 are the most essential security issues that must be considered.
Authenticity means that: Any Bluetooth device must be able to authenticate themselves to prove/verify who they claim they are. An Impersonation attack is launched pretending to be someone else. If you cannot verify who you are. The protocol should be able to detect this to identify someone posing as another device.
For confidentiality, the data has to be only available to the intended device instead of some other device. Packet sniffing can be launched against this security feature to access data that is being transferred between two devices in an unauthorized manner.
And the third property is Authorization that means only the intended device has access to specified data and control. This combines the above two features. Prove your authenticity first and then exchange data in a secure manner.
How security can be initiated
• Slave sends security request
• Master sends pairing request followed by a
response from slave
• Client accesses characteristics which requires security
• Previously connected devices re-connect to each other.
These are pretty self explanatory
The last point will come back again, this method is called bonding.
You can skip the explanation below as they are expanded further.
When two devices, which initially do not have security, wish to do something that requires security, the devices must first pair. This process is triggered by a Central device (e.g. a smartphone) that is attempting to access a data value (a “characteristic”) on a Peripheral device that requires authenticated access. Pairing involves authenticating the identity of two devices, encrypting the link using a short‐ term key (STK) and then distributing long‐term keys (LTK) used for encryption. The LTK is saved for faster reconnection in the future, that is termed Bonding
Pairing/Key distribution
(Fundamentally, these exchanges are not very different from what you have already learnt in many other protocols, details vary)
The role each device plays is defined in the Security Manager (SM) portion of the BLE stack. They are the Initiator (the central), and the Responder (the peripheral).
two devices let each other know what they are capable of doing. eg. Feature exchange – where devices i/o capability, whether MiTM protection is needed, OOB flag is set…
‐The values they are reading are Attribution Protocol (ATT) values. These live at layer 4 with L2CAP, and are typically not ever encrypted. ‐determine which pairing method is going to be used in phase two,
‐ ATT values will be different for a Bluetooth Smart vs a Bluetooth Smart Ready device. (again smart and smart‐ready terms are for certain versio of standards, Smart‐ready typicially phones/laptops, smart – other less capable devices)
‐to generate a Short Term Key (STK).
‐devices agreeing on a Temporary Key (TK) mixed with some random numbers which gives them the STK.
‐ STK itself is never transmitted between devices, commonly known as LE legacy pairing.
‐ if the Secure Connection Only Mode is being used, a Long Term Key (LTK) is generated at this phase (instead of an STK), and this is known as LE Secure Connections.
Phase Three
‐the key from phase two is used to distribute the rest of the keys needed for communications. If an LTK wasn’t generated in phase two, one is generated in phase three.
Data like the Connection Signature Resolving Key (CSRK) for data signing, you already know digital signature
‐ the Identity Resolving Key (IRK) for private MAC address generation and lookup are generated in this phase. – we talk about this a bit later.
Image src: https://medium.com/rtone-iot-security/deep-dive-into-bluetooth-le-security-d2301d640bfc
Pairing Message Format
Not to be memorized (or examinable).
Not to be memorized (or examinable).
Just appreciate that the protocol exchange for request response has these fields as discussed in previous foil, phase‐1.
The second step of the pairing procedure is the Authentication step which is performed based on the information exchanged in the previous step in the Pairing Request and Pairing Response messages.
In this step the Temporary Key is generated. There are 3 ways of generating the TK in BLE (described below): Just Works, OOB, and Passkey Entry. The priority of these methods is the following: if both devices have set the OOB flag than the OOB method is used regardless of the other flags in the Pairing Request and Response. If the OOB flag is not set on at least one of the devices then the MITM flag is checked. If both devices have not set the MITM flag then the just works method is chosen (IO capabilities are ignored), else the pairing algorithm is chosen based on the IO Capabilities.
The following table describes the relation between the TK and the pairing methods.
• Just Works: As above but defaults to 0, users press some buttons (e.g. on Headphone or speaker without display)
• Passkey Entry: 6 digits displayed on one device and the same entered on other
• Out of Band (OOB) : Use NFC on Phone and headphone, or Camera on Phone and display on Watch (Apple pairing)
• Numeric Comparison: both devices display the same six digit value on their respective screens or LCD displays, and you make sure they match and hit or click the appropriate button on each device.
Just Works. Obviously, not all devices have a display, such as headphones or a speaker. Therefore, the Just Works method is probably the most popular one. Technically, it is the same as Numeric Comparison, but the six‐digit value is set to all zeros. While Numeric Comparison requires some on‐ the‐fly math if you are performing a MITM attack, there is no MITM protection with Just Works.
Passkey Entry. With Passkey Entry, a six‐digit value is displayed on one device, and this is entered into the other device.
Out Of Band (OOB). A communication method outside of the Bluetooth communication channel is not used, but the information is still secured. The is a good example of this workflow. During the pairing method, a swirling display of dots is displayed on the watch face, and you point the pairing iPhone’s camera at the watch face while (according to Apple) bits of information are transmitted via this process. Another example is using Near Field Communication (NFC) between NFC‐ capable headphones and a pairing phone.
For key exchange in Bluetooth, there are currently above pairing. However, the Bluetooth core specifications states that none of these paring methods provide protection against a passive eavesdropper.
Numeric Comparison. Basically, both devices display the same six digit value on their respective screens or LCD displays, and you make sure they match and hit or click the appropriate button on each device. This is not to prevent a man‐inthe‐middle (MITM) attack, mainly because it doesn’t, but rather to identify the devices to each other.
“None of these key pairing methods provide protection against a passive eavesdropper” – Bluetooth Core Spec
Security in BLE
• Legacy Connections (all version )
– Enter/agree on temporary key at each device – From this TK, generate Short Term Key
– STK encrypts connection between two devices.
• Secure Connections (v4.2 and higher)
– Uses shared key generation method (e.g ECDH) – This key LTK then encrypts the session
Self explanatory. Also read explanation on different phases.
Later options of using session key using Elliptic curve DH is more secure. Again details of certificate/key generation etc is similar to what you have seen earlier.
Security Modes/Levels
• Security Mode 1 enforces security by means of encryption and contains four levels:
– SecurityLevel1:NoSecurity(Noauthenticationandno encryption)
– SecurityLevel2:Unauthenticatedpairingwithencryption
– SecurityLevel3:AuthenticatedpairingwithAES-CCMencryption
– SecurityLevel4:AuthenticatedLESecureConnectionspairing with encryption. Level 4 uses Elliptic Curve Diffie- -256 (ECDH) and AES-CCM encryption.
• Security Mode 2: enforces security by means of data signing and contains two levels:
– Security Level 1: Unauthenticated pairing with data signing – SecurityLevel2:Authenticatedpairingwithdatasigning
JUST SKIM THOUGH THIS. There is too much details, no need to memorise any of this.
Basically, devices start with lowest level and then can ramp up based on application needs and capabilities. Connection operates at a specific Security mode. Within each mode are several security levels. The required security mode/level of a connection may change from time to time, there are procedures to increase that level
The new security level of the connection is based on the method of pairing performed and this is selected based on the I/O capabilities of each device. The security level of any subsequent reconnections is based on the level achieved during the initial pairing. Standards has a nice table of device capabilities and how the intersection gives you appropriate choice.
The role each device plays is defined in the Security Manager (SM) portion of the BLE stack. They are: Initiator: Always corresponds to the Link Layer Master and therefore the GAP central.
Responder: Always corresponds to the Link Layer Slave and therefore the GAP peripheral.
Each connection starts its lifetime in Security mode 1, Level 1, and can later be upgraded to any security level by means of an authentication procedure discussed below.
Security Manager Protocol (SMP)
SMP offers
– Device Authentication
– Device Authorisation
– DataIntegrity
– Data Confidentiality
– DataPrivacy
A number of keys help with these tasks Temporary Key (TK)
– Determined by the type of pairing use Connection Signature Resolving Key (CSRK)
– Usedforsendingsigneddatawithoutencryption – Authenticatesamessage
Self explanatory.
Important to understand purpose of each key (again this is not very different from what you have learnt earlier)
What services and keys are used for the communication between two devices are established during the SMP Pairing procedure which is performed by the SMP and set up by the Application according to its needs.
The third phase of the pairing procedure is the distribution of the keys. The keys are distributed using specific SMP packets. The keys are encrypted with the STK and once stored in a security database must have the same properties (authentication, MITM protection) as the STK. The keys which can be distributed are: (LTK, EDIV and Rand), IRK, CSRK.
The distributed EDIV and Rand values are transmitted in clear text by the master device to the slave device during encrypted session setup.
The BD_ADDR of devices is also distributed in this phase.
• Short-Term Key (STK)
– Usedtoencryptaconnectionwhen2devicesarepairingforthe
first time
– STK = AES128 (TK, Srand || Mrand), where Srand , Mrand random numbers generated by the Master and the Slave
• Long-Term Key (LTK)
– CanbededucedbytheSlaveusingandEncryptedDiversifier-EDIV (unique to each master) and a Rand value sent from the Slave to the Master when the devices are bonding
– slave can store the LTK (or the EDIV) in database
• Identity Resolving Key (IRK) for Privacy (discussed later)
o hash = AES128(IRK, prand), where random_address = [hash || prand || 0b10]
encrypted diversifier
slave can store the LTK (or the EDIV) in database
If EDIV stored, then it can derive LTK as needed without further exchange with master. Makes things quicker.
Link Layer
Header (2 bytes) Payload (0- 37 bytes)
• Only PDU encrypted which creates security vulnerability
– packet sniff to break the confidentiality in PDU.
Preamble (1 byte)
Access Address (4 bytes)
(2 to 39 bytes)
PDU type (1 byte)
Payload length (1 byte)
From networking perspective, we need to under the link layer protocol to be able to do security analysis. Again, no need to memorise any of this.
Preamble: 8‐bit sequence (01010101), it is for receiving radio to synchronize the transmission.
Access Address: it is a 32‐bit address for recipient to pickup the intended Bluetooth packets.
PDU = Protocol Data Unit
CRC = Cyclic Redundancy Check
In each Bluetooth packet, you have 4 parts. 1 byte Preamble, 4 bytes Access address, (2‐39 bytes) PDU and 3 bytes CRC.
CRC provides the integrity check whether the packet has experienced any bit corruption.
In actual PDU, there is a 2 byte header and up to 37 bytes of payload.
Note that only the PDU gets encrypted using the Session key (STK or LTK) that we discussed earlier, rest three (Preamble, Access address and CRC) are sent in plaintext. Packet sniffing can be used to break the confidentiality.
• Bluetooth advertisement requires broadcast of MAC address. (See Alexa example)
– Tracking of MAC address can identify user’s move
• Privacy concerns
COVID-19 -tracking apps uses it with user consent.
• How to preserve privacy ?
– Change MAC frequently
– How do you trust who you are talking to if frequent change.
A quick detour considering that we are in the middle of COVID. How privacy plays a role (both positive and negative)
Singapore COVID app
https://www.businessinsider.com.au/singapore‐coronavirus‐app‐tracking‐testing‐no‐ shutdown‐how‐it‐works‐2020‐3?r=US&IR=T
Resolvable Private Address
• To avoid tracking, use Resolvable Private Address
• During key exchange, negotiate, Identity Resolution Key
– IRK helps creation and resolution of random M
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com