WO2007063491A2

WO2007063491A2 - Protection of digital content

Info

Publication number: WO2007063491A2
Application number: PCT/IB2006/054481
Authority: WO
Inventors: Boris Skoric; Johan C. Talstra
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-12-02
Filing date: 2006-11-28
Publication date: 2007-06-07
Also published as: WO2007063491A3

Abstract

A method of processing digital content on a content processing device includes receiving digital content that has been protected through encoding and/or scrambling using a predetermined algorithm. Additionally, an obfuscated computer program is received that is associated with the protected digital content for execution by the processing device. The program includes authentication instructions for performing authentication of the processing device and conversion instructions for performing at least a part of decoding and/or descrambling of the protected digital content in dependence on a response of the processing device to an authentication challenge. According to the method, a multi-round zero-knowledge algorithm is used for authenticating the processing device. Execution of respective rounds of the zero-knowledge algorithm is time-sequentially intermixed with content conversion of sequential parts of the digital content.

Description

Protection of digital content

FIELD OF THE INVENTION

The invention relates to a method of processing protected digital content and to a method of generating a computer program for processing protected digital content. The invention further relates to respective computer program products for causing a processor to perform the methods. The invention further relates to a processing device for processing protected digital content.

BACKGROUND OF THE INVENTION

Currently a large percentage of content, such as audio and/or video, is distributed electronically, for example on an optical storage, such as CD, DVD or in the future Blu-ray Disc or HD-DVD, via the Internet (e.g. downloaded or streamed), or through digital broadcasting (e.g. via satellite, terrestrial broadcasting or cable networks). Digital content can be easily copied and re-distributed. Content providers have thus long been interested in protecting their investment in creating and/or distributing the content. Many copy-protection or other conditional access systems have been designed that control copying and/or rendering of the content, for example no copy can be made, a single copy can be made, content may only be rendered once, content may be rendered several times within a predetermined time period, content may be copied but can only be rendered on an authorized rendering device, etc.. More in general, processing of the digital content is controlled. This is done by using cryptographic techniques. The encoded digital content itself or parameters required for decoding/descrambling of the protected content are encrypted. The decryption algorithms and/or decryption keys are managed by trusted, preferably tamper-resistant hardware and/or software modules that enforce the access control rules.

For content distributed on optical storage media several different content protection schemes (CPSs) are used or proposed. For DVD video the content scrambling system (CSS) has been designed, for DVD audio the CPPM scheme is proposed, for Blu-Ray Disc and HD-DVD the AACS system is proposed. A main purpose of many protection schemes is to ensure that ordinary users cannot make unauthorized copies of content and that sophisticated hackers cannot make life easy for 'casual' hackers by sharing their knowledge. In several CPSs, each playback device has a set of highly confidential Device Keys. These are needed for the processing of Key Blocks. A Key Block is a data structure that accompanies encrypted content. Roughly speaking, a Key Block contains the decryption key for the content, but in such a form that it can only be accessed by devices that contain non-revoked Device Keys. A sophisticated hacker can help "casual" hackers by prying the Device Keys out of a playback device and publishing these keys on the internet. Casual hackers can then make unauthorized copies of content using these Device Keys. However, the Licensing Authority (LA) sees which Device Keys have been compromised and will revoke them, i.e. the LA will issue Key Blocks in the future that cannot be processed by the published Device Keys. Most copy protection systems are vulnerable to a more problematic attack called the "key publishing hack". Here the sophisticated hacker does not publish the Device Keys that he has obtained. Instead he publishes content decryption keys for movies. The hacker can keep doing this indefinitely without fear, for the LA cannot see which Device Keys were used and hence cannot revoke anything.

US 2004/0133794 describes the concept of "Self-Protecting Digital Content" (SPDC). The record carrier does not only contain encrypted content and a Key Block, but also a piece of executable code (a program). Each playback device has a built-in "virtual machine" (VM) on which the executable code can be run. The VM is a miniature operating system offering a limited number of built-in functions that can be invoked by the SPDC executable. The executable plays an essential role in the decryption of the content, e.g. by performing a last descrambling step after the conventional CPS has done its work. The descrambling by the executable typically requires a number of secret algorithms contained in the executable. The executable has to be heavily obfuscated, for otherwise hackers will be able to read the employed algorithms simply by inspecting the executable. The VM has to be tamper-proofed. The advantage over the fixed CPS is the following. A hacker who has access to a set of Device Keys (and hence is able to obtain the content decryption key) still is not able to obtain the content descrambling algorithm. In addition the hacker has to understand what the SPDC executable is doing to the content. Hence a successful hack requires a hardware hack to obtain Device Keys and reverse- engineering of the executable to find the algorithm. It is possible to include a completely new executable with every movie, i.e. a new descrambling algorithm and obfuscation method. In this way hackers are forced to do a lot more work for each movie title than for a straightforward key publishing hack.

