View page as slide show


Security & wireless services

  • Mobile device features
    • OS support to security aspects
    • Differences on device capability – CPU, RAM, …
    • Battery uptime
  • Wireless issues to handle
    • Disconnections
    • Denial of Service (DoS) attacks
    • Connection to 3rd parties
    • Transfer capabilities
  • General security risks are similar in wired & wireless worlds
    • Wirelessness enhances many of the risks


  • RF signal floats everywhere & can be read
  • Infrared is more challenging to intrude
  • Short communication range
    • Is not sound security measure
    • However is reduces risks
  • Protections
    • Selecting communication partner to verify the data cause to proper target
      • Service discovery methods
      • Authentication to verify the communication partner
    • Encryption can be used to protect eavesdropping
  • Don't forget the metadata
    • Some headers can not be encrypted


  • Many algorithms require extensive calculation power
    • Mobile devices lack high processing power
      • Encryption can be slow
      • Heavy calculation —> battery exhaustion
    • Careful selection of cryptographic algorithms is important
      • Cryptography on hardware instead of software?

Symmetric cryptography

  • Shared key
    • Random number generator required
    • Key exchange protocol & latency e.g. Diffie-Hellman, Shamir three pass
  • Block ciphers
  • Stream ciphers
    • Pseudo-Random Number Generator (PRNG)
      • Good initialisation import - recall WEP issues
      • Can start generating the key stream prior to data arrival
    • Encryption is fast → just XOR of generated key stream & data

Asymmetric cryptography

  • Key exchange
    • When is the public key is exchanged?
  • Certificate
    • Means to contact revocation list?
    • Which TTP are trusted? trusted for what?
    • Which certificates should we store in devices memory
  • Where to store keys & certificates
    • Tamper resistance

Asymmetric cryptography ...

  • Much slower than symmetric cryptography
    • RSA uses raising the text (to be encrypted) to a power of secret key
    • Computed/calculated number is very big
  • Requires special libraries to handle these big numbers
    • Use of small encryption key speeds up encryption (& signature verification)
    • Big number calculation requires more memory for handling the process
  • Elliptic curve cryptography (ECC)
    • Shorter keys can be used to gain same level of security
    • Encryption done by adding points together in an elliptic curve


  • Transmission reliability
    • Snow, water, trees, magnetic fields → bits lost in transmission
    • Third party attacks – packet injections, …
  • Hashes / Digests
    • One way functions
    • Anyone can create & verify
  • Message Authentication Code (MAC)
    • Similar to hashes but rely on key
    • Only those knowing the key can create & verify

Integrity ...

  • Digital signatures
    • Done with asymmetric cryptography
    • Anyone can verify, secret key owner can create
    • Chain of hashes
  • Packet contains
    • Message - actual payload to be transmitted - Mi
    • Commitment - hash of the key used for next message verification
      • h(ki+1)
    • Authenticator - key used in previous message
      • (ki -1)
    • Hash value of random key & message, commitment & authenticator
      • h(ki, Mi, h(ki+1), ki-1)
    • MAC can be used with key ki instead of plain hash


  • Disconnections
    • Moving out of range
  • Denial of Service (DoS) attacks
    • Jamming radio frequency
  • Too many users/ spam
    • Plutocratic access control (pay for use)
    • Cryptographic puzzles

Availability ...

  • Attacks against battery
    • Aim to prevent use of device - exhaust its battery
    • Cryptographic puzzles use a lot of battery
    • Constant authentication, verification & secure channel formation
  • Remedies
    • Resource reservation
      • Limit amount of connection forming per source - “connection quota”
    • Limit functionalities on low battery
    • Send puzzles to other end to solve - slow down the attack


  • Identification
    • State the identity
  • Authentication
    • Verify the identity
  • User authentication
    • Biometric
      • Digital representation of persons physical feature X
      • X is compared to prior stored similar attribute in the database
      • Biometric reader needed for attribute collection
    • Passwords
      • UI needed

