具有可信执行环境的移动设备的制作方法

本发明一般地涉及移动设备，并且更特别地涉及向移动设备供应可信执行环境和贯穿这样的可信应用的生命周期在移动设备上加载和执行的可信应用的安全的管理。

在移动通信设备的简短历史中，设备已经从被主要或甚至排他性地专用于移动电话通信迅速地演进成是非常强大的多用途设备。随着最近的技术发展，使用移动设备（例如，移动电话）用于不同的应用，诸如支付、交通购票、忠诚计划、银行账户访问、对建筑物或办公室的物理访问控制等，现在是可能的。近场通信是一种使这些新功能在移动设备上可能的使能技术。

安全是针对这些功能中的许多功能的导入标准；例如，对于成功商业程序而言，能够具有移动交易是安全的并且不容易被想要窃取信息（诸如在使交易安全中使用的账号、交易模式、个人数据或密码密钥）的攻击者拦截的置信度，这通常是必要因素。

可信执行环境（tee）提供一种用于在某些移动设备上执行的应用的增强安全的机制，所述可信执行环境（tee）是移动设备的主处理器的安全区域。可信执行环境以硬件实现。tee为可信应用提供隔离的执行环境，由此提供更高级别的安全。

globalplatform™发布了用于在安全芯片技术上安全计算的规范，包括提供标准化的可信执行环境（tee），所述标准化的可信执行环境（tee）包括确保敏感数据在可信环境中被存储、处理和保护的主处理器中的安全区域。globalplatform提供标准应用程序接口（api），通过所述标准应用程序接口（api），应用程序（也称为应用程序（app））可以访问由globalplatform可信执行环境的安全处理器区域提供的安全功能。

商业tee技术方案的一个示例是来自英国cambridge的arm公司的armtrustzone技术，armtrustzone，http://www.arm.com/products/processors/technologies/trustzone/。trustzone技术被紧密集成到处理器中同时将处理器的外部的安全环境扩展到例如外设（诸如存储器和加密块），以允许安全意识应用（例如，可信应用）的系统范围安全。

不幸的是，许多移动设备没有配备以硬件实现可信执行环境的技术。然而，那没有减少对在这样的更多限制的设备上以可信执行环境的方式提供安全计算功能的需要。否则，在设备上执行的应用易受恶意软件和可能揭露设备的用户的秘密信息或对用户或对服务提供者造成经济损失的广泛的可能攻击的攻击。

根据前述内容将显而易见的是，仍然存在对用于提供灵活的、方便的并且又强大的机制以向没有配备在它们的处理器的硬件中实现的安全区域的设备提供安全的可信执行环境的改进的方法的需要。理想地，这样的解决方案与例如如由globalplatform提供的可信执行环境解决方案的硬件实现兼容，使得可以开发在基于处理器的可信执行环境上以及在不要求这样的硬件的替代机制上执行的应用程序。

根据前述内容将显而易见的是，仍然存在对用于在缺乏硬件tee的具体硬件特征的移动设备上提供与硬件实现的tee相当的安全增强的改进的方法的需要。

技术实现要素：

本发明的实施例的各方面一般地涉及一种用于保护用于在移动设备上执行的移动应用的方法，包括：

移动设备被配置成：

将来自不可信应用提供者的移动应用的不可信部分加载到移动设备上；

将来自可信应用提供者的移动应用的可信部分加载到移动设备中；

将移动应用的可信部分安装在移动设备上，由此提供可信执行环境。

根据本发明的实施例，将移动应用的可信部分加载到移动设备中包括以下步骤：

移动应用根据移动应用的标识符和移动设备的设备指纹来生成可信执行环境idteeid；所述生成的可信执行环境idteeid由移动应用传输到密钥供应服务器；

操作密钥供应服务器以生成要与可信执行环境idteeid相关联的密钥并将可信执行环境idteeid和生成的密钥传输到密钥导向器并将生成的密钥传输到移动设备；

可信应用提供者被配置成接收teeid并且根据由移动设备发送的生成的密钥来计算的teeid的散列，并且被配置成通过密钥导向器服务器来认证移动设备；

在成功认证移动设备时，操作可信应用提供者以将包括可信应用的移动应用的可信部分传输到移动设备；以及

移动设备被配置成将移动应用的可信部分安装在移动设备上，由此提供可信执行环境。

根据本发明的实施例，移动应用的不可信部分包括：

客户端应用，其在移动设备的丰富执行环境中可执行；以及

可信应用解释器，其用于可以在其中实现可信应用的指令集。

根据本发明的实施例，可信应用在由可信应用解释器可解释的指令集中实现。

根据本发明的实施例，与移动应用相关联的密钥包括白盒密钥“wbc密钥”和初始pin加密密钥“ipek”，并且其中，方法进一步包括在将与移动应用相关联的密钥传输到移动设备之前使用wbc密钥对ipek加密，并且其中，ipek的加密的版本被传输到移动设备。

根据本发明的实施例，在由可信服务器提供者传输到移动设备之前，用根据初始pin加密密钥“ipec”生成的会话密钥来加密移动应用的可信部分。