The SPDC system is vulnerable to an extended form of the key publishing hack. A sophisticated hacker performs a hardware hack to obtain Device Keys as before and additionally steals all the secrets present in the VM of a playback device. The hacker then writes a program that perfectly emulates the VM, e.g. on an ordinary PC. The hacker publishes the VM emulator. Ordinary users can now copy SPDC code to their PC and run it in their VM emulator. This exactly reproduces all the actions that would be performed by the executable in a real VM, i.e. content gets correctly descrambled. The known SPDC system has been designed to withstand such an attack as is shown in Fig.l. Block 100 illustrates the processing in the content processing device 100 that decodes and/or descrambles the protected content. The VM 110 as proposed by CRI contains a VM Private Key (VM Id) and a VM Public Key Certificate (signed by the LA) that authenticates the VM's corresponding Public Key. The SPDC executable 120 contains the LA's Public Key 122. The executable asks in step 121 the VM for the VM Public Key Certificate. The executable checks in step 123 the LA's signature under the Certificate using the LA Public Key 122. If the LA signature is invalid the procedure may be aborted in step 124. If the LA signature is valid, the SPDC executable then runs a protocol with the VM to check if the VM really possesses the Private Key corresponding to the VM Public Key in the Certificate. To this end the executable uses the system function that forces the VM to create a signature with the VM Private Key. It generates a challenge in step 125 and sends that to the VM. The VM signs it with its private key 114. In step 126 the signature is checked. If this check fails, the code refuses to do anything useful (abort in step 124). This scheme forces the hacker to include the hacked VM's Public Key Certificate and Private Key in the published VM emulator. This allows the LA to identify the hacked playback device based on a known association between the device and its VM, and to revoke the device using the ordinary fixed part of the CPS (i.e. future Key Blocks). If the check is valid, the protected content is processed in step 127 using the algorithm 128 embedded in the code.

SUMMARY OF THE INVENTION

It is an object of the invention to provide an improved content protection method and processing device.

To meet an object of the invention, the method of processing digital content on a content processing device includes receiving digital content that has been protected through encoding and/or scrambling using a predetermined algorithm, receiving an obfuscated computer program associated with the protected digital content for execution by a processing device; the program including authentication instructions for performing authentication of the processing device and conversion instructions for performing at least a part of decoding and/or descrambling of the protected digital content in dependence on a response of the processing device to an authentication challenge; wherein the method further includes using a multi-round zero -knowledge algorithm for authenticating the processing device and time- sequentially intermixing executing respective rounds of the zero -knowledge algorithm with content conversion of sequential parts of the digital content.

Like in the conventional SPDC scheme, the protected content is at least partially processed by an associated program that may, but need not, be specific for the content. The protected processing includes decoding and/or descrambling. The inventors have realized that the signature scheme used in SPDC requires a significant amount of processing. Since the authentication is performed before the content is processed, in practical applications a moderately-sized signature will be used in order not to delay the processing too much. This leaves SPDC open to a brute force attack for obtaining the secrets stored in the virtual machine. Moreover, a hacker knows that the program first performs the authentication and then the content processing. This information makes de-obfuscating of the program easier. According to the invention, a multi-round zero-knowledge scheme is used for authenticating the processing device. In a preferred embodiment of claim 9, the processing device includes a virtual machine and the program checks the authenticity of the virtual machine. However, the program may also be executed directly on the processing device, in which case it is the processing device itself that is directly authenticated. According to the invention the rounds of the authentication are spread over time as the content processing already takes place. A single round of a zero-knowledge algorithm is in general considerably less demanding in CPU cycles than a full signature scheme. Therefore, processing can start quickly. By doing additional rounds during the processing of the content, a high level of authentication can be achieved. In fact, in most practical applications it would be up to the content owner to determine the desired level of authentication simply by inserting more authentication rounds in the program. Brute force attacks can be eliminated by simply choosing a high enough number of rounds. Any suitable zero-knowledge algorithm may be used, such as the Feige-Fiat-Shamir or Schnorr scheme.

In a preferred embodiment, the intermixing is performed using a predetermined schedule for mixing authentication instructions with conversion instructions. The schedule could simply involve inserting an authentication round at regular predetermined time intervals (e.g. every second), or regular processing cycles (e.g. every 25 video frames, or every 44.000 audio samples). This is a simple way of obtaining the intermixing. Instead of a regular scheme, a random or pseudo-random scheme can be used, e.g. to vary the time interval or number of processing cycles within predetermined boundaries.

In a preferred embodiment, the load on a processor of the processing device during execution of the program is measured and execution of authentication instructions associated with a single round of the zero-knowledge algorithm is enabled if the measured load is below a predetermined threshold. In this way, the authentication is ongoing but unnoticed. If the load is below the threshold (e.g. less than 80% of a fully- loaded CPU), an authentication round could in principle take place. Additional criteria may be used for deciding whether or not to actually perform the authentication (e.g. if the previous round has recently completed, the authentication may be skipped or delayed).

In a preferred embodiment, authentication-triggering signals are associated with respective time-sequential parts of the digital content. The program contains instructions for identifying the authentication-triggering signals during processing of the content, and in response to identifying an authentication-triggering signal causing execution of authentication instructions of a respective round of the zero -knowledge algorithm. In this way, it is the content itself that triggers the authentication. This is particularly useful in situations where the program and content are supplied separately. For example, the program is supplied once and may be used repeatedly by the processing device, but the content can only be processed real-time (e.g. through streaming through the Internet) and can not be stored in plaintext format. In this way, the content supplier can in time increase the security by inserting more triggers in the content.

