BACKGROUND

[0001] Particular embodiments generally relate to cryptography.

[0002] Digital terminal adapter (DTA) devices may be used in networks, such as cable networks. A DTA device may be a device that converts a digital signal to another form, such as an analog signal. A computer chip that is installed in the DTA device may include a security mechanism, such as encryption keys. The keys are used to when communicating with network devices. For example, a cable head end may send content to the DTA devices using a multi-layer security scheme that may be based on public key infrastructure (PKI) technology or symmetric key cryptography, or a combination thereof.

[0003] A black box may refer to a cryptographic key server that is installed at a chip foundry for provisioning cryptographic keys to be programmed onto the chips. A black box vendor refers to a vendor that provides a black box. In general, a black box vendor may be different from a device manufacturer. However, a device manufacturer may also be a black box vendor. For example, the DTA devices may be manufactured by a black box vendor. The DTA devices are associated with a model type. For example, a model type is associated with a specific type of computer chip. Multiple DTA devices of the model type may be manufactured. Each DTA device includes the same type of computer chip. At some point, a device model type may become compromised due to hardware or software vulnerability. In this case, a very large group of devices of the same model type may need to have their keys revoked.

Typically, it is unlikely that a specific device or small group of devices becomes compromised. In other examples, digital certificates may be installed in the computer chip and digital certificates can be revoked.

[0004] A certificate hierarchy may be used to revoke devices for a model type. An authorization certificate authority (CA) for each model type may be defined. Devices are then associated with individual device certificates that are chained to the CA certificate. Thus, whenever the CA certificate is revoked, that automatically revokes all the device certificates under that certificate tree for that CA certificate. While this scheme will revoke all individual device certificates, this solution needs to maintain a different CA for each device model type. This complicates the provisioning of the certificates at a manufacturing facility because the manufacturing facility needs to maintain and track all the different certificate authorities. Also, in cases where the security system is symmetric key based rather than PKI -based, this approach cannot be used.

SUMMARY

[0005] In one embodiment, a method includes receiving a revocation request for revoking a model type of a device. A first computing device determines a list of device unit identifiers (UIDs) that are associated with the model type from a database. The device UIDs are for devices of the model type manufactured by a first entity. The method adds the list of device UIDs to a device revocation list and outputs the device revocation list to revoke a validity of secure information associated with devices associated with the list of device UIDs.

[0006] In another embodiment, a non-transitory computer-readable storage medium is provided containing instructions for controlling a computer system to be operable to: receive a revocation request for revoking a model type of a device; determine, at a first computing device, a list of device unit identifiers (UIDs) that are associated with the model type from a database, the device UIDs for devices of the model type manufactured by a first entity; add the list of device UIDs to a device revocation list; and output the device revocation list to revoke a validity of secure information associated with devices associated with the list of device UIDs.

[0007] In another embodiment, an apparatus is provided comprising: one or more computer processors; and a computer-readable storage medium comprising instructions for controlling the one or more computer processors to be operable to: receive a revocation request for revoking a model type of a device; determine a list of device unit identifiers (UIDs) that are associated with the model type from a database, the device UIDs for devices of the model type manufactured by an entity; add the list of device UIDs to a device revocation list; and output the device revocation list to revoke a validity of secure information associated with devices associated with the list of device UIDs.

[0008] The following detailed description and accompanying drawings provide a more detailed understanding of the nature and advantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 depicts a simplified system for synchronizing and revoking security information according to one embodiment.

[0010] FIG. 2 depicts a simplified flowchart of a method for revoking security information according to one embodiment.

[0011] FIG. 3 shows a more detailed example for synchronizing DTA revocation lists according to one embodiment.

[0012] FIG. 4 depicts a more detailed example of a DTA revocation list manager according to one embodiment.

DETAILED DESCRIPTION

[0013] Described herein are techniques for a security synchronization system. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. Particular embodiments as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include

modifications and equivalents of the features and concepts described herein.

[0014] FIG. 1 depicts a simplified system 100 for synchronizing and revoking security information according to one embodiment. System 100 includes a revocation authority 102, a black box vendor 104-1 (BBV1), and a black box vendor 104-2 (BBV2).

