Enhancing Web Browsing Security on Public Terminals Using Mobile Composition

1. Enhancing Web Browsing Security on Public Terminals Using Mobile Composition Richard Sharp & Anil Madhavapeddy, Roy Want & Trevor Pering ACM MobiSys’08 2008. 10. 16. Ahn Jung-Sang

2. Content • Introduction • System Overview • Security Model • Technical Details • Performance Evaluation • Conclusion

3. Introduction • Crimeware • Malicioussoftware to facilitate illegal activity • Stealing identities, Committing fraud • Key-logger, Screen-grabber • Most prevalent crimeware • Current web security model • HTTPS/SSL • Protects data when transmission between client & server • Cannot preserve data in untrusted user PC

4. Introduction • Split-Trust Browsing • Combination of 2 devices • General purpose networked PC (untrusted) • Personal trusted device • Linked together as device composition • USB, Bluetooth, Wireless, Etc.. • Security-critical operations are performed in device. • Using its display & keypad for I/O • Information entered in device cannot be read by PC • Thwarting PC-based key-loggers

5. System Overview Trusted Personal Device Untrusted PC Web Server Internet Browser RDC Agent Browser

6. System Overview • RDC (Remote Device Communication) Agent • Forward message • between web server & personal device • With encryption & decryption • Session key is known only to server & device • Crimeware on PC is unable to read • Two separate Internet connections • Not means that establish an additional Internet connection • Tunnel data between server & device over PC’s connection • Assumption • Web applications have been written explicitly to support split-trust browsing

7. Security Model • Threat Model • Attacker’s motivation: to steal information • Passive monitoring attacks: recording everything from PC • Active injection attacks: injecting malicious data packets into PC • PC-based browser is untrustworthy • Security Policy Model • 1. Communication channel between server & device must be authenticated & encrypted. • 2. All security-sensitive form must be filled by the device. • 3. All security-sensitive information must be displayed only on the device. • 4. Web app. must not allow submission from device to be replayed. • 5. All security-critical operations must be initiated by the device.

8. Security Model • Property 5 • All security-critical operations must be initiated by the device • Example • Charlie says to Bob “Please sign the following authorization to transfer $100 from your account to Alice’s account” • But paper says only “I authorize the money transfer” • Bob signs the paper, and Charlie takes it to bank • Charlie says to cashier “Here’s the authorization to transfer all funds from Bob’s account to my account” • Text of conformation must specify fully the action being initiated.

9. Security Model • Property 4 • Web application must not allow form submission messages from device to be replayed • Must not accept data arising from the same form submission • Why? - consider the following attack • On-line banking sends a form asking to confirm money transfer • When user submits the form, the PC records submit message • Attacker may maliciously initiate another money transfer, and replay the user’s previous confirmation message to complete

10. Technical Details • Architecture • Trusted personal device: cell phone (Motorola E680) • Connected using Bluetooth • Runs a simple cHTML browser • Web browser: Firefox • RDC agent: implemented as a Firefox browser extension • Embedded message: AES-encrypted, Base64

11. Technical Details • Embedding Split-Trust in HTML • Meta tag specifies that this page contains embedded messages • Form contains hidden field that stores value attribute • The name attribute associates form field with event

12. Technical Details • RDC Agent • Run as a Firefox browser extension • Written in combination of JavaScript & XML • First checks for the meta tag • If present, uses the DOM API to check if there are any ‘rdc-’ prefixed hyperlink tag • For each hyperlink tags, an event listener is added with a callback function • Forwards its associated message to the personal device

13. Technical Details • RDC Agent • Authentication and Key Exchange • Negotiation of a session key  uses SSHv2 • diffie-hellman-group1-sha1 with RSA host keys • Start with meta tag with name=“kex-init”

14. Technical Details • Components on the Cell Phone • Crypto Layer • Cross-compiled • Open source GNU Multi-Precision Arithmetic Library (libGMP) • Open source AES implementation • cHTML browser • Unable to interface this system with phone’s built-in browser • Implemented a simple cHTML browser as a Java MIDP app. • Interfaces with Crypto layer via a loopback TCP connection

15. Technical Details • Dealing with Forms • When user clicks <a> tag • RDC forwards ‘rdc-onClick-0-msg’ to personal device. • This message contains encrypted cHTML content + form field • The phone relays message back to RDC in its HTML reponse • This triggers the RDC to poll the phone for user’s response

16. Technical Details • When user select ‘submit’ in phone’s browser • Crypto layer encrypts user input • Return it to RDC-agent in an HTTP response • RDC agent inserts it into value attribute named ‘rdc-…-response’ • Crimeware may swap the message other name • Encrypted message contains a set of (<fieldname>, <input>) • Avoiding Replay Attacks • Nonce & timestamp • Phone’s browser automatically copies this into response message • Then web application checks • It has not seen the nonce before • The response is timely

17. Performance Evaluation • Measured the latency between server and device • Message is encrypted using AES with 1024-bit key & Base64 • Message length is 850 byte • Expect that most messages are smaller than this

18. Conclusion • Crimeware is becoming a serious problem • The current web security model • Protects data as it is transmitted between server & client • But doesn’t prevent crimeware attacks in end-point client • Split-trust browsing through mobile composition • Allows users to combine their PC with trusted personal device • Security-critical operations are performed in device

19. Discussion • Mobile application is installed on the untrusted terminal • Service providers have to modify their applications • What makes a personal device trusted? • The best case is specifically designed personal device but.. • How about PDA & cell phone? • Usability issues • Links that causes new content to appear on the device • Highlighted background? • Stick the personal device on the side of PC monitor