GB2591244A - Electronic device manufacture and content provision - Google Patents

Abstract

A method of preparing an electronic device to use stored content (e.g. firmware) comprises generating a delta data structure comprising data to modify an initial image in accordance with a first content data block; encrypting a resultant content data block using a corresponding encryption key; and providing the initial image and the encrypted block for embedding as stored content on the electronic device. A method of generating an update for an electronic device to use stored content, comprises acquiring a first delta data structure comprising data to modify an initial image in accordance with a first content data block to produce a current image; decrypting an encrypted block required by the first delta data structure using an encryption key to produce a first decrypted block, generating a second delta data structure comprising data to modify the current image in accordance with a second content data block; and providing the second delta data structure to the electronic device. A method of bringing a device to a specified level of content, comprises decrypting an encrypted block using a key and applying a delta data structure using the decrypted block to modify an image of content to the specified level.

Description

ELECTRONIC DEVICE MANUFACTURE AND CONTENT PROVISION

The present technology is directed to controlling the integrity of content, particularly encoded content, to be transmitted to receiving electronic devices over a network, especially when untrusted intermediaries may be involved in the transmission process In the past, information processing environments were typically isolated from the "real world", secured from interference by physical barriers and lack of electronic connections, and under the control of dedicated professionals with detailed knowledge of system operation, data integrity and system security. Such installations were once kept behind locked doors and tended by trained operators and system programmers; they were often only accessible from dedicated terminal devices which were themselves often kept in secure areas of a plant or office. Updates to data content (including executables, such as software and firmware) were usually conducted by selected professionals whose interactions with the systems were filtered through access control lists and passwords, and were often subject to checks and balances such as "buddy-checking", managerial sign-offs, and sometimes long periods of testing and parallel operation to ensure that the correct and secure functioning of the systems was maintained.

In recent years, by contrast, more and more devices are becoming networked and provided with local processing capability; these devices are typically in unprotected environments, open to the world through Internet connections, and under the control of people without any particular training in system operation, integrity and security. Very recently, devices from home computers to vehicles and light-bulbs have begun to acquire these additional functions and to be connected together through the Internet of Things (IoT). With this massive proliferation of networked devices, system security and content/executable integrity present increasingly complex difficulties. For example, such devices are not shipped in the way that conventional data processing devices have been shipped in the past -because they are increasingly treated as mere commodities, they may be held in stock at warehouses and retail outlets for some time before being sold and installed by the ultimate user. Thus, the conventional means of dealing with any data content on the devices, such as firmware, are no longer adequate, and the integrity and functionality of the device at its point of use may easily become compromised.

In a first approach to the many difficulties encountered in controlling the integrity of content to be transmitted to receiving electronic devices over a network, the present technology provides a machine-implemented method of preparing an electronic device operable to use stored content, comprising generating a first delta data structure based on an initial image and at least one first content data block, said first delta data structure comprising data to modify said initial image in accordance with said first content data block; encrypting at least one resultant content data block affected by said first delta data structure to generate at least one encrypted block using at least one corresponding content encryption key; and providing said initial image and said at least one encrypted block for embedding as stored content on said electronic device.

Secondly, there is provided a machine-implemented method of generating an update for an electronic device operable to use stored content, comprising acquiring a first delta data structure based on an initial image and at least one first content data block, said first delta data structure comprising data to modify said initial image in accordance with said first content data block to produce a current image; decrypting at least one encrypted block required by said first delta data structure using at least one content encryption key to produce at least a first decrypted block; generating a second delta data structure based on said initial image, said at least a first decrypted block and at least one second content data block, said second delta data structure comprising data to modify said current image in accordance with said second content data block; and providing said second delta data structure for application on said electronic device.

Thirdly, there is provided a machine-implemented method bringing an electronic device operable to use stored content to a specified level of said content, comprising receiving at said device a delta data structure and at least one content encryption key; accessing an image of content previously embedded as stored content on said device, said image of content comprising at least a base image of content and at least one encrypted block; decrypting said at least one encrypted block using said content encryption key to recover a decrypted block; and applying said delta data structure to said decrypted block to modify said image of content to said specified level of said content.

In a hardware approach, there is provided electronic apparatus comprising logic elements operable to implement the methods of the present technology. In another approach, the computer-implemented method may be realised in the form of a computer program operable to cause a computer system to perform the process of the present technology.

