Bluetooth Security

1
Bluetooth Security

• How security is implemented for services running
  on Bluetooth devices, and future security issues
  for this technology
• By Scott Anson

2
Agenda

• Security terminology.
• Overview of the architecture pertaining to
  security.
• Description of the various modes of security
  available.
• Closer look at link-level security
• Issues with Bluetooth security.

3
Security Threats

• Disclosure Threat leaking of information from a
  system to an unwanted party. Confidentiality
  violation.
• Integrity Threat unauthorized changes of
  information during transmission.
• Denial of Service Threat resources blocked by
  malicious attacker. Availablity violation.

4
Terms

• Authentication process of determining the
  identity of another user.
• Authorization process of deciding if device A
  has the access rights to device B. Notion of
  trusted
• Symmetric Key Security generally, A trusts B if
  B can prove that it has the same shared key that
  A does.

5
Wireless Versus TraditionalSecurity

• There is no centralized, trusted third party for
  a wireless network
• User Authentication becomes harder
• Authentication must go across a network without
  being cracked
• Device uniqueness low battery denial of service
  attacks!

6
Bluetooth Overview

• Ad Hoc Networks of Multiple Types of Devices
  PDAs, Laptops, Mobile Phones
• Piconets Small Clusters (Max Size 8) of Devices
  Forming an Ad Hoc Network. Masters Determine the
  Frequency. Piconet Example Transfer of Files
  Between Participants at a Meeting.
• Scatternets Larger Networks Formed of up to 10
  Piconets.

7
Device Architectural Overview
8
Mapping of Bluetooth Overview to IEEE 7-layer
model (thanks to IEEE)
9
Link Manager the DataLink layer

• Link Managers involvement with security depends
  on Bluetooth security mode only the strictest
  setting requires that data link implement
  security.
• Security for pairing, authentication and
  encryption is implemented by both software and
  hardware at this layer.
• We will later look at the specifics.

10
Transport/ Session Layer

• RFCOMM enforces the security policy for dial-up
  networking and other services relying on a serial
  port. Supports emulation of multiple serial
  ports between two devices. Session Layer.
• L2CAPP Logical Link and Adaption Protocol.
  Manages the creation and termination of virtual
  connections called channels with other devices.
  Negotiates and dictates security parameters for
  channel establishment. Network/Transport Layer

11
Security Manager

• A service and a device data store
• Answers access requests by protocol
  implementations (e.g. L2CAPP) or higher layers
  R2COMM, applications.
• Enforces authentication and encryption if they
  are needed before connecting to application
• Initiates setting up trusted pairings and gets
  PIN codes from users, saves addresses of other
  devices.

12
Multiple Security Modes

• Mode 1 No security other than against casual
  eavesdroppers
• Mode 2 Service Level Security established
  after creating the channel, above datalink layer.
• Mode 3 Datalink Level Security security
  initiated before establishing channel, by the
  Link Manager, as well as by the Service Level.
• Security Mode determines what stage of connection
  does security

13
Communication from 60,000

• 1.) Inquiry A device in a new environment will
  automatically initiate an inquiry to discover
  what access points are within its range. This
  will result in the following events
• i.) All nearby access points respond with their
  addresses.
• ii.) The device picks one out the responding
  devices.
• 2.) Paging a baseband procedure invoked by a
  device which results in synchronization of the
  device with the access point, in terms of its
  clock offset and phase in the frequency hop,
  among other required initializations. (see spec
  for detailsmaster/slave issues here).

14
60,000 foot view continued

• 3.) Link establishment The LMP will now
  establish a link with the access point. If
  Security Mode 3, then Pairing (6) begins at this
  layer.
• 4.) Service Discovery The LMP will use the
  SDP(Service Discovery Protocol) to discover what
  services are available.
• 5.) L2CAP channel created With information
  obtained from SDP, a L2CAP channel is created.
  This may be directly used by the application or
  by another protocol (e.g. RFCOMM)
• 6.) Pairing begins here if in Security Mode 2.

15
Pairing, the 60000 view of security

• Security Manager of access point is consulted
• --checks security mode and service security
  policy, if security is required, the access point
  transmits a security request for pairing
• --pairing is only successful if the user knows
  the pin of the access point
• --the PIN is not transmitted over the wireless
  channel but another key generated from it is
  used, so that the PIN is not compromised.
• --Encryption will be invoked if secure mode is
  used.

16
Device Security Levels

• Trust level of the device determines which
  services that device has access to.
• Trusted Device The device has been previously
  authenticated, a link key is stored and the
  device is marked as "trusted" in the Device
  Database.
• Untrusted Device The device has been previously
  authenticated, a link key is stored but the
  device is not marked as "trusted" in the Device
  Database
• Unknown Device No security information is
  available for this device, e.g. untrusted

17
Mode 1 No Security

