System for efficient generation and distribution of challenge-response pairs

Abstract

A method for implementing response function agnostic, challenge-response authentication on a CE device includes sharing a series of proxy responses to a series of authentication challenges with a service provider, receiving an associated actual response from an initialization phase response function for each of the authentication challenges, where at least one of the initialization phase response function and a parameter required for the initialization phase response function is withheld from the service provider, encrypting each of the proxy responses with its associated actual response, thereby generating a series of encrypted proxy responses, storing the encrypted proxy responses on the CE device, receiving one of the authentication challenges from the service provider, inputting the authentication challenge to an operation phase response generator on the CE device, where the operation phase response generator is configured with the same response function used by the initialization phase response generator, and decrypting the proxy response from the encrypted proxy responses and results of the inputting, thereby producing the proxy response to the authentication challenge without sharing the at least one of the response function and a parameter required for the response function with the service provider. Related apparatus and methods are also described.

Claims

1. A method for generating and storing challenge-response pairs for the authentication of a consumer electronics (CE) device, the method comprising: sharing at least one challenge K.sub.CHALLENGE-i and a series of integers i with a service provider, wherein said CE device is configured to receive a service from said service provider; sharing at least one proxy response K.sub.IRD-i with said service provider, wherein each of said K.sub.IRD-i is associated with one of said at least one K.sub.CHALLENGE-i according to said series of integers i; for each said K.sub.CHALLENGE-i, generating an associated K.sub.RESPONSE-i by inputting said K.sub.CHALLENGE-i to a response generator associated with said CE device; producing one of said challenge-response pairs from each said K.sub.CHALLENGE-i and its said associated K.sub.RESPONSE-i, wherein at least one of a response function of said response generator and a parameter required for said response function is withheld from said service provider; for each of said K.sub.RESPONSE-i, deriving EK.sub.IRD-i, from both said K.sub.RESPONSE-i and said associated K.sub.IRD-i; and storing each of said EK.sub.IRD-i on said CE device according to said series of integers i, wherein a given said K.sub.IRD-i is derivable from said K.sub.RESPONSE-i received from said response generator in response to said K.sub.CHALLENGE-i paired with said K.sub.IRD-i and said EK.sub.IRD-i associated with said paired K.sub.CHALLENGE-i.

2. The method according to claim 1 and also comprising: deriving said at least one said challenge K.sub.CHALLENGE-i from meta-key MK.sub.CHALLENGE and said series of integers i, wherein said MK.sub.CHALLENGE is shared with said service provider; and deriving said at least one said proxy response K.sub.IRD-i from meta-key MK.sub.IRD and said series of integers i, wherein said MK.sub.IRD is shared with said service provider.

3. The method according to claim 2 wherein at least one of said meta-key MK.sub.CHALLENGE or said meta-key MK.sub.IRD is common to more than one said CE device.

4. The method according to claim 2 wherein said meta-key MK.sub.CHALLENGE is equal to said MK.sub.IRD on said CE device, wherein said deriving said at least one challenge K.sub.CHALLENGE-i uses a different algorithm than said deriving said at least one said proxy response K.sub.IRD-i.

5. The method according to claim 1 wherein said at least one K.sub.CHALLENGE-i comprises at least two K.sub.CHALLENGE-i and said at least one K.sub.IRD-i comprises at least two K.sub.IRD-i.

6. The method according to claim 1 wherein said storing each of said at least one EK.sub.IRD-i comprises storing each of said at least one EK.sub.IRD-i in non-volatile memory.

7. The method according to claim 1 wherein said parameter required for said response function is withheld from the manufacturer of said CE device.

8. The method according to claim 1 wherein said response generator either: uses a key-based computation, wherein the key used in said key-based computation is withheld from said service provider; or the response generator uses a physically unclonable function (PUF) device.

9. The method according to claim 1 and also comprising: receiving RK.sub.CHALLENGE-i and Ri from said service provider, wherein said RK.sub.CHALLENGE-i is equal to one of said at least one K.sub.CHALLENGE-i and Ri is equal to one of said series of integers i associated with said one of at least one K.sub.CHALLENGE-i; inputting RK.sub.CHALLENGE-i to an operation phase response generator; in response to said inputting, receiving RK.sub.RESPONSE-i from said operation phase response generator; deriving unencrypted UK.sub.IRD-i from said RK.sub.RESPONSE-i and said EK.sub.IRD-i, wherein said EK.sub.IRD-i is associated with said Ri; and returning said UK.sub.IRD-i to said service provider in response to said RK.sub.CHALLENGE-i, thereby authenticating said CE device.

