WO2006031127A2

WO2006031127A2 - Methods and arrangements for distributing computer programs and user licenses in a secure manner

Info

Publication number: WO2006031127A2
Application number: PCT/NO2005/000338
Authority: WO
Inventors: Nicholas Wood; Markku Koskela; Attila Nagy; Akos Kiss
Original assignee: Safenet Norway As
Priority date: 2004-09-15
Filing date: 2005-09-14
Publication date: 2006-03-23
Also published as: WO2006031127A3; NO20043858L; NO20043858D0

Abstract

Methods and arrangements for distributing computer programs and user licenses in a secure manner are disclosed, wherein licences and computer programs are distributed independently, and wherein the a protected computer program never is changed into a registered version, but where a Digital Rights Management agent installed on the computer of a user includes a database over computer programs that may be executed legally on the computer, and the necessary keys for decryption and executing encrypted functions in the program. The program is protected by a combination of encryption, coding and self-destructive code. Further, it is disclosed how keys are developed, how local information is protected in the DRM agent, and how the DRM agent is validated from the protected program.

Description

METHODS AND ARRANGEMENTS FOR DISTRIBUTING COMPUTER PROGRAMS AND USER LICENSES IN A SECURE MANNER

FIELD OF THE INVENTION

The present invention relates to the field of digital rights management. More particularly, the invention relates to a system and an infrastructure for distributing interactive multimedia products, such as games in a manner wherein distribution and sale of licenses are separated from the distribution of the product itself. Furthermore, the invention relates to various aspects of the system.

BACKGROUND OF THE INVENTION

Over the last five to ten years the growing importance of the Internet and other digital distribution channels for distribution and sale of consumer products such as computer programs, music, movies, games and other multimedia content, has created a situation where efficient distribution and the struggle against unauthorized copying are conflicting issues. Technical measures intended to prevent piracy and secure copyright control often leads to inconvenience for the users and makes it difficult to exploit the potential of efficient distribution the digital communications infrastructure offers.

A number of copy protection schemes have been suggested. One method that has been in use for quite some time, in various forms, involves the association of the product with some kind of hardware distributed with the product, either the carrier upon which the product is stored - such as a CD ROM - or some electronic device often referred to as a dongle, where the product cannot be used or accessed without the simultaneous use of that specific hardware. Others rely on the distribution of products with unique serial numbers and that must be unlocked through a registration process in order to activate the product. Others again depend on a key that must be entered during installation of the product and that is either only distributed with a hardcopy of the product or separately over the Internet. Others again depend on dedicated viewer programs in order to access and interact with the content.

Most or all of these methods suffer from one or more limitations such as inconvenience for the user, inefficiencies in the distribution process, and weak security.

SUMMARY OF THE INVENTION

The present invention aims at providing a digital rights management infrastructure - or eco system - that is efficient and highly secure while at the same time separating the sale of licenses from the distribution of the product. The result is a distribution infrastructure, methods and systems capable of utilizing the efficient distribution of digital products offered by such distribution channels as the Internet, while offering highly secure rights management with no single point of attack for the would be cracker of the system.

The invention embodies a generic eco system allowing computer program products such as games to be distributed using any means, electronic or on physical media, with a clear separation of concerns. Furthermore, the invention provides various aspects of this eco system. It should be noted that while some of these aspects are only relevant in situations where the product is a computer product including executable code, i.e. a computer program of some sort, other aspects of the invention will have a more general application and can be used advantageously also when the product is pure content, such as music, video, text files and the like.

First of all, licenses are separated from computer program installation packages. Separation of licenses (the ability of consumers to play a game) from the game itself is an essential part of the architecture. In commercial terms it means that the billable asset changes from the physical media file to the rights to play the game (the license). This enables a number of new scenarios, such as free promotion CDs, superdistribution, electronic delivery of media, etc.

Secondly, license management is separated from billing models and payment systems. Retailers, online or high street, remain responsible for charging of consumers using whatever means they like to offer - cash, credit cards, phone subscription, and so on. The only change from a retailer perspective is that the billable asset changes from the physical game media to a license (the right to play a game).

This separation of concerns is an essential feature of the present invention as it removes any dependencies between license management and the way games are being promoted, sold or billed for. There are no technical restrictions on what business models that can be supported.

From a retailer and game distribution point of view, the following features of the infrastructure according to the invention should be noted:

A protected program in itself can be freely distributed using any means. The program can be put on any physical media, such as a CD or MM card, without any requirements for unique ID codes, copy protection or similar. Retailers will be responsible for billing and payment. The actual distribution does not involve pricing, billing or any other commercial transaction.

The game itself is "free" in the sense that it is no longer the billable item in the ecosystem. A consumer can install a game and automatically activate any trial mode. To activate a full version he or she will need a registration code, which can be purchased from a retailer (online or high street). This is the billable item in the system.

It should be noted that such a separation of distribution and licensing has been partly implemented in prior art solutions. However, in the prior art, even if the license has been sold separately from the distribution of the computer program, the program itself has included some kind of unlocking mechanism that will change the program from an unregistered to a registered version by entering a registration code. According to the present invention the computer program product never changes; instead a digital rights management agent installed on the users computer or device handles registration, and enables the execution of any licensed program. The features mentioned above are achieved through a first aspect of the invention, according to which a computer program product such as a computer game is produced in a manner that makes it impossible to execute. Preferably at least some parts of the game are encrypted, encoded or protected through other means. The program is then distributed in this form, and always remains in this form. It is never changed through any unlocking, registration or similar. According to a preferred embodiment of the invention, encryption keys are generated at a central web service and distributed to computer program producers to be used in order to encrypt games.

Instead, a digital rights management agent is produced, in the form of a separate program, a DLL-file or the like. The digital rights management agent is then distributed to all user computers, and it is this digital rights management agent that enables execution of the computer program product.

It should, however, be noted that there is no need for one digital rights management agent for each protected computer program. Rather, the digital rights management agent is able to handle licenses for any number of protected computer programs. This is done by way of license keys held by the digital rights management agent and used in order to decrypt and access the protected features of the computer program.

Whenever a user purchases a license to a game, he or she will receive a registration code. When the user enters the registration into her local computer, the registration code is sent to a central web service and exchanged for a license key. Thus, the digital rights management agent will be capable of enabling the execution of any computer program for which it has received a valid license key. Preferably, the web service distributing the keys to the digital rights management agents are the same, or at least operated in conjunction with, the web service distributing keys to program producers. According to the present invention, a registration code is unique to a sales transaction, and is only valid for a particular game and is normally only valid once.

The registration code can be distributed in a number of ways, including pre-generated and sold in a sealed envelope, on a scratch card or in some similar physical manner. Alternatively, the invention also supports direct online dynamic generation of codes. It is possible to use the system to remove dependency on pre-printed media altogether. This greatly reduces costs associated with printing, distributing and storing physical media. It also greatly reduces the time for a game to reach retail stores, as well as reduces the risk of not getting enough or getting too many physical copies out into stores.

Exactly how the digital rights management agent is able to enable execution of the computer program will depend on how the computer program product is protected.

