WO2014154236A1

WO2014154236A1 - Obtaining or providing key data

Info

Publication number: WO2014154236A1
Application number: PCT/EP2013/056261
Authority: WO
Inventors: Shengbo Xu
Original assignee: Irdeto B.V.
Priority date: 2013-03-25
Filing date: 2013-03-25
Publication date: 2014-10-02

Abstract

A method for a device to obtain a cryptographic key for use in a cryptographic process, the method comprising: receiving key data, the key data comprising a message and a verification code; deriving an authentication code based on the message; determining whether the verification code matches the authentication code; and if the verification code matches the authentication code then enabling the device to perform a cryptographic operation on the received key data using a key associated with the device to obtain the cryptographic key for use in the cryptographic process, and if the verification code does not match the authentication code then not enabling the device to perform the cryptographic operation on the received key data.

Description

OBTAINING OR PROVIDING KEY DATA

Field of the invention The invention relates to a method for a device to obtain a cryptographic key for use in a cryptographic process, a method for providing a cryptographic key to a device for use in a cryptographic process, and systems and computer programs arranged to carry out such methods. Background of the invention

Figure 1a of the accompanying drawings schematically illustrates a system 100 providing secure content delivery. The system 100 comprises a content provider system 102, a network 104 and a receiver 106. The content provider system 102 is arranged to transmit, data to the receiver 106 via the network 104.

The network 104 may be any kind of network suitable for transmitting or communicating data from the content provider system 102 to the receiver 106. For example, the network 104 could comprise one or more of a local area network, a wide area network, a metropolitan area network, the internet, a wireless communications network, a cable network, a digital broadcast network, a satellite communication network, a telephone network, etc. The content provider system 102 may then communicate with the receiver 106 over the network 104 via any suitable communication mechanism/protocol in order to communicate data from the content provider system 102 to the receiver 106.

The content provider system 102 may be any system that is suitable for communicating data to the receiver 106 via the network 104. The content provider system 102 comprises one or more processors 110, a memory 1 12 and a network interface 114. The network interface 114 is arranged to interface with the network 104 to enable the content provider system 102 to communicate with the network 104 (so that the content provider system 102 can then communicate with the receiver 106 via the network 104). The content provider system 102 may store, in the memory 112, data to be transmitted to the receiver 106. This data may be generated by the processors) 110 and/or may be data that the content provider system 102 receives from another system (not shown in figure 1 a).

As examples, the content provider system 102 could be a headend system of a digital broadcast system (in which case the network 104 could comprise a terrestrial broadcast network or a satellite broadcast network) or the content provider system 102 could be a headend system of a cable network system (in which case the network 104 could comprise a cable network). The content provider system 102 could comprise one or more servers for transmitting, or providing access to, data over the internet (in which case the network 104 may comprise the internet). However, it will be appreciated that the content provider system 102 may take other forms instead.

The data to be transmitted from the content provider system 102 to the receiver 106 comprises content Z and conditional access data. The content Z may be any form of content, and may comprise one or more of video data, image data, audio data, multimedia data, text data, software (or a computer

program/module), etc. The content Z may be provided to the content provider system 102 by a separate system (not shown in figure 1 a) for the content provider system 102 to then provide to the receiver 106. The content Z is transmitted in encrypted (scrambled) form. In particular, one or more sections of the content Z may be encrypted with a respective control word CW (an

encryption/decryption key) - the CW to be used to encrypt a current amount of content Z may be changed on a regular basis, e.g. once every couple of seconds. Figure 1a illustrates encrypted content {Z}cw being transmitted from the content provider system 102 to the receiver system 106 - in general, throughout this description, an amount of data X that is encrypted and for which a decryption key K is required to decrypt the encrypted data to obtain the clear text data X is represented as {X}k. The conditional access data may comprise data which the receiver 106 can, if sufficiently authorised, use to gain access to the encrypted content - this typically includes entitlement control messages (ECMs) and entitlement management messages (EMMs). This shall be described in more detail shortly. The content Z and the conditional access data may be encoded as respective data streams that are multiplexed together in a single transport stream that is transmitted from the content provider system 102 to the receiver 106 via the network 104.

The content provider system 102 may comprise one or more conditional access (CA) and/or digital rights management (DRM) systems or modules (which may be executed by the processors) 110) which are responsible for performing the encryption of the content Z, the generation and cycling of CWs, and the generation of the conditional access data (e.g. ECMs and EMMs) according to the authorization of subscribers. This is illustrated in more detail in figure b of the accompanying drawings, as set out in more detail later.

The receiver 106 may be any system that is suitable for receiving data from the content provider system 102 over the network 104. The receiver 106 comprises a network interface 120, a receiver device (or module) 122, and a decoder 124. The receiver device 122 may be implemented as hardware (e.g. a receiver chip set) or may be implemented as obfuscated software or firmware executed on a processor inside the receiver 106.

The network interface 120 is arranged to interface with the network 104 to enable the receiver 106 to receive data from the network 104. Data received by the network interface 120 is passed to the receiver device 122. The receiver device 122 passes conditional access data that it receives to a secured module 130 (e.g. a smart card) communicably coupled to the receiver device 122. The secured module 130 processes the conditional access data and, if the secured module 30 is authorised to provide access to the received content Z, the secured module 130 provides information over a communication channel or interface 140 to the receiver device 122 that enables the receiver device 122 to decrypt the encrypted content {Z}cw - this information could be the CW itself or information from which the receiver device 122 is able to generate the CW. The receiver device 122, upon obtaining a valid CW, decrypts the encrypted content {Z}cw using the CW so as to produce the clear text content Z. The receiver device 122 is arranged to pass the content Z to the decoder module 124. The decoder module 124 is arranged to perform any decoding necessary (e.g. data

compression decoding), formatting, signal generation, etc. so as to output the content Z in a suitable form (e.g. a signal for provision to a television). In some systems, the decoder module 124 is not part of the receiver 106 but may, instead, form part of a separate system (such as a television). In other systems, the decoder module 124 and the receiver device 122 may be implemented within the same hardware and/or software.

Typically, an ECM contains a CW that the receiver 106 needs to decrypt the encrypted content {Z}cw, or at least information by which the receiver 106 can generate the CW. In order to secure the CW so that only authorised receivers 106 can access the content Z, the content of the ECM is encrypted using a key PK. An EMM is transmitted to the receiver 106, where the EMM contains the key PK. The key PK is contained in the EMM in encrypted form - this is performed in a manner that only the secured module 130 (or a group of secured modules 130) can decrypt (e.g. using a public key associated with a private key of the secured module 130, or using a secret key shared only by the secured module 130 and the content provider system 102). The EMM is, therefore, targeted at the specific secured module 130 (or group of secured modules 130) and will only have been transmitted by the content provider system 102 if the content provider system 102 wishes (or has been instructed) to provide the subscriber/user associated with the secured module 130 access to the content Z. The secured module 130 to which the EMM is targeted can decrypt the content of the EMM to access the key PK. The secured module 130 can then use the key PK to decrypt the content of the ECM, and can then pass some or all of the content of the ECM, via the interface 140, to the receiver device 122 to enable the receiver device 22 to decrypt the encrypted content {Z}cw-