[0015] A black box vendor may refer to a company that offers black box services to system on a chip (SOC) vendors. For example, black box vendors may provide a black box, which is a server that provides keys in a chip foundry for programming to chips such as SOCs. A device manufacturer may manufacture a device that has a SOC embedded in a device factory. In one embodiment, a device that makes use of a SOC may be a network device, such as a digital terminal adapter (DTA) device, a set- top box, or another device used in content delivery systems, such as cable systems. In one example, the device receives content from a content provider, and converts the content to another form for display. The device will be referred to as a DTA device hereinafter, but other devices may be used.

[0016] The SOC may be a computer chip used in the DTA device. Each DTA device may include a unit identifier (UID). In one embodiment, the DTA UID differentiates each DTA device from all others, and may be a 48-bit unique ID. The SOC also includes security functionality and other security related information. The security information may include public or symmetric keys, and/or certificates. Other forms of cryptography may also be used. In one example, a secure key may be a DTA USK (unique secret key) that is unique to each DTA device. In one

embodiment, the DTA USK is a 128-bit cryptographic key that is random and uniquely assigned to each DTA device, and is solely associated with a specific DTA device UID.

[0017] The device UID is associated with a key and optionally a digital certificate that are installed in each device and/or SOC. For example, the key may be installed in the SOC. Each black box vendor 104 may keep track of which device UIDs are associated with each device model type at the time when devices and/or SOCs are provisioned in a manufacturing facility.

[0018] Black box vendors 104 include a revocation list manager 106 that keeps track of UIDs corresponding to DTAs that had the corresponding USKs compromised and should be denied service. Each revocation list manager 106 at each black box vendor 1004 may maintain a DTA UID list.

[0019] Revocation authority 102 may be a vendor that is designated as being certified to provide an RA revocation list to black box vendor 104-1 and black box vendor 104-2. The RA revocation list is used by black box vendors 104 to revoke keys that have been compromised. The RA revocation list includes a list of one or more model types, but not a list of actual DTA UIDs for the DTA devices that were manufactured for the model type. For example, different device manufacturers may manufacture DTA devices. The DTA devices may be categorized by a model type. For example, different model types may be defined by which SOC is included in the DTA device. For example, a model type #10 may include SOC #1 and a model type #20 may include SOC #2. Also, different companies may manufacture the same model type of DTA device by including the same SOC in the DTA device.

[0020] When black box vendors 104 receive the RA revocation list, revocation list managers 106 perform a process to revoke the keys for individual DTA devices. In a process that is described in more detail below, black box vendors 104-1 and 104-2 synchronize security information by including DTA device UIDs for the model type on a new DTA revocation list. The DTA revocation list includes DTA device UIDs that correspond to the model type specified on the RA revocation list. The DTA revocation list is then made available for download or sent to networking devices, such as a head-end device that is communicating with the DTA devices. The headend device can revoke the validity of the keys for the DTA devices on the DTA revocation list. For example, the head-end device may not allow any communication from the DTA devices that include the DTA device UIDs found on the revocation list. Other security actions may also be performed. Accordingly, revocation list managers 106 receive a model type and convert the model type into specific device UIDs for use in revoking the security information in the specific DTA devices associated with the device UIDs.

[0021] FIG. 2 depicts a simplified flowchart 200 of a method for revoking security information according to one embodiment. A more detailed example of the method will be described below. At 202, black box vendor 104-1 receives a revocation request including an RA revocation list that includes a model type from revocation authority 102. In one embodiment, a single black box vendor 104 may receive the revocation request. That black box vendor 104 may communicate with other black box vendors 104 to synchronize the DTA revocation list for each. In alternative embodiments, each black box vendor 104 may receive the RA revocation request.

[0022] At 204, black box vendor 104-1 generates a delta DTA revocation list #1. The delta DTA revocation list includes device UIDs that are associated with the model type received in the revocation request. For example, revocation list manager 106-1 may use a DTA key list to determine which DTA UIDs are associated with the model type.