Implementations of the disclosed technology will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows an example block diagram of a deployment of a computer-implemented embodiment of the present technology comprising hardware, 15 firmware, software or hybrid components; Figures 2-4 show simplified examples of a method according to an embodiment of the presently described technology; Figure 5 shows one example of a data flow for device preparation and commissioning or first attachment update according to an embodiment of the present technology; Figure 6 shows one example of a data flow for feature enablement according to an embodiment of the present technology; and Figures 7-9 show portions of data flows according to an embodiment of the present technology.

As described above, the manufacturing, distribution, deployment, commissioning and operation of modern electronic devices in today's massively-connected environment presents a number of difficulties, in particular where the integrity of the content on the device is concerned.

Content, which includes, as stated above, both data and executable instructions, is now typically delivered over networks that are unsecured, such as the Internet, and its handling on arrival is conducted by people without any special knowledge of system operation, integrity and security. Such content is open to accidental and deliberate corruption at all stages from source, through the delivery mechanisms over the network to the receiver device, and this may render the receiver device open to unintended errors and to many kinds of malicious interference.

In a further example of the complexities of the present state of technology, devices may be distributed to users without their functions being fully enabled. In such a case, the devices must be commissioned, that is, must have content, such as firmware adapted for specific purposes, made usable. In some cases, devices may need to be customised at the time of initial commissioning, or may need to have updates applied to them then or later. Additionally, device firmware or software may be authored by an original author, and then provisioned to devices in a factory or in the field after their onward distribution to the ultimate user. In all these cases, the delivery of the content may be vulnerable to error or malicious interference in transit through the distribution path to the ultimate user.

These factors render it necessary to exert a level of control over the distribution of content, to maintain its integrity, and the exerting of that control presents many difficulties.

Several entities are typically involved in the flow of the content from the original designer to the ultimate user: 1. OEM: the designer/content author of the end device.

2. Contract Manufacturer (CM): the manufacturer of a device.

3. Silicon Vendor (SiV): The designer of a device's processor circuitry.

4. Silicon Fab (SiF): The manufacturer of a device's processor circuitry in a factory (SiF is sometimes owned by the SiV).

5. Distributor: The middle-man that buys devices from the SiV and sells them to the OEM, optionally providing value added services, such as preprogramming.

6. Ultimate user: The purchaser of the device for its intended purpose.

Many devices are manufactured in CM factories that are not trusted. These devices still may need to receive confidential and proprietary content, such as trade secret firmware. If the content is installed in the CM factory, the OEM must provide that CM with an image to flash onto the device. This risks exposing confidential, proprietary content to an untrusted CM, who could use it to create grey-market goods. Further, many devices sit in inventory for long periods prior to deployment, which risks their firmware being out of date at deployment time, leading to a requirement for a firmware update when the device first connects or is otherwise commissioned ready for use.

Conventional approaches to the provision of content to devices include contracting a distributor or a trusted third party to pre-program images, shipping an encrypted binary to the CM and using in-field key provisioning to deliver the decryption/installation key, or shipping a minimal image to the CM and using a firmware update mechanism to deliver substantially all of the production image. These approaches have significant drawbacks; for example, asking a distributor or third party to deliver devices with different images for different product content may attract significant additional cost. Shipping a full content initial image typically means that a device needs to install the initial image prior to updating to the latest version. This doubles the energy consumption of the update (Flash programming energy consumption forms the majority of a firmware update) because the device must first flash the decrypted original image, and then flash the updated image. Shipping a full image update is bandwidth-intensive and may require a significant portion of a constrained device's battery life. It can also not be sent using convenient multicast technology because each device needs to be updated at time of first connect.

Content that is to be delivered over a network may comprise data or executable instructions and may be encoded in various ways. In one implementation, content may comprise data encoded in a machine-readable format, and it may comprise data encoded together with structure entities that define the structure to be imposed on the data -for example, a word-processor file may comprise text data encoded in ASCII intermingled with directives that control the presentation of the text data, such as line feed and font change codes. Other content may be distributed using the present technology in other formats that may be more convenient, for example, formats that use less bandwidth over the signal medium. In one example, a modification to already stored data may be distributed to receivers in the form of transform instructions, so that specified locations in the pre-existing data at the receiver may be modified according to the transform instructions. In another example, content in the form of a delta file may be distributed to receivers, so that receivers can add new data or replace pre-existing data with changed data according to embedded instructions in the delta file. In these examples, the bandwidth occupied by the content is significantly less than if a whole new image of the content were to be transmitted.