In a preferred embodiment, a commitment value u is retrieved from the processing device. Preferably, this commitment value is (pseudo-)random. An authentication round then includes calculating a challenge c in dependence on the received value u. Preferably, other data is also used for calculating the challenge (e.g. time, program counter). The calculation may be based on a (cryptographic) one-way function. The challenge c is provided to the processing device. The processing device calculates a response. The program receives the response value R from the processing device. The program verifies whether the response R satisfies a zero -knowledge consistency relation with the commitment u and the challenge c. Using this approach, the processing device does not know the program's challenge in advance, making it more difficult for an attacker to know in advance which challenges the code is going to send to the VM, and hence more difficult to successfully cheat (i.e. give the correct response without knowing the VM Private Key. This would make it possible to publish a non-traceable VM emulator or processing device). Moreover, the program does not need its own random number generator; its behavior can be completely deterministic, making it more suitable for execution by a VM emulator. The scheme forces an attacker to use the private value of the VM or processing device. In principle, each zero- knowledge round might use its own commitment value (giving maximum security), but this value may also be used for several or even all rounds (this speeds up the ZK rounds, especially if computation of a commitment requires exponentiation, such as in the Schnorr ZK scheme).

In a preferred embodiment, the decoding and/or descrambling depends algebraically on a parameter and execution of a single round of the zero -knowledge algorithm results in an algebraic updating of the parameter. With algebraic updating is meant that the value of the parameter is updated by performing an algebraic operation on at least the parameter itself and a value representing the output of the authentication round (e.g. the output of the function g). For example, the output of g may be XOR-ed together with the parameter to give the updated parameter. Any suitable decoding and/or descrambling parameter may be controlled in this way (e.g. a descrambling parameter that controls mixing of individual pixels or pixel segments, such as frame or field lines). Suitable parameters are: cryptographic keys (symmetric or asymmetric), seeds for random number generation, Initial Values for decryption, initial values for stream ciphers, pointers to memory addresses, bit masks, keys for a keyed hash function, shares for secret sharing schemes, etc. By algebraically updating the parameter, no conditional testing is required in the program that could enable a hacker to remove the test and only keep the actually executed statements. The updating of the parameter ensures that the processing remains correct as long as the authentication is correct.

In an embodiment, the processing device is associated with a cryptographic certificate identifying the processing device. The program retrieves the certificate, verifies the signature under the certificate, and algebraically updates the parameter in dependence on the verification. Preferably, the certificate includes a unique identifier of the processing device. Preferably the digital signature is created under control of a private key of the Licensing Authority (LA), enabling verification of the identifier by the program using the LA public key.

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

Fig. 1 shows a block diagram of the prior art SPDC system and method; Fig. 2 shows a block diagram of main components in the system; Figs. 3 and 4 are examples of the Schorr and Feige-Fiat-Shamir zero- knowledge schemes; and

Fig.5 shows a preferred embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Fig.2 shows a block diagram of main components in the system. Block 200 indicates a device that protects the digital content. It may use one or more conventional content protection functions for this. The received raw content, such as audio, video, images, electronic books, etc., may be scrambled in block Scr (e.g. by mixing part of the content), encoded in block Cod (e.g. using MPEG2 or MPEG4 encoding or other encoding schemes suitable for the specific type of content) and part of it or the entire content may then be encrypted in block Enc. Suitable encryption schemes are well-known for example from broadcasting (e.g. Cryptoworks, irdeto, Mediaguard), as well as optical storage (e.g. CPPM, AACS). Scrambling and coding in itself are optional. Also the sequence in which certain processing steps are performed may be chosen differently by the skilled person. In the example of Fig.2, a controller Cont controls the specific blocks, such as Scr, Cod and Encr, that are involved in protecting the digital content. The controller, for example, sets the parameters of the blocks Scr, Cod and/or Enc. Those parameters can be seen as keys that will be required for performing reverse operations in the processing device 100 that receives the protected content and at least partly converts it to a plain-text form (e.g. renderable by a suitable rendering device). The specific blocks that are involved in protecting the digital content may be implemented using dedicated hardware modules or ICs. If so desired, the functions of the blocks that may also be partly or entirely performed in software, e.g. by the controller/processor Contr. The protected content is output via block Outpl for supply to the processing device 100. It may be supplied in any form, e.g. on a storage medium or via a communication network, like Internet. The output Outpl is of a type suitable for such supply (e.g. a network card and software for accessing Internet or acting as a Web server). The protected content is received via a corresponding input Inpl (e.g. optical storage reader or Internet interface) of the processing device 100. Device 200 will be referred to as encoding device, device 100 will be referred to as processing device. The encoding device 200 may receive information from a Licensing Authority (LA), for example a public key of the LA. The encoding device 200 generates a program Prog with instructions/parameters to be executed by a processor Proc of the decryptor device 100. The program Prog may have all instructions required for decryption Deer the protected content, decoding Dec the content and descrambling Descr the content. However, for some or all of these blocks also optimized hardware may be used by the processing device 100, where the program Prog includes instructions and parameters/keys for controlling those hardware blocks. The program Prog is supplied via output Outp2 to the processing device 100 that receives it through the input Inp2. The program Prog is then loaded into the processor Proc of the processing device 100 for execution. The program may have been generated for a specific hardware and/or software platform. For example, the instructions are compiled to be executed on a specific type of CPU pre-loaded with a specific operation system or real-time kernel. Similarly, the instructions may have been designed to control specific hardware components (e.g. specific ICs, or dedicated pre-programmed DSPs) for performing the descrambling, decoding and/or decryption. Fig.2 shows three separate processing blocks Deer, Decod, Desc, which may also be separate hardware components/ICs. In the Figure, the Processor Proc slightly overlaps those blocks to illustrate that at least part of the processing is controlled or performed by the program Prog executed by the processor Proc.

