由多租户服务提供方执行动态平台重新配置

摘要

计算机平台上的可管理性引擎或附属处理器可从可管理性引擎的制造时所授权的服务提供方接收对于激活并且使用嵌入该平台内的特征。可管理性引擎可通过服务提供方向许可服务器发起对于认证的请求。许可服务器可通过服务提供方提供服务提供方认证的证据，连同识别服务提供方的证书。然后可管理性引擎可能够激活关于耦合于可管理性引擎的平台的特征，但仅通过已经被授权的一个特定服务提供方。

说明书

技术领域

这大体上涉及计算机系统，并且具体地涉及由服务提供方对那些计算机系统上的特征的选择性启用。

背景技术

计算机系统及其部件可以能想象地提供有一组特征，其中一些特征在被最终用户购买时可能是不活跃的。服务提供方然后可例如以费用作为回报而被授权来激活当前被最终用户所拥有的平台上的那些特征。

一个示例将是计算机可以被卖出具有实现某一处理器速度的给定倾斜率（skew rate）。给定服务提供方可希望启用更高的速度来启用服务提供方所希望提供的服务。然后服务提供方可与处理器的制造商协定以使服务提供方能够激活比销售时处理器内可用的更高的倾斜率。这样的激活可引致制造商向服务提供方收费。然后服务提供方可以将激活的特征（在该情况下是较高的倾斜率）与服务提供方所提供的其他特征绑定。

附图说明

图1是本发明的一个实施例的示意描绘；

图2是对于本发明的一个实施例的终端到终端激活流程；

图3是对于本发明的一个实施例的流程图；以及

图4是根据本发明的一个实施例对于服务提供方的密钥结构。

具体实施方式

根据本发明的一些实施例，动态平台重新配置通过多租户服务提供方而可以是可能的。也就是说，给定硬件装置制造商可授权超过一个服务提供方向制造商的硬件的最终用户提供服务。这在一些情况下可由第一服务提供方使用密钥结构来实现，该密钥结构保护一个服务提供方以避免其他服务提供方将使用激活的硬件特征（大概在一定成本下）的可能性。

作为示例，给定服务提供方可希望提供比在制造商销售的处理器中原始预备的更高的倾斜率。服务提供方可能够使用许可服务来进行此。服务提供方可付费给部件制造商以便得到在处理器内激活增强特征的许可。但该服务提供方不希望第二服务提供方一起并且使最终用户能够使用该相同的增强特征（在该情况下是较高的倾斜率），因为第一服务提供方为升级付费并且不能与不花钱获得该特征的第二服务提供方在平等的基础上竞争。

同时，硬件装置制造商可更喜欢向多个服务提供方销售升级硬件装置的权限。这对制造商提供更大的收益并且对制造商的最终用户/顾客提供更多的服务。

在一些实施例中，这些全异机会中的全部可以由允许不同服务提供方与最终用户的平台中的相同硬件装置一起工作的许可和证书方案的组合来完成。当硬件装置的特征被一个服务提供方启用时，利用识别该服务提供方的证书来启用它使得第二服务提供方在未向硬件装置的制造商支付任何费用的情况下无法直接使用该相同激活特征。

从而，参考图1，根据一个实施例，可实现云或连续计算环境。尽管在该示例中仅示出一个许可服务器，云15可包括任何数量的服务提供方服务器12和任何数量的许可服务器14。任何数量的平台11可通过云来与服务提供方服务器通信，服务提供方服务器在一个实施例中进而通过云与许可服务器或多个许可服务器通信。

存储装置17可耦合于可管理性引擎10。该存储装置可以是光、半导体或磁存储器。

从而，希望向给定平台11提供服务的服务提供方可尝试激活平台11上的特征，其对于提供该服务是必需的。例如，服务提供方可希望提高给定平台的操作速度使得它将操作快到足以高效地做服务提供方想要平台所做的某些事情。

在一个实施例中，服务提供方联系许可服务器来获得对该提高的许可。在一些情况下，该许可可以在服务提供方产生的成本下来获得。在一个实施例中，费用可由服务提供方产生来升级第三方的平台。大概地，服务提供方然后得到平台11的所有者或可能某种其他实体的补偿。

服务提供方向平台11内的可管理性引擎10呈现许可。该可管理性引擎10可以是服务处理器或附属处理器，其在一些实施例中是与平台的中央处理单元分离并且分隔的第二处理器。然而，其他设置可以也是可能的。在一些实施例中，可管理性引擎甚至可以不被平台的剩余部分访问。

