移动虚拟化技术与Android安全方案

移动虚拟化技术与Android安全方案移动虚拟化技术与Android安全方案1目前主要的移动安全威胁应用安全威胁金融支付威胁企业业务威胁个人应用威胁

-

游戏。。。个人隐私数据安全威胁个人隐私数据企业业务数据目前主要的移动安全威胁应用安全威胁2移动安全的两大隐患应用对应用的攻击应用对数据的攻击移动安全的两大隐患应用对应用的攻击应用对数据的攻击3终端侧主要的安全解决方法隔离

隔离

隔离应用

系统

数据虚拟化技术是终端侧实现隔离的基础技术终端侧主要的安全解决方法隔离隔离隔离应用系统数据虚4Android

虚拟化类型Hypervisor(双系统)AppWrapper(应用打包)FrameworkVirtualization(框架虚拟化)Android虚拟化类型Hypervisor(双系统)5这一刀切在哪里App

WrapperFrameworkVirtualizationHypervisor这一刀切在哪里AppWrapperFrameworkV6Hypervisor技术方案-基于CPU和内核的准虚拟化(Paravirtualization)-主要工作集中在Host

Kernel,

Guest

Kernel和HAL-应用、框架、库存Runtime基本不受影响-性能和体验良好-VM之间高度隔离-开发量大-与硬件高度相关，需针对硬件移植-VM之间资源共享困难-对硬件资源要求高

优点

缺点Hypervisor技术方案-基于CPU和内核的准虚拟-7App

Wrapper

技术方案-针对Android

App的安全封装-为App提供或替换API，提供互相隔离的服务-对操作系统要求低-无特殊硬件要求-轻量-安全性差，存在大量共用的服务和资源-App需改造或重新打包，对App兼容性差，对资源有很多限制

优点

缺点AppWrapper技术方案-针对AndroidA8Framework

Virtualization-对APP兼容性高，不需要移植-应用隔离和资源共用可以调整-对硬件无特殊要求-针对不同硬件和Android发行版仍有一些移植的工作量-HAL的资源共享和调度还有一定的工作需要做

技术方案-利用LXC，namespace等内核技术创造多个互相隔离的进程环境(namespace)-在隔离的环境分别运行服务和APP-改造HAL和服务以公用硬件资源和实现必要的namespace间通讯

优点

缺点FrameworkVirtualization-对APP兼9Hypervisor

vs

Framework

VirtualizationXen(有硬件辅助),Hypervisorkvm(有硬件辅助),HypervisorLxc(原生linux),

FrameworkVirtualizationHypervisorvsFrameworkVirtua10硬件辅助的Hypervisor模式ARMX86VMMYYvIRQ

（后期加上）YYvMMU（后期加上）YYvIOMMU（后期加上）YY硬件辅助的Hypervisor模式ARMX86VMMYYvI11硬件辅助的Hypervisor模式VMMVIRTUALMACHINE

MONITORVIROVIRTUALINTERRUPTREQUESTVMMUVIRTUALMEMORY

MANAGEMENTVIOMMUVIRTUALIO

MMU硬件辅助的Hypervisor模式VMMVIRTUALMA12硬件辅助下Hypervisor的实现原理15/7/13硬件辅助下Hypervisor的实现原理15/7/131315/7/13硬件辅助下Hypervisor的实现原理15/7/13硬件辅助下Hypervisor的实现原理14Hypervisor性能测试15/7/13BareMetal

ABare

MetalBBare

MetalAvgKVM

AKVM

BKVM

AvgKVMto

BareMetal相对裸机Xen

AXen

BXen

AvgXentoBare

MetalC-­‐Ray35.3235.3835.3535.6435.6835.660.87%36.1336.1336.132.16%POV-­‐Ray230.05229.99230.02232.74232.14232.441.04%236.33235.45235.892.49%Smallpt1601601601621621621.23%168167167.54.48%BlowGish302830243026299329902991.5-­‐1.15%283928732856-­‐5.95%DES737400073756677374833.5727066772730007271833.5-­‐1.42%685866769636676911167-­‐6.71%MD5495684952849548488824891748899.5-­‐1.33%464284687946653.5-­‐6.20%OpenSSL397.73397.63397.68394.6393.3393.95-­‐0.95%387.5389388.25-­‐2.43%7-­‐Zip124831245212467.5121961206312129.5-­‐2.79%118541190411879-­‐4.95%TimedMAFFT