The present technology is capable of securely delivering up-to-date content, such as firmware, to devices even when they are manufactured in an untrusted factory, without exposing any proprietary firmware to that untrusted factory and without the need to send the whole of the content to the device. As an additional refinement, this mechanism can be used to provide secure feature delivery and update to all or only a subset of devices, or to provide for individually tailoring the production level of content on devices from a set of functions that are shipped to all devices, but only enabled on selected devices.

In one refinement, there may be provided a set of optional feature components each contained in one or more encrypted blocks. Each such component can have its own content encryption key (CEK). This allows the OEM to selectively deliver CEKs to devices in order to enable the features and bring them up to date if necessary in a single operation, without exposing the code for those features to any device except those that need it.

In a yet further refinement, the final production system may be constructed by applying a selective delta process to a "kit-of-parts" comprising fragments of code and data that are stored in advance on the device -in this way, devices may be shipped with many possible final configurations, and each device may then be tailored to its individual final form using the delta that is appropriate for the case.

In all these cases, as will be clear to one of skill in the art, the content that is stored on a device before it is commissioned, and the unenabled content that is retained on the device after commissioning, remains in an encrypted form. This means that, during the production of the device, its stocking in a warehouse, and its delivery to the ultimate user, any confidential material in the content is safe from exposure. It further means that, even after the device has been manufactured with its pre-loaded content, stocked and delivered, any of the content to which the various parties are not authorised have access remains hidden.

In a brief description of a basic embodiment seen from an author or a confidential distributor point of view, a device is prepared so that it can eventually make use of stored content in its normal mode of operation. The device is provided with a base image that is typically designed to contain at least the low-level machine instructions sufficient to update the device content -that is, to access stored blocks of content and to receive, decrypt and apply a delta to those blocks.

The delta between that base image and an original first full set of content is computed -typically, the resulting delta comprises a large set of blocks of new material. In that case, if so desired, the instruction parts of the delta may be reduced to an efficient minimum. The blocks are then encrypted using one or more content encryption keys (CEK). At this point, the device content may be passed to a manufacturer or distributor who is not entitled to acquire the confidential material comprised in the content -that manufacturer or distributor is not provided with any CEKs, and thus the content in the encrypted blocks remains secret.

As a result of the above processing, the device is now provisioned with a set of content that, when decrypted and enabled, would render it operational at an initial level of function valid at the time of manufacture. This could be achieved simply by distributing the one or more CEKs to the devices using an in-field provisioning mechanism. Typically, however, a device may be some time in the stocking and distribution process before it is acquired by an ultimate user, and thus it will be in need of update at the time it is commissioned for first use.

To construct an update, which may be a commissioning update, the distributor or other party authorised to access the content first decrypts the encrypted blocks, thus setting the content to the initial level of function that was valid at the time of manufacture. The delta between the current level and the updated version is then computed. The delta and any CEKs for blocks that must be decrypted and accessed to process the delta are then provided to each target device using any appropriate in-field provisioning mechanism.

In a brief description of a basic embodiment seen from a device point of view, the device is initially provided with a hybrid content image. The hybrid content image contains both a base image of the content (such as a minimal firmware image that contains only the firmware update code), and a number of encrypted blocks. When the device first connects, in-field provisioning delivers a key for one or more encrypted blocks to the device. Device commissioning then consists of the device performing a first connect procedure, at which time the device receives a delta data structure and at least one content encryption key (CEK). This delta data structure has been computed against both the minimal client and the plaintext of at least one block that has been stored in encrypted form on the device. The device computes its new image by referencing both the minimal image and the result of decrypting the at least one encrypted block referenced by the delta. In this way, both the encrypted image decryption and the first-connect update are combined into a single step. This also eliminates the need for encryption of the first-connect delta data structure, as it consists of a delta against data that is not known by any third party.

When a subsequent update is received, the device has a current image, which may be in the first instance the image that was installed on its first commissioning as described above. The device receives a new delta data structure and at least one content encryption key (CEK). The device computes its new image by referencing both the current image and the result of decrypting the at least one encrypted block referenced by the delta.