Preferably, the program is written for execution on a virtual machine that shields the underlying hardware and software from the program. The processing device 100 then executes the virtual machine (or actually emulates the virtual machine). The remainder of the description focuses on the embodiment where the program is written for a virtual machine and the processing device includes the virtual machine. The invention can equally well work in a situation where no virtual machine is present. For 'virtual machine' then the 'actual machine', i.e. processing device 100 should be read.

The processing device 100 itself may be a rendering device, such as a television. It may also be a source device, such as a set-top box or optical storage player, or a storage device, such as a hard-disk storage device or rewriteable optical storage device. In particular, the processing device 100 may act as both a source device and a rendering device. In particular, the processing device 100 may be a multi-media PC. The processing device turns the protected content, which as such can not be rendered in a meaningful way (e.g. the user can not clearly identify the original audio/video) into a representation that can be rendered in a meaningful way. The processing device receives the protected digital content and the program Prog. It may receive both in any suitable form, e.g. on a storage medium, such as optical storage or solid state memory, via broadcasting (e.g. terrestrial, satellite, cable), via streaming or downloading through a network, such as the internet, via any suitable medium, such as broadband network (e.g. cable, ADSL) or 3G mobile networks. Both pieces may be provided in combination or separately, may be provided once or repeatedly, may be provided within a same time frame (e.g. within a week of each other) or at least one may be available over a prolonged period. For example, the program may be provided once, possibly against payment, giving the purchaser the right to render the content that is associated with the program. The content may be available for downloading from a web-site for a long period. It may also give the user the right to store the content in protected form (e.g. on a hard-disk storage device) and render the content, under control of the associated program, under rules built-in or associated with the program (e.g. the content may always be rendered, may be rendered during a certain period only, or may be rendered a predetermined limited number of times). One or both may be updated, e.g. through the internet. Preferably, the validity of the virtual machine is regularly checked through a network, such as the Internet, for example by contacting the Licensing Authority. If it is found that the virtual machine has been hacked, the LA may revoke the virtual machine using any suitable technique. Revocation as such is outside the scope of the invention. As a consequence of revocation of the processing device and/or its virtual machine, the authentication performed by the program Prog will fail and no correct processing will occur.

In itself the blocks shown in Fig.2 are known, for example from SPDC as described in US 2004/0133794, and are therefore not described in detail here. As with the conventional SPDC system, the program Prog must be well-obfuscated. Techniques for doing this are well-known and are not the subject of the invention. Suitable examples are given in C. Collberg, C. Thomborson, D. Low, "A Taxonomy of Obfuscating Transformations", Technical report #148, department of Computer Science, The University of Auckland, New Zealand, and WO 02/095546. As such, the method of generating the program also includes the step of obfuscating Obf the program. The method of processing the protected content under control of the program also includes the step of de-obfuscating De-obf the program. As such, device 200 includes means for obfuscating the program and device 100 includes means for de-obfuscating the program.

Also secret information (e.g. private keys, device keys, etc.) in the Virtual Machine (VM) must be highly hack-resistant, for instance by storing such information in a tamper-resistant device. Again such techniques are well-known, e.g. in the form of tamper- resistant smart-cards. As in the conventional SPDC system, the program may only be executed on a virtual machine that is assumed to be valid. To this end, as before the program must at least perform an initial check of the authenticity of the VM as soon as possible after starting the program, at least before a protected part of the content needs to be processed. As before, the program also contains instructions for performing part of that processing or controlling the processing. It will be appreciated that the program may include instructions for causing a processor to perform the actual authentication or processing (i.e. the actions are performed in software), but it may equally well include instructions that cause the processor to control dedicated hardware for performing the authentication and/or processing.

It will be appreciated that the program prog causes the processor to trigger issuing an authentication challenge. The processor may be loaded with a program so that it generates the challenge itself. Alternatively, the processing device 100 may include dedicated hardware for issuing the challenge in response to t a trigger form the processor Proc. The authentication is checked of the processing device 100 (or its Virtual Machine). So, the processing device (or the VM) includes means for responding to the challenge. Also here this may de done in software or using a hardware module operated under control of the software.