[0023] At 206, revocation list manager 106-1 merges the delta DTA revocation list #1 with a current DTA revocation list. The current DTA revocation list may be a list that includes any DTA UIDs that were previously revoked. By merging the delta DTA revocation list #1 with the current DTA revocation list, any DTA UIDs that are not included on the current DTA revocation list are added to the current DTA revocation list.

[0024] At 208, revocation list manager 106-1 sends the current DTA revocation list to black box vendor 104-2. In other examples, just the delta revocation list #1 may be sent, the current revocation list including the delta revocation list #1 may be sent, or any other indication of the changes may be sent. Certain verification steps may be taken to verify the changes to the current DTA revocation list are valid, but are described in more detail below. At 210, revocation list manager 106-2 generates a delta DTA revocation list #2. Because black box vendor 104-2 may be associated with a device manufacture different from black box vender 104-1, , black box vendor 104-2 may have provided keys in SOCs in DTA devices of the same model type with different device UIDs. Delta DTA revocation list #2 includes these device UIDs.

[0025] At 212, revocation list manager 106-2 merges the current DTA revocation list with the delta DTA revocation list #2. Different ways of creating the current DTA revocation list may be used. For example, revocation list manager 106-2 may receive delta revocation list #1, generate its own current revocation list, and then add both the delta revocation list #1 and #2 to its own current revocation list. This adds any device UIDs that were not on the current DTA revocation list. The current DTA revocation list now includes the merged device UIDs from the delta DTA revocation lists #1 and #2.

[0026] At 214, revocation list manager 106-2 sends the current DTA revocation list to black box vendor 104-1. In other examples, just the delta revocation list #2 may be sent. Certain verification steps may be taken to verify the changes to the current DTA revocation list is valid, but are described in more detail below. At this point, both revocation list manager 106-1 and/or revocation list manager 106-2 have the current DTA revocation list that can be deemed official.

[0027] At 216, revocation list manager 106-1 and/or revocation list manager 106-2 makes the current DTA revocation list available. For example, the current DTA revocation list is made available for download or the current DTA revocation list is sent to a networking device, such as a head-end device. The head-end device would then use the current DTA revocation list to revoke the security information, such as the key, for associated devices having the device UIDs on the current DTA revocation list. Different head-end devices may use conditional access systems, which use the USK keys to monitor access to each DTA device. Revocation list manager 106-1 may be associated with a Conditional Access System #1 and may supply the current DTA revocation list only to head-end devices that utilize Conditional Access System #1. Revocation list manager 106-2 may be associated with a Conditional Access System #2 and may supply the current DTA revocation list only to head-end devices that utilize Conditional Access System #2.

[0028] FIG. 3 shows a more detailed example for synchronizing DTA revocation lists according to one embodiment. The communication is between revocation authority 102, black box vendor 104-1, black box vendor 104-2, head-end #1 and head-end #2. At 301, a current DTA revocation list (RL i) is the official current revocation list. For example, after a synchronization process is performed, DTA revocation list (RL i), where "i" may be an integer, is the current DTA revocation list. An initial DTA revocation list RL O may be an empty list and each synchronized current DTA revocation list may increment "i". At any point in time during a synchronization process, if a third party (e.g., head-end 302) requests a current DTA revocation list from one of black box vendors 104, the current official DTA revocation list is returned to the requester. If a third party requests the current DTA revocation list during a synchronization process, black box vendor 104 asks the third party to wait until the current synchronization is completed. The current DTA revocation list may be made available for retrieval by authorized parties at one or more servers or may be pushed to each head-end 302.

[0029] At 302, black box vendor 104-1 receives a revocation request (SRLJ). For example, revocation authority 102 may decide that a certain model type, such as a model type defined by an SOC chip model, should be revoked due to a security breach. The chip model may be identified by an SOC major model and an SOC minor model pair. The SOC major model defines an "SOC key ladder" type that is used by the SOC vendor. This may be SOC-vendor specific. For each SOC major model, there may be one or more "SOC minor models" that specify the particular SOC chip type or version. Different SOC minor models may have (slightly) different security architectures. The SOC minor model may be used during revocation such that revocation authority 102 may request that all DTA devices based on a particular SOC minor model be added to the DTA revocation list. In other examples, a SOC major model may be specified to revoke all SOC minor models associated with the SOC major model.

