As a delegate for Tech Field Day 6 in Boston, I was introduced to VMware’s Mobile Virtualization Platform (MVP) which allows you to have a single hardened VM running within, currently, very few Android-based devices, as such requires a version of Android from VMware for the virtual machine aspect of MVP. The first version of MVP has several interesting security solutions to various security issues. Given the current spat of Android based malware, it is important to consider the security features of any new product whether it is a version 1.0 or not. Even with these issues, MVP has some very interesting uses outside the realm of a mobile phone platform. I can see this being used on tablets as well.
Security Issue #1: Since the virtual machine runs within the context of the same kernel as the standard mobile OS, it may be possible to hop from the standard mobile OS into the VM or even see traffic as it traverses into the VM.
To address this, VMware hardened the VM as well as encrypted it within the phones memory (Figure 1). This hardened and encrypted VM and its mobile OS would need to come directly from VMware as they need to inject into this version of the mobile OS paravirtualized drivers and the virtualization layer. In addition, the only way to deploy such a VM would be through an enterprise deployment model, which we were not shown during Tech Field Day 6.
Security Issue #2: Given an encrypted image it may be possible to decrypt the image at leisure?
VMware has used a higher level of encryption than normal and ensured the only way to decrypt the VM is to first be connected to the enterprise environment as the keys for the encrypted VM are not stored locally and are not directly tied to the users enterprise password used to access the VM. In addition, given the current state of Mobile forensics, VMware has also put a time limit on the life of a disconnected VM. This offline life, settable within the enterprise management tool would remove the VM after a set number of days.
Even so, it maybe possible to grab the encrypted image long before the offline lifetime and decrypt the VM using brute force and other methods using current phone forensic technologies.
Security Issue #3: Could the VM or Standard Mobile OS ease drop on a call made?
While aimed primarily at the mobile phone market, MVP would be a very handy tool for a tablet as well given their bigger screens and ease of use. The work VMware did to ensure phone functionality works within the VM would also benefit 3G enabled tablets but requires special devices that understand how to split a cell signal between the two devices. This could be achieved using two SIM cards or special carriers as the VM would have a different mobile number than the standard mobile device. Just like VLANs and NPIV (N_port ID Virtualization) for SANs. There needs to be a way to address a cell signal to two different mobile numbers within the same device.
Conclusion
VMware has thought through the security issues around MVP while choosing the path of least resistance. The secured and hardened mobile OS to use within MVP would need to come from VMware at this time, which implies that adoption of MVP by Apple users will be minimal. I just do not see Apple giving VMware direct access to iOS anytime soon. Even so, I would like such a tool for my iPad and iPhone. Hopefully one day.
Is this also a step to VMware owning the OS as well as the VM, bringing the OS into the VM as it were? I could see this as they march down the path to real cloud based applications. The real question is how responsive will VMware be to Malware and other attacks for mobile and other VM based objects?
Lastly, I would still like to see multiple VMs on mobile devices so that breaking one OS does not give any access to the underlying kernel. The current approach looks very much like vSphere 4’s version of ESXi and I still question the security of that approach. VMware may have to build both types of MVP to be acceptable to the security conscious and government organizations.
Even so, I would want to use MVP.
Comments are closed.