HK1027178A - Method and system for networked installation of uniquely customized, authenticable, and traceable software applications - Google Patents

Description

Method and system for online installation of uniquely customized, legal, and traceable software applications

The present invention relates to a method and system for electronic sale and installation of software applications uniquely customized, legitimate, and tracked for each user to the user over a network.

With the increasing importance and reliability of computer-on-networks environments, such as the internet, electronic software sales (ESD) as a means of selling software applications to users has become increasingly important. Currently existing online facilities allow users to order and install software applications without having to physically deliver the compressed packaged software. Typically, a software publisher will prepare a master version of a software application for electronic sale. The user then places an order for the software application on-line, and the publisher receives and fulfills the order. The user then downloads the software application and installs it on his own computer.

A disadvantage in current online facilities is that the software applications delivered to the user are identical in form to the software applications obtained from the distributors and catalogs. Absent encryption protection, users are free to share sales versions of software with each other.

Even if there is encryption protection, the potential for illegal copying is quite large, since all users have exactly the same copy of the software application (and necessarily the same way of encryption). In all cases where there is a single basic decryption key, where the decryption key (or its equivalent) is mostly inserted by the user, the user can share the software application with other users who utilize the key to obtain an unused amount of use of the program. There are bulletin boards and internet sites dedicated to sharing these decryption keys, where access to the non-pay-for-use population of programs is desired by applying for their respective decryption keys of the applications.

Furthermore, although more sophisticated anti-piracy methods are provided in software applications, it is often not uncommon for software "hackers" to generate "cracked" programs, and processing a freely distributed, limited-functionality version of a program with such programs can generate a fully functional modified version of the program that does not necessitate the purchase of usage rights. For the high hands of simply applying "unveiled" universal decryption keys, it is not useful even to distribute the different single-key forms in the most elegant and large quantities (which may involve one-time responses for dynamically trying to derive the key). Although this "unveiling" involves more technical complexity than the above-described shared key, it is very similar in distribution channel and possible impact on product revenue.

Furthermore, software applications sold by conventional ESD techniques do not provide any means of protecting their respective integrity against unauthorized tampering.

Portland software corporation produces a product known as ZipLock^TMTrade mark sold electronic software sales system that encapsulates software for electronic sales over the internet. ZipLock^TMThe system discloses a system for selling standard executable software applications protected by cryptographic keys from a secure server to a client residing on a user's computer. The data entered by the user is transmitted to the security server and used to construct a customized digital license that is sent to the user in a separate computer file. ZipLock^TMThe system provides neither a mechanism to detect tampering with the executable software application itself, nor is it able to track whether a digital license is included in the unlicensed reselling of the software application.

The prior art discloses some other systems and methods for preventing software sold electronically to a user from being used illegally. In U.S. patent No. 5,509,074 to Choudhury, a method of protecting electronically distributed material using cryptographic protocols is disclosed. The first illustrated embodiment requires dedicated hardware in order to decrypt the document sent to the user. This limits the widespread use of this approach on personal computers used by the general public. In the second approach, no dedicated hardware is required. In this method, the publisher modifies the interline or interword spacing of the document to make each document unique to each user. The unique document is then encrypted and transmitted to the user's computer. Upon receiving the encrypted document, the user's computer prompts the user to enter his or her secret key, which is used to decrypt the document for viewing. The method disclosed in this document does not prevent piracy, it simply works to trace out the user's resistance to piracy through the available pirate documents. Furthermore, this document only fits data files and cannot protect any type of executable file.

In U.S. patent No. 5,416,840 to Cane, a method and system for securing the sale of computer programs over broadcast media, such as radio frequency utility broadcasts or computer networks, is disclosed. In this document, the method involves encrypting at least a portion of a computer program, providing a password to a user for decrypting the computer program so that the computer program can be installed and used. A unique password is generated and communicated to the user for subsequent use in decrypting selected software programs hosted on the media. Although it discloses a method and system for generating, sending and using unique passwords that cannot be shared by different users of a software application, this document requires users to have proprietary hardware, which limits widespread use with mass-owned personal computers.

In Yuval, U.S. patent No. 5,586,186, a method and system for controlling illegal access to software sold to a user is disclosed. The main components of the system are an encryptor, a user key generator and a decryptor. The encryptor generates an encryption key and a decryption key, encrypts the software with the encryption key, and stores the encrypted form of the software onto a broadcast medium such as a CDROM. The user key generator generates a unique key using a digital representation of the identification information provided by the user and the decryption key. The decryption machine is responsible for decrypting the encrypted form of the software using the identification information and the unique user key provided by the user. The decryption method disclosed in this document allows a large number of different but logically similar keys to be used as decryption keys, each of which is unique to a particular user. However, this document does not disclose means for customizing a software application with user-specified data so that the software application itself can be authenticated. Furthermore, this document does not prevent piracy through shared keys, it only hinders piracy through traceable keys.

The invention relates to a method for electronically selling a software application from a distributing computer to an installing computer, comprising the steps of: the method includes receiving identifying information at the distribution computer, embedding the identifying information into the software application to form an identifiable software application at the distribution computer, generating a cryptographic signature for the identifiable software application, embedding the cryptographic signature into the identifiable software application to form an identifiable and verifiable software application, and transmitting the identifiable and verifiable software application from the distribution computer to the installation computer.

The method and the system of the invention disclose an on-line software customization, transmission and installation mode. Rather than selling software applications to users under the installation of fully homogeneous, non-traceable executable files on an installation computer, the methods and systems disclosed herein disclose a means to build, distribute, and install on the installation computer a unique artifact of software applications that is verifiable and traceable to a particular user.

