CN111108735A - 资产更新服务 - Google Patents

Abstract

一种在多个远程设备上为一个或多个服务请求者管理资产更新服务的方法，所述方法包括：在管理服务器处接收指示要在一个或多个远程设备处更新的资产的更新数据；在管理服务器处接收活动数据，所述活动数据与所述更新数据关联并且指示更新要被应用于的远程设备的子集；和在管理服务器处接收通过向远程设备的所述子集传送更新通信来发起固件更新的请求，所述更新通信指示为了更新远程设备的资产而要检索的资产。

Description

资产更新服务

技术领域

本申请涉及一种使服务能够以可由第三方管理的自动且可靠的方式更新联网电子设备的固件或其他资产数据的机制。

背景技术

远程电子设备可被配置成连接到服务器并与服务器通信。服务器可被配置成管理设备的操作和与设备的通信。在许多应用，比如物联网(IoT)之类的应用中，可能存在配置成连接到服务器并由该服务器以类似或相同的方式管理的许多类似或相同的设备。

为了使设备安全并且可靠地工作，需要提供对设备的资产(比如设备的代码、密钥和/或配置之类)的更新。在例子中，在设备上运行的固件可能需要更新——例如，以解决安全缺陷或者修改设备的行为。在许多这样的应用中，这些设备可能在物理上完全不同或无法访问，或者数量众多以致无法分别直接手动更新每个设备的固件。

因此期望改进更新远程电子设备的资产(比如固件之类)的方式。

发明内容

一种用于在多个远程设备上为一个或多个服务请求者启用资产更新的方法，所述方法包括：在管理服务器处接收指示针对第一服务请求者的要在一个或多个远程设备处更新的资产的更新数据，所述更新数据包括清单数据，所述清单数据包括指示有效载荷的存储位置的有效载荷统一资源标识符(URI)、指示清单数据的信任的认证信息、和有效载荷散列；在管理服务器处接收活动数据，活动数据与更新数据关联并且至少指示针对第一服务请求者的、要对其应用资产更新的远程设备的子集；和在管理服务器处接收针对第一服务请求者发起资产更新的请求，所述资产更新是通过向由活动数据至少指示的远程设备的所述子集传送包括清单数据的更新通信来发起的，所述清单数据指示为了更新远程设备而要检索的有效载荷。

一种在多个远程设备上为一个或多个服务请求者启用资产更新的管理服务器，所述管理服务器包括：至少一个接口，用于：在管理服务器处接收指示针对第一服务请求者的要在一个或多个远程设备处更新的资产的更新数据，所述更新数据包括清单数据，所述清单数据包括指示有效载荷的存储位置的有效载荷统一资源标识符(URI)、指示清单数据的信任的认证信息、和有效载荷散列；在管理服务器处接收活动数据，活动数据与更新数据关联并且至少指示针对第一服务请求者的、要对其应用资产更新的远程设备的子集；和在管理服务器处接收针对第一服务请求者发起资产更新的请求，所述资产更新是通过向由活动数据至少指示的远程设备的所述子集传送包括清单数据的更新通信来发起的，所述清单数据指示为了更新远程设备而要检索的有效载荷。

附图说明

下面将参考附图说明本公开的例子，附图中：

图1图解说明按照例子的系统图；

图2图解说明按照活动发起固件的更新的例证方法的流程图；

图3图解说明创建清单(manifest)的例证方法的流程图；

图4图解说明将清单上传到管理服务器的例证工作流；

图5图解说明将有效载荷上传到管理服务器的例证工作流；

图6图解说明创建活动的例证工作流；

图7图解说明处理活动的例证工作流；

图8图解说明监视活动的进度的例证工作流；和

图9图解说明按照包含多个服务请求者的另一个例子的另一个系统图。

具体实施方式

本申请涉及提供一种设备和方法，所述设备和方法使得能够以自动且可靠的方式更新一个或多个远程设备的资产。资产的更新向第三方提供将进行更新活动的职责委托给具有许多技术优势的更新服务的能力。委托的一个方面在于第三方可能不希望必须信任更新服务才能开展更新。

更新服务基于第三方与设备之间建立的信任关系，提供如何使服务能够代表第三方进行更新，而无需第三方信任该服务。另外，更新服务不一定需要可以直接访问有效载荷，并且也不将有效载荷直接传递给设备。因此，在实施例中，固件更新的所有者和设备管理实体(即第一服务请求者)不必是同一实体。

通过第三方向服务提供包含有效载荷URI、指示清单数据的信任的认证信息、以及有效载荷散列的清单数据，以便传送给远程设备，远程设备具备可信地进行资产更新所需的一切，因为远程设备已与第三方建立了信任。因而，清单信息可被分发给服务，并被提供给多个远程设备，而不需要服务的信任。这是因为基于第一服务请求者和远程设备之间的信任关系，远程设备可信任清单数据(归因于认证信息)，从而可信任有效载荷URI。由于有效载荷URI可信，因此远程设备可以确保从其检索资产的URI是有效的。此外，由于有效载荷散列也可信，因此设备可进行对检索的散列的认证，并因此可信任获得的有效载荷。

另外，“第一服务请求者”不需要被潜在涉及，并且不需要复杂的技术能力来连接到多个不同的远程设备，这些设备可能涉及多种不同的通信协议和具有不同处理能力的设备。因而，第一服务请求者不需要具备任何与设备直接通信的能力。这种方法以不需要设备所有者信任设备通信使能者的方式，允许设备所有者和设备通信使能者之间的职责分离。

下面的描述只是举例说明了一些例子。

图1图解说明其中可以实现本技术的计算系统100。

计算系统100包含通信耦接到管理服务器120的多个远程电子设备110。远程电子设备110是可能位于不同位置的电子设备，比如物联网(IoT)设备之类。远程电子设备110可通过不同网络或者通过同一网络连接到管理服务器120。例如，远程电子设备110可通过有线或无线连接，连接到管理服务器120。

管理服务器120是配置成管理远程设备及它们各自与管理服务器120的连接的计算服务器(或多个服务器)。管理服务器使设备的资产可由设备的所有者或管理者管理和维护。设备的所有者或管理者可能要求更新其负责的设备的一个或多个资产，从而成为向管理服务器120请求与该请求关联的远程设备110的更新的请求者。管理服务器120可提供一个或多个接口，通过所述接口可以管理远程设备的更新。这可以通过接收经门户提供的数据和/或经诸如REST API之类的应用编程接口(API)网关接收数据的接口来提供。

在图1的布置中，管理服务器120可被配置成向远程设备110提供新的资产，比如新的固件之类，使得新的资产可被载入远程设备110中以便更新该设备。远程设备的资产可包括代码(比如固件或引导装载程序之类)、密钥提供或分发、或者配置设定中的一个或多个。在更新固件的例子中，新的固件需要被载入远程设备110中的原因可能有很多。例如，固件可修复远程设备上的关键固件错误，或者向设备添加新的功能。管理服务器120可包括配置成控制远程设备100的更新的管理的软件(这里称为云更新服务)。如后所述，管理服务器120运行以确保更新处理是安全的。通过确定固件经过认证(例如，使得防止闪存(flash)恶意固件的企图)，或者确定固件可被加密，可以提供安全性。管理服务器120可被配置成使得更新从管理服务器120被推送给远程设备110，使得远程设备110不必不断轮询更新，这使设备能效更高。

