Security in Wireless and Mobile Networks

• Issues and possible security attacks in wireless and mobile systems

• Zero-interaction authentication

• Problems in 802.11 and Mobile IP

• Possible directions

On Attacks

Attacks can happen in each layer of the protocol stack over wireless and mobile networksExample: jamming in the physical layer

intruder sends jamming signals in the same physical channel to “jam” the users’ signals

Attacks happen in military context, and also civilian environment

Possible solution:Limit the transmission power for intruders and

usersTurn to spread spectrum technology

Example: link-layer snooping/eavesdroppingProblem: passively listen to the channel and

retrieve information without being detectedSolution: encrypt the data

On Attacks (II)

Example: Denial of Service Attack at the network layerIntruders break into the system and prevent the

system from serving normal network usersBy issuing a large amount of junk trafficBy silently dropping user traffic By sending false signals to invoke incorrect

reaction from the protocols and users

It is hard to enumerate a generic attack model (it can be really big!), has to look at the specific problem context

Security support

AuthenticationEnsure that users are the persons they claim to beThe most important service

Message PrivacyEnsure that information is not accessible by

unauthorized persons

Message IntegrityEnsure that information is not altered by unauthorized

users in a way that is not detectable by authorized users

Security Support (II)

Non-repudiation: ensure the message originators cannot deny that they sent the messages

Service availability: a system is operational and functional

Access Control: only qualified users can access services and resources

Privacy: users maintain the right to control what information about them is collected about them, how it is used and maintained, what for and by who uses it.

Authentication

Verify the true identity of a user

Issues in wireless:Mobility: how to manage mobile usersComputation: where to place the

computational workloadScalability: how to handle a large number of

devices/users

Need an inherent trust model

On trust models

typical models:Trusted third party basedPGP web of trustLocalized trust model

A relevant problem: root of trustProblem: who to trust in your security design?

Philosophy issuePoint of attack

Cases:Proxy server in a proxy-based architecture?Home agent, foreign agent in mobile IP?Ad hoc networks?

Current status in wireless security

Many protocols provide certain security featuresIEEE 802.11 MACMobile IPTLS wireless extensionsMobile ad-hoc routing

Still a wide open research area

802.11 WEP Protocol

Intends to enforce confidentiality, access control and data integrity

The use of stream cipher exposes to keystream reuse attack

CRC-32 is not sufficient for message integrity

Security Issues in Mobile IPv6

Mobile IPv6 uses binding updates that confirm the identity of a device as it moves to a new location.Once the binding update is authenticated,

communications go straight to the new location without passing through the HA

Uses IPsec to secure binding update messages. But IPsec will not work for these messages:IPSec depends on a public-key infrastructure that has

not yet been deployedThe key management component of IPsec requires

heavy processing by end devices

Mobile IPv6

Alternative solution: Purpose-built keys (PBK)Before each Mobile IPv6 session, Generate a temporary

public/private key pair; discard the key pair when the session is complete

No need to register the temporary keys with a third party

Keys change regularly, user anonymity is preservedCons:

PBKs cannot confirm the actual identity of the user, only the identity of the device.

Leave communications open to “man-in-the-middle” attacks

SPINS: Sensor Network Security

Message broadcast authenticationBased on a modified TESLA, but still use key chain

Sender setup: generate a secret chain of keysBroadcast authenticated messages: for

synchronized. Sender uses the key of the current interval to compute the message authentication code of packets in the interval. Then reveal the key after a delay after the end of the current interval

Bootstrapping a receiver Each receiver needs an authentic key of the key chain. Once the receiver has a key in the chain, the key chain can self authenticate.

Authenticating broadcast messages: receiver verifies the key revealed for previous interval

• Nodes freely roam

• Multi-hop communication towards remote nodes

• Shared wireless medium is error-prone

Ad hoc network security

Design Challenges

• Security breach– Vulnerable wireless links– Occasional break-ins may be inevitable over long time

• Service ubiquity in presence of mobility– Anywhere, anytime availability

• Network dynamics– Wireless channel errors– Node failures– Node join/leave

• Network scale

Conventional Approaches

• Centralized & Hierarchical scheme– Single server– Multi-server infrastructure

Server

ServerServer

Server

Problems of Conventional Approaches(Centralized & Hierarchical)

• Service performance comparison– Low success ratio: 80%– Large average delay

One Proposal

Ubiquitous and robust service provision in the presence of random mobility

Localized algorithms and protocols One-hop wireless communication

Why this model?

• No single point of compromise– Hackers must break into K nodes simultaneously to

compromise the system

• No single point of DoS attack & node failure• K offers tradeoff between intrusion tolerance and

service availability– K=1, single point of compromise, maximal availability

– K=N, single point of DoS attack, maximal intrusion tolerance

Network Protocol

• Broadcast service request• Compute partial certificates• Combine K partial certificates

1. Broadcast request3. Routing shuffling package

2. Unicast shuffling package4. Unicast partial secret share

Zero-Interaction Authentication

Mark Corner and Brian Noble

User-Centric AuthenticationHow does a device know who is typing? Authentication