根据本发明的实施例，移动应用的不可信部分包括实现与可信执行环境的硬件实现类似的功能的应用程序接口。

根据本发明的实施例，用于保护用于在移动设备上执行的移动应用的方法包括以下步骤：

将可信应用与可信安全存储设备相关联；以及

将初始随机秘密存储在移动设备的安全存储设备中；以及

在对可信应用的安全存储设备中的数据的每次访问时，使用初始随机秘密“irs”、设备指纹和用于可信应用的唯一id“uuid”来生成用于对存储在与可信应用相关联的可信存储设备中的数据加密的安全存储数据密钥“ta_sk”。

根据本发明的实施例，用于保护用于在移动设备上执行的移动应用的方法包括以下步骤：

在可信应用的执行期间：

确定与可信应用的该特定执行相关联的一次性运行时密钥；

当在可信应用的该特定执行期间将量存储到由可信应用使用的运行时存储器中时，使用一次性运行时密钥来对量掩蔽；以及

当在可信应用的该特定执行期间从由可信应用使用的运行时存储器取回量时，使用一次性运行时密钥来对量取消掩蔽。

根据本发明的实施例，用于保护用于在移动设备上执行的移动应用的方法包括以下步骤：

在对具有用于执行或解释的编译形式的可信应用的第一次运行时，基于可信应用的编译形式来计算第一值并且基于可信应用的编译形式来存储该值；

在可信应用的随后执行时，基于可信应用的编译形式来执行相同的计算以基于可信应用的编译形式来产生第二值，比较第一值与第二值，并且如果第一值与第二值不是相同的则采取校正动作。

根据本发明的实施例，用于保护用于在移动设备上执行的移动应用的方法进一步包括通过以下操作来针对潜在时移攻击保护：

在软件可信执行环境的第一执行时确定用于移动应用的特定指令的预期执行时间；

存储针对所述某些指令的预期执行时间；

在软件可信执行环境的随后执行期间：

跟踪指令计数；

周期性地取出系统时钟；

根据当前指令计数来计算预期执行时间；

比较当前系统时钟与预期执行时间；以及

如果比较指示不可接受的偏差，则采取校正动作。

根据本发明的实施例，特定指令是对应用程序接口的函数的调用。

根据本发明的实施例，用于保护用于在移动设备上执行的移动应用的方法包括以下步骤：

用具有多个循环的虚设代码段来修改可信应用的关键部分，所述多个循环中的每个可以作为短循环或作为长循环来执行；

将多个检查点分配在虚设代码段中并且与可信应用的所述关键部分相邻；

在对可信应用的执行时，确定通过虚设代码的执行路径，其中，执行路径执行定义数量的短循环和长循环；

确定针对每个检查点的预期到达时间；以及

在到达检查点时，比较实际到达时间与预期到达时间，并且如果实际到达时间与预期到达时间之间的偏差超出预定阈值则采取校正动作。

附图说明

图1是图示其中移动应用可以从应用程序商店被加载到移动计算设备上并且用于访问来自服务提供者（sp）的服务的环境的框图。

图2是图示图1的网络的更多细节的高级示意图。

图3是图示图1和2的移动设备的硬件部件的框图。

图4是图示可以被存储在图1、2和3的移动设备的存储器中的包括应当被保护免受攻击的数据的示例性软件模块和数据的框图。

图5是图示根据一个实施例将移动应用程序加载到图1、2、3和4的移动设备上并且将这样的移动应用程序的安全方面初始化的步骤的流程图。

图6是图示根据实施例的具有用于移动应用的可信执行环境的移动设备的实施例的框图。

图7是图示可信应用与可信存储区域之间的关系的框图。

图8是图示在移动应用被加载在其上的移动设备与用于执行在图6的可信应用的供应中使用的密钥多样化的可信服务管理器集线器之间的连接的连接图。

图9是图示允许安全供应可信应用的密钥多样化的时序图。

图10是图示将来自在图9中图示的过程的白盒密码密钥用作用于保护用于图6的可信应用的存储的信任根（root-of-trust）的数据流图。

图11是图示对运行时存储器的部分加密以防止从运行时存储器转储（dump）恶意提取数据的时序图。

图12是图示用于检测可信应用的操纵的一个实施例的机制的流程图。

图13是图示其中时钟完整性检查被用于防止时钟变更攻击的实施例的机制的流程图。

图14是图示移动应用程序的示例执行的执行路径图，其中已知持续时间的选择的循环的执行时间例如通过调试器的使用来检查以确定可能的操纵。

图15是图示在运行时期间的执行路径的随机化的流程图，其中随机化的执行持续时间被检查以确定可能的操纵。

具体实施方式

在以下详细描述中，对附图做出了参考，所述附图通过图示的方式示出了其中可以实施本发明的具体实施例。足够详细地描述这些实施例以使本领域技术人员能够实施本发明。要理解，本发明的各种实施例（尽管不同）不必是相互排斥的。例如，在本文中结合一个实施例描述的特定特征、结构或特性可以在其他实施例内实现。此外，要理解，在不脱离本发明的精神和范围的情况下，可以修改每个公开的实施例内的各个元素的位置或布置。因此，不将以下详细描述看作是限制的意义，并且本发明的范围由适当地解释的所附权利要求限定。在附图中，相同的标号贯穿若干视图指代相同或相似的功能。

