US20070174631A1 - System and Method for Controlling Usage of Software on Computing Devices - Google Patents
System and Method for Controlling Usage of Software on Computing Devices Download PDFInfo
- Publication number
- US20070174631A1 US20070174631A1 US11/670,619 US67061907A US2007174631A1 US 20070174631 A1 US20070174631 A1 US 20070174631A1 US 67061907 A US67061907 A US 67061907A US 2007174631 A1 US2007174631 A1 US 2007174631A1
- Authority
- US
- United States
- Prior art keywords
- string
- software
- key
- authorization key
- authorization
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
Definitions
- the present invention relates to a method and system for controlling usage of software on a computing device.
- An authorization key is generated as a function of a device string and a software string.
- the device string is a unique string stored in the device.
- the software string is a unique string stored in a software authorized for use on the device.
- the authorization key is encrypted using a private key and stored in the device.
- the authorization key is decrypted using a public key corresponding to the private key.
- a test key is generated as a function of the device string and a request software string.
- the request software string is a unique string stored in the software for which use has been requested.
- the authorization key is compared to the test key. When the test key matches the authorization key, usage of the software for which use has been requested on the device is permitted.
- FIG. 1 shows an exemplary system according to the present invention for controlling usage of a software
- FIG. 2 shows an exemplary system according to the present invention for creating and storing a software authorization key
- FIG. 3 shows a an exemplary system according to the present invention for verifying whether the software can be executed on a particular computing device
- FIG. 4 shows an exemplary embodiment of a method for creating and storing a software authorization key according to the present invention.
- FIG. 5 shows an exemplary embodiment of a method for verifying whether the software can be executed on a particular computing device according to the present invention.
- FIG. 1 shows an exemplary system for controlling usage of software on computing devices where the use of a software 4 is allowed only particular platforms 2 a and 2 d.
- the platforms 2 a - 2 d may be any computing devices (e.g., PCs, handheld devices, PDAs, etc.) which may operate on one of a plurality of operating systems, (e.g., Windows, Unix, Apple OS, etc.).
- the software 4 may be any program/code (e.g., office suite, image recognition software, etc.) which a hardware/software manufacturer desires to restrict the use thereof.
- the restriction of software 4 to particular platforms 2 a and 2 d may be accomplished by creating and storing the authorization keys 14 a and 14 d for the software in the registries 16 a and 16 d of the corresponding platforms.
- Each of the registries 16 a - 16 d is a digital storage area of a computing device (e.g., ROM, hard drive, etc.) that may contain information about the particular platforms 2 a - 2 d (e.g., build date, manufacturer, etc.).
- the authorization keys 14 a and 14 d may be created using the first string 6 a and 6 d stored in the platforms 2 a and 2 d respectively, in conjunction with the second string 10 stored in the software 4 as shown in FIGS. 2 and 4 , so that only platforms 2 a and 2 d may utilize the software 4 .
- the first strings 6 a and 6 d and the second string 10 are unique and specific to the platforms 2 a and 2 d and the software 4 respectively.
- the first strings 6 a - 6 d may be created and stored by the manufacturer in the platforms 2 a - 2 d during the production process.
- the second string 10 may likewise be created and stored in the software 4 .
- the platform string 6 may be formed by combining sub-strings present on the platform 2 , such as a combination of an original equipment manufacturer (“OEM”) string and a product-name string.
- the first strings 6 a and 6 d and the second string 10 may not be modified by the subsequent user after the manufacturing process.
- the unique nature of the first strings 6 a and 6 d and the second string 10 and the lack of available modification means makes them suited for identification and authorization purposes of the platforms 2 a and 2 d and the software 4 .
- the platforms 2 a and 2 d are allowed to run the software 4 because they are the only ones that have the proper authorization keys 14 a and 14 d.
- the authorization keys 14 a and 14 d are created using the second string 10 and the first string 6 a and 6 d stored in the platforms 2 a and 2 d respectively. Since the platforms 2 a and 2 d are used in creating the authorization keys 14 a and 14 d these are the only platforms capable of running the software 4 . Conversely, the platforms 2 b and 2 c lack the required authorization keys. Therefore, these platforms 2 b and 2 c are not able to utilize the software 4 .
- FIG. 2 shows the generation of the authorization key 14 using the first string 6 and the second string 10 stored in the platform 2 and the software 4 , respectively.
- the first string 6 and the second string 10 are specific and unique to their locations (i.e., the platform 2 and the software 4 ).
- FIG. 4 shows a method for creating the authorization key 14 which may be subsequently used by the platform 2 to determine if it is allowed to utilize the software 4 .
- the first string 6 and the second string 10 are utilized to generate a third string 8 .
- the third string 8 may be formed by combining or concatenating the first string 6 and the second string 10 . This step is important to the creation of the unique authorization key 14 . Since the first string 6 is unique to the platform 2 and the second string is unique to the software 4 , the resulting third string 8 is specific only to a combination of the platform 2 and the software 4 that are used in creating the third string 8 .
- the third string 8 may be hashed in order to form a first encryption key 12 .
- a conventional hashing algorithm may be used to produce a hash value of the third string 8 .
- a person skilled in the art will understand that any one of a plurality of hashing algorithms (e.g., MD2, MD4, MD5, and SHA-1, etc.) may be used for such purpose.
- a hashing algorithm is part of a hashing function which transforms a set of data (i.e., the third string 8 ) into another form that is more suitable for computing processes (i.e., the encryption key 12 ).
- Hashing of the third string 8 may also provide another level of security because the hashed data cannot be utilized unless it can be hashed in reverse to obtain the original data (i.e., the third string 8 ).
- the resulting first encryption key 12 is encrypted to form an authorization key 14 using one of a plurality of encryption schemes.
- the first encryption key 12 may be encrypted using the private key of a private/public key pair.
- the private/public key pair algorithm is similar to a conventional PGP system where the private key is used to encrypt messages (e.g., email) and a public key is used to decrypt the previously encrypted messages.
- the PGP system may operate in the following manner: a creator of the message possesses one half of the private/public key pair, which is used to encrypt messages and the other half is distributed to parties who need to decrypt the messages sent to them by the creator.
- the private/public key pair may be used in a substantially similar manner as that in the PGP system: the encryption key 12 is exported to a binary large object (“blob”) where it is encrypted using the private key.
- the blob is a generic sequence of bits that contain one or more fixed-length header structures plus context specific data. This blob may be then stored in the registry 16 as the authorization key 14 .
- the authorization key 14 is stored in a registry 16 of the platform 2 .
- the authorization key 14 may be in the form of the blob which can be exported to a file and copied to any number of computing devices of the platform 2 .
- all the computing devices of the platform 2 could be capable of operating software 4 which greatly reduces the difficulties of mass-producing the authorization key 14 .
- FIG. 3 shows a system for authorizing the software 4 to be utilized on the platform 2 .
- the platform 2 contains the registry 16 in which the authorization key 14 is stored after it was created using the method shown in FIG. 2 and 4 .
- the software 4 Prior to the operation of the software 4 on the platform 2 , the software 4 needs to determine if it is authorized to run on the platform 2 by using the authorization key 14 .
- FIG. 5 shows a method for determining if the software 4 is authorized to run on the platform 2 .
- the authorization key 14 is extracted from the registry 16 and the authorization key 14 is decrypted in order to obtain the first encryption key 12 .
- the decryption may be accomplished by using the public key of the same private/public key pair used in step 36 of FIG. 3 .
- This step is similar to the decryption process of the PGP system where the public key is used to decrypt a message encrypted with a private key. If the public key used to decrypt the authorization key 14 is from the same public/private key pair as the private key used to encrypt the first encryption key 12 , then the second encryption key 28 produced as a result of this decryption will be identical to the first encryption key 12 .
- the platform 2 and the software 4 create a second encryption key 28 from a fourth string 20 and a fifth string 26 .
- the strings are located in the platform 2 and the software 4 respectively.
- the fourth string 20 and the fifth string 26 are combined to form a sixth string 24 . Since authorization to use the software 4 is ultimately based on a comparison of the third string 8 with the sixth string 24 , it is important that the fourth string 20 and the fifth string 26 are combined in the same manner, whether by concatenation or otherwise, as the first string 6 and the second string 10 were combined to form the third string 8 in step 32 . If different methods of combination are used in steps 32 and 44 the third string 8 and the sixth string 24 would never be the same and authorization to use the software would never be granted.
- the sixth string 24 is hashed in order to form a second encryption key 28 .
- the method shown in FIG. 5 allows the software 4 to determine if it is authorized to run the platform 2 by comparing the sixth string 24 and the third string 8 . If the sixth string 24 and the third string 8 are the same then the platform 2 is authorized to utilize the software 4 . Therefore, to ensure that the sixth string 24 and the third string 8 are properly analyzed by the software 4 , the hashing algorithm used in step 46 must be exactly the same as the one used in step 34 . If the hashing functions used in steps 46 and 34 are different they would also yield a different hashing result of the sixth string 24 from that of the third string 8 , even though the two strings are the same. The difference in the hashing results would in turn produce the second encryption key 28 that is different from the first encryption key 12 . Since the main test of the method shown in FIG. 5 depends on the comparison of the first and second encryption keys 12 and 28 , any difference between the two keys will cause a denial of authorization for the software 2 , despite the fact that the software 4 should have been authorized.
- Step 48 - 54 determine if the software 4 was in fact used in conjunction with the platform 2 to create the authorization key 14 by utilizing the first and second encryption keys 12 and 28 to analyze data.
- Data could be any file, code, or variable that is stored in the platform 2 or the software 4 (e.g., first string 6 , second string 10 , third string 8 , etc.). The information that data contains is irrelevant since data provides only a sample for the encryption keys 12 and 28 to do their testing as described below.
- a first data is encrypted using the first encryption key 48 to generate a second data.
- the second data is decrypted using the second encryption key 12 to generate a third data.
- the software 4 compares the first data to the third data (i.e., the product of encryption and decryption of the first data). If the first and third data are the same (i.e., the encryption and the decryption processes are reversible), then the first and second encryption keys 12 and 28 are the same. Since the first and second encryption keys 12 and 28 are exactly the same, then the third string 8 and the sixth string 24 were obtained from the same sources (i.e., the platform 2 and the software 4 were in fact used to create the authorization key 14 ). If this is the case, then in step 56 the software 4 is authorized to run on the platform 2 .
- the third data i.e., the product of encryption and decryption of the first data.
- step 54 the software 4 is prohibited from operating on the platform 2 .
- the present invention allows for manufacturers or software makers to insure that only certain software will run on specific platforms or computing devices. Since the authorization key is created using the strings unique to the software and the platform, copying the authorization key from one platform to another may be futile. It would discourage in copying the authorization key from one platform to another because prior to operation, the software and the platform must verify that they were in fact used to create the authorization key.
- This invention is especially useful in preventing unauthorized software use in computer devices that only run one specific type of software (e.g., handheld scanners and imagers). In those devices one party usually manufactures the devices as well as provides them with the required software. Prior to this invention, it was possible for a third party to duplicate the original devices and then use the original software on that device without the permission of the original manufacturer. With the present invention, the duplicate devices would be useless to the third party. The duplicate devices would be incapable of operating the original software because they would lack the required authorization codes.
- the present invention may be advantageously utilized to overcome limitations of some operating systems with limited data security capabilities.
- some operating systems e.g., Windows CE
- Windows CE do not support the public/private-key encryption of general data.
- these operating systems do support such encryption for the specific purpose of importing and exporting “session” keys.
- the present invention takes advantage of this limited encryption capability by combining the data to be compared into keys.
- These keys formed by combining data from both the platform 2 and the software 4 , can then utilize the public/private-key functionality of such operating systems. In this manner, the present invention reduces the cost of implementation by dispensing with the need to expand the security capabilities of such operating systems.
- the present invention may also be advantageously utilized in other operating systems which do support public/private-key encryption of general data.
- the method according to the present invention adds an additional layer of obfuscation and security.
- the present invention allows for the platform 2 to be equipped to run the software 4 even after the software 4 has been released into the market. This may be accomplished by transmitting to the platform 2 (e.g., a Personal Digital Assistant or PDA) the string required to form an authorization key 14 when the user attempts to run the software 4 on the platform 2 .
- the platform 2 e.g., a Personal Digital Assistant or PDA
Abstract
Described is a method and system for controlling usage of software on a computing device. An authorization key is generated as a function of a device string and a software string. The device string is a unique string stored in the device. The software string is a unique string stored in a software authorized for use on the device. The authorization key is encrypted using a private key and stored in the device. Upon a request to use software on the device, the authorization key is decrypted using a public key corresponding to the private key. A test key is generated as a function of the device string and a request software string. The request software string is a unique string stored in the software for which use has been requested. The authorization key is compared to the test key. When the test key matches the authorization key, usage of the software for which use has been requested on the device is permitted.
Description
- The present application is a Continuation application of U.S. patent application Ser. No. 10/609,956 filed Jun. 30, 2003 entitled “System and Method for Controlling Usage of Software on Computing Devices”, the entire disclosure of which is expressly incorporated herein by reference.
- Conventional computing devices utilize a wide variety of software packages in their everyday operations. Although presently, software distribution is primarily regulated through licensing, access codes, CD-keys, etc., such security precautions are susceptible to manipulation by unauthorized third parties. Therefore, there is a need for more secure means of authorizing software usage on particular computing devices.
- The present invention relates to a method and system for controlling usage of software on a computing device. An authorization key is generated as a function of a device string and a software string. The device string is a unique string stored in the device. The software string is a unique string stored in a software authorized for use on the device. The authorization key is encrypted using a private key and stored in the device.
- Upon a request to use software on the device, the authorization key is decrypted using a public key corresponding to the private key. A test key is generated as a function of the device string and a request software string. The request software string is a unique string stored in the software for which use has been requested. The authorization key is compared to the test key. When the test key matches the authorization key, usage of the software for which use has been requested on the device is permitted.
- The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute part of the specification, illustrate several embodiments of the invention and, together with the description, serve to explain examples of the present invention. In the drawings:
-
FIG. 1 shows an exemplary system according to the present invention for controlling usage of a software; -
FIG. 2 shows an exemplary system according to the present invention for creating and storing a software authorization key; -
FIG. 3 shows a an exemplary system according to the present invention for verifying whether the software can be executed on a particular computing device; -
FIG. 4 shows an exemplary embodiment of a method for creating and storing a software authorization key according to the present invention; and -
FIG. 5 shows an exemplary embodiment of a method for verifying whether the software can be executed on a particular computing device according to the present invention. -
FIG. 1 shows an exemplary system for controlling usage of software on computing devices where the use of asoftware 4 is allowed onlyparticular platforms platforms 2 a-2 d may be any computing devices (e.g., PCs, handheld devices, PDAs, etc.) which may operate on one of a plurality of operating systems, (e.g., Windows, Unix, Apple OS, etc.). Thesoftware 4 may be any program/code (e.g., office suite, image recognition software, etc.) which a hardware/software manufacturer desires to restrict the use thereof. - The restriction of
software 4 toparticular platforms authorization keys registries registries 16 a-16 d is a digital storage area of a computing device (e.g., ROM, hard drive, etc.) that may contain information about theparticular platforms 2 a-2 d (e.g., build date, manufacturer, etc.). - As described in detail below, the
authorization keys first string platforms second string 10 stored in thesoftware 4 as shown inFIGS. 2 and 4 , so thatonly platforms software 4. Thefirst strings second string 10 are unique and specific to theplatforms software 4 respectively. Thefirst strings 6 a-6 d may be created and stored by the manufacturer in theplatforms 2 a-2 d during the production process. Thesecond string 10 may likewise be created and stored in thesoftware 4. Theplatform string 6 may be formed by combining sub-strings present on theplatform 2, such as a combination of an original equipment manufacturer (“OEM”) string and a product-name string. Thefirst strings second string 10 may not be modified by the subsequent user after the manufacturing process. The unique nature of thefirst strings second string 10 and the lack of available modification means makes them suited for identification and authorization purposes of theplatforms software 4. - As shown in
FIG. 1 , only theplatforms software 4 because they are the only ones that have theproper authorization keys authorization keys second string 10 and thefirst string platforms platforms authorization keys software 4. Conversely, theplatforms platforms software 4. -
FIG. 2 shows the generation of theauthorization key 14 using thefirst string 6 and thesecond string 10 stored in theplatform 2 and thesoftware 4, respectively. As stated above, thefirst string 6 and thesecond string 10 are specific and unique to their locations (i.e., theplatform 2 and the software 4). -
FIG. 4 shows a method for creating theauthorization key 14 which may be subsequently used by theplatform 2 to determine if it is allowed to utilize thesoftware 4. Instep 32, thefirst string 6 and thesecond string 10 are utilized to generate athird string 8. Thethird string 8, for example, may be formed by combining or concatenating thefirst string 6 and thesecond string 10. This step is important to the creation of theunique authorization key 14. Since thefirst string 6 is unique to theplatform 2 and the second string is unique to thesoftware 4, the resultingthird string 8 is specific only to a combination of theplatform 2 and thesoftware 4 that are used in creating thethird string 8. - In
step 34, thethird string 8 may be hashed in order to form afirst encryption key 12. In particular, a conventional hashing algorithm may be used to produce a hash value of thethird string 8. A person skilled in the art will understand that any one of a plurality of hashing algorithms (e.g., MD2, MD4, MD5, and SHA-1, etc.) may be used for such purpose. A hashing algorithm is part of a hashing function which transforms a set of data (i.e., the third string 8) into another form that is more suitable for computing processes (i.e., the encryption key 12). Hashing of thethird string 8 may also provide another level of security because the hashed data cannot be utilized unless it can be hashed in reverse to obtain the original data (i.e., the third string 8). - In
step 36, after thethird string 8 is hashed, the resultingfirst encryption key 12 is encrypted to form anauthorization key 14 using one of a plurality of encryption schemes. Thefirst encryption key 12, for example, may be encrypted using the private key of a private/public key pair. The private/public key pair algorithm is similar to a conventional PGP system where the private key is used to encrypt messages (e.g., email) and a public key is used to decrypt the previously encrypted messages. The PGP system may operate in the following manner: a creator of the message possesses one half of the private/public key pair, which is used to encrypt messages and the other half is distributed to parties who need to decrypt the messages sent to them by the creator. In the present invention, the private/public key pair may be used in a substantially similar manner as that in the PGP system: theencryption key 12 is exported to a binary large object (“blob”) where it is encrypted using the private key. The blob is a generic sequence of bits that contain one or more fixed-length header structures plus context specific data. This blob may be then stored in theregistry 16 as theauthorization key 14. - In step 38, the
authorization key 14 is stored in aregistry 16 of theplatform 2. For example, theauthorization key 14 may be in the form of the blob which can be exported to a file and copied to any number of computing devices of theplatform 2. As a result, all the computing devices of theplatform 2 could be capable of operatingsoftware 4 which greatly reduces the difficulties of mass-producing theauthorization key 14. -
FIG. 3 shows a system for authorizing thesoftware 4 to be utilized on theplatform 2. Theplatform 2 contains theregistry 16 in which theauthorization key 14 is stored after it was created using the method shown inFIG. 2 and 4. Prior to the operation of thesoftware 4 on theplatform 2, thesoftware 4 needs to determine if it is authorized to run on theplatform 2 by using theauthorization key 14. -
FIG. 5 shows a method for determining if thesoftware 4 is authorized to run on theplatform 2. Instep 42, theauthorization key 14 is extracted from theregistry 16 and theauthorization key 14 is decrypted in order to obtain thefirst encryption key 12. The decryption may be accomplished by using the public key of the same private/public key pair used instep 36 ofFIG. 3 . This step is similar to the decryption process of the PGP system where the public key is used to decrypt a message encrypted with a private key. If the public key used to decrypt theauthorization key 14 is from the same public/private key pair as the private key used to encrypt thefirst encryption key 12, then thesecond encryption key 28 produced as a result of this decryption will be identical to thefirst encryption key 12. - In
steps platform 2 and thesoftware 4 create asecond encryption key 28 from afourth string 20 and afifth string 26. The strings are located in theplatform 2 and thesoftware 4 respectively. Instep 44, thefourth string 20 and thefifth string 26 are combined to form asixth string 24. Since authorization to use thesoftware 4 is ultimately based on a comparison of thethird string 8 with thesixth string 24, it is important that thefourth string 20 and thefifth string 26 are combined in the same manner, whether by concatenation or otherwise, as thefirst string 6 and thesecond string 10 were combined to form thethird string 8 instep 32. If different methods of combination are used insteps third string 8 and thesixth string 24 would never be the same and authorization to use the software would never be granted. Instep 46, thesixth string 24 is hashed in order to form asecond encryption key 28. - The method shown in
FIG. 5 allows thesoftware 4 to determine if it is authorized to run theplatform 2 by comparing thesixth string 24 and thethird string 8. If thesixth string 24 and thethird string 8 are the same then theplatform 2 is authorized to utilize thesoftware 4. Therefore, to ensure that thesixth string 24 and thethird string 8 are properly analyzed by thesoftware 4, the hashing algorithm used instep 46 must be exactly the same as the one used instep 34. If the hashing functions used insteps sixth string 24 from that of thethird string 8, even though the two strings are the same. The difference in the hashing results would in turn produce thesecond encryption key 28 that is different from thefirst encryption key 12. Since the main test of the method shown inFIG. 5 depends on the comparison of the first andsecond encryption keys software 2, despite the fact that thesoftware 4 should have been authorized. - Step 48-54 determine if the
software 4 was in fact used in conjunction with theplatform 2 to create theauthorization key 14 by utilizing the first andsecond encryption keys platform 2 or the software 4 (e.g.,first string 6,second string 10,third string 8, etc.). The information that data contains is irrelevant since data provides only a sample for theencryption keys step 48, a first data is encrypted using thefirst encryption key 48 to generate a second data. Instep 50, the second data is decrypted using thesecond encryption key 12 to generate a third data. - In
step 52, thesoftware 4 compares the first data to the third data (i.e., the product of encryption and decryption of the first data). If the first and third data are the same (i.e., the encryption and the decryption processes are reversible), then the first andsecond encryption keys second encryption keys third string 8 and thesixth string 24 were obtained from the same sources (i.e., theplatform 2 and thesoftware 4 were in fact used to create the authorization key 14). If this is the case, then instep 56 thesoftware 4 is authorized to run on theplatform 2. - If the first and third data samples are different, however, then that denotes that the
software 4 was not used in the creation of theauthorization key 14. In other words, thethird string 8 and thesixth string 24 are different because they are stored ondifferent platform 2 andsoftware 4 than the ones that were used in creating theauthorization key 14. As a result, instep 54, thesoftware 4 is prohibited from operating on theplatform 2. - The present invention allows for manufacturers or software makers to insure that only certain software will run on specific platforms or computing devices. Since the authorization key is created using the strings unique to the software and the platform, copying the authorization key from one platform to another may be futile. It would discourage in copying the authorization key from one platform to another because prior to operation, the software and the platform must verify that they were in fact used to create the authorization key.
- This invention is especially useful in preventing unauthorized software use in computer devices that only run one specific type of software (e.g., handheld scanners and imagers). In those devices one party usually manufactures the devices as well as provides them with the required software. Prior to this invention, it was possible for a third party to duplicate the original devices and then use the original software on that device without the permission of the original manufacturer. With the present invention, the duplicate devices would be useless to the third party. The duplicate devices would be incapable of operating the original software because they would lack the required authorization codes.
- The present invention may be advantageously utilized to overcome limitations of some operating systems with limited data security capabilities. For example, some operating systems (e.g., Windows CE) do not support the public/private-key encryption of general data. However, these operating systems do support such encryption for the specific purpose of importing and exporting “session” keys. The present invention takes advantage of this limited encryption capability by combining the data to be compared into keys. These keys, formed by combining data from both the
platform 2 and thesoftware 4, can then utilize the public/private-key functionality of such operating systems. In this manner, the present invention reduces the cost of implementation by dispensing with the need to expand the security capabilities of such operating systems. - The present invention may also be advantageously utilized in other operating systems which do support public/private-key encryption of general data. The method according to the present invention adds an additional layer of obfuscation and security.
- It will be apparent to those skilled in the art that the present invention allows for the
platform 2 to be equipped to run thesoftware 4 even after thesoftware 4 has been released into the market. This may be accomplished by transmitting to the platform 2 (e.g., a Personal Digital Assistant or PDA) the string required to form anauthorization key 14 when the user attempts to run thesoftware 4 on theplatform 2. - It will be apparent to those skilled in the art that various modifications and variations can be made in the structure and the methodology of the present invention, without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
Claims (17)
1. A method for securing software on a computing device, comprising:
(a) generating an authorization key as a function of a device string and a software string, the device string being a unique string stored in the device, the software string being a unique string stored in a software authorized for use on the device;
(b) encrypting the authorization key using a private key; and
(c) storing the authorization key in the device.
2. The method according to claim 1 , wherein step (a) includes the following substeps:
performing at least one of combination and concatenation of the device string and the software string to create a resulting string, and
hashing the resulting string to generate the authorization key.
3. The method according to claim 2 , wherein step (b) includes the following substeps:
converting the authorization key into a binary large object, and
encrypting the binary large object using the private key to generate the encrypted authorization key.
4. The method according to claim 1 , wherein step (c) includes the substep of storing the authorization key into a registry of the device.
5. A computing device capable of securing software loaded thereon, comprising:
a processor; and
a memory arrangement storing a preloaded authorization key and a device string which is a unique string, the authorization key being generated as a function of the device string and a software string, the software string being a unique string stored in a software authorized for use on the device, the authorization key being encrypted using a private key.
6. The device according to claim 5 , wherein the device includes a portable computing device.
7. The device according to claim 5 , wherein the device is using Windows CE operating system, and wherein the software includes Windows CE compatible software.
8. The device according to claim 5 , wherein the authorization key is created by at least one of combining and concatenating of the device string and the software string to create a resulting string, the resulting string being hashed to generate the authorization key.
9. The device according to claim 8 , wherein before the authorization key is stored into the memory, the authorization key is converted into a binary large object which is encrypted using the private key to generate the encrypted authorization key.
10. The device according to claim 5 , wherein the device is one of a handheld scanner and an imager.
11. A computing device for controlling usage of software on a further computing device, comprising:
a memory arrangement; and
a processor generating an authorization key as a function of a further device string and a software string, the software string being a unique string stored in a software authorized for use on the further device, the further device string being a unique string being stored in the further device, the authorization key being encrypted using a private key,
wherein the processor stores the authorization key and a public key corresponding to the private key in the memory arrangement.
12. The device according to claim 11 , wherein the further device includes a portable computing device.
13. The device according to claim 11 , wherein the further device is using Windows CE operating system, and wherein the software includes Windows CE compatible software.
14. The device according to claim 11 , wherein the processor generates the authorization key by converting the authorization key into a binary large object and encrypting the binary large object using the private key to generate the encrypted authorization key.
15. The device according to claim 11 , wherein the device is one of a handheld scanner and an imager.
16. A computer-readable storage medium storing a set of instructions, the set of instructions capable of being executed by a processor to control usage of software on a computing device, the set of instructions performing the steps of:
(a) generating an authorization key as a function of a device string and a software string, the device string being a unique string stored in the device, the software string being a unique string stored in a software authorized for use on the device;
(b) encrypting the authorization key using a private key; and
(c) storing the authorization key in the device.
17. A method, comprising:
(a) upon a request to use software on a computing device, performing the following substeps:
decrypting an authorization key using a public key which corresponds to the private key, the authorization key generated as a function of a device string and a software string and encrypted using a private key, the device string being a unique string stored in the device, the software string being a unique string stored in a software authorized for use on the device;
generating a test key as a function of the device string and a request software string, the request software string being a unique string stored in the software for which use has been requested, and
comparing the decrypted authorization key to the test key; and
(b) when the test key matches the decrypted authorization key, permitting usage of the software for which use has been requested on the device.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/670,619 US20070174631A1 (en) | 2003-06-30 | 2007-02-02 | System and Method for Controlling Usage of Software on Computing Devices |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/609,956 US7216238B2 (en) | 2003-06-30 | 2003-06-30 | System and method for controlling usage of software on computing devices |
US11/670,619 US20070174631A1 (en) | 2003-06-30 | 2007-02-02 | System and Method for Controlling Usage of Software on Computing Devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/609,956 Continuation US7216238B2 (en) | 2003-06-30 | 2003-06-30 | System and method for controlling usage of software on computing devices |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070174631A1 true US20070174631A1 (en) | 2007-07-26 |
Family
ID=33552270
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/609,956 Active 2025-08-27 US7216238B2 (en) | 2003-06-30 | 2003-06-30 | System and method for controlling usage of software on computing devices |
US11/670,619 Abandoned US20070174631A1 (en) | 2003-06-30 | 2007-02-02 | System and Method for Controlling Usage of Software on Computing Devices |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/609,956 Active 2025-08-27 US7216238B2 (en) | 2003-06-30 | 2003-06-30 | System and method for controlling usage of software on computing devices |
Country Status (5)
Country | Link |
---|---|
US (2) | US7216238B2 (en) |
EP (1) | EP1639433A2 (en) |
JP (1) | JP2007527561A (en) |
CA (1) | CA2529064A1 (en) |
WO (1) | WO2005001650A2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020052850A1 (en) * | 1994-10-27 | 2002-05-02 | Mitsubishi Corporation | Digital content management system and apparatus |
US8554684B2 (en) | 1994-04-01 | 2013-10-08 | Intarsia Software Llc | Controlling database copyrights |
US8595502B2 (en) | 1995-09-29 | 2013-11-26 | Intarsia Software Llc | Data management system |
US9245260B2 (en) | 1994-10-27 | 2016-01-26 | Xylon Llc | Data copyright management |
WO2021218331A1 (en) * | 2020-04-28 | 2021-11-04 | 深圳壹账通智能科技有限公司 | Offline software licensing method, apparatus and device, and storage medium |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030033626A1 (en) | 2000-07-31 | 2003-02-13 | Hahn Frederick M. | Manipulation of genes of the mevalonate and isoprenoid pathways to create novel traits in transgenic organisms |
JP4868801B2 (en) * | 2005-09-13 | 2012-02-01 | キヤノン株式会社 | License authentication device |
US8635309B2 (en) | 2007-08-09 | 2014-01-21 | Hand Held Products, Inc. | Methods and apparatus to change a feature set on data collection devices |
US9239920B2 (en) * | 2013-04-23 | 2016-01-19 | Qualcomm Incorporated | Generation of working security key based on security parameters |
WO2015070160A1 (en) * | 2013-11-08 | 2015-05-14 | MustBin Inc. | Bin enabled data object encryption and storage apparatuses, methods and systems |
US20170076106A1 (en) | 2015-09-16 | 2017-03-16 | Qualcomm Incorporated | Apparatus and method to securely control a remote operation |
JP6581611B2 (en) * | 2017-02-21 | 2019-09-25 | 日本電信電話株式会社 | Authentication key sharing system and authentication key sharing method |
CN113496011B (en) * | 2020-04-03 | 2024-01-26 | 杭州海康威视数字技术股份有限公司 | Calling authority authentication method of protected intelligent application and intelligent device |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002333927A (en) * | 2001-05-08 | 2002-11-22 | Sony Corp | Data distribution method, program for data distribution method, data processing method and recording medium |
JP2002351565A (en) * | 2001-05-23 | 2002-12-06 | Interstate:Kk | System, method and program for preventing illegal use |
US20030084332A1 (en) * | 2001-10-26 | 2003-05-01 | Koninklijke Philips Electronics N.V. | Method for binding a software data domain to specific hardware |
-
2003
- 2003-06-30 US US10/609,956 patent/US7216238B2/en active Active
-
2004
- 2004-06-24 CA CA002529064A patent/CA2529064A1/en not_active Abandoned
- 2004-06-24 WO PCT/US2004/020142 patent/WO2005001650A2/en active Application Filing
- 2004-06-24 JP JP2006517581A patent/JP2007527561A/en active Pending
- 2004-06-24 EP EP04776971A patent/EP1639433A2/en not_active Withdrawn
-
2007
- 2007-02-02 US US11/670,619 patent/US20070174631A1/en not_active Abandoned
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8554684B2 (en) | 1994-04-01 | 2013-10-08 | Intarsia Software Llc | Controlling database copyrights |
US20020052850A1 (en) * | 1994-10-27 | 2002-05-02 | Mitsubishi Corporation | Digital content management system and apparatus |
US7827109B2 (en) * | 1994-10-27 | 2010-11-02 | Makoto Saito | Digital content management system and apparatus |
US8448254B2 (en) | 1994-10-27 | 2013-05-21 | Intarsia Software Llc | Digital content management system and apparatus |
US9245260B2 (en) | 1994-10-27 | 2016-01-26 | Xylon Llc | Data copyright management |
US8595502B2 (en) | 1995-09-29 | 2013-11-26 | Intarsia Software Llc | Data management system |
WO2021218331A1 (en) * | 2020-04-28 | 2021-11-04 | 深圳壹账通智能科技有限公司 | Offline software licensing method, apparatus and device, and storage medium |
Also Published As
Publication number | Publication date |
---|---|
CA2529064A1 (en) | 2005-01-06 |
WO2005001650A3 (en) | 2007-11-08 |
WO2005001650A2 (en) | 2005-01-06 |
US7216238B2 (en) | 2007-05-08 |
JP2007527561A (en) | 2007-09-27 |
EP1639433A2 (en) | 2006-03-29 |
US20050005134A1 (en) | 2005-01-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20070174631A1 (en) | System and Method for Controlling Usage of Software on Computing Devices | |
US9992014B2 (en) | Methods for cryptographic delegation and enforcement of dynamic access to stored data | |
US6044155A (en) | Method and system for securely archiving core data secrets | |
TWI684890B (en) | System and method for computing device with improved firmware service security using credential-derived encryption key | |
US9281949B2 (en) | Device using secure processing zone to establish trust for digital rights management | |
US7266699B2 (en) | Cryptographic infrastructure for encrypting a database | |
US9847880B2 (en) | Techniques for ensuring authentication and integrity of communications | |
US8301896B2 (en) | Multi-level file digests | |
US20030219121A1 (en) | Biometric key generation for secure storage | |
US6339828B1 (en) | System for supporting secured log-in of multiple users into a plurality of computers using combined presentation of memorized password and transportable passport record | |
US6976167B2 (en) | Cryptography-based tamper-resistant software design mechanism | |
US20060005046A1 (en) | Secure firmware update procedure for programmable security devices | |
EP3694143B1 (en) | Enabling access to data | |
US20100138652A1 (en) | Content control method using certificate revocation lists | |
US20080072066A1 (en) | Method and apparatus for authenticating applications to secure services | |
US20020087866A1 (en) | Secure authentication of users via intermediate parties | |
KR20130056342A (en) | Secure and efficient content screening in a networked environment | |
US7805616B1 (en) | Generating and interpreting secure and system dependent software license keys | |
US20100287378A1 (en) | Signatures for multiple encodings | |
CN101048720A (en) | Proof of execution using random function | |
US20060143477A1 (en) | User identification and data fingerprinting/authentication | |
CN113468545A (en) | File encryption and decryption method, device and system | |
KR20210143846A (en) | encryption systems | |
KR100749868B1 (en) | Device Keys | |
Mani et al. | Cloud Security and Data Integrity with Client Accountability Framework |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SYMBOL TECHNOLOGIES, INC., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HERROD, ALLAN;EPSHTEYN, ALAN J.;SCHREIB, ROBERT J.;REEL/FRAME:018873/0269;SIGNING DATES FROM 20030903 TO 20030909 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |