Remote Mobile Screen (RMS): An Approach For Secure BYOD Environments
Santiago Gimenez Ocano
Committee Members: Dr. Byrav Ramamurthy (Advisor)
Dr. David Swanson and Dr. Witawas Srisa-An
Monday, April 13, 9:00am
347 Avery Hall
Abstract
Bring Your Own Device (BYOD) is a policy where employees use their own personal mobile devices to perform work-related tasks. Enterprises reduce their costs since they do not have to purchase and provide support to the mobile devices. BYOD increases job satisfaction and productivity in the employees, as they can choose which device to use and do not need to carry two or more devices.
However, BYOD policies create an insecure environment, as the corporate network is extended and it becomes harder to protect it from attacks. In this scenario, the corporate information can be leaked, personal and corporate spaces are not separated, it becomes difficult to enforce security policies on the devices, and employees are worried about their privacy. Consequently, a secure BYOD environment must achieve the following goals: space isolation, corporate data protection, security policy enforcement, true space isolation, non-intrusiveness, and low resource consumption. We found that none of the currently available solutions achieves all of these goals.
We developed Remote Mobile Screen (RMS), a framework that meets all the goals for a secure BYOD environment. To achieve this, the enterprise provides the employee with a Virtual Machine (VM) running a mobile operating system, which is located in the enterprise network and to which the employee connects using the mobile device. We provide an implementation of RMS using commonly available software for an x86 architecture.
We address RMS challenges related to compatibility, scalability and latency. For the first challenge, we show that least 90.2% of the productivity applications from Google Play can be installed on an x86 architecture, while at least 80.4% run normally. For the second challenge, we deployed our implementation on a high-performance server and run up to 596 VMs using 216 GB of RAM. Further, we show that the number of VMs is proportional to the available RAM. For the third challenge, we used our implementation on GENI and conclude that an application latency of 150 milliseconds can be achieved.