Alignment7.767.87.787.787.817.7950.19%8.58.348.427.60%CLOMP3.283.293.285-­‐0.46%3.093.163.125-­‐5.60%PostMark3658367636673791385738244.11%320532053205-­‐14.41%性能降低1.85%6.31%Hypervisor性能测试15/7/13BareMeta15性能表现很好，是吧？请注意，测试所用是功能软件（如加密，解密等。请看下边性能表现很好，是吧？请看下边16一个虚拟网卡的IRQ性能测试一个虚拟网卡的IRQ性能测试17分析在所有硬件辅助都已经使用的情况下，网络中断响应能力已经下降50%核心是:

I/O若存在大量的设备I/O性能会更加劣化分析在所有硬件辅助都已经使用的情况下，网络中断响应能力已经18移动虚拟化技术交互是移动设备的核心，所以,

存在大量的

I/O.所以我们现在选择

lxc,不是kvm,

不是xen移动虚拟化技术交互是移动设备的核心，19结构示意appframeworklibHALappframeworklibHALappframeworklibHALkerneldevice

namespacedevice

driverscgroupmount,net,utc,user,IPC,pidname

space用户层内核层结构示意appframeworklibHALappframe20增加device

namespace支持基于device

namespace更改设备驱动使用mount

namespce使用pid

namespace使用所有linux

kernel中存在的namespace使用cgroup控制资源而后,

我们有了containers增加devicenamespace支持2115/7/1315/7/1322我们完成了

containers控制中心,create,

start,

stop,

info,

destroy,

etc.

containers交互代理.

新的device

namespace

修改所有相关linux

kernel

device

drivers我们完成了containers控制中心,23所以，合二为一所以，合二为一24方案说明

新平台移植只需修改linux

kernel平台相关device

drive

原平台各版本的android原则上不需修改

同时启动不同版本的android需额外存储空间约330M

同时启动相同版本的android不需额外存储空间

每多启动一个android新增约170M内存

每多启动一个android性能损失约%0.1(粗测)方案说明新平台移植只需修改linuxkernel平台25测试15/7/13测试15/7/1326我们正在做向更多的手机移植我们的方案新的FOTA机制新的DDMS支持samsung

s4,

nexsus

5,

定制

手机我们正在做向更多的手机移植我们的方案27我们也许会做

ARM/KVM,

加入VFIO，以及所有设备virtIO化，到这个时候I/O

将不再成为瓶颈我们也许会做ARM/KVM,加入VFIO，以及所有设28安全吗？Hypervisor：虚拟机逃逸FrameworkVirtualization:

内核漏洞安全吗？Hypervisor：虚拟机逃逸29参考

/page/KVM_Forum_2014

/files/wpid-asplos2014-

kvm.pdf

https://major.io/2014/06/22/performance-benchmarks-kvm-vs-xen/

/images?q=tbn:ANd9GcQGOKrjfmh1sHTnTMB-H-2Y4Ry77kxfuvMImk1MKMccAsaKz0hN参考/30谢谢！谢谢！31移动虚拟化技术与Android安全方案移动虚拟化技术与Android安全方案32目前主要的移动安全威胁应用安全威胁金融支付威胁企业业务威胁个人应用威胁

-

游戏。。。个人隐私数据安全威胁个人隐私数据企业业务数据目前主要的移动安全威胁应用安全威胁33移动安全的两大隐患应用对应用的攻击应用对数据的攻击移动安全的两大隐患应用对应用的攻击应用对数据的攻击34终端侧主要的安全解决方法隔离

隔离

隔离应用

系统

数据虚拟化技术是终端侧实现隔离的基础技术终端侧主要的安全解决方法隔离隔离隔离应用系统数据虚35Android

虚拟化类型Hypervisor(双系统)AppWrapper(应用打包)FrameworkVirtualization(框架虚拟化)Android虚拟化类型Hypervisor(双系统)36这一刀切在哪里App

WrapperFrameworkVirtualizationHypervisor这一刀切在哪里AppWrapperFrameworkV37Hypervisor技术方案-基于CPU和内核的准虚拟化(Paravirtualization)-主要工作集中在Host

Kernel,

Guest

Kernel和HAL-应用、框架、库存Runtime基本不受影响-性能和体验良好-VM之间高度隔离-开发量大-与硬件高度相关，需针对硬件移植-VM之间资源共享困难-对硬件资源要求高

优点

缺点Hypervisor技术方案-基于CPU和内核的准虚拟-38App

Wrapper

