• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Operating System Support for Mobile Devices
 

Operating System Support for Mobile Devices

on

  • 1,351 views

 

Statistics

Views

Total Views
1,351
Views on SlideShare
1,350
Embed Views
1

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Screen, content size, javascript, plugins such as flash
  • (e.g., an e-mail message)
  • We are getting closer to the goal because of advances in enabling technologies.
  • Service composition: when playing movie, send sound to stereo When laptop is active, turn down the volume of the TV
  • What is semantic distance : quantify user’s intuition about relationship between files
  • Number of special cases, and they use a heuristic for each. I’ll just take a couple
  • 05/09/10 Session #, Speaker Name
  • 05/09/10 Session #, Speaker Name Data modifications: add new record, replace existing record, delete record
  • 05/09/10 Session #, Speaker Name Any type of data: calendar data (iCalendar, vCalendar), address book (vCard), email messages, XML documents, binary data, etc. Data is identified by MIME types.
  • 05/09/10 Session #, Speaker Name Client maintains a change log. Server maintains a change log. When they synchronize, the client and server use the change logs to determine what data has changed. Change log must track: replace, addition, deletion. Each piece of data in the datastore has a unique identifier. Client and server can each use their own private identifiers for internal use. The server is responsible for maintaining “Mapping Table” for mapping
  • 05/09/10 Session #, Speaker Name WBXML: W AP B inary XML compact representation for XML documents http://www.wapforum.org/
  • 05/09/10 Session #, Speaker Name The sync4j client runs on J2SE. The sync4j server runs on J2EE. Open source license: virtually identical to JDOM license (similar to Apache Public License)
  • 05/09/10 Session #, Speaker Name XML data binding tools: Castor http://www.castor.org/ Sun JAXB http://java.sun.com/xml/ Enhydra Zeus http://zeus.enhydra.org/
  • 05/09/10 Session #, Speaker Name
  • 05/09/10 Session #, Speaker Name