[0030] At 303, black box vendor 104-1 needs to notify black box vendor 104-2 that a synchronization process is going to be performed. For example, black box vendor 104-1 sends a reservation request to black box vendor 104-2 to reserve the next sequence number (i+1) for the revocation request (SRLJ). Reserving the next sequence number ensures that black box vendor 104-2 will not update the current DTA revocation list separately. At 304, black box vendor 104-2 confirms the receipt of the reservation request. [0031] At 305, black box vendor 104-1 generates a delta DTA revocation list (ARL_i+l). The delta DTA revocation list contains the DTA UIDs that black box vendor 104-1 generates based on the model type (e.g., SOC major model, SOC minor model) being revoked. To determine the new entries of the DTA UIDs being revoked for this request, black box vendor 104-1 may compare the new DTA revocation list (SRLj+1) with the previous revocation request (SRLJ). This determines the model types that need to be revoked. Then, the DTA UIDs associated with the model types are determined for the delta DTA revocation list.

[0032] At 306, black box vendor 104-1 merges the delta DTA revocation list (ARL_i+l) with the current DTA revocation list (RL i) to form a new DTA revocation list (RL_i+l). The new DTA revocation list includes the previously revoked DTA UIDs and the newly added DTA device UIDs.

[0033] At 307, black box vendor 104-1 computes a hash (RLH_i+l) over the new DTA revocation list (RL_i+l). Although hashing is described, a hash over the new DTA revocation list does not need to be performed. The hash may be used to securely communicate the new DTA revocation list to black box vendor 104-2 and also reduce the amount of information that needs to be transmitted. At 308, black box vendor 104-1 sends synchronization data, such as the hash of the DTA revocation list (RLH_i+l) and the delta DTA revocation list (ARL_i+l), to black box vendor 104-2.

[0034] At 309, black box vendor 104-2 merges the delta DTA revocation list with its own current DTA revocation list (RL i) to form a new DTA revocation list (RL_i+l).

[0035] At 310, black box vendor 104-2 computes the hash of the new DTA revocation list (RL_i+l) to form the hash of the DTA revocation list (RLH_i+l) and verifies that the hash of the DTA revocation list is the same as the hash of the DTA revocation list received from black box vendor 104-1. This step is done in order to verify that black box vendor 104-2 has the same current DTA revocation list as black box vendor 104-1. Although this verification is described, it may not be performed in other embodiments. [0036] At 311 , black box vendor 104-2 generates a second delta DTA revocation list (ARL_i+2). The second delta DTA revocation list includes DTA UIDs that black box vendor 104-2 generates based on the model type (e.g., SOC major model, SOC minor model) being revoked. For example, black box vendor 104-2 may be a different company that manufactures DTA devices that have the same model type as DTA devices from black box vendor 104-1. The DTA devices that were

manufactured by black box vendor 106-2 have different device UIDs that black box vendor 106-2 is only aware of. The sequence number for the delta DTA revocation list is also incremented to i+2. If the verification fails, black box vendor 104-2 and black box vendor 104-1 may resolve the discrepancy. This process is not described, however. Before the discrepancy is resolved, the current DTA revocation list (RL i) remains the official one.

[0037] At 312, black box vendor 104-2 merges its delta DTA revocation list (ARL_i+2) with the current DTA revocation list received from black box vendor 104- 1 (RL_i+l) to form a new current DTA revocation list (RL_i+2).

[0038] At 313, black box vendor 104-2 computes the hash of the new current DTA revocation list (RL_i+2) to form a hash of the current revocation list (RLH_i+2). At 314, black box vendor 104-2 sends synchronization data (e.g., its delta revocation list (ARL_i+2) and the hash of the current DTA revocation list RLH_i+2) to black box vendor 104-1.

[0039] Black box vendor 104-1 may then verify the second DTA revocation list (ARL_i+2) from black box vendor 104-2. For example, at 315, black box vendor 104-1 merges its current DTA revocation list (RL_i+l) with the second delta DTA revocation list (ARL_i+2) to form a final DTA revocation list (RL_i+2). At 316, black box vendor 104-1 computes the hash of the final DTA revocation list to form the hash of the final DTA revocation list (RLH_i+2), and verifies that the hash is the same as the hash of the final DTA revocation list received in the synchronization data from black box vendor 104-2.

