Claims:1. A method for securing a batch of user devices (102) in a managed network (100), comprising:
receiving a common code verification public key and a first digital signature at a user device (102a) in the batch of user devices (102), wherein the first digital signature is generated by a server (106) in the managed network (100) by signing the common code verification public key using a device private key, wherein the device private key and a corresponding device public key are generated by the server (106) using a random seed and a common seed, wherein the common seed is generated for the batch of user devices (102) and the random seed is generated for the user device (102a) by the server (106), and wherein the random seed and the device public key are embedded in a first memory (208) associated with the user device (102a);
storing the common code verification public key and the first digital signature in a second memory (210) associated with the user device (102a);
receiving a software code and a second digital signature at the user device (102a), wherein the second digital signature is generated by signing the software code using a common code signing private key by the server (106), and wherein the common code signing private key and the common code verification public key are generated for the batch of user devices (102) by the server (106);
verifying the first digital signature using the device public key;
verifying the second digital signature using the common code verification public key stored in the second memory (210) upon verification of the first digital signature; and
replacing the common code verification public key stored in the second memory (210) with a new common code verification public key upon detecting a specified condition.

2. The method as claimed in claim 1, wherein replacing the common code verification public key in the second memory (210) associated with the user device (102a) comprises:
invalidating the common code verification public key stored in the second memory (210) associated with the user device (102a) based on one or more instructions received from the server (106) upon detecting the specified condition;
transmitting the random seed embedded in the first memory (208) associated with the user device (102a) to the server (106);
receiving the new common code verification public key and a third digital signature at the user device (102a), wherein the third digital signature is generated by the server (106) by signing the new common code verification public key using the device private key, and wherein the device private key is regenerated by the server (106) using the common seed and the random seed received from the user device (102a);
storing the new common code verification public key and the third digital signature in the second memory (210) associated with the user device (102a); and
verifying the third digital signature using the device public key.

3. The method as claimed in claim 2, further comprising:
receiving the software code and a fourth digital signature at the user device (102a), wherein the fourth digital signature is generated by the server (106) by signing the software code using a new common code signing private key, and wherein the new common code signing private key is generated by the server (106) upon detecting the specified condition; and
verifying the fourth digital signature using the new common code verification public key stored in the second memory (210) associated with the user device (102a).

4. The method as claimed in claim 1, wherein detecting the specified condition comprises at least one of determining that the common code verification public key is compromised, determining that a specified time interval following generation of the common code verification public key has lapsed, and determining that the software code in the user device (102a) needs to be updated.

5. The method as claimed in claim 1, wherein the first memory (208) is a one-time programmable memory and the second memory (210) is a re-writable memory.

6. A method for securing a batch of user devices (102) in a managed network (100), comprising:
generating a common code signing private key, a common code verification public key, and a common seed for the batch of user devices (102);
generating a device private key, a device public key, and a random seed corresponding to a user device (102a) in the batch of user devices (102), wherein the device private key and the device public key are generated using the common seed and the random seed generated by the server (106);
embedding the device public key and the random seed in a first memory (208) associated with the user device (102a);
generating a first digital signature by signing the common code verification public key with the device private key;
transmitting the common code verification public key and the first digital signature to the user device (102a), wherein the user device (102a) stores the common code verification public key and the first digital signature in a second memory (210) associated with the user device (102a), and wherein the first digital signature is verified by the user device (102a) using the device public key embedded in the first memory (208) associated with the user device (102a);
generating a second digital signature by signing a software code with the common code signing private key;
transmitting the software code and the second digital signature to the user device (102a), wherein the second digital signature is verified in the user device (102a) using the common code verification public key stored in the second memory (210) associated with the user device (102a) upon verification of the first digital signature; and
replacing the common code verification key stored in the second memory (210) associated with the user device (102a) with a new common code verification public key upon detecting a specified condition.

7. The method as claimed in claim 6, wherein replacing the common code verification public key at the user device (102a) comprises:
generating the new common code verification public key and a new common code signing private key for the batch of user devices (102);
transmitting one or more instructions to the user device (102a) to invalidate the common code verification public key stored in the second memory (210) associated with the user device (102a) upon detecting the specified condition;
receiving the random seed from the user device (102a) in response to the instructions;
regenerating the device private key corresponding to the user device (102a) using the common seed and the random seed;
generating a third digital signature by signing the new common code verification public key using the device private key; and
transmitting the new common code verification public key and the third digital signature to the user device (102a), wherein the third digital signature is verified in the user device (102a) using device public key embedded in the first memory (208) associated with the user device (102a).

8. The method as claimed in claim 7, further comprising:
generating a fourth digital signature by signing the software code with the new common code signing private key; and
transmitting the software code and the fourth digital signature to the user device (102a), wherein the fourth digital signature is verified in the user device (102a) using the new common code verification public key stored in the second memory (210) associated with the user device (102a).

9. The method as claimed in claim 6, wherein detecting the specified condition comprises at least one of determining that the common code verification public key is compromised, determining that a specified time interval following generation of the common code verification public key has lapsed, and determining that the software code in the user device (102a) needs to be updated.

10. The method as claimed in claim 6, wherein the first memory (208) is a one-time programmable memory and the second memory (210) is a re-writable memory.