Referring to Figure 1, an example of a deployment of a computer-implemented embodiment of the present technology is shown. Device 100 is shown in Figure 1 as being networked with at least Author 124 and Distributor 126, but is also operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing processing systems, environments, and/or configurations that may be suitable for use with device 100 include, but are not limited to, gateways, routers, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics (smartphones, smart watches, tablets), network PCs, minicomputer systems, mainframe computer systems, and distributed computing environments that include any of the above systems or devices.

Device 100, Author 124 and Distributor 126 may be described in the general context of computer systems and computer systems on a chip (SoC). Such computer systems comprise executable instructions, such as program modules, being executed by a computer processor. Generally, program modules may include: routines; programs; objects; components; logic; and data structures that perform tasks or implement abstract data types.

In one possible practical scenario, Author 124 may be a creator of content, such as firmware or software, for eventual deployment on network-attachable devices, such as device 100. In this example, the devices may be sold to the ultimate users by a party other than Author 124, for example, by a hardware vendor who cannot be exposed to any of the trade secrets embodied in the content created by the Author 124, for example a factory 134. Factory 134 may be a contract manufacturer factory, in which case it is beneficial to maintain the content in its encrypted form, so that the contract manufacturer has no access to any confidential material during the manufacturing process. In another example, devices may be shipped with content at a basic level of functionality, with the expectation that this level of functionality will be augmented in the field by installing or enabling additional features. Similarly, devices may be shipped with content in a standard form, and particular ones of the ultimate users may need the content to be customised for their individual needs. These needs are conventionally met by distributing complete replacements for device content, but this may present difficulties where, for example, network bandwidth is limited. In such cases, it would be more efficient to distribute more limited amounts of data, and this can be achieved by initially providing devices with modifiable content, and then distributing modifications in the form of deltas -that is, combinations of new data where absolutely necessary and modification instructions to adapt existing data where that is feasible.

Network 122 is for enabling communication between device 100 and other devices. The network 122 may use wireless communication, such as communication using wireless local area network (Wi-Fi), short range communication such as radio frequency communication (REID) or near field communication (NEC), or communications used in wireless technologies such as ZigBee, Thread, Bluetooth, Bluetooth LE, IPv6 over Low Power Wireless Standard (6L0WPAN) or Constrained Application Protocol (CoAP). Also, the network 122 may use a cellular network such as 3G or 4G. The network 122 may also use wired communication such as using a fibre optic or metal cable.

The communication circuitry 104 could also use two or more different forms of communication, such as several of the examples given above in combination.

In an embodiment, device 100 is connected through a network 122 comprising a wide area network (WAN) to Author 124 and Distributor 126. In 15 many embodiments the WAN is typically a wired network such as the Internet. In one embodiment, network 122 may comprise a cloud computing environment.

Device 100 comprises: processor 102; network adapter 104; and device memory 114.

Processor 102 is for loading machine instructions from device memory 114 and for performing machine operations in response to the machine instructions. Such machine operations include: performing an operation on a value in a register (for example arithmetical or logical operations); moving a value from a register to a memory location directly and vice versa; and conditional or non-conditional branching. A typical processor can perform many different machine operations. The machine instructions are written in a machine code language which is referred to as a low-level computer language. A computer program written in a high-level computer language (also known as source code) needs to be compiled to a machine code program (also known as object code) before it can be executed by the processor. Alternatively, a machine code program such as a virtual machine or an interpreter can interpret a high-level language (such as C) in terms of machine operations.

Network adapter 104 is for enabling communication between Device 100 and other network devices.

Device memory 114 comprises content in the form of base image 116 and blocks 118. Additionally, device memory 114 comprises key store 120 for storing content encryption keys.

Processor 102 comprises: processing circuitry 112, which in turn comprises cryptographic engine 130; firmware 110; operating system 108; and processor memory 106.

Processing circuitry 112 is for processing instructions and comprises: fetch circuitry for fetching instructions; decode circuitry for decoding instructions; and execution circuitry for executing instructions (not shown). Data and program code stored in device memory 114 are accessible to processing circuitry 112, including, for example, base image 116 and blocks 118.

Firmware 110 may comprise an operating kernel program for running every other process and environment. Firmware 110 can be embodied in circuitry or program instructions in processor memory 106.

Operating system 108 is the basic system for loading and executing program modules including device applications. Operating system 108 can be embodied in circuitry or program instructions in processor memory.

