通过基于一次性证书请求的动态证书的软件组件的身份管理的制作方法

通过基于一次性证书请求的动态证书的软件组件的身份管理
[0001]
相关申请
[0002]
本申请要求于2018年5月21日提交的发明人为thomas p.chmara等人的标题为“identity management for software components”的临时申请序列no.62/674,283的优先权，该申请通过引用并入本文。


背景技术：

[0003]
强烈期望对软件组件授予可信的身份，使得可以向与这些组件交互的应用和用户确保这些组件的身份。许可软件(例如，来自microsoft、adobe、intuit)通常包含许可“密钥”，其声明在引入到该软件组件时授予“永久”身份。“白盒”解决方案和其它“指纹”算法试图利用环境标记来组装唯一身份以识别执行平台——当软件已被移动或复制时，与关联唯一身份相比，需要更多检测。
[0004]
转向基于云的服务，尤其是软件“容器”，它们经常被启动和销毁以管理服务容量并且经常被用经修改的代码库重新启动以应用校正内容或者修改或扩展特征内容，使得为软件可执行程序或组件提供唯一的、一致的、可证明的身份更加困难。
[0005]
这种部署场景具有挑战性，因为没有直接的方法将“制造身份”(证书)与软件组件实例相关联，或将该身份分配给为替换该容器而创建的容器：如果使用公开证书，那么有助于唯一识别实例的“私有密钥”不能被共享(即使是被共享给使用部署这些容器的控制引擎)，或者它不再是“私有的”。
附图说明
[0006]
当结合下面各图时，根据以下描述，将更容易理解本公开，并且其中相同的附图标记表示相同的元素，其中：
[0007]
图1是根据本公开中阐述的一个示例的功能框图；
[0008]
图2是根据本公开中阐述的一个示例的通信流程图；
[0009]
图3是根据本公开中阐述的一个示例的通信流程图；
[0010]
图4是根据本公开中阐述的一个示例的功能框图；
[0011]
图5是根据本公开中阐述的一个示例的通信流程图；
[0012]
图6是根据本公开中阐述的一个示例的通信流程图；以及
[0013]
图7是根据本公开的用作身份管理系统和/或应用主机的计算设备的示例的框图。


技术实现要素：