11. A managed network (100), comprising:
a server (106) in communication with a batch of user devices (102) operating in the managed network (100), wherein the server (106) is configured to:
generate a common code signing private key, a common code verification public key, and a common seed for the batch of user devices (102);
generate a device private key, a device public key, and a random seed corresponding to a user device (102a) in the batch of user devices (102), wherein the device private key and the device public key are generated using the common seed and the random seed generated by the server (106);
embed the device public key and the random seed in a first memory (208) associated with the user device (102a);
generate a first digital signature by signing the common code verification public key with the device private key;
transmit the common code verification public key and the first digital signature to the user device (102a), wherein the user device (102a) stores the common code verification public key and the first digital signature in a second memory (210) associated with the user device (102a), and wherein the first digital signature is verified by the user device (102a) using the device public key embedded in the first memory (208) associated with the user device (102a);
generate a second digital signature by signing a software code with the common code signing private key;
transmit the software code and the second digital signature to the user device (102a), wherein the second digital signature is verified in the user device (102a) using the common code verification public key stored in the second memory (210) associated with the user device (102a) upon verification of the first digital signature; and
replace the common code verification key stored in the second memory (210) associated with the user device (102a) with a new common code verification public key upon detecting a specified condition.

12. The managed network (100) as claimed in claim 11, wherein the server (106) is further configured to:
generate the new common code verification public key and a new common code signing private key for the batch of user devices (102);
transmit one or more instructions to the user device (102a) to invalidate the common code verification public key stored in the second memory (210) associated with the user device (102a) upon detecting the specified condition;
receive the random seed from the user device (102a) in response to the instructions;
regenerate the device private key corresponding to the user device (102a) using the common seed and the random seed;
generate a third digital signature by signing the new common code verification public key using the device private key;
transmit the new common code verification public key and the third digital signature to the user device (102a), wherein the third digital signature is verified in the user device (102a) using device public key embedded in the first memory (208) associated with the user device (102a).
generate a fourth digital signature by signing the software code with the new common code signing private key; and
transmit the software code and the fourth digital signature to the user device (102a), wherein the fourth digital signature is verified in the user device (102a) using the new common code verification public key stored in the second memory (210) associated with the user device (102a).

13. The managed network (100) as claimed in claim 11, wherein the detection of the specified condition comprises at least one of determining that the common code verification public key is compromised and determining that a specified time interval following generation of the common code verification public key has lapsed.

14. A user device (102a) in a batch of user devices (102) that are configured to operate in a managed network (100), the user device (102a) comprising:
a first memory (208), wherein the first memory (208) is a one-time programmable memory;
a second memory (210), wherein the second memory (210) is a re-writable memory; and
wherein the user device (102a) is configured to:
receive a common code verification public key and a first digital signature at a user device (102a) in the batch of user devices (102), wherein the first digital signature is generated by a server (106) in the managed network (100) by signing the common code verification public key using a device private key, wherein the device private key and a corresponding device public key are generated by the server (106) using a random seed and a common seed, wherein the common seed is generated for the batch of user devices (102) and the random seed is generated for the user device (102a) by the server (106), and wherein the random seed and the device public key are embedded in a first memory (208) associated with the user device (102a);
store the common code verification public key and the first digital signature in a second memory (210) associated with the user device (102a);
receive a software code and a second digital signature at the user device (102a), wherein the second digital signature is generated by signing the software code using a common code signing private key by the server (106), and wherein the common code signing private key and the common code verification public key are generated for the batch of user devices (102) by the server (106);
verify the first digital signature using the device public key;
verify the second digital signature using the common code verification public key stored in the second memory (210) upon verification of the first digital signature; and
replace the common code verification public key stored in the second memory (210) with a new common code verification public key upon detecting a specified condition.

15. The user device (102a) as claimed in claim 14, wherein the user device (102a) is further configured to:
invalidate the common code verification public key stored in the second memory (210) associated with the user device (102a) based on one or more instructions received from the server (106) upon detecting the specified condition;
transmit the random seed embedded in the first memory (208) associated with the user device (102a) to the server (106);
receive the new common code verification public key and a third digital signature at the user device (102a), wherein the third digital signature is generated by the server (106) by signing the new common code verification public key using the device private key, and wherein the device private key is regenerated by the server (106) using the common seed and the random seed received from the user device (102a);
store the new common code verification public key and the third digital signature in the second memory (210) associated with the user device (102a); and
verify the third digital signature using the device public key.
, Description:The following specification particularly describes the invention and the manner in which it is to be performed.

MANAGED NETWORK AND METHOD TO SECURE ENDPOINT DEVICES IN THE MANAGED NETWORK

FIELD OF THE INVENTION

[0001] The present specification relates generally to the field of computer networks, and particularly to a managed network and a method to ensure improved network security for endpoint devices in the managed network.

DESCRIPTION OF RELATED ART