系统100还包括例如通过门户和API通信耦接到管理服务器120的开发者设备130。开发者设备130是固件及其对应元数据从其被提供给管理服务器120的电子设备。该处理将在后面更详细地说明。开发者设备可形成请求管理服务器120作为服务提供设备的资产的更新的服务请求者的一部分。开发者设备可以是开发者通过其能够提供将应用于远程设备110的固件映像(或者其他资产数据)的设备。

系统100还包括通信耦接到管理服务器120的操作者设备140。操作者设备是远程设备的所有者可从其处理远程设备的管理的电子设备。因此，操作者设备140形成请求远程设备的资产的更新的服务请求者的一部分。操作开发者设备130的开发者可以是操作所述操作者设备140的同一实体，或者所述实体可以是分开的实体。

远程设备100上的资产的更新，比如固件更新之类由管理服务器作为服务提供，并且是作为来自开发者设备130的更新数据和来自操作者设备140的活动数据的通信的结果而发起的。为了更新远程设备100，这两个实体中的每一个提供共同定义将由管理服务器120代表服务请求者管理的更新处理的相应一组数据。操作者设备130是可由更新的资产，比如更新的固件数据的开发者操作或管理的设备。这允许开发固件的开发者的位置与管理服务器120的位置分开。

更新数据可由开发者设备130提供。更新数据提供关于将在远程设备110上更新的资产以及更新该资产的方式的指示。例如，更新数据可包含要被更新的资产的新值，以及为了使远程设备得以获取该新值在远程设备处要满足的标准。在一些例子中，更新数据可包含有效载荷数据和清单数据。

有效载荷数据定义将应用于远程设备的更新的资产的值。例如，在要被更新的资产是设备的固件的情况下，有效载荷数据可定义要安装在一个或多个远程设备110上的固件映像数据。有效载荷数据可定义更新的固件并且可以是固件映像。清单数据描述与有效载荷相关的元数据，比如如何在本地设备处更新有效载荷，或者有效载荷存储在何处。关于可作为清单数据存储的信息的类型的更多细节将在后面说明。例如，清单数据可定义在何处找到有效载荷(例如，有效载荷的URI)、有效载荷数据应用于的设备类型、和在应用有效载荷数据时如何决定是否信任该有效载荷数据。可通过在开发者设备130处运行的清单工具，在开发者设备130上生成清单数据。管理服务器120被配置成从开发者30接收更新数据，并且在一些例子中，被配置成将清单数据发送给远程设备110以转发开发者关于在何处获得映像以及在什么条件下下载和应用映像的指令。术语清单数据和有效载荷数据在这里用来指代数据本身，比如固件映像或完整的清单数据之类。然而，要意识到的是本文中提到的传送清单数据和/或有效载荷数据可改为涉及传送指示接收实体可单独访问所述数据的位置的URI。

操作者设备140可将与特定的一组更新数据关联的活动数据提供给管理服务器120。操作者设备140是可由设备的所有者或负责设备的管理的实体(比如确定哪些设备要被更新和以何种方式更新的实体)操作或管理的设备。更新活动可被视为更新远程设备110的策略，并且由活动数据定义。关于特定更新活动的活动数据被配置成将清单与设备筛选器(filter)耦接。设备筛选器指示通信上耦接到管理服务器120的远程设备110中的哪些远程设备应被更新。这样，设备筛选器识别将被应用于通信上耦接到管理服务器120的所有远程设备，以便选择要应用更新的远程设备110的子集的筛选器。因而，管理服务器120可被配置成使用更新活动的活动数据将清单发送给与设备筛选器匹配的所有设备。在一些实现中，通过将清单与不同的筛选器耦接，清单可以被包括在不止一个更新活动中。这可允许操作者设备140成批地管理远程设备110的更新，其中，按照与该批次关联的设备筛选器，每个更新活动仅针对远程设备的一个子集。

清单格式

如上所述，要被更新的资产的有效载荷数据(例如固件映像)与描述发生更新的方式的清单(例如元数据)是分离的。通过将有效载荷与清单分离，简化了有效载荷的分发。例如，单个有效载荷(例如，固件映像)可被发送给不同的设备。这还允许通过不需要被信任的内容分发网络分发固件映像，因为信任是通过元数据建立的-如后所述。

为了使远程设备应用特定资产的更新，远程设备须确定它收到的更新应该是可信的并且应该被应用。例如，设备可能需要知道更新的作者是否可信、更新是否已损坏、更新是否应用于该设备、更新是否是最新的、应在何时应用更新。

因而，可以从一个或多个字段导出清单，以使设备能够判定是否应用更新。清单的字段形成提供给管理服务器120的清单数据。许多字段可用于生成形成清单的编码。从其导出清单的字段可以包含下述中的一个或多个：

·将对清单签名的私钥及其匹配证书；

·指示使用的签名和加密的类型的数据；

·生成清单的时间戳；

·识别固件的开发者和/或远程设备的制造商的制造商ID；

·识别更新所应用于的设备的类别的设备类别ID；

·例如呈文件和/或到有效载荷的链接(例如作为URL)形式的有效载荷；

·有效载荷类型；

·远程设备110应从其取得有效载荷的URL；

·指示设备应将有效载荷存储在何处的存储标识符；

·安装条件数据，指示应安装有效载荷的条件，比如基于设备上的负载；

·安装时间数据，指示应发生有效载荷的安装的时间窗口，例如通过定义最早时间和最迟时间；和

·指示清单的信任的认证信息，例如包括固件映像的散列和可信开发者的签名。

通过将清单提供给远程设备110，远程设备110可判定是否安装接收的更新。作为该处理的一部分，远程设备110判定更新是否是从管理服务器120接收的有效更新。图1的系统可实现安全特征，从而确保恶意的第三者无法与远程设备110通信以迫使远程设备110安装未经授权的资产，比如含有安全缺陷的未经授权的固件。

数据的核实

为了保护清单的安全，管理服务器120和开发者设备130被配置成利用加密方法，比如公钥加密之类。

在例子中，每个远程设备110和开发者设备130被配置成利用椭圆曲线加密(ECC)，一种公钥加密(可改为使用其他公钥加密技术)。在例子中，在开发者设备130和远程设备110上运行的清单工具使用椭圆曲线数字签名算法。该算法使用两项信息：即，称为私钥的秘密，和与该秘密对应的称为公钥的数字。

为了对清单签名，私钥的持有者(开发者设备130)首先利用SHA256计算清单的散列，随后利用私钥转换该散列。称为签名的该新数字被附加到清单中。随后，拥有公钥的任何实体(比如每个远程设备110)可通过：利用SHA256计算文档的散列、利用公钥将签名转换回散列、并比较计算的散列和签名散列，来核实签名与文档匹配。

如果散列相同，那么核实者可以确信签名者拥有私钥。这是因为即使已有利用私钥进行转换的许多例子，从公钥确定私钥也是一个计算上困难的问题。

公钥通常封装在证书内，证书包含关于公钥及其所属方的附加信息。该证书也被签名，或者由另一个机构(证书授权机构)签名，或者由其本身签名(自签名证书)。证书通常由指纹来识别，所述指纹诸如证书的散列(例如，证书的SHA256散列)之类。

远程设备可使用ECC曲线ecc-secp256r1，一种NIST推荐的曲线。代替RSA，可以在远程设备上使用ECC，因为ECC减小了密钥大小并且在计算能力有限的平台上具有更高的性能。

真实性对于可以修改设备的行为的任何操作，尤其是固件更新来说是至关重要的。验证固件更新的真实性有助于保持暴露在互联网上的设备(比如远程设备110)按其设计者的意图工作；验证失败可能会导致设备受损或者破坏。

