View page as slide show

Wireless Service Engineering

Security

Resources

  • Trappe, Washington: Introduction to Cryptography with Coding Theory
  • Bruce Schneier: Crypto-gram newsletter http://www.schneier.com/crypto-gram.html
  • Frank Stajano: Security
  • Secured Communications course

Security and wireless services

  • Mobile device features
    • Operating system support to security aspects
    • Differences on device capabilities
      • computational power, memory …
    • Battery
  • Wireless issues to handle
    • Disconnections
    • Denial of service attacks
    • Connections to third parties
    • transfer capabilities
  • General security risks are same in wired and wireless world
    • Wirelessness enhances many of the risks

Confidentially

  • RF signals float everywhere and can be read
  • Infrared is a bit harder to intrude
  • Short communication range is not a sound security method, although it reduces risk.
  • Protections
    • Selecting communication partner to verify that the data cause to proper target
      • Service discovery methods
      • Authentication to verify the communication partner
    • Encryption can be used to protect against eavesdropping
  • Don't forget the metadata
    • Some header's cannot be encrypted.

Cryptography

  • Many algorithms require extensive calculation power
    • Mobile devices don't have high processing power
      • Encryption can be slow
      • Heavy calculation uses lot of battery power
    • Careful selection of cryptographic algorithms is important
      • Cryptography on hardware instead of software?