Processor memory 106 provides the execution environment for processor 102 and space for the program instructions for firmware 110, operating system 108 and other programs -one example of such other programs is the software-implemented cryptographic engine 130 that is suitable for decrypting encrypted content using received content encryption keys 120.

Author 124 and Distributor 126 are similarly operational with numerous other general purpose or special purpose computing system environments or configurations and are typically computer server systems, comprising similar basic computer components to Device 100 but these are not shown nor described. Distributor 126 comprises stored content comprising its copy of the base image 116A and its copies of blocks 118A. Distributor 126 further comprises cryptographic engine 128, which is operable to encrypt content using content encryption keys 132. Cryptographic engine 128 and cryptographic engine 130 may take any of the well-known forms of cryptographic arrangement -these are well known in the art, and need no further description here.

Turning to Figure 2, there is shown the first of a series of methods according to an embodiment of the present technology. In Figure 2, the method 200 is for preparing an electronic device that is operable to use stored content. At 202, the method 200 begins, and at 204, an initial image (which may be a base image operable to update content) is acquired. The initial image comprises a reduced image of the complete content, and may, in the case of firmware content, comprise a subset of the firmware functionality sufficient only to receive and process updates to a skeleton version of the content, all other subsets of the firmware content being established by a subsequent commissioning process in the form of an initial update.

At 206, a first delta data structure is generated. The first delta data structure may comprise data and instructions. For example, complete replacement data blocks may be included in the delta data structure, the new data blocks to be applied verbatim; similarly, modifications to existing data may be included in the delta data structure, the modifications comprising instructions for modifying existing data, with small elements of replacement data where these are necessary. At 208, at least one encrypted block derived from the initial image and the delta is generated using the corresponding content encryption key (CEK). At 210, the at least one encrypted block and the corresponding content encryption key (CEK) are provided for embedding in the device, and at 212, the process completes.

Turning to Figure 3, there is shown the second of the series of methods according to an embodiment of the present technology. In Figure 3, the method 300 is for generating an update for an electronic device operable to use stored content. The method begins at 302 and at 304, a CEK is acquired -typically by receiving the CEK over a network, but the CEK may also be acquired by accessing a data store, which may be local or remote. At 306, a first delta data structure is acquired. The first delta data structure is based on an initial image and at least one content data block, and comprises data, which may include instructions, to modify the initial image in accordance with said first content data block to produce a current image. At 308, the required content blocks for implementing the first delta are decrypted and the current image is computed. At 310, the content needed to bring the device up to a specified update level is acquired, and at 312, a second delta data structure is generated, where the second delta data structure comprises data to modify the current image in accordance with the updated content data block(s). At 314, the resultant second delta data structure is provided for distribution to appropriate devices.

In one embodiment, the second delta data structure may be provided only to selected devices in a population. In another embodiment, the second delta data structure may be provided to all the members of a population of devices, but with the CEK only being provided to those devices in the population that have authority to use the delta, or to access the content or features enabled by the delta.

Figure 4 shows the third of the series of methods according to an embodiment of the present technology. In Figure 4, the method 400 is for bringing a device up to a specified level of content. For example, the level of content may be a release or modification level of device firmware or software, or it may be an update level of date-sensitive data. In one embodiment, the level may refer to a level of functionality -for example, a device may be initially acquired with a limited set of functions that can be augmented later with additional, optional features.

The process begins at 402, and at 404, delta data structure and a CEK are acquired, typically by receiving them over a network, but equally conveniently in certain cases, by receiving them from a direct connection, such as a plug-in memory stick. At 406, an initial image and the encrypted content block(s) required by the delta are accessed. The initial image may be a base image, as described above, typically having a simple set of functions including update application. The content block(s) required by the delta are decrypted at 408 using the CEK. At 410, the delta is applied to the decrypted content block(s), and at 412, the results of the computation are applied to the device.

In an embodiment, the process of Figure 4 comprises an initial commissioning of a device, in which case, the initial image may comprise no more than the code necessary to perform the process of receiving a delta, accessing a CEK, decrypting encrypted content blocks, applying the delta and storing the resulting content. In another embodiment, the process of Figure 4 comprises an update applied to a usable device in which there is already an installed image at a previous level.

In one possible embodiment, some blocks may comprise add-on features available by means of a subscription CEK, so that only those ultimate users who have subscribed to the additional features can decrypt the relevant content blocks and therefore have access to the additional features.