在本发明的实施例中，呈现了提供一种机制的技术，通过所述机制使可信执行环境（tee）在没有配备用于支持可信执行环境的硬件机制的移动设备上可用。呈现的机制允许可信应用被开发，在针对标准硬件支持的可信执行环境的应用程序员接口被开发时，所述可信应用可以被最终用户和服务提供者同样信任，由此允许针对在本文中描述的机制开发的应用容易移植到这样的基于硬件的可信执行环境。

图1是网络111的示意性图示，所述网络111将移动设备103连接到一个或多个远程服务提供者（sp）服务器113。sp可以提供大量的可能的服务中的任何服务。典型的示例包括在线银行业务、在线商务、在线教育（instruction）、在线投票等。如本文的读者理解的那样，在这些示例中，交易的安全是极其重要的。

用户101操作移动设备103以通过网络与sp服务器113中的一个交互。使用被下载到移动设备103的专用应用程序来有利地执行这样的交互。这样的专用应用程序（也被称为应用程序）向用户提供特征丰富环境，用户101通过所述特征丰富环境与服务器应用交互。用户可以从应用程序商店115获得应用程序。应用程序商店115的示例包括由美国california的cupertino的苹果公司针对用于诸如iphone和ipad的ios设备的应用程序提供的应用程序商店、由美国california的mountainview的谷歌公司提供的googleplay应用程序商店以及由美国washington的redmond的微软公司提供的windows商店。

如本文的读者理解的那样，对于许多在线交易，安全是至关重要的。因此，应用程序本身必须是可信的并且由应用程序管理的数据必须被保护。

图2是图示网络111的更多细节的高级示意图。每个订户移动设备103通过移动网络运营商（mno）117与其他网络设备通信，设备103的用户101是对移动网络运营商（mno）117的订户，例如，mno117可以是移动电话服务的提供者。

如果个体服务提供者（sp）必须与每个个体移动网络运营商交互以传送消息、管理应用、供应服务以及供应安全机制，则不管作为交易的部分还是作为部署的部分，混乱将接着发生。因此，被称为可信服务管理器（tsm）的中心参与者被引入globalplatform中以管理sp与mno之间的通信。

图2提供了可信服务管理器（tsm）可以如何结合服务提供者（sp）和移动网络运营商（mno）起作用的示例。每个tsm119¹建立服务提供者（sp）115与移动网络运营商（mno）117之间的链接，所述每个tsm119是计算机硬件119-c和软件（未图示）的组合。每个tsm可以将多个mno连接到多个sp。反之，给定sp115或mno117可以被连接到tsm119或多个tsm119。

图3是移动设备103的示意性图示。移动设备103可以包括经由总线202连接到随机访问存储器（ram）203、只读存储器（rom）204以及非易失性存储器（nvm）205的处理器201。移动设备103进一步包括用于再次通常经由总线202将处理器201连接到天线211的输入/输出接口207，移动设备103可以通过所述天线211被连接到主机计算机或其他外围设备。

nvm205可以包括如在图4中被图示的计算机程序301。尽管此处描绘了计算机程序301全部都共同位于nvm205中，但是在实际实施中，不存在这样的限制，因为程序可以被分布在多个存储器上并且甚至被临时安装在ram203中。此外，移动设备103可以包括多个rom或nvm。程序301包括操作系统程序以及加载到移动设备103上的应用程序。移动应用程序215的nvm205还可以包含私有数据，诸如以其基本形式或以导出量存储的私有密钥212或共享秘密密钥209，以及诸如账号的其他用户私有信息214。以下在本文中描述了用于保护这样的数据的机制。

移动设备103程序301可以包括密码模块213、通信模块217以及操作系统os219。

如以上在本文中讨论的那样，移动应用程序215可以被用于对非常敏感的数据操作，例如访问在线银行账户，以及提供对秘密数据的访问。为了保护这样的移动应用程序215，提供了将移动应用程序215划分成两个部分的技术，所述两个部分在本文中被称为不可信部分和被称为可信部分。不可信部分是在由移动平台（例如，ios或android）提供的丰富执行环境（ree）501中执行的该部分。不可信部分因此可以提供由移动平台提供的丰富用户体验，而开发者和服务提供者不需要关心该部分的安全漏洞。换言之，将不可信部分的分发转存（unload）到不可信的分发器（例如，应用程序商店）上被认为是安全的。

另一方面，可信部分是对其而言需要安全措施的移动应用程序215的部分。那些部分通过安全通道从可信站点被下载并且通过密码被进一步保护。

图5是图示根据一个实施例的加载和初始化安全移动应用程序215的步骤的流程图。用户101（或诸如移动网络运营商117的另一个参与者）将不可信部分安装到移动设备103的nvm205中，步骤551。如在图5中图示的那样，初始步骤551可以包括从应用程序商店下载不可信部分，所述应用程序商店例如针对ios设备的苹果公司应用程序商店或针对android设备的googleplay。结合下面的图6讨论不可信部分的细节。