The methods and systems disclosed herein provide for a User Installation Agent (UIA) residing on an installation computer to establish a connection with a secure sales agent (SDA) residing on a sales computer through a distribution channel. The UIA and/or SDA prompts the user for identification information that is used, along with pertinent business information such as license terms, to establish a unique data set that is embedded by the SDA into the desired software application. By using a cryptographic hash algorithm and private/public key cryptography, where the private key is known only by the SDA, a cryptographic signature of the desired software application and the embedded data set is calculated and embedded into the software application. The software application with the embedded data and the cryptographic signature is sent to and installed on the installation computer through a distribution channel. Optionally, the installation computer can verify that neither the software application nor the embedded data has been tampered with using the cryptographic signature. The public key (set) for decrypting the cryptographic signature may be sent to the installation computer together with the software application or by other means, such as email, internet bulletin board, etc. After installation, the embedded data and cryptographic signatures are used in various ways, for example, to provide a means of tracking users of the software application, to manage the continued integrity of the software application, to ensure that the license status is continuously maintained, to perform virus checks, or to automatically upgrade the software application itself.

FIG. 1 is a block diagram of a system overview to illustrate various inputs and components of the system and method of the present invention;

FIG. 2 is a data flow diagram of the structure and operation of a secure distribution agent employed by the present invention;

FIG. 3A is a block diagram showing structural details of a collection distribution file using a single-step cryptographic process;

FIG. 3B is a block diagram showing structural details of a collection distribution file processed using two-step cryptography;

FIG. 3C is a block diagram showing structural details of a cryptographically processed collection distribution file utilizing a variation of the two-step cryptographic process shown in FIG. 3B;

FIG. 4 is a block diagram of the structure and operation of a user installation agent as employed by the present invention;

FIG. 5 is a block diagram showing a means of extracting and verifying embedded data from an installed distribution file;

FIG. 6 is a flow chart of a first embodiment of the present invention that verifies embedded data with a public encryption key;

FIG. 7 is a flow chart of a second embodiment of the present invention that verifies embedded data with each user's unique cryptographic key; and the number of the first and second groups,

FIG. 8 is a block diagram illustrating various uses of an installed software application sent to a user via the present invention.

FIG. 1 illustrates various inputs and components of the system and method of the present invention. The top level represents an electronic software sales (ESD) back-end component 10 comprising a software exchange station, software manufacturer, issuer, credit card facilitator, etc., all of which exchange with a Secure Distribution Agent (SDA)100 residing on a distribution computer, which forms an essential part of the present invention. SDA100 interfaces with each ESD backend component 10 via the internet or a private computer network to provide payment method support, to load software applications from a publisher, and so forth. The exact characteristics of the ESD backend component 10 can be varied without affecting the method and system of the present invention.

SDA100 is comprised of a cooperative software program system that operates in a secure environment. The nature of the secure environment is not important to the present invention as long as it ensures privacy of the user's data, ensures authentication of the user and other possible third parties, and operationally properly restricts external access. The environment may or may not be physically separate from the installed computer. The structure and operation of SDA100 is illustrated in more detail in fig. 2.

One of the inputs to SDA100 is a database set 20 of supported software applications, licensing terms, licensed users, and the like. Prior to and during the operation of the present invention, SDA100 transmits and receives pertinent data to/from database group 20. The exact nature and content of the database set 20 is not an essential feature of the present invention.

The distribution channel 300 shown in fig. 1 may consist of a computer network, such as the internet or a private network, or a security layer required to maintain security if the SDA100 is in close proximity to the User Installation Agent (UIA) 200. Alternatively, it may comprise some combination of these components. The distribution channel 300 is used to connect the UIA200 and SDA100 (and thus the distribution computer and the installation computer) to exchange information between the two agents, and to distribute the aggregate distribution file 170 (shown in fig. 2) from the SDA100 onto the UIA 200. Although a distribution channel 300 is shown between SDA100 and UIA200, the system of the present invention does not require that SDA100 be physically remote from UIA 200.

At the user end is the UIA200, and the UIA200 is an installation/automatic upgrade software program residing on the installation computer. The program is used to communicate with SDA100 via distribution channel 300 and to perform the required operations, described in more detail below, on the installation computer. Although one UIA200 is typically required for each supported software application, it is well known in the art to develop a UIA200 that can support multiple software applications. Also shown in FIG. 1 is a distribution form 30 of the UIA200, which includes various supporting files. The nature of the distribution form 30 of the UIA200 is not important to the operation of the present invention. Any of a CD ROM, World Wide Web (WWW) download, floppy disk, etc. may be used.

The UIA200 receives user input data 32 such as name, address, payment options, etc. and data related to receiving an end user license. The UIA200 may also be input with context sensitive data 34 for processing, such as the speed of the CPU, the size of the hard disk, the speed of the modem, and so forth. The identification information processed by the UIA200 may include any information regarding the buyer, vendor, installation agent, date, serial number, license description, etc. These data can be used to automatically register the desired software applications and buyers or their business agents.

As described above, the identification data 32, 34 constitutes identification information relating to the user, the computer thereof, or the like. The UIA200 processes the identification data 32, 34 and transmits it to the SDA100 over the distribution channel. It will of course be understood that it is not necessary to transmit the identification information to SDA100 via distribution channel 300. For example, identifying information may be entered into SDA100 locally, orally, in writing, or otherwise electronically. SDA100 combines the identification information 32, 34 with the data stored in database set 20 to produce a collection distribution file 170 that is uniquely customized, verifiable, and traceable to the user. The aggregate distribution file 170 is sent to the UIA200 through the distribution channel 300. The output from the UIA200 is a unique custom software application 15 (hereinafter referred to as an "installed collection distribution file") that is installed on the installation computer with the identification information embedded therein.