The secured module 130 (sometimes referred to as a conditional access (CA) client and/or a digital rights management (DRM) client) may take one of several forms. For example, the secured module 130 may be a smart card (or chip) with embedded software for carrying out the above functionality, the smart card being removable from the receiver 106; or the secured module 130 may be implemented as obfuscated software or firmware executed on a processor inside the receiver 106 (an example of which is disclosed in EP2227015 - for example, figures 3 and 7 thereof and their associated descriptions - the entire disclosure of EP22270 5 is incorporated herein by reference). As examples, the receiver 106 may comprise one or more of a set-top- box, a personal computer, a mobile telephone, a games console, etc., but it will be appreciated that the receiver 106 may take other forms instead.

Although a single content provider system 102, a single network 104 and a single receiver 106 are illustrated in figure 1a, it will be appreciated that the system 100 could comprise multiple content provider systems 102, multiple networks 104 and multiple receivers 106, and that figure 1 a has been simplified for ease of illustration. In particular, each content provider system 102 may provide data to multiple receivers 106 over one or more networks 104, and each receiver 106 may receive data from multiple content provider systems 102 over one or more networks 104.

Figure 1 b of the accompanying drawings schematically illustrates more details of an example content provider system 102. The content provider system 102 comprises a CA system that stores, in a key database, one or more keys that the CA system needs - for example: the CA system may store in the key database a respective unique key (CSUK) associated with each of the various receiver devices 122 with which the CA system is associated; the CA system may store in the key database secret keys shared between the CA system and the secured modules 130 (with these secret keys being used to secure EMMs targeted at those secure modules 130); etc. The CA system may also store, in a subscriber database, various subscriber information, e.g. authorisations of subscribers/users associated with the secured modules 130. The CA system comprises an EMM generator (EMMG) and an ECM generator (ECMG) that generate EMMs and ECMs respectively - this is coordinated by a subscriber management system (SMS). In particular, a CW is generated by a CW generator CWG (which may also act as a Simulcrypt Synchroniser SCS). The SMS uses the generated CW and, based on the subscriber information from the subscriber database and the key information from the key database, instructs the ECMG to generate ECMs containing the CW and instructs the EMMG to generate EMMs associated with the generated ECMs and targeted at specific authorised subscribers (or their secured modules 130). As mentioned above, the content of an ECM is encrypted using a key PK. The key PK is contained in an associated EMM. The content of the EMM is encrypted using a key associated with a target secured module 130 (this key being retrieved by the SMS from the key

database). An EMM may, additionally or alternatively, contain a secure key termed a session key LK, together with an encrypted form of that session key {LKJCSUK (encrypted using the unique key CSUK of a target receiver device 122). The content provider system 102 comprises a multiplexer that multiplexes together (a) a content data stream; (b) a data stream comprising the EMMs generated by the EMMG; and (c) a data stream comprising the ECMs generated by the ECMG - the multiplexer outputs a transport stream. A scrambler then scrambles portions of the content data stream in the transport stream using the generated CW. This scrambled transport stream may then be communicated to receivers 106 via the network 104. The above description of figure 1 b is well- known in this field of technology and shall not be described in more detail herein.

The skilled person will appreciate that the above system 100 and variants thereof are well known and, therefore, no further details need be provided herein for such conventional systems.

As mentioned above with reference to figure 1a, the CW (or information from which the receiver device 122 can obtain the CW) is communicated over the interface 140 from the secured module 130 to the receiver device 122. For ease of explanation, the rest of the description shall refer to the CW itself being communicated to (or received at or obtained at) the receiver device 122, but it will be appreciated that the description applies equally to information from which the receiver device 122 can obtain the CW.

The interface 140 needs to be secure. If the interface 140 is not secure, then an attacker can monitor the interface 140 and read the CWs and distribute them to other receivers 106 whose subscribers/users (or, equivalently, their associated secured modules 130) are not authorised to access the content Z so that those subscribers/users can access the content Z in an unauthorised manner.

Figure 2a of the accompanying drawings schematically illustrates the use of a so-called "key ladder" to secure the interface 140. A "key ladder" represents a hierarchy or a set (or group or collection) of one or more keys by which key data (e.g. a cryptographic key or information used to generate or obtain a cryptographic key) can be secured. For example, the key ladder may comprise one or more encryption keys (e.g. for encrypting the key data using a first encryption key and then encrypting that encrypted data or the first encryption key using a second encryption key, and so on); the key ladder may comprise one or more corresponding decryption keys by which the original key data may be obtained (i.e. by undoing the encryption performed using the encryption keys). It will be appreciated that the encryption keys may be the same as the decryption keys when using symmetric encryption algorithms. It will be appreciated that a sender of the key data may use some of the keys of the key ladder (e.g.

encryption keys and/or signature keys) to secure the key data, and that a receiver of the secured key data may use other keys of the key ladder (e.g. decryption keys and/or authentication keys) to obtain the initial key data from the secured key data.

In the example shown in figure 2a, the secured module 130 receives the encrypted control word {CW}_PK (e.g. in an ECM) as set out above. Assuming that the secured module 130 has access to the key PK (e.g. if an EMM containing the key PK has been sent to the secured module 130), then the secured module 130 can decrypt the encrypted control word {CW}_PK to obtain the CW. The secured module 130 may then encrypt the CW to form an encrypted control word {CW}LK using a session key LK known to both the secured module 130 and the receiver device 122 - i.e. the session key LK is required to decrypt this encrypted control word {CW}LK- The secured module 130 may then provide the encrypted control word {CW}LK to the receiver device 122 over the interface 140 - thus, the interface 140 is secured. The receiver device 122, knowing the session key LK, can decrypt the encrypted control word {CW}LK to obtain the CW.

The receiver device 122 comprises a key ladder module 200. The key ladder module 200 is arranged to perform cryptographic processing using one or more keys of the key ladder to obtain initial key data from secured key data that the key ladder module 200 receives (this secured key data having been formed from the initial key data secured using one or more keys of the key ladder). The cryptographic processing may be, for example, decryption and/or authentication, as appropriate, depending on the cryptographic processing that was applied to the initial key data to obtain the secured key data. For the example of figure 2a, the key ladder module 200 is arranged to decrypt the received encrypted control word {CW}LK to obtain the CW using the session key LK. As the receiver device 122 is also arranged to carry out the decryption of the encrypted content {Z}cw using the obtained CW (implemented using a decryption module 310 in figure 2a) the clear text CW is not made available on an external interface of the receiver device 122.

Figure 2b of the accompanying drawings schematically illustrates more detail of an example key ladder module 200 (which is discussed in more detail in European patent applications 10154151.4, 10193312.5 and 11250650.6, for example, the entire discloses of which are incorporated herein by reference). In particular, an EMM provided by the content provider system 102 may contain: (a) a session key (LK) and (b) the session key LK encrypted using a unique key (CSUK) unique to the receiver device 122 (or to the key ladder module 200 of the receiver device 122), i.e. {LK}csuK (in the above-mentioned European patent applications, the session key LK is referred to as "CSSK"). The unique key CSUK may be generated by the receiver device 122 during the manufacture or creation of the receiver device 122 (e.g. during manufacture of a chip for the receiver device 122); the unique key CSUK may be generated by the

manufacturer of the receiver device 122 and installed into the receiver device 122 during the manufacture/initialisation of the receiver device 122. The unique key CSUK, along with an identification (CSID) of the associated receiver device 122, may then be provided (in a tightly controlled distribution) from the manufacturer of the receiver device 122 to an associated CA system of the content provider system 102. The unique key CSUK is stored securely in the receiver device 122 (i.e. after initialisation, it cannot be read via an external interface) and is kept as a closely guarded secret by the CA provider operating that CA system of the content provider system 102. The content provider system 102 may have generated the session key LK in any way (e.g. as a random number). The secured module 130 can obtain the session key LK from the EMM. The secured module 130 may pass the encrypted session key, encrypted with the unique key CSUK, i.e. {LKJCSUK. to the receiver device 122, or its key ladder module 200, and the key ladder module 200 may then decrypt {LKJCSUK using the unique key

CSUK. In this way, both the secured module 130 and the receiver device 122 obtain the session key LK. The key ladder in this example thus comprises: (a) the key LK for the secured module 130 to use and; (b) the keys CSUK and LK for the receiver device 122 and the content provider system 102 to use.

It will be appreciated that other methods for establishing the session key LK between the secured module 130 and the receiver device 122 may be used. For example, instead of the content provider system 102 generating the session key LK and informing the secured module 130 and the receiver device 122 of that session key LK, the session key LK may be generated by the secured module 130 and may be communicated to the receiver device 22 in encrypted form

{LKJCSUK - the secured module 130 may have been informed of the unique key CSUK by the receiver device 122 in a secured communication between the secured module 130 and the receiver device 122. Other variants are known or could be used.

In the example shown in figure 2b, the keys of the key ladder are symmetric/secret keys, and hence the key ladder module 200 makes use of symmetric cryptographic algorithms (implemented as decryption modules "D" in figure 2b). However, it will be appreciated that the key ladder module 200 may, additionally or alternatively, make use of an asymmetric cryptographic algorithm - for example, the session key LK may be a private key known only by the receiver device 122, with the secured module 130 using the corresponding public key to carry out the encryption of the CW. For example, European patent applications 0193312.5 and 11250650.6 disclose how the secured module 130 may encrypt a virtual CW (CW*) using a public key CSPK of the receiver device 122. Here, the public key CSPK and its associated private key CSSK may be generated by, or initialised in, the receiver device 122 during the manufacture or creation of the receiver device 122 (e.g. during manufacture of a chip for the receiver device 122) - the public key CSPK may then be distributed as required. The encrypted CW* may also have a digital signature applied using a private key SK of the secured module 130. Here, the private key SK and its associated public key PSK may be generated by, or initialised in, the secured module 130 during the manufacture or creation of the secured module 130 - the public key PSK may then be distributed as required. The signed and encrypted CW* is provided to the receiver device 122. The receiver device 122 may use the public key PSK (corresponding to the private key SK) of the secured module 130 to verify the digital signature, and may then use its own private key CSSK (corresponding to the public key CSPK) to decrypt the encrypted CW* to obtain CW*. The receiver device 122 then uses CW* and the public key PSK of the secured module 130 as inputs to a hash function, the output of which is the CW to use. In this case, the key ladder comprises: (a) keys CSPK and SK for the secured module 130 to use and; (b) keys CSSK and PK for the receiver device 122 to use.

It will be appreciated that key ladders, and key ladder modules 200, may be implemented in many other ways. Such key ladder modules 200 are often proprietary to, or specific to, particular CA providers - hence, different key ladder modules 200 for different CA providers may function, or use keys, in different ways. In general though, a key ladder module is arranged to receive a secured form of an initial amount of data and to obtain, from that secured form of the initial amount of data, that initial amount of data using one or more corresponding keys (of the key ladder). In such a scenario, the initial amount of data was secured (to form the secured form of the initial amount of data) using corresponding keys of the key ladder. Thus, the receiver device 122 may implement a key ladder module 200 to secure the interface 140 between the receiver device 122 and the secured module 130. The key ladder used by a key ladder module 200

comprises initialization data to uniquely configure that key ladder - this could be, for example, the unique key CSUK initialized and stored in the key ladder module 200, and known to the associated CA system, for the example described above with respect to figure 2b.

Although as mentioned above with reference to figure 2a, the receiver device 122 is arranged both to decrypt the received encrypted control words

{CW}LK and to carry out the decryption of the encrypted content {Z}cw using the obtained CW, and thus the clear text control word CW is not made available on an external interface of the receiver device 122, an attacker might try to intercept the CW as it is sent between the key ladder module 200 and the content descrambler 310 which decrypts the encrypted content {Z}_Cw using the clear text control word CW. This might be possible in practice if, for example, the key ladder module 200 and the content descrambler were implemented as separate chips connected by circuit traces on a module. To prevent such interception, receiver devices 122 may implement the key ladder module 200 and descrambler 310 in a single integrated circuit "chip" or "device", such that the interface between those modules is difficult to probe during operation. Such a chip is herein termed a "secured chip" or "secured device".

Message Authentication Codes (or "MACs") are well-known. A MAC is associated with a message, the integrity and/or origin of which is to be

authenticated. A source of a message generates a MAC from the message, using a predetermined function and a secret key K - this predetermined function may be viewed as a keyed hashing function. The MAC is sent with the message to a message receiver. The receiver may generated a second MAC from the received message (using the same predetermined function and secret key K) and compare the second MAC against the received MAC - if the two MACs match, then the origin of the message can be authenticated (as only a source with knowledge of the secret key K may have generated the MAC that accompanied the message) and the integrity of the message can be authenticated (as the second MAC would not match the first MAC if the message received by the receiver had been modified).

Figure 3 of the accompanying drawings schematically illustrates an example of a MAC authentication scheme, including a sender 410 and a receiver 420 which respectively generate and use a MAC to authenticate a message 430 which the sender 410 wishes to send to the receiver 420. The sender 410 uses a secret key K, known to both the sender 4 0 and the receiver 420, as input to a MAC algorithm 415 (a predetermined function, e.g. a cryptographic operation such as a keyed-hash calculation) which operates on the message using the key K to produce a first MAC 440. The sender 410 sends the message 430 and the MAC 440 to the receiver 420. The receiver 420 separates the message 430 from the MAC 440, and generates a second MAC (shown as MAC* in figure 3) 450 for the received message by using the same secret key K and a corresponding MAC algorithm 425 (which is identical to the MAC algorithm 415 in the sender). If the first MAC 440 is identical to the second MAC 450 then the message has been authenticated; otherwise the authentication fails.

In 1998, Paul Kocher et al introduced "Simple Power Analysis (SPA) and

Differential Power Analysis (DPA)" in a document: P. Kocher, J. Jaffe, B. Jun, "Differential Power Analysis, Advances in Cryptography" - Crypto'99, LNCS 1666, pp. 388-397, Springer, 1999 (hereafter referred to as the Kocher

document) which dealt with extracting cryptographic keys by measuring the power dissipation of a cryptographic module during key ladder processing.

In 2001 , Jean Jacque Quisquater et al introduced "Simple Electro- Magnetic Analysis (SEMA)" and "Differential Electro-Magnetic Analysis (DEMA)" techniques in a document: J. J. Quisquater and D. Samyde, "Electromagnetic analysis (EMA): Measures and counter-measures for smart cards", Proceedings of the International Conference on Research in Smart Cards: Smart Card

Programming and Security (E-smart), I. Attali and T. Jensen, Eds., 2001 , vol. 2140 of LNCS, pp. 200-210, Springer- Verlag (hereafter referred to as the

Quisquater document).

DPA and DEMA have posed a critical threat to the security of secret keys and secret key derivation schemes as used, for example, in receiver devices 122. Both DPA and DEMA involve measuring the power consumption of a device while the device performs a cryptographic operation (e.g. the decryption of {LKJcsu_K using the unique key CSUK of the receiver device 122). Such

measurements can be performed, for example, using a digital oscilloscope and other commonly available equipment so as to tap into the power supply of a device under observation, and thereby measure and store a trace of the power supply voltage and/or current while the device is performing the cryptographic operation. By correlating the power consumption of the device with pre- computed (or estimated) values, such techniques can derive a secret key used in the cryptographic operation (e.g. the unique receiver key CSUK in the above examples).

In more detail, a DPA/DEMA attack is typically carried out in five stages: i) select a key-dependent value in the cryptographic algorithm to be observed;

ii) collect power traces from the device while it is performing a number of cryptographic operations on known input values (e.g. while it is encrypting a number of known plaintexts or decrypting a number of known cipher texts); iii) calculate hypothetical intermediate values for every possible value of the selected key-dependent value;

iv) select a consumption model for the device and accordingly construct a selection function (or look-up-table) to classify the hypothesized consumptions; and