加载和保护移动应用程序215的可信部分可以在对移动应用程序215的第一次使用时发生，步骤553，通常在引导模块509的支持下。在子步骤555中，从被称为供应服务器的可信服务器（例如，可信服务管理器119、服务提供者或可以被认证的服务提供者的代表）下载可信部分。结合图6讨论了移动应用程序215的可信部分的部件的细节，然而，注意，每个移动应用程序215由一个或多个可信应用519组成。

移动应用程序215的可信部分和不可信部分的加载可以后面跟着步骤557，所述步骤557以某方式将这些部分相关联，使得来自不可信部分的方法调用到达预期的可信应用219处，并且相关联步骤可以包括链接步骤。

用于保护可信部分和存储在与可信应用219相关联的可信存储设备中的数据的机制依赖于密码密钥。在移动应用的初始运行期间，密钥供应步骤559被执行以获得必要的密钥。以下例如结合图8和9更详细地描述密钥供应步骤559。

然后，一旦可信部分已经被加载并与不可信部分链接，移动应用程序215就被执行，步骤561。

图6图示了用于为移动应用215提供可信执行环境的一个实施例。在高级别处，移动应用程序215包括两个部分，不可信部分和可信部分。前者可能从不可信源被下载并且不需要被保护。不可信部分包括在由移动平台os提供的丰富执行环境（ree）501中执行的移动应用程序215的元素以及不需要被保护的可信执行环境的基础设施部分。可信部分从可信源被加载，被密码地保护，并且然后通过被并入到移动应用程序215中的软件可信执行环境（软tee）503执行。

移动平台os的虚拟机解释器515解释移动应用程序215的不可信部分的指令。

诸如智能电话的移动平台提供丰富执行环境（ree）501。ree501提供广泛和灵活的功能的指令表（repertoire），可以从所述功能的指令表构建强大的、有吸引力的和有用的移动应用程序215。智能电话的任何用户在电话可以被用于的许多事物和由用户可以在每天的基础上使用的各种应用程序提供的聪明用户界面处。尽管ree提供了丰富和强大的执行环境，但是ree使设备易受可能损害设备的用户的敏感的或有价值的信息的攻击的攻击。在本文中描述的技术提供一种机制，通过所述机制，这些安全风险通过将软tee503引入到移动应用程序215中来减轻。

在步骤551中加载的不可信部分包括在ree501中执行的移动应用程序215的部分。这些ree部件507包括客户端应用505、引导模块509、ree代理511以及安全应用api513。引导模块509包含用于将从供应服务器供应的密钥编组（marshal）、可信部件的初始加载以及链接部件的指令。ree代理511提供一种机制，通过所述机制，移动应用程序215可以与外部服务器（特别地，可信服务管理器119）交互。ree代理511进一步与发行者安全域（isd）529对接。为具体globalplatform应用分配的存储器区域可以在被称为安全域（sd）的安全区域中被管理。安全域是设备外授权的设备上代表。安全域（sd）支持安全服务，诸如密钥处理、加密、解密、数字签名生成和针对与每个sd相关联的实体（例如，发行者或可信服务管理器）的应用的验证。每个sd代表特定参与者被建立，所述特定参与者例如卡发行者（发行者安全域）、应用提供者（应用安全域）或tsm（tsmsd）。sd被建立以将来自一个参与者的密钥和其他安全信息与其他参与者隔离，并且反之亦然。

因此，isd发行者安全域是与设备的发行者相关联的移动设备上的安全域并且用于管理与发行者相关联的密钥。在步骤551中的移动应用程序的初始加载期间，isd529可以被下载到移动设备103。

安全应用api513可以例如是如在teeclientapispecificationv1.0|gpd_spe_007，globalplatform，2011年12月（http://www.globalplatform.org/specificationsdevice.asp）中定义的globalplatform客户端api的实现。移动应用程序215的非安全部分使用安全应用api513访问移动应用程序215的安全部分。在globalplatform中，可信执行环境（tee）以硬件实现并且由应用使用globalplatform客户端api来访问。在一个实施例中，安全应用api513被实现为仿真globalplatform客户端api，使得移动应用程序215可以被写入一次并且在具有tee的硬件实现的设备上执行或者使用如在本文中描述的软tee503。因此，通过将安全应用api513实现为globalplatform客户端api仿真，移动应用程序215容易被移植到实现globalplatformtee的设备。

在步骤551中，安全应用api513可以在移动应用程序的初始加载期间被下载到移动设备103。

因此，为了克服ree501的安全风险，在移动应用215中提供软件可信执行环境（软tee）503。在初始下载步骤551中，软tee503基础设施与ree部件507一起下载。

软tee虚拟机（软teevm）517是软tee503的中心部件。在初始下载步骤551中，可以下载软teevm517。软teevm517在移动应用程序215内提供仿真层。软teevm517执行与主机环境的指令集不同的指令集并且因此不应当与机器的本地虚拟机解释器515混淆。在软tee503中执行的程序，例如可信应用，针对该特殊指令集被编译并且得到的可信应用二进制文件（binary）519由软teevm517解释。