Although the description of the present invention implies that the "user" is an individual user of the software application 15 installed on a personal computer, those skilled in the art will appreciate that the present invention may also operate in a networked end-user environment, where the "user" is a network administrator responsible for installing software on a central server for use by several end-users.

Fig. 2 is a data flow diagram of the structure and operation of SDA100 employed in the present invention. Original distribution file 130 is shown as an input to conversion program 110. In a contemplated implementation, the original distribution file 130 is input to the SDA100 by the database group 20 shown in fig. 1. It should be understood that the original distribution file 130 does not have to be input to the SDA100 via the database cluster 20, as the original distribution file 130 may already reside on the distribution computer that contains the SDA 100. Conversion program 110 has as another input data 140 to be embedded in distribution file 130 and has the required public/private cryptographic key pair 150. The embedded data 140 is generated by the user interactive program 120, and the user interactive program 120 interacts with the user through the UIA200 to receive the identification data 32, 34 (shown in FIG. 1) and data from the database farm 20 supporting the software application, licensing terms, licensed user.

Although the embedded data 140 may be in any form and in any content, it is contemplated that the embedded data 140 will include information that can track the software application 15 to individual users as well as license execution. For example, the embedded data 140 may include a unique serial number that identifies the aggregate distribution file 170 that is distributed to the user. This eliminates serial number fraud common in the software industry, where existing software applications can only perform simple validity checks that can be spoofed by the use of extensive, single valid serial number hash over multiple uses. The embedded data 140 may take the form of a full license agreement customized for each user including the user's name, address, software serial number, licensing terms, and the like. A record of the user information collected by the user interaction program 120 may be maintained by the database group 20.

The output of transformation program 110 is aggregate distribution file 170, which contains both the contents of original distribution file 130, embedded data 140, and the cryptographic signatures of embedded data 140 and original distribution file 130. The aggregate distribution file 170 is then sent to the UIA200 through the distribution channel 300. The UIA200 then installs the aggregate distribution file 170 onto the installation computer. Once the aggregate distribution file 170 is installed, it takes the form of an installed aggregate distribution file 15.

Through its connection with the UIA200, SDA100 may negotiate with the user for arbitrary license terms, display the End User License Agreement (EULA), confirm acceptance of the agreement, and automatically perform online registration of software according to the user identity and specific license terms that have been established. For business and legal considerations, for example, SDA100 may present different quote terms and license terms to users in different countries, and possibly provide different executable versions. In addition, different offers may be provided depending on the attributes of the installed computer, such as CPU power.

SDA100 is not required to be intelligent in determining that the user-proposed address and credit card number are valid, compatible, and functionally located within a given geometric area. These functions may be performed by the high-level ESD component 10 shown in fig. 1.

FIG. 3A illustrates the process of building the collection distribution file 170 in more detail. For purposes of illustration, it is assumed that the structure of the original distribution file 130 includes header information and different types of internal sections for code, static data, and the like, such as Windows^TMThe 'portableexecutables' (PE) program file of (a). It will be appreciated by one of ordinary skill in the art that the method and system of the present invention can be applied to a number of different file formats. Similarly, the inputs 140, 151 to the conversion program 110 and the output 170 of the conversion program 110 are shown as computer files, but they may be in-memory images, streams from other processing machines, and so forth.

A typical sequence of steps performed by SDA100 to construct aggregate distribution file 170 is described below.

1. The conversion program 110 is run as a result of the user interaction program 120 determining that conversion is required (i.e., that a particular collection distribution file 170 is approved for transmission in accordance with the method of the present invention, and that the required embedded data blocks 140 have been constructed). Unless otherwise instructed to do so, the conversion program 110 performs all subsequent steps.

The goal is to obtain what is commonly referred to as a "digital signature" or "cryptographic signature," which essentially has two aspects:

(i) generating a cryptographic fingerprint uniquely corresponding to the data "ed" 130, 140 by using a cryptographic hash algorithm; and

(ii) the cryptographic fingerprint is protected by encryption with a private key so that a recipient of the cryptographic fingerprint by using a public key and a cryptographic algorithm can confirm that the data "ed" 130, 140 has not been compromised and does not need to have the ability to generate a new cryptographic fingerprint therein and does not otherwise change the data in a plausible manner.

These two steps are essential to achieving the advantages of the present invention, as without these two steps a third party can intervene or change the data without the recipient being able to perceive it. This process is different from simply encrypting the data 130, 140, such an approach is not sufficient for the operation of the present invention because it is not a perceptible approach to falsely changing the data 130, 140.

2. The input/output logic 111 of the conversion program reads in the required original distribution file 130, its corresponding cryptographic private key 151 and the data 140 to be embedded. Although not required by conversion program 110, a public key 152 may be passed in to add it to collection distribution file 130. A cryptographic signature 174 is generated using the cryptographic hash algorithm 112 and a public-private key (PPK) encryption algorithm 113. The basic steps of the process are:

2.1 applies a one-way hash function "hf" to the data "ed" 130, 140 to generate a cryptographic signature "edh", i.e., edh ═ hf (ed). The requirements for the cryptographic fingerprint are as follows: (i) which yields a reasonable compression result, i.e. length (edh) < length (ed), and preferably a fixed-length result, (ii) the fingerprint itself cannot be used back to determine the original data block, i.e. there is no inverse hash function "bhf" and thus bhf (edh) ed; (iii) it is particularly sensitive to changes in "ed"; that is, a single bit change in "ed" would change about 50% of the bits in "edh", and (iv) constructing a fake embedded data block "fed" that would generate the same fingerprint as "ed", that is, hf (ed) ═ hf (fed), is extremely difficult. There are several algorithms that meet these requirements, such as MD5 (message digest 5) and SHA (secure hash algorithm). Other algorithms that also meet the above criteria may be used with the present invention.

2.2 encrypts the cryptographic fingerprint "edh" using private key 151 "prk" and public/private encryption function "ppef" to generate cryptographic signature "edf" 174, i.e.: edf — ppef (prk, edh). The requirements for the encryption function "ppef" are as follows: (i) it produces results that are not significantly larger than its input; (ii) it effectively protects relatively short data sets because "edh" is several bytes long instead of thousands; (iii) it is computationally infeasible to derive the private key "prk" using the public key 151 ("puk") and the cryptographic signature "edf" 174 or using multiple instances of "edf" 174 (which can be seen on the installation computer), i.e., there is no deciphering function "cf" that makes puk ═ cf (edf, puk); (iv) there is no conceivable means of replicating "ppef" with "prk" under the actual lack of possession of both "ppef" and "prk". In principle, "ppef" can be derived from its corresponding decryption function, so that in the real world "prk" is an important secret; (v) its corresponding public key decryption function "ppdf" has acceptable performance for the file length of interest on a typical installation computer. Note that if a particular ppef/ppdf is selected for security reasons that does not yield acceptable performance, only a portion of the selected file may be encrypted and still provide the same benefits; (vi) which is applicable (preferably, by conventional cryptanalysis) to the domain, i.e., digital signatures. There are several algorithms that meet these requirements, such as those of RSA and Rabin and ElGamal. Careful selection of implementation parameters may help to achieve desired security and performance.

3. The cryptographic signature 174 from step 2.1 and the data 140 to be embedded are inserted into the original distribution file 130 to generate the aggregate distribution file 170. This insertion is not simply a copying of the bits to the middle of the file because it must comply with the format requirements of the particular file type. For example, the header must be updated to identify new data, and so on.

The system and method of the present invention does not require that embedded data 171 or cryptographic signature 174 be located in collection distribution file 170 in any particular manner. What is needed is: (i) the software installed on the computer, in particular the UIA200, is capable of locating the embedded data 171 and the cryptographic signature 174, and (ii) the aggregate distribution file 170 is capable of performing its intended function after installation on the installed computer; for example, if it is an executable file, it still conforms to the structural requirements and other platform requirements so that it can be loaded and run on the installation computer as before the conversion process. For example, if the file is in the general-purpose format of current computers containing Intel microprocessors and is running under the Microsoft Windows operating system, the conversion program 110 should examine the "header" section of the original distribution file 130 to determine if there are sections containing static data in order to avoid sections containing executable code. The static data section should be selected and the appropriate location for the user to embed the data block 171 and the cryptographic signature 174 should be found or established. This can be done, for example, by: (i) determining that an existing static data block has unused capacity sufficient to add the data, (ii) allocating a new static data block, or (iii) expanding an existing static data block.

The method illustrated in fig. 3A discloses a single-step process in which a cryptographic signature 174 is determined for the original distribution document 130 and the embedded data 140. An alternative method, as shown in fig. 3B, employs a two-step process in which a cryptographic signature 172 of embedded data 171 is first generated using the same algorithm described in step 2 above. The embedded data cryptographic signature 172 is then embedded into the original distribution document 130. The original distribution file 130, the embedded data 171, and the embedded data cryptographic signature 172 are then input to a second cryptographic step in which the overall cryptographic signature 176 is determined using the same algorithm described above in step 2. A benefit of the two-step process is that it increases the ability of the system and method of the present invention to verify and detect tampering with a software application installed on an installation computer. For example, separate cryptographic public/private key pairs may be provided for the two cryptographic signatures 172, 176. Furthermore, the two-step process can extract and verify the embedded data 171 even if the original file content 173a, 173b is corrupted.

An alternative to building the collection distribution document 170 using a variation of the two-step cryptographic process is to first obtain a first cryptographic signature 175 using only the original document content 173a, 173b and a second cryptographic signature 172 using the embedded data 171. This is shown in fig. 3C. This approach has all the advantages of the two-pass process shown in fig. 3B, and also allows independent verification of the embedded data 171 and the original file content 173a, 173B. This allows the user to confirm that the original distribution file 130 provided by the publisher was not altered by the online installation process disclosed in the present invention.

It will be appreciated by those of ordinary skill in the art that it is not necessary to generate any of the cryptographic signatures 172, 174, 175, 176 shown in fig. 3A, 3B and 3C using the same cryptographic public/private key pair, or even the same key algorithm. Further, the cryptographic signatures 172, 174, 175, 176 do not have to be calculated each time the collection distribution file 170 is distributed to a user. SDA100 may maintain a partial pre-computation signature database to speed up the relevant computation. Cryptographic hardware support available at the installation computer, such as an RSA coprocessor, can be used to achieve good responsiveness at maximum security. Furthermore, collection distribution file 170 need not be integrally constructed by SDA 100. All that is necessary is that the aggregate distribution file 170 can be transmitted by the UIA200 in its entirety.

