Method and apparatus for software licensing electronically distributed programs

[0002] 1. Field of the Invention

[0003] The present invention relates to the field of use of computer software registration. More particularly, the present invention relates to secure registration of computer software.

[0004] 2. Description of Related Art

[0005] The use of wide-area-networks such as the Internet to distribute software has become a very popular way to distribute software. The software can be programmed to be—until a license is purchased—either fully functional for a “trial period” of a certain duration, or partially functional. Providing potential customers the ability to download functional versions of a particular software allows access to an audience base that is limited only by the means of distribution (e.g., the size of the audience which has access to the Internet).

[0006] In addition, using networks to distribute demonstration or “demo” software is cost effective for the software company, as the company does not need to first place the demo software onto a distribution medium such as floppy disks or compact disk read-only-memory (CD-ROM) disks. Moreover, the company does not have to create or pay for packaging, nor maintain an inventory. The cost saving is especially beneficial in helping companies save marketing funds, which can be invested in other programs.

[0007] However, these cost savings disappear when the company has to ensure that customers who download the software pay for the software. Companies which put functionally limited versions of their software on the network requires a customer to send in payment for the software before the customer is sent a fully functional version. These companies must maintain a stock of packaged software, exactly the problem that a network-based distribution method attempts to solve.

[0008] Companies which put a time limit or other restrictions on their software require the customer to pay for a license before the customer is sent a “key code”. The key code is entered into the program, which then unlocks any restrictions. The problem associated with this scheme is that the same key code can be used for any copy of the software, so multiple individuals can unlock their respective copies of the software by simply purchasing one license and distributing the received key code amongst themselves.

[0009] Thus, it would be preferrable to have a software distribution scheme that overcomes the problems associated with these methods.

[0010] A method including the steps of receiving a registration identifier for a client; generating a registration key based on the registration identifier; and transmitting the registration key to the client.

[0011] FIG. 1 is a block diagram of a client system and a vendor system configured in accordance to a preferred embodiment of the present invention.

[0012] FIG. 2 is a flow diagram of the operation of the client system for initiating a request for registration of a software license.

[0013] FIG. 3 is a flow diagram of the operation of the server system in receiving the request of the client system and generating a registration key for the software on the client system.

[0014] FIG. 4 is a flow diagram of the operation of the client system after it has received the registration key for the software.

[0015] The present invention provides a method and apparatus for distributing software licenses. For purposes of explanation, specific embodiments are set forth to provide a thorough understanding of the present invention. However, it will be understood by one skilled in the art, from reading this disclosure, that the invention may be practiced without these details. Further, although the present invention is described through the use of software distribution over the Internet, most, if not all, aspects of the invention apply to software distribution in general. Moreover, well-known elements, devices, process steps and the like are not set forth in detail in order to avoid obscuring the present invention.

[0016] Through the use of public key cryptography, one-way hash functions and unique machine identification, software registration is provided which is individualized to a particular computer. Thus, software registration is “locked-in” to a particular computer and cannot be used on another computer—preventing the sharing of key codes.

[0017] In order to describe this system of software distribution, explanation is first provided below for public key cryptography, one-way hash functions and unique machine identification.

[0018] Public Key Cryptography

[0019] Public key cryptography provides the ability for two parties to send information securely between themselves. Unlike symmetrical cryptography, which requires a shared secret key, public key cryptography uses one key, a “public” key, to encode information and another complementary key, a “private key” to decode encrypted information. The security of the system lies in the method used to create the key pair and the belief that it is very difficult to determine the private key from the public key.

[0020] In use, a user publishes the public key and keeps the private key secret. Parties wishing to send a message to the user encrypt the message with the user's published public key and send it to the user. Upon receiving the encrypted message, the user decrypts the message with the user's private key, thereby recovering the original message.

[0021] The user can also “sign” a document by using the user's private key. The user would encrypt the message with the private key, and other parties would decrypt the message with the user's public key. Only documents encrypted with the user's private key will be intelligible when decrypted with the user's public key.

[0022] Mathematically, encryption is represented by:

[0023] C=E_k1(M)

[0024] and decryption is:

[0025] M=D_k2(C),

[0026] where M is the original message, C is the encrypted message, k1 is the public key, k2 is the private key, E() is the encryption function and D() is the decryption function. For signing of documents, the keys used would be reversed.

[0027] One-Way Hash Functions

[0028] A one-way hash function is a function which cannot be easily reversed. Specifically, given an input, an output is easy to generate, but given the output, the input is practically impossible to reconstruct. Also, given an output, it would be very difficult to generate input data which hashes to the output value. One-way hash functions can output more, less, or the same amount of information (e.g., number of bits) from a given input. To be useful, the hash function should return practically unique values for a given input. Usually, the hash values have less information than the input data.

