Paranoid Android: Versatile Protection For Smartphones

1. GeorgiosPortokalidis Columbia University Philip HomeburgVrijeUniversiteit Kostas AnagnostakisNiometris R&D Herbert BosVrijeUniversiteit Paranoid Android:Versatile Protection For Smartphones

2. Paranoid Android? Click this album to play this song …

3. Outline • Introduction • Architecture • Implementation • Evaluation • Related Work • Conclusion

4. Introduction • Recently, iPhone and Android platform have shown to be susceptible to remote exploits • Obama’s blackberry

5. Introduction • Using a file scanner or antivirus, like ClamAV • Time-consuming (30 minutes) • Battery problem (2% battery capacity) • Is 11.8x slower than running it on single-core VM • We argue for a different security model that completely devolves attack detection from the phone • Key: Cloud !

6. Introduction • Antivirus file scanning • Zero-days? Remote exploits? Memory-resident attacks? • Smartphone APIs • Android: Java Dalvik VM • But also provide native APIs • May be vulnerable to these attacks

7. Introduction • Contributions: • Multiple security checks simultaneously without overburdening the device • Execution recording and replaying framework for Android • Transparent backup of all user data in the cloud • Replication mechanism • Application transparent recording and replaying

8. Architecture • Tracer • Record all info needed to accurately replay its execution • Replayer • Receive the trace and faithfully replays the execution within the emulator • Proxy • Intercept and temporarily store inbound traffic • The replayer can access the proxy to retrieve the data needed for replaying

9. Architecture

10. Architecture • Assumptions • The replay server will not be compromised • Attackers cannot break the encryption • The device is able to contact the server safely, to create an initial replica, and setup the tracer • The servers have out-of-band channels to notify users about problems and a way to restore the image

11. Architecture • Tracer • Nondeterministic inputs and events • Mostly pass through the system calls • Record all data transferred from kernel to user space through system calls

12. Architecture • Replayer • Use the recorded values when replaying the system calls on replica • Including IPC using system calls • Only replay process and not kernel execution • May not be able to detect an attack against the kernel • But most kernel vulnerabilities are only exploitable locally • Shared memory: repeatable deterministic task scheduler

13. Architecture • Synchronisation • Loose Synchronisation • Transmit the trace only when the device is awake and connected to the Internet • User is most likely to be attacked while surfing the web • Support extremely sychronisation • Only sync when recharging

14. Architecture • Synchronisation • Tamper-Evident Secure Storage • HMAC: Hash-based Message Authentication Code • HMAC = Hash( K xoropad, Hash(K xoripad, text)) • STORE(message + HMAC(key, message)) • key’ = Hash(key) • key = key’ • If sync error, the device is treated as potentially compromised

15. Architecture • Security Methods • Dynamic analysis in emulator • Antivirus software • Memory scan • System call detection • P.S. only implement the first two

16. Architecture • Proxy and Server Location • User Notification and Recovery • Handling Data Generated On the Device • Bulk downloads • Incremental downloads

17. Implementation • Need a new boot image! • Linux ptrace • PTRACE_SYSCALL

18. Implementation • Starting The Tracer • Init starts tracer first • Next, init starts the exec stubs • The stub writes its pid to tracer’s FIFO and pauses • Then tracer attaches to the process, and continues the stub • Exec

19. Implementation • Scheduling And Shared Memory • User space Scheduler • Ensuring no two threads that share a memory object can ever run concurrently • Triggered by system call • Spinlock and mutexes • Future work • CREW protocol (concurrent-read-exclusive-write) • To track all reads from memory

20. Implementation • Ioctls • An interface between user and kernel space • /dev/binder • Handles about 200 ioctl commands

21. Implementation • Execution Trace Compression • Record only system calls that introduce nondeterminism • Use a network proxy so that inbound data are not logged in the trace • Compress data using three algorithms • Delta encoding • Huffman encoding • DEFLATE algorithm (gzip)

22. Implementation • Attack Detection Mechanisms • Virus Scanner • ClamAV • Dynamic Taint Analysis • Overhead imposed is high • Only on replica

23. Evaluation • HTC G1 with tracer • Modified QEMU for replayer

24. Evaluation

25. Evaluation • Data Volume: • 5 hours of audio playback • 22.5 MB 64B/s 121B/s

26. Evaluation • CPU loading • 15% higher • Browsing may consume up to 30% more energy

27. Evaluation • Server Scalability • Dual-Core NB • 2.26GHz P8400 + 4G RAM • Quad-Core • 2.40GHz Q6600 + 8G RAM • Amazon EC2

28. Evaluation • Dynamic Taint Analysis • X2-x2.5 slowdown • If DTA applied to all replica • Only roughly half of the instances reported in Figure5

29. Evaluation • Overhead Imposed By Ptrace • Compression (deflate_slow) consumes only 7.62% • 65% is spent in ptrace and waitpid • Solution: move to kernel

30. Evaluation

31. Related Work • Malkhi et al. • Secure execution of java applets using a remote playground • Ripley: automatically securing web 2.0 applications through replicated execution • CloudCloud • Acceleration • SmartSiren • Antivirus in smartphones

32. Related Work • VirusMeter • Kirin

33. Conclusion • Attack detection on a remote server in the cloud • No limit on the number of attack detection techniques • Transmission overhead is kept below 2.5KiBps