operating system support for mobile devices

139
1 Security and Cooperation, Wrap up 4/23/2009 Richard Yang

Upload: peterbuck

Post on 15-Jan-2015

1.283 views

Category:

Documents


4 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Operating System Support for Mobile Devices

1

Security and Cooperation, Wrap up

4/23/2009

Richard Yang

Page 2: Operating System Support for Mobile Devices

2

Admin.

Projects due May 12

We will continue to hold regular office hours until May 12 or you can send email to make appointments

Page 3: Operating System Support for Mobile Devices

Recap: Adaptive Mobile Applications

Client: informs service capability/status makes best use of available resource/data

Service: adapts to client capability/status audio/image/video/web content adaption

3

client service

request

result

Page 4: Operating System Support for Mobile Devices

4

Example: Adapting Web Content

One major goal of the World Wide Web Consortium (W3C) has been device-independent content by decoupling layout from rendering

What are some arguments that we need to adapt web content for mobile devices?

Page 5: Operating System Support for Mobile Devices

Web Content Adaption Approaches HTML auto formatting

Variant selection (e.g., according to HTTP accept or x-wap-profile of UAProf)

Content negotiation RFC 2295: Transparent Content Negotiation in

HTTP

Transcoding E.g., pdf to html, html to XHTML-MP/WML

5

Page 6: Operating System Support for Mobile Devices

6

Example: Adapting Web Content

WAP defines wireless application environment (WAE) to produce content suitable for wireless devices XHTML-MP (mobile profile) in WAP 2.0 Wireless Markup Language (WML) in earlier versions of

WAP

Page 7: Operating System Support for Mobile Devices

7

WAP 2.0 Architecture

Servicediscovery

Securityservices

App

lica

tion

fram

ewo

rkP

roto

col f

ram

ewo

rk

External services EFI

Provisioning

NavigationDiscovery

ServiceLookup

Cryptolibraries

Authenti-cation

Identification

PKI

Securetransport

Securebearer

Se

ssio

nT

ran

sfe

rT

ran

spo

rtB

ea

rer

Multimedia Messaging (Email)

WAE/WTA User Agent (WML, XHTMLMP)

Content formats

Push

IPv4

IPv6

CSD

SMS

USSD

FLEX

GPRS

MPAK

...

...

Datagrams(WDP, UDP)

Connections(TCP with

wireless profile)

Hypermedia transfer (WTP+WSP, HTTP)

Strea-ming

MMS

PushOTA

Capability Negotiation

Synchronisation Cookies

Was: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet now: Open Mobile Alliance (Open Mobile Architecture + WAP Forum + SyncML + …)

Page 8: Operating System Support for Mobile Devices

8

WAE

Session

Transport

Datagram

Transport layer security

Page 9: Operating System Support for Mobile Devices

9

Wireless Markup Language

W3C XML-based language

Tag-based browsing language: screen management (text, images) data input (text, selection lists, etc.) hyperlinks & navigation support

Page 10: Operating System Support for Mobile Devices

10

WML High-Level Structure

WML pages are called DECKS

Each deck consists of a set of CARDS, related to each other with links

When a WML page is accessed from a mobile phone, all the cards in the page are downloaded from the WAP server

Page 11: Operating System Support for Mobile Devices

11

WML Elements Deck/Card Elements wml card template head access meta

Tasks go prev refresh noop

Event Elements do ontimer onpick onevent postfield

onenterforward onenterbackward

Variables setvar

User input input select option optgroup fieldset

Anchors, Images, and Timers a anchor img timer

Text Formatting br p table tr td

Page 12: Operating System Support for Mobile Devices

12

Header

Deck

Card2

Card1Navigation

Variable

SelectElements

WML Example

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <WML> <CARD> <DO TYPE=“ACCEPT”> <GO URL=“#eCard”/> </DO> Welcome! </CARD> <CARD NAME=“eCard”> <DO TYPE=“ACCEPT”> <GO URL=“/submit?N=$(N)&S=$(S)”/> </DO> Enter name: <INPUT KEY=“N”/> Choose speed: <SELECT KEY=“S”> <OPTION VALUE=“0”>Fast</OPTION> <OPTION VALUE=“1”>Slow</OPTION> <SELECT> </CARD></WML>

Page 13: Operating System Support for Mobile Devices

13

<WML> <CARD> <DO TYPE="ACCEPT" LABEL="Next"> <GO URL="#card2"/> </DO> Dalhousie<BR/>Directory </CARD>

<CARD NAME="card2"> <DO TYPE="ACCEPT"> <GO URL="?send=$type"/> </DO> Services <SELECT KEY="type"> <OPTION VALUE="em">1.Email</OPTION> <OPTION VALUE="ph">2.Phone</OPTION> <OPTION VALUE="fx">3.Fax</OPTION> </SELECT> </CARD></WML>

DalhousieDirectory_____________Next

Services1. Email2. Phone3. Fax .OK

Navigation Path: An Example