[0029] One-way hash functions are useful in constructing “signatures” of documents. For example, if user A has a document, and user B wants to prove to user A that he has the same document, user B can run an agreed upon one-way hash function and send the result to user A, who can run the same one-way hash function and compare hash values. If they match, user A has strong evidence that user B has a copy of the same document.

[0030] Mathematically, the hash function is represented by:

[0031] S=H(M)

[0032] where M is the original message, H() is the one-way hash function, and S is the signature of the message.

[0033] Unique Machine Identification

[0034] Modern operating systems support remote procedure calls (RPC), which requires a unique method of identifying each machine on a network. Thus, most operating systems include a way of generating universal unique identifiers (UUID), which are unique in time and space. These UUID's have a well defined layout and have preallocated portions for location information, time information, and user defined information. Every UUID created on a particular machine will have the same values for the location bits. Therefore, these bits can be used to uniquely identify a particular machine.

[0035] Software Registration

[0036] FIG. 1 is a block diagram of a client system 50 and a vendor system 80 configured in accordance with one embodiment of the present invention.

[0037] Client 50 contains a CPU 52, which is a general purpose processor, coupled to a network adapter 54. Also coupled to network adapter 54 and CPU 52 is a memory 56, which stores the data and procedures which CPU 52 uses to operate.

[0038] Memory 56 of client system 50 contains a machine unique identifier U 58; a hash function H(U) 60; a public key Kp 62; an encryption procedure E_k() 64; a decryption procedure D_k() 66; a registration storage unit 68; an equality test procedure 70 and software 72.

[0039] As discussed above, machine unique identifier U 58 is a number that is unique to client system 50, and the size of machine unique identifier U 58 can be of any length, as generated by client system 50.

[0040] Also, as discussed above, encryption procedure E_k() 64 decryption procedure D_k() 66 are used to encrypt and decrypt, respectively, messages which are received from vendor system 80.

[0041] Public key K_pis used with encryption procedure E_k() 64 to create an encrypted version of a one-way hashed machine unique identifier U 58, as described below. Public Key K_p62 is also used with decryption procedure D_k() 66 to authenticate any registration keys received from vendor system 80.

[0042] Registration storage unit 68 is used to store the registration key received from vendor system 80 for enabling features of software 72.

[0043] Equality test procedure 70 is used to verify that the decrypted version of the registration key stored in registration storage unit 68 is equivalent to the one-way hashed value of machine unique identifier (U) 58, as generated by hash function H(U) 60. Equality test procedure 70 is interfaced with software 72 to enable/disable functionality of software 72 based on the output of equality test procedure 70, as discussed below.

[0044] Continuing to refer to FIG. 1, vendor system 80 contains a network adapter 82 which is used to communicate with network adapter 54 of client system 50 through a network 96. Network 96 can be a general purpose network such as the Internet or a local-area-network containing two or more systems.

[0045] Vendor system 80 also contains a CPU 84, which can be a general purpose processor, coupled to network adapter 82. It is to be noted that CPU 84 and CPU 52 of client system 50 can also be custom integrated circuits.

[0046] Also coupled to network adapter 82 and CPU 84 is a memory 86. Memory 86 of vendor system and memory 56 of client system 50 can also be general purpose data storage devices or custom data storage devices such as integrated circuits and can be built into CPU 84 of vendor system 80 and CPU 52 of client system 50, respectively.

[0047] Memory 86 of vendor system 80 contains a decryption procedure D_k() 88; a registration number generator 90; and encryption procedure E_k() 92, and secret key K_s94.

[0048] Decryption procedure D_k() 88 is functionally equivalent to decryption procedure D_k() 66 of client system 50. Similarly, encryption procedure E_k() 92 is functionally similar to encryption procedure E_k() 64 of client system 50. However, vendor system 80 will use secret key K_s94 and decryption procedure D_k() 88 to decrypt the messages generated by encryption procedure E_k() 64 of client system 50 (client system 50 using public key K_p). Also, vendor system 80 will use secret key K_s94 in encryption procedure E_k() 92 to authenticate messages which are sent to decryption procedure D_k() 66 of client system 50.

[0049] Registration number generator 90 is used to verify user payment information CC which is received from client system 50. After payment is made, registration number generator will allow vendor system 80 to generate a registration key.