Authentication ...

  • Replay attacks
    • Credentials eavesdropped on transmission & used later to impersonate user
  • Defences
    • One time passwords
    • Challenge-response
      • Credentials not transmitted just proof of knowlegde
      • Could be used as an attack to burden mobile devices
  • Tokens
    • The token does the authentication for the user
  • Challenge-response
    • SecureID
    • crypto challenges

Authentication ...

  • Other authentication methods
  • Device authentication
  • Shared secret
  • Unique ID
    • can be faked?
  • Asymmetric crypto & certificates
  • Service authentication
  • Single Sign-On (SSO)
    • Liberty Alliance, Live ID, OpenID, Kerberos, …
    • Needs connection to third party
      • Not feasible in local P2P connections e.g. Bluetooth between 2 PDAs
  • Authentication tokens


  • Who can do what?
    • Read/Write/Execute, …
  • Bell-LaPadula security policy model
    • No read up
    • No write down
  • No write up
  • Logging of events

Secure transient association

  • Who controls who (association)
    • Cordless phone BS stealing
    • Open WLAN spots
    • Head sets
  • Transient
    • When slave device sold - how new owner gain control from old one?
  • Case thermometer
    • 10 thermometers in disinfect fluid
    • All able to send data to doctors PDA
    • How does the doctor PDA know automatically which thermometer was picked up

Resurrecting Duckling Security Policy

  • Policy to determine who is allowed to command the given device
    • Universal remote control
    • Public projector
    • Car keys
  • Duckling is imprinted to its “mother”
    • Imprint lasts duration of device's “life”
    • New imprint done on “resurrection” –> resurrection duckling
  • Provides anonymous authentication
    • No identity checked just validity for control
    • No need to know other party
    • No need for 3rd party

Resurrecting Duckling Security Policy ...

  • Policy principles
  1. Two state principles
    • Imprintable & imprinted
  2. Imprinting principle
    • Duckling transitions from Imprintable –> Imprinted state
    • Imprinting happens when imprinting key is sent to device
    • Transmission should be done over secure channel
  3. Death principle
    • Upon death duckling transitions from Imprinted –> Imprintable state
      • Ordered by mother duck (tamper resistance)
      • At old age
      • At completion of specific transaction
      • Death by reset button

Resurrecting Duckling Security Policy ...

  • Policy principles …
  • Assasination principle
    • Duckling should made such that it's assasination is difficult
  • Recovery of imprint key
    • Password forgotten
    • Remote control broken / lost

Resurrecting Duckling Security Policy ...

  • Escrowed Seppuku (TTP orders the suicide)
    • Manufacturer key
    • Can we trust manufacturer?
  • Backup key locally to other device
  • Split secret (Shamir secret sharing scheme)
    • Add-ons
    • Transfer of control
      • On mothers permission
      • Car radio allows mobile phone to transmit call to radio's loudspeakers

Case: Bluetooth & security

  • Authentication & encryption done for connection
  • Non-discoverable devices have to be contacted based on BDADDR
    • Brute-force attack find non-discoverable devices
  • All security features are options
    • Bad defaults
    • No authentication, authorisation or encryption on file sharing ?

Case: Bluetooth & security ...

  • BT devices can be used to track host if BT is up & running
    • BT snipper-riffle
    • BT war-driving
      • Scan devices to find ones with services open without authentication requirements
      • In open WLAN hotspots intruder just gets access to network.
      • In Bluetooth they get access to data
  • More examples on Bluetooth security inadequacy


  • Is the service public or private?
  • Whats the service use policy?
  • Do I need authentication?
    • User / device authentication
    • Is real identity needed or just right for use?
  • Authorisation
    • What can be done on service
    • Is there multiple levels of service use?

Considerations ...

  • Cryptography
  • Is it needed?
  • What algorithms should I use?
  • What protocols work best?
  • How about key exchange
  • Can the device handle all we give to it?
  • What level of security measures should be handled at
    • Radio, transport or application layer?


  1. Trappe, Washington: Introduction to cryptography with coding theory
  2. Bruce Schneier: Crypto-gram newsletter
  3. Frank Stajano : Security
  4. Secured communications course


  • Context-Awareness
Last modified: 2013/07/01 14:42