Page 14: Operating System Support for Mobile Devices

14

Third Party Adaptation: WAP Gateways

Translate, e.g., between text WML and binary WML (WMLC) from HTML web sites to WML, WMLC, or

XHTML-MP

Add additional information to each request this would be configured by the operator and

could include telephone numbers, location, billing information, and handset information

Page 15: Operating System Support for Mobile Devices

15

WAP Gateway for Web Provides a link between a mobile network and Internet Converts the 'Web' response into a 'WAP' response, e.g.,

HTML -> WML pages, or WML bytecode (WMLC) to reduce the size and number of packets

Page 16: Operating System Support for Mobile Devices

16

Web Server

Content

WM

L D

ecks

wit

h W

ML

-Scr

ipt

WAP Gateway

Encoder,Decoder

WMLScriptCompiler

Protocol Adapters

Client

WML

WML-Script

WTAI

etc.

WAP HTTP

1

Request URL Request

2

HTTP Request

3

HTTP Response

4

Response WML Content

5

7

Example Message Flow

Page 17: Operating System Support for Mobile Devices

17

Example:

http://en.wikipedia.org/wiki/Wikipedia:WAP_access

Page 18: Operating System Support for Mobile Devices

Status

WAP 2.0 is moving towards XHTML-MP XHTML-MP removes many WML features

http://www.developershome.com/wap/xhtmlmp/xhtml_mp_tutorial.asp?page=wmlFeaturesLost

Given emergence of newer phones such as iPhone and Android, it is not clear special content encoding is necessary

18

Page 19: Operating System Support for Mobile Devices

Summary

Adaptation is a key design consideration of mobile application/systems

It involves efforts of both clients and services

19

Page 20: Operating System Support for Mobile Devices

Big Picture

20

Foundational Primitives: Communications, Location, Service Discovery,

UI/Media, Power Management, Security

Application Development Framework

Applications (Adaptation, and support for adaptations)

Page 21: Operating System Support for Mobile Devices

21

Security and Cooperation in Wireless and Mobile

Networks

Page 22: Operating System Support for Mobile Devices

22

Introduction

This is a vast and active field, a course by itself

Many references on wireless security A good book on wireless cooperation:

Thwarting Malicious and Selfish Behaviorin the Age of Ubiquitous Computing, by Levente Buttyan and Jean-Pierre Hubaux, Cambridge University Press, 2007.

available at: http://secowinet.epfl.ch/

Page 23: Operating System Support for Mobile Devices

23

Generic Network Security Attack Models

authenticity; incentive-compatibility

confidentiality

integrity

availability

Page 24: Operating System Support for Mobile Devices

24

Why is Security Challenging in Wireless/Mobile Networks? No inherent physical protection

physical connections between devices are replaced by logical associations

sending and receiving messages do not need physical access to the network infrastructure (cables, hubs, routers, etc.)

Broadcast communications wireless usually means radio, which has a broadcast

nature transmissions can be overheard by anyone in range anyone can generate transmissions,

• which will be received by other devices in range• which will interfere with other nearby transmissions

Thus it is easier to implement jamming, eavesdropping, injecting bogus messages, and replaying previously recorded messages

Page 25: Operating System Support for Mobile Devices

25

Why is Security Challenging in Mobile Networks?

Since mobile devices typically have limited resources (e.g., CPU cycles, battery supply), the designer might want to select simple security mechanisms

However, this may lead to serious security flaws bad example: Wired Equivalent Protection

(WEP), the original security protocol for 802.11

Page 26: Operating System Support for Mobile Devices

26

WEP: A Bad Example

Page 27: Operating System Support for Mobile Devices

27

802.11 Message Flow

data messagesprotected by WEP

Page 28: Operating System Support for Mobile Devices

28

Wired Equivalent Privacy (WEP)

WEP was intended to provide comparable confidentiality to a traditional wired network, thus the name

WEP implements message confidentiality and integrity

WEP encryption is used in 802.11 authentication

Page 29: Operating System Support for Mobile Devices

29

WEP Security

WEP confidentiality through encryption using RC4, a stream-

based encryption algorithm using a shared key

WEP integrity through message check sum using encrypted

cyclic redundancy check (CRC)

WEP authentication through challenge/response

Page 30: Operating System Support for Mobile Devices

30

WEP Encryption

For each message to be sent: RC4 is initialized with the shared secret

between station STA and access point (AP)• WEP allows up to 4 shared keys

RC4 produces a pseudo-random byte sequence (key stream) from the shared key

This pseudo-random byte sequence is XORed to the message

Page 31: Operating System Support for Mobile Devices

31

WEP Encryption To avoid using the same key stream, WEP

encrypts each message with a different key stream the RC4 generator is initialized with the

shared secret plus a 24-bit IV (initial value)• shared secret is the same for each message• 24-bit IV for each message• there is no specification on how to choose the IV;

sender picks the IV value

Page 32: Operating System Support for Mobile Devices

32

WEP Integrity