10. A method for decrypting media on a consumer electronics (CE) device, the method comprising: sharing at least one challenge K.sub.CHALLENGE-i and a series of integers i with a media provider; sharing at least one proxy response K.sub.IRD-i with said media provider, and wherein each of said at least one K.sub.IRD-i is associated with one of said at least one K.sub.CHALLENGE-i; according to said series of integers i; for each K.sub.CHALLENGE-i, generating an associated K.sub.RESPONSE-i by inputting said K.sub.CHALLENGE-i to an initialization phase response generator associated with said CE device, wherein at least one of a response function for said initialization phase response generator and a parameter required for said response function of said initialization phase response generator is withheld from said media provider; for each of said associated K.sub.RESPONSE-i, deriving EK.sub.IRD-i from both said associated K.sub.RESPONSE-i and said associated K.sub.IRD-i; storing each of said EK.sub.IRD-i on said CE device according to said series of integers i; receiving encrypted media, received challenge RK.sub.CHALLENGE-i and Ri from said media provider, wherein said RK.sub.CHALLENGE-i is equal to one of said at least one K.sub.CHALLENGE-i derived from said meta-key MK.sub.CHALLENGE and Ri is equal to one of said series of integers i associated with said one of at least one K.sub.CHALLENGE-i; generating RK.sub.RESPONSE-i by inputting said RK.sub.CHALLENGE-i to an operation phase response generator on said CE device, wherein said operation phase generator is configured with the same response function as said initialization phase response generator; deriving unencrypted UK.sub.IRD-i from said RK.sub.RESPONSE-i and said EK.sub.IRD-i, wherein said i associated with EK.sub.IRD-i equals Ri; and using UK.sub.IRD-i to decrypt said encrypted media.

11. The method according to claim 10 and also comprising: deriving said at least one challenge K.sub.CHALLENGE-i from meta-key MK.sub.CHALLENGE and said series of integers i, wherein said MK.sub.CHALLENGE is shared with said service provider; and deriving said at least one said proxy response K.sub.IRD-i from meta-key MK.sub.IRD and said series of integers i, wherein said MK.sub.IRD is shared with said service provider.

12. The method according to claim 11 wherein at least one of said meta-key MK.sub.CHALLENGE or meta-key MK.sub.IRD is common to more than one said CE device.

13. The method according to claim 11 wherein said meta-key MK.sub.CHALLENGE is equal to said MK.sub.IRD on said CE device, wherein said deriving said at least one challenge K.sub.CHALLENGE-i uses a different algorithm than said deriving said at least one said proxy response K.sub.IRD-i.

14. The method according to claim 11 wherein said at least one K.sub.CHALLENGE-i comprises at least two K.sub.CHALLENGE-i and said at least one K.sub.IRD-i comprises at least two K.sub.IRD-i.

15. The method according to 10 wherein said using comprises: either decrypting said encrypted media with UK.sub.IRD-i, wherein said encrypted media is encrypted with said K.sub.IRD-i associated with said K.sub.CHALLENGE-i; or deriving a decryption key from UK.sub.IRD-i, wherein said K.sub.IRD-i associated with said K.sub.CHALLENGE-i was used to secure said encryption key, and decrypting said encrypted media with said encryption key, wherein said encrypted media is encrypted with said encryption key.

16. The method according to 10 wherein said storing each of said at least one EK.sub.IRD-i comprises storing each of said at least one EK.sub.IRD-i in non-volatile memory.

17. The method according to 10 wherein said parameter required for said response function is withheld from the manufacturer of said CE device.

18. The method according to 10 wherein said response function either: uses a key-based computation, wherein the key used in said key-based computation is withheld from said service provider; or uses a physically unclonable function (PUF) device.

19. The method according to 10 and also comprising: receiving RKCHALLENGE-i and Ri from said service provider, wherein said RKCHALLENGE-i is equal to one of said at least one KCHALLENGE-i and Ri is equal to one of said series of integers i associated with said one of at least one KCHALLENGE-i; inputting RKCHALLENGE-i to an operation phase response generator; in response to said inputting, receiving RKRESPONSE-i from said operation phase response generator; deriving unencrypted UKIRD-i from said RKCHALLENGE-i and said EKIRD-i, wherein said EKIRD-i is associated with said Ri; and returning said UKIRD-i to said service provider in response to said RKCHALLENGE-i, thereby authenticating said CE device.

