Transcript lec1119

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 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
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
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
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 users
Computation: where to place the computational
workload
Scalability: how to handle a large number of
devices/users
Need an inherent trust model
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?
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
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 deployed
The 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 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
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
Ad hoc network security
• Nodes freely roam
• Multi-hop communication towards remote nodes
• Shared wireless medium is error-prone
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
Server
Server
Server
Server
• Centralized & Hierarchical scheme
– Single server
– Multi-server infrastructure
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
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
Zero-Interaction Authentication
Mark Corner and Brian Noble
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
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
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
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
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
Key-Encrypting
Key
File Key
File Key
File
Laptop
Key-Encrypting
Key
File Key
Key-Encrypting
Key
File Key
Session
Encryption
Token
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
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
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!
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
Implementation
VFS
Keyiod
Keyd
Page Cache
Authentication
Client
Authentication
Server
ZIA
Key Cache
Underlying FS
Disk
Kernel Module
Laptop
Token
Linux 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 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
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
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 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
Time to secure/restore the file system
Time (s)
7
6
Reconnection
5
Disconnection
4
3
2
1
0
0
5
10
15
20
Page Cache Size (MB)
25
30
35
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%
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
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
Benefit of optimizations
Turn off prefetching, caching to see how useful they are for AB
Ext2fs
52.63 (0.30)
-
ZIA
57.54 (0.20)
9.32%
No prefetching
No caching
232.04 (3.40)
340.86%
Not many mkdir operations, but lots of locality
optimizations are critical
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.”
Evaluation: Per-Operation Overhead
Time (us) / Operation
2500
2000
1500
1000
500
0
Filldir
Mkdir
Readpage
Operation Type
Writepage
Lookup
Creating directories
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%
Directory creations eventually run at key acquisition speed
one key acquisition per K directories
K determined by size of fresh-key prefetch block
Reading directories
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%
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
Copying large trees
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%
Dominated by memcpy and encryption costs
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
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
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.
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
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