METHOD OF USING SYSTEM SPECIFIC DATA TO UNLOCK FILES THAT
SHARE A COMMON KEY
FIELD OF THE INVENTION
This invention relates to the field of information storage and delivery and, more specifically, to controlling file access on a client system.
BACKGROUND
Information may be distributed to users through various ways. Information contained in files that are located on a client system or a server system may be distributed via the Internet to a user operating another client system. The amount of information a user can receive via the Internet is limited by the bandwidth of their connection to the Internet, which for many users is typically 56 kilobits per second or less. However, using the Internet to transmit information may make such information susceptible to interception by unintended users. As such, files containing the information may be encrypted before distribution in order to prevent unauthorized access to the information. An authorized user is provided with a key with which to access the information contained in the encrypted files. The size of the encrypted files, however, may be large, thereby making Internet downloading of such files impractical with smaller bandwidth connections.
Another way to distribute files to an end user is to store the files on a portable storage medium and then delivering the medium to the user. CDs (compact disks) and DVDs (digital versatile disks) are types of portable storage mediums that allow for the storage of large files that may be quickly retrieved. These storage mediums may also be easily mass produced for distribution to many end users. Copies of the storage mediums are generated using a master storage medium containing the original files. To prevent unauthorized access, the files stored on these devices may also be encrypted.
One method of encrypting files uses a common encryption key for each copy of the file that is produced for distribution to users. One problem with
having multiple copies sharing a common encryption key is that if a malicious user discovers the encryption key, it may be used to unlock any other user's copy of the same file. If this encrypted data is for sale, a massive amount of potential sales revenue may be lost.
Another method of encrypting files is to increase the number of masters produced, using a different encryption key for each. However, in order to provide sufficient protection against the discovery of an encryption key, the number of different keys may number well into the thousands, thereby making manufacturing infeasible.
Yet another method of encrypting files is to provide each user with a copy specific key that may be combined with the common key. In this manner, a high portion of the information in a file may be mass produced on a portable storage medium and distributed to end users, while keeping the remaining portions of the file on a server system. An end user obtains the missing portions by connecting to the server system via the Internet and providing the server system with the combined key. Once the combined key is verified, the missing file information is downloaded to the client's system.
One problem with such a method is that proprietary software may be needed to "glue" all the information together in the correct manner. Such glue software may undesirably add to the complexity and the cost of implementing such a method. SUMMARY OF THE INVENTION
The present invention pertains to a method of conducting a transaction. The method may include registering information about a client system from among a plurality of client systems. The information is registered on a server system and may include a characteristic specific to the client system. The method may also include purchasing access to the file by the client system from the server system with the file being stored at the client system. The method may further include enabling the file to be accessed only by the client system
purchasing access. Hie file access is enabled based on the characteristic specific to the client system.
Additional features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
Figure 1 illustrates one embodiment of a client-server network.
Figure 2 illustrates one embodiment of a transaction between a client system and a server system.
Figure 3 illustrates one embodiment of interaction between a client system and a server system.
Figure 4 illustrates one embodiment of a client system.
Figure 5 illustrates one embodiment of an encryption method.
Figure 6 is a flow chart illustrating another embodiment of interaction between a client system and a server system.
DETAILED DESCRIPTION
In the following description, numerous specific details are set forth such as examples of specific characteristics, algorithms, and components, etc. in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that these specific details need not be employed to practice the present invention. In other instances, well known components or methods have not been described in detail in order to avoid unnecessarily obscuring the present invention.
The method described herein may be used to conduct a transaction between a client system and a server system. In one embodiment, the method may include registering information about a particular client system from among multiple client systems. The information is registered on a server system
and may include a characteristic specific to the client system being registered. The method may also include purchasing access to the file by the client system from the server system and enabling the file to be accessed only by the client system purchasing access to the file. The access of the file may be enabled based on the characteristic specific to the client system.
Portable storage medium, such as DVD, represents a much higher bandwidth conduit for information delivery than the Internet connections of most computer users. Thus, bandwidth intensive information, such as full- spectrum audio, video, or other media-rich content, that may otherwise be noticeably impacted by delivery over an Internet connection, may instead be delivered using a portable storage medium. The information is stored in files on the portable storage medium. In one embodiment, the information contained in the files may be encrypted to prevent unauthorized users from accessing the information. The files may be reproduced on one or more of the storage medium and then distributed to end users. An end user may then install the storage medium on their client system. The files located locally at the client system may be accessed in response to activation through interaction with a server system.
In one embodiment, access to information stored at a client system is controlled by packing the individual data objects comprised by the information into a specialized file, called a packed file. A packed file may include access control information, such as file size or last modified time. A dedicated file system device driver may also be provided to interact with the packed file. Because the packed file and the file system driver effectively constitute an additional file system layer that resides below the existing file system structure maintained by a client's operating system and standard file system driver, the packed file and file system driver are referred to herein as a "virtual file system" (VFS) and the file system driver as the "virtual file system driver" (VFSD).
Figure 1 illustrates one embodiment of a client-server network. A user initially installs a portable storage medium 10, for example a DVD, in an
appropriate media reader 11 of his or her client system 18 as indicated by arrow 17. In an alternative embodiment, another type of portable storage medium may be used, for example, a CD. In yet another embodiment, a non-portable type of storage medium may be used, for example, a hard disk drive of client j.ystem 18.
As discussed below, the portable storage medium 10 may include an installation program that is automatically loaded into the system memory of the client system 18 and executed by a client processor 13 within the client system 18 to install the virtual file system driver 27 into the user's client system 18. The user may then connect to server system 12 through network 21 and conduct a transaction in order to gain access to some of the information contained on storage medium 10. For example, if storage medium 10 contains an encrypted file that the user desires to obtain access to, the user must connect client system 18 to server system 12 to obtain a key in order to decrypt the desired file. The connection of a client system to a server system via a network is well known in the art; accordingly, a more detail discussion is not provided.
In one embodiment, identification (ID) data about client system 18 is determined and transmitted to server system 12 to obtain a common key that provides access to the desired file. The identification (ID) data contains characteristic information specific to the particular client system 18 requesting access to a desired file. The ID data may be encrypted with a client key in order to prevent unauthorized use of the ID data to access files stored on storage medium 10.
The client key is a private key that is specific to storage medium 10 and is known by the VSFD of client system 18 and server system 18. In one embodiment, client system 18 need not be aware of the client key. At the time of registration, the VFSD of client system 18 transmits an encrypted ID data string to server system 12. In one embodiment, the encrypted ID data string may be stored on server system 21 in a database along with other user specific information.
At the time when the user desires access to an encrypted file, server system 12 retrieves the user's encrypted ID data string from the database and uses it to encrypt a common key that will allow the user of client system 18 to access a desirad file. In one embodiment, the common key may be the same key that is provided to all client systems (i.e., client system 18 and client systems 19) and known by server system 12. The result of the encryption is transmitted from server system 12 to client system 18, where the VFS stores it locally. The encrypted common key may be stored on storage medium 10 or on other storage devices of client system 18.
Each time the user of client system 18 seeks access to the desired file a read request is sent to the VFS. In one embodiment, when the first read request for the desired file is sent to the VFS, the VFS will regenerate a client system specific encrypted ID data string using the same client key as before. The VFS will then decrypt the encrypted common key data string received from server system 12 using the regenerated client system specific encrypted ID data string. If the regenerated client system specific encrypted ID data string does not match the originally generated client system specific encrypted ID data string, then the desired file may not be accessed.
In an alternative embodiment, if the regenerated client system specific encrypted ID data string does not match the originally generated client system specific encrypted ID data string, the desired file may be accessed but the contents of the file appear as random data that is substantially unusable by the client. As such, copying the originally generated client system specific encrypted ID data string to any of the other client systems 19 may be useless because the ID data string is unique to a particular client system.
Figure 2 illustrates one embodiment of a transaction between a client system and a server system. In one embodiment, a user is first required to register his client system with a server system before gaining access to a desired file on storage medium 10, step 210. A program from storage medium 10 may be executed that determines the identity of client system 18 based on a system
specific characteristic. The client system connects with server system 12 to notify server system 12 of the identity of client system 18. In one embodiment, the user may be provided with a client-specific key at the time of registration that may be used to gain access to a desired file. Ac the time of registration, the server system may store user information such as user name, password, and client key.
Subsequent to registration, the user may purchase access to a file located on storage medium 10 by providing an indication of such to server system 12, step 220. In one embodiment, the user may be required to provide some consideration (e.g., money or information) in return for access to the desired file. In an alternative embodiment, access to the desired file may be given to the user without requiring consideration. As such, the time of purchase refers to the time at which a user desires access to the file regardless of whether any consideration is provided.
At the time of purchase, the user may be required to login using the user information that was provided at the time of registration. The user may also be presented with a web page that identifies additional files available to the user. The user need not be informed of the additional items of content that are located on storage medium 10, or of all the items of content stored on the storage medium 10. Once the user is identified by server system 12, the user's client key may be accessible as part of the user information stored on server system 12.
By purchasing access to a file, the user receives a common key that may be used to gain access to the file. The common key may be downloaded to client system 18 over network 21. In another embodiment, the common key may be sent to the user by other means, for example, copied onto a storage medium that is delivered to the user.
The user gains access to the desired file using the common key, step 230. The common key provided to the user, in step 220, is in a format that is useable only with the previously registered client system 18. In one embodiment, the common key is encrypted with the identity of client system 18 that was registered in step 210. The identity of client system 18 is regenerated in step 230
and then compared with the identity generated at step 210. If the identity generated in step 210 matches the identity generated in step 230, then the user is allowed access to the desired file on storage medium 10.
Figure 3 illustrates one embodiment of interaction between a client system and a server system. Initially, a portable storage medium 310 is loaded into a media reader of a user's client system 318. As discussed above, an installation program resident on portable storage medium 310 may automatically execute to install an application program 335 and a VFSD 327. This is indicated in Figure 3 by arrow 319.
After the application program 335 and the VFSD 327 have been installed, application program 335 may be automatically launched as indicted by arrow 323. In one embodiment, application program 335 presents a display 325 informing the user that access to a file is available from a provider of the content on the portable storage medium 310. The application program 335 may also prompt the user to connect to server system 312 of the content provider (i.e., the provider of the information on the portable storage medium). Alternatively, the application program 335 may immediately connect to server system 312 through network 321. A system analysis program may also be executed at this time to analyze client system 318 to determine a system specific characteristic about client system 318, as discussed in further detail below. The system analysis program may be incorporated within the application program 335 or function as a separate application program.
By way of example, when application program 335 is launched, a web browser may be invoked on client system 318 with an appropriate address, for example a universal resource locator (URL) in the web browser's command line. The address specifies the web page for server system 312 of the provider of the content that the user desires access to. The user may be informed that access to the content is available to registered members and may be prompted to register. If the user activates the register button 326, the URL of a registration page is transmitted to server system 312 which, in turn, transmits a registration page 329
that is displayed on client system 318. This operation is indicated by arrows 327. In one embodiment, on registration page 329, the user may be prompted to enter one or more client specific characteristics. In an alternative embodiment, the user may be prompted to provide user specific characteristics such as a name or an electronic mail address. In yet another embodiment, the user specific characteristics may be generated by the server system 312 without user interaction.
After the user has registered, the user may then obtain access to desired content, page 330. In one embodiment, a client key may be generated when server system 312 receives registration information from client system 318. Server system 312 combines the client specific characteristic (or the user specific information) with a common key. The common key may be used to gain access to the desired content on portable storage medium 310. The common key is provided to the user in a format that is useable only with the previously registered client system 318. In one embodiment, the common key is encrypted, with the characteristic of client system 18 that was previously registered, on server system 312 and then transmitted to client system 318.
The characteristic of client system 318 is regenerated by the application program 335 and used to decrypt the encrypted common key. If the regenerated client specific characteristic matches the originally generated client specific characteristic, then the user is allowed access to the desired content. The application program 335 may access a desired file on portable storage medium 310 via file open and file read calls passed through a chain of software modules, including operating system (OS) 337, file system driver 339, and VFSD 327. The returned file may then be presented 341 to the user of client system 318.
Figure 4 illustrates one embodiment of a client system. A system analysis program may be contained on portable storage medium 410 or downloaded from server system 421 at the time of registration either onto portable storage medium 410 or directly onto client system 418. The system analysis program, operating from either client system 418 or portable storage medium 410,
analyzes client system 418 to determine a system specific characteristic about client system 418.
In one embodiment, for example, client system 418 may access network 21 of Figure 1 using an Ethernet device 430. The Ethernet protocol uses a 48-bit addressing scheme for each Ethernet device that is used to connect to a network (e.g., network 21 of Figure 1). Every Ethernet device is assigned a unique 48-bit Ethernet address by its manufacturer. Each manufacturer has been assigned a block of addresses that they may use for their products. These address blocks are administered and assigned by the Institute of Electrical and Electronics Engineers (IEEE). It is the manufacturers' responsibility to ensure that every device that leaves the factory has a unique address from that block.
As such, no two Ethernet devices on a network should have the same physical address. In this manner, client system 418 may be distinguished from other client systems (e.g., client systems 19 of Figure 1) by the Ethernet address of Ethernet device 430. In an alternative embodiment, other types of information particular to client system 418 may be used to differentiate it from other client systems, for examples, information stored on a hard disk drive 440. The information stored on hard disk drive 440 may include, for examples, serial number, drive size, creation date, directory file creation dates and registry entries.
This system specific characteristic is used to enable access to the desired file on portable storage medium 410 only by client system 418. This may prevent the desired encrypted file and key from being copied onto and used by other client systems, because these other client systems have different system characteristics.
Figure 5 illustrates one embodiment of an encryption method. A system specific characteristic of a client system is compiled into an identification data string 510. In one embodiment, data string 510 may be hashed into a unique 256-bit sequence as follows. The encryption application contained on the storage medium compresses data string 510 into a 160-bit checksum using the Secure
Hash algorithm (SHA). The 160-bit checksum may be augmented into a 256-bit identification (ID) data string by randomly generating three 32-bit numbers, using the first 96 bits of the checksum as seed values.
An encryption engine 520 may then be used to encrypt the resultant 256- bit ID data string into encrypted data string 530 with a client key stored on the storage medium. The client key may be specific to the particular storage medium that the client system is using and is known by the server system. In one embodiment, encryption engine 520 may use a block cipher algorithm, for example, Twofish to encrypt the ID data string. Twofish is a 128-bit block cipher that accepts a variable length key up to 256 bits. Twofish is available from Counterpane Internet Security, Inc., of San Jose, CA. Twofish is known in the art; accordingly, a more detailed discussion is not provided.
In an alternative embodiment, encryption engine 520 may use another encryption algorithm, for examples, Blowfish from Counterpane Internet Security, Inc., of San Jose, CA; Serpent from Lars Knudsen of the University of Bergen, Norway, and Data Encryption Software (DES) from American Software Engineering of Boise, ID.
Figure 6 is a flow chart illustrating another embodiment of interaction between a client system and a server system. In one embodiment, an application is executed to determine client data that contains specific characteristics of a client system, step 605. The application may be executed either on the client system or from a remote system. A first data string is generated on the client system using a client key and the client data, step 610. In one embodiment, the first data string may be generated by hashing the client data into a multiple bit sequence and encrypting the multiple bit sequence using the client key.
The first data string is transmitted from the client system, step 615, and received by a server system, step 620. In one embodiment, the server system may retrieve a stored client key that was stored on the server system during a previous connection between the client system and the server system. The server system decrypts the first data string, using the client key, to determine the
specific characteristic of the client system that transmitted the first data string, step 625.
The server system generates a second data string, containing the common key, using the specific characteristic of the client system, step 630. The second data string is transmitted from the server system, step 635 and received by the client system, step 640.
In one embodiment, the client system determines client data a second time, step 645, similar to that performed in step 605. By generating the client data a second time, rather than storing and using the first generated client data, tampering with the client data may be prevented. The second data string is decrypted, step 650, using the client data generated in step 645 to obtain the common key. If the client data generated in step 645 matches the client data generated in step 605, then the client system can successfully decrypt the second data string to obtain the common key. The common key may then be used to access a desired file stored on the client system, step 655. If the client data generated in step 645 does not match the client data generated in step 605, then the client system may not successfully decrypt the second data string to obtain the common key, step 670. Without the common key, the client system may not access the desired file stored on the client system to obtain the original unencrypted data, step 675.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.