20. An authentication system for a consumer electronics (CE) device comprising: an authentication storage unit configured to store at least a series of encrypted responses, wherein each of said encrypted responses are derived from a proxy response and an actual response to an authentication challenge from a service provider, wherein said proxy responses and authentication challenges are shared with said service provider; an I/O module configured to at least receive said authentication challenges and encrypted media from said service provider, wherein said encrypted media is encrypted with one of said proxy responses; a response function configured to provide said actual responses to said authentication challenges, wherein at least one of said response function and at least one parameter required for said response function is withheld from said service provider; and a challenge responder configured to employ a decryption module to facilitate derivation of said proxy response for an associated received said authentication challenge from said service provider by using said provided actual responses to decrypt said encrypted responses, wherein said decryption module is configured to decrypt said encrypted media using said one of said proxy responses.

21. The authentication system according to claim 20 wherein said authentication system is implemented in a smart card.

22. The authentication system according to claim 20 wherein said I/O module is further configured to return said proxy response to said service provider to authenticate said CE device.

23. The authentication system according to claim 20 wherein: said I/O module is further configured to receive encrypted media from said service provider; said encrypted media is encrypted with one of said proxy responses; and said description module is configured to decrypt said encrypted media using said one of said proxy responses.

24. The authentication system according to claim 20 wherein: said each of series of encrypted responses are associated with a series of i; and said I/O module is further configured to receive one of said series of integers i along with said authentication challenge from said service provider, thereby indicating which of said encrypted responses is associated with a given received said authentication challenge.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:

(2) FIG. 1 is a schematic illustration of a CE device, constructed and operative in accordance with an embodiment of the present invention;

(3) FIG. 2 is a block diagram of a challenge-response pair process that may be performed to generate one or more challenge-response pairs for the CE device of FIG. 1;

(4) FIG. 3 is a block diagram of a challenge-response process that may be performed by the CE device of FIG. 1; and

(5) FIG. 4 is a schematic illustration of a response function agnostic, broadcast decryption system, constructed and operative in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF AN EMBODIMENT

(6) The terms “scrambled” and “encrypted”, in all of their grammatical forms, are used interchangeably throughout the present specification and claims to refer to any appropriate scrambling and/or encryption methods for scrambling and/or encrypting data, and/or any other appropriate method for intending to make data unintelligible except to an authorized entity. Well known types of scrambling or encrypting include, but are not limited to DES, 3DES, and AES. Similarly, the terms “descrambled” and “decrypted” are used throughout the present specification and claims, in all their grammatical forms, to refer to the reverse of “scrambled” and “encrypted” in all their grammatical forms.

(7) Consumer electronic (CE) devices, such as, for example, set-top boxes, personal computers, tablets, handheld communications devices and the like, may typically be entitled to various services based on agreements with service providers. In order to receive such services, the CE devices may be required to provide identifying information to authentication servers associated with the service providers. The authentication servers may use challenge-response pairs as a means for authentication. In such a scenario, an authentication server may send a “challenge” to the CE, which may then respond with a “response.” If the received response matches an expected response for the issued challenge, the server may authenticate the identity of the device. Typically, multiple challenge-response pairs are generated to facilitate periodic switching or fallbacks in the event that a given pair is compromised.

(8) Such challenge-response pairs may typically be generated prior to distribution of the CE device by inputting a challenge to a response function associated with the CE device. Such a response function may be, for example, a key-based computation that may generate a seemingly unpredictable, yet consistent, response to a given challenge. Alternatively, the response function may be a hardware-based physical unclonable function (PUF). The generation process may typically be performed on the CE device itself. However, if the device's response function may be reproduced, it may be performed elsewhere on any other suitable platform, such as a standard computer or a specialized device. Once generated, copies of the challenges and their associated responses for each device and/or groups of devices may be stored on the authentication server.

(9) The authentication server may then use the stored challenge-response pairs to authenticate subsequent communications with the CE device. As per the scenario disclosed hereinabove, the authentication server may send a challenge to the CE device. The CE device may then use its response function to generate a response which may then be returned to the authentication server. The authentication server may then authenticate the CE device if the returned response received from the device matches the associated response stored on the authentication server.