[0040] If verification is successful, black box vendor 104-1 sends a confirmation back to black box vendor 104-2 at 317. If verification fails, black box vendor 104-1 and black box vendor 104-2 may work together to resolve the discrepancy. As described above, the current DTA revocation list (RL i) remains the official one until resolved.

[0041] At 318, the new DTA revocation list (RL_i+2) becomes the official DTA revocation list. The official DTA revocation list may be based on a standard, such as X.509 certificate DTA revocation list (CRL) standard and may be processed using public key infrastructure (PKI) implementation. The sequence number has been incremented by two for the single revocation request received from certificate authority 102. Even if a black box vendor 104 does not have any entries to add for a particular request, the sequence number may be incremented.

[0042] At 319, black box vendor 104-2 may push the DTA revocation list (RL_i+2) to authorized parties, such as head-end 302-1. Also, at 320, black box vendor 104-1 sends the DTA revocation list (RL_i+2) to head-end 302-2. Black box vendors 104-1 and 104-2 may use different cable networks and thus different head-ends 302 may be contacted with the DTA revocation list. Head-ends 302-1 and 302-2 may be cable head-ends that distribute content to DTA devices. Head-ends 302 may not distribute content to DTA devices that include the DTA UIDs specified on the DTA revocation list. Also, the DTA revocation list may be made available for download.

[0043] FIG. 4 depicts a more detailed example of DTA revocation list manager 106- 1 according to one embodiment. A request processor 402 receives a revocation request from revocation authority 102. Request processor 402 forwards the request to a delta revocation list (RL) generator 404.

[0044] Delta RL generator 404 determines a list of device UIDs associated with a model type included with the revocation request. The list of model types and device UIDs may be stored in a database 406 that is queried. Delta RL generator 404 then generates a delta DTA revocation list that includes device UIDs that correspond to new device model(s) that have been revoked.

[0045] An RL merge manager 410 may have the current revocation list and merges the current DTA revocation list with the delta DTA revocation list. The merged list is sent to a communicator 408, which is then configured to communicate

synchronization information from black box vendor 104-1 to black box vendor 104-2. As described above, the synchronization information may be the delta DTA revocation list and a hash of the merged DTA revocation lists. However, other synchronization information may be sent to allow DTA revocation lists to be synchronized. For example, only the delta DTA revocation list may be sent.

[0046] Black box vendor 104-2 may determine its own delta revocation list as described above and send synchronization information back to black box vendor 104- 1. Communicator 408 of black box vendor 104-1 receives synchronization information from black box vendor 104-2. For example, a second delta DTA revocation list and a hash of a final DTA revocation list may be received. RL merge manager 410 may then verify the final DTA revocation list as described above. For example, the second delta DTA revocation list may be merged with the current DTA revocation list of black box vendor 104-1 to form the final DTA revocation list, which is then verified with the hash of the final DTA revocation list received from second black box vendor 104-2. RL merge manager 410 then outputs the official DTA revocation list to a DTA revocation list communicator 412. DTA revocation list (RL) communicator 412 can then provide the official DTA revocation list to one or more servers for download or push the official DTA revocation list to other authorized parties.

[0047] Accordingly, particular embodiments provide a method to take revocation requests using model types and determine device UIDs in which to revoke security information. The method also allows for synchronization between multiple black box vendors 104. This provides protection when a particular model type has software or hardware vulnerability. It may be rare when one specific device or a small set of devices have their security information revoked. Particular embodiments allow for a very large group of devices of the same model type to be revoked at the same time.

[0048] Particular embodiments may be implemented in a non-transitory computer- readable storage medium for use by or in connection with the instruction execution system, apparatus, system, or machine. The computer-readable storage medium contains instructions for controlling a computer system to perform a method described by particular embodiments. The instructions, when executed by one or more computer processors, may be operable to perform that which is described in particular embodiments.

[0049] As used in the description herein and throughout the claims that follow, "a", "an", and "the" includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.

[0050] The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope of the invention as defined by the claims.