[0002] Advancement and proliferation of computer networks have given rise to multiple interconnected subnetworks of computer systems distributed across the globe. A managed network is one such type of an interconnected subnetwork that is built, secured, and managed by a service provider or a service operator. Various online services such as digital content distribution, internet protocol television (IPTV), firewall services, intrusion detection services, cloud computing services, cloud storage services, and the like are deployed using the managed networks by service providers and service operators.
[0003] The managed networks typically include multiple servers and multiple endpoint devices (hereinafter referred to as “user devices”). Examples of the user devices are mobile phones, laptops, desktops, set-top boxes, routers, modems, gateways, and the like. The user devices communicate with the servers by adhering to designated communication protocols. The servers authenticate, manage, and provide selected online services to the user devices. Particularly, the servers provide the user devices with software code to facilitate a subscription to various online services by the user devices. The user devices execute the software code to access these online services. Therefore, it becomes essential to verify that the software code is authentic, has not been tampered with, and has been received from a legitimate source prior to its installation on the user devices. Ensuring that the software code is received from a legitimate and authorized source typically secures the user devices against a variety of malicious attacks including counterfeit online services, hacks, and viruses.
[0004] Conventionally, managed networks employ digital signatures that are shared with the user devices to allow them to determine authenticity and integrity of the software code. The digital signatures may be generated at the server using public key signature algorithms such as Rivest-Shamir-Adleman (RSA) public key cipher, digital signature algorithm (DSA), and the like. In certain managed networks, the digital signatures may be generated and verified using asymmetric cryptography. In asymmetric cryptography, a pair of cryptographic keys, including code signing and code verification keys, is used to sign and verify the software code. In an existing technique, the code signing key is a private key and the code verification key is a public key. At the server, the software code is signed by the code signing key to generate a corresponding first digital signature. Further, the first digital signature, the code verification key, and the software code are transmitted to the user devices. The first digital signature is subsequently verified at the user devices using the code verification key to ensure that the software code is received from a genuine and authorized service provider. The process of code signing and verification is well known in the art. The software code that is signed by the code signing key may only be verified by the code verification key that belongs to the same pair of cryptographic keys as the code signing key. Thus, use of the digital signature aids the user devices in verifying the authenticity and integrity of the software code distributed by the server, thereby securing the user devices against unauthorized access.
[0005] Typically, the user devices include a one-time programmable (OTP) memory to store the code verification key used to verify the digital signature. As the OTP memory is programmable only once, the code verification key is stored in the OTP memory only once. Subsequently, the code verification key can only be read from the OTP memory. The code verification key residing in the OTP memory forms a root of trust in the user devices. When a user device receives the software code along with the first digital signature from the server, the user device employs the code verification key residing in the OTP to verify the software code prior to its installation in the user device.
[0006] Ensuring authenticity and integrity of the code verification keys and code signing keys, therefore, is key to securing the user devices. Several techniques to manage the code verification keys and the code signing keys are known in the art. In one such technique, a common code verification and a common code signing key pair is generated for all the user devices. The common code verification key is fused in the OTP memories of all the user devices. However, in an event of a compromise of the common code signing key, the common code verification key and the common code signing key need to be invalidated to prevent unauthorized access to the user devices. As the common code verification key is fused in the OTP memory, in case of a compromise, either the OTP memories of all the user devices, or all the user devices in entirety, need to be replaced. Such a large scale replacement of the user devices is an undesirable, expensive, and time consuming process.
[0007] In an alternate technique, unique code signing and code verification key pairs are generated for each user device. Thus, the risk of a compromise of the unique code signing key is restricted only to the corresponding user device. However, even in such a scenario, the affected user device needs to be replaced in case of a compromise, leading to unnecessary replacement and logistic costs. Further, the software code for each user device has to be signed with the corresponding unique code signing key before transmitting the software code thereto. Thus, the server has to perform a redundant task of generating, maintaining, and/or signing the software code with different code signing keys, thereby increasing the processing load and time of the server. Moreover, the server has to maintain a dedicated database to store the unique code signing and code verification keys corresponding to each of the user devices.
[0008] In light of the foregoing discussion, there exists a need for a system and method that ensures the security of the user devices by verifying the authenticity and integrity of software codes distributed by the server to the user devices, and that overcomes the aforementioned drawbacks of the existing art.

SUMMARY