According to the invention, a multi-round zero -knowledge algorithm is used for the authentication. ZK algorithms are interactive protocols that allow a prover (in this case the VM) to prove to a verifier (in this case the program Prog executed on the virtual machine by processor Proc) knowledge of a secret, without revealing a single bit of information about the secret. Preferably, the well-known Schnorr, Fiat-Shamir, or Feige-Fiat- Shamir multi-round zero -knowledge algorithm is used. They involve multiple challenge- response rounds. Apart from the obvious advantage of zero leakage, these zero -knowledge protocols have the additional advantage that the prover does not have to perform heavy computations (large-number exponentiation).

Fig.3 illustrates the Schorr scheme. In this scheme, there is public knowledge of a modulus/?, which is a prime; a prime q, dividing p-\, a value g such that gq=\ mod/?, and a value V=g^~s mod p. The value s < q is private to the VM (or processing device). H is a one-way hash function. The virtual machine (VM) or the processing device 100 itself generates a random value w <q (or causes it to be generated). It calculates the commitment value u: u = gw mod p. Program Prog causes calculation of a challenge c: c = H(u, optional other data).

The virtual machine (VM) or the processing device 100 calculates a response (or causes it to be calculated):

R = w+sc mod q. A verification value is then calculated by or under control of program Prog:

A = g^RV° - u mod p.

Fig.4 illustrates the Feige-Fiat-Schamir scheme. In this scheme, there is public knowledge of modulus n, which is a product of two secret primes, and public values Vi... V^. Private values are: si...Sk such that V₁ ^'1 = sf mod n. His a one-way hash function. For the commitment u, a random value w<n is generated and the commitment is calculated as:

M = w² mod n. The challenge is calculated as: c = H(u, optional other data), c e {0,1}*. The response should be:

R = w ^• si^cl...Sk* mod n. The verification value is:

A = U - R² Vι^cl...V_k ^ck mod n.

If so desired also the Guillou-Quisquater algorithm may be used. Although this latter case is designed to perform the authentication in a single round, it can also be used in a multi-round version. By choosing the parameters suitably small, for certain applications adequate single- round performance (speed) can then be achieved. With each round, the probability that the prover is cheating decreases by a constant factor.

Analogously to Public Key Crypto, zero -knowledge is based on a "difficult problem" such as discrete logs / factoring, and involves Private Values and Public Values. A verifier can check that the prover knows the Private Value by checking if the received responses are consistent with the Public Value.

Using multi-round zero-knowledge authentication

In the original SPDC system the program verified the authenticity of the VM by issuing a random challenge, the VM signed it with its private key, the program verified the signature with the VM's public key. It had obtained the VM's public key as part of a certificate. The certificate was signed with a private key of the Licensing Authority. The certificate was then first checked with the LA private key. In the method and system according to the invention, the authentication is based on a multi-round zero-knowledge protocol. Preferably this replaces the authentication based on the VM's signature. However, if so desired it may also be in addition to this mechanism, for example, using the original mechanism for the initial authentication before starting the content processing and then additionally using the mechanism according to the invention during content processing as well. One round of the ZK protocol can be executed very fast. This means that the VM and the code are occupied for a far shorter time than in the case of ordinary signature creation and verification, respectively. Hence, according to the invention, ZK authentication rounds are activated during content processing (e.g. descrambling). This facilitates software obfuscation. In the original system where the signature was used, the de-obfuscator knows that all instructions for verifying the authenticity are executed by the program in time before the content processing begins. In the ZK case, the authentication instructions can in principle be executed at any moment and thus be located at any place in the program, increasing the obfuscation of the program. Moreover, the number of rounds need not to be known in advance. This has the advantage that in a situation where the verification is performed using conditional testing (e.g. IF statement) the program can be much better obfuscated.

The sophisticated hacker can avoid identification of the hacked playback device (by doing so, it becomes impossible to revoke the device). The hacker runs original SPDC code on an original or hacked VM step by step, investigating it, and finally creating a modified SPDC program from the original. The hacker keeps only those lines of SPDC code that actually get executed. These instructions get copied in unmodified form to the new program. 'IF' statements, conditional jumps and jumps to variable-dependent locations are not copied into the new program. In the end, any system call that reveals identifying information on the VM is replaced by an operation that writes some fake info to the proper location in working memory where the output of the function call would have arrived. The hacker publishes a VM emulator without any identifying information (VM certificates, Private Key, serial numbers etc.) and the modified SPDC code. Casual hackers can then run the modified SPDC code on the 'faceless' VM emulator. This hack works for the following reasons.

Somewhere in the original code, a function call is made to obtain a signature made by the VM Private Key. In some heavily obfuscated way, the signature is checked using the VM Public Key (obtained from the VM Certificate). This is a critical moment. An IF-statement decides whether or not to proceed with the rest of the useful part of the program. The hacker copies all the actions that occur after the "yes" decision. Hence, the modified program will correctly descramble the content. (Note that the hacker does not have to have the faintest clue about what the program is doing). The omission of IF-statements and jumps yields a program that does its job regardless of the certificate and signature that is fed into it. This allows the hacker to replace the real VM keys by fake keys. The LA cannot identify the hacked VM based on the published SPDC code and the published identity-less VM emulator. This hack can be automated. The creation of modified SPDC code is a relatively simple algorithm. Consequently, the sophisticated hacker does not have an additional workload per movie, which was the original goal of the SPDC system. Furthermore, the 'casual' hackers do not have to download large amounts of data, because the modified SPDC program is shorter than the original one.