typically something you know: passwordsomething you have: smartcards something you are: biometricsdone once and assumed to hold forever

This is acceptable for PCs: have relatively high physical securitywhen someone is in my office, I know it

Doesn’t work for mobile devices: relatively low physical securitySeattle-Tacoma airport found 330 laptops in three monthsphysical possession does not equal authentication

So what? If device is lost an imposter has the rights of the useroperating system protections can be bypassed

Solution: constant but invisible authenticationZIA: Zero-Interaction Authentication

protect data by constantly authenticating userkeep usable by having something answer for the user

Authentication token: provides this abilityworn by user for increased physical securityenough computational power for small cryptographic

taskscommunication via short-range wireless network

Restores parity between physical possession and authentication

Gives the user no reason to turn off protectionNo noticeable impact on performance or usability

Outline

Designhow are is the machine protected?how does the machine depend on the token?how do we improve performance?

ImplementationLinux prototype system with iPAQ handheld token

Evaluationwhat is the cost of protection? what overhead does ZIA add?how fast can the machine be secured and recovered?

Related work

Design guidelines

Protect file system data from physical possession attacksall data on disk must be encryptedensure user is present for each use of datauser retains long-term authority to decrypt

Can’t contact token on every instance of useadds latency to otherwise-short operations

Take advantage of caching already used in file systemson-disk information is kept encrypted for safetycached information is kept unencrypted for

performancetoken provides sole method for decrypting files

Moving data from disk to cache

Tokens cannot decrypt file contents directlysmall, battery-powered: limited computationconnected to laptop via wireless link

latency comparable to disk, bandwidth much less

Instead, store file encrypting key on disk, itself encryptedkey encrypting key never leaves token

File Key

File

Key-EncryptingKey

Laptop Token

Key-EncryptingKey

File Key

File Key

Key-EncryptingKey

File Key

SessionEncryption

Handle keys efficientlyKey acquisition time can be expensive

one network round trip + processing timethis requires millisecondscan’t add this to every disk operation!

Two mechanisms mitigate this problemoverlap key acquisition with disk reads (similar

magnitudes)cache decrypted keys so they are available during writes

Neither mechanism helps new file creationis an asynchronous write: nothing with which to overlapnothing you read before hand: caching cannot save youobservation: you don’t need any particular keyprefetch a stash of file keys to use on create

Assign keys per directory

What is the right granularity for file keys?small grain limits damage in the case of key exposure large grain provides opportunity for overlapping

We chose per-directory keysleverage access patterns

files in same directory tend to be used togetheracquisition time amortized across a directory

simplifies key managementkeys are stored in hidden file inside directory

Access rights are on a per-directory basis admits per-directory sharing, similar to AFS

Maintain performance, ensure securityOptimizations reduce laptop/token interactions

high locality, low creation rate: never decrypt a key!

Add periodic polling to refresh authenticationcryptographic challenge-response protocolneed not be frequent, since people are slow

When token does not answerassume user is absent, protect all data on the machinemust be fast enough to foil theft

When user comes back into rangerestore machine to “pre-departure” statemust appear as if machine never changed: no faulting

in!

Make protection fast and invisible

Key question: what to do with cached data on departure?

One alternative: flush data on departure, read in on arrivalflush step is fast: write dirty pages, bzero cacherecovery is too slow: read entire file cache from disk

Instead, we encrypt the cache on departure, decrypt on arrivalflushing is still fast: all in-memory operationsrecovery is much faster: no disk operations

necessary

Implementation

DiskLaptop

VFS

Page Cache

ZIA

Underlying FS

Key Cache

KeyiodAuthentication

Client

KeydAuthentication

Server

Token

Kernel ModuleLinux kernel using a stackable file system

Rijndael(AES) used for encryption

User-space daemon for authentication, key requests

Evaluation overview

Wanted to answer a few questionswhat overhead does ZIA impose? how long does it take to secure the cache?how long does it take to restore the cache

Prototype Systemclient system: IBM Thinkpad 570 PII 366MHztoken system: Compaq iPAQ 3650 Strongarm

200MHz connected by 802.11 network in 1Mb/s mode

Average cost of key acquisition: 13.9 ms (0.0015)

similar to the average seek time of drives

Evaluation: Andrew Benchmark

Testing typical system operation

Used a Modified Andrew Benchmark short version: copy and compile a source treewe use the Apache source code for a larger

benchmarksource code is 7.4 MB, compiled version is 9.7 MB

Compare ZIA against three file systemsExt2fs: underlying physical file systemCryptfs: FiST’s cryptographic file system (+Rijndael)

Careful to start with cold file cachereport mean, standard deviation for 20 trials

Andrew Benchmark results

File System Time, sec Overhead(vs. Ext2fs)

Ext2fs 52.63 (0.30) -

Cryptfs 57.52 (0.18) 9.28%

ZIA 57.54 (0.20) 9.32%

ZIA is statistically identical to simple encryption!

Time to secure/restore the file systemAll data must be encrypted when user leaves

All data must be decrypted when user returns

Benchmark:copy a (variably-sized) tree into ZIAdisable token, measure time to safetyenable token, measure time to recovery