[0014]
本公开扩展了身份管理的技术的当前状态。执行软件组件可以采用可公开核实的安全唯一身份与当前的解决方案，但是需要某种形式的本地持久性存储来安全地存储那些身份(例如，私有密钥)。这对于云或虚拟机托管的、基于容器的或其它部署模型是个障碍，在这些部署模型中，执行软件的环境是短暂的并且因此缺乏持久性存储。本公开在一个实施例中描述了一种提供动态管理的、密码安全的唯一身份凭证(例如，证书)的方法和装置，
这些唯一身份凭证可以被创建、分配、暂停、停止暂停和撤销而无需设备可访问的本地持久性存储。
[0015]
在一些实施例中，一种方法和装置将一个或多个外部可核实的唯一密码身份凭证与瞬态软件环境中的软件组件相关联。在一些实施例中，不需要持久性存储。在一些实施例中，该身份凭证的秘密(例如，私有密钥或共享密钥)仅对软件组件是已知的(即，不同于证书和密钥可以被分配给实体的现有解决方案，该装置和方法通过证书签名请求(csr)将该证书的使用替换为其中秘密仅对正在执行的映像已知的证书)。在一些实施例中，一种方法和装置提供从不持久性地存储在设备上(并且因此更难以受危害)的身份凭证秘密。在一些实施例中，初始身份凭证与应享有相似信任(然后被授予唯一身份)的一类实体相关联，例如组身份凭证，并且被用于获取唯一身份凭证。在一些实施例中，一种方法和装置通过可信实体在这种环境中跨软件组件的移除和重构编排一系列身份凭证。
[0016]
在一些实施例中，如果在没有重构的情况下“移动”应用(例如，使用vmware公司的vmotion产品的活跃可执行程序的迁移)，那么证书(例如，身份凭证)保持不变，并且它可以继续是可信的。在一些实施例中，如果证书不同，那么与(外部)可信实体一起进行协调以更新将被用于识别组件的值。在一些实施例中，一种方法和装置在基于容器的框架中实现所述身份凭证。
[0017]
在一些实施例中，一个或多个计算设备采用至少一个应用组件实例，并且请求一次性使用身份凭证(例如，基于唯一地识别应用组件实例的数据、包含对应的公共密钥和私有密钥的pki证书)作为应用组件实例的第一身份凭证。计算设备使用基于一次性使用凭证签名的请求(例如，使用第一身份凭证pki证书的公共密钥)请求为应用的应用组件实例动态创建的第二身份凭证。计算设备接收动态创建的第二身份凭证，并由应用组件实例在密码功能中使用该动态创建的第二身份凭证。
[0018]
在一些实施例中，一个或多个计算设备采用至少一个应用组件实例，并且请求身份凭证(例如，基于唯一地识别应用组件实例的数据、包含相应的公共密钥和私有密钥的pki证书)作为应用组件实例的第一身份凭证。计算设备使用基于身份凭证(例如，使用第一身份凭证pki证书的公共密钥)签名的请求来为应用的应用组件实例请求动态创建的第二身份凭证。计算设备接收动态创建的第二身份凭证，并由应用组件实例在密码功能中使用该动态创建的第二身份凭证。
[0019]
在一个示例中，密码功能是认证操作。
[0020]
在一个示例中，由应用管理器发送对于动态创建的(例如，根据需要生成的)第一身份凭证的请求。在一个示例中，对于与应用实例相关联的一次性使用凭证的请求基于唯一标识符，该唯一标识符是唯一地识别应用组件实例的信息。在一个示例中，应用组件实例与工业传感器交互。
[0021]
在一个示例中，一次性使用凭证和动态创建的第二身份凭证均包括由证书授权机构(ca)产生的pki证书。
[0022]
在一个示例中，虚拟机接收所生成的应用组件实例的一次性使用凭证，并将所生成的应用组件实例的一次性使用凭证传递到使得第一身份凭证可用于应用组件实例的容器。
[0023]
在另一个示例中，一个或多个计算设备采用至少一个应用组件实例，并使用与应
用组件实例相关联的唯一标识符来请求一次性使用凭证(例如，pki证书)作为应用组件实例的第一身份凭证，并接收以密码方式生成的一次性使用凭证作为应用组件实例的第一身份凭证。计算设备采用虚拟化引擎，该虚拟化引擎提供以密码方式生成的一次性使用凭证以供包含应用组件实例的容器使用。
[0024]
在另一个示例中，为了重新启动或替换组件实例，一个或多个计算设备使用与第一应用组件实例相关联的先前的第一身份凭证的唯一标识符为第一应用组件实例的替换组件实例请求动态创建的替换第一身份凭证。一个或多个计算设备接收动态创建的替换第一身份凭证，该动态创建的替换第一身份凭证包括与第一应用组件实例相关联的先前的第一身份凭证的以密码方式绑定的唯一标识符。一个或多个计算设备使用基于替换第一身份凭证签名的请求，为应用的替换应用组件实例请求动态创建的第二身份凭证(例如，操作身份凭证)。一个或多个计算设备接收动态创建的第二身份凭证，并在密码操作中使用该动态创建的第二身份凭证。
[0025]
在“替换条件”下，即，在重新启动应用的情况下，也替换第一(供给(provisioning)/制造/登记)凭证。系统提供凭证的相关性，使得由设备或应用的唯一属性定义的基础身份(唯一标识符)每次都使用同一组属性来定义每个新凭证。
[0026]
在一个示例中，使用与替换第一应用组件实例相关联的替换第一身份凭证对证书签名请求进行签名。还公开了对应的方法。
具体实施方式
[0027]
两个身份的使用
[0028]
在一些系统中，在制造期间引入到(硬件)设备的初始“制造身份”被用于以密码方式对可以管理(在密码意义上，即，更新、暂停、撤销)的“操作身份”的请求进行“签名”。在本公开中，“制造身份”是短暂的——在很短的时间段内保持存在——并且可以认为“操作身份”可以被直接交付。
[0029]
但是，虽然这种直接证书注入可以作为实施例得到支持，但是它可能不是优选的：由组件获取的证书为应用提供了完全安全的私有密钥(甚至引擎不知道它)，而引擎确实知道制造证书(和密钥)。获取原始“制造身份”并且知道关于组件操作的所有信息的攻击者无法使用这种信息来得出该私有密钥。
[0030]
由于数字标识符(id)的结构，单个制造证书也可以生成几个操作密钥(有时出于不同目的)；并且本文的系统使用该新的“产生”证书/密钥来获取附加的身份，以供在一个或多个设备应用内使用。
[0031]
组件身份
[0032]
每个产品组件已经拥有唯一身份(即，唯一标识符)，每个软件元素的语义目的是设备的设计和操作行为的一部分。例如，工业器械“知道”它具有从连接到pci总线3上的usb端口5的热电偶接收温度数据的应用组件；该器械上的另一个软件元素“知道”该热电偶位于炉子31b的排烟口13处。
[0033]
挑战在于该组件能够向其它软件元素“证明”其身份。当组件是在同一进程内执行线程的静态链接库时，这种证明是固有的；当该组件仅通过网络连接进行交互时，需要唯一的、可公开核实的身份凭证，以能够将合法实例与意外的错误配置和恶意攻击者区分开。这
意味着任何形式的认证对于使用(注意，不是对于例如容器的实例，而是对于报告关于热电偶的应用，该热电偶报告炉子31b的排烟口13处的温度)都必须是唯一的。
[0034]
身份凭证必须可核实为表示唯一身份，pki证书在这方面非常优秀，因为其行为被理解，并且软件容易可用于允许证书的核实。但是，将认识到的是，pki证书仅仅是一个示例，并且本文描述的操作可以适用于对称密钥技术和其它共享秘密密钥技术。
[0035]
容器
[0036]
容器是组合(通常)单个可执行程序和可执行程序所需环境的映像；这使得分发更简单，减少了应用缺少必要环境或配置数据的可能性，并将容器与平台上的其它容器隔离。平台上的所有容器都共享同一内核(其是负责控制对系统资源的访问的适当“操作系统”)。平台可以运行容器和传统影像的组合。
[0037]
当在云服务中使用时，容器通常被设计为临时性的以限制其升级、修改或替换的操作成本，而持久性信息被保持在容器外部。虽然容器框架是通用的，但是容器本身可以包含不同的可执行程序。此外，通常使用自定义信息启动每个容器(至少，必须足够详细地指定适当的容器(其包括服务于要满足的特定角色的应用)，以允许它服务于其目的)。
[0038]
容器仅仅是软件设计模式的推广；相同的要求或多或少地适用于许多或大多数软件应用，但是它们使(隔离的)一些品质达到极致。通用容器与其主机的文件系统以及与其设备隔离。当产生容器时，容器管理器可以准予对设备的访问权限(在docker
tm
中，通过指定
“-
device<devicepath>”)，在最新版本的docker
tm
中，不再需要对容器进行特权设置。容器的网络访问可以通过配置来控制。
[0039]
图1是本发明的基于容器的实现方式的实施例的图示。注意，这是功能视图，每个组件本身可以被实现为单个元素或一系列元素。元素和/或组件可以以任何合适的方式实现。在一些实施例中，这包括存储在存储器中的存储的软件、固件或其它可执行代码(在被执行时使一个或多个处理器如本文所述地操作)和/或一个或多个现场可编程门阵列(fpga)、专用集成电路(asic)或被配置为或可配置为执行本文所述的操作的任何其它合适的逻辑。除了或代替使用可编程处理器，在希望时，逻辑也可以被实现为一个或多个状态机或其它合适的逻辑。当使用一个或多个处理器实现时，一个或多个处理器可以包括cpu、gpu或任何其它合适结构的一个或多个处理核心，并且如果希望，可以被并入在一个或多个设备、可经由互联网访问的web服务器、企业服务器或任何其它合适的组件中。存储器可以是任何合适的存储器，包括但不限于ram、rom、dram、sram、光学存储装置或任何合适的存储装置中的一种或多种，并且还可以包括一个或多个数据库。
[0040]
如图1中可以看出的，在这个示例中，与应用的主要功能一起示出了一种实现方式：需要安全身份凭证的应用由虚线示出，其中本发明的实施例用对角线示出。
[0041]
还参考图2，应用的应用管理器10确定应用的组件12-16的数量和作用；这可以动态或静态完成。例如，在动态的情况下，应用管理器执行发现(以确定不同组件的性质和类型，通常针对准许/预期的组件列表进行验证)，如在分布式系统和基于web的环境中已知的那样；对于静态供给(尤其是在预计有固定的一组元素或组件并且其必须存在以允许服务的工业系统中)，将供给组件及其类型的列表。
[0042]
为应用管理器10供给由发行ca 18或任何适当的可信授权机构创建并被其信任的身份凭证；该身份凭证可以通过具有本领域知识的人员所熟悉的任何手段引入到应用管理
器10中。
[0043]
对于需要身份凭证的应用的每个组件，应用管理器10使用接口101通过提交唯一识别该应用中的那个组件的唯一标识符信息来请求身份凭证200(作为示例而非限制本发明的通用性，工业传感器应用可以使用关于节点、传感器、其附件和配置的信息；对于金融服务应用，该信息可以包括特定用户的账户信息和其它凭证)。在一个示例中，制造代理20(其暴露接口101)可以被用于向服务网关22提交身份凭证请求(例如，足以允许创建证书的数据)，服务网关22包括应用组件的唯一身份(即，唯一标识符)并与证书授权机构(ca)18交互以创建202与该唯一识别信息相关的pki证书；证书以密码方式绑定唯一标识数据。包含使用唯一身份生成的公共和私有密钥对的证书通过接口101返回206给应用管理器10。在一个示例中，身份凭证是在使用之后被撤销或在定义的时间段之后到期的一次性使用凭证。但是，可以采用任何一次性使用机制。在其它实施例中，身份凭证不必是一次性使用凭证。本领域的从业人员将认识到，身份发行机制的具体细节可以改变，同时仍然在本发明的范围内。
[0044]
用于识别该生成的身份凭证的适当信息由管理控制台26(也被称为供给服务器)在身份供给数据库24中更新204，这可以在内部或通过接口102显式完成，而不失一般性。
[0045]
该身份凭证被授予206在需要其身份的外部可核实证明的组件上。在实施例中，该身份凭证在组件初始化时被授予。本领域的从业者将认识到，身份凭证可以被引入到静态可执行映像，或者视情况通过本领域的从业者已知的任何数量的手段被动态地引入到该执行环境；优选实施例包括但不限于共享存储器、初始化参数、发现服务、初始化消息和机制以及通信服务。
[0046]
针对需要身份证明的每个组件重复该处理。
[0047]
每个组件已被扩展具有使用接口方面28通过接口103与公开的身份管理操作进行交互的能力。每个组件在卷入需要可公开核实的安全身份的操作之前，都使用该第一身份凭证来获取新的、唯一的、创建的身份；在优选实施例中，这是通过使用该第一身份凭证(例如，公共密钥)签名并通过接口103提交的证书签名请求csr来完成的。所公开的身份管理操作确认请求有效；在优选实施例中，这是通过检查请求及其签名来进行的；如果请求有效，那么通过服务网关22通过接口103从ca 18返回数字证书形式的新身份凭证。
[0048]
这种新的身份凭证可以由组件按照需要用于执行密码功能，诸如但不限于例如对信息进行加密、核实签名和对数据进行数字签名。如步骤208所示，应用管理器10指示容器管理器30启动已经为其提供身份凭证的应用。如步骤210所示，容器管理器30创建容器32。诸如服务器之类的应用主机34经由使用容器32来开始应用。容器指示网关应用，如步骤212所示。数据中心中的一个或多个服务器或服务类机器(在这个示例中一般地示为身份管理系统36)包括服务网关22、制造代理20、发行证书授权机构18、供给服务器26和身份供给数据库24。身份供给数据包括由ca 18发行的经存储的证书。供给服务器26可以存储凭证的公共证书信息，或者可以引用ca数据。而且，各种功能组件可以根据希望适当地分布在多个设备之间。在一个示例中，应用控制器39和应用主机34位于一个或多个服务器(也参见图7)中，诸如web服务器或任何其它合适的设备。在这个示例中，传感器42将信息提供给相应的应用组件。在一些示例中，本文提供的服务可以是云服务的一部分。
[0049]
并非限制实现方式，替代实施例将看到步骤206和208被修改以替代地生成“组身
api(接口102)执行设备/应用的这些识别特性的提交。这样做使得请求者被信任为真实的。由同一ca信任(通常是因为它是由同一ca发行的)单独的凭证(在应用主机上预先供给并由应用管理器10使用)被使用。
[0063]
在一些实施例中，供给身份凭证将仅在该设备的供给信息的上下文中使用(它对于任何其它设备无效，或者在组身份的情况下，对于不在该组中的任何设备无效)。
[0064]
第二应用(其已获取该证书和设备身份)可以尝试模拟该设备。存在一个窗口，在此期间可能会发生这种模拟(直到在身份管理系统内调解了两个转换)。很难告诉哪个是“真实的”，哪个(些)是替身(doppelganger)，但是可以确定已发生危害。
[0065]
如果拦截器获得第一(“供给”)身份凭证并首先使用它，那么有几种缓解措施。
[0066]
系统将识别预期的软件的认证尝试是无效的(因为另一个应用已经使用该凭证进行了认证)，并且经常会发出提醒或警报来通知这些事件，从而导致后续调查。“预期的”软件是证书的合法用户。当合法设备尝试执行动作时，系统将检测到这些请求来自替代来源，现在(至少)有两个设备/应用断言相同的身份并使用相同的凭证来证明这一点(从而违反了该身份唯一的要求)。系统可能无法确定哪个是合法的(第二个到达的将导致提醒或指示已检测到这种错误状况并且应进行调查)。
[0067]
消息流程
[0068]
在优选实施例并且在图2中示出的上下文中，存在可以提供聚合和管理服务的“网关”；虽然其角色与本发明不直接相关，但它说明了本发明如何可以支持一个以上的应用(并且一者依赖于另一者，即，应用依赖于网关)。
[0069]
再次参考图2，换句话说，应用管理器10被供给由身份管理系统创建并受身份管理系统信任的身份凭证206；该身份可以通过具有本领域知识的技术人员熟悉的任何手段引入到应用管理器10中。
[0070]
对于该网关，在步骤200中，应用管理器10使用接口101通过提交唯一标识符信息“gtwyinfo”来请求该网关的身份凭证，该唯一标识符信息“gtwyinfo”唯一地识别该应用中的那个组件(例如，组件12)。
[0071]
在供给服务器26处更新识别该生成的身份凭证的适当信息，这可以在身份管理系统36内部进行，或者通过接口102显式地进行而不失一般性。在这个实施例中，还示出为步骤204。
[0072]
在步骤206中返回的该身份被授予在需要身份的组件上。在优选实施例中，在组件初始化时授予该身份(步骤208、210、212)。
[0073]
每个组件已被扩展具有通过接口103(例如，通过接口方面28)与身份管理系统进行交互的能力。该接口可以基于用于执行登记的scep、est或其它行业标准协议(以获取操作证书——“第二身份凭证”或“身份证明”)，并以后用于(操作证书的)续签。在一些实施例中，每个组件在卷入需要可公开核实的安全身份的系统之前，使用该第一身份凭证来获取新的唯一的创建的身份；在这个实施例中，这在步骤214中利用使用该第一身份凭证签名并通过例如接口103提交的证书签名请求来完成。身份管理系统经由ca 18确认请求有效；在优选实施例中，这是通过检查请求及其签名来进行的；如果请求有效，那么如步骤216所示，例如通过接口103返回新的第二身份凭证。
[0074]
该第二身份凭证由组件按照需要用于执行加密功能；在这个实施例中，这在步骤
218中在认证操作的上下文中示出。
[0075]
图3图示了将“应用”(其被启动以监视传感器42或其它特定于设备的组件)引入到应用主机34的实施例。该消息流程图示了如何在服务操作的上下文中使用获取的供给身份。
[0076]
图3指示了用于向应用引入身份凭证的步骤和交互，该应用被启动以在软件容器中执行。在这个实施例中，应用通过已经引入到环境中的egw 40(边缘网关)与用于管理其操作身份的环境交互。
[0077]
在步骤300中，应用管理器10(参考图1)使用例如接口101通过提交唯一标识符信息“sensorinfo”来请求应用组件12的身份凭证，该唯一标识符信息“sensorinfo”唯一地识别该应用中的那个组件。ca 18基于被存储为应用供给数据37的唯一标识符信息“sensorinfo”来产生初始身份凭证“identity1”。
[0078]
在“供给”存储库或服务26处更新301用于识别该生成的身份凭证的适当信息，这可以在身份管理系统内部进行，或者通过接口102显式地进行而不失一般性。在这个实施例中，还示出为步骤301。
[0079]
在步骤302中返回的identity1(第一身份凭证)是包含sensorinfo和对应的公共密钥/私有密钥对的证书，并被授予在需要身份凭证的应用组件上。在优选实施例中，在组件初始化时授予该身份凭证(步骤304、306、308)。
[0080]
利用该过程的每个应用组件可以被扩展具有通过接口103(参见图1)与身份管理系统36进行交互的能力。在一些实施例中，每个组件在卷入需要可公开核实的安全身份(经由pki)的操作之前，使用该第一身份凭证来获取新的唯一的动态创建的身份；在这个实施例中，这是在步骤310中利用使用该第一身份凭证签名并通过例如接口103提交的证书签名请求来完成的(在这个优选实施例中，它由egw转发312，但用于获取证书的csr(证书签名请求)的交付可以通过本领域从业人员熟悉的任何手段来完成)。身份管理系统确认请求有效；在实施例中，这是通过检查请求及其签名进行的；如果请求有效，那么通过例如接口103在314返回新的身份凭证。
[0081]
该新的身份凭证可以由组件按照需要用于执行加密功能。在这个实施例中，这在步骤316中在认证操作的上下文中示出。作为该实施例的一方面，该身份凭证被用于保护在步骤322中传送到应用管理器(或其它适当的目的地)的传感器数据(在步骤320中从由该应用组件监视的传感器42接收318)。
[0082]
组件退出和重新实例化
[0083]
应用容器的退出以及应用组件在新容器中的还原所涉及的步骤在以上消息流程和步骤中未具体示出，但是可以参考这些较早的图描述的并在图6中示出。与基于容器的环境的实施例相关联的那些步骤的简要回顾如下。本领域的从业人员将意识到，这仅是一个实施例，并且可以扩展到其它执行环境而不失一般性。
[0084]
容器管理器30通知应用管理器10容器已退出。应用管理器10确定是否需要重新开始应用组件12以满足产品的需求。假设将要重新开始应用组件，那么应用管理器10将再次与该身份管理系统交互，参考图3，应用管理器10通知接口101先前的操作身份凭证“identity2”不再有效，并且(当身份是使用pki证书的实施例的身份时)必须被撤销或以其它方式(如果不是pki证书)变为无效。
[0085]
应用管理器10将基于唯一标识符信息“sensorinfo”创建新的“identity1”凭证，并更新“供给”存储库中与传感器相关联的身份(这些步骤与图3的步骤300相似)。
[0086]
其余步骤如图3所示，认识到，由于步骤300中的动作，身份管理系统准备接受即将发生的身份请求(图3描述中的步骤306)并发行新的“identity2”凭证以供重新实例化的应用组件使用。
[0087]
如所示出的，应用管理器对于第一身份凭证(也被称为供给身份)的请求300在一个示例中是使用唯一传感器信息sensorinfo生成的公共密钥基础设施证书。第一身份凭证(例如，证书，也被称为t1(第1层)凭证)由ca 18生成。identity1凭证是包含唯一传感器信息数据(sensorinfo)以及一个或多个公共密钥和私有密钥对的公共密钥证书。
[0088]
如上所述的虚拟化引擎可以是容器环境中的docker容器引擎，但可以在虚拟机环境中或以任何其它合适的方式实现为vmware
tm
虚拟引擎。应用管理器10知道应用正在使用的环境。服务网关22充当证书授权机构18的代表，并发出证书撤销请求，并向ca 18发出证书请求。供给组件26将ca 18所发行的证书的引用或冗余本地副本作为身份供给数据存储在供给数据库24中。应用组件在容器内部运行，并且私有密钥不由应用组件或应用存储在持久性存储中。应用采用密码引擎来例如对操作身份的请求进行签名，并根据期望执行其它密码功能。
[0089]
图4是类似于图1所示的采用虚拟化引擎400的功能框图。这些操作可以应用于容器环境(例如，当客户端通过api或(一个或多个)实用程序进行交互以发出对于诸如docker engine的容器“引擎”的请求时)，并且还可以应用于其它虚拟化环境(例如，通过api或(一个或多个)实用程序进行交互以发出虚拟机监督程序请求)。在一个示例中，对等方402可以是传感器的监视站。在这个示例中，应用组件向ca发出的对于操作身份的请求是对于新证书的请求，因此是对于新identity2的请求，其中第一身份凭证经由已提供的公共密钥证书的撤销而被撤销并且用作一次性使用身份的类型。新证书用作操作身份凭证(identity2)，并包含传感器信息和另一个公共密钥和/或私有密钥。
[0090]
图5是基于图1和图4所示的体系架构的类似于图3的通信流程图。将描述传感器应用的实施例的操作场景。在这个示例中，应用的实例化由平台p55上的应用管理器10指示。在这个场景中，应用管理器10已经识别热电偶应用a7监视炉子5、排气口3上的热电偶编号2的要求。因此，在这个环境中，该应用由包含以下方面的唯一标识符(例如，sensorinfo)引用：{a7/p55/f5/v3/t2}。注意，容器保持匿名，它只是提供临时载具以用于执行应用。该方法通过上面图示的方法将密码安全的可发布凭证与该应用的唯一标识符相关联。
[0091]
应用管理器10请求300为应用组件创建身份凭证(1)。身份凭证(即，由ca签名的包含唯一标识符和基于唯一身份的公共密钥/私有密钥对的证书)被创建，以便包含根据凭证的规范适当地编码的唯一身份{a7/p55/f5/v3/t2}，并且凭证与应用的关联被记录301作为供给数据库24中的供给数据。身份凭证被返回302给应用管理器，应用管理器将身份凭证与其启动应用的请求一起传递304给虚拟化引擎。
[0092]
虚拟化引擎30将身份凭证传递306到容器，该容器使其可用于308应用组件。通过使用与最佳实践一致的方法，应用组件使用该临时(例如，一次性使用)身份凭证(即identity1)请求310更安全的身份。使用临时身份凭证的公共密钥对该请求310进行签名，并针对供给数据库24中的供给信息和证书信息验证请求310，并将该新身份返回314给应
用，该应用可以在执行其任务时与对等方402的交互中使用它。在该实施例和工作流程中，identity1被视为“一次性”使用凭证，并且此时被撤销500。对等方可以使用提供的凭证来认证316应用的身份502(即{a7/p55/f5/v3/t2})。
[0093]
图6是图示根据本公开中阐述的一个示例的重新启动应用的通信流程图。如所示出的，继续涉及传感器应用的场景，考虑容器退出的情况。按照这些环境的惯例，虚拟化引擎接收容器已退出的指示(以及状态和其它信息)，并回收与其操作一致的资源。一旦意识到容器的退出，应用管理器10将执行适合其环境的业务处理，以确定下一步动作。
[0094]
可能不再需要应用组件，在这种情况下，应用管理器10将不会重新启动应用。在一个示例中，应用管理器终止身份以反映这种有用性结束(end-of-usefullness)条件。应用管理器更新身份凭证，使得环境中的这个或另一个实体不能再进一步使用该身份凭证。例如，这是通过接口102完成的，该可信代理与系统(mp/saw/供给服务器)进行通信，以更新由供给服务器记录的设备状态，从而指示其身份由那组属性定义的设备不应被授予任何进一步的凭证或身份证明。此后，对于新的“第一凭证”的任何后续请求将被拒绝。
[0095]
可能仍然需要应用组件(它可能已经崩溃或它可能已经被请求退出，使得可以更新应用映像或另一个软件组件，等等)，因此在虚拟化引擎400通知600应用管理器10容器退出之后，应用管理器10可以决定重新启动应用602。
[0096]
如果要重新启动应用组件，那么应用管理器10使用相同的元组{a7/p55/f5/v3/t2}请求604应用组件的凭证。应认识到，初始身份凭证(identity1)和操作(identity2)凭证不再有用。如果它们尚未被撤销(例如，t1从未被使用过；或者曾被使用过，并且已经为先前的实例创建t2)，那么它们被ca撤销以确保持续的安全性，并且新的凭证identity1b被创建以便包含身份{a7/p55/f5/v3/t2}、在供给数据库24中被更新606，并且被返回给应用管理器608。
[0097]
应用管理器10将其(重新)启动应用组件的请求传递610到虚拟化引擎400。虚拟化引擎400将凭证14传递612到容器，该容器使其可用于614应用。在一个示例中，通过使用与最佳实践一致的方法，应用组件使用该临时身份凭证来请求616更安全的身份(操作身份凭证)。针对供给信息和凭证信息验证该请求616，并且将重新启动身份凭证返回618给应用，该应用可以在执行其任务时与对等方的交互中使用它。再次，在该实施例和工作流程中，identity1被视为“一次性”凭证，并且此时被撤销617。
[0098]
对等方可以使用所提供的凭证来认证620应用的身份。重要的是，要注意，对等方接收并验证{identity2b}622(更新的证书)。这不是不寻常的更改(当然，事实上，证书被持续(即使很少)更新)，但是由证书识别的身份{a7/p55/f5/v3/t2}与identity2(或任何先前的化身(incarnation))的身份相同。
[0099]
图7图示了身份管理系统36和/或应用主机34的框图，该身份管理系统36和/或应用主机34被实现为具有一个或多个处理器700(诸如cpu、dsp或(一个或多个)任何其它合适的处理器)和可以由一个或多个处理器700通过本领域中已知的任何合适的总线结构704访问的存储器702。存储器702可以是任何合适的存储器，包括通过网络分布的存储器和/或ram、dram、rom、eprom形式的本地存储器或任何其它合适的存储器。在这个示例中，存储器702包含机器可读指令，该机器可读指令在被执行时使一个或多个处理器700执行本文所述的各个操作。(一个或多个)处理器700用作在执行所存储的代码时可操作为执行功能的逻
辑。计算设备还可以以任何其它合适的形式实现，诸如专用集成电路(asic)、状态机、或者硬件和存储软件的任何合适组合。如本领域中已知的，该装置还包括合适的接口706，以提供到网络的接口、用户接口或所需的任何其它合适的接口。
[0100]
在前面的优选实施例的详细描述中，已经参考了构成其部分的附图，并且在附图中通过图示的方式示出了可以实践本发明的特定优选实施例。充分详细地描述了这些实施例以使本领域技术人员能够实践本发明，并且应该理解，可以利用其它实施例，并且可以进行逻辑、机械、化学和电气更改而不脱离本发明的范围。为了避免使本领域技术人员能够实践本发明所不必要的细节，该描述可能省略了本领域技术人员已知的某些信息。此外，本领域技术人员可以容易构造结合本发明的教导的许多其它变化的实施例。因此，本发明无意限于本文所述的具体形式，而是相反，其意图是涵盖可以合理地包括在本发明的范围内的这些替代、修改和等同形式。因此，前面的详细描述不是限制性的，并且本发明的范围仅由所附权利要求限定。实施例和其中描述的示例的以上详细描述仅出于例示和描述的目的给出，并不是为了限制。因此，可以预期的是，本发明涵盖落入以上公开和本文所要求保护的基本原理的范围内的任何和所有修改、变型或等同形式。
[0101]
上面的详细描述和其中描述的示例仅出于说明和描述的目的给出，并不是为了限制。例如，可以以任何合适的方式完成所描述的操作。方法可以以仍然提供所描述的操作和结果的任何合适的顺序来完成。因此，可以预期的是，本实施例覆盖落在以上公开的和本文所要求保护的基本原理的精神和范围内的任何和所有修改、变型或等同形式。