Fig. 4 illustrates the structure and operation of the UIA200, the UIA200 including a transitional installation index 204, a transitional installation input file set 205, and a UIA native executable software program 203. Those skilled in the art will appreciate that there are many ways to implement UIA program 203. Since a significant portion of the UIA200 functionality involves user interaction and dialogue with SDA100, options for implementing the UIA200 include making it an adjunct to a World Wide Web (WWW) browser, or implementing it as a stand-alone program that embeds or invokes existing browser capabilities on the installed computer.

The typical execution sequence of the UIA200 is explained below:

1. after copying the UIA program 203 and its supporting data 204, 205 onto the installation computer, the user launches the UIA program 203. Note that the UIA program 203 may also be installed remotely, for example as an active program within the browser frame sent by the WWW server. Unless otherwise noted, all subsequent steps are performed by UIA program 203.

2. The installation computer reads out installation index 204 and installation input file set 205 to determine the particular default SDA100 corresponding to the installation of the desired software application (referred to as the "installed collection distribution file") 15.

3. The installation computer is checked to determine the presence of appropriate means, e.g., a TCP/IP network interface, modem, etc., for establishing communication with SDA 100. If such a device cannot be found, the program optionally assists the user in finding the parameters for proper operation and then issues a warning to stop. This is because access to SDA100 is essential to the operation of the present invention.

4. User 1 is prompted with default data from steps (2) and (3) above, telling the UIA program 203 where to locate the desired SDA100 and on which type of distribution channel 300. User 1 is then given the opportunity to change this information, either for business reasons (e.g., perhaps some SDA has changed name or location), or for technical reasons (e.g., the user does not have a working TCP/IP connection and wishes to use a direct modem link, perhaps through an 800 toll-free telephone number.)

5. The UIA program 203 establishes contact with SDA100 through distribution channel 300. If not, the UIA program optionally alerts the user to determine the parameters for proper operation and stops. Although optional for the security of the present invention to operate the distribution channel 300, it is contemplated that the distribution channel 300 may support an appropriate protocol that protects SDA100 from fraud. Common protocols that support authorization and privacy, such as Secure Sockets Layer (SSL), are properly available.

UIA program 203 acts as an intermediary between the user and SDA100, enabling the user to determine the legal agreements SDA100 can support for the desired installed set distribution file 15. The UIA program also has the ability to determine whether the available system resources of the installing computer meet the requirements of the desired installed collection distribution file 15.

There is no technical limitation on the contents displayed to the user, the problems the user may pose, and the various choices in the data that the installation computer may collect, etc. Because SDA100 operates to undergo data acquisition, data embedding, software distribution, and software installation processes, the systems and methods of the present invention may employ various levels of passwords without even notifying users of the password keys or any information they may deduce. This is in contrast to other electronic delivery systems, which typically require input, secret keys, or derivation sequentially off-line, thereby being significantly compromised to the user. Of course, the public key used in the verification of the cryptographic signature is an exception, and the user can easily determine the public key, but it is not a security issue since they cannot be fraudulently applied.

7. Assuming that user 1 meets all criteria set forth by SDA100, SDA100 will determine the specific set of files that must be sent to UIA200 to complete the installation on the installation computer, and in particular at least one aggregate distribution file 170 (shown in fig. 3A-3C). The nature of the agreement agreed upon between user 1 and SDA100, or how the agreement takes effect, is immaterial to the system and method of the present invention. This is taken care of by SDA100 and the commercial system it is directed to, if any. Most importantly, the UIA200 is not, and cannot itself, decide whether an agreement has been reached between the user and the SDA 100. The UIA200 does not and should not have access to all of the information required to complete the installation, except through interaction with the SDA 100.

SDA100 sends an index of the desired distribution file to ULA200 via distribution channel 300. The UIA200 augments its own local index with the index to form a complete index for the upcoming installation.

The SDA100 constructs one or more aggregate distribution files 170 and any other files required for installation and sends these files to the UIA200 via the distribution channel 300.

UIA program 203 completes the installation of installed distribution files 15 using its local index and support files 204, 205 in a manner consistent with the platform on which the computer is installed. In particular, the UIA200 installs the collection distribution file 170 without the cryptographic signature 174 and embedded data 171 being affected. Once the aggregate distribution file 170 is installed on the installation computer, it is referred to as an installed aggregate distribution file 15. UIA program 203 also performs other system updates 212 as needed, such as updating operating system registration (in the case of windows 95) and installing any additional application files. Other optional operations may also be involved, such as leaving appropriate 'uninstalled' utilities.

12. If an error occurs, the UIA program 203 may notify the SDA100 to restart the installation. If no error occurs, the UIA program 203 notifies the SDA100 that all the required data has been received. This should be used, for example, as a trigger for SDA100 to conduct a financial transaction. Placing financial matters in the latter half of the process minimizes the likelihood that the user will be charged without successfully installing the software application, which reduces one cause of user frustration.

UIA program 203 deletes any transition files, indexes, etc. that may be placed in the installation computer.

UIA program 203 disconnects and exits SDA100, distribution channel 300.

Once the optional verification process, described in further detail below, is complete, the user may then run the installed collection distribution file 15 on the installation computer. It should be understood that the later described verification process may be performed before or after installation is completed.

The method and system of the present invention should reduce disputes caused by the failure to successfully install purchased software. If the installation computer does not have sufficient resources to run the required software application, the UIA200 may detect and alert the user before any financial transactions are made. Further, the final financial commitment for the user to purchase the software application may be completed after the installation process, so that the probability that the financial transaction is successful but the installation itself fails may be low.

