Paranoid Android: Versa2le Protec2on For Smartphones

Paranoid Android: Versa.le Protec.on For Smartphones Georgios Portokalidis Joined work with: Philip Homburg and Herbert Bos/Vrije Universiteit Amsterdam, The Netherlands Kostas Anagnostakis/Niometrics R&D, Singapore Why Protect Smartphones? •  They are used to: –  Do things we used to do with computers –  Store sensi.ve data –  Perform calls –  As e-­‐wallets •  They include various sensors (GPS, accelerometer, compass, etc.) •  Large codebases, and many users 12/10/10 ACSAC 2010 2 Can We Use Exis.ng Solu.ons? •  Network intrusion detec.on and preven.on –  Smartphones are highly mobile and connected (3G, WiFi, Bluetooth, IR) •  Firewalls –  Client-­‐side bugs, and malicious downloads •  Host anomaly detec.on –  Consumes resources, inaccurate •  An.virus scanners –  Consumes resources, slow, inaccurate 12/10/10 ACSAC 2010 3 Our Goals •  Create a mechanism that enables mul.faceted security with fixed overhead –  Including support for heavyweight mechanisms like dynamic taint analysis (DTA) •  Enable backup and recovery of device data •  AZackers cannot disable the checks •  Determine if such an architecture is efficient for applica.on on smartphones 12/10/10 ACSAC 2010 4 Our Approach …. •  Faithfully replicate smartphone execu.on in remote servers •  Apply security checks on replicas 12/10/10 ACSAC 2010 5 Recording and Replaying in a Nutshell •  Record nondeterminis.c inputs •  Use a network proxy to avoid recording incoming data •  Compress recorded data •  Transmit data to replica •  Replay recorded inputs at the replica 12/10/10 ACSAC 2010 6 Synchroniza.on •  Issues: –  Transmi`ng data requires power –  Connec.vity can be lost •  Opportunis.c data transmission to server •  Data are stored on the device –  We use tamper-­‐evident storage based on rolling hashes: key′= HASH(key)
12/10/10 ACSAC 2010 7 Security Server •  We can apply any detec.on technique that does not interfere with the replicated execu.on –  System call profiling, file scanning, DTA, etc. •  The same as applying the check on the device •  Checks can be added transparently •  A server can host mul.ple replicas 12/10/10 ACSAC 2010 8 Marvin: A Paranoid Android Prototype •  Plaeorm –  Android OS 1.6 –  HTC G1 developer phone •  User space implementa.on –  Rapid prototyping –  Portable –  Using ptrace() 12/10/10 ACSAC 2010 9 Implementa.on Issues •  Scheduling and shared memory –  We use determinis.c scheduling –  Alterna.ves •  Kernel space determinis.c scheduling •  Concurrent-­‐read-­‐exclusive-­‐write (CREW) protocol •  IOCTLS –  Used exis.ng descrip.ons from the QEMU user space emulator –  Manually added Android related ones 12/10/10 ACSAC 2010 10 Security Server •  Replica hosted on Android QEMU emulator •  File scanning using ClamAV Applica.ons –  Detects viruses stored in the file system •  DTA-­‐enabled QEMU Android OS QEMU emulator –  Detects memory corrup.on aZacks 12/10/10 ACSAC 2010 11 Data Genera.on Rate for Various Tasks 64B/s 12/10/10 121B/s Data generated by various tasks 12 Performance •  Idle opera.on and performing calls –  CPU load and baZery life are not affected •  During intensive usage like browsing –  CPU load average increased by ≈15% –  BaZery consump.on increased by ≈30% 12/10/10 ACSAC 2010 13 User Space Tracing: Lessons Learned •  Recording in user space is slow •  The recording component spends 65% of the .me receiving events from the kernel –  ptrace & waitpid •  Could a kernel space implementa.on do beZer? –  Intercep.ng the read() system call in user space is ≈25x slower than doing so in the kernel –  We are working on a kernel implementa.on 12/10/10 ACSAC 2010 14 Conclusions •  Smartphones are valuable targets, and they will be under aZack •  Current security solu.ons are not sufficient for security sensi.ve organiza.ons •  Outsourcing security is feasible, and can provide mul.faceted security 12/10/10 ACSAC 2010 15