技术方案-针对Android

App的安全封装-为App提供或替换API，提供互相隔离的服务-对操作系统要求低-无特殊硬件要求-轻量-安全性差，存在大量共用的服务和资源-App需改造或重新打包，对App兼容性差，对资源有很多限制

优点

缺点AppWrapper技术方案-针对AndroidA39Framework

Virtualization-对APP兼容性高，不需要移植-应用隔离和资源共用可以调整-对硬件无特殊要求-针对不同硬件和Android发行版仍有一些移植的工作量-HAL的资源共享和调度还有一定的工作需要做

技术方案-利用LXC，namespace等内核技术创造多个互相隔离的进程环境(namespace)-在隔离的环境分别运行服务和APP-改造HAL和服务以公用硬件资源和实现必要的namespace间通讯

优点

缺点FrameworkVirtualization-对APP兼40Hypervisor

vs

Framework

VirtualizationXen(有硬件辅助),Hypervisorkvm(有硬件辅助),HypervisorLxc(原生linux),

FrameworkVirtualizationHypervisorvsFrameworkVirtua41硬件辅助的Hypervisor模式ARMX86VMMYYvIRQ

（后期加上）YYvMMU（后期加上）YYvIOMMU（后期加上）YY硬件辅助的Hypervisor模式ARMX86VMMYYvI42硬件辅助的Hypervisor模式VMMVIRTUALMACHINE

MONITORVIROVIRTUALINTERRUPTREQUESTVMMUVIRTUALMEMORY

MANAGEMENTVIOMMUVIRTUALIO

MMU硬件辅助的Hypervisor模式VMMVIRTUALMA43硬件辅助下Hypervisor的实现原理15/7/13硬件辅助下Hypervisor的实现原理15/7/134415/7/13硬件辅助下Hypervisor的实现原理15/7/13硬件辅助下Hypervisor的实现原理45Hypervisor性能测试15/7/13BareMetal

ABare

MetalBBare

MetalAvgKVM

AKVM

BKVM

AvgKVMto

BareMetal相对裸机Xen

AXen

BXen

AvgXentoBare

MetalC-­‐Ray35.3235.3835.3535.6435.6835.660.87%36.1336.1336.132.16%POV-­‐Ray230.05229.99230.02232.74232.14232.441.04%236.33235.45235.892.49%Smallpt1601601601621621621.23%168167167.54.48%BlowGish302830243026299329902991.5-­‐1.15%283928732856-­‐5.95%DES737400073756677374833.5727066772730007271833.5-­‐1.42%685866769636676911167-­‐6.71%MD5495684952849548488824891748899.5-­‐1.33%464284687946653.5-­‐6.20%OpenSSL397.73397.63397.68394.6393.3393.95-­‐0.95%387.5389388.25-­‐2.43%7-­‐Zip124831245212467.5121961206312129.5-­‐2.79%118541190411879-­‐4.95%TimedMAFFT

Alignment7.767.87.787.787.817.7950.19%8.58.348.427.60%CLOMP3.283.293.285-­‐0.46%3.093.163.125-­‐5.60%PostMark3658367636673791385738244.11%320532053205-­‐14.41%性能降低1.85%6.31%Hypervisor性能测试15/7/13BareMeta46性能表现很好，是吧？请注意，测试所用是功能软件（如加密，解密等。请看下边性能表现很好，是吧？请看下边47一个虚拟网卡的IRQ性能测试一个虚拟网卡的IRQ性能测试48分析在所有硬件辅助都已经使用的情况下，网络中断响应能力已经下降50%核心是:

I/O若存在大量的设备I/O性能会更加劣化分析在所有硬件辅助都已经使用的情况下，网络中断响应能力已经49移动虚拟化技术交互是移动设备的核心，所以,

存在大量的

I/O.所以我们现在选择

lxc,不是kvm,

不是xen移动虚拟化技术交互是移动设备的核心，50结构示意appframeworklibHALappframeworklibHALappframeworklibHALkerneldevice

namespacedevice

driverscgroupmount,net,utc,user,IPC,pidname

space用户层内核层结构示意appframeworklibHALappframe51增加device

namespace支持基于device

namespace更改设备驱动使用mount

namespce使用pid

namespace使用所有linux

kernel中存在的namespace使用cgroup控制资源而后,

我们有了containers增加devicenamespace支持5215/7/1315/7/1353我们完成了

containers控制中心,create,

start,

stop,

info,

destroy,

etc.

cont