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

2. Outline Motivation Challenges Our contribution Object Dependency Graph (ODG) Vulnerability Experimental results Conclusion 2

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

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

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

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

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

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

9. 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 9 Object Dependency

10. 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 Call relationship Message passing Local ObjectRemote Object Message passing

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

12. 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 leaks Side/Covert channels Cloud Environment Designated backdoors … Vulnerability due to interaction with cloud

13. 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. 13 Cloud Environment Object Dependency Object Dependency Object Dependency Attack

14. Modeling with Object Dependency Graph (ODG) 14 v1 v2 v3 v4 e 12 e 13 e 23 e 34

15. Minimal path set 15 o y d x r od 1 r 2 r 3 r 4 LEGENDS Compromised object

16. Minimal cut set 16 o y d x c od 1 c 2 c 3 c 4 Compromised object

17. Lower bound of vulnerability 17

18. 18 Upper bound of vulnerability

19. The bounds of the propagated vulnerability and the algorithm 19 Algorithm 1 Propagated Vulnerability Algorithm 1function pva(o, d): 2 upperBound = 1 3 4 5 for each edge e1 in p1 do 6 7 end for 8 9 10 11 12 13 14 for each edge e2 in p2 do 15 16 end for 17 18 end for 19 20 return result 21end function Algorithm implementation shown in Algorithm 1. Input: the ODG topology Output: bounds of the propagated vulnerability

20. The impact of a compromised object 20

21. 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 Name From Original Packages Imported Packages PackagesClassesActivities TrendCraw293183 MyExpense32411194 iMetro2214520192 packages written specifically for the apps imported from other libraries

22. 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 analysis 22

23. Experiment process 23 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

24. Impact of system-wide vulnerability change 24 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 RenderProgramRenderStationRenderStationName RenderProgram RenderStationName RenderStation

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

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

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

28. Thank you! Questions? 28