v) correlate the hypothetical consumptions with measured consumption values, and select the hypothesis which best fits the measured behaviour, as the correct key candidate.

Further details of DPA can be found in the Kocher document, and further details of DEMA can be found in the Quisquater document.

So-called "side channel" attacks have been successfully used against receiver devices 122 (including secured chips) to derive secret keys, such as the unique key CSUK - if an attacker is able to derive the value of CSUK, then he can, in future, obtain and distribute (in an unauthorised manner) keys or other conditional access data to enable other users to gain access to encrypted content, even if those other users are not entitled to access that content. In general, side channel attacks operate by sending a large number of different inputs to the device being analysed, and monitoring and analysing the power consumption of the device (e.g. power supply voltage and/or current) and/or the electromagnetic emissions from the device whilst the key ladder module 200 processes those different inputs. For example, secret keys (such as, for example, the unique key CSUK of a receiver device 122) can sometimes be derived using a few million power traces. Since existing DPA/DEMA test environments can collect on average 1 million power traces per day, an attacker can typically carry out a successful attack in about 1 week. This is a significant threat to the security of the key ladder module 200. Summary of the invention

The invention provides a countermeasure to help reduce the likelihood of a DPA attack or a DEMA attack being successful.

However, existing key ladder designs are widely adopted and supported, and thus any change to the interface of the key ladder module 200 would be undesirable. Thus, although it is desirable to overcome the above-identified vulnerability of existing key ladder modules 200 to side channel attacks, it would be desirable to reduce the aforementioned vulnerability without modifying the interface to the key ladder module 200 (i.e. the nature and number of the inputs to and outputs from the key ladder module 200). Embodiments of the invention address this additional problem, as described below.