According to a second aspect of the invention this is done through the use of one or more of the following three protection measures. In this specification the term obfuscation will be used for the sum total of measures used in order to protect the program, while the various individual measures will be referred to by more descriptive terms, such as encoding and encryption. During development of the computer program, the programmer identifies functions which it is desirable to protect. Each of these functions is subdivided into basic blocks, and into one or more such basic blocks self destruct code is inserted. This is code that when executed will destroy already executed code from the same basic block, making it impossible to copy this executed code from the working memory of a computer during execution of the program. Following this, each basic block containing self destruct code is encoded according to some algorithm. Finally the entire function part of the program is encrypted using an encryption key.

It will be understood that in order for the digital rights management agent to enable execution of a computer program protected according to this scheme, it must possess the encryption key used to encrypt the program (or the decryption key in case unsymmetrical encryption is used), and the encoding algorithm used to encode the individual basic blocks. The digital rights management agent does not have to possess any means in order to handle the self destruct code. The results of the self destruct code is that the deobfuscated code never remains intact in the computers memory, and that consequently the digital rights management agent must deobfuscate the various parts of the program repeatedly.

It will be understood that the protection of the computer program product depends on secure distribution and storage of the encryption keys and decoding algorithms. According to a preferred embodiment of the invention the encryption keys are unique to each computer program product (or content product), while the encoding algorithm is the same for all protected products and can be distributed as part of the digital rights management agent.

According to a third aspect of the invention, all data used locally by the digital rights management agent is protected locally through obfuscation. The digital rights management agent maintains a local database with one record for each licensed computer program product or content product. Each such record contains the license (license information) and the encryption key. The license information can relate to various license policies, such as a trial license valid for a specific period of time, a number of trials etc. The encryption key is the key used to decrypt the encrypted functions or parts of the protected product.

According to this aspect of the invention each record of the local database is encrypted using a unique encryption key. This unique encryption key is not stored, it is generated every time it is needed, and the algorithm used for this key generation is obfuscated. This means that if an attacker were to gain access to one data protection key, he would only have access to the content protection key stored in one data record. AU the other records are protected using different keys. In order to gain access to all records, an attacker would have to break through the obfuscation of the key generation algorithm and reproduce all keys individually. As mentioned above the keys used to encrypt the local data records are generated rather than stored. According to a fourth aspect of the invention, these keys, as well as the keys used to encrypt the program functions, are derived using particular hardware and/or software information and a randomization algorithm involving a random table. According to a preferred embodiment, keys used for encryption of data records (e.g. license information and key) are derived from a combination of a record ID, hardware ID and a random table. The record ID binds the key to the individual license stored in the particular data record in the local database. The hardware ID binds the key to the unique hardware upon which the digital rights management agent is installed. The record ID and the hardware ID is used to look up the contents of a randomized table, and the result provides the encryption key for the record.

According to a preferred embodiment of the invention the same method is used for generation of content encryption keys at the central web service. In this manner it is not necessary to store a large number of encryption keys at the web service. Instead the encryption keys are generated based on the computer program product ID and hardware ID unique to the web service.

According to a fifth aspect of the invention, validation is used in order for a protected program product to accept a digital rights management agent. The protected computer program calculates a hash of specific parts of the digital rights management agent. This hash is compared with a pre-calculated expected value. This pre calculated value is determined by the central web service from the digital rights management agent and encoded into the protected computer program together with the algorithm for calculating the hash, i.e. which specific parts of the digital rights management agent to validate and how to calculate the hash over those parts. These two parts, the expected hash and the algorithm, are preferably provided to the game producer as a macro that can be included anywhere in the game code. According to a preferred embodiment, the macro is distributed throughout the code of the protected computer program. This process of validation prevents the protected program from sending calls to a digital rights management agent that has been tampered with in order to extract information from the obfuscated parts of the computer program.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will be better understood by way of an example, illustrated in the enclosed drawings. It should be understood, however, that the invention is not limited to the details and arrangements shown in the example. In the drawings:

FIG. Ia and Ib show a general overview of the digital rights management system according to the invention; FIG. 2 illustrates an overview of the protection scheme provided by the present invention;

FIG. 3 illustrated an overview of computer program protection;

FIG. 4 shows the general steps of creating a protected computer program;

FIG. 5 illustrates the software development tool chain; FIG. 6a through 6d show the steps of decrypting a protected computer program at run time;

FIG. 7a through 7f show the steps of decoding at run time; FIG. 8 illustrates local data protection and validation. FIG. 9a to 9c illustrates update of the digital rights management agent;

FIG. 10 illustrates the web service components and portals that are part of a central web service;

FIG. 11 shows a network reference model;

FIG. 12 illustrates the distribution of a digital rights management agent; FIG. 13 is a flow chart for the development process;

FIG. 14 illustrates the process of producer registration;

FIG. 15 illustrates the process of key distribution;

FIG. 16 illustrates consumer registration and vault creation;

FIG. 17 illustrates retailer registration;

DETAILED DESCRIPTION

The present invention will now be described in greater detail with reference to the drawings.

The invention embodies a generic ecosystem allowing computer program products to be distributed using any means, electronic or on physical media, with a clear separation of concerns. It will be understood by the skilled person that some aspects of the invention demand that the computer program product includes executable code, while other aspects of the invention are applicable also to media content such as music files and the like.

First of all, licenses are separated from program installation packages. Separation of licenses (the ability of consumers to execute the program, e.g. play a computer game) from the program itself is an essential part of the architecture. In commercial terms it means that the billable asset changes from the physical media file to the rights to use the program (the license). This enables a number of new scenarios, such as free promotion CDs, superdistribution, electronic delivery of media, etc. Secondly, license management is separated from billing models and payment systems. Retailers, online or high street, remain responsible for charging of consumers using whatever means they like to offer — cash, credit cards, phone subscription, and so on. The only change from a retailer perspective is that the billable asset changes from the physical program media to a license (the right to play a game). This separation of concerns is an essential feature of the present invention as it removes any dependencies between license management and the way programs are being promoted, sold or billed for. There are no technical restrictions on what business models that can be supported. Some example business models are described below.

High street retailers or online retailers sell games on CD. When a consumer purchases a game, she will receive a CD with the game files. At the same time she will also receive a registration code that will allow her to activate the game (e.g. as a scratch card, or printed on the receipt, or similar).

A mobile phone operator provides free game CDs (or free online game downloads) to its subscribers. Consumers can install games and activate a free trial mode. If they like the game, they can purchase the right to activate the full game either online via the operator web site, or in an operator owned stored. The operator can charge its subscribers via the phone bill.

A consumer has a game and a CD. She likes the game, so she sends the CD (or a copy) to a friend to check it out. The friend installs the game, and automatically activates a free trial mode. If she likes it too, she buys the right to activate the full game either online or from a high street retailer (e.g. buys a scratch card, or receives a registration code electronically).

Free game CDs, or promotion CDs with several games, are provided for free through magazines or retailers. Consumers can install the game(s) and automatically activate a free trial mode. If they like a game, they can purchase the right to activate the full game either online or from a high street retailer (e.g. buy a scratch card, or receive a registration code electronically).