Symmetric cryptography

  • Shared key
    • Random number generator required for generation
    • Keyexchange protocol and latency e.g. Diffie-hellman key exchange or shamir three pass protocol
  • Block ciphers
    • Rijndael (AES) takes 361 Pentium III cycles to encrypt or decrypt a 128 bit block (http://jya.com/bg/gladman.pdf)
      • For 5 MHz processor 5M/s * 128b/361 = 1.77285 Mb/s encryption speed
      • Enough speed for encrypting data for Bluetooth communications
  • Stream ciphers
    • Pseudorandom number generator
      • Good initialisation important (remember the problems on WEP)
      • Can start generating the keystream prior the data has arrived
    • Encryption is fast (just XORing the generated key stream and data)

Asymmetric cryptography

  • The key exchange
    • When the public key is exchanged?
    • Certificate
      • Is there a way to contact revocation list?
      • Which third parties are trusted?
      • Which certificates we should store on limited memory devices
  • Where to store the keys and certificates
    • Tamper resistance
  • Much slower than symmetric cryptography
    • RSA uses raising the text top be encrypted to a power of secret key (C = Memod n)
      • The calculated numbers are very big
  • Require special libraries to handle these big numbers
    • Use of small encryption key speeds up encryption (and signature verification) faster
    • big number calculation require also more memory for handling the process.
  • Elliptic curve cryptography
    • Shorter keys can be used to gain same level of security
      • Encryption done by adding points together in elliptic curve

Integrity

  • Transmission reliability
    • snow, water, trees, magnetic fields all may cause loss of bits
    • Third party attacks
  • Hashes
    • One way functions
    • Anyone can create and verify
  • MAC's (Message authentication code)
    • Similar to hashes, rely from key.
    • Only those who know the key can create and verify
  • Digital signatures
    • Done with Asymmetric Cryptography
    • Anyone can verify, secret key owner can create
  • Guy Fawkes
    • chain of hashes
    • Packet contains :
      • Message: the actual payload that is wanted to be transmitted: Mi
      • Commitment: hash of the key used for next message verification: h(ki+1)
      • Authenticator: the key used in previous message: ki−1
      • Hash value of random key and the message, commitment and authenticator: h(ki,Mi, h(ki+1), ki−1)
        • Mac can be used with key kiinstead of plain hash

Availabillity

  • Disconnections
    • Moving out of range
    • Denial of service attacks
      • Jamming radio frequency
      • Too many users / spam
        • Plutocratic access control (pay for use)
        • cryptographic puzzles
  • Attacks against battery
    • To prevent use of device, kill it's battery (Ross Anderson, Frank Stajano)
      • Cryptographic puzzles use lot of battery
      • Constant authentication verification and secure channel forming
    • Remedies
      • Resource reservation
        • limit the amount of conenction forming per source: “connection quota”
      • Limit the functionalities on low battery.
      • Send puzzles to other end for solving, thus slowing down the attack

Authentication

  • Identification
    • states the identity
  • Authentication
    • Verifies the identity
  • User authentication
    • Biometrics
      • Digital representation of physical feature of person compared to the one stored in database
      • Require Biometric reader
    • Passwords
      • Require UI
  • Replay attacks
    • the credentials (password, bio info, token id) are eavesdropped on transmission and used later to impersonate user.
    • defense: one time passwords
    • challenge-response
      • Credentials not transmitted just proof of knowledge
      • Can be used as an attack to burden mobile devices
  • Tokens
    • Token does the authentication for user.
    • Challenge-response
      • Secur ID
      • crypto challenges
    • Other device authentication methods
  • Device authentication
    • Shared secret
    • Unique ID
      • can be faked?
    • Asymmetric cryptography and certificates
  • Service authentication
  • Single Sign-on (SSO)
    • Liberty Alliance, .NET Passport, kerberos…
    • Require connection to third party
      • Not feasible in local peer-to-peer connections
      • e.g. Bluetooth conenction between two PDA's
    • Authentication tokens

Authorisation

  • Who can do what?
    • read/write/execute …
  • Bell- LaPadula Security policy model

1. No read up

2. No Write Down

  • No write up
  • Logging of events

Secure transient association

  • Who can control who (association)
    • Cordless telephone basestations stealing.
    • open wlan spots.
    • head sets
  • Transient:
    • When slave device is sold, how the new owner gains the control from old one?
  • Case thermometer
    • 10 thermometers in disinfectant fluid.
    • All able to send data to doctors pda
    • How the doctor pda knows automaticly which one the doctor picks up for measuring temperature.

Resurrecting Duckling security policy

  • Policy to determine who is allowed to command the given device
    • universal remote control,
    • Public projector
    • car keys
    • The duckling is imprinted to it's “mother”
      • imprinting remains during the “life” of device
      • new imprinting is done on “resurrection” (thus resurrecting duckling)
  • Provides anonymous authentication
    • No identity checked just the validity for control
    • no need to know the other party
    • no need for third party
  • Policy principles

1. Two state principle

  • Imprintable and Imprinted

2. Imprinting Principle

  • In imprinting the duckling moves from imprintable to imprinted state.
  • Imprinting happens when imprinting key is sent to device.
  • Transmission should be done over secure channel.

3. Death principle

  • On death the duckling moves from imprinted to imprintable state death
    • by order from mother (tamper resistance important)
    • by old age
    • by completion of specific transaction
    • death by reset button

4. Assasination Principle

  • Duckling should be made so that it's assasination is hard
  • Recovery on imprintkey
    • password forgot
    • remote control broken

1. escrowed seppuku (trusted thrid party orders the suicide)

  • manufacturer key
  • can we trust manufacturer

2. Backup key locally to other device)

3. Split secret (shamirs 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 and Security

  • Authentication and encryption is done for connection
  • Non-discoverable devices have to be contacted based on BDADDR
    • Brute-force attack to find non discoverable devices
  • All security features are optional! -
    • bad defaults
      • no authentication, authorisation or encryption on file sharing!?!
  • BT device can be used to track the user if BT is up and running
    • Bluetooth sniperrifle
    • Bluetooth wardriving
      • scanning devices to find ones with services open without authentication requirement.
      • In open wlan hotspot the intruder just gets access to network, on bluetooth they get access to data
  • Some other examples how Bluetooth security measures have been found inadequate (http://trifinite.org/trifinite_stuff.html)

Things to consider

  • Is the service public or private?
  • What is the service use policy?
  • Do I need authentication
    • Authenticate user or device?
    • Is real identity required or just right for use?
  • Authorisation
    • What can be done on service
    • Is there multiple levels on service use
  • Cryptography
    • Is it needed
    • What algorithms to use
    • What protocols work best
    • Hopw about key exchange
    • Is user device apable of handling all we give to it.
  • What level the security measures should be handled at (radio, transport or application layer?)
Last modified: 2013/07/01 14:42