Operating System Support for Mobile Devices Operating System Support for Mobile Devices Presentation Transcript

  • Security and Cooperation, Wrap up 4/23/2009 Richard Yang
  • Admin.
    • Projects due May 12
    • We will continue to hold regular office hours until May 12 or you can send email to make appointments
  • 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
    client service request result
  • 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?
  • 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
  • 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
  • WAP 2.0 A rchitecture Service discovery Security services Application framework Protocol framework External services EFI Provisioning Navigation Discovery Service Lookup Crypto libraries Authenti-cation Identification PKI Secure transport Secure bearer Session Transfer Transport Bearer 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 Push OTA Capability Negotiation Synchronisation Cookies
      • W as: WAP Forum, co-founded by Ericsson, Motorola, Nokia, Unwired Planet now: Open Mobile Alliance (Open Mobile Architecture + WAP Forum + SyncML + …)
  • WAE Session Transport Datagram Transport layer security
  • Wireless Markup Language
    • W3C XML-based language
    • Tag-based browsing language:
      • screen management (text, images)
      • data input (text, selection lists, etc.)
      • hyperlinks & navigation support
  • 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
  • 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
  • WML Example <?xml version=&quot;1.0&quot;?> <!DOCTYPE wml PUBLIC &quot;-//WAPFORUM//DTD WML 1.1//EN&quot; &quot;http://www.wapforum.org/DTD/wml_1.1.xml&quot;> <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> Header Deck Card2 Card1 Navigation Variable Select Elements
  • Navigation Path : An Example <WML> <CARD> <DO TYPE=&quot;ACCEPT&quot; LABEL=&quot;Next&quot;> <GO URL=&quot;#card2&quot;/> </DO> Dalhousie<BR/>Directory </CARD> <CARD NAME=&quot;card2&quot;> <DO TYPE=&quot;ACCEPT&quot;> <GO URL=&quot;?send=$type&quot;/> </DO> Services <SELECT KEY =&quot;type&quot;> <OPTION VALUE=&quot;em&quot;>1.Email</OPTION> <OPTION VALUE=&quot;ph&quot;>2.Phone</OPTION> <OPTION VALUE=&quot;fx&quot;>3.Fax</OPTION> </SELECT> </CARD> </WML> Dalhousie Directory _____________ Next Services 1. Email 2. Phone 3. Fax . OK
  • 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
  • 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 r educe the size and number of packets
  • Example Message Flow WAP HTTP Web Server Content WML Decks with WML-Script WAP Gateway Encoder,Decoder WMLScript Compiler Protocol Adapters Client WML WML-Script WTAI e tc. 1 Request URL Request 2 HTTP Request 3 HTTP Response 4 Response WML Content 5 7
  • Example:
    • http://en.wikipedia.org/wiki/Wikipedia:WAP_access
  • 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
  • Summary
    • Adaptation is a key design consideration of mobile application/systems
    • It involves efforts of both clients and services
  • Big Picture Foundational Primitives: Communications, Location, Service Discovery, UI/Media, Power Management , Security Application Development Framework Applications (Adaptation, and support for adaptations)
  • Security and Cooperation in Wireless and Mobile Networks
  • 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 Behavior in the Age of Ubiquitous Computing, by Levente Buttyan and Jean-Pierre Hubaux , Cambridge University Press, 2007.
      • available at: http://secowinet.epfl.ch/
  • Generic Network Security Attack Models authenticity; incentive-compatibility confidentiality integrity availability
  • 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
  • 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
  • WEP: A Bad Example
  • 802.11 Message Flow data messages protected by WEP
  • 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
  • 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
  • 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
  • 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
  • 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
  • WEP IV secret key RC4 message | ICV message | ICV IV IV secret key RC4 message | ICV encode de code KS KS CRC check CRC
  • 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
  • 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
  • Bit-Flipping Attack
  • 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
  • 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
  • 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
  • WEP Shared Key Authentication
    • Shared key authentication is based on a challenge-response protocol:
      • AP  STA: r
      • STA  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)
  • 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
  • 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
  • Cooperation in Wireless, Mobile Networks
  • 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
  • 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
  • Node Utility
    • Assume each node wants to maximize its utility
    • The utility of being on the path P of a source-destination pair:
    • where - p i is the amount the network rewards node i - 1 P (i) is 1 if node i is on the path P; otherwise 0
    • - c i is the cost of the link used in P, if a link from i is used
  • Discussion
    • How about we reward nodes according to their claimed costs?
  • 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
  • Example: N1 - assume N1 declares the cost as 2, how much will N1 be rewared according to the VCG mechanism? (1+3)-1 = 3 - assume N1 declares the cost as 1, how much will N1 be rewarded 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 be rewared 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 1 2 1 3 N2 D N1 S
  • Formal Results
    • Each n ode r eports its l ink c osts t ruthfully
    • Thus the network chooses the lowest cost path for each source-destination pair
  • Analysis on Truthfulness
    • By contradiction
    • Assume node i’s true costs for its links are C i but reports W i
      • think of W i and C i as vectors of link costs
    • The node decides to declare W i instead of C i 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
  • VCG Proof
    • Assume the lowest cost path computed is
      • LCP when the node reports C i , and
      • LCP’ when reports W i
    • it must be the case that (1 P (i) meant i on path P)
    Right hand side is LCP we computed; left hand side is one path. Contradiction.
  • Revisit some slides of first class
  • Enabling Technologies
    • Development and d eployment of wireless/mobile technology and i nfrastructure
      • i n-room, in-building, on-campus, in-the-field, MAN, WAN, GPS
    • Miniaturization of c omputing m achinery
    • . . . -> 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
  • At Home WiFi WiFi WiFi cellular bluetooth UWB satellite WiFi 802.11g/n
  • At Home Source: http://teacher.scholastic.com/activities/science/wireless_interactives.htm
  • Mobile and W ireless S ervices – Always Best Connected UMTS, DECT 2 Mbit/s UMTS Rel. 6 400 kbit/s LAN 100 Mbit/s, WLAN 54 Mbit/s UMTS Rel. 5 400 kbit/s GSM 115 kbit/s, WLAN 11 Mbit/s GSM 53 kbit/s Bluetooth 500 kbit/s GSM/EDGE 135 kbit/s, WLAN 780 kbit/s LAN, WLAN 780 kbit/s
  • Habitat Monitoring: Example on Great Duck Island A 15-minute human visit leads to 20% offspring mortality Patch Network Transit Network Basestation Gateway
  • Why is the Field Challenging?
  • Challenge 1: Unreliable and Unpredictable Wireless Coverage What Robert Poor (Ember) calls “The good, the bad and the ugly”
    • Wireless links are not reliable: they may vary over time and space
    Asymmetry vs. Power Reception v. Distance * Cerpa, Busek et. al
  • Challenge 2: Open Wireless Medium
    • Wireless interference
    • Hidden terminals
    • Exposed terminal
    S1 S2 R1 R1 S1 R1 S2 R1 S1 S2 R2
  • 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
  • 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
  • Challenge 4: Portability
    • Limited battery power
    • Limited processing, display and storage
    • Mobile phones
    • voice, data
    • simple graphical displays
    • GSM/3G
    • Laptop
    • fully functional
    • standard applications
    • battery; 802.11
    P erformance /Weight/Power Consumption Sensors, embedded controllers
    • PDA phone
    • data
    • simpler graphical displays
    • 802.11/3G
  • Challenge 5: Changing Regulation and Multiple Communication Standards cellular phones satellites wireless LAN cordless phones 1992: GSM 1994: DCS 1800 2001: IMT-2000 1987: CT1+ 1982: Inmarsat-A 1992: Inmarsat-B Inmarsat-M 1998: Iridium 1989: CT 2 1991: 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: CT0 1984: CT1 1983: AMPS 1993: PDC 2000: GPRS 2000: IEEE 802.11a Fourth Generation (Internet based)
  • 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
  • Summary
    • Driven by t echnology and v ision
      • infrastructure (communication/location)
      • d evice miniaturization
      • mobile computing platforms
    • The f ield is m oving f ast and has many opportunities
  • Backup Slides on Cooperation
  • Backup Slides on Sync/Replicate Management
  • Discussion
    • What challenges does the file system face in wireless/mobile environment?
  • 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
  • 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
  • SEER: automatic prediction of related files to avoid user manual configuration of hoarding
  • SEER: A Predictive Hoarding System
    • View s 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?
  • Basic Idea of SEER: Semantic Distance
    • Q uantif ies user’s intuition about relationship between files
      • smaller  closer in relation
    • Infers relationship
      • static (d one by an external investigator ), e.g.,
        • observes directory structure/membership
        • observes naming convention
        • #include in a program
      • dynamic
        • w atches user’s behavior
  • Lifetime Semantic Distance
    • L ooks 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
      • need s distance between two files, not events
      • u se s geometric mean to convert to a single distance
    Semantic distance - A  B , A  C is 0 - A  D is 3 A B C D Time Sample file access sequence
  • Basic Idea of SEER: Clustering Algorithm
    • Based on algorithm by Jarvis and Patrick
    • Allows overlapping clusters
    • Steps
      • c alculate s n nearest neighbors for each file
      • Phase 1 : i f two points (files here) have at least kn overlapping neighbors, combine their clusters into one
      • Phase 2 : i f two points have more than kf but less than kn overlapping neighbors, overlap the clusters i.e . add each to the other cluster
    Summary of clustering algorithm Relation Action kn ≤ x kf≤ x<kn x<kf Combine clusters Overlapping clusters No action
  • Example
    • Seven files , A-G
      • {A} {B} {C} {D} {E} {F} {G}
    • P hase 1 :
      • {A, B}  {A, B, C}
      • {D, E} {F, G}  {D,E,F, G}
    • P hase 2 :
    • two pairs {A, C} {C, D}
    • {A, C} : same cluster already
    • {C, D}  overlap clusters
    • Final r esult
      • {A, B, C, D} {C,D, E, F,G}
    Number of s hared neighbors From To A B C D E F G A B C D E F G kn kf kn kf kn kn kn
  • Using Both Lifetime Semantic Distance and the Input of External Investigator
    • Essentially gives application specific info
    • Example
      • large directory distance => looser relationship
        • s ubtract directory distance from shared neighbor count
  • Real W orld A nomalies: S pecial C ases
    • Many special cases
      • a uthors use a heuristic to solve each
    • Shared libraries
      • e. g . : library X
      • m ight cause unwanted clustering
      • H euristic : files which represent more than a certain percentage of all references marked as “frequently-referenced” (1%)
        • e liminate from calculation
    • Critical files (e . g . : startup files)
      • r arely accessed but important
      • u se heuristic and hoard
        • s pecial control file that specifies such files
        • d etect by names e. g . .login etc
    • Temporary files (e . g . : in /tmp)
      • t ransient and don’t depict correct relationship
      • m ight displace other important files from n closest
      • h euristic: i gnore files in /tmp etc. completely
    • Simultaneous access
      • e. g . : read mail & compile code
      • i ndependent streams are intermixed !
      • m aintain reference-history on a per-process basis
    More Special Cases …
  • Scheduling of Multimedia Applications
    • Earliest deadline first (EDF) scheduling
      • - a llocate cycle budget per job
      • - e xecute job with earliest deadline and positive budget
      • - c harge budget by number of cycles consumed
      • - p reempt if budget is exhausted
  • Bayou: automatic conflict update
  • Bayou: Managing Update Conflicts
    • Basic idea: application specific conflict detection and update
    • Two mechanisms for automatic conflict detection and resolution
      • dependency check
      • merge procedure
  • Bayou Write Operation: An Example
  • Mobile file systems: dealing with low bandwidth: LBFS: efficient file comparison and merging
  • 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)?
  • LBFS: Low-Bandwidth File System
    • Break Files into chunks and transfer only modified chunks
    • Fixed chunk size does not work well
      • why?
  • 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
  • What is data synchronization?
    • Data synchronization “is the process of making two sets of data look identical” (source: syncml.org white paper)
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Data Synchronization Session # 1481 - Copyright 2002 Sean C. Sullivan Datastore2 Datastore1 A C B C A B A C B
    • Exchange data modifications
    • Resolve conflicts
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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)
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML sponsors Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML features
    • Synchronize any type of data
    • Multiple protocol bindings
      • HTTP, WSP, OBEX
    • Security
    • Interoperability
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML: clients & servers Session # 1481 - Copyright 2002 Sean C. Sullivan SyncML server client modifications server modifications
  • SyncML synchronization types
    • Two-way sync
    • Slow sync
    • One-way sync from client only
    • Refresh sync from client only
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML synchronization types (cont.)
    • One-way sync from server only
    • Refresh sync from server only
    • Server alerted sync
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML terminology
    • Message
    • Package
    • Command
    • Status code
    Session # 1481 - Copyright 2002 Sean C. Sullivan
    • Datastore
    • Device info
    • Meta info
    • Capabilities exchange
  • SyncML and XML
    • Abbreviated naming convention
      • Ex: ”protocol version” is <VerProto>
    • XML prolog is not required
    • WBXML
      • WAP B inary XML
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML documents
    • <SyncML> DTD
    • Meta info DTD
    • Device info DTD
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • <SyncML> document
    • <?xml version=&quot;1.0&quot;?>
    • <!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)
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • <SyncHdr> element
    • <SyncHdr>
    • <VerDTD>1.0</VerDTD>
    • <VerProto>SyncML/1.0</VerProto>
    • <SessionID>session41</SessionID>
    • <MsgID>msg80386</MsgID>
    • </SyncHdr>
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • <SyncBody> element
    • <SyncBody>
    • <Add>
    • <CmdID>cmd80486</CmdID>
    • <Item>…</Item>
    • </Add>
    • </SyncBody>
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • SyncML commands
    • <Add>
    • <Alert>
    • <Atomic>
    • <Copy>
    • <Delete>
    • <Exec>
    • <Get>
    • <Map>
    Session # 1481 - Copyright 2002 Sean C. Sullivan
    • <Put>
    • <Replace>
    • <Results>
    • <Search>
    • <Sequence>
    • <Status>
    • <Sync>
  • Meta Info document
    • Contains sync session parameters
    • <MetInf>
    • <Format>…</Format>
    • <Type>…</Type>
    • <MaxMsgSize>586
    • </MaxMsgSize>
    • </MetInf>
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Device Info document
    • Describes device capabilities
    • For both client and server
    • <DevInf>
    • <SwV>0.99</SwV>
    • <HwV>3.14</HwV>
    • <DevTyp>pda</DevTyp>
    • </DevInf>
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j project
    • Java implementation of SyncML protocol
    • Sync4j client
    • Sync4j server
    • open source
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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 - ?
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j’s modular design
    • “ core” protocol message library
    • transport protocol libraries
    • extensible client framework
    • extensible server framework
    • client application
    • server application
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j implementation
    • Immutable objects
    • Exception class for each SyncML “status code”
    • Declaration of constants
      • public final static variables
    • Command object hierarchy
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j command hierarchy Session # 1481 - Copyright 2002 Sean C. Sullivan AbstractCommand ResponseCommand RequestCommand AddCommand, DeleteCommand, ReplaceCommand, … ResultsCommand, StatusCommand
  • Sync4j toolset
    • Jakarta Ant
    • JDOM
    • Apache Xerces-J
    • CVS
    • log4j
    • Sun JDK 1.4.0
    • Sun J2EE SDK
    • JUnit
    • Apache Tomcat
    • Netbeans
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j packages
    • sync4j.core
    • sync4j.transport
    • sync4j.framework
    Session # 1481 - Copyright 2002 Sean C. Sullivan
    • sync4j.client
    • sync4j.server
    • sync4j.tests
  • Sync4j core classes
    • Message
    • DeviceInfo
    • MetaInfo
    • Command classes:
      • AddCommand
      • DeleteCommand
      • ReplaceCommand
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • sync4j.core.Message
    • Two ways to construct a Message object:
      • from a String of XML
      • from more basic sync4j objects
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j Message example 1
    • String strXML = “<SyncML> … </SyncML>”;
    • Message msg;
    • try
    • {
    • msg = new Message(strXML);
    • }
    • catch (InvalidMarkupException ex)
    • {
    • }
    • catch (XMLSyntaxException ex)
    • {
    • }
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • Sync4j Message example 2
    • SyncHeader header = new SyncHeader(...);
    • SyncBody body = new SyncBody(...);
    • Message msg;
    • msg = new Message(header, body);
    • String strXML = msg.toXML();
    Session # 1481 - Copyright 2002 Sean C. Sullivan
  • 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
    Session # 1481 - Copyright 2002 Sean C. Sullivan End
  • For more information… Session # 1481 - Copyright 2002 Sean C. Sullivan End Please visit http://sync4j.sourceforge.net/
  • Backup Slides on TELA
  • TELSA: A Positive Example
  • 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
  • TESLA
    • T imed E fficient S tream L oss-tolerant A uthentication
    • Uses only symmetric cryptography
  • Basic Authentication Mechanism
    • F: public one-way function; MAC: message digest function
    t F( K ) Authentic Commitment P MAC( K ,P) K disclosed 1: Verify K 2: Verify MAC 3: P Authentic!
  • 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
  • TESLA: Example K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7 K3 Keys disclosed 2 time intervals after use P5 K5 P3 K3 P2 K2 P1 K2 Verify MACs P4 K4 F F Authenticate K3
  • TESLA Summary
    • Advantages
      • low overhead
        • communication (~ 20 bytes)
        • computation (~ 1 MAC computation per packet)
      • tolerate packet loss
    • Problems
      • time synchronization
      • delayed authentication
  • 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
  • SEAD Metric Authenticators
    • Each node generates a hash chain and distributes the last element (C N+1 ) to allow verification:
      • chain values C N-k+1 , …, C N authenticate metrics 0 through k-1 for sequence number 1
      • C N-2k+1 ,…C N-k authenticate metrics 0 through k-1 for sequence number 2
      • C N-ik+1 ,…C N-(i-1)k authenticate metrics 0 through k-1 for sequence number i
    C 0 C 1 C 3 C 2 C 5 C 4 C 6 C 7 C 9 C 8 C 10 C 12 C 11
  • SEAD Metric Authenticators
    • Each node generates a hash chain and distributes the last element (C N+1 ) to allow verification:
      • Chain values C N-k+1 , …, C N authenticate metrics 0 through k-1 for sequence number 1
      • C N-2k+1 ,…C N-k authenticate metrics 0 through k-1 for sequence number 2
      • C N-ik+1 ,…C N-(i-1)k authenticate metrics 0 through k-1 for sequence number i
    C 0 C 1 C 3 C 2 C 5 C 4 C 6 C 7 C 9 C 8 C 10 C 12 C 11
  • SEAD Metric Authenticators
    • Each node generates a hash chain and distributes the last element (C N+1 ) to allow verification:
      • Chain values C N-k+1 , …, C N authenticate metrics 0 through k-1 for sequence number 1
      • C N-2k+1 ,…C N-k authenticate metrics 0 through k-1 for sequence number 2
      • C N-ik+1 ,…C N-(i-1)k authenticate metrics 0 through k-1 for sequence number i
    C 0 C 1 C 3 C 2 C 5 C 4 C 6 C 7 C 9 C 8 C 10 C 12 C 11
    • Each node generates a hash chain and distributes the last element (C N+1 ) to allow verification:
      • Chain values C N-k+1 , …, C N authenticate metrics 0 through k-1 for sequence number 1
      • C N-2k+1 ,…C N-k authenticate metrics 0 through k-1 for sequence number 2
      • C N-ik+1 ,…C N-(i-1)k authenticate metrics 0 through k-1 for sequence number i
    SEAD Metric Authenticators C 0 C 1 C 3 C 2 C 5 C 4 C 6 C 7 C 9 C 8 C 10 C 12 C 11
  • SEAD Metric Authenticators
    • Within a sequence number i:
    • C N-ik+ 1 represents metric 0
    • C N-ik+ 2 represents metric 1
    • C N-ik+ m+1 represents metric m
    • C N-ik+ k represents metric k-1
    C 9 C 10 C 11 Metric 0 Metric 1 Metric 2
    • When 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