Patent Application
20200285457
The present application relates to a mechanism to enable a service to update the firmware or other asset data of networked electronic devices in an automated and reliable manner that can be managed by third parties.
Remote electronic devices may be configured to connect to a server and to communicate with that server. The server many be configured to manage operation and communication with the devices. In many applications, such as internet of things (IoT) applications, there may be many similar or identical devices that are configured to connect to the server and be managed by that server in similar or the same way.
In order for the devices to operate in a secure and reliable manner it is necessary to provide updates to assets of the devices, such as code, keys, and/or configuration of the device. In an example, firmware operating on the device may need to be updated—for example to address security flaws or to modify the behaviour of the device. In many such applications, the devices may be physically disparate or inaccessible or so numerous that it is unfeasible to directly and manually update the firmware of each device separately.
There is therefore a desire to improve the manner by which the assets (such as firmware) of remote electronic devices is updated.
A method for enabling an asset update for one or more service requesters on a plurality of remote devices, the method comprising: receiving, at a management server, update data indicating an asset to be updated at one or more remote devices for a first service requester, the update data comprising manifest data comprising a payload uniform resource identifier (URI) indicating where the payload is stored, authentication information indicating the trust of the manifest data, and a payload hash; receiving, at the management server, campaign data associated with the update data and indicating at least a subset of the remote devices to which an asset update is to be applied for the first service requester; and receiving, at the management server, a request to initiate the asset update for the first service requester by transmitting to the at least the subset of the remote devices indicated by the campaign data an update communication comprising the manifest data indicating that a payload is to be retrieved for updating the remote device.
A management server for enabling an asset update for one or more service requesters on a plurality of remote devices, the management server comprising: at least one interface to: receive, at the management server, update data indicating an asset to be updated at one or more remote devices for a first service requester, the update data comprising manifest data comprising a payload uniform resource identifier (URI) indicating where the payload is stored, authentication information indicating the trust of the manifest data, and a payload hash; receive, at the management server, campaign data associated with the update data and indicating at least a subset of the remote devices to which an update is to be applied for the first service requester; and receive, at the management server, a request to initiate the asset update for the first service requester by transmitting to the at least the subset of the remote devices indicated by the campaign data an update communication comprising the manifest data indicating that a payload is to be retrieved for updating the remote device.
Examples of the disclosure will be described with reference to the appended drawings in which:
The present application relates to the provision of apparatuses and methods by which the updating of assets of one or more remote devices can be enabled in an automated and reliable manner. The updating of assets provides third parties with the capability to delegate the responsibility for enacting an update campaign to an update service which has a number of technical benefits. One aspect of the delegation is that third parties may not want to have to trust the update service to roll out an update.
The update service provides how to enable a service to perform an update on behalf of a third party without the third party having to place trust in the service, based on an established trust relationship between the third party and the device. In addition, the update service does not necessarily need to have direct access to the payload and does not deliver that payload directly to the devices.
Therefore, in embodiments the owner of the firmware update and the device managing entity (i.e. the first service requester) need not be the same entity.
By the third party providing to the service manifest data comprising a payload URI, authentication information indicating the trust of the manifest data, and payload hash for transmission to the remote device, the remote device is equipped with everything it needs to perform an asset update in a trusted manner because the remote device already has an established level of trust with the third party. As such, the manifest information can be distributed to the service and provided to a number of remote devices without requiring the trust of the service. This is because the remote device can trust the manifest data (due to the authentication information) and thus can trust the payload URI, based on a trust relationship between first service requestor and remote device. Since the payload URI is trusted, the remote device can be sure that the URI from which the asset is retrieved is valid. Furthermore, since the payload hash is also trusted, the device can perform authentication of the retrieved hash and thus can have trust in the obtained payload.
In addition, the “first service requester” does not need to be potentially involved and complex technical capability to connect to a number of different remote devices, which could involve multiple different communication protocols and devices with different processing capabilities. As such the first service requester is not required to have any capability to communicate directly with the device. This approach enables the separation of responsibility between device owner and device communication enabler in a manner that removes the need for the device owner to trust the device communication enabler.
The following description sets forth a number of examples by way of illustration only.
The computing system 100 comprises a plurality of remote electronic devices 110 that are communicatively coupled to a management server 120. The remote electronic devices 110 are electronic devices that may be disparately located, such as Internet-of-Things (IoT) devices. The remote electronic devices 110 may be connected to the management server 120 through different networks or through the same network. For example, the remote electronic devices 110 may be connected via a wired or wireless connection to the management server 120.
The management server 120 is a computing server (or servers) configured to manage the remote devices and their respective connections to the management server 120. The management server enables assets of the devices to be managed and maintained by an owner or manager of the devices. The owner or manager of the devices may require one or more assets of the devices it is responsible for to be updated and thus becomes a requestor that requests of the management server 120 an update of the remote devices 110 associated with that request. The management server 120 may provide one or more interfaces through which the updating of the remote devices can be managed. This may be provided through an interface that receives data provided via a portal and/or receives data via an application programming interface (API) gateway such as a REST API.
In the arrangement of
System 100 further comprises a developer device 130 communicatively coupled to the management server 120, for example through the portal and the API. The developer device 130 is an electronic device from which the firmware and its corresponding metadata is provided to the management server 120. This process will be described in more detail later. The developer device may form part of a service requester that requests that the management server 120 provide as a service an update of assets of the device. The developer device may be a device through which a developer is able to provide the firmware image (or other asset data) that is to be applied to the remote devices 110.
System 100 further comprises an operator device 140 communicatively coupled to the management server 120. The operator device is an electronic device from which the management of the remote devices can be handled by the owner of the devices. The operator device 140 therefore forms a part of the service requester that requests an update of assets of the remote devices. The developer that operates the developer device 130 may be the same entity that operates the operator device 140 or the entities may be separate entities.
Updates of assets, such as a firmware update, on the remote devices 100 are provided as a service by the management server and are initiated as a result of the communication of update data from the developer device 130 and campaign data from the operator device 140. In order to update the remote devices 100, each of these two entities provides a respective set of data that collectively defines the update process to be managed by the management server 120 on behalf of the service requester. The developer device 130 is a device that can be operated by or managed by a developer of the updated asset, such as updated firmware data. This allows the location of the developer that develops the firmware to be separate from the location of the management server 120.
Update data may be provided by the developer device 130. The update data provides an indication as to the asset that is to be updated on the remote devices 110 and the manner by which the update of that asset is to occur. For example, the update data may comprise the new value of the asset that is to be updated and the criteria to be met at the remote device in order for the remote device to take the new value. In some example, the update data may comprise payload data and manifest data.
The payload data defines the values of the updated asset to be applied to the remote devices. For example, where the asset to be updated is the firmware of the device, the payload data may define the firmware image data that is to be installed on one or more remote devices 110. The payload data may define the updated firmware and may be a firmware image. The manifest data describes metadata relating to the payload, such as how it is to be updated at the local device, or where it is stored. More detail concerning the type of information that can be stored as manifest data will be described later. As an example, the manifest data may define where to find the payload (e.g. the URI of the payload), the device types to which the payload data applies, and how to decide whether to trust the payload data when it is being applied. The manifest data may be generated at the developer device 130 by a manifest tool operating at the developer device 130. The management server 120 is configured to receive the update data from the developer 130 and, in some examples, to send the manifest data to a remote device 110 to forward the developer's instructions about where to obtain the image and under what conditions to download and apply it. The terms manifest data and payload data are used herein to refer to the data itself, such as a firmware image or the complete manifest data. However, it will be appreciated that reference herein to transmitting manifest data and/or payload data may instead involve transmitting a URI indicating a location at which the receiving entity can separately access the data.
The operator device 140 may provide to the management server 120 campaign data that is associated with a particular set of update data. The operator device 140 is a device that can be operated by or managed by an owner of the devices or an entity responsible for the management of the devices—such as an entity that determines which devices are to be updated and in which manner. An update campaign can be considered to be a strategy by which the remote devices 110 are to be updated and is defined by campaign data. The campaign data for a particular update campaign is configured to couple the manifest with a device filter. The device filter indicates which of the remote devices 110 that are communicatively coupled to the management server 120 should be updated. In this way, the device filter identifies a filter that is to be applied to all remote devices communicatively coupled to the management server 120 so as to select a subset of the remote device 110 to which the update is to be applied. As such, the management server 120 can be configured to use the campaign data of the update campaign to send the manifest to all devices matching the device filter. In some implementations, a manifest may be included in more than one update campaign, coupling it with different filters. This can allow the operator device 140 to manage the update of remote devices 110 in batches, with each update campaign targeting only a subset of the remote devices according to the device filter associated with the batch.
As mentioned above, the payload data for an asset to be updated (e.g. a firmware image) is separate from the manifest (e.g. metadata) that describes to a manner by which the update is to occur. By separating the payload from the manifest, the distribution of payload is simplified. For example, a single payload (e.g. firmware image) can be sent to disparate devices. This also permits distribution of the firmware image over a Content Distribution Network, which does not need to be trusted, because trust is established via the metadata—as will be explained later.
In order for a remote device to apply an update of a particular asset, it has to determine that the update it has received should be trusted and should be applied. For example, the device may need to know whether the author of the update can be trusted, whether or not the update is corrupted, whether the update applies to the device, whether the update is up-to-date, at what time the update should be applied.
Accordingly, the manifest may be derived from one or more fields to enable the device to determine whether or not to apply the update. The fields of the manifest form the manifest data provided to the management server 120. A number of fields may be used to generate an encoding that forms the manifest. The fields from which the manifest is derived may comprise one or more of:
By providing the manifest to the remote device 110, the remote device 110 can determine whether or not to install the received update. As part of this process, the remote device 110 acts to determine whether or not the update is a valid update received from the management server 120.
The system of
To secure the manifest, the management server 120 and the developer device 130 are configured to use a cryptographic method, such as public key cryptography.
In an example, each remote device 110 and the developer device 130 are configured to make use of elliptic curve cryptography (ECC), a type of public key cryptography (other public key cryptography techniques may instead be used). In an example, a manifest tool operating at the developer device 130 and the remote device 110 use the Elliptic Curve Digital Signature Algorithm. This algorithm uses two pieces of information: namely a secret, called the private key and a number, called the public key, which corresponds to the secret.
To sign the manifest, the holder of the private key (developer device 130) first computes a hash of the manifest using SHA256, then transforms that hash using the private key. This new number, called the signature, is appended to the manifest. Later, anyone with the public key (such as each remote device 110) can verify that the signature matches the document by: computing a hash of the document using SHA256, transforming the signature back into a hash using the public key, and comparing the computed hash and the signature hash.
If the hashes are the same, then the verifier can be confident that the signer was in possession of the private key. This is because it is a computationally hard problem to determine a private key from a public key, even if you have many examples of a transformation done using the private key.
Public keys are generally packaged inside a certificate, which contains additional information about the public keys and who they belong to. This certificate is also signed, either by another authority (a Certificate Authority) or by itself (a self-signed certificate). Certificates are generally identified by a fingerprint, such as a hash of the certificate (e.g. a SHA256 hash of the certificate).
The remote device may use the ECC curve ecc-secp256r1, a NIST-recommended curve. ECC may be used instead of RSA on the remote devices because of reduced key size and higher performance on computationally limited platforms.
Authenticity is critical to any operation that can modify the behaviour of a device, particularly a firmware update. Validating the authenticity of firmware updates helps keep internet-exposed devices (such as remote devices 110) doing what their designers intend; failure to validate could lead to compromise or destruction of devices.
A signature provides both integrity and authenticity validation to the firmware. Regardless of authority, if the provided signature matches the firmware, then a remote device 110 can be confident that the holder of the private keys for the signature has approved the firmware. This prevents impersonating someone when sending firmware to a device, or modifying the firmware in transit.
Devices can decide which private keys to trust without knowing the private keys, by trusting the matching certificates. Provided that private keys are adequately protected, this guarantees that the device will install only authentic firmware.
The manifest is signed by a private key at the developer device 130, creating a signature. The remote device 110 verifies a manifest's signature using the verification certificate. The manifest will only have a valid signature if it was created with the same private key as the verification certificate, implying whoever created it has access to that key. If the signatures match, the manifest is granted authority. The remote device will reject an incorrectly signed manifest.
The manifest may also contain a hash (such as a SHA256 hash) of the payload (e.g. the firmware image). Since the manifest is signed, this ensures that, regardless of the download method, the manifest can only be used to install a full and unaltered copy of the intended image.
As mentioned above, the operator device 140 may be configured to transmit to the management server campaign data for an update campaign comprising a device filter that indicates which of the remote devices 110 are to be affected by the update of the asset. Then, when the update campaign is uploaded to the management server 120, the campaign can be started and monitored.
An example process for initiating an update campaign is described in relation to
At step 220, the payload data (e.g. the firmware image) is transmitted from the developer device 130 to the management server 120 and is stored either at the management server or at another remote device (not shown in
At step 230, manifest data is generated that defines the manner in which the update of the asset (e.g. firmware) of remote devices 110 should be handled. The manifest may be generated at the developer device 130 and/or may be generated externally and passed to the developer device 130 for transmission to the management server 120. The manifest may be generated at a manifest tool running on the developer device 130 (or other device). As mentioned previously, the manifest may comprise one or more fields that define the manner by which the update of the remote devices should occur, as discussed above. In addition, the manifest may comprise a manifest signature—for example that was generated using a public key cryptographic technique. The manifest may also comprise a hash of the payload that was created and transmitted at steps 210 and 220.
At step 240, the manifest may be transmitted from the developer device 130 to the management server 120. It will be appreciated that the generation and transmission of the manifest and the payload may occur together. Put another way, steps 210 and 230 may be combined and steps 220 and 240 may be combined.
The manifest may be generated in one of a number of ways using a manifest tool. For example, the manifest tool may parse an input file (such as a JSON input file) which comprises information used to create the manifest. Where information is missing from the input file, the manifest tool may check for a defaults file that contains default values for fields missing in the input file. Alternatively, the manifest tool may generate a manifest by receiving command line arguments defining the fields to be inserted into the generated manifest.
In some arrangements, the manifest with an unencrypted payload may comprise at least (i) a cryptographic mode to use (such as none-ecc-secp256r1-sha256), (ii) a payload URI (uniform resource identifier), (iii) one of a URI of a certificate to be used for signing the manifest or a local file that is to be used for signing the manifest, (iv) a local file that is the signing key for that certificate, and (v) one of a vendor ID and device class ID, or a device ID (to identify devices to which the manifest applies).
In this mode, the manifest tool creates a manifest that is signed; the payload is unencrypted. The target remote device(s) 110 already has the provided certificate, or provides a way to fetch that certificate. An example approach for creating a manifest will be described later.
At step 240, the generated manifest can be uploaded to the management server in a similar manner to the payload of step 220, for example via an API and/or via a portal.
At step 250, a device filter is created at the operator device 140. The device filter indicates a plurality of remote devices 110 which are to be updated. When processed the device filter prevents remote devices 110 which are not permitted to be updated from being updated. The format of the device filter will be described in more detail.
At step 260, an update campaign is created at the operator device 140 by defining campaign data for the update campaign. As mentioned previously, an update campaign defines an approach for updating the assets of remote devices and can be considered as a construct by which assets such as firmware updates are presented to one or more pre-determined remote devices. Typically, a campaign may comprise or be associated with at least one manifest as defined from a developer device 130 and a device filter as defined at the operator device 140. Accordingly, the update campaign collectively defines an asset update that is to be applied, the manner in which it is to be applied, and the devices to which the asset update is to be applied in the defined manner.
Accordingly, campaign data can be considered to be a definition of a process that advertises a manifest to one or more devices. This can be done by writing to a manifest resource on the appropriate remote device 110 via a connection service hosted on the management server 120. If a particular remote device is not reachable immediately, it is possible for it to miss the advertisement and hence miss the update. This can be mitigated by starting a second, different campaign to those devices using the same or a different device filter. Devices which have already been updated will ignore the second campaign, either because it is not listed in the device filter or because it already has the latest firmware version. The list of devices to which the asset update is to be applied may be derived from a device directory, which may be a global register of registered devices. The mechanism to select a subset of devices is a device filter. Although the manifest may pre-set a filter with a class and/or a vendor of the devices it is compatible with, deployments may require additional device targeting information.
For example, instead of or in addition to a class or vendor ID it may be possible to filter the devices that are advertised to according to a campaign using other fields. For example, there may be fields that indicate a physical location of the devices, a model number of the devices, or other such fields. An example filter is illustrated below which will advertise the update to a number of devices with a particular model number within a particular floor of a particular building:
mode1=‘AIRCONv3-revB’, customer=‘ARM’, city=‘CAMBRIDGE’, building=‘CPC1’, floor=‘2’
In some examples, the operator device 140 may access an API to connect to the management server 120 which may allow the following actions to take place to manage campaigns and device filters:
To explain the generation of remote device filters, it is also useful to provide some detail on the lifecycle of a remote device. During manufacture of a remote device, the device can be provided with: a device certificate, which provides access credentials to the management server; and application code, along with a bootloader.
The status of a device changes as the device goes through the bootstrap process to enrol it on with a management service provided by the management server. Once fabricated, a remote device starts in an “unenrolled” status. Once enrolment is complete, the remote device enters a “registered” state. In the event of an error during an enrolment process, the device will not make it to the registered state. The device status can be accessed via the management server.
The management server may be configured using one or more of the following fields:
Where state can take one of the following values:
Managing devices in a large-scale cloud deployment can be overwhelming due to the large number of devices in the field. Complex and sophisticated filters that enable the selection and management of devices can be provided by maintaining a list of fields. The fields can then be used to generate such complex filters, which can be used to interact with or monitor subsets of devices. For example, it would be possible to filter devices by any combination of the above attributes. In addition, the management server allows for custom attributes to be added by the operator device 140.
The update campaign is started or deployed at step 270 and the update process begins. The deployment advertises the specified manifest to a list of devices as defined in the device filter. The start of the campaign at step 270 may be triggered by the operator device 140 transmitting to the management server a “start” command. This may, for example, be performed by an API or via a portal. The process of advertising manifests to devices then begins.
At step 280, the progress of the update campaign can be monitored at the operator device 140 by receiving or retrieving progress or status information from the management server 120. During deployment, an advertisement message is sent to a set of devices as defined in the device list.
However, as mentioned previously the deployment may not result in each of the set of devices being updated. For example, devices may or may not see the advertisement, devices may ignore the advertisement for various reasons (such as the devices being low power or being in a critical state), or devices may receive advertisements from other deployments or via other means.
Therefore, the update mechanism described herein provides a mechanism to monitor devices rather than campaigns. For convenience, campaigns can be filtered by the devices they target.
At step 330 of the method, the inner part of the manifest is hashed and then signed at step 340 using the hash and the certificate private key. At step 360, the inner part, hash, signature, certificate fingerprint, and certificate URI is wrapped in the outer part of the manifest.
In some arrangements it may be possible to create a manifest with an encryption mode (for example none-ecc-secp256r1-sha256). To create a manifest with encryption mode, additional information is provided. For example, the following information may be provided:
Set out below is an example manifest in which all fields are provided via an input file:
As mentioned previously, there are a number of different ways data may be provided to a manifest tool. The tool may parse a JSON input file, which can contain all of the information used to create the manifest. Where information is missing from the input file, the manifest tool may check for a file that contains defaults in the current working directory. Another way is to provide data via command line arguments; many of the fields used by the manifest tool can be overidden on the command line.
Manifests may use SHA256 for hashes, ECDSA signatures on the secp256r1 curve, with no encryption. This encryption mode can be referred to as none-ecc-secp256r1-sha256 in the manifest tool.
For creating a manifest with unencrypted payload, the following fields may be used:
Further payload information that may be stored in the manifest may include:
The authenticity of an update is to be provable, with sufficient levels of entropy to remain secure for the lifetime of the device (for example, at least 128 bits of security for a 15+ year lifetime). Typically, this means that updates are signed. Other proof mechanisms are acceptable, such as MACs, or Zero Knowledge Proofs. Since the manifest contains information about how to install the update, the manifest's authenticity can be provable. To reduce the overhead required for validation, the manifest contains the digest of the payload, rather than another signature. This does not change the provability of the payload. The authenticity of the manifest is provable with a signature, the authenticity of the payload digest is provable with the manifest, and the authenticity of the payload is provable with the payload digest.
In some arrangements, the manifest is signed by an authorized update author. The update author is the actor that assembled the update image. An intermediary signer may not be used. In such arrangements, the target device has public keys that it uses to authenticate an update provisioned in a secure and irrevocable way. The device does not accept new keys unless they are signed by the old key. The device should retain this audit trail.
Devices regularly expire author public keys and revoke author public keys when an author becomes untrusted. This may be done with certificate expiry and certificate revocation. The server may use a mechanism similar to OCSP stapling to simplify manifest signature certification revocations checks for the device. The management server 120 may be configured to fetch certificates on behalf of the remote device 110 and attach the individual revocation statuses for the certificates involved in verifying the validity to the manifest.
The update author can use an HSM for signing. The content of the manifest can be compared before and after signing. The comparison can be done on a different machine than the signing. For large deployments, the manifest can be verified on an air-gapped computer with an HSM.
For large deployments, the update author can use an air-gapped build machine running a secured compiler. Optionally, the compiler can be signed by the vendor. For large deployments, the compiler itself can sign all build outputs. The digest of the resultant binary should be compared to the digest in the manifest. The update author can verify the contents of the manifest as retrieved from the cloud service prior to dispatching the manifest to a target device._The manifest can contain a digest of the payload.
Manifests can contain a globally, monotonically increasing sequence number. Even when many authorized firmware authors are present, across many locations, the sequence number provided in the manifest can be monotonically increasing.
Manifests and the contents thereof are be stored or transmitted in non-canonical form. If such a mechanism is technically necessary, e.g. a database, then the manifest are transmitted to and verified by the recipient of the non-canonical data. Protection of payload encryption keys. A device vendor can perform a risk analysis and choose their desired level of payload security.
Encrypted payloads can come in a variety of security levels:
A device vendor chooses which of these payload security classes best fits their risk profile, while balancing the use of symmetric keys (pre-shared, low energy, but hard to protect), asymmetric keys (not shared, high energy, easier to protect), energy profile, etc. When encrypted payloads are used, the manifest can include the digest of the payload encryption key. Any firmware update that is stored off-chip can be signed with a unique, per-device encryption key. Any firmware update that is stored off-chip can be encrypted with an unique, per-device encryption key. Devices can encrypt any off-chip data with an unique, per-device encryption key to prevent extraction. Devices can disable any SWD/JTAG read-out facilities by burning the appropriate debug protection fuses. Where a device supports a secure debugger, this need not be disabled. Devices can check certificate expiry times against manifest timestamps. A manifest may not be accepted if its timestamp is later than the expiry time of the certificate used to sign it. A manifest may not be accepted if its installation time is later than the expiry time of the certificate used to sign it. Devices may enforce time securely using a logical clock, based on secure origins. This applies regardless of whether there is an RTC or not, since RTCs can be attacked as well.
Manifests may be delivered to devices over a secure, authenticated channel. Payloads may be delivered over a secure, authenticated channel. The risk of not delivering manifests, payloads over a secure, authenticated channel is an increased risk of denial of service via the threats mitigated by this requirement. Each device may have an unique, cryptographically provable identity. This identity may be verifiable by a communication partner, such as a server, a peer device, or a user's application. The target device may implement rate limiting that is suitable to its application space. It may not be possible to send many manifests quickly, since that can cause the device to use large quantities of energy and/or flash cycles.
Status reports should be routed through a trusted, private communication medium, which prevents an attacker from inspecting packets sent by a device and selecting which ones to block.
All descriptive information about the payload can be signed. This can include:
In systems with more than one storage location, the update authors may be identified by Access Control List (ACL). These ACLs identify what the update author is permitted to do on a device. For an update to be installed, it may need to meet the required privileges for the target storage location. The privileges are granted by the signature of an Update Author. All actors who receive a manifest validate the authenticity of a manifest before processing its contents.
A trust anchor may be considered to be a public key, installed on a device at time of manufacture that a device trusts completely for a particular task. Trust anchors should not be replaced, revoked, or expired. A trust delegate may be considered to be a public key, signed by a trust anchor, or a trust delegate. Ultimately, each chain of delegation ends in a trust anchor. Trust delegates may be replaced, revoked, or expired at any time.
A security model that can be applied to the systems described herein is built using the security requirements discussed above.
The workflow of
As can be seen from
The workflow begins at step 501 at which a request to build a firmware image is transmitted to the build tools from the developer device. The build tools return at step 502 a compiled image to the developer device. At step 503, a request to upload the firmware is passed via the portal at 503 and the API gateway a step 504 to the firmware catalogue service at step 505 in the management server 120. At step 506, the firmware image is stored in the firmware storage. At steps 507, 508, 509, and 510 confirmatory messages confirming that the firmware has been stored are returned to the developer device.
Also provided is an API gateway through which communications are passed into the sub-services of the management server 120. In the example of
The workflow of
At step 607, a create campaign message is transmitted from the cloud portal to the API gateway, the create campaign message comprises an indication of the manifest that is to be associated with the selected manifest. At step 608, the API gateway forwards the create campaign message to the deployment service which records the creation of a campaign associated with the selected manifest. At steps 609 and 610, confirmation messages that the campaign has been created at the deployment service are transmitted.
At step 611, the portal issues a request to the API gateway for a list of valid device filters. The valid filters can, for example, be selected from the filters which specify a device manufacturer and model number listed in the selected manifest. Other fields in the manifest can additionally or alternatively be used to identify the list of valid device filters to be used based upon the manifest. A request for the list of valid is transmitted from API gateway to the device catalogue service at step 612. The device catalogue determines which of the filters made available at the device catalogue service are valid and returns a valid list at step 613 to the API gateway, which is then forwarded at step 614 to the portal. At step 615, the device filter to be used is selected from the list of valid device filters and provided to the portal. The portal transmits a campaign update message to the deployment service via the API gateway at steps 616 and 617. The campaign update message indicates the device filter to be used. Once received at the deployment service, the campaign is updated at the deployment service. Confirmation messages confirming that the update has taken place are returned to the portal and presented to the operator device at steps 618 and 619.
At step 620, the operator device initiates at step 620 the start of the update campaign by entering data the web portal. For example, this may take the form of a start campaign message or an interaction with a user interface. At steps 621 and 622, the start campaign message is transmitted from the web portal, through the API gateway, and to the deployment service. The deployment service may immediately initiate the update campaign if there is bandwidth to do so. Alternatively, if other campaigns are currently in progress the deployment service may be queued for processing once resources are available. At steps 623, 624, and 625 a confirmation is returned to the operator device that the update campaign has been initiated. By providing this approach, it is not necessary for the device operator to receive a copy of the payload in order to generate a campaign.
In some arrangements, the created campaign data may be signed before it is uploaded to the management server 120. In such approaches, the signed campaign data may be required by the remote device 110 which is to be updated in order to authenticate the campaign data, and accept it. The campaign data may be signed using a public key cryptographic signature or a keyed-hash message authentication code (HMAC). The signing of the campaign data achieves end-to-end security of the campaign data which protects against altered maliciously.
The remote device 110 may be configured to act to resolve any conflict between received campaign data and received manifest data. For example, the remote device may receive manifest data indicating that devices belonging to a particular manufacturer are to be updated but may receive campaign data that allows another manufacturer (for example the campaign data may make an exception to the valid manifest data). The remote device 110 may automatically reconcile the conflict, for example by automatically deferring to one of the campaign data and the manifest data based on a pre-determined rule. Alternatively, the remote device 110 may notify the management server 120 of the conflict that must be resolved by user intervention.
The workflow of
At step 703, campaign metadata entries are created for the device and at step 704 the deployment service provides data to the device catalogue service such that a device log for a remote device can be updated at step 705 to reflect the deployment of updated asset data to the remote device.
At step 706, a request for manifest data is sent from the deployment service to the firmware catalogue and at step 707 the firmware catalogue returns a copy of the manifest. An updated manifest data is sent to the connector channel service at step 708 which transmits manifest data to one or more remote devices in accordance with the device filter. The devices either acknowledge receipt of the communication or do not, based on the success of the communication. The resultant status of the update is returned at step 710 to the deployment service which updates the metadata associated with the remote device at step 711.
Workflow 800 begins at step 801 where the connector channel service is notified of a change in the resource of a device. This may occur, for example, using an HTTP callback. At step 802 the connector channel service informs the device catalogue service of the resource change. At step 803, the device catalogue service creates a device log entry relating to the resource change. At step 804, the connector channel service informs the deployment service if all the devices have reached the target version, at which point the campaign can be marked as complete.
At any point, the operator device initiates at step 805 an instruction via the portal to monitor the campaign. At steps 806 and 807, the portal requests device log entries for the campaign which are retrieved from the device catalogue service at step 807 and returned to the API gateway at step 808. The logs can then be provided to the operator device to show to the operator device the status of the update of the asset of the remote devices according to the update campaign.
In the arrangement of
The management server 120 can be configured to manage multiple update services in parallel, each requested by a separate service requestor. For example, in the arrangement of
For a particular service requestor, the device operator for that service has access to the payload data and manifest data provided to the management server 120 from the developer device of that service provider. However, a particular service requestor would not necessarily have access to the payload data and manifest data of another service requestor. Similarly, a subset of the remote devices communicatively coupled to the management server would typically be associated with a particular service requestor. Such remote devices can be therefore be referenced and updated using a campaign associated with that same service requestor. However, unless explicitly allowed for by the service requestor, a service requestor will not be able to access or update remote devices that do not belong to the service requestor.
In the example of
As will be appreciated by the skilled person, the communication between the various elements of the system can be performed by a wired connection or a wireless connection. For example, the mechanisms described herein may be performed in a manner that is agnostic to the update method and to the communication method between devices and servers. For example, the mechanisms described herein are application to updates via USB mass storage (CMSIS-DAP), server APIs, UART, ZigBee, BLE, Ethernet (TFTP+DHCP) and WIFI are covered by the same format. Moreover, communication between devices and servers may occur via any wired or wireless communication. The communications between various devices may be direct or indirect, and thus may occur through one or more gateways, and may occur over one or more different communication protocols or physical transmission media provided that a communicative channel between devices is established.
As will also be appreciated, reference herein to a device or a server should not be interpreted to be limited to a single hardware element. The techniques described herein are applicable to cloud computing techniques in which the operation of a single device or server, or the provision of a single service, may be distributed amongst one or more physical devices or servers. Accordingly, reference herein to a server should include reference to a plurality of servers that are communicatively coupled so as to provide the functionality of the single referred-to server.
In a particular aspect, present techniques provide a method for managing an asset update service for one or more service requesters on a plurality of remote devices, the method comprising: receiving, at a management server, update data indicating an asset to be updated at one or more remote devices; receiving, at the management server, campaign data associated with the update data and indicating a subset of the remote devices to which an update is to be applied; and receiving, at the management server, a request to initiate an asset update by transmitting to the subset of the remote devices an update communication indicating that the asset is to be retrieved for updating the asset of the remote device.
In a further particular aspect, present techniques provide a management server for managing an asset update service for one or more service requesters on a plurality of remote devices, the management server comprising: at least one interface to: receive, at the management server, update data indicating an asset to be updated at one or more remote devices; receive, at the management server, campaign data associated with the update data and indicating a subset of the remote devices to which an update is to be applied; and receive, at the management server, a request to initiate the asset update by transmitting to the subset of the remote devices an update communication indicating that the asset is to be retrieved for updating the asset of the remote device.
The methods described herein can be implemented in hardware or software or any combination of hardware and software. For example, the methods described herein can be implemented as computer-readable code comprising computer-readable instructions. The computer-readable instructions may be stored on a computer-readable storage medium, including a non-transitory computer-readable storage medium, such as a hard-disk or solid-state memory.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1717204.0 | Oct 2017 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB2018/052996 | 10/17/2018 | WO | 00 |