(10) It will be appreciated that the device manufacturer and the service provider operating the authenticating server may be different entities that may be required to cooperate in order to generate and store the challenge-response pairs for use by the authentication server. In some cases it may be problematic for the device manufacturer to provide the response function to the service provider. For example, if the response functions are PUFs, it may not be feasible to reproduce them for use by the authentication server. Similarly, there may be business/legal considerations that may preclude the manufacturer from providing the service provider with the details of key-based response functions. For example, some manufacturers may simply prefer to keep the response function a secret from their customers, i.e. the service provider, and may therefore refuse to share the details of the response function.

(11) In such cases the pair generation process may therefore only be performed using the device itself. While the service provider may theoretically process each of the devices to generate the challenge-response pairs, such an undertaking may add further expense and/or complexity to the process, and in any case may require the service provider to take physical possession of the devices prior to their distribution to end users. Accordingly, it may be beneficial for the manufacturer to generate the pairs and forward the resulting list of challenge-response pairs to the service provider. Unfortunately, oftentimes device manufacturers may not be relied upon to deliver such a list without error.

(12) The inventors of the present invention have realized that challenge-response pair based security may be implemented on a CE device by a manufacturer without actually sharing the list of challenge-response pairs with the service provider. Instead, as may be described in detail hereinbelow, the responses may be used to encrypt security information provided by the security operator, thereby facilitating a “response function agnostic” version of a challenge-response pair based security system. As will be described hereinbelow, in such a response function agnostic security system, the “challenger”, i.e. the service provider of the previous example, may effectively authenticate a response to a challenge, even without knowledge of the response function used by the responder, i.e. the CE device, to generate the response to the challenge.

(13) Reference is now made to FIG. 1 which illustrates a CE device 100, constructed and operative in accordance with an embodiment of the present invention to facilitate the generation of challenge-response pairs for use by a non-manufacturer entity that does not possess the details of the response function in use for CE device 100. CE device 100 may comprise I/O module 110, device storage unit 130, challenge responder 140 and challenge generator 150.

(14) CE device 100 may be configured to communicate with authentication server 10 and challenge-response pair generator 120 via I/O module 110. Challenge-response pair generator 120 may typically be associated with the manufacturer of CE device 100, whereas authentication server 10 may typically be associated with a service provider requiring authentication of CE device 100. For example, the service provider may provide television programming services. In such a case, authentication server 10 may be implemented as part of a television headend. It will be appreciated that the service provider may alternatively, or additionally, provide other services, such as, for example, telephony, radio, music content, text messages and the like.

(15) It will be appreciated that CE device 100 may also comprise additional functionality as required for its intended commercial purpose. For example, CE device 100 may be a set-top box, personal computer, tablet or handheld communications device that may receive services from the operator of authentication server 10. However, in the interests of clarity, the additional functionality required to receive such services may not be depicted in FIG. 1. Alternatively, CE device 100 may be configured as an accessory element that may be dedicated to providing authentication functionality vis-à-vis authentication server 10. For example, CE device 100 may be configured as a smartcard or any other software/hardware module designed to provide authentication services vis-à-vis authentication server 10.

(16) Challenge-response pair generator 120 may comprise key generator 122 and encryption module 125. Reference is now made also to FIG. 2 which illustrates a challenge-response pair process 200 that may be performed by challenge-response pair generator 120 to generate one or more challenge-response pairs for CE device 100. Challenge-response pair generator 120 may input (step 205) authentication data into CE device 100 via I/O module 110. Such authentication data may be received from the service provider operating authentication server 10 prior to the start of process 200. As may be discussed hereinbelow, a copy of the authentication data may be stored in serial key database 15 on authentication server 10. The authentication data may include a device ID for CE device 100, which challenge-response pair generator 120 may store as device ID 135 in authentication storage unit 130. Authentication storage unit 130 may be implemented using any suitable means, such as, for example, flash memory, thereby providing a measure of protection against modification by unauthorized parties.

(17) The authentication data may also include a challenge meta-key (MK.sub.CHALLENGE) and a response meta-key (MK.sub.IRD). Together, MK.sub.CHALLENGE and MK.sub.IRD may be suitable for deriving a set of one or more challenge-response pairs per one or more algorithms agreed upon by the operators of authentication server 10 and Challenge-response pair generator 120. MK.sub.CHALLENGE may be suitable for deriving a series of challenges K.sub.CHALLENGE according to one or more algorithms known to both the operators of authentication server 10 and challenge-response pair generator 120. For example, for a series of i=1 to N challenge-response pairs, key generator 122 may initialize (step 215) i according to an agreed upon algorithm.