It will be appreciated by those of ordinary skill in the art that the UIA200 can be distributed to users in the form of a medium that is mass produced and contains the original distribution file 130, or that the UIA200 can be derived from a single copy of the ticket without being subject to successful remixing reuse. In this case, SDA100 sends only the incremental information it needs to construct the aggregate distribution file 170 and complete the installation to UIA 200. Any attempt to pirate a software application can be defeated by ensuring that the distributed form of the UIA200 contains an incomplete set of executable files, thereby requiring the base data from SDA100 for execution on the installation computer.

Fig. 5 shows the verification and extraction of user data from an installed aggregate distribution file 15 to verify that neither the original file content 173a, 173b nor the embedded data 171 has been tampered with. This step is optional for the operation of the present invention, as the user can run the installed collection distribution file 15 without verification. It should be understood that the verification process described below may be performed before or after installation is complete. If verification is performed prior to installation on the installation computer, the UIA203 performs the following process on the aggregate distribution file 170, rather than on an installed aggregate distribution file.

The process shown in fig. 5 is related to the installed collection distribution file 15 using the two-step process shown in fig. 3B. The principle of authenticating and extracting user data from an installed collection distribution file 15 constructed using the single-step cryptographic process shown in fig. 3A or constructed using a variation of the two-step process shown in fig. 3C is the same as described below, but with appropriate modifications depending on the characteristics of the cryptographic keys to be compared.

Although a separate authentication and reading program 400 is shown to perform the functions of authenticating and reading embedded data 171, those skilled in the art will appreciate that these functions need not be implemented in such a separate program, but may be combined with the functions of other programs, such as UIA200, license inspection programs, virus inspection programs, program loading software, copying programs, and the like. A typical execution sequence of the verification and read-out procedure 400 is described below:

1. the authentication and readout routine 400 is run either by the user or by automatic invocation of other routines such as the UIA 200. The following steps are performed by the verification and readout routine 400 unless otherwise indicated.

2. The decision of which installed collection distribution file 15 to process is made either by prompting the user or communicated as a parameter by the UIA 200. It is also determined (if derivable from a particular implementation, as the files themselves contain different) which particular public key 152 is applicable to the installed collection distribution file 15.

3. The studied installed collection distribution file 15 is opened and checked that it meets the application format requirements. For example, a given implementation may support Intel^TMExecutable (EXE) and Dynamic Link Library (DLL) files in 'PE' format for processors. If the installed collection distribution file 15 fails these basic checks or cannot be found, the verification and readout program 400 issues an appropriate warning and stops.

4. The document is examined to determine the location of the total cryptographic signature 176, the embedded data cryptographic signature 172, and the embedded data 171. The installed collection distribution file 15 may be formatted in various ways to support this determination, such as including pointers to these sections within the file header. If applicable in this particular implementation (i.e., the public key 152 is contained in a file, as opposed to being determined by the authentication and readout program 400), the desired public key 152 is found and extracted.

If any of the above steps fails, the verification and read process 400 fails with an appropriate alarm.

5. The master cryptographic signature 176 is decrypted into an unencrypted form 176a (decrypted remote master fingerprint) using the public key 152.

6. A local version of the total cryptographic signature 176b (a locally calculated total fingerprint) is calculated using the same known cryptographic signature algorithm employed by SDA 100. This calculation must exclude the total cryptographic signature 176 itself, i.e., cover all parts of the installed collection distribution file 15 except 176, so that the locally calculated total fingerprint 176b is independent of itself.

7. The locally computed total fingerprint 176b is compared to the decrypted remote total fingerprint 176 a. If they are different, the authentication and readout program fails with a warning that the installed aggregate distribution file 15 is corrupted. At this point, the UIA200 may be invoked to make contact with the SDA100 to again obtain the installed aggregate distribution file 15.

8. The embedded data 171 is extracted and graphically presented to the user if the program is invoked by the user and is communicated to the caller routine in the form of a message if invoked by software.

9. The embedded data cryptographic signature 172 is decrypted into its unencrypted form 172a (decrypted remote embedded data fingerprint) using the public key 152.

10. A local version 172b of the embedded data cryptographic signature 172 (the locally calculated embedded data fingerprint) is calculated using the same known cryptographic signature algorithm as employed by SDA 100.

11. The locally computed embedded data fingerprint 172b and the decrypted remote embedded data fingerprint 172a are compared. If they are different, the verification and read-out procedure fails in case the warning embedded data 171 is destroyed.

If this is followed by the single-step process shown in FIG. 3A, then a similar comparison process is performed on the cryptographic signature 174. Similarly, if a variation of the two-step cryptographic process shown in FIG. 3C is performed, then a similar comparison process is performed on the original document content cryptographic signature 175.

Fig. 6 is a flow chart that integrates the processes described with respect to fig. 2, 3A, 3B, 3C, 4, and 5. Note that the public key 152 used to verify the integrity of the installed collection distribution file 15 may be sent to the UIA200 by any means, as it is not secret and may be used for more than one purpose. The public key may be embedded in collection distribution file 170, it may be explicitly sent to the user as a separate file or message, or it may be automatically sent by the installation computer from a network hosting facility (e.g., Verisign)^TMCompany).