According to a first aspect of the invention, there is provided a method for a device to obtain a cryptographic key for use in a cryptographic process, the method comprising: receiving key data, the key data comprising a message and a verification code; deriving an authentication code based on the message;

determining whether the verification code matches the authentication code; and if the verification code matches the authentication code then enabling the device to perform a cryptographic operation on the received key data using a key associated with the device to obtain the cryptographic key for use in the cryptographic process, and if the verification code does not match the

authentication code then not enabling the device to perform the cryptographic operation on the received key data.

The cryptographic operation may comprise a decryption operation on the received key data using the key associated with the device.

The cryptographic process may comprise decrypting a received encrypted control word using the cryptographic key, the control word for decrypting encrypted content.

The method may comprise performing the cryptographic operation on the received key data using the key associated with the device to obtain the cryptographic key for use in the cryptographic process if the verification code matches the authentication code. According to a second aspect of the invention, there is provided a method for providing a cryptographic key to a device for use in a cryptographic process, the method comprising: obtaining a message; deriving an authentication code based on the message; sending key data comprising the message and the authentication code to the device, to thereby enable the device to perform a cryptographic operation on the key data using a key associated with the device to obtain the cryptographic key.

The message may be obtained by generating the message using random or pseudo-random data.

The method may further comprise: carrying out a cryptographic operation on the key data using the key associated with the device, thereby generating the cryptographic key; and encrypting a control word using the cryptographic key, the control word for decrypting encrypted content.

With the first or second aspect, the width of the message may be selected such that the number of possible values of the message is fewer than a number of performances of the cryptographic operation by the device which are required to successfully carry out a side-channel attack on the cryptographic operation at the device.

With the first or second aspect, the deriving an authentication code may be performed using a predetermined function based on the message.

The predetermined function may comprise a cryptographic function operating on the message using the key associated with the device. The cryptographic function may be a cryptographic hash of the message using the key associated with the device.

The predetermined function may comprise cryptographically processing, using the key associated with the device, the message and a predetermined initialisation vector to generate a result; wherein the authentication code is the whole or a part of the result.