可管理性引擎10然后在它能够使平台11能力被修改之前证实该许可是正确的。因为平台能力中的全部都未被激活，这防止平台的滥用并且为了销售平台和/或可管理性引擎的制造商的利益而实施补偿方案（大概以较低的成本）。

在一个实施例中，如果然后激活平台特征，第二服务提供方无法使用平台11上的该特征，因为该特征仅仅能连同证书一起被激活，该证书与一个特定服务提供方关联。从而，在这样的实施例中，不具有证书的其他服务提供方不可以使用在平台上激活的特征。这防止免费加载的服务提供方从其他服务提供方激活的特征中获益，并且因此防止在不平等的成本基础上竞争。

从而，根据一个实施例，参考图2，可牵涉三个实体。它们是可管理性引擎或ME 10、服务提供方服务器12和许可服务器14。

在一些实施例中，可管理性引擎10可执行操作，该操作被保护以避免基于主机（即，平台）的网络威胁。也就是说，可管理性引擎不仅与平台11自身隔离，而且与平台外部的装置隔离，但通过网络与之连接。可管理性引擎可被服务提供方和许可服务器两者所信赖来保护平台的资源和执行上下文。

在一些实施例中，服务提供方基于不对称密钥和身份保护技术向平台的所有者提供服务。许可服务器确保服务提供方在为了服务提供方和平台最终用户的利益而实现平台的特征的激活之前与平台或可管理性引擎制造商具有适当的活跃业务关系。

从而，初始地，可以由可管理性引擎10在本地生成密钥，如在16处指示的。该密钥初始因为它无法用于执行任何任意事务而未被激活。然后，如在18处指示的，在可管理性引擎与服务提供方之间建立安全或西格玛通道。西格玛通道是在Intel Media Vault技术中使用的术语，但任何安全通道可在本发明的一些实施例中实现。西格玛通道例如可使用签名的Diffie-Hellman密钥，其在它发布给最终用户之前内置到可管理性引擎内。在一个实施例中，西格玛通道可使用增强的隐私识别或EPID技术（从Intel公司可获得）。EPID是加密方案，其实现硬件装置的远程验证，同时保护装置所有者的隐私。具有嵌入式EPID私钥的硬件装置可以证明远程方是有效装置（硬件制造商所认证的），而不暴露所有者的身份并且无需证实者能够将验证尝试联系起来。

相同的密钥可用于证明该平台是可靠的。它例如因为它由控制许可服务器并且授权服务提供方激活平台（其包括可管理性引擎）的特征的制造商来制造而可以是可靠的。密钥还可用于将可管理性引擎的环境（其包括它的固件哈希和版本信息）报告给远程位点。另外，密钥可用于向服务提供方公开公钥，因此服务提供方可以证实密钥并且确认该平台是可靠的。

西格玛通道可使用Diffie-Hellman密钥交换在可管理性引擎与服务提供方之间创建共享对称密钥，同时使用EPID来证明可管理性引擎是合法的。服务提供方呈现由可管理性引擎的制造商发布的证书使得可管理性引擎可以证实服务提供方由该制造商授权。然后，如在20处指示的，服务提供方依靠许可服务器14来供应密钥吊销列表（识别为GRP-RL、PRIV-RL和SIG-RL），以及传统吊销列表（CRL）以用于证实服务提供方。从而，权限被吊销的服务提供方可以容易地由可管理性引擎识别来确保仅被授权的服务提供方修改平台（其包括可管理性引擎）的特征。

然后，如在22处指示的，服务提供方向可管理性引擎供应吊销列表使得EPID签名操作可包括允许服务提供方确定EPID签名吊销状态的证据。可管理性引擎接收对于服务提供方的证书的吊销状态。如果可管理性引擎不能处理吊销列表，它相反可依靠在线证书状态协议（OCSP）响应器，其在一个实施例中经由服务提供方而被代理。参见RFC 2560.11, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, Network Working Group Request for Comments, June 1999。

然后可管理性引擎签名随机数和吊销列表，如在框24处指示的，从而完成安全协议握手。另外，对于密钥的证书签名请求（CSR）被供应给服务提供方以便转发给许可服务器。在一个实施例中，该证书签名请求包含证明密钥的合法性的EPID签名属性和它的默认配置属性。可管理性引擎然后发起对来自许可服务器的许可的请求。