签名为固件提供完整性和真实性验证。无论权限如何，如果提供的签名与固件匹配，那么远程设备110可以确信签名用私钥的持有者已经批准了该固件。这防止了在向设备发送固件时冒充他人，或者在传送中修改固件。

通过信任匹配的证书，设备可在不知道私钥的情况下决定信任哪些私钥。如果私钥受到充分保护，那么这保证设备只安装可靠的固件。

在开发者设备130处利用私钥对清单签名，从而创建签名。远程设备110利用核验证书核实清单的签名。只有在签名是利用与核验证书相同的私钥创建的(意味创建签名之人可以访问该私钥)的情况下，清单才具有有效签名。如果签名匹配，那么清单被授权。远程设备将拒绝签名不正确的清单。

清单还可包含有效载荷(例如，固件映像)的散列(比如SHA256散列)。由于清单被签名，因此这确保无论下载方法如何，清单都只能用于安装预期映像的完整且未被更改的副本。

更新活动管理

如上所述，操作者设备140可被配置成将更新活动的活动数据传送给管理服务器，活动数据包含指示哪些远程设备110将受到资产更新的影响的设备筛选器。随后，当更新活动被上传到管理服务器120时，可以开始和监视该活动。

结合图2说明发起更新活动的例证处理。图2的处理200始于步骤210，在步骤210，开发者生成有效载荷，例如以固件映像的形式。该步骤可以在开发者设备130处发生或者可以在分开的设备处发生，有效载荷数据从所述分开的设备被传递给开发者设备130。在一些布置中，在该步骤只构建固件，而引导装载程序未改变。在一些布置中，在新的应用中，可以维持原始应用的存储器布局。

在步骤220，有效载荷数据(例如，固件映像)从开发者设备130传送给管理服务器120，并存储在管理服务器或者存储在另外的远程设备(图1中未图示)处。在一些布置中，有效载荷数据可以存储在由开发者设备130(例如在一个或多个清单中)定义的用户资源定位符(URL)处，使得远程设备可以从已知位置访问有效载荷。在一些布置中，如前所述，管理服务器120可允许对管理服务器的上传由API(应用编程接口)进行。在一些布置中，管理服务器可允许通过门户和通过API网关上传有效载荷。在这样的布置中，管理服务器120可向开发者设备130返回指示有效载荷的存储位置的URL。该返回的URL随后可在清单中使用。在一些布置中，有效载荷可被加密。

在步骤230，生成定义应处理远程设备110的资产(例如固件)的更新的方式的清单数据。清单可以在开发者设备130处生成和/或可以在外部生成并传递给开发者设备130，以便传送给管理服务器120。清单可在开发者设备130(或其他设备)上运行的清单工具生成。如前所述，清单可包含定义应进行远程设备的更新的方式的一个或多个字段，如上所述。另外，清单可包含清单签名——例如利用公钥加密技术生成的清单签名。清单还可包含在步骤210和220创建和传送的有效载荷的散列。

在步骤240，清单可以从开发者设备130传送到管理服务器120。要意识到的清单和有效载荷的生成和传送可以同时发生。换句话说，步骤210和230可以合并，并且步骤220和240可以合并。

清单可以利用清单工具以多种方式之一来生成。例如，清单工具可解析包含用于创建清单的信息的输入文件(比如JSON输入文件之类)。在输入文件中缺失信息的情况下，清单工具可以检查包含输入文件中缺失的字段的默认值的默认文件。或者，清单工具可以通过接收定义要插入到生成的清单中的字段的命令行参数来生成清单。

在一些布置中，具有未加密的有效载荷的清单至少可包含(i)要使用的加密模式(比如none-ecc-secp256r1-sha256之类)，(ii)有效载荷URI(统一资源标识符)，(iii)将用于对清单签名的证书的URI或者将用于对清单签名的本地文件中的一个，(iv)作为证书的签名密钥的本地文件，和(v)供应商ID和设备类别ID，或者设备ID中的一个(以识别清单适用于的设备)。

按照这种模式，清单工具创建已签名的清单；有效载荷未加密。(一个或多个)目标远程设备110已具有提供的证书，或者提供取得证书的方式。创建清单的例证方法将在后面说明。

在步骤240，生成的清单可以用与步骤220的有效载荷类似的方式，例如通过API和/或通过门户被上传到管理服务器。

在步骤250，在操作者设备140处创建设备筛选器。设备筛选器指示要更新的多个远程设备110。当被处理时，设备筛选器防止不被允许更新的远程设备110被更新。设备筛选器的格式将被更详细地说明。

在步骤260，通过定义更新活动的活动数据，在操作者设备140处创建更新活动。如前所述，更新活动定义更新远程设备的资产的方法，并且可被视为向一个或多个预先确定的远程设备呈现诸如固件之类的资产更新的构成体(construct)。一般地，活动可包含从开发者设备130定义的至少一个清单以及在操作者设备140处定义的设备筛选器或者与所述至少一个清单以及所述设备筛选器关联。因而，更新活动集体定义要应用的资产更新、应用资产更新的方式、以及将以定义的方式应用资产更新的设备。

因而，活动数据可被视为向一个或多个设备通告清单的处理的定义。这可以通过经托管在管理服务器120上的连接服务写入到适当远程设备110上的清单资源来实现。如果特定的远程设备不是立即可达的，那么该远程设备可能错过该通告，并因此错过更新。这可以通过利用相同或不同的设备筛选器对这些设备开始第二次不同的活动来缓解。已被更新的设备将忽略第二次活动，因为它未在设备筛选器中列出，或者因为它已具有最新的固件版本。要应用资产更新的设备的列表可从设备目录导出，所述设备目录可以是已注册设备的全局寄存器。选择设备的子集的机制是设备筛选器。尽管清单可以用与之兼容的设备的类别和/或供应商预先设定筛选器，不过部署可能需要额外的设备针对性信息。

例如，代替或者除了类别或供应商ID以外，可能可以利用其他字段来按照活动筛选被通告的设备。例如，可能存在指示设备的物理位置、设备的型号的字段，或者其他这样的字段。下面举例说明例证的筛选器，该筛选器将向在特定建筑物的特定楼层内的具有特定型号的许多设备通告更新：

型号＝‘AIRCONv3-revB’、客户＝‘ARM’、城市＝‘CAMBRIDGE’、建筑物＝‘CPC1’、楼层＝‘2’

在一些例子中，操作者设备140可访问API，以连接到管理服务器120，这可允许进行以下行动以管理活动和设备筛选器：

·查看所有目前连接的远程设备的列表；

·创建并存储筛选器，以使列表更加可导航；

·查看和编辑设备详情；

·向设备添加定制属性；

·查看连接设备的资源值；

·创建、管理和使用设备筛选器；

·添加定制属性；

·访问设备事件日志；

·删除设备；和

·撤销并生成新的证书或密钥。

为了说明远程设备筛选器的生成，提供关于远程设备的生命周期的一些细节也是有用的。在远程设备的制造期间，设备可被提供：向管理服务器提供访问凭证的设备证书；和应用代码，连同引导装载程序。

随着设备经过引导(bootstrap)处理以是该设备登记了由管理服务器提供的管理服务，设备的状态变化。一旦制造完成，远程设备就以“未登记”状态启动。一旦登记完成，远程设备就进入"注册状态"。如果登记过程中发生错误，设备无法进入注册状态。可通过管理服务器访问设备状态。

管理服务器可以使用以下字段中的一个或多个字段来配置:

·识别设备的设备ID；

·设备名；