[0009] An object of the present disclosure is to provide a managed network and a user device operating in the managed network that are configured to ensure that a software code provided by an online service provider is authentic. The managed network includes a server and a batch of user devices (also referred to herein as the endpoint devices) including the user device. The server, in turn, includes a provisioning system and a code signing system for facilitating provisioning of the user devices to aid in authentication of the software code provided to each user device. Each user device in the batch of user devices, in turn, includes an OTP memory and a re-writable memory that are used to store trust values and other information.
[0010] In one embodiment, the code signing system generates common code signing private and common code verification public keys for use in the authentication of the software code. Further, the provisioning system generates a user device private key and a user device public key corresponding to each user device. The user device private and public keys are generated using a common seed and a random seed. The server generates the common seed for each batch of user devices and the random seed for each user device in the batch of user devices. The provisioning system embeds the user device public key and the random seed in corresponding OTP memory of each user device. Additionally, the provisioning system generates a first digital signature for each user device by signing the common code verification public key with the user device private key. The provisioning system subsequently transmits the first digital signature and the common code verification public key to the user device. The user device stores the first digital signature and the common code verification public key in the re-writable memory. Further, the code signing system generates a second digital signature by signing the software code with the common code signing private key. The code signing system then transmits the second digital signature and the software code to the user device. The user device receives the second digital signature and the software code. The user device verifies the first digital signature corresponding to the common code verification public key stored in the re-writable memory using the user device public key. Further, the user device verifies the second digital signature corresponding to the software code using the common code verification public key upon verification of the first digital signature.
[0011] Another object of the present disclosure is to replace the common code verification public key stored in the re-writable memory associated with the user device upon detecting a specified condition. The code signing system generates a new common code verification public key and a new common code signing private key. The provisioning system receives the new common code verification public key. Additionally, the server transmits one or more instructions to the user device to invalidate the common code verification public key. The user device invalidates the common code verification public key and transmits the random seed and the batch information to the provisioning system in response to the instructions. The provisioning system regenerates the user device private key and the user device public key using the random seed and the common seed, which is stored in the server. Further, the provisioning system generates a third digital signature by signing the new common code verification public key with the regenerated user device private key. The provisioning system transmits the third digital signature and the new common code verification public key to the user device. The user device receives and stores the third digital signature and the new common code verification public key in the re-writable memory. The user device verifies the new common code verification public key using the regenerated user device public key, and upon successful verification, replaces the common code verification public key with the new common code verification public key.
[0012] A further object of the present disclosure is to provide a method for securing a batch of user devices in a managed network. The method includes generating a common code signing private key, a common code verification public key, and a common seed for the batch of user devices. The method further includes generating a device private key, a device public key, and a random seed corresponding to a user device in the batch of user devices. The device private key and the device public key are generated using the common seed and the random seed generated by the server. Further, the method includes embedding the device public key and the random seed in a first memory associated with the user device and generating a first digital signature by signing the common code verification public key with the device private key. Additionally, the method includes transmitting the common code verification public key and the first digital signature to the user device. The user device stores the common code verification public key and the first digital signature in a second memory associated with the user device. The first digital signature is verified by the user device using the device public key embedded in the first memory associated with the user device. Moreover, the method includes generating a second digital signature by signing a software code with the common code signing private key. The method further includes transmitting the software code and the second digital signature to the user device. The second digital signature is verified in the user device using the common code verification public key stored in the second memory associated with the user device upon verification of the first digital signature. Furthermore, the method includes replacing the common code verification key stored in the second memory associated with the user device with a new common code verification public key upon detecting a specified condition.
[0013] Thus, the managed network and associated protocols provide enhanced security for endpoint devices through use of multi-level verifications using different key pairs, while enabling the recycling of the common code verification public key. Recycling of the common verification public key allows for quick mitigation of any compromise of the common code signing private key without needing to replace a large number of affected user devices. Further, the need of unique code signing and verification key pair for each user device and a dedicated database to store the unique code signing and verification key pairs for all the user devices is eliminated, thereby reducing overhead of the server.

BRIEF DESCRIPTION OF DRAWINGS