接着，如在25处指示的，连同证书认证（CA）后端一起工作的服务提供方证实CSR。该证实可包括通过密钥的EPID签名的证实。CA签名认定包含在CSR中的信息是合法的并且因此它应该也证实EPID签名。

在26处，CA后端发出对于密钥的证书，其可包括指示如何保护密钥的证书扩展。这可经由将包含在CSR中的EPID证明复制到该证书内来实现。

之后，在27处，服务提供方将许可请求中继给许可服务器，从而授权许可服务器激活密钥以供使用。许可还可授权服务提供方对影响该密钥的使用的策略采取管理控制。

接着，在28处，许可服务器证实许可请求并且检查服务提供方的业务协定是否支持密钥的激活以及可管理性引擎中支持特征的使用。在一些实施例中，许可服务器还可证实可管理性引擎能够支持服务提供方所需要的能力。

许可服务器还可发出授权可管理性引擎激活密钥以在适当的情况下与服务提供方一起使用的许可（如在30处指示的）。服务提供方然后被授权来配置控制用户平台以及其他平台可如何交互的策略（使用密钥）。服务提供方然后有效地变成密钥策略的所有者。在31处，许可服务器更新详述服务提供方和激活事件的日志，其在一些实施例中可用于向服务提供方收费。

接着，在32处，由许可服务器发出的许可被供应给服务提供方的服务器。该许可可以对于特定平台和特定密钥是特定的。如果创建第二或第三密钥，该第二或第三服务提供方可以作为密钥所有者而被采用。

在一些实施例中，在34处，服务提供方监视许可服务器与可管理性引擎之间的许可流。服务提供方还可证实源于合法许可服务器的许可并且服务提供方可更新激活的许可服务器日志（如在33处指示的）。许可服务器和服务提供方日志可离线比较来根据任何业务安排审查记账细节。

最后，可管理性引擎通过激活密钥并且实现或过滤可管理性引擎能力的可用性来安装许可。例如，服务提供方可被许可以使用强的多因素验证，其例如将导致可管理性引擎配置成允许某些策略被与安全证明有关的服务提供方配置。一个这样的示例是What You See Is What You Sign，其中签名消息的内容无法改变（WYSIWYS）。

根据本发明的一个实施例，在图3中示出的流程图可在与可管理性引擎关联的软件、硬件或固件中实现。在软件实施例中，指令序列可存储在例如光、磁或半导体存储装置的非暂时性计算机可读介质上。

在框40处开始，由可管理性引擎建立与服务提供方的安全会话来为期望的服务注册。可管理性引擎可获得服务提供方公钥，或作为另一个示例，经由例如西格玛通道等安全通道协商一次性密码（OTP）种子（对于仅一次登录会话有效），如在框42中指示的。然后可管理性引擎将服务提供方的公钥或种子存储在所有者主体对象中，如在框44中指示的。

接着，在框46中，可管理性引擎使用密钥EPID来向许可服务器证明平台身份和配置。该证明可通过服务提供方中继。然后在一些实施例中，可管理性引擎获得并且证实对该主体的许可（使用在制造时在可管理性引擎处预备的激活主体），如在框48中指示的。可管理性引擎然后在菱形52处检查许可是否是可以。如果否的话，通过关闭西格玛通道并且执行清除而使该事务无效，如在72处指示的。如果许可是可以的，则可管理性引擎激活该主体或服务提供方，这在一个实施例中通过将主体元数据中的有效位设置为真而实现，如在框54中指示的。

管理实体通过例示在该主体活跃时被启用的平台能力列表来安装许可，如在框56中示出的。然后在58处可管理性引擎等待要使用的主体。在60处，主体结构也装载到可管理性引擎。在菱形62处的检查确定是否已经激活了该主体。如果是这样的话，对于许可结构中的每个可管理性引擎能力（框64），在菱形63处的检查确定该能力是否活跃。如果是这样的话，在框66处激活该能力并且对主体（密钥或种子）执行操作（框68）并且然后流程返回，如在70处指示的。

在图2和3中示出的序列可在硬件、软件和/或固件中实现。在软件实施例中，该序列可由存储在例如光、磁或半导体存储器等非暂时性计算机可读介质（其包括例如存储装置17）上的指令实现。该存储装置17还可存储由制造商引入的签名密钥和识别激活平台特征的特定服务提供方的密钥或种子。

