Security in Wireless and Mobile Networks

1. 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

2. On Attacks • Attacks can happen in each layer of the protocol stack over wireless and mobile networks • Example: 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 users • Turn to spread spectrum technology • Example: link-layer snooping/eavesdropping • Problem: passively listen to the channel and retrieve information without being detected • Solution: encrypt the data

3. On Attacks (II) • Example: Denial of Service Attack at the network layer • Intruders break into the system and prevent the system from serving normal network users • By issuing a large amount of junk traffic • By 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

4. Security support • Authentication • Ensure that users are the persons they claim to be • The most important service • Message Privacy • Ensure that information is not accessible by unauthorized persons • Message Integrity • Ensure that information is not altered by unauthorized users in a way that is not detectable by authorized users

5. 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.

6. Authentication • Verify the true identity of a user • Issues in wireless: • Mobility: how to manage mobile users • Computation: where to place the computational workload • Scalability: how to handle a large number of devices/users • Need an inherent trust model

7. On trust models • typical models: • Trusted third party based • PGP web of trust • Localized trust model • A relevant problem: root of trust • Problem: who to trust in your security design? • Philosophy issue • Point of attack • Cases: • Proxy server in a proxy-based architecture? • Home agent, foreign agent in mobile IP? • Ad hoc networks?

8. Current status in wireless security • Many protocols provide certain security features • IEEE 802.11 MAC • Mobile IP • TLS wireless extensions • Mobile ad-hoc routing • Still a wide open research area

9. 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

10. 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 deployed • The key management component of IPsec requires heavy processing by end devices

11. 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 preserved • Cons: • PBKs cannot confirm the actual identity of the user, only the identity of the device. • Leave communications open to “man-in-the-middle” attacks

12. SPINS: Sensor Network Security • Message broadcast authentication • Based on a modified TESLA, but still use key chain • Sender setup: generate a secret chain of keys • Broadcast 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

13. Ad hoc network security • Nodes freely roam • Multi-hop communication towards remote nodes • Shared wireless medium is error-prone

14. 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

15. Conventional Approaches Server Server Server Server • Centralized & Hierarchical scheme • Single server • Multi-server infrastructure

16. Problems of Conventional Approaches(Centralized & Hierarchical) • Service performance comparison • Low success ratio: 80% • Large average delay

17. One Proposal • Ubiquitous and robust service provision in the presence of random mobility • Localized algorithms and protocols • One-hop wireless communication

18. 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

19. Network Protocol 2. Unicast shuffling package 4. Unicast partial secret share 1. Broadcast request 3. Routing shuffling package • Broadcast service request • Compute partial certificates • Combine K partial certificates

20. Zero-Interaction Authentication Mark Corner and Brian Noble

21. User-Centric Authentication • How does a device know who is typing? Authentication • typically something you know: password • something you have: smartcards • something you are: biometrics • done once and assumed to hold forever • This is acceptable for PCs: have relatively high physical security • when someone is in my office, I know it • Doesn’t work for mobile devices: relatively low physical security • Seattle-Tacoma airport found 330 laptops in three months • physical possession does not equal authentication • So what? If device is lost an imposter has the rights of the user • operating system protections can be bypassed

22. Solution: constant but invisible authentication • ZIA: Zero-Interaction Authentication • protect data by constantly authenticating user • keep usable by having something answer for the user • Authentication token: provides this ability • worn by user for increased physical security • enough computational power for small cryptographic tasks • communication via short-range wireless network • Restores parity between physical possession and authentication • Gives the user no reason to turn off protection • No noticeable impact on performance or usability

23. Outline • Design • how are is the machine protected? • how does the machine depend on the token? • how do we improve performance? • Implementation • Linux prototype system with iPAQ handheld token • Evaluation • what is the cost of protection? • what overhead does ZIA add? • how fast can the machine be secured and recovered? • Related work

24. Design guidelines • Protect file system data from physical possession attacks • all data on disk must be encrypted • ensure user is present for each use of data • user retains long-term authority to decrypt • Can’t contact token on every instance of use • adds latency to otherwise-short operations • Take advantage of caching already used in file systems • on-disk information is kept encrypted for safety • cached information is kept unencrypted for performance • token provides sole method for decrypting files

25. Moving data from disk to cache • Tokens cannot decrypt file contents directly • small, battery-powered: limited computation • connected to laptop via wireless link • latency comparable to disk, bandwidth much less • Instead, store file encrypting key on disk, itself encrypted • key encrypting key never leaves token

26. Handle keys efficiently • Key acquisition time can be expensive • one network round trip + processing time • this requires milliseconds • can’t add this to every disk operation! • Two mechanisms mitigate this problem • overlap key acquisition with disk reads (similar magnitudes) • cache decrypted keys so they are available during writes • Neither mechanism helps new file creation • is an asynchronous write: nothing with which to overlap • nothing you read before hand: caching cannot save you • observation: you don’t need any particular key • prefetch a stash of file keys to use on create

27. 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 keys • leverage access patterns • files in same directory tend to be used together • acquisition time amortized across a directory • simplifies key management • keys are stored in hidden file inside directory • Access rights are on a per-directory basis • admits per-directory sharing, similar to AFS

28. Maintain performance, ensure security • Optimizations reduce laptop/token interactions • high locality, low creation rate: never decrypt a key! • Add periodic polling to refresh authentication • cryptographic challenge-response protocol • need not be frequent, since people are slow • When token does not answer • assume user is absent, protect all data on the machine • must be fast enough to foil theft • When user comes back into range • restore machine to “pre-departure” state • must appear as if machine never changed: no faulting in!