(18) Key generator 122 may then derive (step 220) K.sub.CHALLENGE-i from a combination of MK.sub.CHALLENGE and i. For example, key generator 125 may employ encryption module 125 to encrypt MK.sub.CHALLENGE with i using AES or any other suitable encryption algorithm. Key generator 125 may also derive (step 225) K.sub.IRD-i from MK.sub.IRD and i in similar manner. It will be appreciated that other methods may also be used to derive K.sub.CHALLENGE-i and/or K.sub.IRD-i. For example, the authentication data provided by the service provider may include a list of random numbers to populate series of one or more K.sub.CHALLENGE-i and/or K.sub.IRD-i. In such a case it may therefore not be necessary to perform steps 220 and 225. It will be appreciated, however, that whichever method may be used to derive K.sub.IRD-i, it may not be in any case directly derivable from K.sub.CHALLENGE-i. Therefore, with respect to K.sub.CHALLENGE-i, K.sub.IRD-i may not be an actual “response” but rather may be arbitrarily assigned. However, as will be discussed hereinbelow, K.sub.IRD-i may serve as a proxy for an actual response to K.sub.CHALLENGE-i.

(19) Challenge-response pairs generator 120 may send (step 230) the derived K.sub.CHALLENGE-i to response generator 150. Response generator 150 may be a response function employing a key-based computation. Alternatively, response generator 150 may employ a hardware-based response function, such as, for example, a PUF.

(20) It will be appreciated that depending on the response function used for response generator 150, it may be feasible to configure challenge-response pair generator 120 with a similar function, suitable for use with multiple CE devices 100. For example, the response function may employ a generally reproducible key-based computation. In such cases, challenge-response pair generator 120 may also comprise response generator 150′ which may be used to generate a response to K.sub.CHALLENGE-i instead of response generator 150.

(21) Challenge-response pair generator 120 may receive (step 235) K.sub.RESPONSE-i as the response from response generator 150. Encryption module 125 may then encrypt (step 240) K.sub.IRD-i with K.sub.RESPONSE-i, yielding EK.sub.IRD-i. Challenge-response pair generator 120 may store (step 245) EK.sub.IRD-i in challenge-response pair table 132 in authentication storage unit 130 along with its associated i.

(22) If i=N (step 250), process 200 may end. Otherwise, i may be incremented (step 255) and the process flow may return to step 220 where the next K.sub.CHALLENGE-i in series N may be derived.

(23) Upon completion of process 200, a set of N challenge-response pairs may be stored in challenge-response pairs table 132, each comprising an EK.sub.IRD-i and its associated i. It will be appreciated that each K.sub.CHALLENGE-i and K.sub.IRD-i may be derivable by the service provider according to the copy of MK.sub.CHALLENGE stored in serial key database 15. However, since the response function used by response generator 150 may not be known to the service provider, an associated EK.sub.IRD-i may not be derivable by the service provider.

(24) It will be appreciated that in some cases the response function per se may be shared with the service provider. For example, the response function used for generating K.sub.RESPONSE-i may be a well-known encryption algorithm to encrypt a key. Non-limiting examples of such well-known encryption algorithms may include AES, DES or 3DES. In such a case, the response function per se, i.e. which encryption algorithm was used, may be shared with the service provider. However, a necessary parameter such as the key used by the encryption algorithm may still be withheld from the service provider. Accordingly, the service provider may still not be able to derive EK.sub.IRD-i from K.sub.CHALLENGE-i and K.sub.IRD-i even if the response function is known.

(25) Reference is now made to FIG. 3 which illustrates a challenge-response process 200 that may be performed by CE device 100 in response to a CHALLENGE received from authentication server 10. The received challenge and its associated i, heretofore referred to as RK.sub.CHALLENGE-i and Ri, may be received by I/O module 110 from authentication server 10 as a challenge to authenticate the device ID for CE device 100. It will be appreciated that RK.sub.CHALLENGE-i may be one of the series K.sub.CHALLENGE-i and Ri may be its associated i. Response generator 150 may generate (step 320) authentication request response AR.sub.RESPONSE-i in response to K.sub.CHALLENGE-i.