Time to secure/restore the file system

0

1

2

3

4

5

6

7

0 5 10 15 20 25 30 35

Page Cache Size (MB)

Tim

e (s

)

Reconnection

Disconnection

Other Results

Andrew benchmark obligatory, but not necessarily goodoften measures the speed of your compiler

Micro-benchmarks (details in paper): directory creation

ZIA: 6%scanning directories

ZIA: 91%, due to key acquisitioncopying across file system

ZIA: 121% similar to Cryptfs: 118%

Related work

Many examples of cryptographic file systemsCFS (Matt Blaze), Cryptfs (Erez Zadok), EFS (Win2k)all suffer from the problem of “implied consent”once you log in, the file system can forevermore decryptWin2k can ask you to authenticate more frequently

inconvenient: anecdotally, it is often disabled

Can use a smart card to hold keys (Blaze) rather than in-kernelsmart card left in the machine: still has “implied

consent”

FiST (Zadok) has been very useful in fast prototypingwe recommend it despite a few sharp corners

ConclusionsUsually, your machine has the long-term authority to act

as you

Zero-Interaction Authenticationuser retains long-term authority to decrypt sensitive

datalaptop holds only transient authoritydefends against physically losing a laptop

Does not change user behavioronly user-visible action at (infrequent) login time

Does not noticeably impact performance<10% overhead above raw file system

Protects and restores machine quicklyEncrypts buffer cache within five seconds

Benefit of optimizations

Not many mkdir operations, but lots of locality

optimizations are critical

Ext2fs 52.63 (0.30) -

ZIA 57.54 (0.20) 9.32%

No prefetchingNo caching

232.04 (3.40) 340.86%

Turn off prefetching, caching to see how useful they are for AB

Possible Authentication MethodsSeveral popular methods:

Passwords: require typing, forgotten, written downSmart Cards swiped: swiped and never “unswiped” Smart Cards inserted: inserted and leftBiometrics: suffer from a high false negative rate,

bulky

Token provides authentication without interventionUser must only be near terminal to authenticateConforms to user’s expectation: “It should just

work.”

Evaluation: Per-Operation Overhead

0

500

1000

1500

2000

2500

Filldir Mkdir Readpage Writepage Lookup

Operation Type

Tim

e (u

s) /

Op

erat

ion

Creating directories

Directory creations eventually run at key acquisition speedone key acquisition per K directoriesK determined by size of fresh-key prefetch block

File System Time, sec Over Ext2fs

Ext2fs 9.67 (0.23) -

Base 9.66 (0.13) -0.15%

Cryptfs 9.88 (0.14) 2.17%

ZIA 10.25 (0.09) 5.9%

Reading directories

Directory reads with no other activity exposes full key acquisition costsreading keyfile reduces cost of reading directoryno overlapping of key acquisition and directory reads

File System Time, sec Over Ext2fs

Ext2fs 15.56 (1.25) -

Base+ 15.72 (1.16) 1.04%

Cryptfs 15.41 (2.87) -0.94%

ZIA 29.76 (2.43) 91.24%

Copying large trees

Dominated by memcpy and encryption costs

File System Time, sec Over Ext2fs

Ext2fs 19.68 (0.78) -

Base+ 31.05 (1.15) 57.78%

Cryptfs 42.81 (2.30) 117.57%

ZIA 43.56 (0.77) 121.38%

Key-encrypting keys carry permissionsFile encrypted by some key, E

E is also on disk, encrypted with another key, UU is known only to authentication tokenmay also choose to escrow U as a matter of policy

Sharing accommodated by additional encrypted versions of EUNIX protection model: user, group, and worldE encrypted by a user key U, group key G, maybe even

Weach user’s token holds their U, and all applicable Gsmembers of same group share copies of G

This model requires re-encrypting Es if users leave group

Foil tailgaters

How do I prevent my token from responding to your laptop?called the tailgater attack

Leverage the login process users already are familiar withsuppose mcorner logs into weir.eecsweir.eecs sends a challenge to mcorner’s tokenuser gives response to the token

could be simple (a tap) or complicated (one-time pass)

token then bound: only bound tokens respondunless I bind my token to your laptop, you lose

Provides assurance that this user means to use that laptopuser plays the role of trusted third party in binding

What if I lose my token?

Master Keys ( U, G, W ) should be escrowed by adminallows data to be recovered

Security risks are mitigated by infrequent PIN, also need laptop

Token is worn, so detecting loss is possiblebreak contact in clasp, hearbeats, body warmth, etc.

Trust and Threat Model

Focus on foiling physical possession or proximityinspection and removal of disk, probing physical

memoryexploitation of wireless link

eavesdropping, modification, insertion

Cannot protect against certain kinds of attacksremote exploitstrojan horsestrusted, but malicious, users

What about Wormhole attacks?

Wormhole attacks extend range of tokennullifies protections based on proximityusing powerful transmitters/receiversforwarding messages through alternate medium

Detection based on sensitive timing informationWormhole detection in Wireless Ad Hoc Networks

(Yih-Chun Hu, Adrian Perrig, David Johnson)

would not require token/device time synchronization