Patent Application
20140215211
This invention pertains to software security, and more particularly to protecting software against unauthorized use.
Most software is licensed, rather than sold, by the company that developed the software. The license specifies what the customer can do with the software, and installation of the software implies the customer's acceptance of the software's license terms.
Installing software often involves using a code or key that limits the software's installation. When the customer attempts to install the software the customer is prompted for the code. The code is then transmitted back to the software company's servers, which validate the code and verify that the code has not been used before. Not all possible codes are valid, which prevents users from attempting to install in unauthorized copy of the program by trying random codes. If the code is valid and has not been used before, the company's servers record the use of the code, and the software is permitted to install. If the code is not valid, or if the code has been used before, the installation terminates.
But once the software is installed, nothing (other than perhaps a term in the license) prevents the installed software from being reverse engineered. A customer could attempt to recreate the source code for the software from the object code. With the source code in hand, the customer could then create their own version of the software.
Similarly, once the software is installed, nothing (other than perhaps a term in the license) prevents the user from copying the files and data that make up the software from one machine to another. This copying permits the software to run on the other machine, even though it might not have been properly installed on that machine, or authorized to run on that machine.
A need remains for a way to address these and other problems associated with the prior art.
In some embodiments of the invention, server-side software 115-1, 115-2, and 115-3 can be a complete copy of the software, and can be executed by a user when available. But in other embodiments of the invention, server-side software 115-1, 115-2, and 115-3 is not a complete copy of the software. In such embodiments of the invention, server-side software 115-1, 115-2, and 115-3 needs to be combined with the client-side software to form a complete version of the software that can be executed.
Database 110 can also store server-side keys 120-1, 120-2, and 120-3. In some embodiments of the invention, server-side keys 120-1, 120-2, and 120-3 can be keys, or serial numbers, that correspond to a client-side key (that is, a key, or serial number, that is part of the software installed on the client's machine). In other embodiments of the invention, the server-side keys 120-1, 120-2, and 120-3 can be unique to different applications available from security server 105, but shared by all clients using the software. In yet other embodiments of the invention, a single server-side key can be used with any number of software products, and for any number of authorized users of those software products.
As with server-side software 115-1, 115-2, and 115-3, database 110 can store any number of server-side keys. Also, server-side keys 120-1, 120-2, and 120-3 can be stored directly in database 110 or, as shown in
Security server 105 also includes receiver 125, transmitter 130, validator 135, and code generator 140. Receiver 125 can be used to receive information at security server 105. For example, receiver 125 can be used to receive requests for server-side software and server-side keys. Transmitter 130 can be used to transmit information from security server 105. For example, transmitter 130 can be used to transmit server-side software and server-side keys responsive to requests for such.
Validator 135 can be used to validate that requests for server-side software and server-side keys are coming from client machines that are authorized to use the software. For example, when a client machine requests its server-side software and server-side key (for example, server-side software 115-2 and server-side key 120-2), the client machine can include information about the client machine, such as its Internet Protocol (IP) address. Security server 105 can use validator 135 to validate that the client machine is, in fact, authorized to use the software before transmitting server-side software 115-2 and server-side key 120-2 to the client machine.
Code generator 140 can be used to generate the server-side software before it is transmitted to a client machine. For example, in some embodiments of the invention, database 110 stores a separate copy of the server-side software for each authorized client. But storing multiple copies of the server-side software can require a significant amount of space. Therefore, in other embodiments of the invention, database 110 can store the source code (or code in some other form) that can be used to generate the server-side software before transmission to the client machine. Code generator 140 can, for example, compile, encrypt, and obfuscate the server-side software. In this manner, database 110 only needs to store one copy of the server-side software, along with the server-side keys for the authorized users (since the server-side key can be included within the server-side software transmitted to the client machine).
Also connected to network 220 is client machine 225. Client machine 225 represents a machine used by a user, on which the user wants to run the protected software. Client machine 225 can include commercial security mechanisms, to protect any data stored on client machine 225. Resident on the client machine is the client-side software. The client-side software is not a complete version of the software, but includes enough code to perform the necessary tasks before assembling the complete software for execution. The tasks in question are described below with reference to
In some embodiments of the invention, security servers 105, 205, 210, and 215 can be synchronized, so that each security server includes the same information, and any security server can be accessed to assemble the complete software. But in other embodiments of the invention, security servers 105, 205, 210, and 215 are not necessarily synchronized. That is, security server 105 might have data not found on security servers 205, 210, and 215, security server 205 might have data not found on security servers 105, 210, and 215, etc.
In some embodiments of the invention, client machine 225 (more specifically, the client-side software installed on client machine 225) contacts only a security server that the client-side software knows stores the server-side software and server-side key. But in other embodiments of the invention, client machine 225 (again, more specifically, the client-side software installed on client machine 225) contacts every security server (for example, in serial or in parallel). This contact can occur even when the server-side software and server-side key are not available at every security server. Each security server can respond, either by transmitting the server-side software and server-side key or by transmitting decoy information. In this manner, security is enhanced, as an eavesdropper would not know which security servers actually store the server-side software and server-side key. (The client-side software installed on client machine can differentiate between the authentic and decoy security servers, in that only the authentic security server would have or use the correct server-side key.) Further, if an attacker were to attempt to request the server-side software from a security server that had transmitted decoy information (a fact the attacker should not be able to determine), this request would reveal that an attacker was attempting to assemble the complete software without authorization.
In some embodiments of the invention, in the event that an attack is suspected (for example, as described above, where a request for the server-side software is made from a security server that does not include the server-side software, or where the request for the server-side software comes from a client machine that is not authorized), the system can respond by changing the server-side keys that correspond to the client-side keys of the affected user. In this manner, further attempts by the attacker to establish the combined software will fail, as the client-side key the attacker has access to (albeit indirectly) will not be valid, causing the client-side software to self-destruct. And while this response to an attack can invalidate a legitimate client-side key (namely, the client-side key of the user who was compromised), that user can be issued a new valid client-side key (e.g., the authorized user can be provided with a new client-side software), permitting the authorized user to continue to use the software while denying the attacker the ability to use the software. In other embodiments of the invention, of course, the change to the server-side key can be done without affecting the client-side key, minimizing the inconvenience to the client.
While client machine 225 is part of the physical hardware that links the client-side software with the server-side software on one or more of security servers 105, 205, 210, and 215, client machine 225 should have no information about how to contact security servers 105, 205, 210, and 215. That is, the information about how to contact security servers 105, 205, 210, and 215 is part of the client-side software, and should not be known by client machine 225. In addition, the information used to contact security servers 105, 205, 210, and 215 (such as the protocols used to list and access security servers 105, 205, 210, and 215) can be part of the client-side software. As such, the contact information can be compiled, encrypted, and obfuscated into the client-side software, to make it more difficult (if not impossible) for an attacker to determine this information by analysis of the client-side software. In such embodiments of the invention, because the protocols to list and access security servers 105, 205, 210, and 215 can be part of the compiled, encrypted, and obfuscated client-side software, client machine 220 would not have a file (encrypted or not) that identifies how to contact security servers 105, 205, 210, and 215, thereby avoiding one possible attack.
At block 420, the client-side software determines if the machine running the client-side software is authorized. If the machine running the client-side software is not authorized, then at block 425 the client-side software self-destructs. In some embodiments of the invention, self-destruction can include aborting the initialization of the client-side software. In other embodiments of the invention, self-destruction can also include deleting the client-side software from the machine. By deleting the client-side software from the machine, the client-side software cannot be executed again. This step can be useful in the situation where the client-side software has been copied onto a machine that is not authorized to execute the client-side software (for example, someone has hacked onto the client-side machine and copied its contents).
If the client-side software determines that the machine running the client-side software is authorized, then at block 430 (
As described in U.S. Provisional Patent Application Ser. No. 61/757,024, filed Jan. 25, 2013, the client-side software can self-destruct if the client-side software is unable to contact the security servers. While not shown explicitly in
If the server-side software (and server-side key) was received, then at block 450 the client-side software attempts to validate the server-side key. This can be done in any desired manner. For example, the client-side software can verify whether the server-side key matches the client-side key (which can be determined by the client-side software) according to some algorithm.
At block 455 (
As discussed above, in block 430 of
In a further variation, after validating the server-side key, the client-side software can request the server-side software from all security servers, or just from one or more security servers that store the server-side software. But by requesting the server-side software from all security servers—even those that send decoy information—the software is protected, since an attacker would not have any information as to which security servers store the server-side software and which are decoys.
If the client machine was not validated, then at block 520 the security-side key can be changed (since it appears an attacker has an unauthorized copy of the client-side software), and at block 525 the security server transmits decoy information to the client machine. Otherwise, at block 530 (
In the flowcharts of
While the above discussion suggests that the software is divided into two parts—the client-side software and the server-side software—a person skilled in the art will recognize that the software can be divided into any number of parts. For example, the software can be divided into three parts: one part on the client machine (the client-side server) and two parts on security servers (two different server-side software elements). Combining all the parts of the software results in the usable version of the software.
When the software is split into more than two pieces, the server-side keys held by each security server including a portion of the software can be the same or different. That is, in some embodiments of the invention each security server that stores a portion of the software includes the same server-side key. But in other embodiments of the invention, each security server that stores a portion of the software can include a different server-side key. Provided that the client-side software can validate each server-side key, using more than one server-side key introduces no complications.
The above discussion focuses on software as the content being protected by embodiments of the invention. But a person skilled in the art will recognize that any content can be protected in the described manner, without being limited to software. For purposes of this application, the term “software” is defined to include any content, and not just code that can be executed by a computer processor. Where the content is not code that can be executed by a computer processor, the content can be protected by being just encrypted and obfuscated, without being compiled (which is a term that generally applies only to computer-executable code), and the phrase “compiled, encrypted, and obfuscated” can be understood as just “encrypted and obfuscated”.
In embodiments of the invention where the content being protected is not software, the client machine can include software that can implement the algorithms described above, to assemble the complete content for presentation to the user. Thus, while the content might not be software that can be executed by a computer processor, the user can still review the content in any desired and appropriate manner.
The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention may be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
The machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciated that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optical, infrared, cable, laser, etc.
The invention may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles. And, though the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “in one embodiment” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.
Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/757,024, titled “SPLIT DATA EXCHANGE PROTOCOL”, filed Jan. 25, 2013, incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61757024 | Jan 2013 | US |