(26) Challenge responder 140 may comprise decryption module 145 which may employ a decryption algorithm suitable for decrypting data encrypted by encryption module 125. Challenge responder 140 may employ decryption module 145 to derive (step 330) unencrypted value UK.sub.IRD-i by decrypting EK.sub.IRD-i with AR.sub.RESPONSE-i. It will be appreciated that challenge responder 140 may retrieve EK.sub.IRD-i from challenge-response pair table 132 per the value received for i from authentication server 10.

(27) I/O module 110 may then return (step 340) UK.sub.IRD-i to authentication server 10. It will be appreciated that, assuming that the same response function is used by response generator 150 in both processes 200 and 300, UK.sub.IRD-i may equal to K.sub.IRD-i. Furthermore, as discussed hereinabove, K.sub.IRD-i may be derivable according to the authentication data in serial key database 15. Accordingly, authentication server 10 may authenticate CE device 100 by comparing UK.sub.IRD-i to K.sub.IRD-i. If UK.sub.IRD-i equals K.sub.IRD-i, the service provider may provide CE device 100 with services as per any rights associated with its associate device ID. If not, the service provider may refuse to provide services to CE device 100. In such manner, K.sub.IRD-i may effectively serve as a proxy for the actual response to K.sub.CHALLENGE-i. Even though authentication server 10 may not actually receive AR.sub.RESPONSE-i in response to K.sub.CHALLENGE-i, it will be appreciated that CE device 100 may not be able to return the proxy response K.sub.IRD-i without first generating AR.sub.RESPONSE-i. Accordingly receipt of K.sub.IRD-i may be sufficient for authentication server 10 to authenticate CE device 100 per challenge K.sub.CHALLENGE-i.

(28) It will further be appreciated that the authentication process as described hereinabove may be response agnostic; the service provider may effectively use challenge-response pairs uniquely created for a given CE device without knowing the response function used to create the pairs. In fact, the service provider may not even receive the actual response generated by response generator.

(29) It will similarly be appreciated that the challenge-response pairs stored in challenge-response pair table 132 may not be sufficient in and of themselves to enable a hacker to be falsely authenticated by authentication server 10. Even if challenge-response pairs table 132 may be accessed and read by a hacker, K.sub.IRD-i is not stored “in the clear,” but rather in its encrypted form, EK.sub.IRD-i. Since EK.sub.IRD-i may not be recognized by authentication server 10, EK.sub.IRD-i may only be of value to a hacker if the response function of response generator 150 may be duplicated.

(30) It will also be appreciated that the device manufacturing process may be simplified by generating multiple challenges and responses from meta-keys. The manufacturing process may be further simplified using the same meta-keys for multiple devices. Similarly, meta-key allocation may be in accordance with different sub-groups of the overall population of CE devices 100. In some configurations, MK.sub.IRD may even be defined as equivalent to MK.sub.CHALLENGE; as long as the derivation processes of steps 220 and 225 are not parallel, equivalent meta-keys may not produce identical series K.sub.CHALLENGE-i and K.sub.IRD-i. Any of these methods may be employed singly or in combination to reduce the complexity entailed by the explicit provision of a unique series of authentication challenges and proxy responses for every CE device 100.

(31) It will further be appreciated that other information may be exchanged between CE device 100 and authentication server 10 as part of the authentication process. For example, CE device 100 may also send a copy of device ID 135 to authentication server 10 in addition to UK.sub.IRD-i.

(32) The inventors of the present invention have realized that the response function agnostic authentication methods described hereinabove may also be implemented to authenticate a receiving device in a broadcast system. In such a system, instead of returning K.sub.IRD-i to authentication server 10, it may be used as a key to decrypt encrypted media that may broadcast by the service provider.

(33) Reference is now made to FIG. 4 which illustrates a response function agnostic, broadcast decryption system 400. System 400 may comprise broadcast headend 500 and CE device 600. Server 500 may be configured to broadcast encrypted media to be played on CE device 600. CE device 600 may be similar to CE device 100 in that it may be any suitable device for receiving such a broadcast, such as, but not limited to, a set-top box, personal computer, tablet, handheld communications device and the like. It will be appreciated that broadcast headend 500 may provide such broadcast services to multiple CE devices 600. However, in the interests of clarity, only one CE device 600 may be depicted in FIG. 4.

