Versatile Protection for Smartphone

Presenter: Vichhaiy, 5938445

Professor: Vasaka

1

Introduction

Paranoid Android Architecture

Implementation

Evaluation

Conclusion

Reference

Q&A

2

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

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

Figure 1: Paranoid Android architecture overview

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

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

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

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

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

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

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%

They suggest to implement tracer within kernel to reduce the power consumption

14

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

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

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

http://www.cs.vu.nl/~herbertb/papers/trpa10.pdf

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

18

19