CN116049813A - 基于可信执行环境的触屏数据处理方法、设备及存储介质 - Google Patents

基于可信执行环境的触屏数据处理方法、设备及存储介质 Download PDF

Info

Publication number
CN116049813A
CN116049813A CN202210906314.2A CN202210906314A CN116049813A CN 116049813 A CN116049813 A CN 116049813A CN 202210906314 A CN202210906314 A CN 202210906314A CN 116049813 A CN116049813 A CN 116049813A
Authority
CN
China
Prior art keywords
touch screen
tui
trusted
virtual machine
tvm
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
Application number
CN202210906314.2A
Other languages
English (en)
Other versions
CN116049813B (zh
Inventor
陈平原
杨晓明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202311511271.9A priority Critical patent/CN117744068A/zh
Priority to CN202210906314.2A priority patent/CN116049813B/zh
Publication of CN116049813A publication Critical patent/CN116049813A/zh
Application granted granted Critical
Publication of CN116049813B publication Critical patent/CN116049813B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0487—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
    • G06F3/0488—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures
    • G06F3/04886—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures by partitioning the display area of the touch-screen or the surface of the digitising tablet into independently controllable areas, e.g. virtual keyboards or menus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

本申请提供了一种基于可信执行环境的触屏数据处理方法、设备及存储介质，涉及通信技术领域。通过本方案，在多个可信执行环境TEE(如存在两个可信虚拟机TVM1和TVM2)协同提供可信用户界面TUI的场景中，TVM2预先加载触屏服务以及触屏驱动，一旦触屏驱动监听到用户在TUI中输入触屏数据，则TVM2立即向TVM1发送触屏数据，而无需TVM1周期性地向TVM2主动轮询触屏数据。通过本申请改进后的方案，可以简化业务流程，快速获取触屏数据，且不会丢失有效的用户触屏操作，并且可以避免TVM1的大量主动查询以及不必要的交互，提升数据交互效率，提升用户体验。

Description

基于可信执行环境的触屏数据处理方法、设备及存储介质
技术领域
本申请涉及通信技术领域，尤其涉及一种基于可信执行环境的触屏数据处理方法、电子设备及存储介质。
背景技术
伴随着终端智能化的快速发展，移动终端越来越多的涉及商业秘密和个人隐私等敏感信息，移动终端也面临各种安全威胁。黑客可能通过破解系统、恶意输入法、按键日志、截屏等方式获取用户的敏感信息(如用户名、密码、卡号等)，对客户账号安全形成威胁。
目前，可信执行环境(trusted execution environment，TEE)技术提供了可信用户界面(trusted user interface，TUI)功能。通过在TUI上操作，用户可以安全地输入敏感信息，在用户输入界面、系统、应用程序之间形成一个安全的通道，可以安全地把敏感信息传递给应用层，保证用户输入的敏感信息不被盗取。
在多TEE协同提供TUI的方案下，需要将触屏数据(touch panel，TP)从一个可信虚拟机(trusted virtual machine，TVM)传递到另外一个TVM。两个可信虚拟机分别记为TVM1和TVM2，TVM1需要使用线程或者定时器，按照预设频率或周期向TVM2主动轮询触屏数据。也就是说，TVM1每获取一次触屏数据，需要与TVM2执行一次如下交互流程：TVM1向TVM2主动发出触屏数据查询请求；TVM2向TVM1返回一个状态，表示已经收到了请求；当TVM2接收到触屏输入时，TVM2向TVM1返回触屏数据。由此可见，两个TVM之间的TP数据交互流程存在实现复杂度高、交互次数多、实时性差等各方面的问题，导致交互效率较低。
发明内容
本申请提供一种基于可信执行环境的触屏数据处理方法、电子设备及存储介质，能够简化应用于可信执行环境中的多个可信虚拟机TVM之间交互触屏数据的流程，提升数据交互效率。
为达到上述目的，本申请采用如下技术方案：
第一方面，本申请提供一种基于可信执行环境的触屏数据处理方法，应用于电子设备，电子设备中包括主虚拟机TVM、第一可信虚拟机TVM和第二可信虚拟机TVM，主虚拟机TVM应用于复杂执行环境REE，第一可信虚拟机TVM和第二可信虚拟机TVM应用于可信执行环境TEE，所述方法包括：
当所述电子设备的操作系统启动时，所述第二可信虚拟机TVM加载用于可信用户界面TUI的触屏服务以及触屏驱动程序，所述触屏驱动程序用于监听在所述可信用户界面TUI中是否有触屏数据；
当所述触屏驱动程序监听到用户在所述可信用户界面TUI中输入触屏数据时，所述第二可信虚拟机TVM向所述第一可信虚拟机TVM发送所述触屏数据。
其中，第一可信虚拟机TVM可以记为TVM1，应用于第一TEE，第二可信虚拟机TVM可以记为TVM2，应用于第二TEE。第一TEE和第二TEE协同提供可信用户界面TUI服务。
通过本申请方案，在多个可信执行环境TEE(如存在两个可信虚拟机TVM1和TVM2)协同提供可信用户界面TUI的场景中，TVM2预先加载触屏服务以及触屏驱动，一旦触屏驱动监听到用户在TUI中输入触屏数据，则TVM2立即向TVM1发送触屏数据，而无需TVM1周期性地向TVM2主动轮询触屏数据。通过本申请改进后的方案，可以简化业务流程，快速获取触屏数据，且不会丢失有效的用户触屏操作，并且可以避免TVM1的大量主动查询以及不必要的交互，提升数据交互效率，提升用户体验。
其中，主虚拟机可以是采用安卓操作系统的且运行于复杂执行环境的虚拟机。
在本申请实施例中，TVM1负责完成根据应用指定信息来生成图形界面，TVM2负责将TVM1生成的图形界面显示出来。其中，TVM2的触屏驱动采集触屏数据，并通过消息通道发送给TVM1。其中，触屏数据可以包括触屏位置信息(X，Y)以及UP/DOWN等事件信息。该位置信息用于指示触屏操作的位置，例如可以定位到在虚拟键盘上触屏操作时的具体位置，通过该位置可以确定用户选择了虚拟键盘中的哪些数字或字母或字符。该事件信息用于指示触屏的事件类型；其中，DOWN表示手势事件开始，UP表示手势事件结束。
在TVM1接收到TVM2的触屏数据之后，TVM1根据触屏位置信息(X，Y)，UP/DOWN等事件信息进一步做出响应，例如根据触屏位置信息(X，Y)判断用户点击的键盘位置，并根据判断结果确定在TUI的输入框中待显示的内容。其中，待显示的内容可以是字母、数字和/或字符的组合。待显示的内容可以是以下任一项：用户名、账号密码、银行账号。
在一些可能实现方式中，方法还包括：当电子设备的操作系统切换到TUI模式时，第二可信虚拟机TVM触发触屏驱动程序启用TUI模式。在触屏驱动程序启用TUI模式之后，第二可信虚拟机TVM通过触屏驱动程序持续监听是否有触屏数据。
在一些可能实现方式中，方法还包括：当电子设备的操作系统退出TUI模式时，第二可信虚拟机TVM触发触屏驱动程序退出TUI模式。其中，所述触屏驱动程序在退出所述TUI模式后，停止监听是否有触屏数据。
在TVM2中预先加载完成用于可信用户界面TUI的触屏服务和触屏驱动。一旦电子设备的屏幕显示内容切换到TUI界面(进入TUI模式)，触屏驱动实时检测是否存在有效的用户触屏操作，当触屏驱动检测到有有效的用户触屏操作时，触屏驱动获取触屏数据，并且第二TEE的TVM2主动将该触屏数据发送给第一TEE的TVM1。
这样，一旦TVM2侧检测到有有效的用户触屏操作，TVM2就主动向TVM1提交触屏数据，而无需TVM1多次向TVM2请求触屏数据。其中，TVM1只需要监听来自TVM2的触屏数据，不需要向TVM2主动轮询。
本申请方案通过改进目前的软件实现和工作流程，可以对触屏数据流的传输进行优化：可以简化两个TVM之间关于触屏数据的交互流程，通过一次主动通知就可以完成触屏数据的传输。在实际实现时，第一TEE的TVM1不需要与第二TEE的TVM2多次交互，简化了实现流程。
在一些可能实现方式中，所述第二可信虚拟机TVM向所述第一可信虚拟机TVM发送所述触屏数据，包括：所述第二可信虚拟机TVM通过第一消息通道，向所述第一可信虚拟机TVM发送所述触屏数据。其中，第一消息通道是通过套接字socket实现数据传输的方式。
在一些可能实现方式中，所述方法还包括：当所述电子设备的操作系统启动时，所述第二可信虚拟机TVM加载TUI显示驱动程序。
在一些可能实现方式中，方法还包括：第二可信虚拟机TVM显示第一用户界面，该第一用户界面为可信用户界面；第二可信虚拟机TVM接收用户在所述第一用户界面中的触屏操作；响应于用户的所述触屏操作，第二可信虚拟机TVM调用触屏驱动程序，采集所述触屏数据。
本申请方案可以避免TVM1的大量主动查询。其中由于TVM1查询频率较高时，部分查询可能是无效的，因此通过避免TVM1的大量主动查询，可以避免不必要的交互。在实际实现时，第一TEE的TVM1不需要耗费CPU多次查询，避免无效的查询，节省能耗。
另外，本申请方案可以避免因为TVM1查询频率(例如频率较低)带来的可能丢失触屏数据的问题，优化用户体验。在实际实现时，系统不会丢失有效的用户触屏操作，提升用户体验。
在一些可能实现方式中，在所述接收用户在所述第一用户界面中的触屏操作之后，所述方法还包括：所述第二可信虚拟机TVM确定所述触屏操作满足预设的触屏条件；其中，所述预设的触屏条件用于判断所述触屏操作是否为有效的触屏操作。
在一些可能实现方式中，所述触屏操作包括在所述第一用户界面中的预设区域进行输入，所述预设区域为用于输入用户隐私信息的区域。
可选的，本申请实施例中，上述用户的触屏操作可以为点击输入(例如单击输入或双击输入)，也可以为滑动输入，还可以是其它任意可能形式的输入，具体可以根据实际使用需求确定，本申请实施例不作限定。
在一些可能实现方式中，在所述第二可信虚拟机TVM向所述第一可信虚拟机TVM发送所述触屏数据之后，所述方法还包括：
第二可信虚拟机TVM接收所述第一可信虚拟机TVM发送的第二用户界面，所述第二用户界面是所述第一可信虚拟机TVM根据所述触屏数据生成的可信用户界面；
第二可信虚拟机TVM调用TUI显示驱动程序，从显示所述第一用户界面更新显示为所述第二用户界面，所述TUI显示驱动程序为用于触发显示可信用户界面的驱动程序。
在一些可能实现方式中，所述主虚拟机TVM运行有客户端应用CA，并且预设有操作系统内核和第一应用程序编程接口API，所述第一API为所述主虚拟机与所述第一可信虚拟机之间的接口函数；
所述第一可信虚拟机TVM运行有可信应用TA，并且预设有第二API、TUI框架和可信执行环境内核，所述第二API为用于调用所述TUI框架的接口函数；
所述第二可信虚拟机TVM预设有为所述可信应用TA提供可信用户界面TUI服务，所述TUI服务包括TUI显示服务和TUI触屏服务，所述TUI显示服务关联TUI显示驱动，所述TUI触屏服务关联TUI触屏驱动。
在一些可能实现方式中，在所述第二可信虚拟机TVM显示第一用户界面之前，所述方法还包括：客户端应用CA接收到用户对所述客户端应用CA的操作；客户端应用CA调用所述第一API，通过操作系统内核，向所述可信应用TA发起TUI显示请求；响应于所述TUI显示请求，可信应用TA获取所述客户端应用CA对应的第一用户界面；可信应用TA向所述TUI服务发送所述TUI显示请求以及所述第一用户界面。
其中，所述第二可信虚拟机TVM显示第一用户界面，包括：响应于所述可信应用TA发送的所述TUI显示请求，所述TUI服务调用TUI显示驱动程序，显示所述第一用户界面。
在一些可能实现方式中，所述可信应用TA向所述TUI服务发送所述TUI显示请求以及所述第一用户界面，包括：所述可信应用TA调用所述第二API，进入TUI框架，然后通过所述可信执行环境内核以及进程间通信IPC，向所述TUI服务发送所述TUI显示请求以及所述第一用户界面。
在一些可能实现方式中，在所述客户端应用CA接收到用户对所述客户端应用CA的操作之后，所述客户端应用CA调用所述API向所述可信应用TA发起TUI显示请求之前，所述方法还包括：响应于用户对所述客户端应用CA的操作，判断所述客户端应用CA的待显示界面中是否包含用户隐私信息输入区域；当所述客户端应用CA的待显示界面中包含用户隐私信息输入区域时，触发所述电子设备从非TUI模式切换到TUI模式。
其中，所述非TUI模式为所述电子设备在所述REE环境中对应的运行模式，所述TUI模式为所述电子设备在所述TEE环境中对应的运行模式。
在一些可能实现方式中，所述客户端应用CA调用所述API向所述可信应用TA发起TUI显示请求，包括：当所述电子设备切换为所述TUI模式时，所述客户端应用CA调用所述API向所述可信应用TA发起TUI显示请求。
通过本申请改进后的方案，CA对应的TA的可信用户界面(TUI)可以快速获取触屏数据，可以简化业务流程，避免无效的查询，从而节省能耗，并且能够避免丢失用户触屏操作，从而提高用户体验。
第二方面，本申请提供一种基于可信执行环境的触屏数据处理装置，该装置包括用于执行上述第一方面中的方法的单元。该装置可对应于执行上述第一方面中描述的方法，该装置中的单元的相关描述请参照上述第一方面的描述，为了简洁，在此不再赘述。
其中，上述第一方面描述的方法可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，处理模块或单元、显示模块或单元等。
第三方面，本申请提供一种电子设备，所述电子设备包括处理器，处理器与存储器耦合，存储器用于存储计算机程序或指令，处理器用于执行存储器存储的计算机程序或指令，使得第一方面中的方法被执行。例如，处理器用于执行存储器存储的计算机程序或指令，使得该装置执行第一方面中的方法。
第四方面，本申请提供一种计算机可读存储介质，其上存储有用于实现第一方面中的方法的计算机程序(也可称为指令或代码)。例如，该计算机程序被计算机执行时，使得该计算机可以执行第一方面中的方法。
第五方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，所述芯片还包括存储器，存储器与处理器通过电路或电线连接。
第六方面，本申请提供一种芯片系统，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，所述芯片系统还包括存储器，存储器与处理器通过电路或电线连接。
第七方面，本申请提供一种计算机程序产品，所述计算机程序产品包括计算机程序(也可称为指令或代码)，所述计算机程序被计算机执行时使得所述计算机实现第一方面中的方法。
可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
图1为本申请实施例提供的基于可信执行环境的触屏数据处理方法的应用场景示意图；
图2为本申请实施例提供的基于可信执行环境的触屏数据处理方法的界面示意图；
图3为相关技术公开的一种基于可信执行环境的触屏数据处理方法的流程示意图；
图4为相关技术公开的一种基于可信执行环境的触屏数据处理方法的软件模块交互图；
图5为相关技术公开的一种基于可信执行环境的触屏数据处理方法的交互时序图；
图6为本申请实施例提供的一种电子设备的结构示意图；
图7为本申请实施例公开的一种电子设备的基本软件架构示意图；
图8为本申请实施例公开的基于可信执行环境的软件架构示意图；
图9为本申请实施例提供的一种基于可信执行环境的触屏数据处理方法的流程示意图；
图10为本申请实施例提供的一种基于可信执行环境的触屏数据处理方法的软件模块交互图；
图11为本申请实施例提供的一种基于可信执行环境的触屏数据处理方法的交互时序图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。
本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
本申请实施例所述的终端设备可以是手机、个人数字助理(personal digitalassistant，PDA)、平板电脑等其他智能设备。终端设备上可以部署非安全运行环境和安全运行环境，其中，非安全运行环境为终端设备上的复杂执行环境(rich executableenvironment，REE)，运行Android、iOS、Windows Phone等操作系统；安全运行环境为可信执行环境(trust executable environment，TEE)，运行一个安全操作系统。其中，TEE访问的软硬件资源与REE是隔离的，终端设备上的软硬件资源可以分别标识为两种执行环境状态，标识为安全执行状态的软硬件资源只能由TEE执行环境所访问，标识为非安全执行状态的软硬件资源则可以被两种执行环境所访问。TEE构造了一个与REE隔离的安全运行环境，可以为授权的可信软件提供安全的执行环境。
为便于理解本申请实施例，以下对本申请实施例的部分用语进行解释说明，以便于本领域技术人员理解。
REE，即复杂执行环境，REE泛指不具备特定安全功能的运行环境，比如安卓(Android)操作系统或IOS操作系统。需要说明的是，REE除了被称为“复杂执行环境”之外，还可以被称为“不可信执行环境”、“普通执行环境”、“不安全执行环境”、“富执行环境”等等，本申请实施例对此不作限定。
TEE，即可信执行环境，TEE是一种具有运算和储存功能，能提供安全性和完整性保护的独立处理环境。其基本思想是：在硬件中为敏感数据单独分配一块隔离的内存，所有敏感数据的计算均在这块内存中进行，并且除了经过授权的接口外，硬件中的其他部分不能访问这块隔离的内存中的信息。以此来实现敏感数据的隐私计算。
相比较而言，REE是一个容易受到攻击的开放环境，如敏感数据的窃取、移动支付盗用等等；而TEE是中央处理器上的一个安全区域，能够保证敏感数据在隔离和可信的环境内被处理，从而免受来自REE中的软件攻击。此外，与其他的安全执行环境相比，TEE可以端到端地保护TA的完整性和机密性，能够提供更强的处理能力和更大的内存空间。
REE+TEE架构，是通过TEE与REE结合共同为应用提供服务的架构。也就是说，TEE与REE共同存在于电子设备中。通过硬件的支撑，实现TEE与REE的隔离，具有安全能力并且能够抵御常规REE侧易遭受的软件攻击。TEE有自身的运行空间，定义了严格的保护措施，因此，比REE的安全级别更高，能够保护TEE中的数据和软件等免受软件攻击，抵抗特定类型的安全威胁。
本申请方案中采用REE+多TEE架构，其中以多TEE包括第一TEE和第二TEE为例进行示例性地说明。其中，第一TEE运行安全系统，第二TEE运行TUI服务。第一TEE和第二TEE协同实现TUI功能，例如TUI显示和TUI触屏的功能。第二TEE的TVM2(也可以称为TUI TVM)运行TUI服务端的可信虚拟机，集成TUI的驱动，向第一TEE的TVM1提供TUI显示和TUI输入的功能。
OEM TEE：原始设备制造商的可信执行环境。例如，第一TEE作为OEM TEE的角色。
TA，即可信应用，是运行在第一TEE中的应用，能够为运行在第一TEE之外的CA提供安全服务，如输入密码，生成交易签名，人脸识别等。
CA，即客户端应用。CA通常指运行在REE中的应用，但在某些TA调用TA的情况下，主动发起调用的TA也可作为CA。CA可以通过客户端(client)应用程序编程接口(applicationprogramming interface，API)对TA进行调用并指示TA执行相应的安全操作。
TUI触屏服务和触屏驱动：监听来自于用户的触屏事件。其中，触屏事件对应触屏数据，触屏数据包括位置信息以及事件信息。
下面说明本申请的各个示例性实施例所涉及的系统架构。首先需要说明的是，在一些平台上存在一个基于信任区(trust zone)技术的原生TEE，同时使用虚拟机监视器(Hypervisor)技术运行一个或者多个其他的TEE系统，即一个或多个可信虚拟机TVM。在这种类似的平台上，让OEM TEE(第一TEE)通过第二TEE进行TUI的操作，从而避免了在OEM TEE上深度耦合、集成TUI驱动的问题。
图1示出了本申请的各个示例性实施例所涉及的系统架构示意图。如图1所示，该系统架构包括主虚拟机Android VM，可信虚拟机TVM 1，以及可信虚拟机TVM 2。
其中，主虚拟机运行Android系统，用于运行非安全世界的应用。可信虚拟机TVM1应用于第一TEE，该第一TEE运行安全系统。可信虚拟机TVM2应用于第二TEE，该第二TEE运行TUI服务，因此TVM2也可以称为TUI TVM。
在图1所示场景中，可以通过多个可信虚拟机协同来提供TUI。
需要说明的是，TVM2集成了TUI设备驱动，是完成TUI功能的核心系统，向TVM1提供TUI显示和TUI输入的功能。TVM1对Android的应用提供了TUI功能，但是TVM1本身并没有直接集成TUI设备驱动，而是把对TUI的请求通过VM IPC(virtual machine-inter processcommunication)服务提交给TVM2，由TVM2真正完成TUI显示和TUI触屏的功能。
需要说明的是，在有更多TEE TVM(例如两个或更多个TVM1)的情况下，可以按照这种方式进一步扩展，由TUI TVM统一处理TUI的请求，避免各个TEE VM都需要集成TUI驱动。
下面说明图1中各个模块的功能。
客户端应用CA(也称为非安全应用)：非安全应用运行在REE环境下，也就是Android操作系统的运行环境。当应用需要与TEE交互时，会通过图1中的GP TUI API，驱动TVM1中的TUI可信应用执行相关的操作。其中，GP TUI API为可信执行环境的客户端应用程序编程接口(application programming interface，API)。
TUI可信应用：向Android侧非安全世界的应用提供服务。
GP TUI API：全球平台(global platform)定义了TUI的标准API，TEE TVM支持通过这些标准的接口来提供TUI的功能。
TUI框架：TEE内部的TUI框架，完成TUI的核心逻辑。
VM IPC客户端：TUI框架会调用VM IPC客户端相关的模块(主要为libTrustedUI、MinkIPC、VMSocket)，这些模块可以与运行于TUI TVM的TUI服务端进行消息交互。
TEE内核：提供访问TUI服务端的驱动。
TUI服务端：即运行于可信虚拟机上的TUI服务。TUI服务端监听来自于客户端的消息，会根据请求调用TUI显示驱动和TUI触屏驱动(也称为输入驱动)。
TUI显示驱动：负责对TUI的屏幕进行显示输出。
TUI触屏驱动：监听来自于用户的触屏事件。
下面再结合图1所示箭头方向说明各个模块之间的交互(调用)过程。
其中，Android操作系统上的应用通过系统内核，调用TEE的客户端API向TVM1中的TUI可信应用发起请求。然后，TVM1中的TUI可信应用通过GP TUI API调用，进入TUI框架。然后，TUI框架通过VM IPC(inter-process communication)客户端和TEE内核，与TUI服务端进行交互。TUI框架将TUI的图形界面输出给TUI服务端，并且从TUI服务端获取用户的触屏操作信息(指示触屏操作)，然后TUI框架根据触屏操作生成新的图形界面再更新给TUI服务端。最后，TUI服务端将新的图形界面输出给TUI显示驱动，并通过TUI显示驱动显示该新的图形界面。
接下来，结合图2说明TUI界面与UI界面的示意图。如图2中(a)所示，手机显示了一个APP登录界面，该界面为UI界面。如图2中(b)所示，手机显示了密码输入界面，由于该界面会输入用户登录APP的密码等敏感信息，因此该界面为TUI界面。
可以理解，TEE提供了可信用户界面TUI功能。通过在TUI上操作，用户可以安全地输入敏感信息，在用户输入界面、系统、应用程序之间形成一个安全的通道，可以安全地把敏感信息传递给应用层，保证用户输入的敏感信息不被盗取。
其中，TUI驱动把输入界面通过安全显示缓冲区(secure display buffer)呈现给用户，避免通过非安全世界(normal world)输入并传递用户的敏感信息，而是通过安全输入(secure input/secure touch)直接获取用户的输入，从而达到保护用户输入的敏感信息的目的，提高了系统的安全性。
在多TEE协同提供TUI的方案下，需要将触屏数据(TP数据)从一个可信虚拟机TVM传递到另外一个可信虚拟机TVM。两个TVM之间的TP数据交互流程可能存在实现复杂度、交互次数、实时性等各方面的问题，导致交互效率较低。
示例性地，图3示出了TEE TUI的常规方案中在不同TVM之间传输触屏数据的基本工作流程。如图3所示，假设有两个可信虚拟机TVM1和TVM2，TVM1需要使用线程或者定时器，按照预设频率或周期向TVM2主动轮询触屏数据。通过该方案，在TVM2加载触屏服务(步骤A1)之后，TVM1每获取一次触屏数据，需要与TVM2执行一次如下交互流程：
步骤A2：TVM1向TVM2主动发出触屏数据查询请求。
步骤A3：TVM2向TVM1返回一个状态，表示已经收到了请求。
步骤A4：当TVM2接收到触屏输入时，TVM2向TVM1返回触屏数据。
其中，TVM1和TVM2之间循环执行步骤A2至步骤A4。这样，TVM1按照预设查询周期向TVM2主动轮询触屏数据。
图4示出了图3所示流程的软件框架以及在该软件框架中触屏数据的请求及传输流程。如图4所示，TVM2中包括监听服务、触屏服务和触屏驱动等软件模块。在常规方案中，如图4所示，按照如下交互流程，执行步骤1至步骤9，完成触屏数据的传输：
步骤1：在TVM2侧，当监听服务监听到系统启动时，监听服务通知触屏服务加载TUI触屏服务。
步骤2：触屏服务加载触屏驱动。
步骤3：TVM1作为客户端，发起查询触屏数据的请求(称为触屏数据查询请求)。
步骤4：TVM2的监听服务监听到请求，TVM2向TVM1返回触屏查询状态，表示已经收到了请求。
步骤5：监听服务向触屏服务请求触屏数据。
需要说明的是，触屏服务可以通过触屏驱动采集触屏数据。
步骤6：TVM2的触屏驱动在采集到触屏数据之后，将触屏数据通知给触屏服务。
步骤7：触屏服务将触屏数据转发给监听服务。
步骤8：监听服务将触屏数据传输至消息通道。
步骤9：TVM2通过消息通道向TVM1返回触屏数据。
其中，消息通道为从TVM2到TVM1，用于传输数据的通道。
图5示出了两个TVM之间传输触屏数据的时序图。如图5所示，时序图包括S1至S23。
S1：在TVM2侧，当监听服务监听到系统启动时，监听服务通知触屏服务加载TUI触屏服务。
在常规方案中，监听服务不仅转发处理命令数据和显示相关的数据，而且需要负责触屏数据的转发。
S2：TVM2侧触屏服务加载触屏驱动。
下面步骤说明TVM1按照预设查询周期向TVM2主动轮询触屏数据。
S3，TVM1通知系统已切换到TUI模式。
S4，TVM2侧监听服务监听到系统已切换到TUI模式。
S5，TVM2侧监听服务向触屏服务通知系统当前处于TUI模式。
S6，触屏服务触发TUI触屏驱动启用TUI模式。
S7，TUI触屏驱动启用TUI模式，并持续监听是否有触屏数据。
S8：TVM1作为客户端，发起查询触屏数据的请求。
在常规方案中，TVM1会使用线程或者定时器，按照预设频率或周期向TVM2主动轮询触屏数据，参见下述的S9至S14以及S15至S23。
S9：TVM2侧监听服务监听到该请求，TVM2向TVM1返回触屏查询状态，表示已经收到了请求。
S10：TVM2侧监听服务向触屏服务请求查询触屏数据。
S11：TVM2侧触屏服务向触屏驱动尝试查询触屏数据。
S12：TVM2侧触屏驱动检测是否有触屏数据。
S13：TVM2侧触屏驱动未检测到触屏数据。
S14：TVM2侧触屏驱动通知触屏服务未检测到触屏数据，然后触屏服务通知监听服务未检测到触屏数据，然后通过监听服务向TVM1反馈未检测到触屏数据。
需要说明的是，上述步骤S14为可选步骤，即在一些实施例中在S13之后执行S14，在另一些实施例中在S13之后不执行S14。
以上S9至S14为一个查询周期，TVM1向TVM2主动查询触屏数据，但未查询到触屏数据。
S15：TVM1按照预设查询周期，再次向TVM2发送触屏数据查询请求。
S16：TVM2侧监听服务监听到请求，TVM2向TVM1返回触屏查询状态，表示已经收到了请求。
S17：TVM2侧监听服务向触屏服务请求查询触屏数据。
S18：TVM2侧触屏服务向触屏驱动尝试查询触屏数据。
S19：TVM2侧触屏驱动检测是否有触屏数据。
S20：TVM2侧触屏驱动检测到触屏数据。
S21：TVM2侧触屏驱动向触屏服务通知触屏数据。
S22：TVM2侧触屏服务将触屏数据转发给监听服务。
S23：TVM2侧监听服务将触屏数据传输至消息通道，并通过消息通道向TVM1返回触屏数据。
以上S15至S23为再一个查询周期，TVM1向TVM2主动查询触屏数据，并查询到触屏数据。
以上述方式循环执行，TVM1按照预设查询周期向TVM2主动轮询触屏数据。由此可见，常规方案中包括触屏数据的请求流程和触屏数据的传输流程。其中，触屏数据的请求流程是：TVM1→TVM2的监听服务→触屏服务→触屏驱动。相应地，触屏数据的传输流程是：TVM2的触屏驱动→触屏服务→监听服务→消息通道→TVM1。
在上述常规方案中，TVM1需要主动向TVM2发送查询触屏数据的请求。TVM1处于主动状态，TVM2处于被动状态。这样会带来很多问题：查询结果可能是查询到有触屏数据，也可能未查询到触屏数据。当预设查询周期较大时，即查询频率较高时，多次查询中的部分查询可能是无效的，这样会存在无效查询，会耗费CPU资源。而当预设查询周期较小时，即查询频率较低时，可能存在丢失触屏数据的情况。因此，通过上述常规方案发现，相关技术中两个TVM之间的触屏数据交互流程存在交互次数较多的问题，交互效率较低，且可能存在丢失触屏数据的情况。
鉴于此，本申请实施例提供一种基于可信执行环境的触屏数据处理方法及电子设备，通过在手机系统底层的改进，以提高用户体验。
本申请实施例通过改进目前的软件实现和工作流程，可以对触屏数据流的传输进行优化。
通过本方案，在多个可信执行环境TEE(如存在两个可信虚拟机TVM1和TVM2)协同提供可信用户界面TUI的场景中，TVM2预先加载触屏服务以及触屏驱动，一旦触屏驱动监听到用户在TUI中输入触屏数据，则TVM2立即向TVM1发送触屏数据，而无需TVM1周期性地向TVM2主动轮询触屏数据。通过本申请改进后的方案，可以简化业务流程，快速获取触屏数据，且不会丢失有效的用户触屏操作，并且可以避免TVM1的大量主动查询以及不必要的交互，提升数据交互效率，提升用户体验。
参见图6，为本申请实施例提供的一种电子设备的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serialbus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，触摸传感器180K，环境光传感器180L等。
可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，处理器110用于执行本申请实施例中的环境光的检测方法。
其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
外部存储器120一般指外存储器，在本申请实施例中，外部存储器是指除电子设备的内存及处理器的高速缓存以外的储存器，该储存器一般为非易失性存储器。
内部存储器121，也可以称为“内存”，可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。
显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用有机发光二极管(organic light-emitting diode，OLED)。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。
电子设备100还包括各类传感器，可以将各种不同的物理信号转换为电信号。示例性的，压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。陀螺仪传感器180B可以用于确定电子设备100的运动姿态。气压传感器180C用于测量气压。磁传感器180D包括霍尔传感器。加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。距离传感器180F，用于测量距离。电子设备100可以通过红外或激光测量距离。接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。环境光传感器180L用于感知环境光亮度。电子设备100可以根据感知的环境光亮度自适应调节显示屏194亮度。指纹传感器180H用于采集指纹。电子设备100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。温度传感器180J用于检测温度。在一些实施例中，电子设备100利用温度传感器180J检测的温度，执行温度处理策略。骨传导传感器180M可以获取振动信号。
触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。
示例性的，在本申请实施例中，触摸传感器180K可以检测用户对应用程序的图标的点击操作，并将检测到的点击操作传递给应用处理器，确定该点击操作用于启动或运行该应用程序，进而执行该应用程序的运行操作。
电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
以上是以电子设备100为例对本申请实施例作出的具体说明。应该理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
本申请实施例提供的电子设备可以是用户设备(user equipment，UE)，例如可以为移动终端(例如用户手机)、平板电脑、桌面型、膝上型笔记本电脑、手持计算机、上网本、个人数字助理(personal digital assistant，PDA)等设备。
另外，在上述部件之上，运行有操作系统。例如苹果公司所开发的iOS操作系统，谷歌公司所开发的Android开源操作系统，微软公司所开发的Windows操作系统等。在该操作系统上可以安装运行应用程序。
电子设备100的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。
图7是本申请实施例的电子设备100的软件结构框图。
分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层(applications)，应用程序框架层(application framework)，安卓运行时(AndroidRuntime)和系统库，以及内核层(kernel)。
其中，应用程序层可以包括一系列应用程序包。例如，应用程序层可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息、读书、旅游、运动健康、智慧生活等应用程序(应用程序可以简称为应用)，本申请实施例对此不做任何限制。
应用程序层中的应用可以分为系统应用和非系统应用，其中，系统应用具体可以包括桌面，系统用户界面(SystemUI)等，非系统应用可以包括游戏，地图，短视频，社交应用，购物应用、读书、旅游、运动健康、智慧生活等。
本申请实施例中，应用程序层还可以包括屏幕感知模块、业务逻辑处理模块和业务呈现模块等。屏幕感知模块、业务逻辑处理模块和业务呈现模块可以是独立的APP，或者可以分别集成在不同的APP中，或者可以集成在同一个APP中，本申请不做限定。
其中，屏幕感知模块，常驻运行或以低功耗形式运行，具有感知用户在屏幕上的触控操作的能力。屏幕感知模块可以通过应用程序接口(application programminginterface，API)从应用程序层的其他应用程序或应用程序框架层或系统层或内核层来检测相关事件和获取事件的状态。在本申请实施例中，屏幕感知模块主要作用是监听屏幕触控事件(也称为触屏事件)，当监听到触屏事件，将触屏事件通知给业务逻辑处理模块。屏幕感知模块还可以用于获取触控对象是哪个应用(APP)，即应用包名。也就是说，屏幕感知模块可以识别屏幕上是针对某个具体的应用触控的，并生成触屏数据。
业务逻辑处理模块(如：计算引擎)具有业务逻辑处理能力，用于获取触屏数据并处理触屏数据的逻辑。例如，业务逻辑处理模块接收到用户屏幕上触发的触屏事件及屏幕感知模块发送的触屏数据，判断是否满足触屏条件，从而判断是否根据触屏数据进行屏幕更新显示。
业务呈现模块(如：YOYO建议)，用于根据触屏数据进行更新手机屏幕显示。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图7所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，资源管理器，通知管理器等，活动管理器，剪贴板管理器等，本申请实施例对此不做任何限制。
窗口管理器用于管理窗口程序，窗口管理器可以获取显示屏尺寸，判断是否有状态栏，锁定屏幕，截取屏幕等。
活动管理器用于管理各个应用程序的生命周期以及导航回退功能，负责Android的主线程创建，各个应用程序的生命周期的维护。
资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。
Android Runtime包括核心库和虚拟机。Android Runtime负责安卓系统的调度和管理。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(media libraries)，三维图形处理库(例如：openGL ES)，二维图形引擎(例如：SGL)等。表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了二维图层和三维图层的融合。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
下面基于图6的硬件结构和图7的软件架构，结合图8描述本申请实施例的一种系统架构。
图8示出了本申请实施例提供的一种电子设备100的架构图，如图8所示，电子设备100包括硬件平台，以及运行在硬件平台上的互相隔离两个运行环境，即复杂执行环境REE和可信执行环境TEE，两个运行环境分别有独立的硬件资源和操作系统。本文中REE和TEE也可以分别称为REE模块和TEE模块。通过硬件隔离技术，例如信任区(TrustZone)机制，可以实现REE和TEE的硬件资源的隔离，同时可通过虚拟化技术实现REE和TEE对应的操作系统之间，以及应用之间的隔离。这样，TEE所能访问的软硬件资源是与REE是分离的，并且，TEE对应用程序可访问的数据和功能做了非常严格的限制，使其安全级别满足特定的安全需求，因此TEE可被认为是安全的执行环境。REE是TEE之外的运行环境，相比于TEE而言，也可以称为非安全的执行环境。
其中，电子设备100的硬件平台例如包括公共外设和可信外设，可信外设包括只能被TEE控制和访问的安全元件(secure element，SE)，比如安全存储器、安全时钟、可信键盘等。公共外设是可被REE中的操作系统控制和访问的设备。
运行于TEE中的应用程序称为可信应用程序(trusted application，TA)，TA的数量可以有一个或多个(图中仅以两个TA作为示例)。TA的界面可称为可信用户界面(TUI)。运行于REE中的应用程序称为客户应用程序(client application，CA)，CA的数量可以有一个或多个(图中仅以两个CA作为示例)。CA的界面可称为用户界面(User Interface，UI)。举例来说，CA具体可以是各种支付应用、银行客户端、手机盾应用、电子身份证、手机POS或其他等涉及账号、密码等敏感信息输入的应用软件；TA是与CA对应的安全应用，用于进行CA中涉及的敏感信息的输入操作。
关于本申请所有实施例涉及的REE、TEE、CA、TA等术语的定义，还可以参见全球平台组织GP提出的TEE相关标准。
运行于TEE中的TA可以为REE中的CA或者TEE内的其它TA提供安全相关的功能或服务。在TEE中运行的可信的操作系统可向TA提供TEE内部接口，TA通过TEE内部接口来获取安全资源和服务的访问权限，这些安全资源和服务包括但不限于：密钥注入和管理、加密、安全存储、安全时钟、可信用户界面(TUI)和可信键盘等。
运行在REE中的CA可以利用TEE提供的外部接口来请求TEE中的TA所提供的安全服务。在REE中运行的操作系统(例如Windows Phone等终端操作系统)可提供了比TEE中的可信的操作系统更丰富的特性，能接受各种类型的应用程序，但其安全性也低于可信的操作系统。
例如，在移动支付、网上银行转账等场景下，如果涉及用户敏感信息的输入和显示，REE中的CA可以通过TEE提供的外部接口来调用TEE侧的TUI和可信键盘服务，以防止REE侧的应用对用户敏感信息的恶意程序监听和窃取。
基于Linux系统(例如操作系统)的体系架构还可分为用户态(user mode)和内核态(kernel mode)。内核从本质上看是一种软件——控制计算机的硬件资源，并提供上层应用程序运行的环境。用户态即上层应用程序的活动空间，应用程序的执行必须依托于内核提供的资源，包括CPU资源、存储资源、I/O资源等。为了使上层应用能够访问到这些资源，内核必须为上层应用提供访问的接口，即系统调用。
应理解，CA运行于REE的用户态，TA运行于REE的用户态。在REE的内核态中部署有驱动模块(例如包括提供REE访问TEE的驱动接口)；在TEE的内核态中也部署有驱动模块；REE和TEE中的驱动模块都可以访问对应的硬件设备，例如，TA可通过调用GPU实现在显示屏中的显示CA的UI。REE的驱动模块还可包括TUI转换功能或TUI代理功能。此外，REE中还可部署REE控制模块，TEE中还可部署TEE控制模块，CA可以通过REE控制模块和TEE控制模块来访问TA，实现相应的安全操作。例如，REE控制模块可以根据CA的TUI访问请求(或TUI显示请求)调用REE侧的驱动模块驱动硬件设备退出非安全的工作模式(称为非TUI模式)；在硬件设备退出非TUI模式后，TEE控制模块可以根据REE控制模块发送的消息调用TEE侧的驱动模块驱动硬件设备切换为TUI模式，实现与REE的硬件隔离，然后可以调用对应的TA，实现CA对TA的访问、签名、确认等以及在显示屏中的显示TA的TUI。上述REE的驱动模块、TEE的驱动模块，以及REE控制模块、TEE控制模块等具体功能均可通过电子设备中的处理器实现。
本申请实施例中，为了安全地与用户进行交互，安全地向用户呈现信息并通过一个可信的界面接收用户输入，TEE中实现了TUI以及相关的接口，并且通过本申请提供的方案，CA对应的TA的可信用户界面(TUI)可以快速获取触屏数据。
需要说明的是，本申请实施例虽然以Android系统为例进行说明，但是其基本原理同样适用于基于iOS或Windows等操作系统的电子设备。
本申请实施例提供的基于可信执行环境的触屏数据处理方法的执行主体可以为上述的电子设备，也可以为该电子设备中能够实现该基于可信执行环境的触屏数据处理方法的功能模块和/或功能实体，并且本申请方案能够通过硬件和/或软件的方式实现，具体的可以根据实际使用需求确定，本申请实施例不作限定。下面以电子设备为例，结合附图对本申请实施例提供的基于可信执行环境的触屏数据处理方法进行示例性的说明。
下面结合具体的实施例介绍本申请实施例提供的基于可信执行环境的触屏数据处理方法。
图9是本申请实施例提供的基于可信执行环境的触屏数据处理方法的流程示意图。参照图9所示，该方法包括下述的步骤B1-步骤B2。
步骤B1，在系统启动后，TVM2加载触屏服务以及触屏驱动。
需要说明的是，监听服务和触屏服务位于软件架构的应用层，触屏驱动位于软件架构的内核层。触屏服务通过Linux标准的系统调用，与触屏驱动进行交互。
步骤B2，当触屏驱动检测到用户触屏操作时，TVM2将触屏驱动采集的触屏数据主动发送给TVM1。
这样，一旦TVM2侧检测到有有效的用户触屏操作，TVM2就主动向TVM1提交触屏数据，而无需TVM1多次向TVM2请求触屏数据。
下面结合图10，描述本申请实施例提供的基于可信执行环境的触屏数据处理方法的交互示意图。参照图10所示，TVM2中包括监听服务、触屏服务和触屏驱动等软件模块。该方法包括下述的步骤11-步骤14。
步骤11，系统启动后TVM2加载触屏服务。
其中，监听服务作为TVM1访问TVM2的入口。当监听服务监听到系统完成启动时，监听服务通知在TVM2中加载触屏服务。
步骤12：触屏服务加载触屏驱动。
步骤13：当TVM2的触屏驱动检测到有触屏操作时，触屏驱动采集触屏数据。
其中，触屏数据包括触屏位置信息(X，Y)；以及事件信息，如UP或者DOWN。其中，DOWN表示手势事件开始，UP表示手势事件结束。
其中，触屏驱动将触屏数据传输至消息通道。
步骤14：TVM2通过消息通道向TVM1发送触屏数据。
其中，消息通道可以理解为不同的TVM之间的一种数据传输方式。例如，消息通道可以为在多个可信虚拟机之间进行进程间通信的通道。
需要说明的是，以应用服务的角度来看，TVM2和TVM1之间使用底层的socket消息来做进程间通信。在实际实现上，TVM2和TVM1之间使用底层的socket实现传输的方式，不同于常规的TCP/IP网络的socket实现传输的方式，也就是说，不同的模块之间的通信机制在socket层的实现机制不同。
下面分析说明本申请方案与常规方案之间的区别。
在如图4和图5所示的常规方案中，常规方案中包括触屏数据的请求流程和触屏数据的传输流程。其中，触屏数据的请求流程是：TVM1→TVM2的监听服务→触屏服务→触屏驱动。相应地，触屏数据的传输流程是：TVM2的触屏驱动→触屏服务→监听服务→消息通道→TVM1。
相比较而言，本申请方案中仅包括触屏数据的传输流程，而不包括触屏数据的请求流程。触屏数据的传输流程是：TVM2的触屏驱动→消息通道→TVM1，其中传输流程无需经过触屏服务和监听服务的转发，简化了传输流程。
在常规方案中，触屏服务负责触发驱动进入TUI模式和退出TUI模式，同时触屏服务负责转发触屏数据。在本申请方案中，触屏服务负责触发驱动进入TUI、退出TUI，但是不负责触屏数据的转发。
由此可见，在本申请方案中，TVM1无需主动向TVM2发送查询触屏数据的请求。TVM2处于主动状态，一旦TVM2检测到有触屏数据，则主动发送给TVM1。
下面再结合图11，详细说明本申请实施例提供的基于可信执行环境的触屏数据处理方法的时序图。TVM2中包括监听服务、触屏服务、TUI触屏驱动以及TUI显示驱动等软件模块。如图11所示，时序图中包括S101至S118。
S101，系统启动后TVM2加载触屏服务。
其中，当监听服务监听到系统完成启动时，监听服务通知在TVM2中加载触屏服务。
S102，触屏服务加载触屏驱动。
其中，当触屏服务加载触屏驱动之后，触屏服务负责触发触屏驱动进入TUI模式或者退出TUI模式。
S103，TVM1通知系统已切换到TUI模式。
S104，TVM2侧监听服务监听到系统已切换到TUI模式。
S105，TVM2侧监听服务向触屏服务通知系统当前处于TUI模式。
S106，触屏服务触发TUI触屏驱动启用TUI模式。
S107，TUI触屏驱动启用TUI模式，并持续监听是否有触屏数据。
S108，TUI触屏驱动监听到触屏数据。
S109，TVM2侧TUI触屏驱动通过消息通道，将触屏数据发送给TVM1。
S110，TVM1接收触屏数据，并根据触屏数据生成图形界面。
S111，TVM1将图形界面通过消息通道，发送给TVM2。
S112，TVM2侧监听服务接收到图形界面，并将图形界面转发给TUI显示驱动。
S113，TVM2侧TUI显示驱动显示该图像界面。
如此，在TUI触屏驱动启用TUI模式的情况下，TUI触屏驱动持续监听是否有触屏数据，一旦有触屏数据，则TVM2主动向TVM1发送触屏数据，这样可以及时检测到有效的用户触屏操作，不会丢失触屏数据，提升用户体验。
下述的步骤S114至S118说明的TUI显示驱动退出TUI模式的过程。
S114，TVM1通知系统已退出TUI模式。
S115，TVM2侧监听服务监听到系统已退出TUI模式。
S116，TVM2侧监听服务向触屏服务通知系统已退出TUI模式。
S117，触屏服务触发TUI触屏驱动退出TUI模式。
S118，TUI触屏驱动退出TUI模式，此时不再监听是否有触屏数据。
在本申请实施例中，TVM1负责完成根据APP指定信息来生成图形界面，TVM2负责将TVM1生成的图形界面显示出来。其中，TVM2的触屏驱动采集触屏数据，并通过消息通道发送给TVM1。其中，触屏数据可以包括触屏位置信息(X，Y)以及UP/DOWN等事件信息。其中，DOWN表示手势事件开始，UP表示结束。
在TVM1接收到TVM2的触屏数据之后，TVM1根据触屏位置信息(X，Y)，UP/DOWN等事件信息进一步做出响应，例如根据触屏位置信息(X，Y)判断用户点击的键盘位置，并根据判断结果确定在TUI的输入框中待显示的内容。其中，待显示的内容可以是字母、数字和/或字符的组合。待显示的内容可以是以下任一项：用户名、账号密码、银行账号。
在实际实现时，在第二TEE的TVM2中预先完成触屏服务和触屏驱动的加载。一旦电子设备的屏幕显示内容切换到TUI界面(进入TUI模式)，触屏驱动实时检测是否存在有效的用户触屏操作，当触屏驱动检测到有有效的用户触屏操作时，触屏驱动获取触屏数据，并且TVM2主动将该触屏数据发送给TVM1。
其中，第一TEE的TVM1只需要监听来自第二TEE的TVM2的触屏数据，不需要向第二TEE的TVM2主动轮询。本申请实施例通过改进目前的软件实现和工作流程，可以对触屏数据流的传输进行优化，解决常规方案下面临的问题。
具体地，本申请方案可以简化两个TVM之间关于触屏数据的交互流程，通过一次主动通知就可以完成触屏数据的传输。在实际实现时，第一TEE的TVM1不需要与第二TEE的TVM2多次交互，简化了实现流程。
一方面，本申请方案可以避免TVM1的大量主动查询。其中由于TVM1查询频率较高时，部分查询可能是无效的，因此通过避免TVM1的大量主动查询，可以避免不必要的交互。在实际实现时，第一TEE的TVM1不需要耗费CPU多次查询，避免无效的查询，节省能耗。
另一方面，本申请方案可以避免因为TVM1查询频率(例如频率较低)带来的可能丢失触屏数据的问题，优化用户体验。在实际实现时，系统不会丢失有效的用户触屏操作，提升用户体验。
由此可见，通过本申请改进后的方案，可以简化业务流程，避免无效的查询，从而节省能耗，并且能够避免丢失用户触屏操作，从而提高用户体验。
需要说明的是，本申请改进后的方案适用于以下场景：TEE直接运行于信任区(TrustZone)环境的场景，也适用于Hypervisor等TVM环境的场景。
通过本申请方案，在多个可信执行环境TEE(如存在两个可信虚拟机TVM1和TVM2)协同提供可信用户界面TUI的场景中，TVM2预先加载触屏服务以及触屏驱动，一旦触屏驱动监听到用户在TUI中输入触屏数据，则TVM2立即向TVM1发送触屏数据，而无需TVM1周期性地向TVM2主动轮询触屏数据。通过本申请改进后的方案，可以简化业务流程，快速获取触屏数据，且不会丢失有效的用户触屏操作，并且可以避免TVM1的大量主动查询以及不必要的交互，提升数据交互效率，提升用户体验。
可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
在采用对应各个功能划分各个功能模块的情况下，电子设备还可以被划分为包括显示单元、检测单元和处理单元等。需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
本实施例提供的电子设备，用于执行上述基于可信执行环境的触屏数据处理方法，因此可以达到与上述实现方法相同的效果。
在采用集成的单元的情况下，电子设备可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理；存储模块可以用于支持电子设备执行存储程序代码和数据等；通信模块，可以用于支持电子设备与其他设备的通信。
其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。
在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图6所示结构的设备。
本申请还提供一种芯片，该芯片与存储器耦合，该芯片用于读取并执行存储器中存储的计算机程序或指令，以执行上述各实施例中的方法。
本申请还提供一种电子设备，该电子设备包括芯片，该芯片用于读取并执行存储器存储的计算机程序或指令，使得各实施例中的方法被执行。
本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的基于可信执行环境的触屏数据处理方法。
本实施例还提供了一种计算机程序产品，该计算机可读存储介质存储有程序代码，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的基于可信执行环境的触屏数据处理方法。
另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的基于可信执行环境的触屏数据处理方法。
其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本申请实施例提供的方法的代码的程序，以根据本申请实施例提供的方法进行触屏数据处理即可。例如，本申请实施例提供的方法的执行主体可以是电子设备，或者，是电子设备中能够调用程序并执行程序的功能模块。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上，或者说对现有技术做出贡献的部分，或者该技术方案的部分，可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，该计算机软件产品包括若干指令，该指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。前述的存储介质可以包括但不限于：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种基于可信执行环境的触屏数据处理方法，应用于电子设备，所述电子设备中包括主虚拟机TVM、第一可信虚拟机TVM和第二可信虚拟机TVM，所述主虚拟机TVM应用于复杂执行环境REE，所述第一可信虚拟机TVM和所述第二可信虚拟机TVM应用于可信执行环境TEE，其特征在于，所述方法包括：
当所述电子设备的操作系统启动时，所述第二可信虚拟机TVM加载用于可信用户界面TUI的触屏服务以及触屏驱动程序，所述触屏驱动程序用于监听在所述可信用户界面TUI中是否有触屏数据；
当所述触屏驱动程序监听到用户在所述可信用户界面TUI中输入触屏数据时，所述第二可信虚拟机TVM向所述第一可信虚拟机TVM发送所述触屏数据。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当所述电子设备的操作系统切换到TUI模式时，所述第二可信虚拟机TVM触发所述触屏驱动程序启用所述TUI模式；
在所述触屏驱动程序启用所述TUI模式之后，所述第二可信虚拟机TVM通过所述触屏驱动程序持续监听是否有触屏数据。
3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
当所述电子设备的操作系统退出所述TUI模式时，所述第二可信虚拟机TVM触发所述触屏驱动程序退出所述TUI模式；
其中，所述触屏驱动程序在退出所述TUI模式后，停止监听是否有触屏数据。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：
所述第二可信虚拟机TVM显示第一用户界面，所述第一用户界面为可信用户界面；
所述第二可信虚拟机TVM接收用户在所述第一用户界面中的触屏操作；
响应于用户的所述触屏操作，所述第二可信虚拟机TVM调用所述触屏驱动程序，采集所述触屏数据。
5.根据权利要求4所述的方法，其特征在于，在所述接收用户在所述第一用户界面中的触屏操作之后，所述方法还包括：
所述第二可信虚拟机TVM确定所述触屏操作满足预设的触屏条件；
其中，所述预设的触屏条件用于判断所述触屏操作是否为有效的触屏操作；
其中，所述触屏操作包括在所述第一用户界面中的预设区域进行输入，所述预设区域为用于输入用户隐私信息的区域。
6.根据权利要求4或5所述的方法，其特征在于，在所述第二可信虚拟机TVM向所述第一可信虚拟机TVM发送所述触屏数据之后，所述方法还包括：
所述第二可信虚拟机TVM接收所述第一可信虚拟机TVM发送的第二用户界面，所述第二用户界面是所述第一可信虚拟机TVM根据所述触屏数据生成的可信用户界面；
所述第二可信虚拟机TVM调用TUI显示驱动程序，从显示所述第一用户界面更新显示为所述第二用户界面，所述TUI显示驱动程序为用于触发显示可信用户界面的驱动程序。
7.根据权利要求4至6中任一项所述的方法，其特征在于，所述主虚拟机TVM运行有客户端应用CA，并且预设有操作系统内核和第一应用程序编程接口API，所述第一API为所述主虚拟机与所述第一可信虚拟机之间的接口函数；
所述第一可信虚拟机TVM运行有可信应用TA，并且预设有第二API、TUI框架和可信执行环境内核，所述第二API为用于调用所述TUI框架的接口函数；
所述第二可信虚拟机TVM预设有为所述可信应用TA提供可信用户界面TUI服务，所述TUI服务包括TUI显示服务和TUI触屏服务，所述TUI显示服务关联TUI显示驱动，所述TUI触屏服务关联TUI触屏驱动；
其中，在所述第二可信虚拟机TVM显示第一用户界面之前，所述方法还包括：
所述客户端应用CA接收到用户对所述客户端应用CA的操作；
所述客户端应用CA调用所述第一API，通过操作系统内核，向所述可信应用TA发起TUI显示请求；
响应于所述TUI显示请求，所述可信应用TA获取所述客户端应用CA对应的第一用户界面；
所述可信应用TA向所述TUI服务发送所述TUI显示请求以及所述第一用户界面；
其中，所述第二可信虚拟机TVM显示第一用户界面，包括：
响应于所述可信应用TA发送的所述TUI显示请求，所述TUI服务调用TUI显示驱动程序，显示所述第一用户界面。
8.根据权利要求7所述的方法，其特征在于，所述可信应用TA向所述TUI服务发送所述TUI显示请求以及所述第一用户界面，包括：
所述可信应用TA调用所述第二API，进入TUI框架，然后通过所述可信执行环境内核以及进程间通信IPC，向所述TUI服务发送所述TUI显示请求以及所述第一用户界面。
9.根据权利要求7或8所述的方法，其特征在于，在所述客户端应用CA接收到用户对所述客户端应用CA的操作之后，所述客户端应用CA调用所述API向所述可信应用TA发起TUI显示请求之前，所述方法还包括：
响应于用户对所述客户端应用CA的操作，判断所述客户端应用CA的待显示界面中是否包含用户隐私信息输入区域；
当所述客户端应用CA的待显示界面中包含用户隐私信息输入区域时，触发所述电子设备从非TUI模式切换到TUI模式；
其中，所述非TUI模式为所述电子设备在所述REE环境中对应的运行模式，所述TUI模式为所述电子设备在所述TEE环境中对应的运行模式。
10.根据权利要求9所述的方法，其特征在于，所述客户端应用CA调用所述API向所述可信应用TA发起TUI显示请求，包括：
当所述电子设备的操作系统切换为所述TUI模式时，所述客户端应用CA调用所述API向所述可信应用TA发起TUI显示请求。
11.根据权利要求1至10中任一项所述的方法，其特征在于，所述第二可信虚拟机TVM向所述第一可信虚拟机TVM发送所述触屏数据，包括：
所述第二可信虚拟机TVM通过第一消息通道，向所述第一可信虚拟机TVM发送所述触屏数据；
其中，所述第一消息通道是通过套接字socket实现数据传输的方式。
12.根据权利要求1至11中任一项所述的方法，其特征在于，所述方法还包括：
当所述电子设备的操作系统启动时，所述第二可信虚拟机TVM加载TUI显示驱动程序。
13.根据权利要求1至12中任一项所述的方法，其特征在于，所述触屏数据包括位置信息和事件信息，所述位置信息用于指示触屏操作的位置，所述事件信息用于指示触屏的事件类型。
14.一种电子设备，其特征在于，包括处理器，所述处理器与存储器耦合，所述处理器用于执行所述存储器中存储的计算机程序或指令，以使得所述电子设备实现如权利要求1至13中任一项所述的方法。
15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至13中任一项所述的方法。
CN202210906314.2A 2022-07-29 2022-07-29 基于可信执行环境的触屏数据处理方法、设备及存储介质 Active CN116049813B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202311511271.9A CN117744068A (zh) 2022-07-29 2022-07-29 可信用户界面的显示方法、设备及存储介质
CN202210906314.2A CN116049813B (zh) 2022-07-29 2022-07-29 基于可信执行环境的触屏数据处理方法、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210906314.2A CN116049813B (zh) 2022-07-29 2022-07-29 基于可信执行环境的触屏数据处理方法、设备及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202311511271.9A Division CN117744068A (zh) 2022-07-29 2022-07-29 可信用户界面的显示方法、设备及存储介质

Publications (2)

Publication Number Publication Date
CN116049813A true CN116049813A (zh) 2023-05-02
CN116049813B CN116049813B (zh) 2023-10-20

Family

ID=86124184

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202311511271.9A Pending CN117744068A (zh) 2022-07-29 2022-07-29 可信用户界面的显示方法、设备及存储介质
CN202210906314.2A Active CN116049813B (zh) 2022-07-29 2022-07-29 基于可信执行环境的触屏数据处理方法、设备及存储介质

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202311511271.9A Pending CN117744068A (zh) 2022-07-29 2022-07-29 可信用户界面的显示方法、设备及存储介质

Country Status (1)

Country Link
CN (2) CN117744068A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110126139A1 (en) * 2009-11-23 2011-05-26 Samsung Electronics Co., Ltd. Apparatus and method for switching between virtual machines
CN106845285A (zh) * 2016-12-28 2017-06-13 北京握奇智能科技有限公司 一种tee系统与ree系统配合以实现服务的方法及终端设备
CN107844243A (zh) * 2017-11-09 2018-03-27 新华三云计算技术有限公司 云桌面触摸屏实现方法及装置
CN109840436A (zh) * 2017-11-29 2019-06-04 阿里巴巴集团控股有限公司 数据处理方法、可信用户界面资源数据的应用方法及装置
CN109992315A (zh) * 2019-04-09 2019-07-09 Oppo广东移动通信有限公司 触摸屏控制方法、装置、终端及存储介质
CN112817697A (zh) * 2021-02-09 2021-05-18 中国银联股份有限公司 面向可信执行环境的虚拟化系统、方法和设备调用方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110126139A1 (en) * 2009-11-23 2011-05-26 Samsung Electronics Co., Ltd. Apparatus and method for switching between virtual machines
CN106845285A (zh) * 2016-12-28 2017-06-13 北京握奇智能科技有限公司 一种tee系统与ree系统配合以实现服务的方法及终端设备
CN107844243A (zh) * 2017-11-09 2018-03-27 新华三云计算技术有限公司 云桌面触摸屏实现方法及装置
CN109840436A (zh) * 2017-11-29 2019-06-04 阿里巴巴集团控股有限公司 数据处理方法、可信用户界面资源数据的应用方法及装置
CN109992315A (zh) * 2019-04-09 2019-07-09 Oppo广东移动通信有限公司 触摸屏控制方法、装置、终端及存储介质
CN112817697A (zh) * 2021-02-09 2021-05-18 中国银联股份有限公司 面向可信执行环境的虚拟化系统、方法和设备调用方法

Also Published As

Publication number Publication date
CN116049813B (zh) 2023-10-20
CN117744068A (zh) 2024-03-22

Similar Documents

Publication Publication Date Title
CN109960582B (zh) 在tee侧实现多核并行的方法、装置及系统
US9280655B2 (en) Application authentication method and electronic device supporting the same
EP3913516A1 (en) File access authority authentication method and electronic device
KR20170098096A (ko) 생체 정보 기반 인증을 이용한 전자 장치들 간 연결 방법 및 장치
US11042398B2 (en) System and method for guest operating system using containers
WO2020167949A1 (en) Graphics processing unit accelerated trusted execution environment
CN108235767B (zh) 一种支付应用的隔离方法、装置及终端
US20140258734A1 (en) Data security method and electronic device implementing the same
CN109992965B (zh) 进程处理方法和装置、电子设备、计算机可读存储介质
EP4187419A1 (en) Security architecture system, security management method, and computing device
CN112528288A (zh) 可信应用的运行方法、信息处理和内存分配方法及装置
EP4030680A1 (en) Application processing method and related product
CN109416800A (zh) 一种移动终端的认证方法及移动终端
US11948233B2 (en) Image display method and electronic device
CN116049813B (zh) 基于可信执行环境的触屏数据处理方法、设备及存储介质
KR102411608B1 (ko) 보안 네트워크 시스템 및 그 데이터 처리 방법
CN114826785B (zh) 一种动态防护方法、系统级芯片、电子设备及介质
CN107851140A (zh) 利用压力触控生成密码的方法及装置
CN115544586A (zh) 用户数据的安全存储方法、电子设备及存储介质
CN113673676B (zh) 电子设备及神经网络模型的实施方法、片上系统和介质
US20140259155A1 (en) Process authentication method and electronic device implementing the same
CN116415247A (zh) 一种容器安全校验的方法及装置
CN116089924A (zh) 一种权限数据访问的方法、装置、计算机设备和存储介质
WO2015081829A1 (en) Method, device and system for preventing execution of remote codes of application operation in a browser
CN106874746B (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