[0050] A first dotted line 97 is used to logically represent the sending of data from encryption procedure E_k() 64 of client system 50 to decryption procedure D_k() 88 of vendor system 80, while a second dotted line 98 is used to logically represent the sending of encryption procedure E_k() 92 of vendor system 80 to registration storage unit 68 of client system 50. The actual data is sent over network 96 through the use of network adapter 54 and network adapter 82.

[0051] It is to be noted that although software 70 is shown to be a separate functional block in FIG. 1, in alternate embodiments, software 70 contains any combination of the functional and storage elements contained in memory 56 of client system 50.

[0052] FIG. 2 is a flow diagram of the operation of the software registration system, as shown in FIG. 1, where the user decides to register the product.

[0053] In block 100, client system 50 first determines machine unique identifier U 58. As noted above, machine unique identifier U 58 is used to uniquely identify client system 50 and is generated by using a built-in function of the operating system. After machine unique identifier U 58 is determined, client system 50 creates a one-way hashed version of machine unique identifier U using hash function H(U) 60. The generation of the one-way hashed version of the machine unique identifier in block 100 provides a practically unique registration code which does not allow the vendor access to any sensitive machine information, such as the network card ID number. The use of one-way hash function H(U) allows the registration identifier to be a fixed size, independent of how many bits of information are available in machine unique identifier U 58. A fixed size registration identified is useful for multi-platform products as each type of platform may have a different number of location specific bits in the UUID.

[0054] In block 102, client system 50 receives user payment and other transaction specific information (CC). This is information appended to the one-way hashed version of the machine unique identifier and is whatever transaction specific information the vendor requires, such as the user's name and credit card number.

[0055] In block 104, client system 50 generates a registration identifier R by using this formula:

[0056] M=H(U)+CC

[0057] R=E_kp(M)

[0058] where H( ) is hash function 60; U is machine unique identifier 58; CC is private, transaction specific information, such as the user's name and credit card number; M is the one-way hashed machine unique identifier with private user data appended (i.e., the “message”); E_k( ) is encryption procedure 64; k_pis the published, public key; 62 and R is the generated registration identifier. As this information is encrypted using the published public key (Kp), it can only be decrypted and read by vendor system 80 with the private key (K_s).

[0059] In block 106, the registration identifier (R) is transmitted to vendor system 80. This can be done automatically by software 72, which is contained on client system 50 over the Internet, or a text representation of the registration identifier (R) can be generated and sent to the vendor to be processed on vendor system 80.

[0060] As described, the information contained in registration identifier (R) is encrypted before it is transmitted, so it can be transmitted using any method, either securely or non-securely.

[0061] FIG. 3 illustrates the operation of vendor system 80 where the client system 50 has transmitted registration identifier (R).

[0062] In block 110, vendor system 80, upon receiving the registration identifier (R), computes:

[0063] M=D_ks(R)

[0064] H(U)+CC=M

[0065] where R is the registration code; M is the one-way hashed machine identifier with private user data appended, recovered by decrypting R (this is split into two parts to recover H(U) and CC); D_k( ) is decryption procedure 88; and k_sis the secret, private key 94.

[0066] In block 112, the private user information (CC), is used to verify payment for the software. This verification can be as simple as processing a credit card transaction or verifying that the user has sent in payment.

[0067] In block 114, after payment is received, vendor system 80 will generate:

[0068] T=E_ks(H(U))

[0069] where E_k( ) is encryption procedure 92 and T is the generated registration key.

[0070] It is to be noted that as registration key (T) is based on a machine identifier which is unique for client system 50, even if registration key (T) is compromised, it could not be used for another machine.

[0071] In block 116, vendor system 80 will transmit registration key (T) to client system 50. As stated above, as registration key (T) is an encrypted value of the one-way hashed value of machine unique identifier U 58, registration key (T) can be transmitted using any means, whether it is secure or unsecure.

[0072] Further, as registration key (T) is specific for client system 50 and cannot be used by another system, the security of the key system can be compromised and the protection provided by the system would still remain.

[0073] FIG. 4 illustrates the operation of client system 50 after client system 50 has received registration key (T).

[0074] In block 120, client system 50 will store registration key (T) in registration storage unit 68 so that it can be accessed when needed. When software 72 needs to expose or hide functionality based on the registration status, the current key is loaded from this location, decrypted, and checked for correctness as discussed in block 122. Also, the next time software 72 runs or needs to decide if software 72 is a registered copy, client system 50 will go to block 122.

[0075] In block 122, equality test procedure 70 of client system 50 will determine if registration key (T) comes from vendor system 80 by checking to see if the following holds true:

[0076] D_kp(T)=H(U)