[0014] The various features, aspects, and advantages of the present network and method are set forth with particularity in the appended claims. Embodiments of the present network and method will herein after be described in conjunction with the appended drawings provided to illustrate, and not to limit, the scope of the claims, wherein like designations denote like elements, and in which:
[0015] FIG. 1 illustrates a schematic block diagram of a managed network configured to secure a plurality of user devices, according to an embodiment disclosed herein;
[0016] FIG. 2 illustrates a schematic block diagram of an exemplary server and a first batch of exemplary user devices operating in the managed network of FIG. 1;
[0017] FIG. 3 is a flowchart illustrating an exemplary method for securing the user devices in the managed network of FIG. 1; and
[0018] FIG. 4 is a flowchart illustrating an exemplary method for recycling code signing and verification keys upon detecting a specified condition to secure the user devices in the managed network of FIG. 1.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] The following description presents exemplary embodiments of a managed network and a method for securing a plurality of user devices in the managed network. Particularly, the embodiments described herein establish a two-level root of trust for the user devices in order to determine authenticity and integrity of software code received over the managed network. Additionally, the embodiments disclosed herein present a novel method that allows for rapid and efficient recycling of trust values relied upon by the user devices, thus significantly mitigating risks resulting from a compromise of any of these trust values.
[0020] It may be noted that the components and the method steps have been represented in the present description to show specific details that are pertinent for an understanding of the embodiments described herein. Furthermore, the components and the method steps have been represented so as not to obscure the disclosure with details that will be readily apparent to those with ordinary skill in the art having the benefit of the description herein.
[0021] It may further be noted that the singular forms “a,” “an,” and “the,” as used in the specification and claims, include plural references unless the context clearly dictates otherwise. For example, the term “an article” may include a plurality of articles unless the context clearly dictates otherwise.
[0022] Additionally, those with ordinary skill in the art will appreciate that the elements in the figures are illustrated for simplicity and clarity, and are not necessarily drawn to scale. For example, the dimensions of some of the elements in the FIGs. 1-4 may be exaggerated, relative to other elements, in order to improve the understanding of the embodiments described herein.
[0023] Further, there may be additional components described in the foregoing application that are not depicted in one of the drawings. In the event of such component being described, but not depicted in a drawing, the absence of such a drawing should not be considered as an omission of the component from the specification.
[0024] It may be noted that the embodiments described herein are merely exemplary and can be embodied in various forms in alternative implementations. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the embodiments described herein in virtually any appropriately detailed structure. Further, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the embodiments of the managed network and the present method with reference to FIGs. 1-4.
[0025] Particularly, FIG. 1 illustrates a schematic block diagram of an embodiment of a managed network 100 for securing a first and second batch of user devices 102 and 104 operational in the managed network 100. In one embodiment, the managed network 100 is a platform that facilitates a distribution of online services to the first and the second batch of user devices 102 and 104. Examples of the managed network 100 include content delivery networks such as music delivery networks, video streaming networks, software delivery networks, internet protocol television networks, and the like. Further, the managed network 100 may include networks that provide cloud services such as cloud computing platforms, cloud storage services, and the like. Additionally, the managed network 100 may include security networks that provide services such as intrusion detection services, virus protection services, firewall services, and the like for securing the user devices 102 and 104.
[0026] In certain embodiments, the first and second batches of user devices 102 and 104, for example, include a set-top box (STB), a mobile device, a smartphone, a tablet computer, a laptop computer, a desktop computer, and the like. In one embodiment, the managed network 100 interacts with one or more of the first and second batches of user devices 102 and 104 to allow users to access selected online services only in a specified and authorized manner.
[0027] In the embodiment depicted in FIG. 1, the first batch of user devices 102 includes first, second, third, and fourth user devices 102a, 102b, 102c, and 102d (also referred to as ‘user device 102’). Similarly, the second batch of user devices 104 includes first, second, third, and fourth user devices 104a, 104b, 104c, and 104d (also referred to as ‘user device 104’). Although, FIG. 1 depicts two batches of user devices 102 and 104 having four user devices each, alternative embodiments may include less than or more than two batches having one or more user devices that may be secured using the managed network 100 and the method presented herein.
[0028] To that end, in one embodiment, the managed network 100 includes at least one server 106 in communication with the first and second batch of user devices 102 and 104. In certain embodiments, the server 106 corresponds to a computing device configured as a headend server, for example, in a private corporate network, a social networking website, an e-mail service provider, a video streaming service, an audio streaming service, and the like. Further, the server 106 is communicatively coupled to the first and second batches of user devices 102 and 104 over one or more communications links 108 to send and receive data related to the online services.
[0029] Accordingly, the server 106, for example, includes one or more general purpose processors, custom processing units, graphical processing units, microprocessors, microcontrollers, field programmable gate arrays, application specific integrated circuits, digital gates, transistors, and/or other suitable processing devices. Further, the communications links 108, for example, include links connected to a public network, a private network, a local area network (LAN), a wide area network (WAN), or the Internet. Certain exemplary interactions between the server 106 and the user devices 102 over the communications links 108 that are designed to secure the user devices 102 and 104 against unauthorized access will be described in greater detail with reference to FIG. 2.
[0030] FIG. 2 illustrates a schematic block diagram depicting exemplary interactions between the server 106 and the first batch of user devices 102 in the managed network 100. In one embodiment, the server 106 is managed by a service provider to provide one or more online services to the first batch of user devices 102. In particular, the server 106 distributes a software code 206 to the first batch of user devices 102 that configures the user devices 102 to request for and securely access the online services provided by the server 106.
[0031] For clarity, the managed network 100 and the user devices 102 are described herein with reference to a digital cable television network and multiple set top boxes (STBs), respectively. However, it may be noted that embodiments of the managed network and the present method may similarly be applied to secure endpoint devices in other managed networks. Additionally, the present embodiment may similarly apply to interactions between the server 106 and the second batch of user devices 104 for securing the second batch of user devices 104.
[0032] In one embodiment, the service provider maintains the managed network 100 to provide audio-video content and data services to the user devices 102 installed in user premises. Generally, the service provider delivers desired multimedia content to the user devices 102 based on user subscription to a selected set of content and services. A software code 206 resident on the user devices 102 allows the user to access, view, and/or store the multimedia content. The software code 206 also allows the user to interact with the managed network 100 and/or the user device 102 to select programs, request services, and/or execute local or remote applications. Additionally, the software code 206 may include instructions to permit only secure and authorized operations or communications between the server 106 and the user devices 102 operating within the managed network 100. Accordingly, ensuring authenticity of the software code 206 running on the user devices 102 is imperative for protecting content rights, while also preventing malicious attacks on the user devices 102 or the managed network 100.
[0033] Accordingly, in one embodiment, a chain of trust is established to ensure authenticity of the software code 206 present at various points from a boot loader to application layers in the user devices 102. In conventional user devices, root of trust is established by storing a 'code verification public key' in a non-re-writable memory of the user devices. This code verification public key is used to authenticate the software code running on conventional user devices. However, any compromise of the code verification private key necessitates replacement of millions of affected user devices that employ the corresponding code verification public key at huge expense and logistic burden.
[0034] Embodiments of the present managed network 100 mitigate such a scenario by establishing a root of trust in the user devices 102 using two levels of authentication. Specifically, the root of trust using two levels of authentication is established by storing a user device public key in a non-re-writable memory of the user devices 102 and a signed 'code verification key' in a re-writable memory of the user devices 102. An exemplary method for implementing the two level authentication in the user devices 102 to allow the users to securely access desired multimedia content over the managed network 100 is described in greater detail with reference to FIGs. 3-4.
[0035] Generally, the server 106 configures the software code 206 in the user devices 102 to provide the users with secure access to the subscribed content during use including at the time of installation at the user premises, or during a subsequent change in subscription. Specifically, the server 106 includes a provisioning system 202 and a code signing system 204 that communicate with each other and with the first batch of user devices 102 to implement the two-level root of trust for the user devices 102.
[0036] In one embodiment, the provisioning system 202 is configured to perform initial provisioning of the user devices 102, for example STBs, in the managed network 100. Particularly, the initial provisioning is performed when a set top box (STB) is installed in the user premises and is subsequently booted for the first time to configure and register the STB with the server 106. In certain embodiments, the initial provisioning of the user devices 102 is performed to enable the user devices 102 to receive and verify software code 206 received from the server 106. The user devices 102 store the verified software code 206 that configures the user devices 102 to request for and access subscribed online content and services from the server 106.
[0037] Additionally, during the initial provisioning, the provisioning system 202 and the code signing system 204 also employ key generation algorithms to generate cryptographic key pairs that form a root of trust. A cryptographic key pair includes a private key and a public key. It is well known in the art that a key generation algorithm is capable of generating multiple cryptographic key pairs using seed values. In one embodiment, the code signing system 204 generates a common cryptographic key pair for verifying the software code 206, whereas the provisioning system 202 generates individual cryptographic key pairs for each user device in the first batch of user devices 102.
[0038] Particularly, in one embodiment, the code signing system 204 generates a common code signing private key 212 and a common code verification public key 214 for the first batch of user devices 102. Additionally, the server 106 generates a random seed 216 for each user device in the first batch of user devices 102 and a common seed 218 for the first batch of user devices 102. For example, the provisioning system 202 selects the random seed 216 for the user device 102a and the common seed 218 for the first batch of user devices 102. Subsequently, the provisioning system 202 generates a user device private key 220 (also referred to as ‘device private key 220’) and a user device public key 222 (also referred to as ‘device public key 222’) for the user device 102a using the corresponding random seed 216 and the common seed 218. As the random seed 216 is unique to the user device 102a, the user device private key 220 and the user device public key 222 are unique to the user device 102a. Similarly, the server 106 generates three additional random seeds, each corresponding to the user devices 102b, 102c, and, 102d. These random seeds are then used to generate corresponding unique user device private and user device public keys for each of the user devices 102b, 102c, and 102d in the first batch of user devices 102. The provisioning system 202 stores the common seed 218 and batch information (not shown) corresponding to the first batch of user devices 102 in the server 106. The batch information includes unique batch numbers, type of key generation algorithms used for the first batch of user devices 102, the number of user devices included in the first batch of user device 102, and the like.
[0039] In one embodiment, the provisioning system 202 embeds the user device public key 222 and the random seed 216 in a one-time programmable (OTP) memory 208 in the user device 102a before the user device 102a is sent for installation at user premises. Subsequently, the server 106 discards the random seed 216, while retaining the common seed 218. In certain embodiments, the provisioning system 202 also stores the batch information and startup code 221 in the OTP memory 208 of the user device 102a. In one embodiment, the startup code 221 aids the user device 102a to initialize a boot sequence, verify received software code 206, and install the software code 206 following initial provisioning of the user device 102a.
[0040] In certain embodiments, the provisioning system 202 configures the user device 102a to verify the software code 206 by using the common code verification public key 214 received from the code signing system 204. Further, the provisioning system 202 generates a first digital signature 224 by signing the common code verification public key 214 with the user device private key 220. Subsequently, the provisioning system 202 transmits the first digital signature 224 and the common code verification public key 214 to the user device 102a. The user device 102a receives and stores the first digital signature 224 and the common code verification public key 214 in a re-writable memory 210 present in the user device 102a.
[0041] In one embodiment, the server 106 discards the user device private key 220 following the transmission of the first digital signature 224 to the user device 102a. In certain embodiments, subsequent to the initial provisioning of each user device in the first batch of user devices 102, the server 106 performs code signing and code verification procedures for the first batch of user devices 102. Use of the code signing and code verification procedures facilitates verification of the authenticity and integrity of the software code 206 received by the first batch of user devices 102.
[0042] In order to perform the code signing procedure, the code signing system 204 generates a second digital signature 226 by signing the software code 206 with the common code signing private key 212. In certain embodiments, the code signing system 204 generates the second digital signature 226 prior to installation of the user device 102a at the user premises and/or every time the service provider releases a new version of the software code 206 that needs to be updated in the user device 102a. Subsequently, the code signing system 204 transmits the second digital signature 226 and the software code 206 to the user device 102a.
[0043] Upon receipt of the software code 206, the user device 102a verifies the authenticity and/or integrity of the common code verification public key 214 that needs to be used for verifying the received software code. Accordingly, the user device 102a verifies the first digital signature 224 using the user device public key 222. Subsequent to the verification of the first digital signature 224, the user device 102a verifies the second digital signature 226 using the common code verification public key 214 stored in the re-writable memory of the user device 102a. The user device 102a, thus, is able to ensure that the common code verification public key 214 in the re-writable memory 210 and the software code 206 received over the managed network 100 are authentic. Here, the verification of the first digital signature 224 using the user device public key 222 serves as a first level of trust. Further, the verification of the second digital signature 226 using the common code verification public key 214 serves as a second level of trust. Thus, the managed network 100 establishes a two level root of trust to ensure authenticity of the software code 206 to be installed in the user device 102a.
[0044] Establishing the two level root of trust enables the service providers to mitigate risks arising from occurrence of specified conditions that may hinder the security of the user devices 102. For example, the two level root of trust enables the service providers to mitigate any compromise of the common code signing private key 212 by quickly generating a new common code signing and verification key pair. Subsequently, the common code verification public key stored in the re-writable memory of all affected user devices 102 is simply replaced with the new common code verification public key to prevent unauthorized access to the user devices 102. Additionally, the common code signing and verification key pair may also be regenerated, replaced, or recycled for example, at the time of a version update of the software code 206, corruption of the software code 206, in an event of the software code 206 being hacked, and/or after specified periods of time.
[0045] In one embodiment, upon occurrence of the specified condition, the code signing system 204 generates a new common code signing private key and a new common code verification public key. Further, the code signing system 204 transmits the new common code verification public key to the provisioning system 202. Upon receiving the new common code verification public key, the provisioning system 202 transmits one or more instructions to the user device 102a to invalidate the stored common code verification public key 214. The user device 102a, upon receiving these instructions, invalidates the common code verification key. Additionally, the user device 102a transmits the random seed 216 and the batch information to the provisioning system 202 along with a request for a new code verification public key.
[0046] In response to the request from the user device 102a, the provisioning system 202 regenerates the user device private key 220 and the user device public key 222 using the corresponding random seed 216 and the common seed 218. The provisioning system 202 further generates a third digital signature by signing the new common code verification public key with the regenerated user device private key 220. The provisioning system 202 then transmits the third digital signature along with the new common code verification public key to the user device 102a. The user device 102a stores the third digital signature and the new common code verification public key in the re-writable memory 210. The user device 102a verifies the third digital signature using the user device public key 222 embedded in the OTP memory 208. Thus, the managed network 100 replaces the common code verification public key 214 with the new common code verification public key in the event of a compromise without requiring replacement of any hardware components in the user device 102a.
[0047] Furthermore, the code signing system 204 generates a fourth digital signature by signing the software code 206 with the new common code signing private key. The code signing system 204 then transmits the fourth digital signature along with the software code 206 to the user device 102a. The user device 102a receives and verifies the fourth digital signature using the new common code verification public key stored in the re-writable memory 210 following successful verification of the third digital signature corresponding to the new common code verification public key. Subsequent to the verification, the software code 206 is installed in the user device 102a. Thus, the software code 206 is re-verified by the new common code verification key to prevent any unauthorized access to the user device 102a. The managed network 100 similarly secures the second, third, and fourth devices 102b, 102c, and 102d by following similar operational procedure as followed for the user device 102a.
[0048] In one embodiment, the server 106 uses the same common seed for generating cryptographic keys for securing the first and second batch of user devices 102 and 104. In an alternative embodiment, however, the server 106 generates different common seeds (not shown) for generating cryptographic keys for securing the first and second batches of user devices 102 and 104. Further, in certain embodiments, the server 106 uses the same common code signing and code verification keys for signing the software code 206 for both the first and second batches of user devices 102 and 104. In certain other embodiments, the server 106 may employ a different pair of common code signing private key and code verification public key for signing the software code 206 to be transmitted to the first and second batches of user devices 102 and 104.
[0049] In certain embodiments, the server 106 retains the common seeds and batch information corresponding to the first and second batch of user devices 102 and 104 in memory, while discarding the key pairs. Thus, the managed network 100 eliminates the need for a dedicated database to store the cryptographic key pairs generated for each user device of the first and second batch of user devices 102 and 104. Further, the managed network 100 enables efficient recycling of the code signing and code verification keys without any overhead of signing the software code 206 multiple times using different code verification keys for each of the user devices 102 and 104.
[0050] Certain exemplary methods for securing user devices, while enabling recycling of trust values upon occurrence of specified conditions are described with reference to FIGs 3-4. The order of the steps included in the flowcharts may change in practical implementation. Additionally, certain steps may be deleted, modified, or added to the flowcharts. Moreover, the steps included in the flowcharts may be performed sequentially, or in a distributed manner. Further, the steps may involve additional components or omit certain components in practical implementation. For clarity, the exemplary methods of FIGs 3-4 are described with reference to elements of the managed network 100 of FIGs. 1-2.
[0051] FIG. 3 illustrates a flowchart 300 depicting an exemplary method performed by the managed network 100 to secure the first batch of user devices 102. At step 302, the code signing system 204 in the managed network 100 generates the common code signing private key 212 and the common code verification public key 214. Further, at step 304, the server 106 generates the common seed 218 for the first batch of user devices 102 and the random seed 216 for at least the user device 102a. At step 306, the provisioning system 202 generates the user device private key 220 and the user device public key 222 for the user device 102a using the common seed 218 and the random seed 216. At step 308, the server 106 embeds the user device public key 222 and the random seed 216 in the OTP memory 208 of the user device 102a. Additionally, in certain embodiments, the server 106 also stores the batch information and the startup code in the OTP memory 208 of the user device 102a.
[0052] Further, at step 310, the provisioning system 202 generates the first digital signature 224 by signing the common code verification public key 214 with the user device private key 220. At step 312, the provisioning system 202 transmits the first digital signature 224 and the common code verification public key 214 to the user device 102a. At step 314, the user device 102a stores the first digital signature 224 and the common code verification public key 214 in the re-writable memory 210. At step 316, the code signing system 204 generates the second digital signature 226 by signing the software code 206 to be sent to the user device 102a with the common code signing private key 212. At step 318, the server 106 transmits the second digital signature 226 and the software code 206 to the user device 102a. At step 320, the user device 102a verifies the first digital signature 224 using the user device public key 222 embedded in the corresponding OTP memory 208 to determine authenticity and integrity of the common code verification public key 214. At step 322, the user device 102a verifies the second digital signature 226 using the common code verification public key 214 stored in the corresponding re-writable memory 210 to determine authenticity and integrity of the received software code 206.
[0053] In the event of occurrence of specified conditions, such as, compromise of the common code signing private key, version update of the software code 206, and/or after specified periods, the common code signing private key 212 and common code verification public key 214 may need to be replaced. However, unlike traditional managed networks, where the entire user device needs to be changed, the present method allows for replacement of the common code signing private key 212 and common code verification public key 214. An embodiment of the present method for replacing the common code verification public key 214 upon occurrence of a specified condition is described in greater detail with reference to FIG. 4.
[0054] FIG. 4 illustrates a flowchart 400 depicting an exemplary method of replacing the common code verification public key 214 in the event of occurrence of specified conditions. To that end, at step 402, the server 106 generates the new common code signing private key and the new common code verification public key upon detection of the specified condition. The specified condition may be detected, for example, through use of various network and device monitoring routines. At step 404, the user device 102a invalidates the common code verification public key 214. Specifically, the user device 102a invalidates the common code verification public key 214 in response to an instruction received from the provisioning system 202. In one embodiment, the provisioning system 202 transmits the instruction to the user device 102a to invalidate the common code verification public key 214 upon receiving the new common code verification public key from the code signing system 204.
[0055] Subsequently, at step 406, the user device 102a transmits the random seed 216 and batch information along with a request for a new code verification public key to the provisioning system 202. At step 408, the provisioning system 202 regenerates the user device public key 222 and the user device private key 220 using the random seed 216 received from the user device 102a and the common seed 218 stored in the server 106. At step 410, the provisioning system 202 generates the third digital signature by signing the new common code verification public key with the user device private key 220. At step 412, the provisioning system 202 transmits the third digital signature and the new common code verification public key to the user device 102a. At step 414, the user device 102a stores the third digital signature and the new common code verification public key in the re-writable memory 210. At step 416, the server 106 generates the fourth digital signature by signing the software code 206 with the new common code signing private key. At step 418, the server 106 transmits the fourth digital signature and the software code 206 to the user device 102a. At step 420, the user device 102a verifies the third digital signature by using the user device public key 222 embedded in the OTP memory 208. At step 422, the user device 102a verifies the fourth digital signature using the new common code verification public key and subsequently installs the software code 206.
[0056] Embodiments of the managed network 100, disclosed herein, provide enhanced security to the endpoint user devices through the implementation of the two level authentication of root of trust. In contrast to traditional implementations, the managed network enables replacement of the code signing and code verification key pair 212 and 214. The replacement of the code signing and code verification key pair 212 and 214 aids in quick mitigation of any compromise of the common code signing private key 212 without needing to replace all the affected user devices. Thus, the two level authentication and the ability to recycle keys allow the service provider to take immediate actions against unauthorized access, theft, and/or corruption of the multimedia content distributed to the user devices. Additionally, using an embodiment of the managed network 100 eliminates a need for any dedicated database in the server 106 for storing the cryptographic key pairs corresponding to a large number of user devices 102, 104. Furthermore, the managed network 100 achieves the two level authentication of the root of trust without increasing the complexity of the existing systems. Thus, the managed network 100 provides an economical and efficient technique for securing the user devices without huge expense and logistic burden.
[0057] It may be noted that various functions and/or method steps described herein may be implemented in a variety of programming languages, including but not limited to Ruby, Hypertext Pre-processor (PHP), Perl, Delphi, Python, C, C++, or Java. Such code may be stored or adapted for storage on one or more tangible, machine-readable media, such as on data repository chips, local or remote hard disks, optical disks (that is, CDs or DVDs), solid-state drives, or other media, which may be accessed by the processor-based system to execute the stored code.
[0058] Although specific features of various embodiments of the present network and exemplary methods may be shown in and/or described with respect to some drawings and not in others, this is for convenience only. It is to be understood that the described features, structures, and/or characteristics may be combined and/or used interchangeably in any suitable manner in the various embodiments, for example, to construct additional assemblies and techniques for use in managed networks.
[0059] While various embodiments of the present network and method have been illustrated and described, it will be clear that the present network and method is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the present network and method, as described in the claims.