Vulnerability Evaluation for Securely Offloading Mobile Apps in the Cloud

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

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

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

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.

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

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

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.

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

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

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

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

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

14. 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: v1 e12 v2 e13 e23 v4 v3 e34

15. 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. x r r r r 4 3 1 2 od od od od LEGENDS Compromised object o d y

16. 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. x c c c c 1 3 2 4 od od od od o d Compromised object y

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

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

19. The bounds of the propagated vulnerability and the algorithm • 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

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

21. Evaluation and numerical results • Three open-source sample applications: • TrendCrawfetches news feeds from the Internet periodically, and then displays the contents to users. • MyExpensemanages the daily expense of the user. It does not have network-related actions. • iMetroprovides subway maps and station schedules of cities all over the world. It downloads subway information from the Internet according to users' selection. imported from other libraries packages written specifically for the apps

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

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

24. Impact of system-wide vulnerability change • From the figures, the vulnerability of RenderProgramincreased 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 RenderProgram RenderStation RenderStationName RenderProgram RenderStation RenderStationName

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.

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.

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

28. Thank you!Questions?