·设备描述；

·状态；

·创建日期：远程设备可供更新的日期和时间；

·引导日期：远程设备被引导的日期和时间；

·序列号，它是只读的，并且可以从设备的固件填充；

·供应商ID：远程设备的供应商ID，它是只读的，并且可以从设备的固件填充；

·远程设备类别：远程设备的类型ID，它是只读的，并且可以从设备的固件填充；

·工厂名称；和

·基于位置的属性，比如建筑物和楼层编号之类。

其中状态可以采取下述值之一：

·未登记：当设备被添加到管理服务器时的初始状态；

·云登记：远程设备已被添加到服务的各个部分且已开始引导；

·已引导：远程设备现在已引导，并且具有由管理服务器提供的管理服务的身份，但是还不可供更新；

·已注册：远程设备已注册，并且可供更新；和

·取消注册：由于取消注册或者由于注册过期，远程设备不再注册。

归因于该领域中的大量设备，在大规模的云部署中管理设备可能是非常困难的。通过维护字段的列表，可以提供使设备的选择和管理成为可能的复杂且精细的筛选器。这些字段可以用来生成这类复杂的筛选器，所述筛选器可用于与设备的子集交互或者监视设备的子集。例如，可以通过上述属性的任意组合来筛选设备。另外，管理服务器允许操作者设备140添加定制属性。

更新活动在步骤270处开始或部署，并且更新处理开始。部署向在设备筛选器中定义的设备的列表通知指定的清单。通过操作者设备140向管理服务器传送“开始”命令，可以触发在步骤270处的活动的开始。例如，这可以利用API或者通过门户来进行。随后开始向设备通告清单的处理。

在步骤280，通过从管理服务器120接收或检索进度或状态信息，可在操作者设备140处监视更新活动的进度。在部署期间，通告消息被发送给在设备列表中定义的一组设备。然而，如上所述，部署可能不会导致所述一组设备中的每一个都被更新。例如，设备可能看到通告或者可能未看到通告，设备可能由于各种原因而忽略通告(比如设备电力低或处于临界状态)，或者设备可以从其他部署或者通过其他手段接收通告。

因此，本文中描述的更新机制提供一种监视设备而不是活动的机制。为方便起见，活动可由它们所针对的设备筛选。

清单创建

图3图解说明可进行步骤230的例证方法。在步骤310，在操作者设备140处运行的清单工具取得存储在管理服务器120处的有效载荷并对所述有效载荷求散列。有效载荷加载自本地文件(如果可用的话)，否则加载自提供的URI。在步骤320，所述工具(或者从提供的URI或者从本地文件)取得证书并提取证书的指纹。在步骤330，该工具创建清单的内部部分。清单的内部部分可包含元数据中的一个或多个元素，比如：

·提供的ID；

·有效载荷存储在的URI；

·有效载荷大小；和

·有效载荷散列。

在该方法的步骤330，散列清单的内部部分被求散列，并且随后在步骤340处利用该散列和证书私钥签名。在步骤360，将内部部分、散列、签名、证书指纹和证书URI包在清单的外部部分中。

在一些布置中，可以利用加密模式(例如，none-ecc-secp256r1-sha256)创建清单。为了利用加密模式创建清单，提供额外的信息。

例如，可以提供以下信息：

·要使用的散列、签名和加密的类型(如果没有，那么根据强制输入项计算)；

·供应商ID(如果没有，那么从默认值提取)；

·类别ID(如果没有，那么从默认值提取)；

·有效载荷文件(可在命令行中被重写)；

·描述(默认为空)；和

·用于签名的证书(如果没有，那么从默认值提取)。

下面列出的是例证清单，其中所有字段都是通过输入文件提供的：

如前所述，存在可将数据提供给清单工具的许多不同的方式。清单工具可以解析JSON输入文件，JSON输入文件可包含用于创建清单的所有信息。在输入文件中缺失信息的情况下，清单工具可以检查当前工作目录中包含默认值的文件。另一种方式是通过命令行参数提供数据；清单工具使用的许多字段可在命令行被覆盖。

清单可以在不加密的情况下使用SHA256用于散列，基于secp256r1曲线的ECDSA签名。这种加密模式在清单工具中可被称为none-ecc-secp256r1-sha256。

为了创建具有未加密的有效载荷的清单，可以使用以下字段：

·要使用的加密模式(比如none-ecc-secp256r1-sha256之类)；

有效载荷URI；

·将用于对清单签名的证书的URI或者作为将用于对清单签名的证书的本地文件；

·作为证书的签名密钥的本地文件；和

·供应商ID和设备类别ID，或者设备ID。

可存储在清单中的其他有效载荷信息可包括：

·清单版本——使用的清单格式的版本。

·描述——更新的自由文本描述。

·供应商Id——RFC4122 UUID，识别模块化系统中的目标设备或软件模块的供应商。如果提供的话，那么目标可匹配该标识符。

·类别Id——RFC4122 UUID，识别设备或软件模块的种类、型号或版本。如果提供的话，那么目标可匹配该标识符。

·设备Id——RFC4122 UUID，唯一地识别目标设备。如果提供的话，那么目标可匹配该标识符。

·时间戳——清单的创建时间戳。这可用于提供回滚保护。只有给定树的根清单才将此字段用于回滚保护。

·该值增大，并且设备不能安装版本比其当前版本更旧或与当前版本相同的有效载荷。

·如果为了稳定性起见，需要回滚到旧的有效载荷版本，那么将为旧的有效载荷创建新的更新清单。

·nonce——128位的随机字段。它由清单工具提供，以确保应对定时侧信道攻击签名算法是安全的。

·供应商信息——特定于供应商的信息，它可使终端设备不应用该更新。这用于特定于有限情况的扩展(例如，门供应商可能具有“除非您目前被锁，否则不要应用此更新”的标志)。

·立即应用——该标志指示应尽快应用清单所描述的更新。如果未设定，那么不应用该更新，除非正在应用的另一个清单依赖该更新。

·有效起点和有效终点——其间应用该更新是可以接受的时间。在这些时间之外，不应用该清单。

·依赖性——引用其他清单(其他数据类型是错误)。该清单描述的更新连同列表中的所有被引用清单一起自动应用。

·有效载荷——描述要应用的实际有效载荷。子性质见下文：

·别名(alias)——允许清单提供获得在另一个清单中引用的有效载荷的备选位置

·加密模式——它描述用于对有效载荷加密的加密配置

·初始化向量——AES引擎的初始化向量。大小由加密模式决定。如果指定AES加密，那么该字段是强制性的。

安全机制

更新的真实性是可以证明的，并且具有在设备的生命周期内保持安全的足够水平的熵值(例如，对于15年以上的生命周期，至少128位的安全性)。一般，这意味更新被签名。其他证明机制是可以接受的，比如MAC或零知识证明之类。由于清单包含关于如何安装更新的信息，因此清单的真实性是可以证明的。为了减少验证所需的开销，清单包含有效载荷的摘要，而不是其他签名。这不改变有效载荷的可证明性。清单的真实性可以用签名来证明，有效载荷摘要的真实性可以用清单来证明，有效载荷的真实性可以用有效载荷摘要来证明。

在一些布置中，清单由授权的更新作者签名。更新作者是组装更新映像的行动者。可不使用中间签名者。在这样的布置中，目标设备具有公钥，目标设备使用所述公钥认证以安全且不可撤销的方式提供的更新。设备不接受新密钥，除非它们是利用旧密钥签名的。设备应保留该审计追踪。