In a further refinement, the set of encrypted content blocks may comprise a "kit-of-parts", whereby the entire content of a usable device may be assembled from the parts according to the instructions in the delta data structure and according to the content encryption keys that are supplied. In this way, all devices of a production run may be equipped with all the possible permutations of content at production time, and different devices from the run may be made usable in different ways, depending upon the delta data structure and content encryption keys that are supplied to them.

Turning to Figure 5, there is shown one example of a data flow 500 for device preparation and firmware commissioning or first attachment update according to an embodiment of the present technology. In Figures 5 and 6, the encryption discussed is content encryption using content encryption keys, such as CEK 514. It will be clear to one of ordinary skill in the art that the data flows (shown as arrows) may themselves be secured using any of the many available forms of channel and session encryption -this lies outside the scope of the present discussion.

In Figures 5 and 6, parts of the data flows may be under the control of different actors in the system, as described above -OEM, contract manufacturer etc. In embodiments, parts of the data flows may be combined in different arrangements under the control of single actors, or split among separate entities within the overall system. For example, BSI 502, FW1 504 and FW2 506 may all be supplied by a single content author (e.g., an author of original and updated firmware for a device), or they may be supplied by several authors -e.g., in the case where devices with original firmware BSI 502 and FW1 504 were supplied by an original device supplier, but maintenance of the firmware with updates FW2 506 has been outsourced to a different entity. For simplicity, only two "zones" are shown by dotted-line enclosures. The upper enclosure represents the data flows at the providers (OEM, contract manufacturer, firmware author, etc.), and the lower enclosure shows the data flows at the client.

In Figure 5, firmware update FW1 is applied to basic system image BSI 502 using delta technique 508, generating content update 510. As discussed above, the content update 510 is derived using a differencing or delta technique to produce data and instructions for applying the data. The non-essential portions of content update 510 are discarded (typically by a programmed filter mechanism) to produce the delta reference blocks DRB. The delta reference blocks are encrypted using CEK 514 to produce encrypted delta reference blocks, which are stored together with basic system image BSI as a device image 516.

When a commissioning firmware update FW2 506 is required for use (typically when devices first access a network), basic system image BSI 502, encrypted delta reference blocks EDRB (which require decryption 520 using CEK 514 before use to produce delta reference blocks DRB), and firmware update FW2 506 are provided to delta technique 518 to generate commissioning update delta D2 522.

When the client device (in the flows as shown in the lower dotted-line enclosure) needs to be brought up to the FW2 version of content, encrypted delta reference blocks EDRB are decrypted 524 using CEK 514 to produce delta reference blocks DRB. Basic system image BSI 502, the decrypted delta reference blocks and commissioning update delta D2 are combined 526 to produce the production image at the FW2 version or level.

Basic system image BSI 502 is thus supplied as a "bare-bones" image merely to make the recipient devices operable at a basic level of function, leaving firmware updates to bring the devices to a production operational level. Basic system image BSI 502 may contain just enough functionality to boot up and perform a handshake with a network and then to receive, store and install updates. The installing of production functions may then be left to firmware updates. This implementation may be useful, for example, when it is known that devices will take some time to pass through a supply and stockholding chain, so that the firmware that will eventually be required may have passed through several levels of update before the device is deployed in an end-user installation. In such a case, the firmware update may comprise a "roll-up" update to bring the recipient devices up to a level that incorporates a number of intervening updates.

Figure 6 shows one example of a data flow for feature enablement according to an embodiment of the present technology. Feature enablement is the term used for a scenario in which a device may have stored on it the code and data required to implement additional functions over and above those of the ordinary production system, but that code and data is locked in some manner so that only those who are authorised can unlock the functionality and use it in production. Typically, feature enablement is used so that a single version of content can be shipped to many users with different requirements -some users may be content with a simple, less expensive "vanilla-flavour" level of functionality, while others may need a more expensive "chocolate-nut-sundae" level of functionality. A single version of content is shipped to both types of user, and those who need the more expensive "chocolate-nut-sundae" level of functionality can then subscribe to and receive one or more extra keys to enable the extra functions.