整个软tee503系统在软teevm517内执行以确保与客户端应用505执行隔离。当客户端应用505请求对由软tee503保护的资源的访问时，所述客户端应用505对安全应用api513进行调用。软teevm517取回这些请求并将这些请求分派到对应的可信应用519。

如以上讨论的那样，针对由软teevm517可解释的指令集编译可信应用519。为了访问tee503的功能，可信应用经由内部安全应用api525使用对tee内核527的调用。

可信执行环境的重要功能是用于将需要被保护的数据条目与不可信部件（诸如客户端应用程序505）隔离。因此，软tee503包括可信存储设备523。可信存储设备523的部分与每个可信应用519相关联。图7是图示在可信应用519与可信存储区域523之间的关系的框图。存储在可信存储区域523中的数据分别用数据加密密钥（例如，可信应用存储密钥701）来加密。作为密钥供应步骤559的结果，可信应用存储密钥701被提供给可信应用519，这在下面被更详细地描述。

此外，在密钥供应步骤559期间移动应用程序215的个性化包括向软tee503供应个性化的密码密钥材料521，所述个性化的密码密钥材料521被用于安全地接收可信应用519以及用于针对每个可信应用519导出可信应用存储密钥701。

图8是图示在移动应用被加载在其上的移动设备103与用于执行在图6的可信应用的供应中使用的密钥多样化的可信服务管理器集线器605之间的连接的连接图。

移动设备103被连接到可信服务管理器119，并且如在图2中描绘的那样，连接可以是经由移动网络运营商117的。

可信服务管理器119可以与若干相关服务器（例如，密钥供应服务器601和密钥目录服务器603）一起被共同定位在本文中我们可以将其称为可信服务管理器集线器605中。可信服务管理器集线器605的这些部件与移动设备103合作以提供软件tee503来增强移动应用215的安全。

密钥供应服务器601的主要作用是用于生成白盒密码密钥和初始pin加密密钥（ipek），其被用于对应于移动应用215的ree部件507的可信应用519的供应中。在s.chow、p.eisen、h.johnson、p.c.vanoorschot于2002年8月15-16日的第9届annualworkshoponselectedareasincryptography（关于密码学中的选择领域的年度研讨会）（sac2002）的white-boxcryptographyandanaesimplementation中以及在julienbringer、hervechabanne和emmanuelledottax的whiteboxcryptography:anewattempt，cryptologyeprintarchive，报告2006/468，2006年中描述了白盒密码，两者都通过引用并入到本文中。

私有密钥pr.k.kps与密钥供应服务器相关联以允许其对其产生的密钥签名。

密钥目录服务器603的主要作用是用于维持与用于软件tee503的唯一标识符相关联的ipek密钥的数据库，所述软件tee503用于在特定设备103上执行的移动应用程序215的特定实例化。该目录在本文中被称为密钥目录607，该目录可以是数据库表。用于软件tee的唯一标识符在本文中被称为teeid并且在下面被更详细地描述。给定特定teeid，密钥目录服务器可以向询问客户端（例如，可信服务管理器119）提供对应的ipek。

在将可信应用519提供给移动设备103的上下文中的可信服务管理器119的主要作用是用于从移动设备103接收针对可信应用519的请求。请求包括一种机制，通过所述机制，移动设备103（具体地，移动应用215）可以识别其本身并且证明其真实性（即，通过提供teeid和ipek）。在一个实施例中，如以下在本文中描述的那样，ipek由移动设备103以散列的形式来提供。

图9是图示允许安全供应可信应用的密钥多样化的时序图。作为初步步骤（未示出），移动应用程序215的ree部件例如从应用程序商店被下载到移动设备103。

步骤701。移动应用215（具体地，移动应用215的ree部件）在其在移动设备103上执行时确定用于移动应用215的唯一标识符（teeid）。换言之，teeid依赖于应用和设备两者。在一个实施例中，teeid被计算为依赖于被分配给应用的通用唯一标识符（uuid）和移动设备103的设备指纹。这些可以例如被用于产生散列或者可以被并置（concatenate）以创建teeid。

设备指纹可以被计算为应用标识符、唯一os标识符、移动设备103的无线电系列以及移动设备103的imei的并置的散列，例如sha1。应用标识符是应用的封装名称（作为示例，com.companyname.appname）。唯一os标识符是由底层os提供的参数，诸如用于androidos中的androidid和ios中的卷uuid。无线电系列是移动设备上的无线电单元的系列号。imei（国际移动台设备标识）是被分配给移动设备的唯一号码并且在第3代合作伙伴计划的3gppts23.003规范中被指定。

步骤703。将teeid从移动应用程序215传输到密钥供应服务器601。

步骤705。密钥供应服务器601从移动应用程序215接收teeid并且生成要与teeid相关联的初始pin加密密钥（ipek）和动态白盒密码密钥（wbc密钥km）。

在优选实施例中，ipek是由密钥供应服务器601生成的唯一随机aes-256密钥。aes-256是使用256位密钥的高级加密标准的版本。