设备定期使作者公钥到期，并在作者变得不可信时，撤销作者公钥。这可以通过证书到期和证书撤销来实现。服务器可以使用类似于OCSP装订的机制来简化针对设备的清单签名证明撤销检查。管理服务器120可被配置成代表远程设备110取得证书，并将在核实有效性中涉及的证书的个体撤销状态附加到清单中。

更新作者可以使用HSM进行签名。在签名之前和之后，可以比较清单的内容。所述比较可以在与签名不同的机器上进行。对于大型部署，可在具有HSM的气隙计算机(air-gapped computer)上核实清单。

对于大型部署，更新作者可使用运行安全编译器的气隙构建(build)机。可选地，编译器可由供应商签名。对于大型部署，编译器本身可以对所有构建输出进行签名。作为结果的二进制的摘要应与清单中的摘要比较。在将清单发给目标设备之前，更新作者可核实从云服务检索的清单的内容。清单可包含有效载荷的摘要。

清单可包含全局、单调递增的序列号。即使在许多地点存在许多授权的固件作者，在清单中提供的序列号也可以是单调递增的。

清单及其内容是以非规范形式存储或传送的。如果这种机制在技术上是必要的，例如数据库，那么清单被传送给非规范数据的接收方并由其核实。有效载荷加密密钥的保护。设备供应商可进行风险分析，并选择他们期望的有效载荷安全等级。

加密的有效载荷可以各种安全级别出现：

·0类有效载荷：未加密。已知这种有效载荷是可公开访问的。

·1类有效载荷：利用永久预共享密钥加密，可选地可利用密钥导出函数。因有效载荷内容暴露而带来的风险低。一个密钥的泄漏会泄漏所有未来的有效载荷。

·2类有效载荷：为每个设备配置独立的预共享密钥，可选地利用密钥导出函数。对任意个体设备的有效载荷传递都可被撤销。

·3类有效载荷：设备使用基于公钥的密钥协商，确保每个设备接收使用设备特有的密钥加密的相同的有效载荷解密密钥。为每个部署创建用于密钥分发的私钥。对任意个体设备的有效载荷传递都可被撤销。

·4类有效载荷：每个设备通过独立的安全通道接收个体商定的随机数，随后在基于公钥的密钥协商中使用该随机数。该设备随后利用该密钥解密有效载荷加密密钥。这构成前向保密。

·5类有效载荷：每个设备通过独立的安全通道接收个体商定的随机数，随后在基于公钥的密钥协商中使用该随机数。有效载荷是利用该密钥加密的。这不是广播友好的。

设备供应商选择这些有效载荷安全类中最适合其风险简档(risk profile)的有效载荷安全类，同时平衡对称密钥(预共享、低能量、但难以保护)、非对称密钥(不共享、高能量、更容易保护)、能量简档(energy profile)等的使用。当使用加密的有效载荷时，清单可包括有效载荷加密密钥的摘要。片外存储的任意固件更新可以用唯一的、每个设备的加密密钥签名。片外存储的任意固件更新可以用唯一的、每个设备的加密密钥加密。设备可以用唯一的、每个设备的加密密钥加密任何片外数据，以防止提取。通过熔断适当的调试保护熔丝(protection fuse)，设备可以禁用任何SWD/JTAG读出设施。在设备支持安全调试器的情况下，这不需要被禁用。设备可对照清单时间戳来检查证书到期时间。如果清单的时间戳晚于用于对清单签名的证书的到期时间，那么清单不能被接受。如果清单的安装时间晚于用于对清单签名的证书的到期时间，那么清单不能被接受。设备可基于安全起源，利用逻辑时钟安全地强制执行时间。无论是否存在RTC，这都适用，因为RTC也可能受到攻击。

清单可通过安全、经认证的通道传递给设备。有效载荷可通过安全、经认证的通道传递。不通过安全、经认证的通道递送清单、有效载荷的风险是经由通过该要求而缓解的威胁的拒绝服务的增大的风险。每个设备可具有唯一的可以密码方式证明的身份。该身份可由通信伙伴，比如服务器、对等设备或用户的应用核实。目标设备可以实现适合于其应用空间的速率限制。快速发送许多清单可能是不可能的，因为这可能导致设备使用大量的能量和/或闪存周期(flash cycle)。

状态报告应通过可信的、专用通信介质路由，这防止攻击者检查设备发送的分组并选择要拦截哪些分组。

所有关于有效载荷的描述性信息都可被签名。这可包括：

·有效载荷位置

·有效载荷摘要

·有效载荷大小

·有效载荷类型

·用于应用有效载荷的所有指令或参数

·识别有效载荷是否可在该设备上使用的任何规则

在具有不止一个存储位置的系统中，可以通过访问控制列表(ACL)来识别更新作者。这些ACL识别允许更新作者在设备上做什么。对于要安装的更新，它可能需要满足目标存储位置的所需权限。所述权限由更新作者的签名授予。所有收到清单的行动者在处理清单的内容之前，都要验证清单的真实性。

信任锚可被视为制造时安装在设备上的、针对特定任务设备完全信任的公钥。信任锚不应被替换、撤销或失效。信任委托可被视为由信任锚或者信任委托签名的公钥。最终，每个委托链都止于信任锚。信任委托可随时被替换、撤销或失效。

可以应用于在本文中描述的系统的安全模型是利用上面讨论的安全要求构建的。

1.信任

i.在制造时，每个设备都安全地配备有它信任用于进行更新的一个或多个公钥。这些公钥被称为信任锚。每个更新都可以用信任锚或者信任委托核实。信任委托是已用信任锚的私钥签名的公钥。

ii.信任委托可以进一步委托。

iii.信任的委托可提供一种限制信任委托的权限的机制。

iv.信任委托可具有到期日期。

v.只有信任锚，或者靠近信任锚的信任委托才可以撤销信任委托。

vi.如果信任锚或信任委托是片外存储的，那么它被加密和签名。

2.清单

i.称为清单的元数据块用于描述更新。

ii.清单由更新作者签名。云签名可被禁止。

iii.可以在更新作者的计算机或更新作者的HSM上对清单进行签名。更新作者比较清单的签名前内容和签名后内容。

iv.可以利用行业标准容器格式CMS(也已知为PKCS-7或RFC5652)对清单进行签名。

v.通过利用CMS(PKCS-7/RFC5652)，可以通过标准PKCS-11兼容的HSM或智能卡对清单进行签名。这也可在气隙HSM上完成。

vi.可以由一个或多个信任锚或信任委托对清单进行签名。

vii.清单因此可包含：

a.有效载荷的强度可至少为SHA-256的摘要；

b.UTC时间戳，以秒为单位；

c.有效载荷位置；

d.有效载荷摘要；

e.有效载荷大小；

f.有效载荷类型；

g.用于应用有效载荷的所有指令或参数；

h.识别有效载荷是否可在该设备上使用的任何规则；和

i.如果有效载荷被加密，那么清单包含有效载荷密钥的摘要。

3.有效载荷

i.有效载荷可以利用多个模型来加密。当被加密时，清单包含设备解密有效载荷所需的信息，但不包含可供任何其他方解密有效载荷的足够信息。

ii.一旦下载，有效载荷由更新客户端签名，并被存储在：

a.在片上；或者

b.片外，用至少128位的安全性加密(例如，用AES-128或更好的)和/或签名。

4.服务

i.更新作者可把更新证书上传到他们的服务账户，以允许清单签名的服务侧验证。

ii.当收到清单时，更新服务：

a.验证清单的签名。如果没有对应的证书可用，那么更新服务报告错误。