从而，在一些实施例中，平台资源的所有权可扩展到多个服务提供方。然而，一些资源不共享，例如密钥或种子，而共享其他资源，像可管理性引擎执行环境。该许可规定了哪些资源被授权以供服务提供方使用。基于在例如主机嵌入式控制器接口（HECI）等安全接口上到达的请求，平台还动态实行对资源的访问控制。可管理性引擎可以通过跟踪在服务于命令时使用的密钥或种子而区分不同的服务提供方。因此，密钥或种子验证会话。会话使用许可来获悉可管理性引擎中的哪些资源以及平台对于该会话是可见的。

被验证的会话允许服务提供方将服务产品绑定，例如提供与由增强平台提供的其他技术绑定的防盗服务。在一些实施例中，该许可规定了绑定配置。绑定还允许每个服务提供方规定了对于该服务提供方所特定的安全和配置策略。例如，一个服务提供方可规定需要双因素验证，而另一个可规定三因素验证，并且一些其他服务提供方可规定完全没有验证。

图4示出代表用户或机器主体的可管理资源的关系的一个实施例。每个主体可与其他主体和使用策略关联。每个对象类别可描述如下。主体或主要主体可具有1…m的基数。主体可以是包含公共和私有成分的密钥。这些私有成分可每当将密钥值取出可管理性引擎之外时为了机密性而被包装。公钥当在X.509证书的上下文中使用时可称为SubjectPublicKey。参见ITU-T Recommendation X.509（2005）Information Technology Open Systems Interconnection, The Directory Authentication Framework 08/05（从瑞士日内瓦的国际电信联盟可获得）。当密钥用于与另一个系统或装置交互时，它是代表端点的主体实体。当主体用于验证用户时，主体代表用户而“讲话”。与主体关联的对象对如何许可主体代表用户或代表用户讲话施加限制。

所有者主体80具有基数1..1。所有者主体是对主体具有管理控制的服务提供方。所有者主体包含用于验证所有者实体并且与它通信的密钥86。它可包含用于验证所有者的证书的服务提供方公钥。它还可包括会话密钥（SK）和主密钥（MK）值，其对应于可管理性引擎与服务提供方之间的安全会话。

另一个主体82具有基数0..m。所有者主体可配置信任锚，其中该锚主体在建立到其他装置或服务器的安全连接时可信任该信任锚。 

激活主体84具有基数1..1。激活主体指用于验证许可服务器的凭证。这些凭证可在特定芯片集上提供，该特定芯片集可包括可管理性引擎并且包含在服务提供方的远程控制下打开和关闭该芯片集的特征的能力。激活事务标识符（例如，TX1）是该上下文的一部分并且包含主要主体的激活状态。

装置标识符90具有基数0..m。被可管理性引擎识别为可信网格或云的一部分的装置具有装置标识符。所有者主体可根据预先设置的配置策略来配置装置标识符。

主体元数据92具有基数1..1并且包含描述密钥迁移、备份和恢复处理的设定值。例如密钥是否可以用于签名、加密或密钥交换等使用约束可以是主体元数据的一部分。

使用策略88具有基数0..1并且指在使用密钥时的一组策略控制的约束。它可包括对于如何确认用户存在的多因素验证（MFA）规则。例如，在一个实施例中，用户存在可通过鼠标和显示器（其使计算机系统能够识别计算机用户）的使用的用户识别或签名模式来确认。隐私策略可限制该密钥可签名或加密的信息的量。数字权限管理策略还可限制用该密钥保护的数据可如何通过其他装置来重新分配。

用户存在94可具有基数0..m并且包含对于给出用户存在的证据的服务提供方和用户可设置的配置值。这可包括WYSIWAYS、近场通信（NFC）、可信输入/输出（IO）以及其他存在策略。

具有基数0..m的上下文96包括在使用主要主体时可用于使用的平台的特征和能力。上下文源可包括传感器输入，仅举几个例子，例如位点、取向、接近性、温度、功率和电池。

任务信息98具有基数0..m并且包含描述其中使用主要主体的可管理性引擎环境的证明上下文。

整个说明书中对“一个实施例”或“实施例”的引用意指连同该实施例描述的特定特征、结构或特性包括在包含在本发明内的至少一个实现中。从而，短语“一个实施例”或“在实施例中”的出现不一定指相同的实施例。此外，特定特征、结构或特性可采用除图示的特定实施例外的其他适合的形式而设立并且所有这样的形式可包含在本申请的权利要求内。

尽管已经关于有限数量的实施例描述本发明，本领域内技术人员将意识到从其中的许多修改和改动。规定附上的权利要求涵盖所有这样的修改和改动，它们落入本发明的真正精神和范围内。