The predetermined function may comprise: extending the message with a predetermined initialisation vector to produce an extended message;

cryptographically processing the extended message using the key associated with the device to generate a result; and selecting a portion of the result as the authentication code.

The width of the message may be selected such that the number of possible values of the message is fewer than a number of performances of the predetermined function required to successfully carry out a side channel attack on the predetermined function.

According to a third aspect of the invention, there is provided a system arranged to carry out any one of the above methods.

According to a fourth aspect of the invention, there is provided a computer program which, when executed by a processor, causes the processor to carry out any one of the above methods. The computer program may be stored on a computer readable medium.

Brief description of the drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1a schematically illustrates a system providing secure content delivery;

Figure 1 b schematically illustrates detail of an example content provider system;

Figure 2a schematically illustrates the use of a so-called "key ladder"; Figure 2b schematically illustrates detail of an example key ladder module; Figure 3 schematically illustrates example of a MAC authentication scheme;

Figure 4a schematically illustrates a receiver device according to an embodiment of the invention;

Figure 4b schematically illustrates a system for generating and providing key data to the receiver device of figure 4a;

Figure 5a schematically illustrates a receiver device according to an embodiment of the invention; and Figure 5b schematically illustrates a system for generating and providing key data to the receiver device of figure 5a.

Detailed description of embodiments of the invention

In the description that follows and in the figures, certain embodiments of the invention are described. However, it will be appreciated that the invention is not limited to the embodiments that are described and that some embodiments may omit some of the features described below. It will be evident that various modifications and changes may be made herein without departing from the broader spirit and scope of the invention as set forth in the appended claims. Additionally, it will be apparent that features of certain described embodiments can be used in combination with the features of other described embodiments, as a skilled person would understand to be appropriate. Furthermore, not all features of the described embodiments are essential, the essential features being set out in the appended claims.

Embodiments of the invention will now be described with reference to the system 100 as set out above and with further modification as set out below.

Figure 4a schematically illustrates a receiver device 500 according to an embodiment of the invention. The receiver device 500 is the same as the receiver device 122 as described above, except that it also comprises a verification module 510.

The verification module 510 receives key data KD from which a

cryptographic key for use in a cryptographic operation can be derived. In the example shown in figure 5, the key data KD is the encrypted session key