b.验证所有通用清单字段。注意，一些字段在没有只有设备可以得到的知识的情况下是无法核实的。

iii.更新作者可以选择性退出清单的服务侧验证，不过这可能不是默认立场。

iv.在批准将更新部署到设备之前，设备管理者可以检查清单的人类可读部分。这可以在不添加签名的情况下完成。

v.更新服务确保呈现给用户的数据是正确的。

a.用户将用于验证清单的公钥上传到更新服务。

b.当接收到清单时，更新服务验证清单的签名。

c.当响应于搜索提取清单时，更新服务验证清单的签名，随后比较清单内容和搜索项。

d.更新服务通过任意API传递规范的清单。

e.SDK和web门户两者都在本地验证清单签名，随后将清单解析成所需的数据格式。

f.SDK和web门户两者都提供显示本地解析的清单的内容以供用户检查的“最终检查”机制。对照以前显示给用户的任何其他字段比较这些内容，并突出显示任何差异。

vi.更新服务通过TLS或DTLS把清单递送给目标设备。

vii.更新服务只通过TLS或DTLS接受状态报告。

viii.更新服务采取适当步骤，以确保它只允许现代TLS/DTLS连接。

ix.更新服务确保只有独特(unique)的设备连接到服务。

x.更新服务以密码方式核实各个设备的身份。

5.设备

i.设备具有唯一的私钥。

ii.在接收到每个清单之后，不管更新是否成功，设备都进入冷静期，在冷静期，设备将拒绝所有具有“速率限制(Rate Limit)”错误的清单。

iii.当设备接收到清单时，该设备：

a.核实清单签名。

b.检查清单的时间戳不晚于证书的到期时间。

c.检查清单的安装时间不晚于证书的到期时间。

d.核实所有清单字段

清单上传

图4图解说明创建清单并将清单上传给管理服务器120的例证工作流。从图4可以看出，存在许多在本例中例示的不同元件。如前所述，管理服务器120被配置成提供资产更新服务，资产更新服务包含例如以固件映像的形式存储和维护固件有效载荷的服务。如图4中所示，该服务可以在固件编目服务中处理。此外，在清单存储装置中提供清单数据的存储。管理服务器120直接把清单存储在清单存储装置中，或者远程管理清单存储装置中的清单的存储。管理服务器120还提供API网关和门户，通过所述API网关和门户，可以从开发者设备上传清单，开发者设备可被配置成操作更新工具和签名工具，所述更新工具被配置成处理清单的创建，所述签名工具被配置成在清单被上传给管理服务器120之前对清单签名。

图4的工作流始于步骤401，在步骤401，在开发者设备处创建生成清单的请求，并将其传递给更新工具。在步骤402，创建清单并将其传递给开发者设备。在步骤403，未签名的清单被传递给签名工具，此外在步骤404，签名密钥被传递给签名工具。利用签名密钥对清单签名，并在步骤405将其返回给开发者设备。在步骤406，开发者设备请求将已签名的固件清单上传到管理服务器120。该请求是在步骤406通过门户并且在步骤407通过API网关做出的。在步骤408，上传已签名的清单的请求被传递给固件编目，在步骤409，固件编目检查清单的大小是否超过预先确定的限制，并解析清单字段。在步骤410，清单被传送给清单存储装置，以便存储。在步骤411-416，通过各个元件返回确认消息，以确认清单已被成功存储在清单存储装置中。

有效载荷上传

图5图解说明创建待更新的资产的有效载荷，并将其上传到管理服务器120的例证工作流500。

从图5可以看出，该工作流中存在许多元件。在本例中，管理服务器120也被配置成例如以固件映像的形式，存储和维护资产有效载荷的服务。如图5中所示，该服务可以在固件编目服务中处理。此外，管理服务器120直接把固件有效载荷存储在固件存储装置中，或者远程管理固件存储装置中的固件有效载荷的存储。管理服务器120还提供通过其可上传固件映像的API网关和门户。另外，开发者设备还可以访问可用于构建固件映像的构建工具。

该工作流流始于步骤501，在步骤501，构建固件映像的请求从开发者设备传送给构建工具。在步骤502，构建工具将编译的映像返回给开发者设备。在步骤503，上传固件的请求在步骤503经门户并且在步骤504经API网关，在步骤505被传递给管理服务器120中的固件编目服务。在步骤506，固件映像被存储在固件存储器中。在步骤507、508、509和510，向开发者设备返回确认固件已被存储的确认消息。

活动创建

图6图解说明创建活动并将活动提供给管理服务器120的例证工作流600。从图6可以看出，该工作流中存在许多元件。在本例中，管理服务器102使得能够提供更新服务。该更新服务可被视为是作为管理服务器120内的软件模块实现的。为了举例说明工作流，软件模块可被分离许多子模块或子服务。在本例中，门户是由管理服务器120提供的web门户，门户提供接口，操作者设备140可通过该接口与管理服务器120交互或接口连接。

还提供API网关，通过API网关，通信被传递到管理服务器120的子服务中。在图6的例子中，存在许多由管理服务器120操作的不同子服务。实际上，可在更高的抽象层考虑管理服务器120的操作，使得它是单一服务。然而，为了示出数据的工作流，在本例中，示出了3个子服务——即，管理接收的固件有效载荷的存储和维护的固件编目服务，管理设备筛选器的维护和存储的设备编目服务，和管理创建的活动的部署的部署服务。

图6的工作流始于步骤601，在步骤601，操作者设备请求新活动的创建。在步骤602，响应创建新活动的请求，通过门户向API网关发出关于可通过固件编目服务访问的可用清单的列表的请求。在步骤603，API网关将获得可用清单的列表的请求转发给部署服务。在步骤604，指示可用清单的列表的清单列表从固件编目服务传送给API网关。清单列表在步骤605从API传送，并通过门户呈现给操作者设备。在步骤606，设备操作者从可用清单的列表中选择要与活动关联的特定清单，并开始基于所选清单生成活动的处理。

在步骤607，从云门户向API网关传送创建活动消息，所述创建活动消息包含要与所选清单关联的清单的指示。在步骤608，API网关将创建活动消息转发给部署服务，部署服务记录与所选清单关联的活动的创建。在步骤609和610，传送在部署服务已创建该活动的确认消息。

在步骤611，门户向API网关发出关于有效设备筛选器的列表的请求。例如，有效筛选器可以从指定在所选清单中列出的设备制造商和型号的筛选器中选择。附加地或替代地，清单中的其他字段可用于基于清单来识别要使用的有效设备筛选器的列表。在步骤612，关于有效列表的请求从API网关传送给设备编目服务。设备编目确定在设备编目服务可用的筛选器中的哪些筛选器有效，并在步骤613将有效列表返回给API网关，所述有效列表随后在步骤614被转发给门户。在步骤615，从有效设备筛选器的列表中选择要使用的设备筛选器，并提供给门户。在步骤616和617，门户通过API网关将活动更新消息传送给部署服务。活动更新消息指示要使用的设备筛选器。一旦在部署服务收到活动更新消息，就在部署服务更新活动。在步骤618和619，向门户返回并向操作者设备呈现确认更新已经发生的确认消息。

在步骤620，通过在web门户输入数据，操作者设备发起更新活动的启动。例如，这可以采取开始活动消息或者与用户接口的交互的形式。在步骤621和622，开始活动消息从web门户经API网关被传送给部署服务。如果有带宽的话，那么部署服务可立即发起更新活动。或者，如果其他活动目前正在进行中，那么可使部署服务排队，以便一旦资源可用就进行处理。在步骤623、624和625，向操作者设备返回已发起更新活动的确认。通过提供这种方法，设备操作者不需要为了生成活动而接收有效载荷的副本。