[0077] where: D_k( ) is decryption procedure 88; k_pis the published, public key 62; H( ) is the one-way hash function 60; U is machine unique identifier 58; and T is the registration key.

[0078] If the equality holds true, then operation will continue with block 124. Otherwise, operation will continue with block 126.

[0079] In block 124, client system 50 will allow any functionality in software 72 that was previously disabled.

[0080] In block 126, as client system 50 has detected that registration key (T) is not received from vendor system 80 or is not valid, any functionality of software 72 that is not accessible to non-paid users remain locked or hidden.

[0081] It is to be noted that any public key cryptography algorithm that can transmit arbitrary messages will work in the system. However, the security of the system is only as secure as the cryptography algorithm. For public key cryptography systems, security increases as more bits are added to the key (i.e., the key length is increased). In a preferred embodiment, the key length is at least 512 bits.

[0082] In order to prevent an attacker from trying to break the licensing scheme by modifying the executable code containing the check which disables functionality, several alternate embodiments are proposed.

[0083] First, all debug information should be removed from any executable before distribution. This makes it harder for the attacker to follow the flow of control which checks the registration code.

[0084] Second, multiple places in the code can check for the existence of a correct registration key (T). This makes it harder to bypass all of the registration checks.

[0085] Third, the registration checking code can be obfuscated, making it hard to follow and change. This can be made complicated enough that it would be more cost effective to just license the software legally.

[0086] Fourth, for even more security, the software itself could be encrypted with the private key and loaded, decrypted and run using a second loader program. This method would be secure against all but the dumping of the binary image of the running executable out to a disk file and reconstructing a executable program file from a binary image.

[0087] For maximum security, the operating system (OS) itself could be enhanced to only execute encrypted executable files. The OS would be shipped with the decryption key, but the encryption key would remain secret. To execute a program, it would have to be decrypted by the internal OS key. Since only the OS manufacturer would have the encryption key, only programs encrypted by the OS manufacturer could be run. Obviously, this level of security would affect the way that software could be written and used. However some usage models, such as game machines where most software comes from one manufacturer and no software is written on the executing machine itself, could use this security method.

[0088] In one alternate embodiment, time-limited licenses can be granted. Instead of simply decrypting and re-encrypting the unique machine identifier, an expiration date is added to the message. When client system 50 checks registration key (T), client system 50 also decrypts the expiration date and checks if the license has expired.

[0089] In the alternate embodiment, the following functions would be used on vendor system 80:

[0090] M=Dk_s(R)

[0091] H(U)+CC=M

[0092] T=Ek_s(H(U)+V)

[0093] Where: R is the registration code; M is the one-way hashed machine identifier with private user data appended, recovered by decrypting R (this is split into two parts to recover H(U) and CC); V is the expiration date; E_k( ) is the encryption procedure; D_k( ) is the decryption procedure; k_sis the secret, private key; and, T is the generated registration key.

[0094] In addition, on client system 50, the following function would be used:

[0095] Dk_p(T)=K, V

[0096] and a check performed to determine if the two following conditions hold true:

[0097] K=H(U)

[0098] and,

[0099] V has not expired. where: D_k( ) is the decryption procedure; k_pis the published, public key; H( ) is the one-way hash function; U is the machine unique identifier; T is the registration key; K is the machine identifier portion of the decrypted registration key; and V is the expiration date portion of the decrypted registration key.

[0100] It is to be noted that the unique identifier does not have to be hashed before being transmitted. In addition, no private information has to be appended for payment purposes. In another alternate embodiment, only the unique identifier is transmitted.

[0101] In yet another alternate embodiment, the unique identifier, U, is not machine specific but specific in another way, such as user or binary specific. A software distribution site could be set up to download executables that are identical except for an internal identifier.

[0102] Alternatively, the software could be distributed with an installation program that set the executable's internal unique ID to some time or location specific value. Each user would get an equivalent binary file that required a different registration key, but the registration process and key verification would be exactly as in the basic system. This would allow a user to install the software on multiple machines but not share the registration key with other users. If the unique identifier could be something person specific, such as a fingerprint, a voice print, or a handwriting signature, this alternate embodiment could be very attractive.

[0103] Using electronic “money”, the entire process could be automated. A Web server could process the payment with the registration identified and send the registration key back to the user (all over a secure channel such as Secure Socket Layer) within a single transaction.

[0104] While the present invention has been particularly described with reference to the various figures, it should be understood that the figures are for illustration only and should not be taken as limiting the scope of the invention. Many changes and modifications may be made to the invention, by one having ordinary skill in the art, without departing from the spirit and scope of the invention.