Online retailers provide games for download in electronic form. Users install games, automatically activate a free trial mode, and then purchase the right to activate the full game online. High street retailers download games in electronic form. Consumers can install the games in the store to activate a free trial mode, and then purchase the right to activate the dull game. The retailer burns games on CD locally in the store, as needed.

The above examples are merely intended to highlight the inherent flexibility of the architecture arising from the two simple steps of separating physical game delivery from license delivery, and of separating license management from payment models and payment systems.

Reference is now made to FIG. Ia, which shows the main eco-system according to the present invention; in this example the computer program product is a computer game.

The system includes a protection web service 101, which will be described in further detail below. A game producer 102 using a software development kit 103 in accordance with the invention accesses the web service in order to register a game and receive encryption keys. The game package 104 may be distributed in any manner, obfuscated in a manner that will be described in further detail below.

From a retailer 106 and game distribution point of view, the features of the infrastructure according to the invention can be described as follows: A protected game 104 in itself can be freely distributed using any means. If the game is put on physical media 105, such as a CD or MM card, there are no requirements for any unique CD ID codes, CD copy protection or similar. The game can simply be put on media 105 without any special actions, to be distributed electronically as it is. Retailers 106 (high street, online, or commercial web sites) are responsible for billing and payment. The web service 101 is not involved in pricing, billing or any other commercial transactions. This leaves retailers free to implement any business model or payment scheme. Or put the other way round, it leaves the retailers 106 free to continue to use whatever business model or payment scheme they already have in place. The game itself is "free" in the sense that it is no longer the billable item in the ecosystem. A game CD can be copied and passed around between consumers (super distribution), it can be given away for free (promotion CDs), a game can be freely downloaded electronically, and so on.

A consumer 109 can install a game and automatically activate a trial mode. To activate a full version she needs a registration code 108, which can be purchased from a retailer (online or high street). This is the billable item in the system.

The registration code 108 is unique to a sales transaction, and is only valid for a particular game and is normally only valid once.

The registration code 108 can be distributed in a number of ways, including pre- generated and sold in a sealed envelope, on a scratch card or in some similar physical manner. Alternatively, the invention also supports direct online dynamic generation of codes.

It is possible to use the system to remove dependency on pre-printed media all together. This greatly reduces costs associated with printing, distributing and storing physical media. It also greatly reduces the time for a game to reach retail stores, as well as reduces the risk of not getting enough or getting too many physical copies out into stores.

The easiest way to deploy registration codes is through pre-generated codes printed on scratch cards, sold in sealed envelopes etc. With minimal impact on retailers and the way they do business, it can be deployed in a very short time frame. Games are put on CDs that can be distributed through retailers, magazines, or directly between consumers (including copied by consumers). The game CD itself can be given away for free — in a store, in the box with the device, in a magazine. It can be freely copied — passed between friends, or downloaded from a web site. Consumers are always able to automatically activate a free trial mode of the game. Registration codes are pre-generated in batch by the web service and printed on scratch cards (by web site operator or a subcontractor).

Retailers (online or high street) sell scratch cards in the same way as they already sell other merchandise. There is no impact on retailer payment systems, commercial systems or business models. Consumers simply buy scratch cards to activate the full game, regardless of how they got the game itself (from a store, a friend, a magazine, a copy, an online download, etc.).

With this approach the impact on retailers is kept to an absolute minimum, while at the same time distribution is simple and straightforward (no CD copy protection or special CD IDs to manage, for instance). This together allows the solution to be rolled out in a very short time.

In addition to using pre-generated and printed registration codes, the system also supports direct online dynamic generation of codes.

For example, rather than shipping and managing printed cards, a retailer (online, high street, or a commercial web site) may interact with the web service through a retailer portal to register each sale and automatically receive a registration code for that transaction. The code can be printed in the store on the customer receipt, on a separate certificate, or sent to the consumer electronically.

Games can be made available in electronic form to retailers. Retailers can download games online to the store and make them available to consumers (PC disguised as a vending machine in the store). Consumers can install games in the store, or download them electronically from online retailers, and activate a free trial mode. Stores may print CDs on demand.

Turning now to FIG. Ib, the system will be described in further detail.

At the heart of the system is a web service 101 providing all core functions for license and key management, game protection, and so on. It provides a set of pure interfaces to drive all system tasks.

Human interaction with the system is through separate web portals, in turn interfacing with the web service.

There are four main actors in the system. The web service operator is responsible for administration and management of the system, interacts with the system to perform system management and operations tasks, and is able to control access, such as setting up producer and retailer accounts.

The web service operator provides portals for user interface interaction with producers, retailers and end users. In some cases this can be integrated with other services the web service operator provides.

Game producers interact with the service to protect games. This is done through a producer portal (game registration, key management, etc.). Producer accounts are in turn created, modified or deleted by interacting with the web service. Consumers interact indirectly with the web service during game activation (a license is requested automatically by the device).