白盒密码在本文档的范围之外。然而，以下要点对理解在本文中呈现的技术是有用的。白盒密码被用于保护超出分发器的访问控制执行分发的分发的材料。例如，在当前上下文中，移动设备超出设备的发行者的控制以及超出服务提供者的控制，所述服务提供者可以分发应用程序用于在移动设备上使用。白盒密码使用模糊技术来保护分发的材料。在步骤3（705）中，白盒密码库（wbc）二进制文件被创建以包含包括teeid的散列的唯一随机aes-128密钥、使用白盒密码技术被隐藏在aes加密的消息中的wbc密钥。

步骤707。由密钥供应服务器601使用wbc密钥对ipek密钥加密。

步骤709。teeid和ipek密钥被传输到密钥目录服务器603。

步骤711。密钥目录服务器603将teeid和ipek密钥相关联并且将它们存储在密钥目录607中。

步骤713。与将teeid和ipek密钥发送到密钥目录服务器603同时，密钥供应服务器601将wbc密钥库和加密的ipek密钥传输到移动应用215。

步骤715。移动应用215安装wbc库。通过安装wbc库，移动应用215可以使用所述库来解密使用库加密的信息，在该情况中，ipek密钥。

步骤717。移动应用215使用wbc库来解密ipek密钥。

步骤719。ipek密钥被存储到发行者安全域（isd）529中，其与移动应用程序215的不可信部件一起在图5的步骤551中被下载。

步骤723。移动应用215将teeid和使用ipek的teeid的散列（hmac（teeid，ipek））传输到可信服务管理器605。

步骤725。可信服务管理器605将teeid和散列（hmac（teeid，ipek））转发到密钥目录服务器603以验证存在匹配。当密钥目录服务器603维护teeid和对应的ipek的表（以上的步骤711）时，密钥目录服务器603可以验证在步骤723中从移动应用程序215传输到可信服务管理器605的散列与人们根据正确ipek将预期的散列匹配。

步骤727。如果密钥目录服务器603已经确认ipek和teeid对应关系，则密钥目录服务器603将ipek传输回到可信服务管理器。

步骤729。可信服务管理器605存储ipek。可信服务管理器605还用利用ipek生成的会话密钥对ta519加密。

步骤731。可信服务管理器605将加密的ta519传输到移动应用程序215。

步骤733。移动应用程序215使用根据ipek生成的会话密钥对ta519解密并将ta519安装到软tee503中。

由此，移动应用程序215已经被完成以包括可信部件、密钥材料521和ta519以及最初下载的不可信部件。

如以上指出的那样，对应于每个可信应用519的可信存储设备523由可信应用存储密钥（ta_sk）701保护。图10是图示这些存储密钥的生成的流程图。

步骤1001。由移动应用程序215生成初始随机秘密（irs）。

步骤1003。irs由移动应用程序215使用来自图9的步骤705并在步骤713中被提供给移动应用程序的动态白盒密码密钥（wbk）来加密。

步骤1005。加密的irs由移动应用程序215存储在由nvm205中的移动应用程序215管理的文件存储设备中。

在替代实施例中，步骤1001到1005由用户输入pin来替换。pin未被存储。而是，如以下在步骤1009中讨论的那样，其必须在每次执行时被正确地重新输入，否则计算的存储密钥将与在第一次执行时使用的存储密钥不匹配。

步骤1007。与步骤1001-1005同时，由移动应用程序215计算设备指纹（dfp）。dfp可以通过应用标识符、唯一os标识符、无线电系列号和设备的imei号的并置的sha1来计算。

图10的前述步骤被有利地执行一次，其中结果（即，加密的irs和dfp）被存储在nvm205中。以下步骤是当访问可信存储设备时使用的运行时步骤。

步骤1009。在运行时，针对每个ta519，使用例如在rfc5869中指定的基于hmac的密钥导出函数（ietf，基于hmac的提取和扩展密钥导出函数（于2015年9月3日访问的http://tools.ietf.org/html/rfc5869））来计算ta存储密钥（ta_sk）701。对hash函数的输入包括irs、dfp和ta519的uuid。在使用用户pin的替代实施例中，针对pin提示用户。最初输入的pin未被存储。然而，因为对于每次执行，pin被用于计算ta存储密钥，所以必须输入正确的pin以在随后的执行时在步骤1009中计算出正确的ta_sk。

步骤1013。当可信应用519寻求对其对应的存储设备523的访问时，可信应用701使用其存储密钥ta_sk701对来自可信存储设备523的存储或取回的内容加密或解密。

对针对移动应用程序215的攻击的一个弱点是在移动应用程序215的执行期间攻击由移动应用程序215使用的ram中的存储器区域。在移动应用程序215的执行期间攻击者可以执行对存储在ram203中的数据的存储器转储，并且试图从存储在ram203中的内容取回敏感信息，诸如账号、密码密钥、个人标识符等。

为了阻挠这样的攻击，在本文中的实施例对由移动应用程序215使用的运行时存储器的部分加密，以便防止从运行时存储器转储恢复有意义的数据。图11是图示该实施例的时序图。在软tee515内部执行的每个可信应用519可以从堆或栈访问ram203。针对每个ta519的堆或栈与任何其他可信应用519的堆或栈分离和隔离。