在一些布置中，创建的活动数据可以在上传到管理服务器120之前被签名。在这样的方法中，要被更新的远程设备110可能需要签名的活动数据以便认证活动数据，并接受活动数据。活动数据可以利用公钥加密签名或者密钥散列消息认证码(HMAC)进行签名。活动数据的签名实现活动数据的端到端安全性，这可防止恶意篡改。

远程设备110可被配置成采取行动来解决接收的活动数据和接收的清单数据之间的任何冲突。例如，远程设备可能接收指示属于特定制造商的设备要被更新的清单数据，不过可能接收允许另外的制造商的活动数据(例如，活动数据可能对有效清单数据进行例外处理)。远程设备110可自动调和冲突，比如通过基于预先确定的规则，自动遵从活动数据和清单数据之一。或者，远程设备110可以将必须通过用户干预来解决的冲突通知管理服务器120。

活动处理

图7图解说明结合图6讨论的用于通过响应开始活动的请求处理活动数据，发起更新活动的管理服务器120内的例证流程700。如前所述，图7的例子图解说明由管理服务器120提供的许多不同的子服务。在一些实现中，管理服务器120可以作为单一服务而操作。然而，为了进行示意，将关于子服务方法示出活动的处理。

图7的工作流始于步骤701，在步骤701，部署服务检索关于要处理的下一个排队活动的信息。基于检索的活动信息，在步骤702，部署服务基于活动数据的设备筛选器来进行将对其应用更新活动的设备的筛选，并从设备编目服务检索要对其应用更新的设备的列表。

在步骤703，为设备创建活动元数据条目，并且在步骤704，部署服务将数据提供给设备编目服务，使得在步骤705，可以更新远程设备的设备日志，以反映更新后的资产数据到远程设备的部署。

在步骤706，从部署服务向固件编目发送对清单数据的请求，然后在步骤707，固件编目返回清单的副本。在步骤708，更新的清单数据被发送给连接器通道服务，连接器通道服务按照设备筛选器，将清单数据传送给一个或多个远程设备。基于通信的成功与否，设备要么确认通信的收到，要么不确认通信的收到。更新的结果状态在步骤710被返回给部署服务，在步骤711，部署服务更新与远程设备关联的元数据。

活动监视

图8图解说明监视活动的进度的例证工作流。与上述附图一样，本例中的管理服务器包含多个子服务，包括设备编目服务、连接器通道服务和部署服务。此外，操作者设备能够通过门户和API网关与管理服务器120通信。

工作流800始于步骤801，在步骤801，向连接器通道服务通知设备的资源的变化。例如，这可利用HTTP回调来进行。在步骤802，连接器通道服务将资源变化通知给设备编目服务。在步骤803，设备编目服务创建与资源变化相关的设备日志条目。在步骤804，如果所有设备都已到达目标版本，那么连接器通道服务通知部署服务，此时活动可被标记为完成。

在任意时刻，在步骤805，操作者设备通过门户发起监视活动的指令。在步骤806和807，门户请求活动的设备日志条目，在步骤807，从设备编目服务检索所述设备日志条目，并且在步骤808，将所述设备日志条目返回给API网关。日志随后可被提供给操作者设备，以便按照更新活动向操作者设备显示远程设备的资产更新的状态。

多个服务请求者

图9图解说明包括管理服务器120、开发者130、设备操作者140和多个远程设备110的计算系统900。这些要素对应于图1中的类似要素。

在图9的布置中，远程设备110、开发者设备130和设备操作者140或者全部被链接，因为它们都与第一服务请求者相关。服务请求者可被视为对允许的远程设备具有公共访问级别的关联组织或用户。例如，开发者130为构成第一服务请求者所请求的第一服务的一部分的远程设备110开发固件。因而，第一服务请求者的设备操作者140可以访问由第一服务请求者的开发者130生成的有效载荷和清单。

管理服务器120可被配置成并行管理多个更新服务，每个更新服务由独立的服务请求者所请求。例如，在图9的布置中，并行地请求3个更新服务。第一更新服务由呈开发者130、设备操作者140和远程设备110形式的第一服务请求者请求(第一服务由背景透明的设备例示)。第二更新服务由呈开发者设备131、操作者设备141和远程设备111形式的第二服务请求者请求(由带浅色斑点的背景例示)。第三更新服务由呈开发者设备132、操作者142和远程设备112的第三服务请求者请求(由带深色斑点的背景例示)。

对于特定服务请求者，该服务的设备操作者可以具有对从该服务提供者的开发者设备提供给管理服务器120的有效载荷数据和清单数据的访问权。然而，特定服务请求者不一定具有对另一个服务请求者的有效载荷数据和清单数据的访问权。类似地，通信上耦接到管理服务器的远程设备的子集一般与特定服务请求者关联。因此，可以使用与该相同服务请求者关联的活动来引用和更新这些远程设备。然而，除非服务请求者明确允许，否则服务请求者将无法访问或更新不属于该服务请求者的远程设备。

在图9的例子中，第一服务请求者可以使用设备操作者140和开发者设备130来控制远程设备110中的至少一些的更新。然而，第一服务请求者可能被阻止更新设备111和112，因为这些设备要由第二和第三服务请求者更新。通过提供这种能力，单个管理服务器能够利用相同的接口来操作来自不同方的多个更新活动。这产生一种安全地更新可应用于在不同物理位置的大量设备的固件的统一且标准化的方法。

技术人员会意识到，系统的各个元件之间的通信可以利用有线连接或无线连接来进行。例如，记载在本文中的机制可以按不知道更新方法以及不知道设备与服务器之间通信方法的方式执行。例如，记载在本文中的机制是通过USB大容量存储装置(CMSIS-DAP)、服务器API、UART、ZigBee、BLE、以太网(TFTP+DHCP)和WIFI对更新的应用由相同的格式所覆盖。此外，设备和服务器之间的通信可以通过任何有线或无线通信进行。各个设备之间的通信可以是直接的或者间接的，从而可以通过一个或多个网关进行，并且可以通过一种或多种不同的通信协议或物理传送介质进行，前提是建立了设备之间的通信信道。

还要意识到的是，本文中对设备或服务器的引用不应被解释成局限于单个硬件元件。记载在本文中的技术适用于云计算技术，其中单个设备或服务器的操作，或者单个服务的提供可分布在一个或多个物理设备或服务器之间。因而，本文中对服务器的引用应包括对被通信耦接以便提供所述单个被引用服务器的功能的多个服务器的引用。

在一个特定方面，本技术提供一种在多个远程设备上为一个或多个服务请求者管理资产更新服务的方法，所述方法包括：在管理服务器处，接收指示要在一个或多个远程设备处更新的资产的更新数据；在管理服务器处接收活动数据，所述活动数据与所述更新数据关联并且指示更新要被应用于的远程设备的子集；和在管理服务器处，接收通过向远程设备的所述子集传送更新通信来发起资产更新的请求，所述更新通信指示为了更新远程设备的资产而要检索的资产。

在另一个特定方面，本技术提供一种在多个远程设备上为一个或多个服务请求者管理资产更新服务的管理服务器，所述管理服务器包括：至少一个接口，用于：在管理服务器处，接收指示要在一个或多个远程设备上更新的资产的更新数据；在管理服务器处接收活动数据，所述活动数据与所述更新数据关联并且指示更新要被应用于的远程设备的子集；和在管理服务器处，接收通过向远程设备的所述子集传送更新通信来发起资产更新的请求，所述更新通信指示为了更新远程设备的资产而要检索的资产。

