应用证书的制作方法
本申请涉及计算设备领域。更具体地，本申请涉及根据公钥基础设施提供信任链。
背景技术：
计算设备越来越多地被用于访问服务，访问服务可能涉及处理潜在敏感信息的服务，例如移动银行、对医疗服务的访问或对就业细节的处理。此外，随着物联网(iot)的不断发展，基于由可以提供传感器信息(例如，温度数据或指示用户是否在场的接近度信息)的设备提供的信息来控制诸如加热、空调或街道照明之类的系统变得越来越普遍。在这些场景中，对于服务提供商来说，重要的是能够验证设备满足某些要求，以信任与设备的交互是安全。服务提供商可能需要具有设备具有某些属性的置信度，例如它是由一组受信任的制造商之一制造的、它通过了某个质量保证步骤、或者它安装了某个硬件组件或软件应用。加密技术可以被用于提供所需的信任根。例如，可以在制造期间将加密密钥嵌入设备中，并且设备以后可以使用该密钥来向外部验证者(verifier)证明该设备具有验证者所期望的属性。
技术实现要素：
至少一些示例提供了一种用于设备的方法，该方法包括：将安装在设备上的特定应用注册到由公钥基础设施提供的信任链中，其中，在信任链中，子证书被与信任链中的父证书相关联的证明者证明为有效；其中，注册包括生成应用证书，应用证书用于验证特定应用被安装在设备上或者证明与特定应用相关联的事件；以及应用证书是设备的设备证书的后代证书。
至少一些示例提供了一种设备，该设备包括：处理电路，该处理电路被配置为：将安装在设备上的特定应用注册到由公钥基础设施提供的信任链中，其中，在信任链中，子证书被与信任链中的父证书相关联的证明者证明为有效；其中，特定应用的注册包括生成应用证书，应用证书用于验证特定应用被安装在设备上或者证明与特定应用相关联的事件；以及应用证书是设备的设备证书的后代证书。
至少一些示例提供了一种用于远程验证者的方法，来验证特定应用是否被安装在设备上或者特定应用是否满足至少一个所需属性，该方法包括：获得与特定应用相关联的至少一个应用证书，其中：至少一个应用证书被注册到由公钥基础设施提供的信任链中；在信任链中，子证书被与信任链中的父证书相关联的证明者证明为有效；以及每个应用证书是设备的设备证书的后代证书；使用至少一个应用证书验证由设备持有的至少一个证明密钥是否有效；以及基于至少一个证明密钥是否有效，验证特定应用是否被安装或者满足至少一个所需属性。
至少一些示例提供了一种计算机程序，用于控制数据处理装置执行上述方法。存储介质可以存储计算机程序。存储介质可以是非暂时性存储介质。
至少一些示例提供了一种装置，该装置包括：处理电路，该处理电路执行数据处理；以及存储介质，该存储介质存储用于控制处理电路以执行上述任何方法的计算机程序。
附图说明
从以下结合附图阅读的示例的描述中，本技术的其他方面、特征和优点将显而易见，其中：
图1示意性地示出了电子设备的示例；
图2示出了由公钥基础设施提供的信任链的示例，其中针对安装在电子设备上的特定应用生成应用证书，在电子设备中应用证书是信任链中的设备证书的后代；
图3是示出在电子设备上安装应用的方法的流程图；
图4示出了注册与特定应用相关联的应用证书链的示例；
图5是示出响应于与特定应用相关联的应用证书更新事件而生成新的应用证书的方法的流程图；以及
图6是示出基于与特定应用相关联的至少一个应用证书来验证设备的方法的流程图。
具体实施方式
计算设备(例如，电子设备)可以被注册到由公钥基础设施提供的信任链中。在信任链中，子证书可以由与信任链中的父证书相关联的证明者(attestor)证明为有效。通常，每个证书提供对应于私钥的公钥，该私钥对于特定设备或消息源保密，并且该证书可以被用于验证声称来自特定源的消息使用该源的私钥进行了签名。
服务提供商可以使用特定设备的证书来验证声称来自给定设备的消息是有效的(并且因此获得该设备具有某些属性或者是访问给定云服务可能需要的一组已知设备中的一个设备的信任)。然而，即使设备可以被验证，恶意用户仍然可能将不安全的应用安装到已知设备上，以便尝试以不期望的方式访问外部服务。
在以下讨论的技术中，安装在设备上的特定应用可以被注册到由公钥基础设施(publickeyinfrastructure，pki)提供的信任链中，其中注册包括生成应用证书，该应用证书用于根据pki来验证特定应用被安装在设备上。应用证书被生成为信任链中的设备的设备证书的后代证书。因此，应用证书成为包括设备证书本身的同一pki链中的叶节点。应用证书使其他人能够建立特定软件被安装在设备上的置信度，这对于一些使用情况可能是重要的。通过在其中安装了应用的设备上生成应用证书，不需要在设备外部暴露与应用证书相关联的私钥(如果证书是由远程认证服务器生成的，则将是这种情况)。
在一些实例中，应用证书可以是设备证书的子证书。在这种情况下，在应用证书和设备证书之间可以没有中间证书，其中设备证书是应用证书的直接父证书。例如，可以利用用于证明设备身份的私钥(即，对应于与设备证书相关联的公钥的私钥)对应用证书进行签名。
可选地，应用证书可以不是设备证书的直接子证书，而可以是进一步的后代证书，例如设备证书的孙子或重孙子证书。例如，在一些情况下，特定设备可以具有多个不同的操作域，每个操作域与其自己的证书相关联，该证书被生成为设备的设备证书的子证书或后代证书。这使得由设备触发的动作能够被归属于一个特定的操作域。因此，应用证书可以是域证书之一的子证书，而不是设备证书本身的子证书。
当生成应用证书时，还针对特定应用生成私钥，该私钥对应于与应用证书相关联的公钥。私钥可以由特定应用可访问或者选定的其他应用访问，这些应用可能需要向验证者证明安装了特定应用。可以使用私钥来对消息进行签名，以便确定在设备上安装了特定应用，并且外部服务提供商然后可以使用相应应用证书来验证使用适当的私钥对消息进行了正确签名，例如通过使用与应用证书相关联的公钥来解密或验证消息的签名。与应用证书相关联的私钥和公钥例如可以对应于从椭圆曲线配对计算获得的值。
在一些示例中，当在设备上安装了特定应用时，特定应用可以被注册到信任链中。例如，注册可以响应于用于将特定应用安装到设备上的安装命令而发生。
在根据公钥基础设施来验证设备的身份成功的情况下，可以进行特定应用的安装。例如，安装过程的一部分可以包括检查由设备的私钥签名的消息是否可以使用设备证书进行验证。因此，当在设备中安装受信任的应用时，在允许继续安装首先证明设备有效，然后生成任何应用证书以将应用注册到信任链中之前。这可以允许应用的发起者验证预期设备不是伪造设备或者可能列入黑名单的设备，而是具有某些特性的合法设备。
在一些情况下，设备可以根据用于指示在设备上安装特定应用的安装命令所指定的信息来选择是否将特定应用注册到信任链中。例如，安装命令可以指定注册标志，其指示是否将应用注册到信任链中。可选地，安装命令可以包括具有根据公钥基础设施定义的特定格式的嵌入式证书签名请求，其可以在安装应用时被执行以触发注册到pki中。因此，应用提供商可以通过在提供给设备的用于安装特定应用的相应安装命令内包括适当的触发信息来控制设备是否要针对特定应用生成应用证书。
可选地，可以在安装特定应用之外的时间将特定应用注册到信任链中。例如，在一些实施方式中，注册和应用证书生成可以在每次设备需要证明安装了特定应用时动态进行。
注册也可以在将特定应用更新到新版本时执行。应用证书可以指定版本标识符，该版本标识符标识安装在设备上的特定应用的版本。这使得外部验证者能够验证所安装的应用的特定版本，这通常与知道是否首先安装了应用一样重要。例如，当在特定应用中识别出安全漏洞时，应用提供商可能发布具有安全漏洞的补丁的新版本，并且服务提供商然后可能希望确保对给定服务的后续访问使用应用的最新版本，以便防止对安全漏洞的后续利用。通过在应用证书内提供版本标识符，如果安装在设备上的应用的版本无法再被接受，则外部验证者可以选择拒绝访问服务的特定请求。因此，当特定应用被更新到设备上的新版本时，可以针对特定应用生成新的应用证书。此外，响应于将特定应用更新为到新版本，可以丢弃特定应用的先前应用证书以及与该应用证书相关联的先前生成的私钥。
可选地，不是当针对同一应用生成新的应用证书时丢弃与特定应用相关联的先前应用证书，而是在生成新应用证书之后可以保留先前应用证书在公钥基础设施中的注册。通过在公钥基础设施中针对同一应用记录多个证书，这些证书可以对应于与特定应用相关联的不同事件(例如，升级到不同版本，或针对应用的配置设置的改变)，这可以允许设备证明特定应用的历史的各个部分，例如，这可以允许增加过去没有干扰应用的置信度。
在其中针对特定应用生成多个证书的一些示例中，新的应用证书可以引用特定应用的先前应用证书。例如，新的应用证书可以被生成为信任链中的先前应用证书的子证书。可选地，新的应用证书和先前应用证书二者可以共享相同的父证书，但是新的应用证书可以包括提供指向先前应用证书的指针的字段。通过在新的应用证书中包括对先前应用证书的引用，这使得能够验证证书在与特定应用相关联的证书链中的顺序，并且还使得能够由验证者识别证书链中的明显缺失。例如，如果证书链示出了应用直接从版本1.2升级到版本1.4，省略版本1.3，则即使随后识别出与版本1.3相关联的安全问题，该设备也可以证明它从未安装该版本，并且因此可以验证特定应用是安全的。因此，可以生成应用证书链，用于证明与特定应用相关联的相应事件的发生或不发生。
响应于各种应用证书更新事件，可以针对特定应用生成新的应用证书。例如，应用证书更新事件可以是与特定应用本身的改变相关联的事件，例如特定应用更新到新版本，或者针对特定应用的配置设置的改变(例如，设备对应用进行个性化设置，或者针对特定应用启用调试功能)。
在其他示例中，应用证书更新事件可以是与其中执行特定应用的周围软件环境相关联的事件，而不是对特定应用本身的应用代码或配置设置的改变。例如，可以响应于更新与其中执行特定应用的软件环境相关联的平台程序代码和/或改变平台代码的配置设置，针对特定应用生成新的应用证书。平台程序代码例如可以包括以下各项中的至少一项：设备的系统固件；设备的操作系统；在设备上提供的受信任的执行环境；以及用于控制或验证对特定应用的程序代码的更新的程序代码。例如，对影响由受信任的执行环境提供的安全边界的代码或配置数据的改变，或对为特定应用提供存储服务的安全驱动器的更新，可以触发针对特定应用生成新的应用证书，以使其他人能够验证其中特定应用在设备上运行的环境。应当理解，这些仅仅是可以触发生成新的应用证书的事件的一些示例。
设备可以具有正常执行环境和受信任的执行环境，在受信任的执行环境中，至少一些数据或程序代码是可访问的，而在正常执行环境中是不可访问的。例如，可以使用硬件架构(例如，由英国剑桥的arm有限公司提供的
并非所有安装在设备上的应用都需要被注册到信任链中。在一些情况下，只有一些应用可以被注册到pki中。例如，在一些情况下，注册到pki可能仅可用于在安全执行环境中运行的应用。
并非所有设备都可以被允许将它们安装的应用注册到信任链中。例如，设备可以与定义设备能力的至少一个设备许可或约束相关联，包括指定是否允许设备将应用注册到信任链中的至少一个许可或约束。因此，响应于安装命令，设备可以根据至少一个设备许可或约束来确定是否允许设备将特定应用注册到信任链中，并且然后可以在确定允许设备这样做时注册特定应用。设备许可或约束可以是在设备制造期间设置的永久许可或约束，或者可以是可以由在设备上执行的软件改变的许可或约束，或者可以从信任链内的祖先定义的许可得出，该许可或约束可以设置对与信任链中的后代证书相关联的设备或软件被允许创建包括应用证书的其他证书的程度施加限制的约束。设备许可或约束可以是设备内设置的内部控制许可(例如，通过信任链中的祖先进程)，或者可以是由操作远程管理设备的第三方(例如，设备可以向其注册服务的服务提供商)设置的远程管理许可，而不是由设备的用户提供的用户授权。
在允许设备注册应用证书的情况下，至少一个设备许可或约束可以指定要包括在针对特定应用生成的应用证书中的信息。这可以允许不同的信息被包括在不同设备的应用证书中。要在应用证书中指定的信息可以以设备满足由至少一个设备许可或约束指定的某些准则为条件。例如，对于一个设备，生成rsa密钥可能是可接受的，但是对于另一设备，生成rsa密钥可能是不可接受的。在另一示例中，设备许可或约束可以指定绝对密钥大小或允许的最小密钥大小，使得不同的设备可以生成具有适合于所需的安全级别的多个比特的密钥。
当应用被注册到信任链中时，生成的应用证书可以被存储在特定应用可访问的存储位置中。这可以是设备本身内的存储位置或远程位置。在证书创建过程期间，不需要联系远程服务器，并且在一些实施例中，注册可以在设备内本地执行。例如，这对于在不存在网络连接的情况下创建证明可能是有用的，例如，用于本地信任使用或在诸如设备到设备网络的本地网络中。
可选地，生成的应用证书可以被返回给请求者，该请求者触发特定应用的安装或更新，或者被提供给另一方。例如，应用证书可以被上传到远程服务器，使得第三方随后可以使用应用证书来验证特定应用是否安装在设备上。
在一些示例中，将应用证书注册到信任链中可以涉及向管理与信任链相关联的证书的第三方登记在设备上生成的应用证书。
因此，设备可以使应用证书对请求验证特定应用是否安装在设备上的验证者可访问。这可以通过在安装应用时将证书上传到远程服务器，或者通过本地存储应用证书并且然后使证书在以后可用来完成。例如，当访问需要验证是否安装特定应用的服务时，证书可以与使用相应私钥签名的消息一起由设备提供。因此，在远程认证服务器处存储证书不是必需的。证书的真实性可以通过跟随信任链直接回到根证书来验证。根证书可以由与设备独立的外部认证机构证明为有效。
在一些示例中，当生成应用证书和相关私钥时，私钥可以被本地存储在设备上，并且应用证书本身可以被上传到远程位置并且然后从设备删除，使得设备本身不需要继续存储应用证书。该方法可以更适合于例如在存储器容量和功率方面可能受到极大限制的物联网类型设备。
应用证书可以具有一系列格式。然而，在一个示例中，应用证书可以包括x.509证书。x.509是用于验证设备的证明的工业标准解决方案，并且因此通过使用用于受信任的应用的标准x.509证书，这也改进了与现有验证技术的兼容性。
以上讨论的应用证书可能不是与特定应用相关联的唯一证书。应用还可以与软件提供商证书相关联，该软件提供商证书由软件的提供商签名并且连同用于安装特定应用的安装命令一起被提供给设备。在安装时，设备然后可以在将在设备上安装应用之前使用软件提供商证书来验证特定应用，以确定应用的提供商是否可信或者应用代码是否可信。例如，软件提供商可以包括软件提供商证书中的软件代码的一部分的散列，其由软件提供商的私钥签名。在安装时，设备可以使用与软件提供商证书相关联的软件提供商的公钥来验证散列的签名，并且通过将散列与接收到的要安装的应用代码的一部分的散列结果进行比较来验证散列，以验证代码在来自软件提供商的途中未被篡改。与软件提供商证书不同，应用证书在安装相应应用的设备上生成，并且证明特定设备安装了特定应用的事实，而不是证明特定应用或提供该应用的软件提供商的真实性。
图1示意性地示出了计算设备2的示例。在该示例中，设备是电子设备2，但是在其他示例中，计算设备可以是使用由激光器或二极管产生的光子进行计算的光学计算设备，或者使用电子和光学计算元件的组合的设备。设备2具有处理电路(例如，中央处理单元(cpu))4和用于存储由处理电路4执行的数据和程序代码的存储电路6(存储器)。存储器6还可以存储与公钥基础设施相关联的密钥或证书。显然，其他数据也可以被存储在存储器6内。在一些情况下，存储器6可以被划分为安全区域和较不安全区域，其中安全区域例如仅可从处理电路4的受信任的执行环境访问，而较不安全区域可从处理电路4的受信任的执行环境和正常执行环境两者访问。可以根据硬件架构(例如，由arm有限公司提供的
设备2还可以具有一个或多个用于感测外部条件(例如温度、压力、红外辐射等)的传感器8、用于向用户显示信息的显示器10、用于接受来自用户的输入手势的用户输入12、以及用于例如通过无线协议(例如，
图2示出了由公钥基础设施提供的信任链的示例。公钥基础设施由证书20的层级表示，该证书20的层级可以用于验证消息源。每个证书20包括公钥22，该公钥22对应于由要被分配的相应源所持有的私钥24。例如，私钥-公钥对可以是根据rsa技术或通过椭圆曲线加密术创建的密钥对。信任链中的信任最终源自与根证书20-r相关联的根认证机构。与根证书20-r相关联的根认证机构可以证明例如与电子设备的特定制造商(oem)相对应的许多子证书是有效的。然后，每个oem可以证明将其自身的证书作为信任链内oem证书的子证书而生成的特定电子设备是有效的。因此，信任链提供了证书树，其中子证书由与信任链中的父证书相关联的证明者证明为有效。由于证书是在连续几代中生成的，因此当确定特定证书有效时，可以意味者，存在一直延伸回到根认证机构(与设备2分离的外部方)的信任链，从而给出了对消息源的真实性的置信度，但是由该链提供的委托证明避免了单个认证机构必须直接向每个设备或消息源本身证明的复杂性。虽然图2示出了其中oem直接为其制造的设备创建设备证书的特定层级，但是在其他示例中，在根证书20-r和设备证书20-d之间可能存在多层制造商证书。除了公钥22之外，证书可以包括与正被认证的相应消息源相关联的其他信息。证书可以具有任何格式，但是在一个特定示例中，可以根据x.509标准来定义。
如图2所示，可以扩展信任链，以使其中安装了特定软件应用的电子设备2可以生成应用证书20-a，该应用证书20-a是安装了应用的设备2的电子设备证书20-d的信任链中的后代证书。可以在安装时、应用的更新时或者安装或更新应用之后生成应用证书。对于一些设备，应用证书20-a可以是设备证书20-d的直接子证书。对于其他设备，在设备证书20-d和应用证书20-a之间可能存在至少一个中间证书，例如与其中安装了应用的设备的特定操作域相关联的域证书。除了公钥22之外，应用证书可以包括有关应用或其中安装了应用的环境的许多信息(例如标识特定应用的应用标识符30、标识安装的应用的特定版本的版本号32)或其他信息(例如指定安装应用的时间的元数据、安装应用时电子设备所处的地理位置)等。
因此，软件提供商可以具有为其应用创建的证书(在应用安装时或安装之后)，该证书可以包含应用标识符和版本号等。证书可以被签名到与电子设备本身相同的公钥基础设施中，作为设备的证书下的叶节点，以提供应用证书如何存在的可追溯性。电子设备在生成应用证书时不必具有网络连接，或者不必访问用于存储与设备证书相关联的密钥的硬件安全模块。每次更新应用时，可以重新生成应用证书以提供新的版本号32，以便允许跟踪在设备中安装了应用的哪个特定版本。x.509格式可以被用于与希望在设备上验证或个性化应用的第三方进行更轻松的互操作，因为当识别或认证设备和密钥时x.509是事实上的标准。
图3示出了图示在电子设备上安装应用的方法的流程图。在步骤50，设备确定是否接收到用于请求安装特定应用的应用命令。当接收到应用安装命令时，则在步骤52，例如通过检查电子设备具有可以使用设备证书验证的适当私钥来验证电子设备，以便检查该电子设备是有效设备而不是未授权副本或黑名单设备。如果设备验证不成功，则在步骤54，拒绝安装受信任的应用。因此，给定软件应用的提供商可能需要电子设备满足某些准则，以便安装应用。
如果设备验证成功，则在步骤56，安装或更新与安装命令相关联的特定应用(如果设备上已经存在应用的先前版本)。在步骤58，设备的处理电路4确定安装命令是否包括注册触发，并且还确定是否允许电子设备2将应用注册到公钥基础设施中。注册触发信息可以是在安装命令内指定的一些信息，其标识针对该特定软件应用在安装软件时是否要执行注册过程(注册过程包括生成应用证书20-a)。例如，注册触发信息可以是命令中指定的布尔标志，其指示该应用是否应当具有为其创建的证书，或者可以是根据与用于信任链中的父节点发出的证书签名请求相同的格式定义的证书签名请求，以针对pki创建新的子证书和密钥对。另一选项将是注册触发可以是隐式的，使得命令可以指定是否不应执行注册，并且可以假设不排除注册的任何命令包括注册触发器。是否允许设备将应用注册到信任链中可以取决于针对设备设置的约束或许可，该约束或许可可以在控制寄存器中或在存储器内定义并且可以在制造设备时固定或可以为可变的。
如果安装命令不包括注册触发，或者不允许设备将应用注册到公钥基础设施中，则在步骤60，阻止应用注册。
如果命令包括注册触发信息，并且允许设备注册应用，则在步骤62，将新安装或更新的应用注册到信任链中。这包括生成应用证书，该应用证书提供对应于与应用相关联的私钥的公钥。在注册时可以新生成公钥和私钥。应用证书被生成为与安装了应用的电子设备2相关联的设备证书的后代证书。因此，可以使用与电子设备相关联的私钥(或者使用与设备证书的后代证书相关联的私钥)来对应用证书进行签名。应用证书可以指定应用版本号以及后续验证者感兴趣的任何其他信息。
在步骤64，使应用证书可用于验证者，验证者然后可以使用证书检查特定应用的特定版本是否安装在设备中。例如，步骤54可以包括将生成的证书存储到电子设备2的本地存储装置6。不必在注册应用时访问网络。相反，可以在稍后的时间将证书提供给验证者，例如连同要使用证书来验证的消息(使用相应的私钥24来签名)。可选地，步骤64可以包括将证书上传到可以存储多个应用和设备的证书的远程证书存储服务器。第三方服务器可以在从电子设备2接收到消息时，使用从证书存储服务器访问的相应的应用证书来验证是否安装了应用。
虽然图3示出了其中响应于应用的安装或更新而生成应用证书的示例，但是类似的步骤也可以在安装或更新了应用已之后的任意时刻执行，例如在访问需要安装了特定应用的证据的服务时。在这种情况下，步骤62和64可以响应于访问这种服务的请求而执行，或者响应于特定应用本身或运行特定应用的监督应用的请求而执行。
总之，当受信任的应用(ta)在受信任的执行环境中被受信任的os(或委托的实体)安装(或更新)时，或在比安装/更新时间更晚的时间，系统可以针对受信任的应用(ta)创建证书。该证书也被链接到设备本身所属的同一pki。
因此，服务提供商具有为其ta创建的证书(例如，x.509)。证书可以包含一系列信息，例如应用id和安装的ta的版本。ta的证书也被签名到与设备本身相同的pki中，作为该设备下的叶子(leaf)。这产生了关于该证书如何存在的可追溯性。该证书创建不需要设备具有网络连接，也不需要访问其中存在与所述pki相关的密钥的pkihsm。此外，当ta也被更新时(因为证书携带ta的版本)，设备证书也被重新生成。位于x.509的证书允许与想要在设备上证明或个性化ta的服务器进行更轻松互操作，因为当通常涉及身份和密钥时x.509是事实上的标准。
下面更详细地讨论示例。当ta要被安装在设备中时，通常在该安装发生之前已经证明该设备是有效的。这允许发起者验证预期设备不是仿真器或其他(潜在地)列入黑名单的设备。一旦这种情况发生，就安装ta。然而，在ta的安装期间，安装命令可以被解析以执行进一步的动作。潜在地，这可以像布尔标志一样简单，该布尔标志表明该ta是否希望创建证书，而不允许额外的参数，或者它甚至可以是嵌入在安装命令内的完全成熟的证书签名请求。此外，该安装命令是否可以合法地要求系统生成证书，可能取决于由信任链中的祖先节点设置的许可或未来约束。该许可可以是在设备内定义的内部控制许可，或者是由第三方定义的远程管理许可，而不是由设备的用户授予的用户许可。
响应于安装命令，系统可以生成至少包括以下属性的x.509证书：taid(标识应用)和ta版本。
其中创建该证书的设备的设备id的价值较小，仅仅是因为成为其父证书的设备证书已经包含上述设备标识符，但是如果需要，该设备id仍然可以被包括在证书中。以上列表不是穷举的，并且仅仅是为了说明的目的而示出。证书可以由设备自己的私钥(即，所谓的“设备密钥”)来签名，为此还存在成为该新生成的证书的父证书的设备证书。
因此，链如下所示：
[根]->[oem]->[设备证书]->[ta证书]
可选地，如果在设备上设置了多个安全域，则每个域可以具有相应的证书，并且ta证书可以被生成为域证书之一的子证书，例如：
根->设备->oem->suid/设备证书->根sd(uuid：603exxyyzz…)->l1(uuid：aabbccdd…)->l2(uuid：11223344…)->ta证书。
在设备上提供与特定odm、oem或安全域相关联的证书可以实现更灵活的制造结构。
一旦创建了证书，就可以将其以指定的文件名存储在ta的存储装置6中，或者由安装ta命令本身定义，或者由系统(和服务提供商)预先知道。可选地，证书可以作为安装命令的返回有效载荷的一部分返回，以便更简单地将其传送到远程方(这避免了仅为了提取所述证书而启动ta)。
当ta要被更新时，针对ta创建新的证书—这是因为ta的版本将改变，并且因此旧的证书现在已过时并且随后被重写。在一些情况下，可能仅存在ta的一个证书，即使ta已被安装并且更新若干次，因为证书应仅匹配最新安装的版本。此外，由于ta的更新，旧的ta证书无论如何不能证明该新的ta证书，因此保留它们的副本似乎是不可行的。然而，如果需要，可以保留旧的证书。
使用电子设备2将ta证书签名到pki链中的方法具有若干益处：
-不需要联系服务器用于证书创建-这都是本地的。因此可以用于在不存在网络连接的情况下创建证明(即，用于本地信任使用，或者如果需要的话在本地网络中，如设备到设备)。
-通过将ta证书签名到与设备本身相同的链中，该链被扩展为还包括受信任的应用—所有这些都与信任链的根相连。这是很有价值的，因为证明都在同一链中(并且还提供了pki证明的审计日志)。
-通过使用标准x.509证书，可以使用工业标准解决方案来验证来自设备/ta设备的证明，而无需创建新的专有证明(或使用其他复杂的解决方案)。
在图2的示例中，示出了针对设备2上安装的给定应用的单个应用证书20-a。然而，如图4所示，也可以在pki中注册两个或多个应用证书，每个证书与安装在设备上的同一应用a相关联。在图4中，为简明起见，未示出根证书20-r、oem证书和域证书，但是仍可以被提供(设备证书20-d和应用证书20-a之间的虚线表示可选地域证书20可以作为信任链中的中间步骤提供，尽管这不是必需的)。
每个应用证书20-a对应于与特定应用的历史相关联的给定事件。例如，第一应用证书对应于正在安装的应用的版本1，第二应用证书对应于其中执行该应用的受信任的执行环境的版本升级，并且同一应用a的第三应用证书对应于正在安装的应用的新版本3。每个新的应用证书都包含对先前应用证书的引用，用于同一引用。在该示例中，这通过在证书的除指示父证书的字段之外的字段中(例如，在x.509证书的扩展(对象id)字段中)包括指向先前应用证书的指针来提供。然而，也可以将新的应用证书生成为同一应用的先前应用证书的子证书。
因此，每次代码改变或配置改变发生时，证书链都会扩展，不仅与应用本身相关联，而且与其基础平台环境(例如，受信任的执行环境或固件)相关联。这意味着，当受信任的应用进行证明时，通过证明拥有用于任何应用证书的证明密钥，该应用不仅可以证明其身份，而且还可以证明在过去没有不可信的代码曾经能够干扰任何应用的存储状态。这种证明在高信任设置(例如，高价值商业)中可能很重要。
因此，每次发生影响行为的改变时，无论如何微小，在设备2上执行的软件(例如，底层受信任的执行环境(tee)或用于控制或验证对特定应用的程序代码的更新的安全程序代码)可以扩展(或创建)描述ta的历史的证书链。影响行为的改变可能包括：
·改变特定应用的应用代码；
·改变设备的平台程序代码(例如，tee代码、用于控制或验证对特定应用的更新的程序代码、设备的操作系统或设备的底层固件)；
·对平台程序代码的配置改变；
·平台程序代码对应用本身进行个性化；
·对应用本身的配置改变，例如启用调试功能；
·影响由tee提供的安全边界的任何代码或其配置的改变，例如禁用回退检测，或更新提供存储服务的安全驱动程序。
例如，考虑将应用全新安装在tee上。可以创建初始证书，其证实应用的代码(例如，版本v1.2和代码散列)以及底层平台代码库(例如，tee版本和代码散列等)。同一应用可能稍后被升级到v1.4。在这种情况下，将创建证实新的应用代码(版本+代码散列)的后续证书。该证书可以包括对应用代码的前一版本的引用，例如通过引用先前证书的特定对象id(或证书的其他字段)，或通过使证书成为证书机构证书链(其中使新的证书成为前一证书的子证书)。因此，如果发现，即，应用的版本1.3是例如泄漏了密钥的已知错误代码版本，则应用可以通过证明和证实支持证书链来最终证明安全漏洞在过去从未被利用，因为v1.3从未安装在设备上。为了支持此功能，每次升级应用或另一应用证书更新事件发生时，与最新证书相关联的证明密钥就会改变。可以通过设备2上的平台程序代码(例如，用于控制/验证对特定应用的程序代码的更新的程序代码)来执行新的证书的生成的管理。
图5示出了图示生成新的应用证书的方法的流程图。在步骤80，设备2的平台代码检测针对特定应用是否发生了任何应用证书更新事件，其例如可以是上面列出的任何影响行为的改变。当发生应用证书更新事件时，在步骤82，平台程序代码控制设备2针对特定应用生成新的应用证书。生成私钥/公钥对，其中将私钥用作设备持有的证明密钥，并且将公钥与证书一起提供，以使第三方能够验证设备是否具有私钥(证明密钥)。可以基于其父证书(例如，设备证书20-d)的私钥对新的证书进行签名。如果新的证书不是针对应用生成的第一证书，则新的证书可以包括对在针对该应用生成的证书链中的前一应用证书的引用。新的证书连同其公钥一起被注册到pki中。例如，新的证书和相关公钥可以被上传到证书管理服务器，并且然后从设备2中丢弃。可选地，设备可以保留证书和/或公钥。无论是否保留证书和公钥，设备都将私钥(证明密钥)保留在安全存储装置中，以防止受信任的执行环境未经授权访问。在步骤84，在生成新的应用证书之后，先前应用证书的注册仍被保留在信任链中。因此，没有必要删除与特定应用相关联的任何先前应用证书。针对同一应用保留多个证书有助于实现对应用的历史的更详细验证。
图6是示出基于与设备上的特定应用相关联的(一个或多个)应用证书来验证设备2的方法的流程图。该方法可以由(与设备2独立的)第三方验证者(例如，对设备正在寻求注册的服务(例如，医疗保健、银行业务、公共服务提供等)进行运营的服务提供商)执行。此外，第三方验证者可以是验证服务提供商，这种服务提供商可以将验证功能委托给该验证服务提供商。在步骤100，验证者获得与设备上的特定应用相关联的至少一个应用证书。例如，可以基于由设备在触发设备的验证的请求中提供的设备标识符，从存储在远程服务器上的证书数据库中获取证书。
在步骤102，验证者使用(一个或多个)应用证书来验证设备持有的一个或多个证明密钥是否有效。例如，与(一个或多个)应用证书相关联的(一个或多个)公钥可以用于基于相应证明密钥验证由设备签名或加密的一个或多个消息。如果基于公钥的验证成功，则这可以指示设备是与应用证书相关联的真实设备，并且由相应证书证明的每个事件都可以被信任为已经发生。
在步骤104，验证者确定特定应用的应用证书链是否包括一个以上的应用证书。如果是，则在步骤106，执行附加的验证步骤，以检查证书在序列中的顺序是否满足预定条件。例如，如果事件发生的顺序可疑或不可能，则这可能表示该设备已被篡改。
无论是否执行步骤106，在步骤108，验证者都标识出针对特定应用提供的证书链中是否存在任何明显的缺失。在一些情况下，证书链中缺失给定证书可能是积极因素，表明设备可以安全地进行验证(例如，因为不存在与应用代码的已知错误版本相对应的证书)。在其他情况下，如果未进行被认为对应用的安全运行至关重要的某些升级或配置设置，则证书链中缺失给定证书可能是不利因素。同样在步骤108，在一些示例中，验证者可以确定在链中是否存在引起关注的证书，例如指示被发现泄漏了密钥的应用的错误版本先前被安装在设备上的证书，或指示对应用进行了配置改变(其禁用安全性所需的功能)的证书。例如，验证者可以访问“禁止列表”，该“禁止列表”标识与事件相关联的证书，如果事件发生，则将要求验证失败。
在步骤110，基于证明密钥是否被验证为有效、链式证书序列的顺序是否有效、证书链中是否存在关注的缺失和/或是否在链中识别出与关注事件相关联的任何禁止的证书，验证者确定设备2(包括在设备上执行的任何软件，例如tee、应用、固件或其他受控子系统)是否通过验证。特定设备是否通过总体验证测试可以是多因素测试，并且可以评估多个不同准则以确定设备是否通过验证。但是，通过使针对给定应用定义的证书链能够证明应用代码本身和周围平台环境的历史中的各种事件，并且将这些证书中的每个证书注册到包含设备证书本身的同一公钥基础设施中，这可以增强对在设备上执行的应用代码的信任，从而也增强对设备本身的信任。
以下条款列出了进一步的示例布置：
(1)一种用于电子设备的方法，该方法包括：将安装在电子设备上的特定应用注册到由公钥基础设施提供的信任链中，其中，在该信任链中，子证书被与信任链中的父证书相关联的证明者证明为有效；其中，注册包括生成应用证书，所述应用证书用于验证特定应用被安装在电子设备上；以及应用证书是电子设备的设备证书的后代证书。
(2)根据条款(1)所述的方法，其中，应用证书是设备证书的子证书。
(3)根据条款(2)所述的方法，其中，利用用于证明电子设备的身份的私钥来对应用证书进行签名。
(4)根据条款(1)至(3)中任一项所述的方法，包括：针对特定应用生成私钥，该私钥对应于与应用证书相关联的公钥。
(5)根据条款(1)至(4)中任一项所述的方法，其中，当特定应用被安装在电子设备上时，将特定应用注册到信任链中。
(6)根据条款(5)所述的方法，其中，在根据公钥基础设施成功验证电子设备的身份的条件下，安装特定应用。
(7)根据条款(1)至(6)中任一项所述的方法，包括：根据用于指示在电子设备上安装特定应用的安装命令所指定的信息来选择是否将特定应用注册到信任链中。
(8)根据条款(7)所述的方法，其中，安装命令指定注册标志，该注册标志指定是否将应用注册到信任链中。
(9)根据条款(7)所述的方法，其中，安装命令包括具有根据公钥基础设施定义的格式嵌入式证书签名请求。
(10)根据条款(1)至(9)中任一项所述的方法，其中，电子设备具有正常执行环境和受信任的执行环境，在受信任的执行环境中，至少一些数据或程序代码是可访问的，而在正常执行环境中是不可访问的；并且在受信任的执行环境中执行的程序代码的控制下执行特定应用的注册。
(11)根据条款(1)至(10)中任一项所述的方法，其中，应用证书指定版本标识符，该版本标识符标识安装在电子设备上的特定应用的版本。
(12)根据条款(1)至(11)中任一项所述的方法，包括响应于将特定应用更新到新版本，针对特定应用生成新的应用证书。
(13)根据条款(1)至(12)中任一项所述的方法，包括响应于将特定应用更新到新版本，丢弃特定应用的先前应用证书。
(14)根据条款(1)至(13)中任一项所述的方法，包括：根据针对电子设备定义的至少一个设备许可或约束，确定是否允许电子设备将特定应用注册到信任链中；其中，当允许电子设备将特定应用注册到信任链中时，将特定应用注册到信任链中。
(15)根据条款(14)所述的方法，其中，所述至少一个设备许可或约束指定要被包括在针对特定应用生成的应用证书中的信息。
(16)根据条款(1)至(15)中任一项所述的方法，包括将所生成的应用证书存储在特定应用可访问的存储位置中。
(17)根据条款(1)至(16)中任一项所述的方法，包括将所生成的应用证书返回给触发特定应用的安装或更新的请求者。
(18)根据条款(1)至(17)中任一项所述的方法，其中，电子设备被配置为使应用证书能够由请求验证特定应用是否安装在电子设备上的验证者访问。
(19)根据条款(1)至(18)中的任一项所述的方法，其中，应用证书包括x.509证书。
(20)一种电子设备，包括：处理电路，其被配置为：将安装在电子设备上的特定应用注册到由公钥基础设施提供的信任链中，其中，在该信任链中，子证书被与信任链中的父证书相关联的证明者证明为有效；其中，注册特定应用包括生成用于验证特定应用安装在电子设备上的应用证书；并且应用证书是电子设备的设备证书的后代证书。
(21)一种计算机程序，用于控制数据处理装置执行根据条款(1)至(19)中任一项所述的方法。
(22)一种存储介质，存储根据条款(21)所述的计算机程序。
在本申请中，词语“被配置为……”用于表示装置的元件具有能够执行定义的操作的配置。在上下文中，“配置”是指硬件或软件的互连的布置或方式。例如，装置可以具有提供定义的操作的专用硬件，或者可以对处理器或其他处理设备进行编程以执行该功能。“被配置为”并不意味着需要以任何方式改变装置元件以提供定义的操作。
尽管在本文中参考附图详细描述了本发明的说明性实施例，但是应当理解，本发明不限于这些精确的实施例，并且在不背离所附权利要求限定的本发明的范围和精神的情况下，本领域的技术人员可以在其中进行各种改变和修改。
- 还没有人留言评论。精彩留言会获得点赞！