{LKJcsu_K (where the session key LK is for decrypting encrypted control words CW). The verification module 510 performs authentication of the key data KD, as described below, to determine an authentication result. The verification module 510 enables or causes performance of the cryptographic operation on the key data KD (e.g. the key ladder module 200 decrypting the encrypted session key {LKJCSUK ) only if the authentication result indicates that the key data KD is authentic. This shall be described in more detail below with reference to the key data KD being the encrypted session key {LKJCSUK as shown in figure 4a, and with reference to the cryptographic operation that is to be enabled being decryption of the encrypted session key {LK}CSUK to obtain the session key LK (and the subsequent operations of the key ladder module 200) - it will, however, be appreciated that embodiments of the invention apply to other devices, and that the key data KD may be of a different nature and that the cryptographic operation may be a different cryptographic operation.

Accordingly, in an example embodiment, the verification module 510 produces an output comprising the encrypted session key {LKJCSUK only if the authentication result indicates that the received encrypted session key {LKJCSUK is authentic. This may be achieved, for example, by arranging for the verification module 510 to pass, or direct, the encrypted session key {LKJCSUK that it received to the key ladder module 200 for performance of the subsequent cryptographic operation only if the authentication result indicates that the received encrypted session key {LKJCSUK is authentic - thus, the key ladder module 200 only receives the encrypted session key {LKJCSUK if the verification module 510 determines that the encrypted session key {LKJCSUK is authentic. In other embodiments, the verification module 510 may conditionally control or enable the subsequent cryptographic operation by other means, e.g. : setting a flag indicating the authentication result (which the subsequent cryptographic operation may be arranged to use to determine whether or not to perform its processing);

controlling power to the subsequent cryptographic operation; outputting a value (e.g. a random value) instead of the encrypted session key {LKJCSUK, SO that the cryptographic operation may be performed but it would not be performed on the encrypted session key {LKJCSUK, SO that an incorrect cryptographic key would be obtained by the key ladder module 200 based on an incorrect input to the key ladder module 200; etc.

In a first embodiment, the verification module 510 is arranged to perform the following steps.

In some embodiments, the verification module 510 uses a key (such as the key CSUK) which is associated with the receiver device 500, in which case the verification module 510 may receive or obtain the key associated with the receiver device 500 (although in some embodiments, this key may be stored as an integral part of the verification module 510, so that the verification module 510 does not actually need to receive or obtain the key associated with the receiver device 500).

The verification module 510 receives input data (referred to herein as key data KD), such as an encrypted session key {LKJCSUK- The key data KD forms the whole or a part of the input to the receiver device 500.

The verification module 510 treats the key data KD as comprising a message M and a verification code V. If the key data KD is authentic, then the verification code V should be related to the message M according to a

predetermined function H (where the predetermined function H produced an authentication code H(M) for the message M), i.e. V=H(M) - in this case, the entity that generated the key data KD would have formed the key data KD so as to comprise M and H(M). If the key data KD is not authentic, then the verification code V is unlikely to be related to the message M via the predetermined function H, i.e. V≠H(M).

The function H may use, or be dependent on, a key, which in one example is the unique key CSUK associated with the receiver device 122 - this is the key that may be obtained or received as discussed above. The

predetermined function H may be a cryptographic function such as an encryption operation or a decryption operation or a (potentially keyed) hashing function. Preferably, the predetermined function H is a function for which it is infeasible to determine, without knowledge of a key, the output H(M) for any given input M, thereby making it infeasible for an attacker (who does not know that key) to generate valid key data KD comprising M and H(M). Preferably, the

predetermined function H is a function for which it is infeasible to determine, for a value A, a corresponding message M such that H(M)=A, thereby making it infeasible for an attacker to generate valid key data KD comprising M and H(M).

In the embodiment shown in figure 4a, the predetermined function H is a function to generate a MAC of the message M (using, for example, the key associated with the receiver device 500, such as the key CSUK, as the key for the MAC algorithm) - thus, the function H may be a keyed hash function. In this case, if the key data KD is authentic, then the verification code is the

authentication code (or MAC) that corresponds to the message M. A further example of the function H shall be described later, but it will be appreciated that other functions H could be used.

The verification module 510 derives, from the message M, an

authentication code H(M) using the function H. The verification module 510 may, therefore, comprise a module 530 for performing the function H.

The verification module 510 then compares the verification code V from the received key data KD with the generated authentication code H(M), using a comparison unit 540 of the verification module 510, to determine the authenticity of the received key data KD. If the result of the comparison is a match (i.e.

V=H(M)) then the key data KD is deemed to be authentic; if the result of the comparison is not a match (i.e. V≠H(M)), then the key data KD is deemed not to be authentic. If the key data KD is deemed authentic, then the verification module 510 enables the receiver device 500 to perform a cryptographic operation on the key data KD so as to obtain a cryptographic key for use in a subsequent cryptographic operation - for example by allowing the key ladder module 200 to decrypt the key data {LKJCSUK SO as to obtain LK; if the key data KD is deemed to not be authentic, then the verification module 510 does not enable the receiver device 500 to perform a cryptographic operation on the key data KD so as to obtain the cryptographic key for use in the subsequent cryptographic operation. Methods for controlling this enablement have been discussed above.

In some embodiments, the key data KD simply comprises the message M and the verification code V in clear form - for example, the message M and the verification code V may simply be concatenated to form the key data KD (e.g. by appending a MAC or other authentication code to a message), or the message M and the verification code V may simply be interleaved to form the key data KD. The module 530 may, therefore, be arranged to simply obtain the message M directly from the key data KD; similarly, the comparison unit 540 may be arranged to simply obtain the verification code V directly from the key data KD. The verification module 510 may be arranged to simply direct the relevant parts of the key data KD to the module 530 and the comparison unit 540 - this may therefore be performed by an optional extraction module 520 of the verification module 510. However, in some embodiments, the key data KD comprises the message M and the verification code V in a more complex manner - i.e. the key data KD may be some invertible function C of the message M and the verification code V so that the key data KD is equal to C(M,V), in which case the verification module 510 may comprise an extraction module 520 that is arranged to perform the inverse C^"1 of the function C on the received key data KD so as to obtain the message M (which is then provided to the unit 530) and the verification code V (which is then provided to the comparison unit 540).

As can be seen from figure 4a, the input interface to the receiver device

500 may be the same as the input interface to the receiver device 122, thereby meaning that the receiver device 500 may be used in existing receivers 106 in place of existing receiver devices 122 without any further changes or

modifications to the receivers 106. Additionally, the interface to the key ladder module 200 of the receiver device 500 may be the same as the interface to the key ladder module 200 of the receiver device 122, thereby reducing or removing any need to re-design the key ladder module 200.

Figure 4b schematically illustrates a system 501 for generating and providing key data KD (such as an encrypted session key {LKJCSUK) to the receiver device 500 of figure 4a. The system 501 may be used, for example, by the content provider system 102 (for example as part of its CA system), or (at least in part) within the secured module 130.

The system 501 comprises a key data generation module 511. The key data generation module 511 comprises a module 531 that is arranged to carry out the same predetermined function H as the module 530 of the verification module 510. The key data generation module 511 receives as input, or otherwise obtains, a message M. The message M may, for example, be generated by a random number generator or a pseudo-random number generator, or it may be generated by some other algorithm. The message generator may be part of the key data generation module 511 or separate from the key data generation module 511. The key data generation module 51 1 passes the message M to the module 531 that derives an authentication code H(M) based on the message M. As mentioned above, the function H may make use of one or more keys, such as a key (e.g. CSUK) associated with the receiver device 500, in which case the module 531 is arranged to receive, or obtain, the or each key for use in performing the function H to generate the authentication code H(M). For example, when generating key data KD for provision to a particular receiver device 122, the key data generation module 511 may be arrange to obtain the key associated with that receiver device 122 - this may be, for example, obtained from the key database of the content provider system 102 if the system 501 is implemented by the content provider system 102, or may be obtained from the receiver device 500 itself if, for example, the system 501 is implemented by the secured module 130.

The key data generation module 511 then generates key data KD by combining the authorisation code H(M) and the message M. As set out above, the message M and the authorisation code H(M) may be combined in any suitable way (e.g. by concatenating or appending them). As mentioned, in some embodiments, the key data KD is generated as an invertible function C of the message M and the authorization code H(M), so that

KD = C(M,H(M)), in which case the key data generation module 511 comprises a combining module 521 for carrying out the function C on the message M and the authorization code H(M) - here, the function C^"1 performed by the extraction module 520 is the inverse of the function C performed by the combining module 521. The system 501 may then provide the key data KD to the receiver 106.

The key data KD can also be referred to as an encrypted key {LK}CSUK- The term "encrypted" key data does not imply that the key data KD is generated by actually encrypting an amount of data (namely the session key LK), but rather means that the key data KD is treated as an amount of payload data in encrypted form - in the example shown in figures 4a and 4b, the payload data is the session key LK. Thus, generating the key data KD using the key data generation module 511 determines the corresponding payload data, namely the payload data equals the key data KD decrypted using a particular key.

For example, as shown in figure 4b, the system 501 may determine the session key LK that is to be provided to a receiver device 500 that has an associated key CSUK for its key ladder module 200 by decrypting (in a decryption module 560) the key data KD generated by the key data generation module 511 using the key CSUK as a decryption key - thus, if the verification module 510 passes the key data KD to the key ladder module 200, then the key ladder module 200 may also generate the session key LK, as set out above. The system 501 may use the generated session key LK to encrypt (using an encryption module 570) CWs that are to be provided to the receiver device 500 and provide the encrypted CWs {CW}_LK to the receiver 106. The system 501 may (for example if it is being used by the content provider system 102) be configured to encrypt content Z with the CWs and provide the encrypted content {Z}cw to the receiver 106.

Whilst the key data KD has been described above as being used in a cryptographic operation (namely decryption by decryption module 560) to generate a cryptographic key, it will be appreciated that other cryptographic operations could be used on the key data D to generate the cryptographic key, as are well-known in this field of technology (and as have been described above, e.g. based on hash functions arid/or signatures).

The system 501 provides key data KD that is compatible with (i.e. can be successfully used by) receiver devices 500 according to embodiments of the invention, as well as legacy receiver devices 122.

The number of binary bits (or width) of the message M can be denoted as |M|, the number of binary bits (or width) of the received verification code V can be denoted as |V|, the number of bits (or width) of the generated authentication code H(M) can be denoted as |H(M)|, and the number of binary bits (or width) of the key data KD can be denoted as |KD|. As mentioned, it is advantageous to maintain the width of the key data |KD| in the embodiments of the invention to be the same width S of corresponding key data (e.g. encrypted session keys

{LKJCSUK) that is input to existing receiver devices 122, so as to maintain backwards compatibility. This leads to the constraint |M| + |H(M)| = |KD| = S. Thus, the inclusion of the authentication code H(M) in the key data KD reduces the number of bits available for the message M from S to S-|H(M)|. Accordingly, the number of valid values for the key data KD (also termed the "key entropy") is reduced from 2^s to 2^|M| (for each possible value of the message M the value of the authentication code is wholly determined by the predetermined function H, and any keys used by the function H). Thus, by reducing the number of valid values of the key data KD, an attacker who is performing a side channel attack on the receiver device 500 will have fewer valid inputs to the receiver device 500 to use and observe - observations by the attacker can only be made based on the 2^|M| different valid values for the key data KD, whereas, for the 2^S-2^|M| other "invalid" values for the key data KD, the key data KD is not used in a

cryptographic operation to obtain the subsequent cryptographic key, so that the attacker cannot make worthwhile observations. Preferably, the number of valid key data KD should be configured (e.g. by selecting the width |M| of the message M and/or configuring/selecting the function H so that a desired value of |M| is given by S-|H(M)|) to be fewer than the minimum number of traces, NT, required to successfully carry out a side channel attack on the key ladder module 200, i.e. so that 2^|M|=2^S"|H(M)I < NT. This is advantageous, since as only valid key data KD are allowed by the verification module 510 to be processed (using a

cryptographic operation) to produce a cryptographic key (e.g. by the key ladder module 200), it will then be impossible (or substantially more difficult) for an attacker to carry out sufficient different key ladder module operations to successfully complete a side channel attack.

Thus, the system 501 of this embodiment generates, for a particular receiver device 122, key data KD (e.g. which represents a cryptographic key LK which is encrypted with the unique key CSUK associated with the receiver device 122), which key data comprises a message portion M and an authentication code H(M); the verification module 510 of that particular receiver device 122 can verify the authenticity of the key data KD before using it. Thus, a receiver device 500 of embodiments, equipped with a verification module 510 as described above, can verify the authenticity of the key data KD received by the receiver device 500 and, if authenticated, can enable cryptographic processing of the key data KD (e.g. by the key ladder module 200) to obtain a cryptographic key (e.g. session key LK), for use in a cryptographic process (e.g. for decrypting the encrypted control words {CW}_LK)- AS mentioned, the ability to authenticate key data before passing it to a cryptographic operation (e.g. the key ladder module 200) makes it more difficult for an attacker to successfully perform side channel attacks on a so- equipped receiver device 500.

Figure 5a schematically illustrates an embodiment of the invention, in which the receiver module 500 is arranged to carry out a particular function H. In the embodiment of figure 5a, the module 530 comprises a cryptographic function module 640, a combining module 650 and a selection module 630. The cryptographic function module 640, combining module 650 and selection module 630 together implement the function H.

The cryptographic function module 640 is arranged to implement a cryptographic function F (e.g. decryption, encryption, hashing, signature generation, etc.). Preferably, this cryptographic function F is a function that is already implemented in existing receiver devices 122 so that the cryptographic function module 640 may make use of (or be) existing resources when modifying an existing receiver device 122 so as to become a receiver device 500 of figure 5a. Additionally, re-use of such resources may help reduce additional software and/or hardware resource requirements and/or power consumption. The cryptographic function F performed by the cryptographic function module may make use of a cryptographic key which may, for example, be a key (such as CSUK) associated with the receiver device 500. The output of the cryptographic function module 640 is provided as an input to the selection module 630.

The combining module 650 is arranged to combine the message M with an initialisation vector INIT according to a combining function W, e.g. by a

concatenation operation, interleaving, or any other suitable way. The initialisation vector INIT may be derived by the receiver device 500 from a unique serial number of the receiver device 500 or other data stored in the receiver device 500, and can be generated using an existing type of initialisation function known to the skilled person. The output of the combining module 650 is provided as an input to the cryptographic function module 640. The initialisation vector INIT enables the input to the cryptographic function module 640 to be configured so that it is suitable for the cryptographic function F. For example, the message M may be 100 bits long, whereas the function F may expect an input that is 128 bits long (for example, due to the function F being implemented using a cryptographic module that would already exist in a legacy receiver device 122), in which case the function W may combine an initialisation vector INIT with the message M so as to extend the message M from being 100 bits to being 128 bits long - the initialization vector INIT could, for example, be 128 bits long and the function W could comprise XOR-ing the whole or part of the initialisation vector INIT with respective bits of the message M; or the initialisation vector INIT could be 28 bits long, and the function W may simply concatenate the message M and the initialization vector INIT.

The selection module 630 is arranged to select one or more parts of the output of the cryptographic function module 640 to generate the result H(M) of the function H. The selection of the one or more parts may be made in accordance with a function S. Thus, H(M)=(S(F(W(M,INIT)))). The function S may select the one or more parts in any suitable way so as to produce an output of the function H of the desired size (|H(M)J) - for example, the function S may select successive bits for its output from respective locations in the output of the function F according to a predetermined indexing function, or may select |H(M)| predetermined bits of the output of the function F (e.g. the first, middle or last |H(M)| bits); etc.

It will be appreciated that the combining module 650 and the cryptographic function module 640 may be combined into a single module that implements a cryptographic function F' that operates on the message M and the initialisation vector INIT, so that F'(M,INIT)=F(W(M,INIT)).

It will be appreciated that one or more of the combining module 650, the cryptographic function module 640 and the selection module 630 may be combined into a single module.

With the embodiment of figure 5a, an attacker only has the ability to provide key data comprising the message M and the verification code V - the attacker cannot modify the initialisation vector INIT. Thus, for the processing of the function H, an attacker can only affect the message M and, therefore, the cryptographic function module 640 will only perform operations on 2^|M| different possible inputs. By configuring or selecting the width |M| of the message M such that 2' ¹ is less than the number of traces (i.e. iterations or performances of the function H) required to successfully carry out a side channel attack on the module 530, the module 530 can be secured against side channel attacks on the predetermined function H (using the same reasoning as set out above for providing resistance against side channel attacks on the processing performed by the key ladder module 200).

It will be appreciated that other methods of reducing the number of possible inputs to the module 530 may be used to providing resistance against side channel attacks on the processing performed by the module 530. For example, if the function H is a keyed hash function on the message M, then there are only 2^|M| possible inputs to the function H - the size of |M| may then be set as described above.

Figure 5b schematically illustrates the system 501 shown in figure 4b, in which the function H is implemented in the same manner as set out above in the receiver device 500 of figure 5a.

Embodiments of the invention can employ the same or similar

cryptographic primitives and modules (e.g. AES or Triple-DES) as are currently implemented in existing receiver devices 122, so that embodiments of the invention can be easily incorporated in existing receiver devices 122 with minimal changes or additional resources, thus saving development time and cost.

Although the key data KD is not completely random (since only the message portion M is random, the verification code V being determined from the message portion M using a predetermined function H), the message M still has sufficient randomness to defeat exhaustive search for the cryptographic key that is to be obtained from the key data KD (namely the key LK in the examples shown in figures 4a, 4b, 5a and 5b). This can be achieved by selecting the cryptographic operation that is to be used on the key data to derive the

subsequent cryptographic key (e.g. the key LK) as one that has good

randomness properties (as would be known to the person skilled in this field of technology), e.g. by making use of an encryption or decryption algorithm to generate the subsequent cryptographic key from the key data KD. The term "key data" should not be taken to mean data which is necessarily a cryptographic key; rather it may be data from which a key can be derived.

Although the foregoing description focuses on protecting the key CSUK in receiver devices 500 for a receiver 106, the verification module 510 may be implemented in other types of device, such as the secured module 30 or Radio Frequency IDentification (RFID) tokens in order to protect such other devices against an attacker using side channel attacks to determine secret key

information stored and used by those devices.

It will be appreciated that the key ladder modules 200 and the verification module 510 may make use of any suitable cryptographic algorithms, mechanisms and protocols. In particular, any encryption/decryption algorithm could be used - these may include symmetric encryption/decryption algorithms (such as AES, DES, etc.); these may include asymmetric encryption algorithms (such as RSA, elliptic curve cryptography, etc.).

It will be appreciated that, whilst the key ladder implemented by the key ladder module 200 has been described above as comprising the secret key CSUK and the session key LK, the key ladder may comprise further keys and it will be appreciated that the same applies analogously to the other key ladders and key ladder modules 200 of the other embodiments described above. It will also be appreciated that embodiments of the invention may make use of key ladders and key ladder modules that operate differently from the versions discussed above.

The module 531 (and thus the function H) has been described, for some embodiments, as using the key CSUK that is associated with the receiver device 500, this being the same key that is used in the processing of the key ladder module 200 to determine a cryptographic key from the key data KD. This is convenient, as it only requires the use and storage of a single key associated with the received device 500. However, it will be appreciated that, in some embodiments of the invention, the key that is associated with the receiver device that is used by the module 531 (and thus the function H) may be different from the key that is used in the processing of the key ladder module 200 to determine a cryptographic key from the key data KD - this may be viewed as providing increase security.

It will be appreciated that the methods described have been shown as individual steps carried out in a specific order. However, the skilled person will appreciate that these steps may be combined or carried out in a different order whilst still achieving the desired result.

It will be appreciated that the description of the above systems and methods has been simplified for purposes of discussion, and the above systems and methods are just one of many different types of system and method that may be used for embodiments of the invention. It will be appreciated that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or elements, or may impose an alternate decomposition of functionality upon various logic blocks or elements.

It will be appreciated that the above-mentioned functionality and modules may be implemented as hardware and/or software: For example, the above- mentioned modules may be implemented as one or more software components for execution by a processor of the system, for example as obfuscated software or firmware, potentially for execution in a secure processing environment.

Alternatively, the above-mentioned modules may be implemented as hardware, such as on one or more field-programmable-gate-arrays (FPGAs), and/or one or more application-specific-integrated-circuits (ASICs), and/or one or more digital- signal-processors (DSPs), and/or other hardware arrangements.

It will be appreciated that, insofar as embodiments of the invention are implemented by a computer program, then a storage medium and a transmission medium carrying the computer program form aspects of the invention. The computer program may have one or more program instructions, or program code, which, when executed by a computer carries out an embodiment of the invention. The term "program," as used herein, may be a sequence of instructions designed for execution on a computer system, and may include a subroutine, a function, a procedure, an object method, an object implementation, an executable

application, an applet, a servlet, source code, object code, a shared library, a dynamic linked library, and/or other sequences of instructions designed for execution on a computer system. The storage medium may be a magnetic disc (such as a hard drive or a floppy disc), an optical disc (such as a CD-ROM, a DVD-ROM or a BluRay disc), or a memory (such as a ROM, a RAM, EEPROM, EPROM, Flash memory or a portable/removable memory device), etc. The transmission medium may be a communications signal, a data broadcast, a communications link between two or more computers, etc.

Claims

1. A method for a device to obtain a cryptographic key for use in a

cryptographic process, the method comprising:

receiving key data, the key data comprising a message and a verification code;

deriving an authentication code based on the message;

determining whether the verification code matches the authentication code; and

if the verification code matches the authentication code then enabling the device to perform a cryptographic operation on the received key data using a key associated with the device to obtain the cryptographic key for use in the cryptographic process, and if the verification code does not match the

2. The method of claim 1 wherein the cryptographic operation comprises a decryption operation on the received key data using the key associated with the device.

3. The method of any one of the preceding claims wherein the cryptographic process comprises decrypting a received encrypted control word using the cryptographic key, the control word for decrypting encrypted content.

4. The method of any one of the preceding claims, comprising performing the cryptographic operation on the received key data using the key associated with the device to obtain the cryptographic key for use in the cryptographic process if the verification code matches the authentication code.

5. A method for providing a cryptographic key to a device for use in a cryptographic process, the method comprising:

obtaining a message; deriving an authentication code based on the message;

sending key data comprising the message and the authentication code to the device, to thereby enable the device to perform a cryptographic operation on the key data using a key associated with the device to obtain the cryptographic key.

6. The method of claim 5 wherein the message is obtained by generating the message using random or pseudo-random data.

7. The method of claim 5 or 6, further comprising: carrying out a

cryptographic operation on the key data using the key associated with the device, thereby generating the cryptographic key; and encrypting a control word using the cryptographic key, the control word for decrypting encrypted content.

8. The method of any one of the preceding claims wherein the width of the message is selected such that the number of possible values of the message is fewer than a number of performances of the cryptographic operation by the device which are required to successfully carry out a side-channel attack on the cryptographic operation at the device.

9. _t The method of any one of the preceding claims wherein the deriving an authentication code is performed using a predetermined function based on the message.

10. The method of claim 9 wherein the predetermined function comprises a cryptographic function operating on the message using the key associated with the device.

11. The method of claim 10 wherein the cryptographic function is a

cryptographic hash of the message using the key associated with the device.

12. The method of claim 9 wherein the predetermined function comprises cryptographically processing, using the key associated with the device, the message and a predetermined initialisation vector to generate a result; wherein the authentication code is the whole or a part of the result.

13. The method of claim 9 wherein the predetermined function comprises: extending the message with a predetermined initialisation vector to produce an extended message;

cryptographically processing the extended message using the key associated with the device to generate a result; and

selecting a portion of the result as the authentication code.

14. The method of any one of claims 9 to 13 wherein the width of the message is selected such that the number of possible values of the message is fewer than a number of performances of the predetermined function required to successfully carry out a side channel attack on the predetermined function.

15. A system arranged to carry out a method according to any one of claims 1 to 14.

16. A computer program which, when executed by a processor, causes the processor to carry out a method according to any one of claims 1 to 14.

17. A computer readable medium storing a computer program according to claim 16.