Fig. 7 is a flow diagram of another set of processes that may be employed in accordance with the present invention in which the original file content 173a, 173b is encrypted using the unique private password that is calculated by the SDA100 for that particular transaction. The SDA100 maintains a record of the unique private key and sends the corresponding unique public key and the collection distribution file 170 to the UIA200 via the distribution channel 300. The UIA200 decrypts the collection distribution file 170 using the public key. For security reasons, it is desirable not to permanently store the public key on the installation computer. Alternatively, the unique public key is made to exist in the Random Access Memory (RAM) of the computer only during installation. This makes it virtually impossible to redistribute the aggregate distribution file 170.

Although the present invention has been described with reference to various preferred embodiments, those skilled in the art will appreciate that many changes, substitutions and alterations are possible. Various uses of the installed collection distribution file 15 are shown in fig. 8. After installation and verification by the UIA, the installed aggregate distribution file 15 may be run conventionally without using the embedded data 171 in any way. To ensure license compliance, the installed collection distribution file may be run in conjunction with a license enforcement program to verify that any license terms that make up a part of embedded data 171 are adhered to. Embedded data 171, as well as cryptographic signatures 172, 174, 175, 176 (depending on the manner in which collection distribution file 170 is constructed) may also be used as input to some virus checking program so that integrity checking of installed collection distribution file 15 may be performed by using public key 152 and the same known cryptographic signature algorithm employed by SDA 100. The verification and readout program 400 shown in fig. 5 may also be run by itself or together with a verification loader each time the installed collection distribution file 15 is run, to refuse to tamper the file and not allow the tampered installed collection distribution file 15 to run. It is also possible to use only the embedded data 171 for display to the user.

The methods and systems disclosed herein may also be used to upgrade installed collection distribution files that are present on an installation computer. In this case, the UIA200 and SDA100 will confirm the license status of the existing installed collection distribution file 15 on the installation computer, and then invoke the methods and systems disclosed herein to build, transmit and install an upgraded version of the installed collection distribution file 15 to the installation computer. The upgrade capability of the present invention may be invoked at the request of a user, or may be invoked automatically when the UIA200 detects that a new version of the original distribution file 130 is available.

The uniqueness of the installed aggregate distribution file 15 may be used to limit its operation to a dedicated Central Processing Unit (CPU) in the installation computer. The identification of the CPU for such purposes may be made by the UIA200 at the stage of collecting the data 32, 34 for transmission to the SDA 100.

The SDA100 and UIA200 disclosed herein are not limited to being invoked only when an installed distribution file 170 is installed or upgraded. For example, in a computer game environment, the SDA100 and the UIA200 may be invoked when the user arrives somewhere in the game to give the user the option to purchase additional functionality or levels of the game.

The present disclosure does not presuppose that the UIA200 does not possess the additional intelligence to enhance the functionality of the present invention. For example, the UIA200 may have the intelligence to find and identify the respective personal digital license on the installation computer, which establishes its identity, which is sufficient to authorize all or a portion of the relevant transaction. Such personal digital licenses and methods for their use are subject to established standards, e.g. Verisign, a commercial thermography provider^TMStandards adopted by companies. Further, the UIA200 may have a look-up and identification of digital "coupon" licensesIntelligence, such an offer determines that a user has certain privileges, such as a right to a particular price for certain software, or a right to determine his membership in a particular group, such as a company. In addition, the UIA200 should locate prior files installed according to the method of the present invention and determine the embedded data 171. If the UIA200 determines that there is information that may affect the terms of the transaction or that there is information that indicates a user's possible interest, e.g., an upgrade, the UIA200 may send this information to SDA100 so that SDA100 may mediate the transaction, announce the upgrade, etc. as appropriate. A typical example of this is to examine the word processing application software installed in accordance with the present invention to determine that the user is eligible for free upgrade so that the present invention can then proceed to installation.

In another set of variations of the present invention, installed aggregate distribution file 15 is a file that employs the principles of Nortel Algorithm Authority (NAN) disclosed in U.S. patent application No. 08/674,037 for adding substantial self-management to its own integrity. In a first variation, the run-time NAA algorithm (which already has the ability to use the native code of the installed collection distribution file 15 as input required for proper operation, and thus the ability to force a catastrophic failure in the event of tampering) extends the scope of this input to include an in-memory copy made up of one or more data items added by the SDA100, such as the master cryptographic signature 176.

In a second variation, the "launch stub" component may proceed further, i.e., extract and decode the embedded data 171 in the installed collection distribution file 15, and compare the license terms thereon (e.g., such as a dedicated CPU identified by some physical media access control address on a network card) with the terms found by checking the current environment. According to the principle of Nortel algorithm authorization, the "boot stub" does not have to "decide" whether or not to proceed, since such decision points are obviously attack points for 'hackers' who wish to defeat the security mechanism. Instead, it will modify the data according to normal program execution so that the program will continue to run only if the data corresponds to the appropriate environment for each license. For the first variant, the application should be pre-built for the particular situation, since its appropriate control flow, in accordance with the pending technique, simply uses the original 'incorrect' input data as the 'corrected' data resulting from applying the correct license data or a simple derivative thereof.

The invention disclosed herein does not necessarily have to change the functionality of the installed form of the installed collection distribution file 15, but only adds information and verifiability thereto. There are then some means by which the efficacy of the installed collection distribution file 15 can be changed in a new manner as allowed by the present invention. In one variation, SIA100 can access various executable forms of a given program or access software routines that dynamically build different forms to generate a program that meets the functionality/price requirements of a particular user and/or that proactively bundles itself to very specific license terms. For example, in the Microsoft Windows environment, different utilities may be embedded through different Dynamic Link Libraries (DLLS) that are optionally included.

