Vulnerability Evaluation for Securely Offloading Mobile Apps in the CloudHe Zhu, Changcheng Huang and James YanDepartment 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

• Applications can be attacked• Service traffic hijacking • DoS

Alice

Hacker

Malicious insider

5

• 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

Outstanding issues

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

9Object Object

Dependency

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.

• Message passing is done by remote service invocation if at least one side is a remote object.

10

Local Object Local ObjectCall relationship

Message passingLocal Object Remote Object Remote Object

Message passing

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

12

Obj

Memory/CPU Cache leaksSide/Covert channels

Cloud Environment

Designated backdoors…

Vulnerability due to

interaction with cloud

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.

13Cloud Environment

Object

Object

Dependency

Object

DependencyObject

Dependency Attack Attack Attack

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:

14

v1

v2

v3v4

e12

e13 e23

e34

Minimal path set• 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.

15

o

y

d

xrod

1

rod2

rod3

rod4

LEGENDSCompromised

object

Minimal cut set

• 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.

16

o

y

d

x

cod1

cod2 cod

3

cod4

Compromised object

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

17

• 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

•

18

Upper bound of vulnerability

The bounds of the propagated vulnerability and the algorithm

19

Algorithm 1 Propagated Vulnerability Algorithm1 function pva(o, d):2 upperBound = 13

4

5 for each edge e1 in p1 do6

7 end for8

9 end for10

11

12

13

14 for each edge e2 in p2 do15

16 end for17

18 end for19

20 return result21 end function

• Bounds for the propagated vulnerability ( is the propagated vulnerability of the edge e):

• Algorithm implementation shown in Algorithm 1.• Input: the ODG

topology• Output: bounds of the

propagated vulnerability

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.

21

App NameFrom Original Packages

Imported PackagesPackages Classes Activities

TrendCraw 2 9 3 183

MyExpense 3 24 11 194

iMetro 22 145 20 192

packages written specifically for the apps

imported from other libraries

ODG simplification

• Assume that impacts of imported packages are merged into cloud-originated 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 analysis22

Experiment process

23

Original Source Code

ODG Support Library

Code with Logging Support

ODG-enhanced APKs

ODG-related logs

Cloud

Compile

Upload

Modify

• 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.

*APK: The file format of android installation package

Impact of system-wide vulnerability change

24

0

200

400

600

800

1000

0.1

0.5

0.9

Cloud-originated Vulnerability (α)

Ob

ject

Vu

lner

abil

ity

(π

) ×

10

00

Pro

pag

ated

Vu

lner

abil

ity

(β

)0

200

400

600

800

1000

0.10.5

0.9

Cloud-originated Vulnerability (α)O

bje

ct V

uln

erab

ilit

y

(π)

× 1

00

0

Pro

pag

ated

Vu

lner

abil

ity

(β

)

0

200

400

600

800

1000

0.10.5

0.9

Cloud-originated Vulnerability (α)

Ob

ject

Vu

lner

abil

ity

(π

) ×

10

00

Pro

pag

ated

Vu

lner

abil

ity

(β

)

• 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

0

5

10

15

20

25

30

35

40

One-hop Neighbor

Two-hop Neighbor

Object Count

RenderProgram RenderStation RenderStationName

RenderProgram RenderStationNameRenderStation

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.

25

0 2 4 6 8 10 12 1430

40

50

60

70

80

90

100CCD-Trend

TAR-Trend

ODG-Trend

CCD-iMetro

TAR-iMetro

ODG-iMetro

CCD-My-Expense

TAR-My-Expense

ODG-My-Expense

Objects Offloaded (%)

Nor

mal

ized

Ph

one-

sid

e E

ner

gy C

ost

(%)

Vulnerable objects accessible by the cloud

• The numbers of objects with more vulnerability impact accessible by the cloud are less exposed to the cloud for ODG.

26

0 2 4 6 8 10 12 140

5

10

15

20

25

30

35

40

CCD-Trend

TAR-Trend

ODG-Trend

CCD-iMetro

TAR-iMetro

ODG-iMetro

CCD-MyExpense

TAR-MyExpense

ODG-MyExpense

Objects Offloaded to the cloud (%)

Num

ber

of V

ulne

rabl

e O

bjec

ts in

the

clou

d

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