Patent Application
20190044709
The problem of software piracy is well known in the computer industry. This problem results in substantial losses for software developers. Many methods have been used to try to prevent unauthorized use of over the years, with limited success. Typically, the effort put out to break protection schemes is proportional to the value of the protected software. Thus, if a software program has high demand, such as a computer game, or has a high cost per unit, such as a professional tool sold to a small market, it is likely to be attacked by software hackers for the purpose of creating an unprotected version of the product. This unprotected version is then made available to others at low cost or free via the internet or other means.
One licensing scheme for software is to have a customer purchase a year (or other time period) worth of updates. For example, if a customer pays today, the customer is allowed to run the current version of the software and any version of the same software released in the next year. The customer will be able to run perpetually any version released within the year that the customer paid for. Any software released after that paid year will not run for the customer, unless the customer purchases another year, and so on.
One way in which this is implemented is by incorporating release or software date information, into the software itself. During runtime, an authorization tool in the software determines whether the software date within the licensing period. If the software date does not fall within the licensing period, then the software will not function.
The problem with licensing this way is that hackers can easily tamper with the software date of a version of software. Even if the software date is encrypted, the encrypted software date of one version of the software could be hacked into another copy of the software.
Accordingly, what is needed to prevent hackers from tampering with the software date in order to unlock versions of the software that are not supposed to run.
The exemplary embodiment provides methods and systems for incorporating software date information into a key exchange protocol to reduce software tampering. Aspects of the exemplary embodiment may include during a software application protection phase, using a license key assigned to the software application and the software date of the software application to generate a first encryption key and a second encryption key; using the first encryption key to encrypt the software application, and bundling the second encryption key with the software application; storing the license associated with the software application, including the license key, in a security domain to protect the licensing key from discovery; when the software application is invoked on the computer, passing a license ID and the software date from the software application to the security domain; responsive to both the security domain containing the license identified by the license ID, and the software date being within a licensing date range of the license, using the license key stored in the security domain and the software date to generate the first encryption key and the second encryption key; encrypting first encryption key with the second encryption key to create a protected first encryption key, and passing the protected first encryption key to the computer; and using the second encryption key bundled with the protected software application to decrypt the protected first encryption key resulting in a decrypted first encryption key, and using the first encryption key to decrypt the protected software application for execution.
According to the method and system disclosed herein, the exemplary embodiment prevents tampering with the software date as doing so will negatively affect the key exchange with the security domain and the software application will be unable to run.
The exemplary embodiment relates to incorporating software date information into a key exchange protocol to reduce software tampering. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the exemplary embodiments and the generic principles and features described herein will be readily apparent. The exemplary embodiments are mainly described in terms of particular methods and systems provided in particular implementations. However, the methods and systems will operate effectively in other implementations. Phrases such as “exemplary embodiment”, “one embodiment” and “another embodiment” may refer to the same or different embodiments. The embodiments will be described with respect to systems and/or devices having certain components. However, the systems and/or devices may include more or less components than those shown, and variations in the arrangement and type of the components may be made without departing from the scope of the invention. The exemplary embodiments will also be described in the context of particular methods having certain steps. However, the method and system operate effectively for other methods having different and/or additional steps and steps in different orders that are not inconsistent with the exemplary embodiments. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
As used herein, the term “software date” refers to the release date of the software, which is typically set by the software publisher. The software date is typically a single date, but may be expressed as a date range or a length of time a software license is valid. As stated above, the software date is often embedded in a software application so that functionality of the software can be disabled once the licensing period is over. The problem with embedding the software date into a software application is that hackers can change this information. Even if the software date is encrypted, the encrypted software date from one release of a software application can be substituted with the encrypted software date of another release of a software application, therefore illegally extending use of the software.
This exemplary embodiments reduce or prevent tampering of the software date associated with a software license by incorporating the software date into a key exchange with a security domain. If the software date is tampered with, then the key exchange results in the wrong key exchange key. Without the correct key exchange key, the software application will fail its check of the license, and the software application will no longer continue to run.
According to the exemplary embodiments, the software date 12 associated with the software application license is incorporated into the key exchange 23 by modifying the cryptographic keys with the software date.
In further detail, and according one aspect of the exemplary embodiment, a license key 10 and the software date 12 are used key to create first and second keys, which are referred to herein as a communication key 16 and a security key 18. The security key 18 is used by a security software tool 19 to encrypt the software application 14 prior to sale to create a protected software application 20. The license key 10 is then stored in the security domain 22 to keep the license key 10 hidden from discovery. The communication key 16 is bundled with the protected software application 20, and is used to implement the key exchange 23 between the protected software application 20 and the security domain 22. The security key 18 is not bundled with the protected software application 20, but is instead generated within the secure environment of the security domain 22 and passed to the protected software application 20 during the key exchange 23 to unlock the software.
When the protected software is invoked on the computer, the protected software application 20 passes the software date 12 information to the security domain 22. Once the software date 12 is verified, as described below, the security domain 22 uses the license key 10 and the software date 12 to generate the communication key 16 and the security key 18 within the security domain 22. The security domain 22 then encrypts 26 the security key 18 with the communication key 16 and transfers the resulting encrypted security key 28 to the computer. The communication key 16 bundled with the protected software application 20 is used to decrypt 30 the encrypted security key 28. The resulting decrypted security key 32 is then used to decrypt 34 the encrypted software code 36. The resulting decrypted software code 38 may then be executed 40.
According to the present invention, the protected software application 20 only contains part of the information needed for decrypting the protected software application (e.g., the software date 12 and the communication key 16), and must receive the remaining information (e.g., the encrypted security key 28) from the security domain 22 before the software can be used. Similarly, the security domain 22 cannot generate the security key 18 without receiving the correct software date 12 information from the protected software application 20. In addition, since the software date 12 is used to modify the communication key 16 and the security key 18, any attempt to substitute or modify the software date 12 or modify the two keys, will cause a failed key exchange 23 and the software will not run.
For additional security, the security domain 22 scrambles or encrypts the security key 18 prior to transferring it to the protected software application 20, thus providing a secure key exchange transaction between the security domain 22 and the protected software application 20. In a further aspect of exemplary embodiment, the protected software application 20 may be required to contain additional information to descramble the encrypted security key 28 before the security key can be used to decrypt the encrypted 36 software code. The additional information may be temporary, and may be forgotten once the protected software application is enabled. Thus, for each invocation of the protected software, the appropriate secure transaction must take place successfully.
The memory system 206 of computer 202 may include an operating system 214, I/O routines 216, and a protected software application 20. The I/O routines 216 are required for communicating over the I/O ports 212. The I/O routines 216 may be part of the operating system 214, or may be loaded as part of the protected software application 20 in some cases. The protected software application 20 is protected through encryption to thwart unauthorized use according to the exemplary embodiments, and may be loaded and installed over a network from a software publisher or online store, for example, or loaded from storage devices 210.
The protected software application 20 is executed by processor 204 at runtime and run according to the exemplary embodiments described below. According to the exemplary embodiments, the protected software application 24 is bundled with license check code 218, a license ID 220, the communication key 16 and the software date 12.
The license check code 218 performs cryptographic checks of the license 222 during runtime on a computer. In one embodiment, the license check code 218 may be injected in once in the protected software application 20. In another embodiment, the license check code 218 may be injected in many places throughout the protected software application 20 so that the cryptographic checks of the license cannot be easily removed. The license check code 218 establishes communications with the security domain 22 and uses the license ID 220, the communication key 16 and the software date 12 and implements the key exchange 23 with the security domain 22.
The license ID 220 and the software date 12 are associated with a license 222 for the protected software application 20. The license ID 220 may be any type of identifier used to identify the license 222. The software date 12 may represent any information about the license term associated with the protected software application 20. For example, in one embodiment, the software date 12 may include a start date (the date the license term begins) and an end date (the date the license term ends). In another embodiment, the software date 12 may include a start date and a length of time the license is valid e.g., 1 yr. or 24 mo., and the like)
In one embodiment, the security domain 22 communicates with the computer 202 on which the protected software application 20 is installed to aid in protecting the protected software application 20 from tampering and to provide secure execution. In one embodiment, the security domain 22 may store or access information regarding the license 222 associated with the protected software application 20, including the license ID 220′, the license key 10, and a license date range 224, where the license date range 224 defines a licensing period for the software application. In one embodiment, the license key 10 may also function as a product key for the protected software application 20. Each software product from a publisher would typically have different license keys because the license key would be different for each software product. Each version of a software product would also have different license keys because the software date 12 is different for each version.
In one embodiment, the security domain 22 may be implemented as a portable external security device 22a that plugs into the computer 202 on which the protected software application 20 is to be run; a white box 14b in the memory system 206; or an external security server 14c.
The security device 22a embodiment may be implemented as a dongle, which is a small form-factor hardware device that connects to the computer 202 via USB, and may include components (not shown) such as a processor, a memory, input/output circuitry, and I/O port. Typically, the processor may comprise a security processor containing necessary circuitry to enable data to be stored in the memory in encrypted form and thus not usable except by the processor itself. The memory is used to store security information, such as encryption keys and authentication information. Other facilities of the processor enable it to establish a secure communications path with the processor 204 on the host computer 202. This technology is well known to those with ordinary skill in the art, and thus will not be described in detail herein. Alternate embodiments include the replacement of the processor with custom logic to perform the same function in hardware rather than software.
The white box 14b may refer to white-box cryptography, which implements a cryptographic algorithm in software that keeps cryptographic assets (e.g., a secret key) secure even when subject to attacks. Typically, the security relies on the confidentiality of the secret key and random data. In one embodiment, the white box 14b may run in the memory system 206 of the computer 202, or even a coprocessor (not shown) for additional security.
The security server 14c may refer to a Web server that guarantees secure transactions and may use the Secure Sockets Layer (SSL) protocol for data encryption and decryption to protect data from unauthorized interception.
The license check code 218 may communicate with the security domain 22 either with internal routines or via standard I/O routines 216 provided with the operating system 214. If the security domain 22 is implemented as the external security device 22a or the external security server 22c, then communication with the license check code 218 may occur through the I/O ports 212. If the security device 14 is implemented as the white box 22b, then communication with the license check code 218 may occur through software calls.
During the software application protection phase 300, the license key 10 assigned to the software application 14 and the software date 12 of the software application 14 are used to generate a first encryption key and a second encryption key (block 304). In one embodiment, the first encryption key may comprise the security key 18 and the second encryption key may comprise of the communication key 16. In one embodiment, the license key 10 may comprise values from various sources and may be at least 16 or 32 bytes in length (256 bits). In one embodiment, the security key 18 and the communication key 16 may be in the form of a number at least 16 bytes in length. This is 128 bit encryption, and is considered sufficiently difficult to break. In the future, both the license key 10 and the security key 18 and the communication key 16 may need to be larger, as computational power available for breaking encryption increases.
The first encryption key is used to encrypt the software application 14, and the second encryption key is bundled with the software application (block 306). This process creates the protected software application 20. The license 222 associated with the software application 14, including the license key 16, is stored in the security domain 22 to protect the license key 10 from discovery (block 308).
When the software application is invoked on the computer, the license ID 220 and the software date 12 from the software application are passed to the security domain (block 310).
Responsive to the security domain 22 containing the license 222 identified by the license ID 220, and the software date 12 being within the licensing date range 224 of the license, the license key 10 stored in the security domain 22 and the software date 12 are used to generate the first encryption key and the second encryption key, preferably within the security domain 22 (block 312).
The second encryption key is used to encrypt the first encryption key to create a protected first encryption key, which is then passed from the security domain 22 to the computer 202 (block 314).
The second encryption key bundled with the protected software application 20 is used to decrypt the protected first encryption key resulting in a decrypted first encryption key, and the decrypted first encryption is used to decrypt the protected software application 20 for execution (block 316).
The license key 10 is first used to generate an unmodified security key 402 and an unmodified communication key 406 for each portion of the software application to be protected [. The unmodified security key 402 may be calculated by performing a first nonreversible mathematical operation 400 on the license key 10. Once the unmodified security key 402 is derived, the unmodified communications key 406 may be calculated by performing a second nonreversible mathematical operation 404 on the unmodified security key 402.
According to the exemplary embodiment, the unmodified security key 402 is modified by the software date 12 through a mathematical operation 408 to generate the actual security key 18. Similarly, the unmodified communication key 406 is modified by the software date 12 to generate the actual communication key 16. The process just described will also be used within the security domain 22 to generate the security key 18 and the communication key 16 the during software authorization.
By generating the security key 18 and the communication key 16 from a non-reversible operation, it is difficult or impossible to determine the hidden license key 10. In the preferred embodiment, the nonreversible mathematical operation 404 may have a higher level of security than the non-reversible mathematical operation 400, and therefore uses a more complex algorithm. This is because it is easiest to discover the communications key 16, since it is embedded within the protected software application 20. The security key 18 does not appear outside of the security device 22 except in a randomized, encrypted format, and temporarily in an unencrypted format during the decryption of the protected software 20. It is immediately discarded after use. Thus, the security key 18 is much more difficult to determine electronically. By making it impossible to compute the security key 18 from the communications key 16, this protective wall is maintained, and the protected software 20 remains protected.
The non-reversible mathematical operations 400 and 404 can be fairly simple to very complex. In the embodiment, where the security domain 22 is implemented as a security device 22a, a fairly limited processor may be available so a simpler algorithm may be preferred. In one embodiment, the non-reversible mathematical operations 400 and 404 could be a MD5 message digest algorithm. As semiconductor technology improves, and more memory and processing power becomes available in low-cost and low-power security processors, the algorithms can be more and more complex. Of course as algorithms become more complex, they also become more secure. Thus, the most complex algorithm practical within the limitations of the available technology is selected for a given implementation.
Referring still to
In order to adequately maintain secrecy, it is important that the communications key 16 be embedded into the protected software application 20 in an obscure manner. One embodiment includes reading hardware values from registers inaccessible from the computer's system bus as part of the data to compute the communications key 16. There are many additional methods for obscuring the communications key 16 which are known to one of ordinary skill in the art, and thus will not be described herein.
After the protection phase, the protected software application 20 is ready for distribution and sale. In the embodiment where the security domain 22 is implemented as the security device 22a or the external security server 22c, the security domain 22 may be made available for sale, either as part of the software, or as a separate purchase. In one embodiment, the security domain 22 may contain multiple licenses 222 for multiple software applications.
Similar to the protection phase, the license key 10 is then used to generate the unmodified security key 402 and the unmodified communication key 406 (step 508). The security domain 22 modifies, as in the protection phase, the unmodified security key 402 and/or the unmodified communication key 406 using the software date 12 to derive copies of the actual security 18′ and actual communications key 16′ (steps 510 and 512).
The security domain 22 may alter the security key 18 in an reversible way, such as performing an exclusive-OR operation (XOR) of the security key 18 with the random number 500, to obtain an XORed security key 516 (step 514). The present invention uses the random number 500 to provide another level of security in hiding the security key 18 generated by the security domain 22. The security domain 22 then encrypts the XORed security key 516 with the communication key 16′ to create an encrypted XORed security key 520 (block 518). Finally, the security domain 22 sends a response containing the encrypted XORed security key 520 back to license check code 218 (block 522). Because the security key 18 is randomized using the random number 500, the response is different each time, and thus the security domain 22 cannot be replaced by a simple circuit that generates the same response each time.
Once the encrypted XORed security key 520 is received by the license check code 218, the license check code 218 decrypts the encrypted XORed security key 520 using the communication key 16 embedded in the protected software application 20 to obtain the XORed security key 516 (step 524). License check code 218 reverses the effects of the random number by performing an exclusive-OR operation (XOR) of the XORed security key 516 with the random number 500 to obtain a copy of the security key 18 (step 526). The security key 18 is then used to decrypt the protected software code 36 (step 528) to allow the decrypted software code 38 to execute correctly (step 530). In an alternative embodiment, the security key 18 could be used instead in computations critical to running the decrypted software code 38.
According to the exemplary embodiments, the security key 18 is never stored with the protected software application 20. Rather security key 18 is generated dynamically from the security domain response, used (in step 528) and discarded. Thus, the security key 18 is not available for discovery by memory dumps or expansion bus transaction analyzers.
And because the security key 18 is modified by the software date 12, any attempt by hackers to modify the software date 12 will result in a failed key exchange, and the software application will not run. Thus, the exemplary embodiments prevent tampering of the software date, or licensing period, associated with a software license.
A method and system for incorporating software date into a key exchange protocol has been disclosed. The present invention has been described in accordance with the embodiments shown, and there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. For example, the exemplary embodiment can be implemented using hardware, software, a computer readable medium containing program instructions, or a combination thereof. Software written according to the present invention is to be either stored in some form of computer-readable medium such as a memory, a hard disk, or a CD/DVD-ROM and is to be executed by a processor. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