In another variation, the initial executable form of the program file has special functionality built in and the option of binding with the license, and SDA100 will deny (possibly verifiable) entry into the executable file of data that lets the executable file display its desired efficacy. In yet another variation, SDA100 may utilize routines having detailed support for a particular program structure to add variable code to prior executables that were not explicitly designed to possess such a variation.

The various embodiments described herein centralize a single "core" file of a particular file type as a cornerstone of installation and security for software applications. However, the method of the invention is of course applicable to more than one file or more than one file type in a particular situation. For example, all static files associated with an installed software application may receive embedded information so that they are verifiable and associated with a particular application and installation instance.

Claims (17)

1. A method for electronically distributing a software application from a distribution computer to an installation computer, comprising the steps of:

a. receiving identification information at the distribution computer;

b. embedding the identifying information into the software application at the distribution computer to form an identifiable software application;

c. generating a cryptographic signature for the identifiable software application;

d. embedding the cryptographic signature into the recognizable software application to form a recognizable and verifiable software application; and

e. transferring the identifiable and verifiable software application from the distribution computer to the installation computer.

2. The method of claim 1, wherein the step of generating a cryptographic signature for said identifiable software application comprises the steps of:

a. applying a one-way hash function "hf" to the identifiable software application "ed" to generate a hash result "edh", wherein edh ═ hf (ed); and

b. the hash result "edh" is encrypted with a cryptographic key to obtain a cryptographic signature.

3. The method of claim 2, wherein the one-way hash function is generated using one of a message digest 5(MD5) algorithm or a Secure Hash Algorithm (SHA).

4. The method of claim 2 or 3, wherein the step of encrypting the hash result "edh" comprises the step of encrypting the hash result "edh" with a public/private encryption function "ppef" and a private cryptographic key "prk" to generate the cryptographic signature "edf", wherein edf _ ppef (prk, edh).

5. The method of claim 4, wherein the public/private encryption function "ppef" is generated using one of an RSA algorithm, a Robin algorithm, and an ElGamal algorithm.

6. The method of claim 1, 2, 3, 4 or 5, wherein the distributing computer and the installing computer are distributed via an internet connection.

7. The method of claim 1, 2, 3, 4, 5, or 6, wherein the identification information received at the distribution computer is transmitted from the installation computer.

8. A method of electronically receiving at an installation computer a software application distributed from a distribution computer, comprising the steps of:

a. receiving an identifiable and verifiable software application from a distribution computer, the identifiable and verifiable software application having embedded therein identification information and a cryptographic signature of the identifiable and verifiable software application; and

b. the recognizable and verifiable software application is installed at an installation computer.

9. The method of claim 8, wherein the installation computer sends identification information to the distribution computer prior to the step of receiving the identifiable and verifiable software application from the distribution computer.

10. The method of claim 8 or 9, wherein the installation computer verifies the integrity of the software application prior to the step of installing the identifiable and verifiable software application.

11. The method of claim 10, wherein the installation computer verifies the integrity of the software application using the cryptographic signature.

12. A method of electronically distributing a software application from a distribution computer to an installation computer, comprising the steps of:

a. receiving identification information at the distribution computer;

b. embedding said identifying information into said software application at said distribution computer to form an identifiable software application;

c. generating a cryptographic signature for the identifiable software application;

d. embedding the cryptographic signature into the identifiable software application to form an identifiable and verifiable software application;

e. transmitting said identifiable and verifiable software application from said distribution computer to said installation computer; and

f. installing the identifiable and verified software application at the installation computer.

13. The method of claim 12, wherein the distributing computer and the installing computer are distributed via an internet connection.

14. The method of claim 12 or 13, wherein the identification information received at the distribution computer is transmitted from the installation computer.

15. A software distribution computer for distributing a recognizable and verifiable software application to a user, comprising:

a. a communication link between the software distribution computer and the user;

b. a storage component for storing the software application for distribution;

c. a communication interface in communication with said link for receiving identification data of said user and for transmitting said identifiable and verifiable software application to said user;

d. means for embedding data received from the installation computer into the software application to form a recognizable software application;

e. means for generating a cryptographic signature for the identifiable software application; and

f. for embedding the cryptographic signature into the identifiable software application to form the identifiable and verifiable software application.

16. A software installation computer for receiving identifiable and verifiable software applications distributed by a distribution computer:

a. a communication link between the software installation computer and the software distribution computer;

b. a storage component for storing identification data and for storing installed software applications;

c. a computer communication interface in communication with said link for transmitting said identification data and for receiving said recognizable and verifiable software application having embedded therein the identification data and a cryptographic signature of the recognizable and verifiable software application;

d. means for installing the identifiable and verifiable software application on the computer storage component.

17. A software distribution computer for distributing identifiable and verifiable software applications from a distribution computer to an installation computer, comprising:

a distribution computer;

a mounting computer;

a communications link between the installation computer and the distribution computer;

the distribution computer includes:

a. a distribution computer storage component for storing software applications for distribution;

b. a distribution computer communication interface in communication with said link for communicating an identifiable and verifiable software application to said installation computer and for receiving identification data from said installation computer;

c. means for embedding the identification data received from the installation computer into the software application to form an identifiable software application;

d. means for generating a cryptographic signature for the identifiable software application; and

e. means for embedding the cryptographic signature into the recognizable software application to form a recognizable and verifiable software application;

the installing computer includes:

a. an installation computer storage means for storing the identification data and for storing the installed software application;

b. an installation computer communication interface in communication with said link for transmitting said identification data to said distribution computer and for receiving said identifiable and verifiable software application from said distribution computer; and

d. means for installing the software application in the installation computer storage component.