本文中描述的方法可以用硬件或软件或硬件和软件的任意组合实现。例如，本文中描述的方法可被实现成包含计算机可读指令的计算机可读代码。计算机可读指令可被存储在计算机可读存储介质上，包括非临时性计算机可读存储介质，比如硬盘或固态存储器。

Claims (29)

1.一种用于在多个远程设备上为一个或多个服务请求者启用资产更新的方法，所述方法包括：

在管理服务器处接收指示针对第一服务请求者的要在一个或多个远程设备处更新的资产的更新数据，所述更新数据包括清单数据，所述清单数据包括指示有效载荷的存储位置的有效载荷统一资源标识符(URI)、指示清单数据的信任的认证信息、和有效载荷散列；

在管理服务器处接收活动数据，活动数据与更新数据关联并且至少指示针对第一服务请求者的、要对其应用资产更新的远程设备的子集；和

在管理服务器处接收针对第一服务请求者发起资产更新的请求，所述资产更新是通过向由活动数据至少指示的远程设备的所述子集传送包括清单数据的更新通信来发起的，所述清单数据指示为了更新远程设备而要检索的有效载荷。

2.按照权利要求1所述的方法，其中所述资产包括远程设备的固件。

3.按照权利要求2所述的方法，其中更新数据包括：

包括要应用于一个或多个远程设备的固件更新的固件数据的有效载荷数据；和

包括与有效载荷数据的安装相关的元数据的清单数据。

4.按照权利要求3所述的方法，其中活动数据与清单数据关联，并且其中所述更新通信包括针对要应用的有效载荷的清单数据。

5.按照前述权利要求中任一项所述的方法，其中活动数据包括设备筛选器，所述设备筛选器指示要应用的筛选器，以识别更新要被应用于的远程设备。

6.按照权利要求5所述的方法，其中每个远程设备与识别与该设备相关的信息的一个或多个字段关联，并且其中所述设备筛选器包括用于识别远程设备中的哪些远程设备要按照活动数据被更新的一个或多个字段的值。

7.按照前述权利要求中任一项所述的方法，其中通过应用编程接口(API)接收更新数据和活动数据。

8.按照前述权利要求中任一项所述的方法，其中管理服务器还被配置成从所述远程设备的子集接收更新状态信息，所述更新状态信息指示在远程设备处的固件更新的状态。

9.按照前述权利要求中任一项所述的方法，其中更新数据是从开发者设备接收的，并且活动数据是从操作者设备接收的，并且其中开发者设备和操作者设备与第一服务请求者关联。

10.按照前述权利要求中任一项所述的方法，还包括：

在管理服务器处，接收指示要在一个或多个远程设备处更新的第二固件的第二更新数据；

在管理服务器处，接收与第二更新数据关联并指示要对其应用更新的远程设备的第二子集的第二活动数据，其中第二子集不同于第一子集；和

接收通过向远程设备的第二子集传送第二更新通信来发起第二固件更新的请求，所述第二更新通信指示为了更新远程设备的固件而要检索的第二固件。

11.按照权利要求10所述的方法，其中第二更新数据包括：

包括要应用于一个或多个远程设备的第二固件更新的第二固件数据的第二有效载荷数据；和

包括与第二有效载荷数据相关的第二元数据的第二清单数据。

12.按照权利要求11所述的方法，其中第二活动数据与第二清单数据关联，并且其中第二更新通信包括要应用的第二有效载荷的第二清单数据。

13.按照权利要求10-12中任一项所述的方法，其中第二活动数据包括第二设备筛选器，所述第二设备筛选器指示要应用的第二筛选器，以识别第二更新要被应用于的远程设备。

14.按照权利要求13所述的方法，其中每个远程设备与识别与该设备相关的信息的一个或多个字段关联，并且其中所述第二设备筛选器包括用于识别远程设备中的哪些远程设备要按照第二活动数据被更新的一个或多个字段的值。

15.按照权利要求10-14中任一项所述的方法，其中通过应用编程接口(API)接收第二更新数据和第二活动数据。

16.按照权利要求10-15中任一项所述的方法，其中管理服务器还被配置成从远程设备的第二子集接收第二更新状态信息，所述第二更新状态信息指示在远程设备处的第二固件更新的状态。

17.按照权利要求10-16中任一项所述的方法，其中第二更新数据是从第二开发者设备接收的，并且第二活动数据是从第二操作者设备接收的，并且其中第二开发者设备和第二操作者设备与第二服务请求者关联。

18.按照前述权利要求中任一项所述的方法，还包括响应于发起固件更新的请求，向远程设备的所述子集传送更新通信，所述更新通信指示为了更新远程设备的固件而要检索的固件。

19.按照权利要求3-18中任一项所述的方法，还包括：

接收针对存储在管理服务器处的清单的列表的清单请求；

响应于所述清单请求，返回存储在管理服务器处的清单的列表；

接收针对存储在管理服务器处的设备筛选器的列表的设备筛选器请求；

响应于设备筛选器请求，返回从存储在管理服务器处的设备筛选器中确定的有效设备筛选器的列表。

20.按照权利要求19所述的方法，其中设备筛选器请求识别清单，并且其中所述方法还包括：

通过基于满足在识别的清单中定义的一个或多个字段的设备筛选器选择存储的设备筛选器的子集，从存储在管理服务器处的设备筛选器中确定有效设备筛选器的列表。

21.按照权利要求19或20所述的方法，其中设备筛选器请求识别清单，并且其中所述方法还包括：

通过基于满足在识别的清单中列出的设备制造商和型号至少之一的设备筛选器选择存储的设备筛选器的子集，从存储在管理服务器处的设备筛选器中确定有效设备筛选器的列表。

22.按照前述权利要求中任一项所述的方法，其中管理服务器按照活动数据存储一个或多个活动。

23.按照前述权利要求中任一项所述的方法，其中在管理服务器处被接收之前，接收的活动数据被签名。

24.按照权利要求23所述的方法，其中利用公钥加密签名或密钥散列消息认证码(HMAC)对活动数据签名。

25.按照权利要求22或权利要求23所述的方法，其中活动数据被转发给所述远程设备的子集，以便进行认证。

26.一种在多个远程设备上为一个或多个服务请求者启用资产更新的管理服务器，所述管理服务器包括：

至少一个接口，用于：

在管理服务器处接收指示针对第一服务请求者的要在一个或多个远程设备处更新的资产的更新数据，所述更新数据包括清单数据，所述清单数据包括指示有效载荷的存储位置的有效载荷统一资源标识符(URI)、指示清单数据的信任的认证信息、和有效载荷散列；

在管理服务器处接收活动数据，活动数据与更新数据关联并且至少指示针对第一服务请求者的、要对其应用更新的远程设备的子集；和

在管理服务器处接收针对第一服务请求者发起资产更新的请求，所述资产更新是通过向由活动数据至少指示的远程设备的所述子集传送包括清单数据的更新通信来发起的，所述清单数据指示为了更新远程设备而要检索的有效载荷。

27.一种进行按照权利要求1-25中任一项所述的方法的装置。

28.包括计算机可读指令的代码，当由处理器执行时，所述计算机可读指令使所述处理器进行按照权利要求1-25中任一项所述的方法。

29.一种配置成存储按照权利要求28所述的代码的计算机可读存储介质。

Images