WEP integrity protection is based on computing ICV (integrity check value) using CRC and appended to the message

The message and the ICV are encrypted together

Page 33: Operating System Support for Mobile Devices

33

WEP

IV secret key RC4RC4

message | ICV

message | ICVIV

IV secret key RC4RC4

message | ICV

encode

decode

KS

KS

CRCCRC

check CRC

check CRC

Page 34: Operating System Support for Mobile Devices

34

Active Attack on WEP: IV Replay Attacks

A known plain-text message is sent to an observable wireless LAN client (how?)

The network attacker will sniff the wireless LAN looking for the predicted cipher-text

The network attacker will find the known frame, derive the key stream (corresponds to the give IV+K), and reuse the key stream

Page 35: Operating System Support for Mobile Devices

35

Active Attack on WEP: Bit-Flipping Attack

The attacker sniffs a frame on the wireless LAN The attacker captures the frame and flips random bits in the data

payload of the frame The attacker modifies the ICV (detailed later) The attacker transmits the modified frame The access point receives the frame and verifies the ICV based

on the frame contents The AP accepts the modified frame The destination receiver de-encapsulates the frame and

processes the Layer 3 packet Because bits are flipped in the higher layer packet, the Layer 3

checksum fails The receiver IP stack generates a predictable ICMP error The attacker sniffs the wireless LAN looking for the encrypted

error message Upon receiving the error message, the attacker derives the key

stream as with the IV replay attack

Page 36: Operating System Support for Mobile Devices

36

Bit-Flipping Attack

Page 37: Operating System Support for Mobile Devices

37

Generating Valid CRC

The crucial step of the flipping attack is to allow the frame to pass the ICV check of the AP

Unfortunately, the CRC algorithm allows generating valid encrypted ICV after bit flipping

Page 38: Operating System Support for Mobile Devices

38

Bypassing Encrypted ICV

CRC is a linear function wrt to XOR:

CRC(X Y) = CRC(X) CRC(Y)

- Attacker observes (M | CRC(M)) K where K is the key stream output- for any M, the attacker can compute CRC(M) - hence, the attacker can compute:

([M | CRC(M]) K) [M | CRC(M)] = ([M M) | (CRC(M) CRC(M)]) K= [M M) | CRC(M M)] K

Page 39: Operating System Support for Mobile Devices

39

WEP Authentication

Two authentication modes

open authentication --- means no authentication !

• an AP could use SSID authentication and MAC address filtering, e.g., at Yale

shared key authentication based on WEP

Page 40: Operating System Support for Mobile Devices

40

WEP Shared Key Authentication Shared key authentication is based on a

challenge-response protocol:…AP STA: rSTA AP: IV | (r K)…

where K is a 128 bit RC4 output on IV and the shared secret

An attacker can compute r (r K) = K

Then it can use K to impersonate STA later:…AP attacker: r’attacker AP: IV | (r’ K)…

Page 41: Operating System Support for Mobile Devices

41

WEP: Lessons

WEP has other problems, e.g., short IV space, weak RC4 keys

Engineering security protocols is difficult one can combine otherwise OK building blocks in a

wrong way and obtain an insecure system at the end• example 1:

– stream ciphers alone are OK– challenge-response protocols for entity authentication are OK– but they shouldn’t be combined

• example 2:– encrypting a message digest to obtain an ICV is a good principle– but it doesn’t work if the message digest function is linear wrt to the

encryption function

Page 42: Operating System Support for Mobile Devices

42

Fixing WEP

After the collapse of WEP, Wi-Fi Protected Access (WPA) was proposed in 2003

Then the full 802.11x standard (also called WPA2) was proposed in 2004

But WEP is still in use

Page 43: Operating System Support for Mobile Devices

43

Cooperation in Wireless, Mobile Networks

Page 44: Operating System Support for Mobile Devices

44

Cooperation in Wireless Networks

A special case of “security attack” is by rational nodes drop packets, mis-represent information

Motivation wireless networks have limited capacity wireless nodes have limited resource—battery power unlike the Internet, where commercial relationship is

worked out, many mesh network nodes belong to different users and may not have incentive to forward others’ traffic

• similar free-riding problems in P2P applications

Page 45: Operating System Support for Mobile Devices

45

Reward-based Routing The network (authority) rewards the nodes so

that they will forward traffic from a source to a destination

Each node has a (private energy/transmission) cost of sending one packet to a neighbor

The objective of the authority is to choose the lowest cost path assume cost reflects energy thus extending network

life time/maximizing capacity—the community benefit

Page 46: Operating System Support for Mobile Devices

46

Node Utility Assume each node wants to maximize its utility The utility of being on the path P of a source-

destination pair:

where - pi is the amount the network rewards node i - 1P(i) is 1 if node i is on the path P; otherwise 0