29. Make protection fast and invisible • Key question: what to do with cached data on departure? • One alternative: flush data on departure, read in on arrival • flush step is fast: write dirty pages, bzero cache • recovery is too slow: read entire file cache from disk • Instead, we encrypt the cache on departure, decrypt on arrival • flushing is still fast: all in-memory operations • recovery is much faster: no disk operations necessary

30. Implementation Linux kernel using a stackable file system Rijndael(AES) used for encryption User-space daemon for authentication, key requests

31. Evaluation overview • Wanted to answer a few questions • what overhead does ZIA impose? • how long does it take to secure the cache? • how long does it take to restore the cache • Prototype System • client system: IBM Thinkpad 570 PII 366MHz • token 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

32. Evaluation: Andrew Benchmark • Testing typical system operation • Used a Modified Andrew Benchmark • short version: copy and compile a source tree • we use the Apache source code for a larger benchmark • source code is 7.4 MB, compiled version is 9.7 MB • Compare ZIA against three file systems • Ext2fs: underlying physical file system • Cryptfs: FiST’s cryptographic file system (+Rijndael) • Careful to start with cold file cache • report mean, standard deviation for 20 trials

33. Andrew Benchmark results ZIA is statistically identical to simple encryption!

34. Time to secure/restore the file system • All data must be encrypted when user leaves • All data must be decrypted when user returns • Benchmark: • copy a (variably-sized) tree into ZIA • disable token, measure time to safety • enable token, measure time to recovery

35. Time to secure/restore the file system

36. Other Results • Andrew benchmark obligatory, but not necessarily good • often measures the speed of your compiler • Micro-benchmarks (details in paper): • directory creation • ZIA: 6% • scanning directories • ZIA: 91%, due to key acquisition • copying across file system • ZIA: 121% similar to Cryptfs: 118%

37. Related work • Many examples of cryptographic file systems • CFS (Matt Blaze), Cryptfs (Erez Zadok), EFS (Win2k) • all suffer from the problem of “implied consent” • once you log in, the file system can forevermore decrypt • Win2k 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-kernel • smart card left in the machine: still has “implied consent” • FiST (Zadok) has been very useful in fast prototyping • we recommend it despite a few sharp corners

38. Conclusions • Usually, your machine has the long-term authority to act as you • Zero-Interaction Authentication • user retains long-term authority to decrypt sensitive data • laptop holds only transient authority • defends against physically losing a laptop • Does not change user behavior • only user-visible action at (infrequent) login time • Does not noticeably impact performance • <10% overhead above raw file system • Protects and restores machine quickly • Encrypts buffer cache within five seconds

39. Benefit of optimizations • Not many mkdir operations, but lots of locality • optimizations are critical Turn off prefetching, caching to see how useful they are for AB

40. Possible Authentication Methods • Several popular methods: • Passwords: require typing, forgotten, written down • Smart Cards swiped: swiped and never “unswiped” • Smart Cards inserted: inserted and left • Biometrics: suffer from a high false negative rate, bulky • Token provides authentication without intervention • User must only be near terminal to authenticate • Conforms to user’s expectation: “It should just work.”

41. Evaluation: Per-Operation Overhead

42. Creating directories • Directory creations eventually run at key acquisition speed • one key acquisition per K directories • K determined by size of fresh-key prefetch block

43. Reading directories • Directory reads with no other activity • exposes full key acquisition costs • reading keyfile reduces cost of reading directory • no overlapping of key acquisition and directory reads

44. Copying large trees • Dominated by memcpy and encryption costs

45. Key-encrypting keys carry permissions • File encrypted by some key, E • E is also on disk, encrypted with another key, U • U is known only to authentication token • may also choose to escrow U as a matter of policy • Sharing accommodated by additional encrypted versions of E • UNIX protection model: user, group, and world • E encrypted by a user key U, group key G, maybe even W • each user’s token holds their U, and all applicable Gs • members of same group share copies of G • This model requires re-encrypting Es if users leave group

46. 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 with • suppose mcorner logs into weir.eecs • weir.eecs sends a challenge to mcorner’s token • user gives response to the token • could be simple (a tap) or complicated (one-time pass) • token then bound: only bound tokens respond • unless I bind my token to your laptop, you lose • Provides assurance that this user means to use that laptop • user plays the role of trusted third party in binding

47. What if I lose my token? • Master Keys ( U, G, W ) should be escrowed by admin • allows data to be recovered • Security risks are mitigated by infrequent PIN, also need laptop • Token is worn, so detecting loss is possible • break contact in clasp, hearbeats, body warmth, etc.

48. Trust and Threat Model • Focus on foiling physical possession or proximity • inspection and removal of disk, probing physical memory • exploitation of wireless link • eavesdropping, modification, insertion • Cannot protect against certain kinds of attacks • remote exploits • trojan horses • trusted, but malicious, users

49. What about Wormhole attacks? • Wormhole attacks extend range of token • nullifies protections based on proximity • using powerful transmitters/receivers • forwarding messages through alternate medium • Detection based on sensitive timing information • Wormhole detection in Wireless Ad Hoc Networks • (Yih-Chun Hu, Adrian Perrig, David Johnson) • would not require token/device time synchronization