(34) As with CE device 100, CE device 600 may comprise I/O module 110, response generator 150, authentication storage unit 130, and CHALLENGE responder 140. CE device 600 may employ methods such as, but not limited to, process 200 to generate and store a series of EK.sub.IRD-i and associated i in authentication storage unit 130. CE device 600 may also comprise media player 160. Media player 160 may be any suitable functionality suitable for playing media such as that transmitted by broadcast headend 500.

(35) Broadcast headend 500 may comprise authentication server 10, encryption module 510, media database 520 and transmitter 530. Media database 520 may be configured to store media for broadcast via transmitter 530. As described hereinabove, authentication server 10 may be configured to generate K.sub.IRD-i associated with CE device 600 for a given i. Encryption module 510 may be configured to encrypt media prior to broadcast.

(36) In operation, encryption module 510 may receive K.sub.IRD-i from authentication server 10 and use it to encrypt media received from media database 520 prior to broadcast. Encryption module 510 may use K.sub.IRD-i as an encryption key to directly encrypt the media. Alternatively, K.sub.IRD-i may serve as an input key for a key ladder function that may derive the actual encryption key to be used by encryption module 510 to encrypt the media. Encryption module 510 may be configured to use any suitable encryption protocol including, for example, AES or DES. Encryption module 510 may forward the now encrypted media to transmitter 530 for broadcast to CE devices 600. It will be appreciated that broadcast headend 500 may comprise other broadcast functionality that in the interests of clarity may not be depicted in FIG. 4.

(37) Authentication server 10 may forward i and its associated K.sub.CHALLENGE-i to transmitter 530. Transmitter 530 may be configured to broadcast the encrypted media to CE devices 600 along with i and K.sub.CHALLENGE-i. It will be appreciated that i and K.sub.CHALLENGE-i may be transmitted periodically in order to accommodate an unknown viewing schedule for users of devices 100.

(38) I/O module 110 may receive the encrypted media as well as i and K.sub.CHALLENGE-i, heretofore referred to as Ri and RK.sub.CHALLENGE-i to indicate that they have been received from broadcast headend 500. I/O module 110 may forward Ri and RK.sub.CHALLENGE-i to challenge responder 140. Challenge responder 140 may use a process similar, but not limited to, steps 310-330 from process 300 to derive UK.sub.IRD-i. It will be appreciated that as described hereinabove, UK.sub.IRD-i may be equivalent to K.sub.IRD-i. Accordingly, UK.sub.IRD-i may facilitate the decryption of the encrypted media received from transmitter 530. For example, if K.sub.IRD-i was used as the encryption key to encrypt the media, UK.sub.IRD-i may be used as the decryption key. If K.sub.IRD-i was used as input to a key ladder function to derive the encryption key, then UK.sub.IRD-i may be input to an identical key ladder function to derive the decryption key.

(39) Accordingly, instead of returning UK.sub.IRD-i to authentication server 10 as in step 340 of process 300, challenge responder 140 may employ encryption module 145 to decrypt the encrypted media. The resulting decrypted media may then be suitable for playing on media player 160.

(40) It will be appreciated that in such manner system 400 may provide a response function agnostic solution for the broadcast and receipt of encrypted media. The response function in use on CE device 600 may be unknown to the operator of broadcast headend 500. However, it may still be used to decrypt encrypted broadcasts from broadcast headend 500.

(41) It will also be appreciated that in contrast to process 300, there may be no need to return UK.sub.IRD-i to authentication server 10, which may make it more difficult for a hacker to acquire both “pieces” of a challenge pair by intercepting K.sub.CHALLENGE-i as it may be received from authentication server 10 and similarly intercepting UK.sub.IRD-i as it may be returned to authentication server 10. Acquiring UK.sub.IRD-i in such manner may be used to circumvent the need for decryption of EK.sub.IRD-i. However, in system 400, UK.sub.IRD-i may not be returned in the clear, thus providing further protection against such an attack.

(42) In practice, some or all of these functions may be combined in a single physical component or, alternatively, implemented using multiple physical components. These physical components may comprise hard-wired or programmable devices, or a combination of the two. In some embodiments, at least some of the functions of the processing circuitry may be carried out by a programmable processor under the control of suitable software. Alternatively or additionally, the software may be stored in tangible, non-transitory computer-readable storage media, such as optical, magnetic, or electronic memory.

(43) It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example, as a computer program product; on a tangible medium; or as a signal interpretable by an appropriate computer.

(44) It will be appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable sub-combination.

(45) It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined by the appended claims and equivalents thereof.