如以上在本文中结合图9讨论的那样，例如，密钥供应服务器601生成包括wbc密钥km的白盒密码库并且将该库传输到移动应用程序215，步骤705和713。在步骤715中，移动应用程序215安装wbc库。

根据本实施例，可信应用通过使用一次性密钥（otk）对数据加密来对存储在ram203中的数据加密：

e=明文xorotk（e=plaintextxorotk）

如下导出otk：

步骤1101：ta519生成随机数（nonce）使得其对于可信应用519的每次执行是唯一的。在优选实施例中，使用随机数来生成otk。然而，可以使用替代机制来生成otk，在这种情况下，随机数可以不是必需的。

步骤1103：ta519使用随机数生成器来生成运行时密钥kr。在优选实施例中，使用随机密钥来生成otk。然而，可以使用替代机制来生成otk，在这种情况下，随机密钥kr可以不是必需的。

在每次存储操作1104时，生成与可信应用519的存储器位置和特定执行相关联的otk，所述otk被掩蔽以便存储，使用otk来加密要被存储在ram中的明文，并且丢弃otk。

步骤1105：生成otk。在优选实施例中，使用以下公式来生成otk：

otk=enc(mem_addr||计数器||随机数,kr)（otk=enc(mem_addr||counter||nonce,kr)）

其中，

mem_addr是要被加密的（一个或多个）存储器页的开始地址，

计数器是（1）在ta519的每次执行时重置并且在每次存储器访问时被递增的计数器，以及

enc是加密函数，其中使用密钥kr来加密并置mem_addr||计数器||随机数

步骤1107：otk被掩蔽。在优选实施例中，ta519使用wbc密钥km来掩蔽otk：

otkm=otkxorkm

步骤1109和1111：掩蔽的otk，即otkm被存储在ram203中。

步骤1113：使用otk来掩蔽要被存储的量的明文：

e=明文xorotk；

步骤1115和1117：掩蔽的量e被传递到ram203并且被存储在ram203中。

步骤1119：丢弃otk。因此，用于在存储在ram中之前掩蔽明文的实际密钥（otk）从未被保留；而是，otk的仅掩蔽的版本otkm被保留并且仅当其被第一次成功地取消掩蔽时其才可以被使用。

反之，在用于读取存储在ram203中的值的每个操作时，掩蔽的otk被取回和取消掩蔽，加密的量被解密成明文，并且丢弃otk，步骤1121。

步骤1123：ta519取回先前在写操作期间存储的掩蔽的otk，即otkm。

步骤1125：使用白盒密钥km从otkm对otk取消掩蔽。

步骤1127：取回加密的量e。

步骤1129：将加密的量e解密成明文：

明文=exorotk（plaintext=exorotk）

步骤1131：再次丢弃otk。

因此，提出了针对攻击保护运行时ram的技术，所述攻击利用存储器转储来恶意地辨别移动应用程序的机密信息。

通过虚拟机执行的软件应用易受基于应用的静态或运行时实例化的变更的攻击的攻击。例如，攻击者可能检查应用并且变更应用试图提取由应用操纵的保护的内容以及操纵应用的行为以使其直接地或以对于攻击者而言以某种方式辨别保护的内容是可能的形式揭露保护的内容。

为了阻挠这样的攻击，本技术的实施例采用若干技术中的一个或多个。

其在图12中被图示的这样的技术中的第一个技术用于提供应用完整性检查。当移动应用程序215的可信应用519被第一次安装到软tee503中时，软tee虚拟机517计算比较值，例如与可信应用519对应的散列值，步骤1201。比较值可以是在可信应用519二进制文件上计算的hmac-sha256mac散列代码。比较值然后被存储在可信容器中，例如被前置于（prependedto）ta519二进制文件，步骤1203。

在每次执行时，当ta519再次由软tee虚拟机517加载时，相同的比较值计算在二进制文件上被执行并且与第一次加载的存储的计算的比较值（称为“当前值”）比较，步骤1205。在步骤1207中，做出存储的比较值与当前比较值是否不同的决定。如果它们相同，则软tee虚拟机517将加载并且执行ta519。如果它们的确不同，则软tee虚拟机517拒绝加载ta519并且发出校正动作，诸如向用户、发行者或服务提供者通知潜在的攻击，步骤1209。

在针对移动应用程序215的另一个可能攻击中，攻击者变更时钟速率或执行时移；后者对数字版权管理drm应用而言是特别关注的。因此，为了阻挠这样的攻击，在另一个实施例中，ta519可以附加地或替代地使用时钟完整性验证技术来验证。图13是图示时钟完整性验证技术的流程图。