The method and system according to the invention can even in a basic embodiment be considerably more resistant against such an attack. Whereas in the original system a heavy-weight authentication protocol was used and the decision tree thus had a very limited depth, it was in principle simple to obtain the entire decisions tree and select the instructions in the desired branch. As described above, the program was even shorter. Although the protocol is heavy-weight it needs to be executed fast (otherwise processing is delayed unacceptably) and as a consequence only limited length signatures are used, meaning it is indeed possible to hack the decision tree. The method and system according to the invention mix the authentication with the processing. As such, authentication is ongoing. In principle as many authentication rounds can be inserted as desired. This can give very deep decision trees. By inserting a loop in the program that executes at least one authentication round and some content processing, it becomes impossible to make a decision tree of limited depth. Any hacked program, if made at all, would also inevitably become long; it needs all authentication rounds and processing functions in the right sequence even if they originally were performed in a loop.

In an embodiment, the intermixing of authentication and conversion is performed using a predetermined schedule for mixing authentication instructions with conversion instructions. The schedule could simply involve inserting an authentication round at regular predetermined time intervals (e.g. every second), or regular processing cycles (e.g. every 25 video frames, or every 44.000 audio samples). This is a simple way of obtaining the intermixing. Instead of using a regular scheme, also a random or pseudo-random scheme may be used, e.g. to vary the number of processing cycles between each successive authentication round. The variation should preferably be within predetermined boundaries, for example between 10 frames and a 1000 frames.

In a preferred embodiment, the load on a processor of the processing device during execution of the program is measured and execution of authentication instructions associated with a single round of the zero-knowledge algorithm is enabled if the measured load is below a predetermined threshold. The encoding device 100 thus inserts such load measuring instructions into the program Prog. In this way, the authentication is ongoing but unnoticed. If the load is below the threshold (e.g. less than 80% of a fully- loaded CPU) in principle an authentication round could take place. Additional criteria may be used for deciding whether or not to actually perform the authentication (e.g. if the previous round has recently finished, the authentication may be skipped or delayed).

In a preferred embodiment, authentication-triggering signals are associated with respective time-sequential parts of the digital content. The encoding device 100 inserts into the program Prog instructions for identifying the authentication-triggering signals during processing of the content and instructions for, in response to identifying an authentication- triggering signal, causing execution of authentication instructions of a respective round of the zero -knowledge algorithm. In this way, it is the content itself that triggers the authentication. For example, the program may trigger an authentication round each time a predetermined number (e.g. 100) of frames, such as I-frames of an MPEG-2 stream, have been processed. In this way, the content itself is still unchanged. It is in general also known to include additional signals into a coded content stream (e.g. DVB supports such a signal already for changing decryption keys in a conditional access system). Such signals may be used or additional signals may be included in the stream. In such a way, the signals accompany the content stream and may be synchronized with it, but are in fact independent of the actual content.

In a preferred embodiment, a commitment value u is retrieved from the processing device. In the embodiment described here in detail, the value is obtained from the VM of the processing device 200. The encoding device 100 thus inserts an instruction into the program Prog for obtaining (e.g. reading) the commitment value. Preferably, this commitment value is (pseudo-)random. The VM thus calculates such commitment and each time issues a (usually) different one. Preferably, the program Prog checks if the commitments of the different rounds are indeed different.An authentication round then includes calculating a challenge c in dependence on the received value u. The encoding device 100 thus inserts instructions in the program Prog for calculating such a challenge. Preferably, other data is also used for calculating the challenge (e.g. time, program counter) enhancing the randomness. The calculation may be based on a one-way function, such as a hash. Preferably a cryptographic hash is used, having a chaotic output. Suitable examples include MD5, SHA- 1, SHA-256, SHA-384, SHA-512. The challenge c is provided to the VM of the processing device. The encoding device 100 thus inserts instructions in the program Prog for providing the VM with a challenge. The VM of the processing device calculates a response. The program receives the response value R from the processing device. The encoding device 100 thus inserts instructions in the program Prog for receiving a response from the processing device. The program verifies whether the response corresponds to the challenge c based on the embedded zero-knowledge algorithm and the commitment value u. The encoding device 100 thus inserts instructions in the program Prog for performing this verification. In principle, each zero-knowledge round might use its own commitment value (giving maximum security), but this value may also be used for several or even all rounds (increasing speed). The verification may simply be in the form of a well-known IF statement that compares the received response with an expected response. A more secure version is described in more detail below. Figs. 3 and 4 give detailed algorithms for the Schnorr and Feige-Fiat-Shamir algorithms. Persons skilled in the art can easily apply other ZK algorithms in a corresponding way.