In Figure 6, the process of applying FW1 504 to basic system image BSI 502 using delta technique 508, generating delta reference blocks 510, encrypting delta reference blocks 510 to produce encrypted delta reference blocks EDRB, and storing EDRB and BSI at the client as device image 516 is as in Figure 5. Unlike Figure 5, however, it is desired to include in the shipped content some additional function FE 602. When potential feature enablement of additional FE 602 is required, FE 602 is treated as input with firmware update FW1 to delta 604, giving feature delta reference blocks FBRB alongside the original delta reference blocks DRB in content update 510. The feature delta reference blocks FDRB 606 are encrypted using additional CEK 608 to give encrypted feature delta reference blocks EFDRB. Typically, in a real-world scenario, the additional features may be divided up and encrypted using a plurality of additional CEKs 608. Each additional CEK 608 may then be supplied only to qualifying users who have, for example, subscribed to the additional functionality by, for example, paying an additional fee. Encrypted delta reference blocks are then treated the same as the original encrypted blocks and stored with them and with basic system image BSI as device image 516.

When a firmware update FW2 506 is required for use, basic system image BSI 502, encrypted delta reference blocks EDRB (which require decryption 520 using CEK 514 before use to produce delta reference blocks DRB), encrypted feature delta reference blocks EFDRB (which require decryption 520 using additional CEK 608 before use to produce delta reference blocks DRB) and firmware update FW2 506 are provided to delta technique 612 to generate an FW2 update delta D2 614.

When the client device (in the flows as shown in the lower dotted-line enclosure) needs to be brought up to the FW2 version of content, encrypted delta reference blocks EDRB are decrypted 524 using CEK 514 to produce delta reference blocks DRB. Basic system image BSI, the decrypted delta reference blocks and commissioning update delta D2 are combined 616 to produce the production image at the FW2 version or level. When it is desired to enable the relevant feature or features additional CEK 608 is used to decrypt the encrypted feature delta reference blocks EFDRB, which are applied to enable the additional feature or features from FE 602.

It will be clear to one of ordinary skill in the art that the feature enablement method described here may be broadly applied to, for example, provide a plurality of variants in the form of a kit of parts, whereby users may select from the kit of parts using plural CEKs to enable selected portions of software or firmware and thus assemble a tailored variant of the software or firmware according to local requirements.

Taking each of the data flows of the various embodiments shown in Figure 6 in isolation for simplicity. Figure 7, 8 and 9 show the three stages -factory image preparation, update and feature enablement.

In Figure 7, a portion of the flow of Figure 6 is shown by which deltas are created for version 1 of the firmware (FW1 504) and an optional feature (FE 602). The deltas are then filtered to retain only the required delta reference blocks DRB 511 and FDRB 605, which are then encrypted as EDRB 512 and EFDRB 606. The outputs from this flow are a factory image of the system 516 comprising the encrypted delta reference blocks EDRB 512 and the encrypted feature delta reference blocks EFDRB 606, along with the corresponding encryption keys, respectively shown as CEK 514 and FCEK 608.

In Figure 8, a second version of the firmware FW2 is processed to create a delta D2 with the basic system image BSI 502 and the delta reference blocks DRB 511, and the delta D2 is used to patch the factory image of Figure 7 to create a system image with the FW2 version of the firmware and the unchanged encrypted feature delta reference blocks EDFRB 606 as in Figure 7.

In Figure 9, when a version 2 of feature enablement is required on the FW2 level of the firmware, a version 2 delta is created with the feature FEv2, firmware FW2 and the feature delta reference blocks FDRB 605. The system that requires this feature to be enabled on its FW2 firmware then receives the necessary encryption key FCEK 608 for FEv2. Th system uses the FCEK 608 to decrypt the encrypted feature delta reference blocks EFDRB 606, and the resultant feature delta reference blocks FDRB 605 are used to patch the FW2 level system image to produce a system image with the FEv2 feature enabled.

There is thus provided a technology adapted to controlling the integrity of content, particularly encoded content, that is to be transmitted to receiving electronic devices over a network, especially when untrusted intermediaries may be involved in the transmission process, and whereby the final production level of the devices and the types of features installed need not be determined at the outset.

As will be appreciated by one skilled in the art, the present technique may be embodied as a system, method or computer program product. Accordingly, the present technique may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Where the word "component" is used, it will be understood by one of ordinary skill in the art to refer to any portion of any of the above embodiments.

Furthermore, the present technique may take the form of a computer program product tangibly embodied in a non-transient computer readable medium having computer readable program code embodied thereon. A computer readable medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

Computer program code for carrying out operations of the present techniques may be written in any combination of one or more programming languages, including object-oriented programming languages and conventional procedural programming languages.

