source paper: http://www.syssec-project.eu/m/page-media/3/paranoid-android-acsac10.pdf

1. Versatile Protection for Smartphone
Presenter: Vichhaiy, 5938445
Professor: Vasaka
1

2.  Introduction
 Paranoid Android Architecture
 Implementation
 Evaluation
 Conclusion
 Reference
 Q&A
2

3.  Smartphones:
 Do things we used to do with
computers
 Games, videos, notes…
 Store sensitive data
 Bank account, passwords…
 Perform calls
 Sensors
 GPS, Accelerometer, Compass,
Proximity , Light, Mics, Camera …
 Not like PC, where many security
approaches available
 Highly valuable target for hackers
3

4.  Experiment on Android HTC G1
 Perform a scan with ClamAV
 ~ 30 mn & consume 2% battery
 Normal file scanning apps
 11.8x slower than a single-core VM
 They propose a new model called Paranoid Android where all checks
are perform NOT on phone, but on the replica hosted on security server
in the cloud
4

5. 5
Figure 1: Paranoid Android architecture overview

6. On the smartphone:
Recorder
Tracer records all information , filters the
needed one, secures with hash (HMAC),
compress and transmit to the replayer
*synchronise: they use loose synchronization
strategy (ex. Synchronise to server only when
recharging)
*temper-evident storage: prevent alter from
hackers
6

7. On the cloud (security server)
Replayer receives the trace and replays
the execution same as on phone, then
they can apply security checks within
emulator
Security checks:
- Dynamic analysis (detect 0-day)
- AV (scan files)
- Memory scanner (abnormal code)
- System call anomaly detection
(abnormal activities)
7

8. They use a network proxy that temporarily stores traffic destined to the
phone, to reduce the amount of data the tracer needs to store and transmit to
the replica.
The replayer can later access the proxy to retrieve the data needed for the
replaying.
8

9.  This is kind of PA’s prototype implementation
 Platform:
 Android OS 1.6
 HTC G1 developer phone
 Record using linux ptrace()
 Mechanism:
 Shared memory
 Create spinlock algorithm for scheduling, ensures no two threads
that share a memory object can ever run concurrently.
 Use ioctls I/O control system, allow communication with drivers
for each request commands
9

10.  Execution Trace Compression
 Record only system call (non-deterministic)
 Use network proxy so that inbound data are not logged
 Compress data using 3 algorithms: delta encoding, Huffman
encoding, DEFLATE ( also used gzip)
 Attack Detection Mechanism
 Virus Scanner, modified version of open source ClamAV with
more than 500000 signatures
 Dynamic Taint Analysis (DTA), a powerful tool to analyze
against zero-day attack
10

11. 11

12. Figure 3: Average data generation rate, when performing various tasks. 12

13.  The volume of data generated directly affects the amount of
energy required to transmit the trace log to the server,
Figure 4: Battery level and CPU load average while browsing on the HTC G1 developer phone.
13
PA introduces 2 overheads:
- Increase CPU usage
- Consume power
 Idle operation and
performing calls
 CPU load and battery life
are not affected
 During intensive usage
like browsing
 CPU load average
increased by ~15%
 Battery consumption
increased by ~30%

14.  They suggest to implement tracer within kernel to reduce the
power consumption
14

15. Figure 5: Number of replica instances that can be run on a server without delay. As CPU
utilization increases on the phone, fewer replicas can be executing in sync with the phone.
15

16. 16
Intercepting the read() system call in user space is ~25x slower than doing so in the kernel

17.  Smartphones are valuable targets and they will be under attack
 They provide prototype of recording and replaying framework
specifically for Android
 Mechanisms for detection attacks, backup state
 Apply multiple security checks simultaneously
 They’re still working on the kernel implementation to handle
overhead
17

18.  http://www.cs.vu.nl/~herbertb/papers/trpa10.pdf
 http://www.syssec-project.eu/m/page-media/3/paranoid-
android-acsac10.pdf
18

19. 19