As described above, the conventional SPDC system is open to an attack that is based on the fact that the certificate verifications hinge on IF-statements. The IF-statements are easily bypassed by the sophisticated hacker, who only has to select those parts of the code that get executed during a "good" run of the code. It is already known to counter this attack organizing the program Prog in such a way that the outcome of both the LA signature check and VM signature check is mathematically bound to algebraic operations later in the program, preferably in the part that does content processing. The lines of code that get executed must always be exactly the same, no matter what the outcome is of the signature verifications. Thus, there must be no conditional jumps, no decisions about which parts of the code to execute. Typically, a signature verification yields a numerical difference Δ between two huge integers, e.g. hundreds of bits long, one being a representation of the received response and the other being a representation of an expected response. Typically, the system can be designed such that Δ = 0 if the correct response R is received. Instead of using IF- statements, these numbers Δ (one obtained from the LA signature check, and one from the VM signature check) can be mixed into some of the parameters that control content processing. Simple examples are adding Δ to a parameter, multiplying the parameter by 1+Δ, or xor-ing the parameter with Δ. If the obfuscation of the SPDC code is good, then the sophisticated hacker cannot separate those parts of the code that are responsible for signature verification from those responsible for content processing. The only thing the hacker can see is the points where the VM Certificate and the VM's responses are received by the program. If the hacker inserts bogus data at these points, then his modified program will compute Δ≠O, leading to incorrect content processing. If he wants to get correct processing, he is forced to publish a program that contains a valid certificate and either a corresponding Private Key or correct responses to all challenges. The presence of the valid certificate (and possibly the private key as well) in the published modified program allows the LA to identify the hacked playback device and to revoke it through the revocation mechanism of the "fixed" copy protection system. The LA can in addition revoke the hacked VM by letting future SPDC code have a list of compromised VMs.