For example, program code for carrying out operations of the present techniques may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, code for setting up or controlling an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array), or code for a hardware description language such as VerilogTM or VHDL (Very high speed integrated circuit Hardware Description Language).

The program code may execute entirely on the user's computer, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network. Code components may be embodied as procedures, methods or the like, and may comprise subcomponents which may take the form of instructions or sequences of instructions at any of the levels of abstraction, from the direct machine instructions of a native instruction-set to high-level compiled or interpreted language constructs.

It will also be clear to one of skill in the art that all or part of a logical method according to embodiments of the present techniques may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the method, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored using fixed carrier media.

In one alternative, an embodiment of the present techniques may be realized in the form of a computer implemented method of deploying a service comprising steps of deploying computer program code operable to, when deployed into a computer infrastructure or network and executed thereon, cause said computer system or network to perform all the steps of the method.

In a further alternative, an embodiment of the present technique may be realized in the form of a data carrier having functional data thereon, said functional data comprising functional computer data structures to, when loaded into a computer system or network and operated upon thereby, enable said computer system to perform all the steps of the method.

It will be clear to one skilled in the art that many improvements and 20 modifications can be made to the foregoing exemplary embodiments without departing from the scope of the present technique.

Claims (13)

1. CLAIMS1. A machine-implemented method of preparing an electronic device operable to use stored content, comprising: generating a first delta data structure based on an initial image and at least one first content data block, said first delta data structure comprising data to modify said initial image in accordance with said first content data block; encrypting at least one resultant content data block affected by said first delta data structure to generate at least one encrypted block using at least one corresponding content encryption key; and providing said initial image and said at least one encrypted block for embedding as stored content on said electronic device.
2. 2. The machine-implemented method according to claim 1, said initial image comprising a base image operable to install content on said electronic device.
3. 3. The machine-implemented method according to claim 1 or claim 2, said first delta data structure being operable to augment said initial image in accordance with said resultant content data block.
4. 4. The machine-implemented method according to any preceding claim, said first delta data structure comprising data operable to make available an installable feature of said stored content.
5. 5. The machine-implemented method according to any preceding claim, said first delta data structure comprising processing instructions.
6. 6. The machine-implemented method according to any preceding claim, said stored content comprising firmware.
7. 7. A machine-implemented method of generating an update for an electronic device operable to use stored content, comprising: acquiring a first delta data structure based on an initial image and at least one first content data block, said first delta data structure comprising data to modify said initial image in accordance with said first content data block to produce a current image; decrypting at least one encrypted block required by said first delta data structure using at least one content encryption key to produce at least a first decrypted block; generating a second delta data structure based on said initial image, said at least a first decrypted block and at least one second content data block, said second delta data structure comprising data to modify said current image in accordance with said second content data block; and providing said second delta data structure for application on said electronic device.
8. 8. The machine-implemented method according to claim 7, at least one of said first delta data structure and said second delta data structure being operable to augment said current image in accordance with said first content data block.
9. 9. The machine-implemented method according to claim 7 or claim 8, at least one of said first delta data structure and said second delta data structure data operable to make available an installable feature of said stored content.
10. 10. The machine-implemented method according to any of claims 7 to 9, said generating a second delta data structure based on said current image, said decrypted first delta data structure and at least one second content data block comprising redacting instructions from said decrypted first delta data structure where said instructions are not needed in said second delta data structure.
11. 11. The machine-implemented method according to any of claims 7 to 10, said first delta data structure comprising processing instructions.
12. 12. The machine-implemented method according to any of claims 7 to 11, said stored content comprising firmware.
13. 13. A machine implemented method of bringing an electronic device operable to use stored content to a specified level of said content, comprising: 14. 15. 16. 17.receiving at said device a delta data structure and at least one content encryption key; accessing an image of content previously embedded as stored content on said device, said image of content comprising at least a base image of content and at least one encrypted block; decrypting said at least one encrypted block using said content encryption key to recover a decrypted block; and applying said delta data structure using said decrypted block to modify said image of content to said specified level of said content.The machine-implemented method according to claim 13, said first delta data structure comprising processing instructions.The machine-implemented method according to claim 13 or claim 14, said stored content comprising firmware.An electronic device comprising logic operable to perform the method of any preceding claim.A computer program comprising computer program code to, when loaded into a computer system and executed thereon, perform the method according to any of claims 1 to 15.