• Only security at this level is by the nature of
  the connection data-hopping and short-distance
• Bluetooth devices transmit over the unlicensed
  2.45GHz radio band, the same band used by
  microwave ovens and cordless phones.(FHSS)
• All Bluetooth devices employ data-hopping,
  which entails skipping around the radio band up
  to 1600 times per second, at 1MHz intervals (79
  different frequencies)
• Most connections are less than 10 meters, so
  there is a limit as to eavesdropping
  possibilities

18
Mode 2 Service Level Security

• Service Access depends on device
• Trusted devices have unrestricted access to all
  services, fixed relationship to other devices
• Untrusted devices generally have no permanent
  relationship and services that it has access to
  are limited.
• Unfortunately, all services on a device are given
  the same security policy, other than application
  layer add-ons.

19
Mode 2 Service Security Levels

• Services can have one of 3 security levels
• Level 3 Requires Authentication and
  Authorization. PIN number must be entered.
• Level 2 Authentication only, fixed PIN ok.
• Level 1 Open to all devices, the default level.
  Security for legacy applications, for example.

20
Mode 3 Link level security

• Security is implemented by symmetric keys in a
  challenge-response system.
• Security implementations in Bluetooth units are
  all the same, and are publicly available
• http//www.bluetooth.com/pdf/Bluetooth_11_Specific
  ations_Book.pdf
• Critical ingredientsPIN, BD_ADDR, RAND(), Link
  and Encryption Keys

21
Security Entities

• PIN up to 128 bit number, can be fixed (entered
  in only one device), or can be entered in both
  devices. If fixed, much lower security.
• BD_ADDR Bluetooth device address, unique 48 bit
  sequence. (IEEE). Devices must know the address
  of devices it wants to communicate with.
  Addresses are publicly available via Bluetooth
  inquiries.

22
Link-level entities continued

• Private Authentication Keys, or Link Keys
  128-bit random numbers used for authentication
  purposes. Paired devices share a link key.
• Private Encryption Key varying length key (8-128
  bits), regenerated for each transmission from
  link key
• RAND frequently changing 128-bit random number
  generated by the device (in software). Common
  input for key generation.
• All Bluetooth devices have this random number
  generator.

23
Initialization

• Needed before two secure devices can communicate.
  5 parts
• Generation of initialization key
• Authentication
• Generation of link key
• Link key exchange
• Generation of encryption key in both devices.
• Conclusion link is either built or aborted

Pairing
24
Generation of initialization key

• Initialization key generation only occurs when
  two devices have not yet communicated before.
• Highest security demands PIN be entered by both
  users. Two devices with fixed pins cannot talk
  securely (mode 3).
• This key used to secure the process of generating
  a shared link key between the devices.

25
Initialization key creation cont.

• F( PIN, sizeof( PIN), RAND, BD_ADDR) produces 128
  bit initialization key via shifting and xors
  (Linear feedback shift registers, whose output is
  combined by a state machine)
• Device A and B now share the initialization key,
  which they use as their temporary link key while
  deciding on what kind of link key they will use
  for data transmission.
• This key is discarded once they agree on a link
  key.

26
Authentication

• Does not always need to be mutual, specified by
  app
• If it is mutual, then both act as verifiers, one
  after the other
• Device A verifier
• Device B claimant
• Basically determines if both have same shared key
  (ACO generated at this time as well for
  encryption)

27
Authentication continued

• A issues challenge c to B, generated by its RAND
• A and B both run the RAND thru same function
• E1(c, BD_ADDR of B, current link key)
• B sends its response to A, who checks to see that
  they match. If failure, start exponential
  waiting with a limit set on number of possible
  attempts.
• On success, the BD_ADDR of other device is stored
  in the Device Database by the Service Manager.

28
Generation of Link Key

• Unit key does not change, it was made when device
  was installed.
• Application decides which device will provide its
  unit key as a link key (favors the device with
  less memory).
• Shared initialization key is used to protect the
  transaction it is XORed with the new link key.

29
Link Key Exchange

• After the unit key is stored on the other device,
  the initialization key is discarded.
• Higher security combination key is used rather
  than the unit key, and this is formed by F( unit
  key, RAND, BD_ADDR) on both A and B.
• Master-slave communications use Master link key.
  A slave gets a master link key when first
  connected to Master and then changes it when
  prompted by Master

30
Encryption

• Encryption requires an authenticated link with an
  established link key
• Devices must agree on an encryption key to
  communicate.
• Packet payloads are encrypted (not the packet
  headers or access codes).
• Devices negotiate on what size Encryption key
  they need, typically around 64 bits. Range is
  1-16 bytes.

31
Encryption Modes

• Encryption Mode depends on the shared key
• If unit or combination key, then
  point-to-multipoint traffic is not encrypted.
  Individual traffic may or may not be encrypted
  (app specific)