为了防止时钟变更攻击，在例如在步骤555或附属步骤555中安装移动应用程序215的可信部分时，可信部分的某些指令（例如，通过软tee503的虚拟机517对内部安全api525中的具体功能的调用）的执行时间被测量，步骤1301，并被记录在安全存储设备1303中，步骤1302。在执行移动应用程序215时执行时钟验证1305。在执行移动应用程序215时，启动软tee虚拟机517，步骤1307，并且软tee虚拟机517保持跟踪指令计数，步骤1309。周期性地，软tee虚拟机517通过取出系统时钟来执行时钟验证检查1311，步骤1313，根据指令计数来计算预期时间，步骤1315，并比较系统时钟与预期时间，步骤1317。如果预期时间与系统时间之间的差相对于某预定阈值是超出范围的，则可以采取某校正动作，步骤1319，例如，停止移动应用程序215或对关于哪些硬件资源可以由移动应用程序215访问设置约束。在一个实施例中，如果n数量的指令将花费一定数量的时间t并且因此在已经对特定指令计数（例如，m*n）跟踪之后，将预期的是执行时间将是m*t。与那的偏差超出特定阈值将触发校正动作。

针对移动应用程序215的攻击可以包括在由虚拟机515执行的同时使用调试技术来检查移动应用程序215的关键功能。在本文中描述的技术的实施例还可以包括用于阻挠这样的检查攻击的技术，这样的检查攻击在可信应用519的安装期间通过对添加到可信应用519的短循环和长循环基准测试（benchmark）来绕过反调试技术。图14是图示概念的时序。

图14图示要被保护免受攻击的可信应用519的关键部分1401，例如密码代码。代码段1403被添加到关键部分1401。关键部分包含多个可能的路径和若干循环。例如，第一循环1405包含短块1407和长块1409。如果用于第一循环的执行路径通过1407的短块，则第一循环1405的给定迭代的次数的执行将比在执行通过长块1409时短得多。类似地，可以使循环2至n1411执行通过短块1413或长块1415，从而再次影响总体执行时间。

由随机数确定无论哪个执行路径被用于代码段1403，所述随机数将指示要执行哪些块并且达多少次迭代。

通过了解针对短块和长块的块执行次数和针对每次循环的迭代的次数，预测代码中的检查点的各种位置之间的预期经过时间是可能的。例如，如果预期长块1409采取t个循环并且预期短块采取5*t个循环，并且已知预期循环11405执行短块n次，则可以预测在检查点1417处的时间b与在开始点1419处的时间a之间的时间差应当是n*t。与那的偏差可能指示代码已经由调试器在循环1的执行期间的某个时间暂停。类似地，分别在检查点1421和1423处用时间c和d。

图15是图示使用图14的机制在运行时期间对执行路径随机化的流程图，其中随机化的执行持续时间被检查以确定可能的操纵。

步骤1501：生成随机数r，所述随机数r被用于确定通过添加的虚设代码段1403的执行路径。

步骤1503：随机数r被用于确定执行路径。例如，r的不同位可以指示针对各种循环是否执行长块或短块。其他位可以指示迭代的次数。

步骤1505：包括是否执行短块或长块的执行路径以及迭代的次数被用于确定在各种标识的检查点处的预期到达时间。

步骤1507：由检查点索引的预期到达时间以及预期总执行时间（即，在检查点1423处的要被保护的关键代码1401的执行之后）以某种保护形式被理想地记录在诸如可信存储设备523中。

步骤1509：在可信应用的执行期间：

步骤1511：在每个检查点处，将在检查点处的到达时间与预期到达时间比较。如果存在超出预定阈值的偏差（步骤1513），则采取校正动作（步骤1515）。

否则，即，如果偏差是可接受地小的，则执行继续1517，直到在步骤1511处遇到接下来的检查点。

因此，如果在可信应用的执行期间的某个时刻处，执行被暂停（例如，使用调试器），则执行时间将被扰乱并且到达时间将与预期到达时间不匹配。这将触发将针对其采取校正动作的条件。

为了说明性目的，我们将在本文中呈现的技术描述为其可以被用于移动设备103中。然而，呈现的技术可适用于具有对安全可信执行环境的需要的任何可编程电子设备。

根据前述内容将显而易见的是，已经呈现了一种技术，所述技术通过提供将可信执行环境引入到移动应用程序中的机制来改进在移动设备上执行的应用的安全，使得当移动设备被用于执行这样的移动应用程序以操纵被存储在移动设备上或使用移动设备在远程服务器上访问的敏感数据时，可以预期增加的信任的级别。这些增强以鲁棒的、灵活的和经济的方式来实现，其不要求对移动设备硬件的修改而又增强与移动设备硬件的操作相关联的安全。

尽管已经描述和说明了本发明的具体实施例，但是本发明不限于如此描述和说明的部分的具体形式或布置。本发明仅由权利要求限制。

¹在本说明书中，若干相关元素分别由n-e、n-c和n-s指代。e代表实体，c代表计算机，并且s代表软件。因此，n-e是实体n-e，其操作计算机n-c，所述计算机n-c根据指令n-s来执行。例如，可信服务管理器实体119-e操作计算机119-c，所述计算机119-c执行可信服务管理器软件。为了易于描述，我们有时通过数字n来指代这些元素，例如tsm119。除非上下文明确相反，否则这通常应当被理解为意指对执行它们相应的角色的所有三个元素的引用，例如，可信服务管理器计算机119-c执行由可信服务管理器软件119-s中的软件规定的一些动作。