Transcript Vulnerability Evaluation for Securely Offloading Mobile Apps in the Cloud He Zhu, Changcheng Huang and James Yan Department of Systems and Computer Engineering, Carleton.

Vulnerability Evaluation for Securely
Offloading Mobile Apps in the Cloud
He Zhu, Changcheng Huang and James Yan
Department of Systems and Computer Engineering,
Carleton University
1
Outline
• Motivation
• Challenges
• Our contribution
• Object Dependency Graph (ODG)
• Vulnerability
• Experimental results
• Conclusion
2
Motivation
• Mobile devices are limited in computing resources and power
• Datacenter has virtually unlimited resources
• Cheaper
• Higher availability
• Elastic resources
• Divide mobile applications into components
• Offloading some components into cloud
• Keep remaining components in mobile devices
• Issues
• Which components to offload
3
Current offloading schemes
• Only consider the constrained resources on mobile platforms
• Target higher computing power and lower energy cost
• CloneCloud[1]: A mobile app partitioning system
• Optimizing execution time and energy use
• ThinkAir [2]: A framework to migrate smartphone apps to the cloud.
• Parallelizing method execution using multiple VM images
• Less phone-side energy consumption and shorter execution time
• Lack of consideration for security when offloading apps
[1] B. G. Chun, S. Ihm, P. Maniatis, M. Naik and A. Patti, "Clonecloud: elastic execution
between mobile device and cloud," In Proceedings of the sixth conference on computer
systems, ACM, 2011.
[2] S. Kosta, A. Aucinas, P. Hui, R. Mortier and X. Zhang, "Thinkair: Dynamic resource
allocation and parallel execution in the cloud for mobile code offloading," In Proceedings
of IEEE INFOCOM, 2012.
4
Security risks for offloading apps
• Datacenter is a shared
environment
• Isolation not strong enough
• Data breach and data loss
• Malicious insiders
• Hackers
Alice
• Applications can be attacked
• Service traffic hijacking
• DoS
Hacker
Malicious
insider
5
Outstanding issues
• Approach based encryption
• Computation overhead
• Only applicable to data
• Running code vulnerable in shared environment
• Lack of analytical model for evaluating vulnerabilities of app
parts for distributed applications.
• Lack of algorithm to offload securely
• Lack of practical systems for securely offloading app
parts into the cloud
6
Challenges for secure offloading
• Complex call relationships of classes and functions within an
app make it difficult to highlight vulnerable parts
• Hard to determine the level of protection for the parts to
choose between security and performance
• No mature systems have been built to break down and
offload apps.
7
Our approach
• Divide an app into multiple parts, aka objects
• Connect objects by their dependencies
• Build an Object Dependency Graph (ODG)
• Identify the sources causing vulnerability
• Calculate how vulnerability can propagate from one object to
another object
• Evaluate the impact of each object
• Optimize offloading based on vulnerability threshold and
resource usage
8
The definition of Objects
• Objects in a running app as the basic units for analysis
• Instantiated from encapsulated class definitions
• Consistent with the definition in Object-Oriented
Programming (OOP)
• Local object
• An object running on the local smartphone
• Remote object
• An object running in the cloud
• Two objects may have dependencies on each other
Object
Object
Dependency
9
Forms of object dependencies
• There are two forms of object dependencies
• Call relationship
• Message Passing
• Call relationship is established by local method invocation
between local objects.
Call relationship
Local Object
Local Object
• Message passing is done by remote service invocation if at
least one side is a remote object.
Local Object
Message
passing
Remote Object
Message
Remote Object
passing
10
Vulnerability
• Definition
• The probability an object will be compromised
• Many sources
• Unsafe environment such as datacenter
• Dependency between objects
• Cloud-originated vulnerability
• Incurred through indirect interactions with cloud
• Caused by shared environment such side channel or DoS
• Propagated vulnerability
• Incurred through direct interactions
• Dependency between objects
• Focus of this paper
11
The cloud-originated vulnerability
•
•
•
•
Many possible sources
Treated as the self-originated vulnerability
Can be obtained through statistics or reputation system
Out of the scope of this paper
Obj
Memory/CPU Cache leaks
Side/Covert channels
Designated backdoors
…
Cloud Environment
12
The propagated vulnerability
• Object dependencies lead to the propagation of
vulnerabilities
• Defined as the probability that an attack originates from one
compromised object to another object through call
relationships or message passing.
Object
Dependency
Dependency
Attack
Object
Attack
Attack
Object
Object
Dependency
Cloud Environment
13
Modeling with Object Dependency Graph
(ODG)
• The ODG is an undirected graph 𝔾 = (𝕍, 𝔼) for the app where
• All objects in an app as a set of vertices 𝕍
• All dependencies as a set of undirected edges 𝔼
• For the example ODG below:
• 𝕍 = {𝑣1 , 𝑣2 , 𝑣3 , 𝑣4 }
• 𝔼 = {𝑒12 , 𝑒13 , 𝑒23 , 𝑒34 }
v1
e12
v2
e13
e23
v3
v4
e34
14
Minimal path set
𝑀
1
2
• Denoted by 𝑅𝑜𝑑 = 𝑟𝑜𝑑
, 𝑟𝑜𝑑
, … , 𝑟𝑜𝑑𝑜𝑑 , is the set of all minimal
paths.
• Minimal path: a set of edges that comprise a path, but the removal
of any one edge will cause the resulting set not to be a path.
Compromised
object
x
o
LEGENDS
d
y
rod1
rod2
rod3
rod4
15
Minimal cut set
𝐷
1
2
• Denoted by 𝐶𝑜𝑑 = 𝐶𝑜𝑑
, 𝐶𝑜𝑑
, … , 𝐶𝑜𝑑𝑜𝑑 , is the set of minimal cuts
from the source to the destination object.
• The minimal cut sets can be found via the CARA algorithm originally
used in the fault tree.
x
Compromised
object
o
d
cod1
cod2
y
cod4
cod3
16
Lower bound of vulnerability
• Attacks will propagate if and only if all minimum cuts have at
least one edge propagates attacks
• Define
𝑖
• 𝑈𝑜𝑑
=
𝑎𝑡 𝑙𝑒𝑎𝑠𝑡 𝑜𝑛𝑒 𝑒𝑑𝑔𝑒 𝑖𝑛 𝑡ℎ𝑒 𝑖 𝑡ℎ 𝑚𝑖𝑚𝑢𝑛𝑢𝑚 𝑐𝑢𝑡 𝑝𝑟𝑜𝑝𝑎𝑔𝑎𝑡𝑒𝑠 𝑎𝑛 𝑎𝑡𝑡𝑎𝑐𝑘
• There are 𝐷𝑜𝑑 minimum cuts
𝐷
1
2
• 𝑝𝑜𝑑 = 𝑃 𝑈𝑜𝑑
𝑈𝑜𝑑
… 𝑈𝑜𝑑𝑜𝑑 ≥
𝐷𝑜𝑑
𝑖=1 𝑃
𝑖
𝑈𝑜𝑑
17
Upper bound of vulnerability
• Attacks from o to d would not be possible if and only if none
of the minimum paths propagate attacks
• Define
𝑗
• 𝑊𝑜𝑑 =
𝑎𝑡 𝑙𝑒𝑎𝑠𝑡 𝑜𝑛𝑒 𝑒𝑑𝑔𝑒 𝑖𝑛 𝑡ℎ𝑒 𝑗 𝑡ℎ 𝑚𝑖𝑛𝑖𝑚𝑢𝑚 𝑝𝑎𝑡ℎ 𝑑𝑜𝑒𝑠 𝑛𝑜𝑡 𝑝𝑟𝑜𝑝𝑎𝑔𝑎𝑡𝑒 𝑎𝑡𝑡𝑎𝑐𝑘𝑠
• There are 𝑀𝑜𝑑 minimum paths
𝑀
1
2
• 1 − 𝑝𝑜𝑑 = 𝑃 𝑊𝑜𝑑
𝑊𝑜𝑑
… 𝑊𝑜𝑑𝑜𝑑 ≥
𝑀𝑜𝑑
𝑗=1 𝑃
𝑗
𝑊𝑜𝑑
18
The bounds of the propagated vulnerability
and the algorithm
Algorithm 1 Propagated Vulnerability Algorithm
• Bounds for the propagated
vulnerability (𝑝𝑒 is the propagated
vulnerability of the edge e):
1
2
3
function pva(o, d):
upperBound = 1
4
5
6
for each edge e1 in p1 do
7
8
end for
9
10
end for
11
• Algorithm implementation
shown in Algorithm 1.
• Input: the ODG topology
• Output: bounds of the
propagated vulnerability
12
13
14
15
for each edge e2 in p2 do
16
17
end for
18
19
20
21
end for
return result
end function
19
The impact of a compromised object
• Simply keeping an object with highest vulnerability on the local
device is not necessarily safer
• Staying locally does not reduce the propagated vulnerability
• Our choice: keep the object o generating the greatest impact on
other nodes in mobile devices:
• Absolute impact: the difference between the vulnerability of each
object with and without 𝑜 being compromised in the ODG
• Relative impact: absolute impact divided by the vulnerability of the
object affected.
• Impact factor: the average relative impact for all objects in ODG
20
Evaluation and numerical results
• Three open-source sample applications:
• TrendCraw fetches news feeds from the Internet periodically, and then
displays the contents to users.
• MyExpense manages the daily expense of the user. It does not have
network-related actions.
• iMetro provides subway maps and station schedules of cities all over the
world. It downloads subway information from the Internet according to
users' selection.
packages written specifically
for the apps
App Name
TrendCraw
MyExpense
iMetro
imported from
other libraries
From Original Packages
Imported
Packages
Classes Activities Packages
2
9
3
183
3
24
11
194
22
145
20
192
21
ODG simplification
• Assume that impacts of imported packages are merged into cloudoriginated vulnerabilities
• Focus on a relatively smaller number of objects
• Does not lose generality with the assumption that imported packages
have been analyzed and account for cloud-originated vulnerabilities.
• Significantly reduced the time for analysis
22
Experiment process
Original Source
Code
Modify
Code with Logging
Support
Compile
Cloud
ODG-enhanced APKs
Upload
ODG Support
Library
ODG-related logs
*APK: The file format of android installation package
• With the ODG support library, the apks can be converted to support
ODG-related logging.
• After uploading the logs to the cloud, the analysis will return the
offloading decision to the smartphone.
23
200
0…
0…
0…
0
0.1 0.3
0.5
0.7
0.9
Cloud-originated Vulnerability (α)
600
400
200
0.6
0
0.1 0.3 0.5
0.7 0.9
Cloud-originated Vulnerability (α)
RenderProgram
RenderStation
40
One-hop Neighbor
35
Two-hop Neighbor
30
Object Count
25
20
15
10
5
0
RenderProgram
RenderStation
0.1
RenderStationName
1000
800
600
400
200
Propagated Vulnerability (β)
400
800
Object Vulnerability (π) × 1000
600
1000
Propagated Vulnerability (β)
800
Object Vulnerability (π) × 1000
1000
Propagated Vulnerability (β)
Object Vulnerability (π) × 1000
Impact of system-wide vulnerability change
0.6
0
0.1 0.3 0.5
0.7 0.9
0.1
Cloud-originated Vulnerability (α)
RenderStationName
• From the figures, the vulnerability of
RenderProgram increased much faster
than the other two objects
• The one- and two-hop neighbors of
RenderProgram are much more than the
other two objects.
• The objects with larger number of
neighbors, including one- and two-hop
neighbors, tend to have higher
vulnerabilities
24
Phone-side energy cost
• Models compared with existing offloading mechanisms which only
consider energy consumption and performance:
• CloneCloud (CCD)
• ThinkAir (TAR)
• ODG
• Compare normalized phone-side energy cost with the three
offloading schemes under different percentages of objects offloaded.
Normalized Phone-side Energy Cost
(%)
100
CCD-Trend
90
TAR-Trend
80
ODG-Trend
70
CCD-iMetro
TAR-iMetro
60
ODG-iMetro
50
CCDMyExpense
TAR-MyExpense
40
30
0
2
4
6
Objects Offloaded (%)
8
10
12
14
25
Vulnerable objects accessible by the cloud
Number of Vulnerable Objects in the cloud
40
CCD-Trend
35
TAR-Trend
30
ODG-Trend
25
CCD-iMetro
20
TAR-iMetro
15
ODG-iMetro
10
CCD-MyExpense
TAR-MyExpense
5
ODG-MyExpense
0
0
2
4
6
8
10
Objects Offloaded to the cloud (%)
12
14
• The numbers of objects with more vulnerability impact
accessible by the cloud are less exposed to the cloud for ODG.
26
Conclusion
• Introduced ODG based vulnerability model
• An algorithm to offload based on vulnerability level and
resource usage.
• Experimental results show meeting security requirements
while minimize mobile resource usage
• Vulnerability depends on the topology of ODG
27
Thank you!
Questions?
28