1 / 49

Security in Wireless and Mobile Networks

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.

karim
Download Presentation

Security in Wireless and Mobile Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related