Consumers interact directly with the service only if they wish to create a vault and register their device, something that will enable them to move their license to a different device. Consumer registration can be done either online (web or via MM application), or through the MM application on the device. (In this specification the MM application refers to a software program installed on the user's computer or console. It provides a user interface towards the digital rights management infrastructure, and can for instance be a web-browser like application, a user interface for installing programs on a device or something similar.)

Either way, it is preferred that a consumer portal handles consumer interaction. The portal interacts with the web service to create, modify or delete a consumer vault.

To activate a game, there has to be a valid sales transaction registered with the system.

Retailers interact with the system to get a unique registration code for a sales transaction. This can be done online through a retailer portal, or codes can be pre-generated and printed on scratch cards or similar. A game can only be activated if the consumer possesses a valid registration code.

The solution contains five main subsystems:

The first is the game producer software development kit 103, which is a collection of tools and software used during the game development process for game protection, packaging and registration. The SDK works in conjunction with the game producer web service.

The producer web service provides interfaces and services towards a producer portal, such as game registration, packaging and game protection, producer account management, and so on.

The licensing web service provides interfaces and services towards devices regarding license and key distribution. It is primarily responsible for secure management and distribution of encryption keys and licenses, and works in conjunction with the digital rights management agent (DRM agent) on the device. It also provides interfaces and services towards a consumer portal, such as vault account management for consumers.

The retailer web service provides interfaces and services for a retailer portal, such as retailer account management and management of registration codes.

Finally, the DRM Agent is a component on the user computer or device responsible for managing encryption keys and licenses on the device. It works in conjunction with games and with the licensing web service.

It should be noted that not only does the game package itself not contain mechanisms for unlocking the game, but the keys used for decrypting the game is never stored at the web service. Instead they are derived when needed using a method consisting of both an algorithm that can be kept secret, and secret data (e.g. a random number table) that only the web service knows. Furthermore, these secrets can be kept separately, meaning that an attack would have to access several sources, maybe even several organizations.

Finally, the protection itself has been designed so that breaking a single element of the protection is not sufficient. An attacker has to break multiple defenses. In fact, even knowing the encryption key is not enough on its own. An attacker still has to locate all protected functions, manually remove the protection (remove encryption from the function, and then remove encoding from each block), and piece it all together manually. Since there is no pattern to this (every game is protected differently) an attacker would not be able to device generic tools - it would all have to be done manually. The defence strategy used in the DRM infrastructure according to the invention, and the various components that implement this strategy, will now be described by way of an example involving the distribution of a computer game and sale of licenses.

The defense strategy is based on four main features. First of all security is increased by raising the bar for would be crackers compared to solutions known in the art. Simple memory dumps will no longer be sufficient. Neither will simple inspection of code or memory be sufficient. Rather, an attacker will be forced to use target debugging through obfuscated code and complex algorithms.

Furthermore, no class breaks will be possible. This means that even if an attacker is able to break the protection of one game, he or she will have to start all over again in order to attack another game. It will not be possible to design generic tools to remove or bypass protection.

Third, there is also no single point of entry in the sense that an attacker must break multiple defenses. Even access to a valid encryption key on its own will not be enough to remove protection. The fourth component of the defense strategy is upgradeability. Algorithms and code can be morphed/mutated/modified in order to throw off attackers. With the separation of the game itself from the entity that enforces security (DRM Agent), this means that the security of the solution can be upgraded by upgrading the DRM Agent. Any such upgrade will then automatically benefit both existing and new games. The main attack scenarios that can be brought to bear by an attacker include the following:

Manipulation of licensing code, including derealization attacks and local data attacks. Manipulation of game code, primarily removal of game protection. Private key attacks. The key defense tactics against these are, according to the invention, as follows:

Against fraud, service policies must be adequate. Examples include maximum one device per consumer for a vault, restriction of frequency of device changes, and restriction of frequency of unsuccessful activation attempts. Against manipulation of licensing code, several measures are implemented. The license code is protected by obfuscation of localized code and algorithms, and through game validation of localized code. In addition local data is encrypted using special data encryption keys. Each data element has its own unique data encryption key, and data encryption keys are never stored in memory or on file system, they are always derived.

Manipulation of game code is defended against through game code protection by multiple defenses, including encryption, encoding, self destruct code and validation code.

Finally, against private key attacks, private key is only used for license delivery, not for game protection. Private keys are stored like other sensitive local data, and private key provisioning is using derived "magic token".

Reference is now made to FIG. 2, which illustrates an overview of the protection scheme provided by the present invention.

The digital rights management web service 201 handles license keys and communicates with the digital rights management agent 202 installed on a users computer or device. The digital rights management agent 202 communicates with the computer program product, such as a game 203, and enables execution of a protected product 203. The digital rights management agent 202 preferably communicates with the web service 201 using PKI-based encryption and receives license information from the web service 201, using e.g. the Rights Object Acquisition Protocol (ROAP). The private key and the received information are protected locally in encrypted form.

The DRM agent 202 includes the following modules. First, a ROAP module 204, handling the communication with the web service 201. Then there is a decryption and decoding module 205, handling decryption and decoding of the protected computer program 203, as will be described in further detail below. A local data protection module 205 handles local data protection, and a localization module 206 handles the binding of the DRM agent 202 to local hardware.

A preferred way of handling localization is to build it into the local data protection, so that local data can only be accessed if the DRM agent 202 has not been moved, and the DRM agent 202 cannot work without access to local data. The protected computer program 203 includes the executable code for running the program. This code is at least partly encrypted 208 and encoded 209, and includes self destruct code 210 that will destroy executable code that has been decrypted and decoded by the DRM agent 202 after this code has been executed, as will be described in further detail below. The protected computer program 203 also includes an agent validation module 210 that validates the DRM agent 202 in order to prevent unauthorized agent code to receive calls from the program 203 and attempt to enable execution of protected code.

The local data protection 205 is based on the use of unique keys for each data element (e.g. data for each license), and these keys are always derived and never stored. Preferably, the keys are derived based on several input variables, making the local data protection localized to the user's hadware. Local data protection and key derivation will be described in further detail below.

Finally the protection itself must be protected. This is done through obfuscation of the key derivation algorithm and other parts of the code, and by validation of parts of the key derivation by the program 203. Together these measures prevent de-localization, i.e. dissolving the association of the license with the user's computer hardware.

Turning now to FIG. 3, which illustrates an overview of the game protection, it can be seen that using a software development kit in accordance with the invention will result in protection in the form of encryption scattered throughout the code. The developer will be in control, and able to include protection per function in the game. An unprotected program 301 is converted to a program 302 with protection scattered throughout the code on a function level.

FIG. 4 illustrates this in more detail. During production of the computer program, e.g. a computer game, a function to be protected 401 is identified and split into basic blocks 402. A simplified explanation of basic blocks would be that they are pieces of computer code with only one entry point and only one exit point. Self destruct code, or "bombs" are then inserted in one or more of these basic blocks, preferably in all 403. Following this step, one or more, but preferably all, basic blocks are encoded according to a predetermined coding scheme. Finally the entire function is encrypted. The reason for using both encoding and encryption is that encryption is a strong protection, but computation heavy, while encoding is weaker, but cheaper in terms of computation. Because of this, according to the invention, decryption is performed infrequently when a program is executed, while decoding is performed every time a function is executed, or preferably every time a basic block is executed. This means when a program is running, decrypted versions of functions may exist in the computers memory, but they will still be encoded. Only one decoded basic block ever exists at the same time.

The self destruct code 403 is code that when executed destroys code that is part of the same basic block and that has already been executed. This ensures that after the code has been decrypted, decoded and executed, it cannot be executed again. Consequently, if an attacker tries to copy decrypted and decoded code by stopping the execution of a protected program in order to copy code from memory, basic blocks that have already been executed will have been destroyed by the self destruct code. The self destruct code 403 preferably works by scrambling or overwriting code in the working memory of the device upon which it is executed. The encoding algorithm can be any well known algorithm that scrambles or "distorts" the code without the use of computation intensive encryption. A straightforward example is a simple XOR algorithm that adds various parts of the code with each other in a reversible manner, or that adds the code with a predetermined random bit string of a certain length.

The encryption scheme can involve any encryption algorithm known in the art, whether it is symmetric or asymmetric. According to a preferred embodiment symmetric encryption is used, using AES 128. As illustrated in FIG. 5, the tool chain in the software development kit focuses on the compiler and the linker. The developer decides which parts of the program require protection and marks the functions in the source code. The compiler must then be capable of identifying these markers and generate function headers for the marked functions. During execution of the program, these headers will be called instead of the functions themselves. The function headers call the DRM agent 202 and requests execution of the function by the DRM agent 202.

The actual insertion of self destruct code, encoding and encryption is preferably performed as part of the linking where functions to be protected are identified based on markers in the compiled code. Individual basic blocks of functions that are marked have self destruct code inserted, and the basic block is encoded. Block headers and block footers are generated and associated with each block. Finally the entire function is encrypted. Encoding and encryption are performed according to predefined encoding and encryption schemes. Many such schemes are well known in the art. Reference is now made to FIG. 6, where decryption at run time is illustrated. As shown in FIG. 6a, protected functions are in encrypted form when they are loaded. When such a function is called, FIG. 6b, the function header (stub) is executed. The function header (stub) then calls the DRM agent, as illustrated in FIG. 6c, and requests decryption. Following decryption, as shown in FIG. 6d, a decrypted but still encoded version of the function will now exist in the computers memory.

After the decrypted function is loaded in computer memory, the various basic blocks it consists of will still be encoded. As shown in FIG. 7, execution of the individual basic blocks again depend on the DRM agent. Turning first to FIG. 7a, when a block is due to be executed its block header is first executed. This block header calls the DRM agent. In FIG. 7b the DRM agent's response, which is to decode the block, is illustrated. The

DRM agent then returns control to the decoded block, as shown in FIG. 7c. Reference is then made to FIG. 7d, which illustrates that the decoded block is executed. As already described the block will include self destruct code which when executed deletes the parts of its own code that has already been executed, ensuring that decoded executable code does not remain in the computers memory. And even if an attacker were able to copy this code, it would delete itself after being run once.

When the block has executed, FIG. 7e, control is returned to the DRM agent. Control is only handed back to the DRM agent when the block footer is reached, i.e. after the self destruct code has been executed. This means that the DRM agent may ensure that a decrypted but encoded version of the block is all that remains in computer memory before it hands control back to the protected program, as shown in FIG. 7f. The computer program will therefore not reach another block header and request further decoding from the DRM agent until after the self destruct code has executed. Consequently, there will never be more than one decoded block in memory at the same time. It will also be understood that the decrypted but encoded block may still remain in memory, reducing the computation load on the computer or device in order to decrypt the function to only once for each time the program is running. It will also be noted that execution of the program will not be possible without the DRM agent.

Turning now to FIG. 8, the local protection will be described in further detail.

The obfuscated game function must be executed by the DRM agent using the encryption key associated with the game license and stored in a local database. Upon retrieving this encryption key, The DRM agent decrypts the function of the protected computer program, which is then available in encoded form, and containing self destruct code.

When the various basic blocks of the functions are executed, the DRM agent decodes the encoded basic block using an algorithm that is stored in the DRM agent. This algorithm is not unique to each game.

All this data used locally by the DRM agent is protected locally through obfuscation. The DRM agent maintains the local database with one record for each licensed computer program product or content product. Each such record contains the license (license information) and the encryption key. The license information can relate to various license policies, such as a trial license valid for a specific period of time, a number of trials etc. The encryption key is the key used to decrypt the encrypted functions or parts of the protected product.

Rather than just encrypting the entire local database, each database record is individually encrypted with a unique key. Furthermore, this unique data protection key is a derived key based on Randomize(DB-key, Hardware ID). This means that the unique data encryption key is not stored; it is generated every time it is needed, and the algorithm used for this key generation is obfuscated. This means that if an attacker were to gain access to one data protection key, he would only have access to the content protection key (license key) stored in one data record. AU the other records are protected using different keys. In order to gain access to all records, an attacker would have to break through the obfuscation of the key generation algorithm and reproduce all keys individually.

As mentioned above the keys used to encrypt the local data records are generated rather than stored. According to the invention, these keys, as well as the keys used to encrypt the program functions, are derived using particular hardware and/or software information and a randomization algorithm involving a random table. According to a preferred embodiment, keys used for encryption of data records (e.g. license information and key) are derived from a combination of a record ID, hardware ID and a random table. The record ID ensures that the key is unique for the particular license stored in the particular data record in the local database. The hardware ID binds the key to the unique hardware upon which the digital rights management agent is installed. Both of these input variables to the key derivation algorithm prevent attacks based on simple data copy from a different device. Finally, random data tables are used.

The record ID and the hardware ID are used to look up the contents of a randomized table, and the result provides the encryption key for the record. Seed=RandomTable(HardwareID|DB-Key) Kd=KDF(Seed)

In more detail, the method for deriving encryption keys can be described as taking one or more parameters (e.g. recordlD+hardwarelD for local data protection, or contentlD/gamelD for media objects/games) and concatenate them into a string. The string is then split up into parts according to some algorithm.

A table containing random numbers is used to randomize the string by taking one part of the string as an index to the table, which then yields a random number. Repeating this process for additional parts of the string produces a string of random numbers that replace the original string. The random number string has no deterministic relationship with the original string - i.e. it is not possible to construct a way to reverse the transformation from observing the output of the process.

An attacker would then need to know both the algorithm for concatenating and splitting the input parameters into parts, and also the exact values of the random number table. This information is normally not available at the same place and/or through the same means. For example, using this scheme to manage content encryption keys in the web service means an attacker has to figure out the algorithm, plus figure out the random number table. The algorithm need not be known by the operators of the central web service, while the random number table can be generated by the operator of the web service and stored on secure hardware accessible only to a trusted employee.

The DRM Agent obfuscation protecting e.g. the data encryption key derivation algorithm and the key derivation table is similar to that used for program code. The data in the DRM agent database may be morphed or mutated as part of an update of the DRM agent. Validation is used in order for a protected program product to accept a digital rights management agent. The protected computer program calculates a hash of specific parts of the digital rights management agent. This hash is compared with a pre-calculated expected value. This pre calculated value is determined by the central web service from the digital rights management agent and encoded into the protected computer program together with the algorithm for calculating the hash, i.e. which specific parts of the digital rights management agent to validate and how to calculate the hash over those parts. These two parts, the expected hash and the algorithm, are preferably provided to the game producer as a macro that can be included anywhere in the game code. According to a preferred embodiment, the macro is distributed throughout the code of the protected computer program. This process of validation prevents the protected program from sending calls to a digital rights management agent that has been tampered with in order to extract information from the obfuscated parts of the computer program.

To make it possible to upgrade the DRM agent without affecting older existing games, validation is done over API calls. DRM agent functions used by the API (e.g. algorithms) are then obfuscated. This means obfuscated algorithms can be upgraded without breaking backward compatibility with games. Validation ensures that algorithms are not removed or replaced. Obfuscation ensures that it is hard for an attacker to figure out how an algorithm works. FIG. 9 illustrates how the DRM agent may be updated without breaking validation. As illustrated in FIG. 9a, a game validates API function calls to the DRM agent. The API, which is protected in the DRM agent, is decrypted and decoded in a fashion similar to that for obfuscated functions in the game. The API functions then call obfuscated functions and performs decryption, key derivation etc., as already described. A change to e.g. the algorithm or key derivation will not affect validation. The same, updated functionality will benefit "new" as well as "old" games; the update is backward compatible. An example would be a morphed or mutated DRM agent. This is illustrated in FIG. 9b.

A change to the API, FIG. 9c, will affect validation. The "old" API is preserved for "old" games, while "new" games and updated "old" games use the new API. An example could be new features in the API.

Returning now to FIG. Ib, it will be seen that the web service preferably includes a number of different portals for the various users of the digital rights management system. These portals and the interaction with the web service through these portals will now be described in further detail.

FIG. 10 illustrates how, according to a preferred embodiment, the web service components are implemented as services on top of a database. These services expose service APIs to external applications.

The web service operator may then provide web portals for user interaction with game producers, consumers and retailers. These portals communicate with the database services using client APIs operating in accordance with the invention. Client APIs can be viewed as remote versions of the service APIs and hide internal protocols used to communicate with the database services.

Additional web service interfaces will provide a customer care and administration portal to perform tasks such as setting up producer or retailer accounts, tracing sales transactions and license deliveries, update or modify settings and data for consumer vaults, and so on.

Apart from serving portals, the database services also interface with other components of the digital rights management infrastructure, such as the license issuing service and key manager components. The DRM Agent installed on a customer's computer or device communicates directly with the licensing issuer service using OMA v2 DRM "ROAP" [OMADRM], and additional protocols based on HTTP/XML. Licenses delivered to the DRM Agent are encoded as OMA v2 DRM Rights Objects using an extended subset of the OMA v2 DRM rights expression language [OMAREL]. As such, the architecture is suitable for future extensions to include DRM protection of game resource files (treated as OMA DRM media objects), and including support for personal domains and device personalization.

A network reference model is illustrated in FIG. 11. The web services will preferably be deployed in standard server clusters. The web services and the database they use will preferably be located together in one physical site.

Portals may be located in different physical sites, possibly multiple sites (e.g. regional web portals). In this case it is preferred that they connect over Internet using VPN connections to communicate with the database services. It is further preferred that access control for the database services is implemented based on standard firewall and VPN rules.

DRM Agents connect to a public port of the license issuer service. Authorization and authentication for such connections are handled by the license issuer service as part of the license delivery protocols. The DRM Agent is a separate component (DLL) that can be preloaded on new devices or downloaded and installed separately on existing devices, as shown in FIG. 12. However, a DRM Agent is a fairly obscure and technical component, and not something consumers should be immediately aware of.

To make life as easy as possible for consumers, it is preferred that the DRM Agent is included in the installation package for the existing MM application. TMs means that whenever the MM application is installed, the DRM Agent is automatically installed at the same time.

If the DRM Agent is updated, a new version of the MM application can be made available for download. For new games that require the updated DRM Agent, it is straightforward to require a new version of the MM application for the games to run on existing devices. An updated DRM Agent can be made backward compatible, ensuring "old" games will still work with the "new" DRM Agent.

In this way, consumers only need to make sure that they have an updated version of the MM application on their device, an existing application they are already aware of. They need not worry about some obscure new component. Similarly, the operator of the web service can distribute the DRM Agent using the existing channels available for the MM application (preinstall, and downloaded updates).

Once a DRM Agent has been installed and first started, it will look for its certificate and private key. If there is none (new device, or the first time a DRM Agent is installed), the DRM Agent will contact the license issuer service to activate itself. It authenticates itself using a derived one time token based on random data, time, and device specific parameters (hardware ID).

The license issuer service will generate a private key and a certificate, and return them to the DRM Agent. Data about the DRM Agent, such as hardware ID, is stored by the license issuer service.

Updating a DRM Agent is a matter of installing a new DRM Agent DLL on the device. DRM Agent activation is not required after a DRM Agent update; a valid DRM Agent will in most cases be able to reuse existing licensing information already downloaded by the previous DRM Agent. In other words, in most cases users will not have to download new licenses following a DRM Agent update.

DRM Agent validation by games as provided by the SDK ensures that only authorized DRM Agents are accepted by protected games,

The SDK is designed as additional tools that can be included with an existing SDK provided by the web service operator. It consists of a modified target compiler and administrative tools (key management, etc.).

The development process has been described in detail above. Reference is made to FIG. 13 for a simplified description:

Code is developed and tested using the normal development tools. It can be tested on an emulator or built for target testing. For target builds the new modified target compiler can be used, but with protection features disabled. The game with its component game objects is registered with the web service, and encryption keys for each game object are generated and returned to the SDK. Game registration is only required once for a game. Once registered, the game can be rebuilt any number of times without requiring a new registration. Developers prepare the game code by selecting parts where protection should be applied. Protection is applied at a function level. A target build is produced using the new modified target compiler, this time with protection turned on. The result is a set of protected DLL files, which are then included into a normal installation package.

The DRM components can be supplied as part of an extended version of a standard SDK. Reference is now made to FIG. 14. Producer registration is the process of signing up game producers to the service, and issuing them with the necessary tools to participate.

Game producers go through a process defined by the web service operator for signing up to the service. This may be done online through the producer portal, or there may be steps in the process requiring signing a paper agreement or similar. Once the web service operator has approved the producer, the portal contacts the producer web service to create an account for the producer. When the account has been set up and is ready to use, the game producer is informed. The SDK is issued to the game producer from the portal (made available for download). Game registration is the process of defining a game package and its content with the web service.

A game package is a complete unit that can be sold, installed and played. It is made up of a number of objects (game DLLs, resource files, etc.). Some objects may be protected, some unprotected, depending on game producer requirements.

First, the game producer logs in at the producer portal. A game package and its content is then defined by the game producer. This includes creating the package, including defining name, version, etc. and input of general information about the game, as well as adding, modifying or removing such information. Further, the game producer defines all protected game objects contained in the package, and any policy issues, such as whether any trial is allowed or not. The latter specifies whether the game supports a trial mode or not. If it does, then the web service may automatically issue a free preview license to users who have not yet purchased a full license. The portal provides the user interface for guiding the producer through the process, and uses database services of the web service to execute and register the game.

The web service will generate globally unique IDs for the game and for all protected game objects. The package ID is used later to identify the game, and the object IDs are used to determine encryption/obfuscation keys for game objects. Game protection consists of encrypting and encoding selected functions of a game, as already described. Functions to be protected are selected at source code level by adding special attributes to the function declarations. These attributes are then picked up by a modified compiler and linker tool (part of the SDK), which will apply the protection. Protection is based on globally unique keys for each game object (DLL) which are generated by the web service.

As shown in FIG. 15, the game producer gets the keys by interacting with the producer portal. This is done once in the development process. After the keys have been established, they can be stored locally.

The game producer logs on to the producer portal and requests keys for the game. It is assumed that the game and its contents (protected game objects) have already been defined as described above.

The portal interacts with the producer web service. Each game object is assigned a unique key. All the keys are returned as a file, which is then used by the SDK to apply protection. Once the keys have been established, the game producer continues to use the SDK for protection of the different game objects. AU game protection is done locally with no further server interaction.

Finally, once game protection is complete there is a normal installation package with protected DLLs and resource files for the game. This installation package can be distributed in any way - electronically or on physical media. The game can only be played with a valid license and a valid DRM Agent on the device.

According to one embodiment of the invention, the web service solution is extended to allow game producers to upload game packages to the producer web service and publish them electronically. Retailers can then download them electronically for burning on demand in the store, or for selling them electronically to consumers, or consumers can by them directly over the web through an e-commerce solution.

Consumer registration and vault creation can be done by the consumer using web or the MM application. The latter case is outlined in FIG. 16. Consumer registration and vault creation is not a necessary part of the invention, but highly preferable since it enables important use cases such as game reactivation on a new device.

Vault creation is done through a consumer portal. It is preferred that this will be an extension of the existing web service portal and consumer account management system. First, the consumer starts the MM application on the device, and chooses to register and create a vault. The launcher application interacts with the consumer portal to allow the consumer to choose a username and password. An account is then created in the portal.

The portal interacts with the licensing web service to create a vault area associated with the username of the consumer. If supported by the portal, it is also possible for the consumer to use a web browser and go directly to the consumer portal.

When a consumer purchases a game she receives a registration code, as described above.

There are three main ways to activate games: using a registration code, using licenses registered in a consumer vault, or using a free trial license.

Using a registration code is an option consumers always have in the system. It does not require any registration by consumers - they simply enter the code, and if it is validated by the system a license is issued.

Registration codes are one-time by default (this is a matter of policy that can be changed subject to the requirements of the web service operator, but the basic assumption is that a registration code is only valid for one activation event). However, if a consumer purchases a new device, or replaces a device because it was faulty, then there is no way for the system to know that she had a license on her own device, so it will not be possible to reactivate games using a registration code.

To support reactivation, in a preferred version of a system according to the invention users may register with the system to create a personal license vault. No personally identifiable information is required to create a vault. Whenever a game is activated a license is automatically logged to the consumers vault. This enables later game reactivation. Finally, if a consumer does not have a license logged in her vault, and if the consumer does not have a valid registration code for the game, the system can automatically issue a free trial license for games that support a trial mode.

Using a Registration Code involves the following steps: A consumer installs a game and starts it. The game asks the DRM Agent if there is a valid license to play the game. If the DRM Agent does not already have a valid license, the consumer is queried for a registration code or a vault user ID. In this case, the consumer enters a registration code. The information is passed on to the license issuing web service, which validates the registration code against the retailer records for the sales transaction. The records are updated to indicate that the code has been used, so that if somebody tries to use it again it will not be accepted. A license is then downloaded to the DRM Agent. The DRM Agent responds to the game that a license is now present.

Using a License Pre-Registered in Vault is similar to the example with registration codes given above, except instead of responding with a registration code the consumer enters her user name to her vault. The license issuer service checks directly with the vault for a valid license, and if there is one it is returned to the device. Before a license is delivered from the vault, the identity of the requesting DRM Agent is checked. If it has changed, a device change is assumed.

A user with a vault may enter both a registration code and her vault user name when prompted by the DRM Agent. The license issuer service will then first check the vault. If there is no license, it will check the validity of the provided registration code. If the code is valid, the vault will be updated and a license returned.

If there is no valid license in the vault of the consumer, and the consumer did not provide a valid registration code, the license issuer service checks the trial policy for the game. If the game supports a trial mode, a free trial license is issued automatically.

The license status is indicated to the game, and if it is a trial license the game will proceed accordingly and only activate the trial mode.

Device Change and Game Reactivation will now be described, according to a preferred embodiment of the invention. The first time a game license is requested from the vault of a consumer, the identity of the requesting DRM Agent (DRM Agent certificate) is stored in the vault. On all subsequent requests, the identity is checked against the vault. If the identity of the DRM Agent is different from that stored in the vault, it is treated as a device change.

What happens when a device change is detected is a matter of service policy and can be configured according to the needs of the game producer and/or the web service operator. The following default options are examples only.

Number of devices in use by each individual consumer: Each consumer is allowed to activate content only on one device at a time.

Maximum allowed frequency of device changes: How often users are allowed to automatically change their device is configurable (e.g. at most once every six months) Retailer registration is the process of signing up affiliate retailers to the service, and issuing them with the necessary tools to participate.

Retailers go through a process defined by the web service operator for signing up to the service. This may be done online through the retailer portal, as shown in FIG. 17, or there may be steps in the process requiring signing a paper agreement or similar.

Once the web service operator approves the retailer, the portal contacts the retailer web service to create an account for the retailer. When the account has been set up and is ready to use, the portal informs the retailer.

For consumers to be able to activate a game, they need a registration code. A registration code is unique to a sales transaction and is used by the system to validate that a consumer has actually purchased the right to activate the game.

Registration codes can be generated online by interacting with the web service. This is useful to online retailers and others with an Internet connection. Alternatively, registration codes can be pre-generated and printed onto scratch cards or similar, which are then sold over the counter just like any other merchandise.

According to a preferred embodiment of the invention, online generation of registration codes is done when the retailer logs into the retailer portal and selects to register a transaction. She enters the package ID for the game.

The portal interacts with the retail web service to register the sale. A registration code is generated and logged to the retailer account together with the package ID.

The registration code is returned to the retailer, who prints it for the consumer. For example, it can be printed on the sales receipt, or on a separate document, or similar.

The various features of the invention will most efficiently be produced as computer program modules, or software modules, by means of which a general purpose central processing unit will be able to perform the steps of the invention. Taken together, the software modules and the hardware upon which they are installed and execute will provide the computer systems or devices according to the invention.

It will be understood that the various computers or devices operated by the web service operator, any games producer, retailer or end user or consumer, may vary according to the various needs and preferences that must be met in the individual case. As an example the web service provider may operate a server farm, the games producer uses work station computers suited for programming tasks, a retailer may use a general purpose computers such as a PC or a system integrated with his cashier register, e-commerce system etc., while the end user may have a game console, a portable device, a PC, or even a PDA or a cell phone.

At the very least these devices will have in common the fact that they include computer storage means for storing computer program code and any necessary data such as encryption keys, user data etc., one or more central processing units capable of performing the various steps of the invention under control of the computer program code, a working computer memory for storing data used during execution of the computer program code, one or more data buses, data interfaces and user interfaces for moving, sending, receiving and displaying information in the form of data, graphics or audio.

Finally it will be understood that while some of the aspects of the invention are only applicable to protection of computer program products such as computer games or other applications, in particular the features that demand executable code in the protected product such as self destruct code or hash algorithms, other aspects are applicable also to content protection, e.g. music files.

Claims

1. Method for distributing computer programs and user licenses in a secure manner, comprising the steps of producing a computer program product including a computer program product identity code and protecting the computer program product from being executed on a computer through encryption, coding or other means of data protection, producing a digital rights management agent to be installed on client computers, said agent being capable of receiving license keys identifying computer program products that have been licensed to a user, and said digital rights management agent being further capable of decrypting, decoding and/or opening other protection of any computer program product identified by any received license key during execution of said computer program, and distributing said computer program product, said digital rights management agent and said licensing keys independently of each other. 2. Method according to claim 1, further comprising the step of performing a business transaction wherein payment for a use of said computer program product is associated with the receipt at a digital rights management agent of a license key identifying said computer program product.

3. System for secure management of licensing keys for computer programs, comprising a computer program product registration database, a computer processing module for generating computer program product identity codes, a computer processing module for deriving encryption keys, a communications interface capable of sending a generated computer identity code and an encryption key as a response to a request for registration of a computer program product from a computer program producer system; a computer processing module for generating transaction identity codes, associating said transaction identity code with a registered computer program product code and storing said association, and a communications interface capable of sending a generated transaction identity code as a response to a request for such a code from a retailer system; and a computer processing module for deriving a licensing key, and a communications interface capable of sending a derived licensing key as a response the first time a generated transaction identity code and a properly associated computer program product code are received from a digital rights management agent installed on a customer computer system.

4. System according to claim 3, wherein said licensing key is derived partly from a hidden algorithm, partly from said computer program identity code received from the digital rights management agent, partly from a random data table, and partly from hardware identity information received from the digital rights management agent.

5. System according to claim 4, wherein said licensing key further includes a PKI type key pair counterpart to said encryption key. 6. System according to claim 4, wherein said derived licensing key is never stored in said system, but can be derived repeatedly if presented with the exact same input data.

7. System for developing a protected computer program product, comprising a communications interface for submitting a request for product registration and receiving as a response a generated computer program product identity code and a derived encryption key, a computer processing module capable of identifying properly marked functions in a computer software development code, dividing said functions into basic blocks and inserting self destruct code into said blocks, encoding said basic blocks, and using said received encryption keys to encrypt said functions of said computer software development code.

8. System for executing a protected computer program, comprising a digital rights management agent module capable of receiving a computer program product identity code from a protected program installed on said system, and a transaction identity code from a user input interface, a communications interface for submitting said computer program product identity code arfd said transaction identity code with a request for a licensing key to a system for managing licensing keys, and a local database module capable of receiving and storing said licensing key together with said computer program identity code, said licensing key enabling said digital rights management agent module to decrypt encrypted functions and decoding encoded basic blocks of said installed computer program.

9. Method for protecting computer program products from unauthorized copying and/or execution, comprising the steps of identifying parts of said program representing critical functions of said program, protecting said parts independently through obfuscation.

10. Method according to claim 9, wherein the step of obfuscating comprises the step of encrypting each part.

11. Method according to claim 9, wherein the step of obfuscating comprises the steps of dividing said parts into basic blocks and encoding each such block in accordance with some predetermined coding scheme.

12. Method according to claim 9, wherein the step of obfuscating comprises the step of dividing said parts into basic blocks, and including self destruct code in one or more of said basic blocks in each of said parts. 13. Method according to claim 9, wherein the step of protecting comprises the steps of dividing said parts into basic blocks, including self destruct code in one or more of said basic blocks in each of said parts, said self destruct code being capable of, upon execution, deleting from computer memory, code of that same basic block that has already been executed, encoding each block in accordance with a predetermined coding scheme, and encrypting each part.

14. Method according to one of the claims 9 to 13, further comprising the step of including, associated with each protected function, a program routine capable of making a call to a digital rights management agent requesting execution of the protected function.

15. Method according to claim 10 or 13, further comprising the step of including for each encrypted part, a program stub capable of calling a digital rights management agent and requesting decryption.

16. Method according to claim 11 or 13, further comprising the step of including for each encoded basic block, a block header capable of calling a digital rights management agent and requesting decoding.

17. Method for decryption at run time of a computer program product including a plurality of obfuscated parts, comprising the steps of before executing an obfuscated part of said computer program including a function, making a call to a digital rights management agent, by means of said digital rights management agent, deobfuscating said part, and executing said function.

18. Method according to claim 17, wherein the step of deobfuscating includes the step of decrypting said part. 19. Method according to claim 17, wherein the step of deobfuscating includes the step of decoding individual basic blocks of said part in accordance with a predetermined coding scheme just prior to execution of that block.

20. Method according to claim 17, wherein the step of executing, for one or more basic blocks of said part, includes the step of executing a self destruct code that is embedded in the basic block and that deletes, from computer memory, code that is part of that same basic block and that has already been executed.

21. Method according to claim 17, wherein the step of deobfuscating includes the steps of

- decrypting said obfuscated part, - decoding individual basic blocks of said decrypted part in accordance with a pre¬ determined coding scheme just prior to execution of said part, and the step of executing, for one or more of said basic blocks, includes the step of executing a self destruct code that is embedded in the basic block and that deletes, from computer memory, code that is part of that same basic block and that has already been executed. 22. Method according to claim 21 , further comprising the step of caching said decrypted part for repeated execution.

23. Method for protecting local data in a digital rights management system capable of handling license data associated with a plurality of content objects stored on a computer system, comprising the steps of for each content object, deriving a local encryption key based on local data unique to the computer system using an algorithm, encrypting said license data with said encryption key and storing the encrypted license data in a record in a local database.

24. Method according to claim 24, wherein said local data unique to the computer system includes hardware identification information extracted from the computer system hardware and additional information distinguishing said content object from other content objects stored on said computer system.

26. Method according to claim 24, further comprising the step of using the same algorithm to generate the same key in order to decrypt the contents of said record whenever said license data is required.

27. Method according to claim 24, wherein the content object is a computer program.

28. Method according to claim 24, wherein the content object is a media file

29. Method for, in a computer system, generating encryption keys for encrypting a digital object, comprising the steps of deriving a first string of digits unique to the object that is to be encrypted, repeatedly using a part of the string to look up an entry in a table of random numbers, and concatenating the numbers resulting from each look up into a second string with no deterministic relationship with said first string.

30. Method according to claim 29, wherein said first string is derived from identification data unique to the object that is to be encrypted.

31. Method according to claim 29, wherein the step of generating a first string further comprises deriving hardware information from a computer system upon which said digital object is to be stored, deriving additional information that, at least on said computer system, is unique to said digital object that is to be encrypted, and concatenating said local hardware identification information and said information unique to the digital object that is to be encrypted. 32. Method according to claim 31 , wherein said information unique to the digital object that is to be encrypted includes information identifying a record in a local database in which said digital object will be stored following encryption.

33. Method according to claim 29, wherein said digital object is a computer program or parts of a computer program.

34. Method according to claim 29, wherein said digital object is a media file.

35. Method according to claim 29, wherein said digital object is another encryption key.

36. Method for validating a digital rights management agent installed on a computer system from a protected computer program, comprising the steps of calculating a hash of specific, pre-defined parts of the digital rights management agent, comparing the result of said calculation with an expected result, and only upon confirmation that said calculated hash corresponds with said expected result, make any calls to said digital rights management agent from said computer program. 37. Method according to claim 36, wherein said expected hash and an algorithm for calculating said calculated hash are provided as a macro that is included in the computer program code.

38. Method according to claim 36, wherein said calculation is done over API calls. 39. Computer program product capable of, when installed on a computer system, performing one of the methods according to claims 1 or 2.

40. Computer program product which, when installed on a computer system, provides said system with the features of one of the claims 3 to 8.

41. Computer program product capable of, when installed on a computer system, performing one of the methods according to claims 9 to 16.

42. Computer program product capable of, when installed on a computer system, performing one of the methods according to claims 17 to 22.

43. Computer program product capable of, when installed on a computer system, performing one of the methods according to claims 23 to 28. 44. Computer program product capable of, when installed on a computer system, performing one of the methods according to claims 29 to 35.

45. Computer program product capable of, when installed on a computer system, performing one of the methods according to claims 36 to 38.

46. Computer program product according to one of the claims 23 to 45, carried on a computer readable medium. 47. Computer program product according to claim 46, wherein said computer readable medium is selected from the group of: a CD-ROM, a magnetic disk, and a flash memory.

48. Computer program product according to claim 39 to 45, carried on a propagated signal.

49. Computer comprising modules and programmed to make it capable of performing one of the methods of claims 9 to 38.