Compared to creating a signature, the multi-round ZK protocol used in the method and system according to the invention returns many more response values Δ [that preferably should be equal to zero as described above]. This allows for better software obfuscation, since an attacker now has to follow the whereabouts of an increased number of variables. Fig.5 shows a preferred block diagram and exchange of how to use the invention. Block 502 illustrates the private ZK value of the processing device 100 (or in this example of its VM). The verification of the LA signature in step 123 yields one Δ-value, in this case Δ_o. Then in step 503 an initial ZK round is triggered. This yields k Δ-values Δi to Δk, where k is preferably larger than 1. This may be done in one round (e.g. using Guillou-Quisquater) or by k short sub-rounds. Block 504 illustrates the ZK round in the processing device (or its VM). Block 505 shows the verification triggered by or executed by the program Prog. A second ZK round, executed during content processing and shown with blocks 506, 507 and 508, yields a further m Δ-values Δk₊i to Δk_+m. At each stage the content processing is preferably made to depend on all available Δ-values. In principle, it can be freely chosen which of the verification steps are algebraically bound to the content processing and which are verified using a conditional test. The binding is illustrated in blocks 509 and 510. Preferably, a ZK round is inserted as frequently as desired, intermixed with the content processing steps 127. It will also be appreciated that in some system it might not be required to use and/or verify the LA signature (thus use of Δo is optional). Preferably, this is used and checked. If so, the processing device (or in the described embodiment: its VM) is associated with a cryptographic certificate identifying the processing device. The encoding device 100 then inserts into the program Prog instructions for: retrieving the certificate; verifying the certificate; and algebraically updating the parameter (or multiple parameters in dependence on the verification. This is preferably done in the same way as done for the existing SPDC system.

Above a preferred embodiment has been described where each verification round gives a new value Δ that preferably is zero when the response is correct and is then algebraically bound to a content processing parameter. This can be generalized in the following way. The response value R that is calculated by an authentic processing device can be mathematically described as using a predetermined function f applied to at least u and c: R=f(u,c). The instructions in the program Prog for verifying the response cause then the processor to calculate a predetermined function g applied to at least R, u, and c, where the output of g is independent of u and c if the response value R is issued by an authentic processing device. So, it calculates g(R, u, c), which for an authentic processing device should correspond to g(f(u,c),u,c). This latter function can be designed such that based on the input values u and c the value f(u,c) can be compensated. As such, g may give any desired constant as output. In the case of Schnorr, the relationship is a bit more tricky. The parameter u is there based on the random value w. The response R is also based on this w and not on u. In this case thus R=f(w,c) and then g(R, u, c) = g(f(w,c), u, c)= g(f(w,c), u(w),c).

In an embodiment, the encoding device 100 inserts at least one bogus authentication round into the program Prog. This round is bogus in the sense that the content processing does not actually depend on the outcome of the verification. This is doable in the method and system according to the invention because the ZK rounds are fast.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A method of processing digital content on a content processing device; the method including receiving digital content that has been protected through encoding and/or scrambling using a predetermined algorithm, receiving an obfuscated computer program associated with the protected digital content for execution by the processing device; the program including authentication instructions for performing authentication of the processing device and conversion instructions for performing at least a part of decoding and/or descrambling of the protected digital content in dependence on a response of the processing device to an authentication challenge; wherein the method includes using a multi-round zero-knowledge algorithm for authenticating the processing device and time-sequentially intermixing executing respective rounds of the zero -knowledge algorithm with content conversion of sequential parts of the digital content.

2. A method of processing digital content as claimed in claim 1, wherein the intermixing is performed using a predetermined time-schedule for performing the authentication during the content conversion.

3. A method of processing digital content as claimed in claim 1, wherein the method includes measuring a load on a processor of the processing device during execution of the program and enabling execution of a single round of the zero -knowledge algorithm if the measured load is below a predetermined threshold.

4. A method of processing digital content as claimed in claim 1, including receiving authentication-triggering signals associated with respective time-sequential parts of the digital content; and identifying the authentication-triggering signals during processing of the content and in response to identifying an authentication-triggering signal executing a respective round of the zero -knowledge algorithm.

5. A method of processing digital content as claimed in claim 1, including receiving from the processing device a commitment value u, calculating a challenge c in dependence on the value u received from the processing device, providing the challenge c to the processing device, obtaining a response value R from the processing device, performing a verification whether the response R is consistent with the commitment u and the challenge c, said verification being based on the zero knowledge algorithm.

6. A method of processing digital content as claimed in claim 1, wherein the decoding and/or descrambling algebraically depends on a parameter and wherein execution of a single round of the zero-knowledge algorithm results in an algebraic updating of the parameter.

7. A method of processing digital content as claimed in claim 1, wherein the processing device is associated with a cryptographic certificate identifying the processing device; the method including retrieving the certificate; verifying the certificate; and algebraically updating the parameter in dependence on the verification.

8. A method of processing digital content as claimed in claim 7, wherein the processing device includes a virtual machine associated with the certificate and the method includes executing the program on the virtual machine.

9. A method of generating a computer program for processing protected digital content; the method including: generating an obfuscated computer program associated with the protected digital content for execution by a processing device; the program including authentication instructions for performing authentication of the processing device and conversion instructions for performing at least a part of decoding and/or descrambling of the protected digital content in dependence on a response of the processing device to an authentication challenge; wherein the method includes using a multi-round zero-knowledge algorithm for authenticating the processing device and generating the program such that during execution of the program authentication instructions of respective rounds of the zero- knowledge algorithm are time-sequentially intermixed with conversion instructions.

10. A method of generating a computer program as claimed in claim 9, wherein the intermixing is performed using a predetermined schedule for mixing authentication instructions with conversion instructions.

11. A method of generating a computer program as claimed in claim 9, wherein the method includes inserting in the program: instructions for measuring a load on a processor of the processing device during execution of the program and instructions for enabling execution of authentication instructions associated with a single round of the zero-knowledge algorithm if the measured load is below a predetermined threshold.

12. A method of generating a computer program as claimed in claim 9, wherein the method includes associating authentication-triggering signals with respective time- sequential parts of the digital content; and inserting in the program instructions for identifying the authentication-triggering signals during processing of the content and in response to identifying an authentication-triggering signal causing execution of authentication instructions of a respective round of the zero -knowledge algorithm.

13. A method of generating a computer program as claimed in claim 9, including inserting in the program instructions for retrieving a commitment value u from the processing device, and wherein the authentication instructions include instructions for calculating a challenge c in dependence on the received value u, for providing the challenge c to the processing device, for obtaining a response value R from the processing device, for performing a verification whether the response R is consistent with the commitment u and the challenge c, said verification being based on the zero knowledge algorithm.

14. A method of generating a computer program as claimed in claim 9, wherein the decoding and/or descrambling algebraically depends on a parameter and wherein execution of a single round of the zero-knowledge algorithm results in an algebraic updating of the parameter.

15. A method of generating a computer program as claimed in claim 14, wherein the processing device is associated with a cryptographic certificate identifying the processing device; the method including inserting in the program instructions for: retrieving the certificate; verifying the certificate; and algebraically updating the parameter in dependence on the verification.

16. A method of generating a computer program as claimed in claim 15, wherein the processing device includes a virtual machine associated with the certificate and wherein the instructions of the program are for execution by the virtual machine.

17. A computer program product including instructions for causing a processor to perform the method of claim 1.

18. A computer program product including instructions for causing a processor to perform the method of claim 9.

19. A processing device for processing protected digital content; the processing device including: means (Inpl) for receiving digital content that has been protected through encoding and/or scrambling using a predetermined algorithm; means (Inp2) for receiving an obfuscated computer program associated with the protected digital content; the program including authentication instructions for causing authentication of the processing device and conversion instructions for causing at least a part of decoding and/or descrambling of the protected digital content in dependence on a response of the processing device to an authentication challenge; processing means (Proc) for executing the obfuscated computer program; means for performing an authentication challenge under control of the program; means for responding to an authentication challenge; and means (Deer, Decod, Desc) for decoding and/or descrambling the protected digital content in dependence on a response of the processing device to an authentication challenge wherein the means for performing an authentication challenge and the means for responding to an authentication challenge are arranged to use a multi-round zero- knowledge algorithm for authenticating the processing device; and wherein the program is arranged to time-sequentially intermixed causing execution of respective rounds of the zero- knowledge algorithm with content conversion of sequential parts of the digital content.