• If a master key is used, there are three possible
  modes
• Mode 1, nothing is encrypted.
• Mode 2, broadcast traffic is not encrypted, but
  the individually addressed traffic is encrypted
  with the master key.
• Mode 3, all traffic is encrypted with the master
  key.

32
Encryption Implementation

• Encryption of payloads is effected with a stream
  cipher called E0 that is resynchronized for every
  payload
• A Software implementation is linked from
  references section.
• E0 consists of three parts
• The initializer (generates the payload key)
• The key stream bits generator
• The encryption or decryption circuit

33
Simplified Encryption Circuitry
Linear-Feedback Shift Register
XOR
Encrypted Word
Data Word
Linear-Feedback Shift Register
XOR
Decrypted Word
Encrypted Word
34
Encryption in detail.

• Key E3( COF, RAND, LinkKey). Variable size
  design due to internationalization issues
• COF Ciphering Offset Number, determined by type
  of link key
• Combination/Unit Link Key equal to ACU from
  initialization This was obtained during the
  initialization key generation process and saved
  in the Security Manager.
• Master Link Key Concatenation of the master
  BD_ADDR and the slave BD_ADDR

35
Wrap up Bluetooth Keys

• Encryption Key is not a Link Key but is derived
  from either the Unit, Combination, or Master Key.
  Can be shorter than the 128-bit link keys.
• 4 Link Keys
• Ki initialization key, protects initialization
  parameters. Formed from combo of RAND, PIN, and
  BD_ADDR. This is discarded after channel
  establishment, at which point the others are
  used.
• Kab combination key, derived from paired devices
  when additional security needed. Memory? Device
  that has the most has to store the combo key.

36
Link Key wrap-up continued

• Ku unit key, generated in installation of a
  device, stored in nonvolatile memory. Unit and
  combo keys generated with the same function,
  different inputs.
• Unit Key cannot change! If it does, then the
  entire piconet is compromised and must be
  re-initialized
• Km master key, used when the master device wants
  to transmit to multiple devices at once.
  Overrides current link keys for one session.
• Master Key is the most typical link key, but for
  scatternet communication (multiple masters), the
  unit key or combination key is always used.

37
General Problems

• Device versus User authentication. Bluetooth
  authenticates devices, not users. This is not
  always appropriate. Depends on app-specific
  fixes.
• Device versus Service specific security. You
  must implement the same security policy (mode) on
  all services on the device.
• Dependence on addresses, shared keys. Fixed PINs
  also pose a problem.

38
General problems continued

• Legacy applications do not use the Service
  Manager (need adapter kits).
• Cannot enforce unidirectional traffic
• Once connection established, assumed permanently
  secure. (unless called by Master to renegotiate,
  which rarely occurs in most implementations.)

39
Specific Problems

• PIN number is the only truly secret key, and this
  is up to the user. 0000 is not good! Solution
  force longer pins, combo of entered pin and
  stored pin
• Battery draining denial of service attack!
• Spoofing due to shared keys A talks to B, over.
  Then A talks to C. Now B can masquerade as A to
  C by faking As device address, and can then lay
  off and eavesdrop.
• Privacy issues? Devices unique address is
  associated with a user.

40
Conclusions

• Inadequate for serious security money transfers.
  Better WLAN
• Additional security must be added at the higher
  layers. This keeps Bluetooth an economical
  solution to non-security-critical interactions.
• Most hackers dont want to sit nearby. Bluetooth
  works great for PANs.
• Security By Obscursion! Not elegant.

41
References

• THE SPEC http//www.bluetooth.com/pdf/Bluetooth_1
  1_Specifications_Book.pdf
• Träskbäck M, Security in Bluetooth An overview
  of Bluetooth security, 2000-11-2http//www.cs.hut
  .fi/Opinnot/Tik86.174/Bluetooth_Security.pdf
• Vainio J., Bluetooth Security,
  2000-05-25http//www.niksula.cs.hut.fi/jiitv/blu
  esec.html
• Knowledge Base on Bluetooth
• http//www.palowireless.com/infotooth/knowbase.asp
  

42
References continued

• Cathal McDaid
• http//www.palowireless.com/bluearticles/cc1_secur
  ity1.asp
• http//www.palowireless.com/bluearticles/cc2_secur
  ity2.asp
• http//www.palowireless.com/bluearticles/cc2_secur
  ity3.asp
• Saarinen M-J, A Software Implementation of the
  BlueTooth Encryption Algorithm E0
  http//www.cc.jyu.fi/mjos/e0.c
• www.xilinx.com tutorials on both Bluetooth
  Overview and Close up on Bluetooth Security
• www.bluetooth.com
• Other bluetooth links http//www.practicallynetwo
  rked.com/tools/wireless_articles.htmBluetooth
• http//www.geocities.com has links to
  bluetooth tutorials