Upload
vichhaiy-serey
View
60
Download
2
Embed Size (px)
Citation preview
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