- ci is the cost of the link used in P, if a link from i is used

)(1 icpu Piii

Page 47: Operating System Support for Mobile Devices

47

Discussion

How about we reward nodes according to their claimed costs?

)(1 icpu Piii

Page 48: Operating System Support for Mobile Devices

48

Payment Using VCG Mechanism VCG stands for Vickrey, Clarke and Groves The VCG mechanism

each node sends the costs of its links to the authority the authority computes the lowest cost path from the

source S to the destination D the payment to node i:

where - LCP(S,D) is the lowest cost path from S to D: {S->R1, R1->R2, …, Rk->D}

- LCP(S,D)\{i} is the previous path but does not include the link from i to its next hop, if i is on the path; if i is not on the path, it is just the previous path

- LCP(S,D;-i) is the lowest cost path from S to D without using i, i.e. remove node i from the graph and then find path

}){\),((cost));,((cost iDSLCPiDSLCPpi

Page 49: Operating System Support for Mobile Devices

49

Example: N1

12

1 3N2

D

N1

S

- assume N1 declares the cost as 2, how much will N1 berewared according to the VCG mechanism? (1+3)-1 = 3

- assume N1 declares the cost as 1, how much will N1 berewarded according to the VCG mechanism?

- what is the utility of N1? 3 - 2 = 1

(1+3)-1 = 3- what is the utility of N1? 3 - 2 = 1

- assume N1 declares the cost as 4, how much will N1 berewared according to the VCG mechanism?

Assume the true cost of N1 to D is 2

(1+3)-(1+3) = 0- what is the utility of N1? 0 - 0 = 0

}){\),((cost));,((cost iDSLCPiDSLCPpi

Page 50: Operating System Support for Mobile Devices

50

Formal Results

Each node reports its link costs truthfully

Thus the network chooses the lowest cost path for each source-destination pair

Page 51: Operating System Support for Mobile Devices

51

Analysis on Truthfulness

By contradiction Assume node i’s true costs for its links are Ci but

reports Wi

think of Wi and Ci as vectors of link costs

The node decides to declare Wi instead of Ci only if the utility is higher

The best scenario a node can be in is that it is given the declared costs of all other nodes’ links and then decides its declarations of the costs of its links in order to maximize its utility action chosen in this way is called dominant strategy

Page 52: Operating System Support for Mobile Devices

52

VCG Proof

Assume the lowest cost path computed is - LCP when the node reports Ci, and

- LCP’ when reports Wi

it must be the case that (1P(i) meant i on path P)

)(1}){\),((cost));,((cost

)(1}){\),('(cost));,('(cost ''

iciDSLCPiDSLCP

iciDSLCPiDSLCPLCPLCP

i

LCPLCPi

)(1}){\),((cost)(1}){\),('(cost '' iciDSLCPiciDSLCP LCPLCPi

LCPLCPi

)(1}){\),((cost)(1}){\),('(cost '' iciDSLCPiciDSLCP LCPLCPi

LCPLCPi

Right hand side is LCP we computed; left hand side is one path. Contradiction.

Page 53: Operating System Support for Mobile Devices

Revisit some slides of first class

53

Page 54: Operating System Support for Mobile Devices

54

Enabling Technologies

Development and deployment of wireless/mobile technology and infrastructure in-room, in-building, on-campus, in-the-field, MAN,

WAN, GPS Miniaturization of computing machinery . . . -> PCs -> laptop -> PDAs/smart phones ->

embedded computers/sensors Improving device capabilities/software

development environments, e.g., andriod: http://code.google.com/android/ iphone: http://developer.apple.com/iphone/ windows mobile

Page 55: Operating System Support for Mobile Devices

55

At Home

WiFi

WiFi

WiFi

cellular

bluetooth

UWB

satellite

WiFi 802.11g/n

Page 56: Operating System Support for Mobile Devices

56

At Home

Source: http://teacher.scholastic.com/activities/science/wireless_interactives.htm

Page 57: Operating System Support for Mobile Devices

57

UMTS,DECT2 Mbit/s

UMTS Rel. 6400 kbit/s

LAN100 Mbit/s,WLAN54 Mbit/s

UMTS Rel. 5400 kbit/s

GSM 115 kbit/s,WLAN 11 Mbit/s

GSM 53 kbit/sBluetooth 500 kbit/s

GSM/EDGE 135 kbit/s,WLAN 780 kbit/s

LAN, WLAN780 kbit/s

Mobile and Wireless Services – Always Best Connected

Page 58: Operating System Support for Mobile Devices

58

Habitat Monitoring: Example on Great Duck Island

Patch Network

Transit Network

Basestation

Gateway

A 15-minute human visit leads to 20% offspring mortality

Page 59: Operating System Support for Mobile Devices

Why is the Field Challenging?

Page 60: Operating System Support for Mobile Devices

60

Challenge 1: Unreliable and Unpredictable Wireless Coverage

Asymmetry vs. PowerReception v. Distance

*Cerpa, Busek et. al

What Robert Poor (Ember) calls “The good, the bad and the ugly”

Wireless links are not reliable: they may vary over time and space

Page 61: Operating System Support for Mobile Devices

61

Challenge 2: Open Wireless Medium

Wireless interference

Hidden terminals

Exposed terminal

S1

S2

R1

R1

S1 R1 S2

R1 S1 S2 R2

Page 62: Operating System Support for Mobile Devices

62

Challenge 2: Open Wireless Medium

Wireless interference

Hidden terminals

Exposed terminal

Wireless security eavesdropping, denial of service, …

S1

S2

R1

R1

S1 R1 R2

R1 S1 S2 R2

Page 63: Operating System Support for Mobile Devices

63

Challenge 3: Mobility

Mobility causes poor-quality wireless links

Mobility causes intermittent connection under intermittent connected networks,

traditional routing, TCP, applications all break

Mobility changes context, e.g., location

Page 64: Operating System Support for Mobile Devices

64

Challenge 4: Portability

Limited battery power Limited processing, display and storage

Sensors,embeddedcontrollers

Mobile phones• voice, data• simple graphical displays• GSM/3G

PDA phone• data• simpler graphical displays• 802.11/3G

Laptop• fully functional• standard applications• battery; 802.11

PPerformanceerformance/Weight/Power Consumption/Weight/Power Consumption

Page 65: Operating System Support for Mobile Devices

65

Challenge 5: Changing Regulation and Multiple Communication Standards

cellular phones satellites wireless LAN

cordlessphones

1992:GSM

1994:DCS 1800

2001:IMT-2000

1987:

CT1+

1982:Inmarsat-

A

1992:Inmarsat-BInmarsat-M

1998:Iridium

1989:CT 21991:DECT 199x:

proprietary

1997:IEEE 802.11

1999:802.11b, Bluetooth

1988:Inmarsat-

C

analogue

digital

1991:D-AMPS

1991:CDMA

1981:NMT 450

1986:NMT 900

1980:

CT01984

:CT1

1983:AMPS

1993:PDC

2000:GPRS

2000:IEEE 802.11a

Fourth Generation

(Internet based)

Page 66: Operating System Support for Mobile Devices

Topics not Covered

There are several topics that are quite interesting but we do not have time to cover in more detail, e.g., Cognitive radio Virtualization of wireless networks Sync (e.g., SyncML) /replicate management Context-aware applications design Mobile device management Controlled mobility

66

Page 67: Operating System Support for Mobile Devices

67

Summary

Driven by technology and vision infrastructure (communication/location) device miniaturization mobile computing platforms

The field is moving fast and has many opportunities

Page 68: Operating System Support for Mobile Devices

Backup Slides on Cooperation

68

Page 69: Operating System Support for Mobile Devices

Backup Slides on Sync/Replicate Management

69

Page 70: Operating System Support for Mobile Devices

70

Discussion

What challenges does the file system face in wireless/mobile environment?

Page 71: Operating System Support for Mobile Devices

71

The Problems Caused by Mobility

Read miss stalls progress (the user has to stop working)

Synchronization/consistency issues may need to synchronize multiple copies of

the same file if multiple users, may need to solve

consistency problems

Heterogeneous device types each device has its own file systems and

naming convention, e.g., digital camera, ipod

Page 72: Operating System Support for Mobile Devices

72

Approaches

Read miss explicit user file selection, e.g., MS briefcase automatic hoarding, e.g., CODA, SEER

Synchronization/consistency issues keep modification logs and develop merge tools, e.g.,

Bayou efficient file comparisons and merging, e.g., rsync,

LBFS

Heterogeneous device types masks the differences , e.g., EnsemBlue

Page 73: Operating System Support for Mobile Devices

73

SEER: automatic prediction of related files to avoid user manual configuration of

hoarding

Page 74: Operating System Support for Mobile Devices

74

SEER: A Predictive Hoarding System

Views user activities as composed of projects than individual files

Predicates files in a project and fetch them together

Discussion: how do you predicate all of the files a project may use?

Page 75: Operating System Support for Mobile Devices

75

Basic Idea of SEER: Semantic Distance Quantifies user’s intuition about

relationship between files smaller closer in relation

Infers relationship static (done by an external investigator), e.g.,

• observes directory structure/membership• observes naming convention• #include in a program

dynamic• watches user’s behavior

Page 76: Operating System Support for Mobile Devices

76

Lifetime Semantic Distance Looks at file open/close (not file content !!) Lifetime semantic distance:

The lifetime semantic distance between an open of file A and an open of file B is defined as 0 if A has not been closed before B is opened and the number of intervening file opens (including the open of B) otherwise

End up with multiple lifetime semantic distances between two events of two files needs distance between two files, not events uses geometric mean to convert to a single distance

AB C

D

Time

Sample file access sequence

Semantic distance- AB , AC is 0- AD is 3

Page 77: Operating System Support for Mobile Devices

77

Basic Idea of SEER: Clustering Algorithm Based on algorithm by

Jarvis and Patrick Allows overlapping clusters Steps

calculates n nearest neighbors for each file

Phase 1: if two points (files here) have at least kn overlapping neighbors, combine their clusters into one

Phase 2: if two points have more than kf but less than kn overlapping neighbors, overlap the clusters i.e. add each to the other cluster

Relation Action

kn ≤x

kf≤x<kn

x<kf

Combine clustersOverlapping clustersNo action

Summary of clustering algorithm

Page 78: Operating System Support for Mobile Devices

78

Example

Seven files , A-G{A} {B} {C} {D} {E} {F}

{G}

Phase 1: {A, B} {A, B, C}{D, E} {F, G} {D,E,F, G}

Phase 2:two pairs {A, C} {C, D}

{A, C} : same cluster already{C, D} overlap clusters

Final result {A, B, C, D} {C,D, E, F,G}

Number of shared neighbors

From ToA B C D E F G

ABCDEFG

kn kf kn kf kn

kn kn

Page 79: Operating System Support for Mobile Devices

79

Using Both Lifetime Semantic Distance and the Input of External Investigator

Essentially gives application specific info

Example large directory distance => looser

relationship• subtract directory distance from shared neighbor

count

Page 80: Operating System Support for Mobile Devices

80

Real World Anomalies: Special Cases Many special cases

authors use a heuristic to solve each

Shared libraries e.g. : library X might cause unwanted clustering Heuristic: files which represent more than a

certain percentage of all references marked as “frequently-referenced” (1%)

• eliminate from calculation

Page 81: Operating System Support for Mobile Devices

81

Critical files (e.g. : startup files) rarely accessed but important use heuristic and hoard

• special control file that specifies such files• detect by names e.g. .login etc

Temporary files (e.g. : in /tmp) transient and don’t depict correct relationship might displace other important files from n closest heuristic: ignore files in /tmp etc. completely

Simultaneous access e.g. : read mail & compile code independent streams are intermixed ! maintain reference-history on a per-process basis

More Special Cases …

Page 82: Operating System Support for Mobile Devices

82

Scheduling of Multimedia Applications

Earliest deadline first (EDF) scheduling

- allocate cycle budget per job

- execute job with earliest deadline and positive budget

- charge budget by number of cycles consumed

- preempt if budget is exhausted

Page 83: Operating System Support for Mobile Devices

83

Bayou: automatic conflict update

Page 84: Operating System Support for Mobile Devices

84

Bayou: Managing Update Conflicts

Basic idea: application specific conflict detection and update

Two mechanisms for automatic conflict detection and resolution dependency check merge procedure

Page 85: Operating System Support for Mobile Devices

85

Bayou Write Operation: An Example

Page 86: Operating System Support for Mobile Devices

86

Mobile file systems: dealing with low bandwidth: LBFS: efficient file comparison and merging

Page 87: Operating System Support for Mobile Devices

87

Motivation

The CODA system assumes that modifications are kept as logs (CML) a user sends the logs to the servers to update

If the storage of a client is limited, it may not be able to save logs then upon reconnection, the cache manager needs to

find the difference between the stored file and its local cached copy

same problem exists for the rsync tool !

Question: how to efficiently compare the differences of two remote files (when the network connection is slow)?

Page 88: Operating System Support for Mobile Devices

88

LBFS: Low-Bandwidth File System

Break Files into chunks and transfer only modified chunks

Fixed chunk size does not work well why?

Page 89: Operating System Support for Mobile Devices

89

Flexible Chunk Size

Compute hash value of every 48 byte block if the hash value equals to a magic value, it is

a chunk boundary

Page 90: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan90

What is data synchronization?

Data synchronization “is the process of making two sets of data look identical” (source: syncml.org white paper)

Page 91: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan91

Data Synchronization

Datastore1 Datastore2

A CB C A BA CB

Exchange data modifications Resolve conflicts

Page 92: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan92

What is a “data synchronization protocol”?

• Method of communication for a data synchronization session

• Protocol features:– naming and identification of records– common protocol commands– identification and resolution of

synchronization conflicts

Page 93: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan93

SyncML defined…

“SyncML is a new industry initiative to develop and promote a single, common data synchronization protocol that can be used industry-wide.” (syncml.org)

“SyncML is a specification for a common data synchronization framework and XML-based format […] for synchronizing data on networked devices.” (syncml.org)

“SyncML is a […] protocol for conveying data synchronization operations.” (syncml.org)

Page 94: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan94

SyncML sponsors

Page 95: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan95

SyncML features

• Synchronize any type of data

• Multiple protocol bindings– HTTP, WSP, OBEX

• Security

• Interoperability

Page 96: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan96

client modifications

SyncML: clients & servers

SyncMLserver

server modifications

Page 97: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan97

SyncML synchronization types

• Two-way sync

• Slow sync

• One-way sync from client only

• Refresh sync from client only

Page 98: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan98

SyncML synchronization types (cont.)

• One-way sync from server only

• Refresh sync from server only

• Server alerted sync

Page 99: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan99

SyncML terminology

• Message

• Package

• Command

• Status code

• Datastore

• Device info

• Meta info

• Capabilities exchange

Page 100: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan100

SyncML and XML

• Abbreviated naming convention– Ex: ”protocol version” is <VerProto>

• XML prolog is not required

• WBXML– WAP Binary XML

Page 101: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan101

SyncML documents

• <SyncML> DTD

• Meta info DTD

• Device info DTD

Page 102: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan102

<SyncML> document

<?xml version="1.0"?>

<!DOCTYPE … >

<SyncML>

<SyncHdr>

</SyncHdr>

<SyncBody>

</SyncBody>

</SyncML>

• “A SyncML Message is a well-formed, but not necessarily valid, XML document.” (syncml.org)

• Contains data synchronization commands (operations)

Page 103: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan103

<SyncHdr> element

<SyncHdr>

<VerDTD>1.0</VerDTD>

<VerProto>SyncML/1.0</VerProto>

<SessionID>session41</SessionID>

<MsgID>msg80386</MsgID>

</SyncHdr>

Page 104: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan104

<SyncBody> element

<SyncBody>

<Add>

<CmdID>cmd80486</CmdID>

<Item>…</Item>

</Add>

</SyncBody>

Page 105: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan105

SyncML commands

• <Add>

• <Alert>

• <Atomic>

• <Copy>

• <Delete>

• <Exec>

• <Get>

• <Map>

• <Put>

• <Replace>

• <Results>

• <Search>

• <Sequence>

• <Status>

• <Sync>

Page 106: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan106

Meta Info document

• Contains sync session parameters

<MetInf>

<Format>…</Format>

<Type>…</Type>

<MaxMsgSize>586

</MaxMsgSize>

</MetInf>

Page 107: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan107

Device Info document

• Describes device capabilities

• For both client and server

<DevInf>

<SwV>0.99</SwV>

<HwV>3.14</HwV>

<DevTyp>pda</DevTyp>

</DevInf>

Page 108: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan108

Sync4j project

• Java implementation of SyncML protocol

• Sync4j client

• Sync4j server

• open source

Page 109: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan109

Sync4j audience

• developers who:– know Java but don’t know SyncML– know SyncML but may not know Java

• commercial application developers

• open source application developers

Page 110: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan110

API design ideas

• SAX API– standard set of interfaces– multiple implementations– usage model: callbacks

• JDOM API– concrete classes; single implementation– root Document object contains Element

objects

Page 111: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan111

API design ideas (cont.)

• Servlet API– usage model: developer builds a new servlet

by subclassing HTTPServlet

• Auto-generate API classes from DTD using an XML data-binding tool - ?

Page 112: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan112

Sync4j design goals

• Hide complexity of the SyncML specification from Java programmers– XML documents, XML parsing– multiple transport protocols

• A complete SyncML implementation

• Interoperability– with existing SyncML clients & servers

Page 113: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan113

Sync4j design goals (cont.)

• API should be natural and familiar to Java programmers– direct object instantiation– exceptions– use Collection API / arrays, where appropriate– event notification via event listeners– familiar naming conventions

Page 114: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan114

Sync4j design goals (cont.)

• API must be familiar to developers who already know the SyncML DTD’s

• API must enforce any restrictions that are defined in the SyncML specification

Page 115: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan115

Sync4j’s modular design

• “core” protocol message library

• transport protocol libraries

• extensible client framework

• extensible server framework

• client application

• server application

Page 116: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan116

Sync4j implementation

• Immutable objects

• Exception class for each SyncML “status code”

• Declaration of constants– public final static variables

• Command object hierarchy

Page 117: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan117

Sync4j command hierarchy

AbstractCommand

ResponseCommandRequestCommand

AddCommand, DeleteCommand,

ReplaceCommand,…

ResultsCommand,StatusCommand

Page 118: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan118

Sync4j toolset

• Jakarta Ant

• JDOM

• Apache Xerces-J

• CVS

• log4j

• Sun JDK 1.4.0

• Sun J2EE SDK

• JUnit

• Apache Tomcat

• Netbeans

Page 119: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan119

Sync4j packages

• sync4j.core

• sync4j.transport

• sync4j.framework

• sync4j.client

• sync4j.server

• sync4j.tests

Page 120: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan120

Sync4j core classes

• Message

• DeviceInfo

• MetaInfo

• Command classes:– AddCommand– DeleteCommand– ReplaceCommand

Page 121: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan121

sync4j.core.Message

• Two ways to construct a Message object:– from a String of XML– from more basic sync4j objects

Page 122: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan122

Sync4j Message example 1

String strXML = “<SyncML> … </SyncML>”;

Message msg;

try

{

msg = new Message(strXML);

}

catch (InvalidMarkupException ex)

{

}

catch (XMLSyntaxException ex)

{

}

Page 123: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan123

Sync4j Message example 2

SyncHeader header = new SyncHeader(...);

SyncBody body = new SyncBody(...);

Message msg;

msg = new Message(header, body);

String strXML = msg.toXML();

Page 124: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan124

Summary

• Use SyncML to synchronize data between mobile applications and server applications

• SyncML is a complex and powerful data synchronization protocol

• Sync4j hides the complexity of SyncML from Java programmers

End

Page 125: Operating System Support for Mobile Devices

Session # 1481 - Copyright 2002 Sean C. Sullivan125

For more information…

End

Please visithttp://sync4j.sourceforge.net/

Page 126: Operating System Support for Mobile Devices

Backup Slides on TELA

126

Page 127: Operating System Support for Mobile Devices

127

TELSA: A Positive Example

Page 128: Operating System Support for Mobile Devices

Digital Signatures Do Not Work

Problem statement: authentication of packets

The typical approach in the Internet is to

attach a digital signature on each packet

However, signatures are expensive, e.g., RSA

1024 on a 2.1 GHz desktop: high signature cost (~5 ms)

high communication cost (128 bytes/packet)

More expensive on low-end processors

http://www.cryptopp.com/benchmarks.html

Page 129: Operating System Support for Mobile Devices

TESLA

Timed Efficient Stream Loss-tolerant Authentication

Uses only symmetric cryptography

Page 130: Operating System Support for Mobile Devices

Basic Authentication Mechanism

t

F(K)AuthenticCommitment

P

MAC(K,P)

Kdisclosed

1: Verify K

2: Verify MAC

3: P Authentic!

F: public one-way function; MAC: message digest function

Page 131: Operating System Support for Mobile Devices

TELSA Security Condition

Sender distributes initial commitment and key

disclosure schedule using, say, digital signature

Security condition (for packet P):

on arrival of P, receiver is certain that sender did not

yet disclose K

If security condition not satisfied, drop packet

Page 132: Operating System Support for Mobile Devices

TESLA: Example

K4 K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K3

P5

K5

P3

K3

P2

K2

P1

K2

Verify MACs

P4

K4

FF

Authenticate K3

Keys disclosed 2 time intervals after use

Page 133: Operating System Support for Mobile Devices

TESLA Summary

Advantages low overhead

• communication (~ 20 bytes)• computation (~ 1 MAC computation per packet)

tolerate packet loss

Problems time synchronization delayed authentication

Page 134: Operating System Support for Mobile Devices

Secure Efficient Ad hoc Distance Vector (SEAD)

Uses one-way hash chains to authenticate metric and sequence number for DSDV

Assumes a limit k-1 on metric (as in other distance vector protocols such as RIP, where k=16) metric value infinity can be represented as k

Page 135: Operating System Support for Mobile Devices

SEAD Metric Authenticators

Each node generates a hash chain and distributes the last element (CN+1) to allow verification: chain values CN-k+1, …, CN authenticate metrics

0 through k-1 for sequence number 1 CN-2k+1,…CN-k authenticate metrics 0 through k-1

for sequence number 2 CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1

for sequence number iC0 C1 C3C2 C5C4

C6 C7 C9C8 C10 C12C11

Page 136: Operating System Support for Mobile Devices

SEAD Metric Authenticators

Each node generates a hash chain anddistributes the last element (CN+1) to allow verification: Chain values CN-k+1, …, CN authenticate

metrics 0 through k-1 for sequence number 1

CN-2k+1,…CN-k authenticate metrics 0 through k-1 for sequence number 2

CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1 for sequence number i

C0 C1 C3C2 C5C4

C6 C7 C9C8 C10 C12C11

Page 137: Operating System Support for Mobile Devices

SEAD Metric Authenticators

Each node generates a hash chain and distributes the last element (CN+1) to allow verification: Chain values CN-k+1, …, CN authenticate metrics

0 through k-1 for sequence number 1 CN-2k+1,…CN-k authenticate metrics 0 through

k-1 for sequence number 2

CN-ik+1,…CN-(i-1)k authenticate metrics 0 through k-1 for sequence number i

C0 C1 C3C2 C5C4

C6 C7 C9C8 C10 C12C11

Page 138: Operating System Support for Mobile Devices

Each node generates a hash chain and distributes the last element (CN+1) to allow verification: Chain values CN-k+1, …, CN authenticate metrics

0 through k-1 for sequence number 1 CN-2k+1,…CN-k authenticate metrics 0 through k-1

for sequence number 2 CN-ik+1,…CN-(i-1)k authenticate metrics 0 through

k-1 for sequence number i

SEAD Metric Authenticators

C0 C1 C3C2 C5C4

C6 C7 C9C8 C10 C12C11

Page 139: Operating System Support for Mobile Devices

SEAD Metric Authenticators

Within a sequence number i: CN-ik+1 represents metric 0

CN-ik+2 represents metric 1

CN-ik+m+1 represents metric m

CN-ik+k represents metric k-1

C9 C10 C11

Metric 0 Metric 1 Metric 2When a node receives a routing update:• It first checks the metric authenticator• If the update is to be accepted:

– It increments the metric by one

– and hashes the authenticator

– then adds the metric and authenticator to routing table