CN106548077A - 通信***和电子设备 - Google Patents
通信***和电子设备 Download PDFInfo
- Publication number
- CN106548077A CN106548077A CN201610910915.5A CN201610910915A CN106548077A CN 106548077 A CN106548077 A CN 106548077A CN 201610910915 A CN201610910915 A CN 201610910915A CN 106548077 A CN106548077 A CN 106548077A
- Authority
- CN
- China
- Prior art keywords
- driving
- performing environment
- passage
- credible
- common
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2149—Restricted operating environment
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Storage Device Security (AREA)
Abstract
本发明涉及通信***和电子设备。尤其涉及一种用于普通执行环境与可信执行环境之间的通信的通信***,其中,通信***包括:普通执行环境和可信执行环境,其中,可信执行环境与普通执行环境隔离;在可信执行环境和普通执行环境均能够运行有操作***和应用,通信***还包括驱动划分单元,该驱动划分单元根据驱动的安全性和可用性分别将其主驱动划分到可信执行环境或普通执行环境中,并且将其虚拟驱动相应地划分到另一执行环境中。
Description
技术领域
本发明涉及一种用于普通执行环境与可信执行环境之间的通信的通信***以及应用该通信***的电子设备。
背景技术
可信执行环境TEE(Trusted Execution Environment)或者说安全运行时环境(safe runtime environment)的基本思想在于:除了普通操作***之外,提供一个与之隔离的安全操作***,并运行在一套隔离的硬件基础之上,这个安全操作***就被称为TEE。已知可以通过ARM信任区(trust zone)技术在微处理器单元中生成受保护的区域来作为TEE。该TEE被用于运行称作信任小程序(trustlet)的应用。ARM在芯片IP设计中已经全面支持了TEE,目前高通、联发科、三星、海思、展讯等都已经在硬件上支持了TEE。Intel的X86架构和Imagination的MIPS架构,也都先后推出了类似的解决方案。而这些解决方案共同存在的问题是以单通道实现在普通执行环境REE与可信执行环境TEE之间的通道,从而使得通道设计复杂,维护难度较大和通信效率低下。
发明内容
本发明要解决的技术问题是通过驱动划分实现普通执行环境与可信执行环境之间简化且效率提高的通信。
为解决该技术问题,本发明提出了一种用于普通执行环境与可信执行环境之间的通信的通信***,其中,通信***包括:普通执行环境和可信执行环境,其中,可信执行环境与普通执行环境隔离;在可信执行环境和普通执行环境均能够运行有操作***和应用,通信***还包括驱动划分单元,该驱动划分单元执行如下步骤:
评估将在通信***上运行的驱动的安全性,
如果该驱动的安全性在第一安全性阈值以上,则将该驱动的主驱动划分到可信执行环境,在普通执行环境设置该驱动的虚拟驱动;
如果该驱动的安全性在第二安全性阈值以下,则将该驱动的主驱动划分到普通执行环境,在可信执行环境设置该驱动的虚拟驱动;
如果驱动的安全性位于第一安全性阈值与第二安全性阈值之间,则检查该驱动的可用性和可实现性;
如果可用性在可用性阈值以下并且可实现性在可实现性阈值以上,则将驱动的主驱动划分到可信执行环境并且在普通执行环境设置该驱动的虚拟驱动,否则将该驱动划分到普通执行环境并且在可信执行环境设置该驱动的虚拟驱动。
在本发明的一个实施例中,驱动划分单元将DRM驱动、摄像头驱动、网络驱动、GPS驱动和存储驱动的主驱动划分到普通执行环境;和/或
将虹膜驱动中关于数据传输、数据分析的驱动的主驱动划分到可信执行环境,将虹膜驱动中的其它驱动的主驱动划分到普通执行环境;和/或
将NFC驱动的主驱动划分到普通执行环境;和/或
将指纹驱动中有关数据传输、数据分析的驱动的主驱动划分到可信执行环境,将指纹驱动中有关共享***中断发起的驱动的主驱动划分到普通执行环境;和/或
将SE驱动划分到可信执行环境;和/或
将支持可信用户接口的驱动的主驱动设置在普通执行环境以及可信执行环境。
在本发明的一个实施例中,支持可信用户接口的驱动包括LCD驱动、触摸屏驱动和I2C驱动。
在本发明的一个实施例中,普通执行环境的安全性低于可信执行环境,普通执行环境又包括安全层次Hypervisor和安全性低于Hypervisor的安全层次Container,其中,Hypervisor与Container相互隔离,驱动划分单元将划分到REE侧的驱动的主驱动分别设置到Container或者Hypervisor中。
在本发明的一个实施例中,在普通执行环境,Container和Hypervisor的环境初始化均从可信执行环境来发起和检测,其中,可信执行环境引导并初始化Hypervisor,Hypervisor再引导并初始化Container。
在本发明的一个实施例中,通信***还包括:布置在普通执行环境与可信执行环境之间的应用通道、驱动通道和调度与控制通道,其中,应用通道用于在普通执行环境和可信执行环境的应用程序之间的通信;驱动通道用于运行在普通执行环境和可信执行环境的驱动之间的通信;以及,调度与控制通道用于调度和控制命令在普通执行环境与可信执行环境之间的通信。
在本发明的一个实施例中,应用通道、驱动通道和调度与控制通道分别设置于普通执行环境与可信执行环境之间的共享内存,用于不同通道的共享内存之间相互独立。
在本发明的一个实施例中,应用通道、驱动通道和调度与控制通道各自包括正向通道和反向通道,其中,正向通道用于将普通执行环境的发送队列中的消息传送到可信执行环境的接收队列中,反向通道用于将可信执行环境的发送队列中的消息传送到普通执行环境的接收队列中。
在本发明的一个实施例中,在普通执行环境和可信执行环境各自的发送队列和接收队列中保存有待发送或所接收的消息的消息类型和消息内容,从而经由符合消息类型的通道发送或接收各个消息。
在本发明的一个实施例中,在普通执行环境能够运行有客户端应用、主驱动、虚拟驱动和/或处理器核心,在可信执行环境能够运行有可信应用、主驱动、虚拟驱动和/或处理器核心。
在本发明的一个实施例中,驱动通道构建为用于在普通执行环境与可信执行环境之间,在虚拟驱动与主驱动之间通信,以实现在普通执行环境与可信执行环境之间的驱动共享。
在本发明的一个实施例中,在普通执行环境调用特定的驱动的情况下,如果在可信执行环境存在该驱动的主驱动而在普通执行环境存在该驱动的虚拟驱动,普通执行环境调用该驱动的设置在该普通执行环境的虚拟驱动,从而触发与该驱动有关的信息经由驱动通道的正向通道被发送至可信执行环境的相应的主驱动,进而该主驱动被调用和将处理后所得的信息经由驱动通道的反向通道返回至普通执行环境的虚拟驱动,以及,在可信执行环境调用特定的驱动的情况下,如果在可信执行环境存在该驱动的虚拟驱动而在普通执行环境存在该驱动的主驱动,可信执行环境调用该驱动的设置在该可信执行环境的虚拟驱动,从而触发与该驱动有关的信息经由驱动通道的反向通道被发送至普通执行环境的相应的主驱动,进而该主驱动被调用和将处理后所得的信息经由驱动通道的正向通道返回至可信执行环境的虚拟驱动。
本发明还提出了一种电子设备,其特征在于,包括:根据本发明的通信***以及网络接口和***设备接口,其中,用户能够经由网络接口或者***设备接口获得应用并且将该应用安装于通信***,用户还能够借助通信***运行不同的应用。
通过本发明的驱动划分方式,可以根据驱动的安全性和可用性将其灵活地安置在可信运行环境或普通运行环境中,以提高运行安全性和效率。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。其中:
图1示意性地示出了一种用于REE与TEE之间的通信的多通道通信***。
图2示意性地示出了根据本发明的驱动通道的一个实施例。
图3示意性地示出了该驱动划分单元的工作流程。
图4示意性地示出了根据本发明的多通道通信***的安全层次。
图5示意性地示出了REE与TEE间的虚拟对接方式。
图6示意性地示出了根据本发明的核心调度单元的工作方式的示意图。
图7示意性地示出了根据本发明的中断控制单元的工作流程。
图8示意性地示出了根据本发明的电子设备。
为了纵览性,为相同或相当的元件贯穿所有附图地标以相同的附图标记。附图仅为示意性的,其中的元件无需合乎比例。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。
根据本发明的实施例,提出了一种用于REE与TEE之间的通信的多通道通信***。该多通道通信***包括REE和与REE隔离的TEE,在TEE和REE中均运行有操作***和应用,例如,在REE侧运行有客户端应用、主驱动、虚拟驱动和/或处理器核心,在TEE侧运行有可信应用、主驱动、虚拟驱动和/或处理器核心;还包括布置在REE与TEE之间的应用通道、驱动通道和调度与控制通道。其中,应用通道构建为在REE和TEE之间的应用程序的通信;驱动通道构建为在REE和TEE之间的用于运行的驱动之间的通信;以及,调度与控制通道构建为在REE与TEE之间的用于调度和控制命令的通信。
根据本发明的实施例,应用通道、驱动通道和调度与控制通道相互隔离并且能够并行通信。从而可以在一台移动终端上同时高效率地解决生物识别、移动支付、数字版权保护、安全定位、物联网安全等多类安全问题。
相反,单通道结构的缺点在于:
(1)通道的结构设计复杂。由于使用单通道,TEE侧需要对REE侧的信息进行解析,通过加载器与TEE侧对应的访问对象进行通信。反之,如果TEE侧有应用要调用REE侧的程序、驱动等,也只能通过此通道来进行通信。对于驱动、应用、调度等操作的数据结构都要使用该通道,一种通信中包含多种数据类型对设计和实现带来了巨大困难。
(2)不符合低耦合的软件设计思想,对于维护和升级存在着非常大的困难。通道的升级可能造成相应模块的相互影响,容易产生错误。
(3)效率低下。单通道无法实现并发处理数据、驱动等不同类型的并发处理。
根据本发明的实施例,对于应用通道、驱动通道和调度与控制通道,分别设置在REE侧与TEE侧之间的共享内存,用于不同的通道的共享内存之间相互独立。通过共享内存,REE与TEE之间实现不同数据类型在不同通道的传递。
换句话说,用于实现不同通道的共享内存是设置在REE侧并可与TEE共享的内存部分,属于非可信内存(设置在TEE侧的内存是REE侧不可访问的可信内存),并且可以通过逻辑划分的方式实现不同通道的内存之间的相互独立。例如,可以为不同的通道划分固定的、相互独立内存区域,或者可以在每次运行中根据需要调整分配给各通道的内存区域,每次调整后,仍通过逻辑划分保证各通道间的独立性。
举例而言,各通道的数据传递过程如下:
首先,将数据载入不同通道的共享内存;然后,在REE或TEE侧读取数据;接下来,在REE或TEE侧根据数据类型,对数据做出标识并封装到不同的数据结构里面,然后将数据放在相应的工作队列中,等待被处理。
由于用于不同通道的内存相互独立,虚拟的“通道”自然也相互隔离。通过这种方式,不同类型的数据经由专用通道进行传送,实现了完全的并发性,并且使得能够支持“多TEE”架构,即,在TEE侧虚拟化出的多个虚拟机的同时通信。
根据本发明的实施例,应用通道、驱动通道和调度与控制通道可以分别采用单工的方式,并且各自包括正向通道和反向通道,其中,正向通道用于将REE侧的发送队列中的消息传送到TEE侧的接收队列中,反向通道用于将TEE侧的发送队列中的消息传送到REE侧的接收队列中。这样进一步提高了“并发性”,并且降低了数据传输中的出错概率。应用通道、驱动通道和调度与控制通道也可以采用半双工或者双工的通信方式,相应地正向通道和反向通道也可以是虚拟通道,可以通过切换或者竞合来实现。
根据本发明的实施例,在REE侧和TEE侧各自的发送队列和接收队列中保存有待发送或所接收的消息的消息类型和消息内容,从而经由符合消息类型的通道发送或接收各个消息。通过该方式能够简单地实现将待传送的消息划分到正确的通道。
根据本发明的实施例,应用通道承载标准的应用协议、如符合GPTEE注1标准的Client API。
根据本发明的实施例,驱动通道构建为用于在REE与TEE之间,在虚拟驱动与主驱动之间通信,以实现在REE与TEE之间的驱动共享。
本发明实施例的方案以TEE技术为核心,面向但不局限于支持ARM Trustzone扩展的处理器芯片,通过本发明所提出的多层次操作方法,可以在一台移动终端上同时高效率地解决生物识别,移动支付,数字版权保护,安全定位,物联网安全等多类安全问题。
TEE的架构大体可以分为三层,包括了硬件层、TEE OS(操作***)层,以及TA(Trusted Application可信应用)层。根据本发明实施例的多通道通信***是在TEEOS层实现的。
图1示出了根据本发明实施例的一种用于REE与TEE之间的通信的多通道通信***100。如图1所示,该多通道通信***100包括REE 101和与REE 101隔离的TEE 102,其中,在TEE 102和REE 101中均运行有操作***和应用,例如,在REE 101端运行有客户端应用、主驱动、虚拟驱动和/或处理器核心,在TEE 102端运行有可信应用、主驱动、虚拟驱动和/或处理器核心。
TEE(trusted execution environment)是一个安全执行环境,它与普通执行环境(REE)之间隔离,而操作***和应用可以分别运行在两个执行环境中。从而需要在TEE与REE之间提供通道以用于数据传输。
因此,多通道通信***100还包括设置在REE 101与TEE 102之间的应用通道103、驱动通道104和调度与控制通道105,其中,应用通道103构建为在REE 101和TEE 102中的应用程序之间的通信;驱动通道104构建为用于运行在REE 101和TEE 102中的驱动之间的通信;以及,调度与控制通道105构建为用于调度和控制命令在REE 101与TEE 102之间的通信。
应用通道103可以为应用厂商的APP提供指定的接口,只要遵循此接口,厂商都可以将注册的APP应用到本平台中,其中,根据本发明可以将具有高度安全性的APP放置在TEE侧。对于安置在TEE侧的APP的准入权限,一般是在设备的工厂阶段,由可信应用开发商和设备商、TEE提供商之间协商,通过签名来验证准入的。
由于驱动种类、占用资源大小的不同,通过驱动通道104,可以实现主机驱动和虚拟驱动之间的通信。可以将不同的驱动灵活地设置保存在TEE侧或者REE侧。对于占用资源较多,且迁移难度较大的驱动可以保留在REE侧。而在TEE侧可以保存占用资源较小且需要较高安全级别的驱动。
关于调度通道,目前的可信执行环境没有对资源的调度。例如,在目前的TEE中,一般都是分配指定的处理器核心负责TEE相关服务和任务(task)的运行,由于目前TEE中要运行的保护内容较少,单核心的处理能力还可以应对。但是随着对TEE需求的扩大,虹膜、DRM等相关应用的使用,会造成TEE侧的负载极大的增加。因此,对于资源的合理调度是十分必要的。目前已知的TEE厂商都没有实现REE与TEE之间的处理器调度。
在本发明的一个实施例中,应用通道103、驱动通道104和调度与控制通道105可以为同一通道。在该实施例中,TEE采用宏内核或沙箱架构,基于其自身的特点,即内核对象仅关联一个进程,导致TEE与REE之间的通信仅能通过单一的通道来进行通信。具体而言,sandbox(沙箱技术)是一种分隔运行程序的安全机制,经常用于执行未测试的代码或者第三方的非可信程序。沙箱通常可以为用户提供一套严密控制的资源集合来保证程序的运行,可以为用户APP提供虚拟***环境,在对沙箱环境中运行的程序即使出现错误,也只是修改破坏本地临时资源而不会造成***的崩溃。沙箱的工作原来为同一时刻只能包含一个沙箱运行,在不支持虚拟化技术的条件下,以及沙箱的机制,TEE中只能同时运行一个可信应用TA。
然而这种单一的、共享的通道的实现方式具有如下特点:(1)通道的结构设计复杂。由于使用单通道,TEE侧需要对REE侧的信息进行解析,通过加载器与TEE侧对应的访问对象进行通信。反之,如果TEE侧有应用要调用REE侧的程序、驱动等,也只能通过此通道来进行通信。对于驱动、应用、调度等操作的数据结构都要使用该通道,一种通信中包含多种数据类型对设计和实现带来了巨大困难。(2)不符合低耦合的软件设计思想,对于维护和升级存在着非常大的困难。通道的升级可能造成相应模块的相互影响,容易产生错误。(3)效率低下。单通道无法实现并发处理数据、驱动等不同类型的并发处理。
根据本发明的又一实施例,应用通道103、驱动通道104和调度与控制通道105相互隔离并且能够并发。其中,应用通道103负责Client APP(REE侧的客户应用)与Trusted APP(TEE侧的可信应用)之间的通信,应用通道103主要承载标准的应用协议(如符合GPTEE注1标准的Client API);驱动通道104负责REE与TEE间设备主驱动和虚拟驱动之间的通信;驱动通道104承载各类驱动的通信接口,本发明采用了驱动虚拟对接的方法来完成REE与TEE之间的驱动共享;调度与控制通道105承载着REE与TEE之间的调度类与控制类命令。
相互隔离的通道是通过虚拟化技术实现的。具体而言,是通过为应用通道103、驱动通道104和调度与控制通道105分别设置在REE侧与TEE侧之间的共享内存而实现的,用于不同的通道的共享内存之间相互独立。应用通道103、驱动通道104和调度与控制通道105各自包括正向通道和反向通道,其中,正向通道用于将REE侧的发送队列中的消息传送到TEE侧的接收队列中,反向通道用于将TEE侧的发送队列中的消息传送到REE侧的接收队列中。在REE侧和TEE侧各自的发送队列和接收队列中保存有待发送或所接收的消息的消息类型和消息内容,从而经由符合消息类型的通道发送或接收各个消息。这样在通过多通道进行消息传递时,才能正确的将消息按照类型通过不同的通道传输到REE或者TEE中。对CA(Client Application,客户端应用)和TA(Trusted Application,可信应用)的消息队列都要有独立的线程来负责处理队列中的内容。通过本实施例的方案,不同的通道之间可以并发,同一通道内CA和TA的调用也不用等待返回的结果,真正做到并发操作。
本发明的该相互隔离的多通道支持并发调用。通过使用上述虚拟化技术,在一个TEE上可以虚拟化多个虚拟机,为不同的TA创建执行空间。如多个设置在REE侧的CA可以同时调用多个设置在TEE侧的TA,多个驱动可以同时相互共享等。虚拟机的特性即为隔离性和安全性,同时也可以实现安全隔离。该实施例的方案真正做到了多通道的并发技术,在***的性能和可扩展性上都处于领先地位。通过该实施例所提出的多层次操作方法,可以在一台移动终端上同时高效率地解决生物识别,移动支付,数字版权保护,安全定位,物联网安全等多类安全问题。
通过本发明的该相互隔离的多通道还相比于不支持虚拟化的技术方案实现了更大的安全性。在TEE侧的保护层次和级别上都要比现有的TEE软件产品有明显的优势。
在TEE和REE之间的数据交换可以采用多种方式,例如,在移动终端中,应用数据(AD)与控制数据(MCP、NQ)经由不同的缓冲器传输,但是这种基于缓冲器的数据传输对于驱动以及调度无法实现有效的控制。基于虚拟化而实现的多TEE的支持,是目前本发明的相互隔离的多通道相比于其他TEE厂商最大的优势。目前其他厂商都不支持多TEE。
图2示出了根据本发明一个实施例的驱动通道。如图2所示,驱动通道104构建为用于在REE与TEE之间,在虚拟驱动与主驱动之间通信,以实现在REE与TEE之间的驱动共享。
驱动的调用是通过虚拟对接的方式实现的。可以根据驱动本身的特点而将主驱动和虚拟驱动分配在不同的执行环境中。也就是说,在一个执行环境中设置驱动的主驱动,在另一执行环境中设置该驱动的虚拟驱动。例如,将文件***驱动放在REE中,FP驱动放在TEE中。驱动的划分方式在以下会进一步说明。
在REE侧调用特定的驱动的情况下,如果在REE侧仅存在该驱动的虚拟驱动而在TEE侧存在该驱动的主驱动,REE调用设置在REE侧的该驱动的虚拟驱动,从而触发与该驱动有关的信息经由驱动通道的正向通道被发送至TEE侧的相应的主驱动,进而该主驱动被调用和将处理后所得的信息经由驱动通道的反向通道返回至REE侧的虚拟驱动。
在TEE侧调用特定的驱动的情况下,如果在TEE侧仅存在该驱动的虚拟驱动而在REE侧存在该驱动的主驱动,TEE调用设置在TEE侧的该驱动的虚拟驱动,从而触发与该驱动有关的信息经由驱动通道的反向通道被发送至REE侧的相应的主驱动,进而该主驱动被调用和将处理后所得的信息经由驱动通道的正向通道返回至TEE侧的虚拟驱动。
通过这种方式,应用可以在REE侧或TEE侧调用任何驱动而感觉不到在REE与TEE之间的转换。以指纹识别应用为例,在REE侧调用指纹驱动,而该驱动的主驱动,或者说真正的驱动位于TEE侧。换句话说,在REE侧调用指纹驱动获取指纹信息,而REE侧却不存在真正的指纹驱动,但通过虚拟化的方式在REE侧定义了操作指纹的接口。
根据本发明的多通道通信***调用REE侧的虚拟化的指纹接口,实际是通过驱动通道104的正向通道将指纹接口的信息传递到TEE中,TEE侧再通过调用真正的指纹接口获得指纹相关信息后,将信息通过反向驱动通道发送到REE侧,REE再获得指纹相关结果。REE侧的CA感觉不到驱动的调用实际上是存在两个执行环境的切换的。这就是通过虚拟化的方式结合驱动通道,实现了消息的通信。
终端上搭载的各类硬件以及其提供的安全服务如指纹识别、虹膜识别、DRM(Digital Rights Management,数字版权管理)、NFC等,都有自身的驱动程序,其驱动划分是在REE侧还是在TEE侧,目前的TEE软件产品均未给出明确的划分方法以及实现方法。本发明提出基于安全性与可用性的需求程度来进行驱动划分的方法以及采用虚拟对接方式的实现方法。
根据本发明的一个实施例,多通道通信***包括驱动划分单元。图3示意性地示出了该驱动划分单元的工作流程。该驱动划分单元执行如下步骤:
在步骤301,评估待在多通道通信***上运行的驱动的安全性;在该驱动的安全性在第一安全性阈值以上的条件下,在步骤302将该驱动的主驱动划分到TEE侧,在REE侧设置该驱动的虚拟驱动;在该驱动的安全性在第二安全性阈值以下的条件下,在步骤303将该驱动的主驱动划分到REE侧,在TEE侧设置该驱动的虚拟驱动;在该驱动的安全性位于第一安全性阈值与第二安全性阈值之间的条件下,在步骤304检查该驱动的可用性和可实现性,如果可用性在可用性阈值以下并且可实现性在可实现性阈值以上,在步骤305将该驱动的主驱动划分到TEE侧并且在REE侧设置该驱动的虚拟驱动,否则在步骤306将该驱动的主驱动划分到REE侧并且在TEE侧设置该驱动的虚拟驱动。
该划分方式兼顾了安全性、可用性以及可实现性。具体而言:
-安全性&可用性考虑:从驱动资源的安全性方面进行划分。对于安全需求强的驱动,趋向TEE侧划分,其中,安全性是第一标准,也是设立单独的TEE的主要目的,因此,安全性高于阈值的驱动应划分到TEE侧;相对于安全性其对可用性的需求更多的情况,趋向REE侧划分,利用REE与TEE虚拟对接方式来保证安全。例如目前终端设备常用的指纹驱动,其安全需求较强,因此指纹的主驱动(Host Driver)划分在TEE中,在REE留有虚拟的(Virtualized)驱动接口供REE使用;而如存储与网络,其驱动***较大,相对于安全性其对可用性的需求更多,因此将主驱动划分在REE侧,TEE侧留有虚拟驱动接口。
-可实现性:对于一些特殊驱动与操作的保护是不能够只考虑其安全性,还需要综合考虑技术上的可实现性。如DRM(数字版权管理)驱动,NFC(近距离无线通信)驱动以及虹膜摄像头驱动,其特点是驱动***较大较难完全迁移到TEE中并且还有一定程度的安全需求。对于此类驱动,考虑技术可实现性,会划分到REE侧,对该类驱动的安全,本发明利用了REE中的虚拟化技术与容器技术将此类驱动资源进行保护。
根据本发明的一个实施例,驱动划分单元将DRM驱动、摄像头驱动、网络驱动、GPS驱动和存储驱动的主驱动划分到REE侧;将虹膜驱动中关于数据传输、数据分析的部分驱动的主驱动划分到TEE侧,而将虹膜驱动中的其它部分驱动的主驱动划分到REE侧;将NFC驱动的主驱动划分到REE侧;将指纹驱动中有关数据传输、数据分析的部分驱动的主驱动划分到TEE侧,并且将指纹驱动中有关SPI中断(共享***中断)发起的部分驱动的主驱动划分到REE侧;将SE(安全元件)驱动划分到TEE侧;以及,将支持TUI(可信用户接口)的驱动的主驱动设置在REE侧以及TEE侧。该划分考虑了安全级别需求以及整体架构的保护级别。支持TUI的驱动包括LCD驱动、触摸屏驱动和I2C驱动。
图4示意性地示出了根据本发明的多通道通信***的安全层次。REE的安全性低于TEE,REE又包括安全层次Hypervisor和安全性低于Hypervisor的安全层次Container,其中,Hypervisor与Container相互隔离,REE与TEE相互隔离。
Container层泛指与Linux操作***下的容器技术类似的相关技术,Hypervisor指通过硬件支持的虚拟化扩展技术建立起的虚拟软件层,TEE指根据不局限于ARM Trustzone扩展的处理器芯片提供TEE技术。
根据本发明的实施例,驱动划分单元将划分到REE侧的驱动的主驱动分别设置到Container或者Hypervisor中。
在本发明的一个实施例中,根据本发明的多通道通信***还包括与REE和TEE隔离的SE运行环境,该SE运行环境可以涵盖移动终端中的eSE(embedded secure element,嵌入式安全单元)、SIM(Subscriber Identification Module客户识别模块)、SSD(securestorage device,安全存储设备)等,拥有最高的安全等级,但是处理能力较弱。
如果分别按照驱动的安全级别和整体架构安全的需求为这些安全层次划分驱动,则有:
REE:网络驱动、GPS驱动。存储驱动等,对他们的安全需求不是那么高,但需求量非常高。需要频繁的使用。如果将其放在TEE里,将严重的影响***的性能。所以放置在REE中不加保护。
REE Container:对于一些特殊驱动与操作的保护是不能够只考虑其安全性,还需要综合考虑技术上的可实现性。如DRM驱动,NFC驱动以及虹膜摄像头驱动,其特点是驱动***较大较难完全迁移到TEE中并且还有一定程度的安全需求。按照本发明,例如将虹膜驱动中关于数据传输、数据分析部分的驱动放置在安全端,其他部分驱动放置在REE Container里。因为驱动的这两部分涉及到安全保护。但是其他部分安全保护级别较低,所以将其放置在REE Container中。
REE Hypervisoer:在REE中,arm虚拟化在REE中支持EL2的硬件虚拟化。虚拟化可以提高安全级别,但是毕竟是在REE中,安全级别低于TEE。NFC目前已经逐渐应用,但主要应用于非安全端,NFC支付的市场需求比较小;其次,NFC设备厂商很少提供在TEE中的移植代码,移植困难相当大,对***稳定会造成相当的影响。所以,保留NFC驱动在REE侧,但是将其放在Hypervisor里,提高安全级别。
TEE:指纹的使用与支付有关,而支付是需要绝对安全的,所以将指纹驱动放置在TEE中,指纹设备的使用只有在安全世界中能够使用。指纹驱动中SPI中断发起是在REE中发起的,这部分不受TEE的保护,其他的指纹数据传输、分析等放置在TEE中。SE的安全级别最高,SE驱动必须放在TEE中。
TUI:指可信用户接口。屏幕的驱动在REE和TEE中都要放置。屏幕的使用是最频繁的,在REE侧需要包含屏幕驱动。但是为了确保在需要安全界面的情况下,如输入银行账号和密码时需要在TEE中执行时,需要在安全端直接调用屏幕驱动。
根据本发明的实施例,实现了不同安全层次之间的虚拟对接方法。具体而言,在REE侧不论是Container还是Hypervisor的环境的初始化均从TEE侧来发起和检测,其中,TEE引导并初始化Hypervisor,Hypervisor再引导并初始化Container。从而,TEE作为安全可信的基础,保证整个安全引导要建立在真实性、完整性校验的基础上。
图5示意性地示出了REE与TEE间的虚拟对接方式。在REE侧不论是Container还是Hypervisor的环境的初始化均从TEE侧来发起和检测,其中,TEE引导并初始化Hypervisor,Hypervisor再引导并初始化Container。TEE作为安全可信的基础,保证整个安全引导要建立在真实性,完整性校验的基础上。
对于DRM与虹膜,当DRM或虹膜TA进行安全操作时,其借由了REE中Container中的驱动模块,当完成一次调用后,Hypervisor立即将DRM与虹膜摄像头驱动的IO控制进行禁止,其借助了处理器芯片中类似于IOMMU或SMMU的机制来完成,确保在安全操作时,驱动的控制寄存器REE OS是不能篡改的。
对于NFC驱动,以线下支付为例,NFC驱动在Hypervisor上的一个虚拟机中进行隔离与保护,预期配合的关键的eSE驱动是完全在TEE中进行保护的,其与可能存在的、最高安全层次的SE进行直接的交互。
其他的如安全定位及物联网安全关键定位模块与驱动模块的保护都可以通过类似的方案来实现。
通过本发明的驱动划分方法及对接方式,切实解决了TEE对各类驱动的保护方式和方法问题。目前其他TEE厂商对驱动***的处理方式一般采用全部迁移到安全端或者全部放在REE里。这样的设计虽然设计简单,安全性相对较高,但是,对驱动的种类和特性没有做相应的分析,造成了实现上存在严重的缺陷,已知的著名TEE厂商中,就出现了将所有的驱动迁移到TEE中的做法,但是到目前仍然没有得到实现,因为驱动和***密切相关,虽然可以完全保护驱动,但无法实现也是不争的事实。
根据本发明的实施例,TEE以密码学方式加密待传送至REE侧的数据,以保证流向REE侧的数据都是密文的。从而将TEE侧不可篡改、不可侦听等安全性传递至REE侧的接收方,保证了TEE运行环境以及整个多通道通信***更高的安全性。
多通道通信***还可以包括处理器核心调度单元。该处理器核心调度单元可以在TEE内部以及在TEE与REE之间调度处理器核心。该处理器核心调度单元每隔一段时间(例如100ms)检查TEE侧各处理器核心的任务负载情况,以及根据检查的结果进行处理:
-在TEE侧的处理器核心任务负载过高的情况下,将其过高部分的任务负载转移至其它未任务负载过高的TEE侧处理器核心,在转移后TEE侧处理器核心总体仍然任务负载过高的情况下,处理器核心调度单元经由调度与控制通道将REE侧的处理器核心迁移到TEE侧,作为TEE侧的处理器核心来处理TEE侧的任务;
-在TEE侧的所有任务处于阻塞或挂起状态的情况下,处理器核心调度单元经由调度与控制通道将所有TEE侧的处理器核心迁移到REE侧,以作为REE侧的处理器核心执行REE侧的任务;
-在TEE侧的任务减少并且出现闲置的处理器核心的情况下,处理器核心调度单元经由调度与控制通道将闲置的处理器核心迁移到REE侧,以作为REE侧的处理器核心执行REE侧的任务。
这种方式可以最大程度上利用目前***的处理器资源,确保TEE和REE中处理程序的良性运行。
根据本发明的一个实施例,在TEE侧处理器核心总体任务负载过高的情况下,可以由任务负载过高的TEE侧的处理器核心向处理器核心调度单元发出请求,使得处理器核心调度单元检查REE侧的处理器核心的状态并且随机选择挂起状态的处理器核心转移到TEE侧,以作为TEE侧的处理器核心执行TEE侧的任务,并且处理器核心调度单元将发出请求的处理器核心的待分发的任务按照特定的任务规则、例如按照优先级排序地或者按照迁移时间先后顺序地分发给新转移来TEE侧的处理器核心以进行处理。
图6示意性地示出了根据本发明的核心调度单元的工作方式的示意图。如图6所示,处理器核心2作为TEE侧专用Core处理安全任务(Secure Task),期间会通过全局调度定期将处理器核心2还回REE,主要是响应REE OS的核间调度与例行任务与中断调度,处理器核心3根据TEE的负载情况动态加入到TEE运行环境中,处理Secure Task,此为本发明提出的基本全局调度方法。
在本发明的又一实施例中,处理器核心调度单元采用基于时间片的单核调度算法来对TEE侧的核心进行调度。其中,每个任务都被分配有优先级。多个进程轮换地在同一TEE核心上相互交替执行,在任一段时间内可以有N个进程在同时执行,但在任意一个时刻只有一个进程在执行。倘若某个进程用完了自己的时间片,但尚未执行完毕,那么就需要将当前使用的核心切换给其它进程使用,所提及的用完时间片的进程通过定时中断在下一轮进程间的时间片循环中在属于自己的时间片到来时再被切换回核心上运行。在TEE和REE总共有多个核心的情况下,处理器核心调度单元可以通过启动新核心来继续执行用完时间片的进程的执行,即通过启用新核心来均衡核心的负载。该新的核心优选是TEE中闲置的核心,也可以是从REE中的闲置核心中随机挑选并且从REE侧迁移过来的核心。为实现该实施例,例如可以采用HEFT(Heterogeneous-Earliest-Finish-Time,异构最早完成时间)或CPOP(Critical-path-on-a-Processor,处理器上的关键路径)算法。
根据本发明的一个实施例,多通道通信***包括中断控制单元,在TEE侧的处理器核心接收到中断的情况下:
-中断控制单元将中断中只能由TEE侧的处理器核心处理的中断作为安全中断划分到第一组中,并且将中断中的其它中断作为非安全中断划分到第二组中。
接下来,可以进行如下处理:
-中断控制单元将第一组中的安全中断交由TEE侧的处理器核心处理,以及
-中断控制单元将第二组中的非安全中断经由调度与控制通道转移给REE侧的处理器核心处理。
或者进行如下处理:
-中断控制单元将第一组中的安全中断交由TEE侧的处理器核心处理,以及
-中断控制单元判断第二组中的非安全中断是SPI(Share PeripheralInterrupt,共享***中断)、PPI(私有中断)还是SGI(软中断),如果是SPI,则中断控制单元指示接收到该中断的TEE侧的处理器核心将其丢弃,并且中断控制单元经由调度与控制通道将该被丢弃的SPI转移至REE侧的处理器核心进行处理;如果是PPI或SGI,则中断控制单元通知处理器核心调度单元,处理器核心调度单元随后经由调度与控制通道将接收到该中断的TEE侧的处理器核心转移到REE侧从而成为REE侧的处理器核心,并且将该中断的任务放在相应的工作队列(working Queue)里面排队,之后,处理器核心调度单元将接收到该中断的REE侧的处理器核心经由调度与控制通道重新转移回TEE侧,从而使其重新成为TEE侧的处理器核心以等待接收其它中断。可选地,在中断被放入工作队列后,处理器核心调度单元立刻将接收到该中断的REE侧的处理器核心经由调度与控制通道重新转移回TEE侧。该实施例的方案可将大量的SPI丢弃,交由其他REE处理器核心进行处理,大大减少了TEE处理器核心切换回REE处理器核心进行处理的次数,从而大幅度提升了TEE的处理效率。
图7示意性地示出了根据本发明实施例的中断控制单元的工作流程。如图7所示,响应于TEE处理器核心接收到中断,中断控制单元判断该中断为安全中断FIQ还是非安全中断IRQ,并且将安全中断FIQ放到一个组中,将其它中断放到另一组中。基于安全中断和非安全中断的划分,对于安全中断需要在TEE中处理该中断,其他中断必须在其他REE处理器核心或者本REE处理器核心中处理。
由于TEE侧的硬件资源有限,为了提高TEE处理器核心的处理能力,一般将非必须在TEE侧中处理的中断分给REE处理器核心来处理,来减轻TEE资源负载。因此,如上划分TEE核心所接收的中断使得能够针对于TEE侧的处理器核心。对于产生的非安全中断IRQ或者安全中断FIQ进行调度,尽量避免TEE侧处理器核心的负载过大。下一步可以将安全中断FIQ留给TEE处理器核心处理,将非安全中断IRQ经由调度与控制通道105迁移到REE侧由REE处理器核心来加入工作队列。之后,该处理器核心被中断控制单元切换回TEE侧,继续等待接收该核心的其它中断。
在可选的下一步骤中,进一步区分非安全中断IRQ是共享***中断SPI、私有中断PPI还是软中断SGI。其中非安全的SPI可以被TEE核心丢弃,通过调度与控制通道105由REE核心接手并处理。SPI可以被任一处理器核心接管,而中断PPI和软中断SGI只能被当前接收到该中断的TEE处理器核心处理,因此对于这部分中断的处理的优化方式是将该TEE处理器核心迁移到REE侧来作为REE处理器核心处理该中断PPI和软中断SGI。从而将在TEE处理器核心中的不需要处理的中断尽可能的分到REE处理器核心去处理。由于TEE处理器核心将大量的SPI丢弃,交由其他REE处理器核心进行处理,大大减少了TEE处理器核心切换回REE处理器核心进行处理的次数,从而大幅度提升了TEE的处理效率。
图8示意性地示出了一种根据本发明的电子设备。该电子设备具有根据本发明的多通道通信***以及网络接口和***设备接口,其中,用户能够经由网络接口或者***设备接口获得应用并且安装在多通道通信***上,用户还能够运行不同的应用。该电子设备例如可以是手机、掌上电脑、笔记本电脑、桌面电脑、可穿戴智能通信设备等任何本领域技术人员认为合理的电子设备。
本发明还涉及一种多通道通信方法,其设计为用于运行根据上述的、根据本发明实施例的多通道通信***。
本发明还涉及一种计算机程序产品,其具有程序代码,以便当在计算机上执行计算机程序时引起执行按照本发明实施例的多通道通信方法。
本发明还涉及一种数据载体,其具有计算机程序的程序代码,以便当在计算机上执行计算机程序时引起执行按照本发明实施例的多通道通信方法。
本发明还涉及一种电子设备,其具有根据本发明实施例的驱动划分单元以及网络接口和***设备接口,其中,用户能够经由网络接口或者***设备接口获得驱动,并且驱动划分单元将该驱动的主驱动划分到可信执行环境或者普通执行环境。
本发明还涉及一种电子设备,其具有根据本发明实施例的处理器核心调度单元以及网络接口和***设备接口,其中,用户能够经由网络接口或者***设备接口获得应用,在该电子设备上运行应用期间,处理器核心调度单元根据可信执行环境的处理器核心上的负载状态而对在可信执行环境内部以及在可信执行环境与普通执行环境之间调度处理器核心。
本发明还涉及一种处理器核心调度方法,其设计为用于运行根据本发明实施例的处理器核心调度单元。
本发明还涉及一种计算机程序产品,其具有程序代码,以便当在计算机上执行计算机程序时引起执行按照本发明的处理器核心调度方法。
本发明还涉及一种数据载体,其具有计算机程序的程序代码,以便当在计算机上执行计算机程序时引起执行按照本发明实施例的处理器核心调度方法。
本发明还涉及一种电子设备,其具有根据本发明实施例的中断控制单元以及网络接口和***设备接口,其中,用户能够经由网络接口或者***设备接口获得应用,在该电子设备上运行应用期间,中断控制单元根据可信执行环境的处理器核心接收到的中断类型而在可信执行环境的处理器核心与普通执行环境的处理器核心之间调度该中断。
本发明还涉及一种中断控制方法,其设计为用于运行根据本发明实施例的中断控制单元。
本发明还涉及一种计算机程序产品,其具有程序代码,以便当在计算机上执行计算机程序时引起执行根据本发明的中断控制方法。
本发明还涉及一种数据载体,其具有计算机程序的程序代码,以便当在计算机上执行计算机程序时引起执行根据本发明实施例的中断控制方法。
以上,仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以权利要求的保护范围为准。
附图标记列表
REE 普通执行环境
TEE 可信执行环境
SE 安全元件
100 多通道通信***
101 REE
102 TEE
103 应用通道
104 驱动通道
105 调度与控制通道
DRM 数字版权保护
NFC 近距离无线通信
IRQ 非安全中断
FIQ 安全中断
SPI 共享***中断
PPI 私有中断
SGI 软中断
eSE 嵌入式安全单元
Claims (13)
1.一种用于普通执行环境与可信执行环境之间的通信的通信***,
其特征在于,
所述通信***包括:普通执行环境和可信执行环境,
其中,
所述可信执行环境与所述普通执行环境隔离;
在所述可信执行环境和所述普通执行环境均能够运行有操作***和应用,
所述通信***还包括驱动划分单元,
该驱动划分单元执行如下步骤:
评估将在所述通信***上运行的驱动的安全性,
如果该驱动的安全性在第一安全性阈值以上,则将该驱动的主驱动划分到所述可信执行环境,在所述普通执行环境设置该驱动的虚拟驱动;
如果该驱动的安全性在第二安全性阈值以下,则将该驱动的主驱动划分到所述普通执行环境,在所述可信执行环境设置该驱动的虚拟驱动;
如果所述驱动的安全性位于所述第一安全性阈值与所述第二安全性阈值之间,则检查该驱动的可用性和可实现性;
如果所述可用性在可用性阈值以下并且所述可实现性在可实现性阈值以上,则将所述驱动的主驱动划分到所述可信执行环境并且在所述普通执行环境设置该驱动的虚拟驱动,否则将该驱动划分到所述普通执行环境并且在所述可信执行环境设置该驱动的虚拟驱动。
2.根据权利要求1所述的通信***,其特征在于,
所述驱动划分单元将DRM驱动、摄像头驱动、网络驱动、GPS驱动和存储驱动的主驱动划分到所述普通执行环境;和/或
将虹膜驱动中关于数据传输、数据分析的驱动的主驱动划分到所述可信执行环境,将虹膜驱动中的其它驱动的主驱动划分到所述普通执行环境;和/或
将NFC驱动的主驱动划分到所述普通执行环境;和/或
将指纹驱动中有关数据传输、数据分析的驱动的主驱动划分到所述可信执行环境,将指纹驱动中有关共享***中断发起的驱动的主驱动划分到所述普通执行环境;和/或
将SE驱动划分到所述可信执行环境;和/或
将支持可信用户接口的驱动的主驱动设置在所述普通执行环境以及所述可信执行环境。
3.根据权利要求2所述的通信***,其特征在于,支持可信用户接口的驱动包括LCD驱动、触摸屏驱动和I2C驱动。
4.根据权利要求1所述的通信***,其特征在于,所述普通执行环境的安全性低于所述可信执行环境,所述普通执行环境又包括安全层次Hypervisor和安全性低于Hypervisor的安全层次Container,其中,Hypervisor与Container相互隔离,所述驱动划分单元将划分到REE侧的驱动的主驱动分别设置到Container或者Hypervisor中。
5.根据权利要求4所述的通信***,其特征在于,在所述普通执行环境,所述Container和所述Hypervisor的环境初始化均从所述可信执行环境来发起和检测,其中,所述可信执行环境引导并初始化Hypervisor,Hypervisor再引导并初始化Container。
6.根据权利要求1-5中任一项所述的通信***,其特征在于,
所述通信***还包括:布置在普通执行环境与可信执行环境之间的应用通道、驱动通道和调度与控制通道,
其中,
所述应用通道用于在所述普通执行环境和所述可信执行环境的应用程序之间的通信;
所述驱动通道用于运行在所述普通执行环境和所述可信执行环境的驱动之间的通信;
以及,
所述调度与控制通道用于调度和控制命令在所述普通执行环境与所述可信执行环境之间的通信。
7.根据权利要求6所述的通信***,其特征在于,所述应用通道、所述驱动通道和所述调度与控制通道分别设置于所述普通执行环境与所述可信执行环境之间的共享内存,用于不同通道的共享内存之间相互独立。
8.根据权利要求6所述的通信***,其特征在于,所述应用通道、所述驱动通道和所述调度与控制通道各自包括正向通道和反向通道,其中,所述正向通道用于将所述普通执行环境的发送队列中的消息传送到所述可信执行环境的接收队列中,所述反向通道用于将所述可信执行环境的发送队列中的消息传送到所述普通执行环境的接收队列中。
9.根据权利要求8所述的通信***,其特征在于,在所述普通执行环境和所述可信执行环境各自的发送队列和接收队列中保存有待发送或所接收的消息的消息类型和消息内容,从而经由符合消息类型的通道发送或接收各个消息。
10.根据权利要求6所述的通信***,其特征在于,在所述普通执行环境能够运行有客户端应用、主驱动、虚拟驱动和/或处理器核心,在所述可信执行环境能够运行有可信应用、主驱动、虚拟驱动和/或处理器核心。
11.根据权利要求10所述的通信***,其特征在于,驱动通道构建为用于在所述普通执行环境与所述可信执行环境之间,在所述虚拟驱动与所述主驱动之间通信,以实现在所述普通执行环境与所述可信执行环境之间的驱动共享。
12.根据权利要求11所述的通信***,其特征在于,
在所述普通执行环境调用特定的驱动的情况下,如果在所述可信执行环境存在该驱动的主驱动而在所述普通执行环境存在该驱动的虚拟驱动,所述普通执行环境调用该驱动的设置在该普通执行环境的虚拟驱动,从而触发与该驱动有关的信息经由所述驱动通道的正向通道被发送至所述可信执行环境的相应的主驱动,进而该主驱动被调用和将处理后所得的信息经由所述驱动通道的反向通道返回至所述普通执行环境的虚拟驱动,以及,
在所述可信执行环境调用特定的驱动的情况下,如果在所述可信执行环境存在该驱动的虚拟驱动而在所述普通执行环境存在该驱动的主驱动,所述可信执行环境调用该驱动的设置在该可信执行环境的虚拟驱动,从而触发与该驱动有关的信息经由所述驱动通道的反向通道被发送至所述普通执行环境的相应的主驱动,进而该主驱动被调用和将处理后所得的信息经由所述驱动通道的正向通道返回至所述可信执行环境的虚拟驱动。
13.一种电子设备,其特征在于,包括:根据权利要求1至12中任一项所述的通信***以及网络接口和***设备接口,其中,用户能够经由所述网络接口或者***设备接口获得应用并且将该应用安装于所述通信***,用户还能够借助所述通信***运行不同的应用。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610910915.5A CN106548077B (zh) | 2016-10-19 | 2016-10-19 | 通信***和电子设备 |
PCT/CN2017/106722 WO2018072713A1 (zh) | 2016-10-19 | 2017-10-18 | 通信***和电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610910915.5A CN106548077B (zh) | 2016-10-19 | 2016-10-19 | 通信***和电子设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106548077A true CN106548077A (zh) | 2017-03-29 |
CN106548077B CN106548077B (zh) | 2019-03-15 |
Family
ID=58369171
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610910915.5A Active CN106548077B (zh) | 2016-10-19 | 2016-10-19 | 通信***和电子设备 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN106548077B (zh) |
WO (1) | WO2018072713A1 (zh) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106547633A (zh) * | 2016-10-19 | 2017-03-29 | 沈阳微可信科技有限公司 | 多通道通信***和电子设备 |
CN107168747A (zh) * | 2017-05-27 | 2017-09-15 | 努比亚技术有限公司 | 移动终端配置的区分方法、装置及计算机可读存储介质 |
CN107919960A (zh) * | 2017-12-04 | 2018-04-17 | 北京深思数盾科技股份有限公司 | 一种应用程序的认证方法和*** |
WO2018072713A1 (zh) * | 2016-10-19 | 2018-04-26 | 北京豆荚科技有限公司 | 通信***和电子设备 |
CN108595928A (zh) * | 2018-04-12 | 2018-09-28 | Oppo广东移动通信有限公司 | 人脸识别的信息处理方法、装置及终端设备 |
CN109960582A (zh) * | 2018-06-19 | 2019-07-02 | 华为技术有限公司 | 在tee侧实现多核并行的方法、装置及*** |
WO2019196793A1 (zh) * | 2018-04-12 | 2019-10-17 | Oppo广东移动通信有限公司 | 图像处理方法及装置、电子设备和计算机可读存储介质 |
CN110727966A (zh) * | 2018-07-16 | 2020-01-24 | Oppo广东移动通信有限公司 | 图像处理方法和装置、存储介质、电子设备 |
CN110795385A (zh) * | 2019-10-29 | 2020-02-14 | 天津飞腾信息技术有限公司 | 片上***的可信核与计算核核资源分配方法及装置 |
WO2020088321A1 (zh) * | 2018-11-01 | 2020-05-07 | 华为技术有限公司 | 一种交互方法及装置 |
CN111722894A (zh) * | 2019-03-21 | 2020-09-29 | 成都鼎桥通信技术有限公司 | 应用处理方法、装置及电子设备 |
CN112953909A (zh) * | 2021-01-28 | 2021-06-11 | 北京豆荚科技有限公司 | 一种基于tee实现车载内外网安全隔离的方法 |
WO2023109211A1 (zh) * | 2021-12-14 | 2023-06-22 | 荣耀终端有限公司 | 业务处理方法和相关装置 |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3627827B1 (en) * | 2018-04-28 | 2024-05-01 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Method for controlling photographing, electronic device, and computer readable storage medium |
CN110728714B (zh) * | 2018-07-16 | 2023-06-20 | Oppo广东移动通信有限公司 | 图像处理方法和装置、存储介质、电子设备 |
CN114600108A (zh) * | 2019-08-16 | 2022-06-07 | 边信联科技股份有限公司 | 异构处理器通过开放式连接器进行具有远距认证及信息独立的可信运算***及方法 |
CN111881459B (zh) * | 2020-08-03 | 2024-04-05 | 沈阳谦川科技有限公司 | 一种基于可信运算环境的设备风险控管***及检测方法 |
CN112784265A (zh) * | 2021-02-05 | 2021-05-11 | 北京火绒网络科技有限公司 | 一种虚拟沙盒针对混淆代码的优化方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1896903A (zh) * | 2005-07-15 | 2007-01-17 | 联想(北京)有限公司 | 支持可信计算的虚拟机***及在其上实现可信计算的方法 |
CN104408371A (zh) * | 2014-10-14 | 2015-03-11 | 中国科学院信息工程研究所 | 一种基于可信执行环境高安全应用***的实现方法 |
WO2016048177A1 (en) * | 2014-09-26 | 2016-03-31 | Intel Corporation | Securely exchanging vehicular sensor information |
CN105591672A (zh) * | 2015-04-30 | 2016-05-18 | ***股份有限公司 | 基于nfc的通信方法和装置 |
CN105791284A (zh) * | 2016-02-29 | 2016-07-20 | 华为技术有限公司 | 一种数据安全传输装置及方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106548077B (zh) * | 2016-10-19 | 2019-03-15 | 沈阳微可信科技有限公司 | 通信***和电子设备 |
CN106547633B (zh) * | 2016-10-19 | 2019-12-31 | 沈阳微可信科技有限公司 | 多通道通信***和电子设备 |
CN106547618B (zh) * | 2016-10-19 | 2019-10-29 | 沈阳微可信科技有限公司 | 通信***和电子设备 |
-
2016
- 2016-10-19 CN CN201610910915.5A patent/CN106548077B/zh active Active
-
2017
- 2017-10-18 WO PCT/CN2017/106722 patent/WO2018072713A1/zh active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1896903A (zh) * | 2005-07-15 | 2007-01-17 | 联想(北京)有限公司 | 支持可信计算的虚拟机***及在其上实现可信计算的方法 |
WO2016048177A1 (en) * | 2014-09-26 | 2016-03-31 | Intel Corporation | Securely exchanging vehicular sensor information |
CN104408371A (zh) * | 2014-10-14 | 2015-03-11 | 中国科学院信息工程研究所 | 一种基于可信执行环境高安全应用***的实现方法 |
CN105591672A (zh) * | 2015-04-30 | 2016-05-18 | ***股份有限公司 | 基于nfc的通信方法和装置 |
CN105791284A (zh) * | 2016-02-29 | 2016-07-20 | 华为技术有限公司 | 一种数据安全传输装置及方法 |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018072713A1 (zh) * | 2016-10-19 | 2018-04-26 | 北京豆荚科技有限公司 | 通信***和电子设备 |
WO2018072714A1 (zh) * | 2016-10-19 | 2018-04-26 | 北京豆荚科技有限公司 | 多通道通信***和电子设备 |
CN106547633A (zh) * | 2016-10-19 | 2017-03-29 | 沈阳微可信科技有限公司 | 多通道通信***和电子设备 |
CN106547633B (zh) * | 2016-10-19 | 2019-12-31 | 沈阳微可信科技有限公司 | 多通道通信***和电子设备 |
CN107168747A (zh) * | 2017-05-27 | 2017-09-15 | 努比亚技术有限公司 | 移动终端配置的区分方法、装置及计算机可读存储介质 |
CN107168747B (zh) * | 2017-05-27 | 2020-12-29 | 努比亚技术有限公司 | 移动终端配置的区分方法、装置及计算机可读存储介质 |
CN107919960A (zh) * | 2017-12-04 | 2018-04-17 | 北京深思数盾科技股份有限公司 | 一种应用程序的认证方法和*** |
EP3633546A4 (en) * | 2018-04-12 | 2020-10-21 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | IMAGE PROCESSING METHOD AND DEVICE, ELECTRONIC DEVICE AND COMPUTER READABLE STORAGE MEDIUM |
CN108595928A (zh) * | 2018-04-12 | 2018-09-28 | Oppo广东移动通信有限公司 | 人脸识别的信息处理方法、装置及终端设备 |
WO2019196793A1 (zh) * | 2018-04-12 | 2019-10-17 | Oppo广东移动通信有限公司 | 图像处理方法及装置、电子设备和计算机可读存储介质 |
US11170204B2 (en) | 2018-04-12 | 2021-11-09 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Data processing method, electronic device and computer-readable storage medium |
CN109960582A (zh) * | 2018-06-19 | 2019-07-02 | 华为技术有限公司 | 在tee侧实现多核并行的方法、装置及*** |
KR20210014686A (ko) * | 2018-06-19 | 2021-02-09 | 후아웨이 테크놀러지 컴퍼니 리미티드 | Tee 측에 대해 병렬인 멀티-코어를 구현하기 위한 방법, 장치 및 시스템 |
KR102509384B1 (ko) | 2018-06-19 | 2023-03-14 | 후아웨이 테크놀러지 컴퍼니 리미티드 | Tee 측에 대해 병렬인 멀티-코어를 구현하기 위한 방법, 장치 및 시스템 |
US11461146B2 (en) | 2018-06-19 | 2022-10-04 | Huawei Technologies Co., Ltd. | Scheduling sub-thread on a core running a trusted execution environment |
WO2019242423A1 (zh) * | 2018-06-19 | 2019-12-26 | 华为技术有限公司 | 在tee侧实现多核并行的方法、装置及*** |
CN110727966A (zh) * | 2018-07-16 | 2020-01-24 | Oppo广东移动通信有限公司 | 图像处理方法和装置、存储介质、电子设备 |
WO2020088321A1 (zh) * | 2018-11-01 | 2020-05-07 | 华为技术有限公司 | 一种交互方法及装置 |
US11709929B2 (en) | 2018-11-01 | 2023-07-25 | Huawei Technologies Co., Ltd. | Interaction method and apparatus |
CN111722894A (zh) * | 2019-03-21 | 2020-09-29 | 成都鼎桥通信技术有限公司 | 应用处理方法、装置及电子设备 |
CN111722894B (zh) * | 2019-03-21 | 2023-04-18 | 成都鼎桥通信技术有限公司 | 应用处理方法、装置及电子设备 |
CN110795385A (zh) * | 2019-10-29 | 2020-02-14 | 天津飞腾信息技术有限公司 | 片上***的可信核与计算核核资源分配方法及装置 |
CN110795385B (zh) * | 2019-10-29 | 2023-11-03 | 飞腾信息技术有限公司 | 片上***的可信核与计算核核资源分配方法及装置 |
CN112953909A (zh) * | 2021-01-28 | 2021-06-11 | 北京豆荚科技有限公司 | 一种基于tee实现车载内外网安全隔离的方法 |
CN112953909B (zh) * | 2021-01-28 | 2023-03-14 | 北京豆荚科技有限公司 | 一种基于tee实现车载内外网安全隔离的方法 |
WO2023109211A1 (zh) * | 2021-12-14 | 2023-06-22 | 荣耀终端有限公司 | 业务处理方法和相关装置 |
Also Published As
Publication number | Publication date |
---|---|
CN106548077B (zh) | 2019-03-15 |
WO2018072713A1 (zh) | 2018-04-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106547618B (zh) | 通信***和电子设备 | |
CN106548077B (zh) | 通信***和电子设备 | |
CN106547633A (zh) | 多通道通信***和电子设备 | |
US9619308B2 (en) | Executing a kernel device driver as a user space process | |
US8996864B2 (en) | System for enabling multiple execution environments to share a device | |
CN108475217B (zh) | 用于审计虚拟机的***及方法 | |
EP2864869B1 (en) | Api redirection for limited capability operating systems | |
WO2015090158A1 (zh) | 一种虚拟网卡中断亲和性绑定的方法和计算机设备 | |
EP3017396B1 (en) | System and method for providing secure access control to a graphics processing unit | |
EP3436947B1 (en) | Secure driver platform | |
KR20080106908A (ko) | 하드웨어 장치와 같은 자원을 소유하는 가상 컴퓨터를 이동시키기 위해 이용될 수 있는 컴퓨팅 시스템 및 방법 | |
US20170102957A1 (en) | System and Method for Trusted Operability When Moving Between Network Functions Virtualization States | |
US7958293B2 (en) | Virtualized serial attached SCSI adapter | |
CN116320469B (zh) | 一种虚拟化视频编解码***及方法、电子设备和存储介质 | |
US20140351833A1 (en) | Multi-computing environment operating on a single native operating system | |
US9569241B2 (en) | Sharing devices assigned to virtual machines using runtime exclusion | |
CN101369258B (zh) | 输入输出控制*** | |
US11768696B2 (en) | Security for microengine access | |
US11385912B2 (en) | System to enable a full desktop experience based on a mobile device | |
CN117708855A (zh) | 基于核间通信的数据加密方法、装置、设备及介质 | |
CN117331878A (zh) | 操作***处理方法、装置、电子设备及计算机存储介质 | |
CN114780209A (zh) | 基于虚拟机监视器的中断处理方法及装置、终端设备、芯片 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |